我们正在寻找一种创造性的方法来衡量独立于现有代码的新代码的代码覆盖率。我们有一个大型遗留项目，并希望开始在任何新功能上获得 90% 以上的覆盖率。我们想要一种方法来轻松查看过滤掉任何旧代码的报告，以确保新功能符合我们的目标。显然，该项目的整体覆盖率仍在增加，但需要一种非手动方式来向我们提供有关新代码活动的反馈。由于我们可以查看源文件上的日期，因此我们可以将其用于静态分析。由于 Cobertura 正在分析他们有新日期的类文件，因此这种技术不起作用。
有什么想法吗？
堆栈：
Java 1.5 JUnit 科贝图拉 哈德森
【问题讨论】：
标签： java code-coverage cobertura
我们也遇到过类似的情况。想要测试新代码，但无法一次测试所有旧代码。我们所做的与您所要求的不完全一样，但可能会给您一个想法。
我们有一个名为 linecoverage.standard 的文件和一个名为 branchcoverage.standard 的文件，它们位于构建服务器（和本地副本）上。它们内部有一个带有当前行和分支覆盖范围限制的数字。如果签入的代码低于标准，则构建失败。如果它符合标准，则通过构建。如果它高于标准，则编写一个等于当前覆盖范围的新标准。
这意味着我们的代码覆盖率永远不会变差，而且应该会慢慢上升。如果新代码达到 90%，覆盖率将继续攀升。你也可以设定一个目标，比如每周将标准提高 1 倍，直到达到你的最终目标（90%）。每周必须对旧代码添加一些测试并不是一个坏主意，如果时间足够长的话。
我们目前的覆盖率高达 75%... 与一年前的 0% 相比相当不错。
【讨论】：
我使用svn blame 结合gcov 的输出为一个大型C++ 项目执行此操作。如果将这两个结果压缩在一起，则每行都有修订信息和覆盖率信息。我实际上将这一切加载到数据库中以进行查询（例如向我展示自 r1234 以来 joe 编写的所有未覆盖的行）。如果您只想要一个总数，您可以避免在总数中计算“旧”未覆盖的行。
【讨论】：
查看emma.sourceforge 和相关的Eclipse 插件here（如果您使用的是Eclipse）
我认为此工具可以通过准确选择要测试的覆盖范围来满足您的需求。
【讨论】：
IMO 最好的选择是将代码库拆分为“新”和“旧”部分。然后要么只对“新”部分运行测试覆盖率分析，要么忽略“旧”部分的结果。
实现此目的的两种最佳方法是 a) 将代码库拆分为两个源代码树（两个项目之间存在依赖关系），或 b) 在单个项目中维护两个单独的包层次结构。
两个单独的项目可能更可取，但如果旧代码库和新代码库之间存在循环依赖关系（旧代码依赖于新代码，新代码依赖于旧代码），这可能是不可能的。如果你可以管理它，新旧代码之间的单向依赖也会使组合的代码库更容易理解。
完成此操作后，要么调整 cobertura，使其仅分析您想要的位，要么至少只关注代码库的“新”部分。另一个提示是，在此方案中，最好在重构/添加测试时将代码位从“遗留”部分移动到“新”部分（如果代码经常朝另一个方向移动，则不是这样）好:-)。
【讨论】：
我们使用 sonar.exclusions 属性如下所示： 我们使用 Sonar 来显示代码覆盖率报告（由 Cobertura 报告）。
a) 确定您不希望报告覆盖率的类（旧类） 使用您的 SCM 命令行客户端。 例如：p4 文件 //depot/...@2000/01/01,@2013/07/13 git log --until="5 天前"
将此列表定向到文件中。 您将需要根据您使用的 SCM 工具进行一些解析，并且您的目标文件应该每行包含一个文件名。
eg. the destination file is excludeFile.list should look like below:
abc.java
xyz.java
...
b) 现在..当您与 Sonar（来自 Jenkins Job）集成时，请使用以下属性。
-Dsonar.exclusions=<filename>
您在 Sonar 中的最终覆盖率报告仅包含您的新课程（在上例中添加于 07/13 之后）。
【讨论】：
我们将您正在尝试做的事情称为Test Gap analysis。这个想法是测试您在开发过程中对大型软件系统所做的所有（或至少大部分）更改，因为这是最多错误的地方。 empirical evidence 也支持这种直觉！
Teamscale 是一个工具，可以满足您的需求，并且可以处理 Cobertura 报告。优点是，您只需像往常一样测量覆盖率，然后将报告上传到 Teamscale，Teamscale 将执行测试差距分析，以逐个方法突出显示新的/更改但未测试的代码。
完全免责声明：我在 CQSE 工作，这家公司是 Teamscale 的开发者。
【讨论】：
在我的场景中，我们需要在日常流程中测量新代码。我们所做的是在本地安装sonarquobe，开发人员可以在这里检查他们的代码质量控制，例如声纳可以提供给我们的新代码的代码覆盖率，并立即采取行动。
对于全局指标，我们仅针对生产代码实施了 sonarquobe，并从那里收集所有质量指标（例如新代码覆盖率）
【讨论】：