查找代码覆盖交叉点的工具?

发布于 2024-10-17 15:26:45 字数 421 浏览 9 评论 0原文

我们公司正在研究在手动回归测试期间使用 cobertura 代码覆盖率的想法,以找出我们在哪里具有“相邻功能”。一般的想法是,如果回归测试 A 命中了businessLogicFoo() 方法,并且回归测试 B 也命中了该方法,我们可以说回归测试 A 和 B 具有“相邻功能”。

我们特别感兴趣的是有效地确定哪些回归测试具有“相邻功能”,以便我们可以安排更好的回归运行(我们有更多的测试需要测试 - 所以我们总是最终测试所有值得回归的测试的子集)。

以前有人尝试过类似的事情吗?使用 cobertura 或其他一些代码覆盖率库?

我的第一个猜测是,我们编写一个常规脚本(我首选的脚本语言)来将 cobertura 报告导出为 XML,然后解析出所涵盖的类/方法 - 过滤掉任何多余的类 - 然后找到两个报告之间的方法/类交集。理想情况下所有控件都在 Maven 中。但我只是猜测。

Our company is investigating the idea of using cobertura code coverage during manual regression tests to find out where we have 'adjacent functionality'. The general idea would be if regression test A hit method businessLogicFoo(), and regression test B also hit that method we could say that regression test A and B have 'adjacent functionality'.

We're particularly interested in efficiently determining which regression tests have 'adjacent functionality' so that we can schedule better regression runs (we have vastly more tests that time to test - so we always end up testing a subset of all regression worthy tests).

Has anyone attempted something like this before? With cobertura or some other code coverage library?

My first guess is that we write a groovy script (my preferred scripting language) to export the cobertura reports as XML, then parse out the classes/methods covered - filter out any superfluous classes - and then find method/class intersections between the two reports. Ideally all controlle in maven. But I'm just guessing.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

甜警司 2024-10-24 15:26:45

你的猜测听起来是正确的(尽管我自己会使用 Ruby :))。
但是,当您确定哪些测试可能重复时,您当然必须确定这些测试是否真的是多余的(它们可能只是部分重叠,在这种情况下,将它们组合起来就是答案,而不是放弃一个)另一个)。
除了手动检查所有已识别的命中之外,我不知道有什么方法可以做到这一点。

Your guess sounds about right (though I'd use Ruby myself :)).
But hen you've determined which of your tests are potentially duplicated, you will then of course have to determine whether the tests are really superfluous (they may just partially overlap, in which case combining them would be the answer, not scrapping one in favour of another).
I don't know any way except manually going over all identified hits to do that.

染柒℉ 2024-10-24 15:26:45

我们的测试覆盖率工具将轻松计算测试覆盖率向量的交集、并集、补集、差集,使你的交叉点计算起来很简单。

您可以将单个测试与其自己的测试覆盖向量相关联,并计算该测试与其他测试的交集,从而告诉您两个测试有多少重叠。如果它们有很小的重叠,那么根据您的描述,它们是“相邻的”。通常,他们会执行一些共享的“核心功能”,这可能会混淆问题,但是您可以通过执行该核心功能的多个测试的交集来计算这一点,并将其减去,以查看它们不共享的内容。

更好的是,如果您修改某些代码,该工具会告诉您哪些测试覆盖率集(例如,哪些测试)受到影响,以及您需要运行哪些测试覆盖率集。更重要的是,这告诉您不需要运行哪些。如果您的测试是手动的,
这对于最大限度地减少重新测试工作应该非常有帮助。

Our Test Coverage tools will compute intersections, unions, complements, set differences, of test coverage vectors easily, making your intersections trivial to compute.

You can associate an individual test with its own test coverage vector, and compute intersections of that with other tests, telling you how much overlap two tests have. If they have small overlap, then they are "adjacent" by your characterization. Often they will exercised some shared "core functionality" which might confuse the issue, but you can compute this by intersection of a number of tests which exercise that core functionality, and subtract it away, to see what they do not share.

Even better, if you modify some code, the tool will tell you which test coverage sets (e.g., which tests) were affected, and therefore which ones you need to run. More importantly, this tells which ones you don't need to run. If your tests are manual,
this should be really helpful in minimizing re-testing effort.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文