如何处理代码覆盖？

有一天，我们在不同的开发人员和项目负责人之间进行了艰苦的讨论，讨论了代码覆盖工具和使用相应的报告。如何处理代码覆盖？

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

来源

2009-02-13 Kai Huppmann

我们使用代码覆盖范围来验证我们在测试工作中不会丢失大部分零件。一旦我们完成了一个里程碑，我们将运行完整的覆盖报告并花费几天时间分析结果，并为我们错过的区域添加测试覆盖率。

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

我们分析unhit代码的大块报告。我们发现这是最有效的用途。在过去，我们会尽力达成一个特定的代码覆盖目标，但在某个点之后，回报会变得非常减少。相反，最好使用代码覆盖作为工具来确保你没有忘记任何东西。

来源

2009-02-13 06:30:35

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

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

3）最重要的部分 - 我们不看为100％覆盖。我们所寻找的是bug /复杂的代码，这很容易从你的单元测试中找到，Devs/Leads将会知道系统的微妙部分。我们确保这些代码区域的覆盖范围是好的，并且随着时间的推移而增加，而不是随着人们在没有必要的测试的情况下进行更多修复而入侵。

来源

2009-02-13 06:33:18 MrTelly

我喜欢测量任何非平凡项目的代码覆盖率。如前所述，尽量不要过分追求达到任意/神奇的百分比。有更好的度量标准，比如基于复杂度的风险度，包/名称空间的覆盖率等。

请看这个样本Clover dashboard以获得类似的想法。

来源

2009-02-13 06:48:49

我们在构建中完成它，并且我们发现它不应该低于某个值，例如85％。我也做自动十大最大未涉及的方法，知道要开始覆盖。

来源

2009-02-13 07:00:55

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

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

您可以使用结果来检测粗略的情况：例如，如果在某个时候更多覆盖级别的趋势消失，您可能会停下来询问发生了什么。也许团队在编写相关的测试时遇到了麻烦。

来源

2009-02-13 07:05:09 Morendil

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

因为我们还拥有一套完整的，通过堆，我们还做了一个额外的覆盖伎俩运行一路硒网测试：

我们成立了网络应用程序与运行覆盖。然后我们运行完整的硒测试自动化测试电池。其中一些只是烟雾测试。

运行完整的测试套件后，只需查看覆盖率和检查代码，即可发现可疑的死代码。在处理大型项目时，这非常好，因为在一段时间之后，您可能会有大量的死代码分支。

实际上我们并没有任何固定的度量标准，但它的设置都是使用一两个按键来运行。

来源

2009-02-13 07:09:45 krosenvold

我们使用代码覆盖率，它被集成在我们的每晚构建。有几种工具来分析覆盖数据，通常他们的报告

语句覆盖
分支覆盖
MC/DC覆盖

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

来源

2009-02-13 07:22:59 kokeksibir

代码覆盖率告诉你“bug捕获”网络有多大，但它并不能告诉你网络中有多大的空洞。

将其用作衡量您的测试工作的指标，但不能作为绝对指标。

可以编写代码，它会给你100％的覆盖率，并且根本不测试任何东西。

来源

2009-02-13 07:28:11 Hibri

我发现它取决于代码本身。我不会重复Joel在第38期播客中的言论，但结果是“尽力务实”。

代码覆盖率在应用程序的核心元素中很棒。

我将代码视为依赖树，如果叶子工作（例如基本UI或代码调用单元测试DAL），并且在开发它们或更新它们时测试它们，他们工作的可能性很大，如果有bug，那么就不难发现或修复，因此模拟一些测试所花费的时间可能会浪费时间。是的，他们所依赖的代码的更新可能会影响到他们，但这又是一个例子，并且他们依赖的代码的单元测试应该覆盖它。

说到中继线或代码分支，代码覆盖范围是功能（与每个功能相对）非常重要。

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

不可避免的是，由于政府行为的改变，我们不得不为参加方程式增加一个参数，并且所有100+个测试都打破了。

我意识到要更新它们，除了测试一个错字（我可以测试一次）之外，我还在进行单元/回归测试数学计算，最后花时间在构建应用程序的另一个区域。

来源

2009-02-13 11:51:05 johnc

查看代码覆盖的方法是查看未覆盖多少，并找出未覆盖的原因。代码覆盖只是告诉我们，单元测试运行时，代码行正在被击中。它并没有告诉我们代码能够正常工作。 100％的代码覆盖率是一个很好的数字，但在中型/大型项目中很难实现。

来源

2009-02-18 23:07:33 azamsharp

1）是的，我们做的测量简单的节点覆盖，东阳：

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

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

3）从报告的数字是用于：

执行覆盖的最低水平（95％，否则生成失败）
的代码查找部分，其应该被测试

有些系统中的测试并不是那么有用（通常需要使用模拟对象来处理外部系统）。但通常具有良好的覆盖率使维护项目变得更加容易。我们知道修补程序或新功能不会破坏现有功能。

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

来源

2010-03-14 16:35:27 user132447

如何处理代码覆盖？

回答

相关问题