我们公司正在研究在手动回归测试期间使用 cobertura 代码覆盖率的想法，以找出我们在哪里拥有“相邻功能”。一般的想法是，如果回归测试 A 命中方法 businessLogicFoo()，并且回归测试 B 也命中该方法，我们可以说回归测试 A 和 B 具有“相邻功能”。
我们对有效地确定哪些回归测试具有“相邻功能”特别感兴趣，以便我们可以安排更好的回归运行（我们有更多的测试需要测试——所以我们总是最终测试所有回归测试的一个子集）。
有没有人尝试过这样的事情？使用 cobertura 或其他代码覆盖率库？
我的第一个猜测是我们编写了一个 groovy 脚本（我首选的脚本语言）来将 cobertura 报告导出为 XML，然后解析出所涵盖的类/方法 - 过滤掉任何多余的类 - 然后找到两个报告之间的方法/类交集. 理想情况下，所有控制都在 Maven 中。但我只是猜测。
我们的测试覆盖工具将轻松计算测试覆盖向量的交集、并集、补集、集差，使您的交集计算起来很简单。
您可以将单个测试与其自己的测试覆盖向量相关联，并计算其与其他测试的交集，告诉您两个测试有多少重叠。如果它们有很小的重叠，那么它们在你的表征中是“相邻的”。他们通常会使用一些共享的“核心功能”，这可能会混淆问题，但是您可以通过将执行该核心功能的多个测试相交来计算这一点，然后将其减去，以查看它们不共享的内容。
更好的是，如果您修改一些代码，该工具会告诉您哪些测试覆盖率集（例如，哪些测试）受到影响，因此您需要运行哪些。更重要的是，这告诉您不需要运行哪些。如果您的测试是手动的，这应该有助于最大限度地减少重新测试的工作量。
您的猜测听起来很正确（尽管我自己会使用 Ruby :)）。但是，当您确定您的哪些测试可能重复时，您当然必须确定这些测试是否真的是多余的（它们可能只是部分重叠，在这种情况下，将它们组合起来就是答案，而不是废弃一个有利于另一个）。我不知道任何方法，除了手动检查所有已识别的命中来做到这一点。