2

前几天，我们在不同的开发人员和项目负责人之间就代码覆盖工具和相应报告的使用进行了激烈的讨论。

  • 你在你的项目中使用代码覆盖率吗？如果是，为什么不呢？
  • 代码覆盖率是您构建或持续集成的固定部分，还是您只是不时使用它？
  • 您如何处理从报告中得出的数字？
4

11 回答 11

4

我们使用代码覆盖率来验证我们在测试工作中没有遗漏重要部分。一旦一个里程碑左右，我们就会运行一份完整的覆盖率报告，并花几天时间分析结果，为我们错过的区域添加测试覆盖率。

我们不会在每次构建时都运行它，因为我不知道我们是否会定期对其进行分析以证明这一点。

我们分析大块未命中代码的报告。我们发现这是最有效的使用方式。在过去，我们会尝试达到特定的代码覆盖率目标，但在某个时间点之后，回报变得非常减少。相反，最好使用代码覆盖率作为一种工具来确保您没有忘记任何事情。

于 2009-02-13T06:30:35.380 回答
3

1) 是的，我们确实使用代码覆盖率

2）是的，它是 CI 构建的一部分（为什么不呢？）

3) 重要的部分——我们不寻求 100% 的覆盖率。我们要寻找的是有缺陷/复杂的代码，这些代码很容易从您的单元测试中找到，并且开发人员/主管会知道系统的微妙部分。我们确保此类代码区域的覆盖率良好，并且随着时间的推移而增加，而不是随着人们在没有必要测试的情况下进行更多修复而减少。

于 2009-02-13T06:33:18.493 回答
2

查看代码覆盖率的方法是查看未覆盖的内容并找出未覆盖的原因。代码覆盖率只是告诉我们，当单元测试运行时，代码行正在被命中。它并没有告诉我们代码是否正常工作。100% 的代码覆盖率是一个不错的数字，但在中/大型项目中很难实现。

于 2009-02-18T23:07:33.107 回答
2

代码覆盖率告诉您“捕捉错误”的网络有多大，但它并没有告诉您网络中的漏洞有多大。

将其用作衡量测试工作的指标，而不是绝对指标。

可以编写可以为您提供 100% 覆盖率并且根本不测试任何内容的代码。

于 2009-02-13T07:28:11.013 回答
1

我喜欢测量任何重要项目的代码覆盖率。如前所述，尽量不要太着迷于实现任意/神奇的百分比。有更好的指标，例如基于复杂性的风险、包/命名空间的覆盖率等。

查看此示例 Clover仪表板以了解类似的想法。

于 2009-02-13T06:48:49.190 回答
1

我们在构建中这样做，我们看到它不应该低于某个值，比如 85%。我还做了自动 Top 10 Largest Not-covered 方法，以了解开始覆盖的内容。

于 2009-02-13T07:00:55.603 回答
0

我发现这取决于代码本身。我不会重复 Joel 在 SO podcast #38 中的陈述，但结果是“尽量务实”。

代码覆盖率在应用程序的核心元素中非常好。

我将代码视为依赖树，如果叶子工作（例如基本 UI 或调用单元测试 DAL 的代码）并且我在开发或更新它们时对它们进行了测试，那么它们很有可能会工作，如果有错误，那么查找或修复并不难，因此模拟一些测试所花费的时间可能会浪费时间。是的，有一个问题是他们所依赖的代码的更新可能会影响他们，但同样，这是一个个案，他们所依赖的代码的单元测试应该涵盖它。

当涉及到代码的主干或分支时，是的，功能的代码覆盖率（相对于每个功能）非常重要。

例如，我最近在一个团队中构建了一个应用程序，该应用程序需要一系列计算来计算碳排放量。我编写了一套测试来测试每一个计算，并且在这样做时很高兴看到依赖注入模式运行良好。

不可避免地，由于政府行为的改变，我们不得不在方程中添加一个参数，并且所有 100 多个测试都失败了。

我意识到要更新它们，除了测试拼写错误（我可以测试一次），我是单元/回归测试数学，并最终把时间花在构建应用程序的另一个区域上。

于 2009-02-13T11:51:05.343 回答
0

许多切换到 Agile/XP 的团队使用代码覆盖率作为衡量其测试自动化工作 ROI 的间接方式。

我认为这是一个实验——假设“如果我们开始编写单元测试，我们的代码覆盖率将会提高”——通过 CI 自动收集相应的观察结果，在图表中报告它等是有意义的。

您可以使用结果来检测粗略点：例如，如果更多覆盖率的趋势在某个时候趋于平稳，您可能会停下来询问发生了什么。也许团队无法编写相关的测试。

于 2009-02-13T07:05:09.807 回答
0

我们使用代码覆盖率来确保我们的测试中没有重大漏洞，并且它每晚在我们的 CI 中运行。

由于我们还有一整套贯穿整个堆栈的 selenium-web 测试，我们还做了一个额外的覆盖技巧：

我们设置了覆盖运行的 Web 应用程序。然后我们运行硒测试的全自动测试电池。其中一些只是冒烟测试。

运行全套测试后，我们可以通过查看覆盖率和检查代码来识别可疑的死代码。这在处理大型项目时非常好，因为一段时间后您可能会拥有大量死代码。

对于我们执行此操作的频率，我们实际上并没有任何固定的指标，但它全部设置为通过一两个按键运行。

于 2009-02-13T07:09:45.070 回答
0

我们确实使用代码覆盖率，它集成在我们的夜间构建中。有几种工具可以分析覆盖率数据，通常它们会报告

  1. 报表覆盖率
  2. 分支覆盖
  3. MC/DC 覆盖范围

我们预计将达到 + 90% 的语句和分支覆盖率。另一方面，MC/DC 覆盖为测试团队提供了更广泛的意义。对于未发现的代码，顺便说一下，我们期望有理由记录。

于 2009-02-13T07:22:59.827 回答
0

1）是的，我们确实测量了简单的节点覆盖率，因为：

  • 使用我们当前的项目很容易做到*（Rails 网络应用程序）
  • 它鼓励我们的开发人员编写测试（一些来自临时测试的背景）

2) 代码覆盖率是我们持续集成过程的一部分。

3) 报告中的数字用于：

  • 强制执行最低覆盖率（95% 否则构建失败）
  • 找到应该测试的代码段

在系统的某些部分，测试并不是那么有帮助（通常需要使用模拟对象来处理外部系统）。但是通常具有良好的覆盖范围可以更容易地维护项目。人们知道修复或新功能不会破坏现有功能。

*为 Rails 设置所需覆盖范围的详细信息：Min Limit 95 Ahead

于 2010-03-14T16:35:27.157 回答