代码覆盖率最佳实践，谷歌权威推荐……

本文来自谷歌工程博客 2020 年 8 月 17 日发表的一篇文章。

题目为《代码覆盖率最佳实践》，

作者是 Carlos Arguelles, Marko Ivanković‎ 和 Adam Bender 。

本文观点简介：

---

1. 代码覆盖率为开发人员的工作流程带来了显著好处。
   

2. 增加代码覆盖率的努力通常会带来卓越工程文化

3. 只是追求高的代码覆盖率百分比，并不能保证测试覆盖率的高质量。

4. 代码覆盖率数据突出显示还有多少内容没有被覆盖

5. 没有一个“理想的代码覆盖率数字”可以普遍适用于所有产品

6. 我们应该致力于全面提高代码覆盖率

7. 不应该着迷于如何将代码覆盖率从90％提高到95％

8. 比涵盖行的百分比更重要的是，人工判断未涵盖的实际代码行的风险

9. 虽然你的产品现在具有较低的代码覆盖率，但并不意味着您不能采取具体的渐进步骤来逐步改进它

10. 虽然超过90％的项目范围的目标很可能不值得，但每次提交的99％的覆盖率目标是合理的

11. 集成/系统测试代码的覆盖范围也很重要。

12. 我们应该设置关卡，限制那些不符合我们代码覆盖标准的代码部署到生产环境

正文如下：

---

我们花了数十年的时间在各种大型软件公司中推动软件测试改进。我们一直提倡的领域之一是使用代码覆盖率数据来评估风险并确定测试中的差距。 

但是，测试覆盖率的价值是一个备受争议的话题，具有强烈观点和令人惊讶的两极分化。每当在很多人的场合里提到代码覆盖率时，就会出现看似无休止的争论。由于人们都在各自营地中寻找安全掩体，所以往往这些对话没有任何成果。

本文档的目的是为您提供工具，引导人们讨论它的方方面面，并找到共同点，以便您可以继续前进，并切实地使用覆盖率信息。我们在代码覆盖率方面提出了最佳实践，以有效地实现代码健康。它们是：

1. 代码覆盖率为开发人员的工作流程带来了显著好处。虽然，它不是衡量测试质量的完美方法，但它确实提供了具有可行数据的合理、客观、行业标准的度量标准。它既不需要大量的人为干预，也普适于所有产品，并且行业中对于大多数语言都有足够的工具可用。 但你必须要对它有所了解，因为它是一种间接和有损的指标，将大量信息压缩为一个数字（覆盖率的值）。它不应成为唯一的一个北极星指标。应该将其与其他技术结合使用，以对您的测试工作进行更全面的评估。

2. 一个开放性的研究题目就是：仅代码覆盖率是否会减少缺陷？我们的经验表明，增加代码覆盖率的努力通常会带来卓越工程文化，从长远来看会减少缺陷。例如，优先考虑代码覆盖范围的团队倾向于将测试视为头等公民，并且倾向于在产品设计中加入更强的可测试性，以便他们可以更轻松地实现测试目标。所有这些反过来导致开始编写更高质量的代码（它们的API中更具模块化，更简洁的合同，更易于管理的代码审查等）。他们还开始更加关心自己的整体健康状况，工程和运营卓越性。

3. 只是追求高的代码覆盖率百分比，并不能保证测试覆盖率的高质量。专注于使数字尽可能接近100％会导致错误的安全感。这也可能是浪费的，消耗了机器的运行时间，并从低价值的测试中产生了技术债，现在需要维护它们。由于缺少测试而导致错误代码被推到生产中的原因可能是因为（a）测试未涵盖特定的代码路径，易于通过代码覆盖率分析识别的测试空白，或者（b）因为测试未进行覆盖确实具有代码覆盖率的区域中的特定边缘情况，这很难或不可能用代码覆盖率分析来捕获。代码覆盖率不能保证所覆盖的行或分支已经正确测试，而只能保证它们已通过测试执行。请仅出于增加覆盖范围的目的而复制/粘贴测试，或添加实际价值很小的测试以符合数量。评估突变的方法是一种更好的技术，它可以评估您是否充分行使了测试所涵盖的范围，并充分断定了故障。

4. 可以肯定的是：较低的代码覆盖率即使自动化测试全部通过，也无法覆盖产品的大部分区域。这增加了将错误代码推送到生产环境的风险，因此应引起注意。实际上，代码覆盖率数据的更多价值并不是突出显示已经覆盖了多少内容，而是突出显示还有多少内容未被覆盖。

5. 没有一个“理想的代码覆盖率数字”可以普遍适用于所有产品。对于一组代码，您想要/需要的测试级别应该是（a）代码的业务影响/关键性；（b）您需要触碰/更改代码的频率；（c）您希望代码生存多久、其复杂性和域变量。我们不能要求每一个团队都有x%的代码覆盖率；这是一个最好由拥有特定领域知识的产品所有者做出的商业决策。任何要达到x%代码覆盖率的任务都应该伴随着基础设施的投资，以简化测试，比如将工具集成到开发人员的工作流程中。请注意，工程师可能会开始将您的目标视为一个复选框，并总是避免将覆盖范围提高到你定下的这个目标之上。所以，这样做比较谨慎。

6. 一般来说，很多产品的代码覆盖率都不高；我们应该致力于全面提高代码覆盖率。虽然没有“理想的代码覆盖率数字”，但在谷歌，我们提供的总体指导原则是60%为“可接受”，75%为“值得称赞”，90%为“模范”。然而，我们喜欢远离广泛的自上而下的授权，并鼓励每个团队选择符合其业务需求的价值。

7. 我们不应该着迷于如何将代码覆盖率从90％提高到95％。增加代码覆盖率超过特定点的收益是对数增长的。但是，我们应该采取具体的步骤将其从30％提高到70％，并始终确保新代码符合我们期望的阈值。

8. 比行覆盖百分比更重要的是，人工判断未涵盖的实际代码行（和行为）（分析测试的差距）以及这种风险是否可以接受。未涵盖的内容比涵盖的内容更有意义。在代码审查过程中对未涵盖的特定代码行进行务实的讨论，比对任意目标编号过度索引更有价值。我们发现，将代码覆盖率嵌入到您的代码审查过程中可以使代码审查更快，更轻松。并非所有代码都同样重要，例如，测试调试日志行通常并不那么重要，因此当开发人员不仅看到覆盖范围编号，而且还看到每个覆盖的行作为代码审查的一部分时，他们将确保最重要的代码 代码被覆盖。

9. 虽然你的产品现在具有较低的代码覆盖率，但并不意味着您不能采取具体的渐进步骤来逐步改进它。继承具有不良测试和不良可测试性的遗留系统可能会令人生畏，并且您可能没有能力去扭转它，甚至不知道从哪里开始。但是至少，您可以采用“童子军规则”（让露营地保持清洁）。随着时间的推移，您将逐渐到达健康的位置。

10. 确保覆盖经常被修改的那些代码。虽然超过90％的覆盖率目标很可能不值得，但每次提交的99％的覆盖率目标是合理的，而90％是一个较低的下限。我们需要确保我们的测试不会随着时间的推移而变差。

11. 单元测试代码的覆盖率计算仅仅是我们遇到的难题之一。集成/系统测试代码的覆盖范围也很重要。部署流水线中所有代码源的覆盖范围（包括单元测试和集成测试）的总体视图至关重要，因为它可以让您更全面地了解测试自动化未覆盖多少代码，因为它们能在部署流水线中自动运行，直到部署到 生产环境。您应该意识到的一件事是，虽然单元测试在执行的代码和评估的代码之间具有高度的相关性，但是集成测试和端到端测试中的某些覆盖是有偶然性的，而不是有意的。但是，将集成测试中的代码覆盖范围合并到一起，可以帮助你避免产生一种错误的安全感，即使你没有在单元测试中覆盖某一部分代码，但你仍错误地以为自己在集成测试中已经覆盖了它们。

12. 我们应该设置关卡，限制那些不符合我们代码覆盖标准的代码部署到生产环境。团队应该讨论并确定哪一种选通机制对他们有意义。不过，您应该小心，不要将其视为需要填写的复选框，因为它会适得其反（“达到指标”的压力几乎不会产生预期的结果）。有许多可用的机制：所有代码的覆盖率与仅新代码的覆盖率；特定硬编码代码覆盖率门上的闸门与以前版本中的增量闸门，要忽略或关注的代码的特定部分。然后，致力于以团队的形式坚持这些原则。违反门的代码覆盖率下降应防止代码被检入并进入生产。

（完）

作为一个有如些多工程师，写了如何多自动化测试用例，坚持写了十多年的公司，给出这份总结。你怎么看？欢迎留言讨论～