11

我们正在寻找一种创造性的方法来衡量与现有代码分开的新代码的代码覆盖率。我们有一个大型遗留项目，并希望开始在任何新功能上获得 90% 以上的覆盖率。我们想要一种方法来轻松查看过滤掉任何旧代码的报告，以确保新功能符合我们的目标。显然，该项目的整体覆盖率仍在增加，但需要一种非手动方式来向我们提供有关新代码活动的反馈。由于我们可以查看源文件上的日期，因此我们可以将其用于静态分析。由于 Cobertura 正在分析他们有新日期的类文件，因此这种技术不起作用。

有任何想法吗？

堆：

Java 1.5 JUnit Cobertura Hudson

4

7 回答 7

3

我们有类似的情况..想要测试新代码，但无法一次测试所有旧代码。我们所做的并不完全是您所要求的，但可能会给您一个想法。

我们有一个名为 linecoverage.standard 的文件和一个名为 branchcoverage.standard 的文件，它们位于构建服务器（和本地副本）上。它们内部有一个带有当前行和分支覆盖范围限制的数字。如果签入的代码低于标准，则构建失败。如果它符合标准，则通过构建。如果它高于标准，则编写一个等于当前覆盖范围的新标准。

这意味着我们的代码覆盖率永远不会变差，而且应该会慢慢上升。如果新代码达到 90%，覆盖率将继续攀升。您还可以设定一个目标，例如每周将标准提高 1 倍，直到达到您的最终目标 (90%)。每周必须对旧代码添加一些测试并不是一个坏主意，如果它分布在足够长的时间内。

我们目前的覆盖率高达 75%ish……相当不错，低于一年前的 0%。

于 2010-09-03T16:07:00.620 回答
1

I did this for a large C++ project by using svn blame combined with the output of gcov. If you zip those two results together you have revision information and coverage information for each line. I actually loaded this all into a database to do queries (e.g. show me all the uncovered lines written by joe since r1234). If you only want an aggregate number you can just avoid counting 'old' uncovered lines in your total.

于 2010-10-19T20:12:49.300 回答
1

在此处查看emma.sourceforge和相关的 Eclipse 插件（如果您使用的是 Eclipse）

我认为该工具可以通过准确选择要测试的覆盖范围来满足您的需求。

于 2010-09-03T14:20:22.353 回答
0

IMO 最好的选择是将代码库分成“新”和“旧”部分。然后要么只在“新”部分运行测试覆盖分析，要么忽略“旧”部分的结果。

实现此目的的两种最佳方法是 a) 将代码库拆分为两个源代码树（两个项目之间存在依赖关系），或 b) 在单个项目中维护两个单独的包层次结构。

两个单独的项目可能更可取，但如果旧代码库和新代码库之间存在循环依赖关系（旧代码依赖于新代码，新代码依赖于旧代码），则可能无法实现。如果你可以管理它，新旧代码之间的单向依赖也会使组合的代码库更容易理解。

完成此操作后，要么调整 cobertura 使其仅分析您想要的位，要么至少只关注代码库的“新”部分。另一个提示是，在此方案中，最好在重构/添加测试时将代码位从“遗留”部分移动到“新”部分（如果代码经常朝另一个方向移动，则不是这样）好的 ：-）。

于 2012-12-10T07:59:54.140 回答
0

我们使用 sonar.exclusions 属性如下所示： 我们使用 Sonar 显示代码覆盖率报告（由 Cobertura 报告）。

a) 确定您不希望报告覆盖率的类（传统类）使用您的 SCM cmd 行客户端。例如：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 之后添加的）。

于 2013-07-19T00:01:21.210 回答
0

我们将您正在尝试做的事情称为测试差距分析。这个想法是测试您在开发期间对大型软件系统所做的所有（或至少大部分）更改，因为这是最多的错误所在。也有经验证据支持这种直觉！

Teamscale是一种工具，可以满足您的需求，并且可以处理 Cobertura 报告。优点是，您只需像往常一样测量覆盖率，然后将报告上传到 Teamscale，Teamscale 将执行测试差距分析，以逐个方法突出显示新的/更改但未测试的代码。

完全免责声明：我在CQSE工作，这家公司是制作 Teamscale 的公司。

于 2019-08-14T06:48:42.353 回答
0

在我的场景中，我们需要在日常流程中测量新代码。我们所做的是在本地安装sonarquobe，开发人员可以在其中检查他们的代码质量控制，例如声纳可以提供给我们的新代码的代码覆盖率，并立即采取行动。

对于全局指标，我们只为我们的生产代码实施了 sonarquobe，并从那里收集所有质量指标（例如新代码覆盖率）

于 2021-11-18T15:55:06.803 回答