Java 查找代码覆盖率交叉点的工具？

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

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

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

---

我的第一个猜测是，我们编写一个groovy脚本（我首选的脚本语言）将cobertura报告导出为XML，然后解析出所包含的类/方法-过滤掉任何多余的类-然后找到两个报告之间的方法/类交合点。理想情况下，所有控制器都在maven中。但我只是在猜测。

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

我们的工具将轻松计算测试覆盖向量的交点、并集、补集、差集，使交点的计算变得简单

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

更好的是，如果您修改一些代码，该工具将告诉您哪些测试覆盖率集（例如，哪些测试）受到影响，因此您需要运行哪些测试覆盖率集。更重要的是，这会告诉你哪些不需要运行。如果您的测试是手动的，

---

这对于最小化重新测试的工作量非常有帮助。

您的目标是识别（几乎）重复的测试吗？在我的经验中，“有更多的时间去测试”是一个非常不寻常的情况。为什么你的测试要花这么长时间运行？我遇到过这样的情况，因为各种原因，有些测试需要很长时间运行。测试需要一个life数据库，运行在其中的大量数据上，我们的测试/开发系统运行在动力严重不足的硬件和网络上。因此，应用程序的完整测试套件可能需要半个多小时才能运行（有时在网络/数据库负载高峰期间需要2个多小时）。它很少完全运行当然，我们通常只运行子集。很抱歉，这可能不清楚：测试是手动功能测试，不是自动的，不是单元测试。