Google代码覆盖率最佳实践

软件质量保障: 所寫即所思｜一个阿里质量人对测试的所感所悟。

谷歌一直倡导的领域之一是使用代码覆盖率数据评估风险并识别测试中的真空。然而，代码覆盖率的价值一直是个争议的话题。每次聊到代码覆盖率时，似乎都会引发无尽的争论。由于大家固守自己阵营，所以每次争论都无疾而终。本文引导大家找到共同点，以便能够切实地使用覆盖率信息。我们提出了代码覆盖率的最佳实践，以有效地处理代码健康问题。

代码覆盖率有益于改进研发流程

它虽不是测试质量的完美度量，但它提供了一个合理、客观、行业标准的指标，并提供可操作的数据。它不需要大量的人为干预，适用于所有产品，并且行业中有大量的工具可用于大多数语言。你必须把它视为一种间接的度量，由于它将大量的信息压缩成一个数字，因此不能把它当做唯一度量指标。相反，应该与其他技术一起使用，以创建更全面的测试评估。

使用代码覆盖率会减少缺陷?

关于仅使用代码覆盖率是否会减少缺陷，这是一个开放性问题，但我们的经验表明，增加代码覆盖率的努力通常会导致工程卓越文化的变化，从长远来看，会减少缺陷。例如，注重代码覆盖率的团队倾向于将测试优先，倾向于在产品设计中嵌入可测试性代码，以便更少的工作量实现测试目标。这反过来又导致更高质量的代码编写（更模块化、更干净的 API 契约、更易于管理的代码审查等）。

高代码覆盖率并不保证测试覆盖的高质量

把注意力放在尽可能让这个数字接近100%，会导致一种虚假的安全感。这也可能是浪费机器运算能力，并且在低价值的测试中创建技术债。由于缺少测试而将糟糕的代码推向生产环境可能发生的原因是，要么是因为（a）你的测试没有覆盖到某个代码路径，这是一种很容易通过代码覆盖率分析来识别的测试间隙；要么是因为（b）你的测试没有覆盖到某个区域的特定边界情况，尽管该边界已经有了代码覆盖，但这种情况很难或不可能通过代码覆盖率分析来捕捉。代码覆盖率并不能保证覆盖到的行或分支被正确地测试了，它只保证这些行或分支已被测试执行过。要谨慎考虑只是为了增加覆盖率而复制/粘贴测试，或者添加实际价值很小的测试来达到数字要求。评估你是否足够地执行了测试覆盖到的代码行，并且是否对失败进行了充分的断言，更好的技术是突变测试。

低的代码覆盖率没有通过充分自动化测试

这增加了我们将糟糕的代码推向生产环境的风险，因此应该引起注意。事实上，代码覆盖率数据的很多价值在于突出显示未覆盖的内容，而不是已经覆盖的内容。

并不存在适用于所有产品的“理想代码覆盖率值”

对一组代码所需要的测试程度应该是以下三个因素共同决定的函数：(a) 代码的业务影响/重要性；(b) 需要多频繁地接触/更改代码；(c) 代码预计的寿命，其复杂性和领域模型。我们不能要求每个团队都必须有x%的代码覆盖率；这是一个最好由产品所有者以领域特定的知识做出的业务决策。任何x%代码覆盖率的要求都应该伴随着基础设施投资，以使测试变得容易，例如将工具集成到开发人员工作流程中。

集成测试覆盖率也很重要

单元测试覆盖率只是解决问题的一部分。集成测试覆盖率也很重要。在你的pipelines（包括单元测试和集成测试）中覆盖所有源代码的情况至关重要，因为这可以提供一个更大的视角，让你了解测试自动化漏测了多少代码，而这些代码可能会在生产环境中出现问题。需要注意的一点是，虽然单元测试执行的代码与被评估的代码之间有很高的相关性，端到端测试的覆盖率则是偶然的。但集成测试的代码覆盖率可以帮助你避免这样的情况。

应该对未达到代码覆盖率标准的部署进行Block

我们应该对未达到代码覆盖率标准的部署进行Block。大家应该讨论哪种block机制更有效。例如：对所有代码的覆盖率进行block，还是仅对增量代码的覆盖率进行block；以特定的硬编码代码覆盖率进行block，还是以与之前版本的差异为基础进行block，只关注特定部分的代码。然后，团队应对覆盖率标准达成共识。当代码覆盖率下降时则违反了这一标准，应该阻止代码提交和部署生产环境。

– END –

---

关注 软件质量保障，与质量君一起学习成长、共同进步，做一个职场最贵Tester！