多少测试覆盖度才算足够

每个软件开发人员和团队都在努力解决的一个熟悉的问题是，“多少测试足以使软件版本合格？” 很大程度上取决于软件的类型、用途和目标受众。人们会期望一种比简单的智能手机手电筒应用程序更严格的测试商业搜索引擎的方法。然而，无论是什么应用，多少测试才足够的问题很难用明确的术语来回答。更好的方法是提供可用于定义最适合手头案例的认证过程和测试策略的考虑因素或经验法则。以下提示提供了一个有用的标准：

• 记录您的流程或策略。
• 有坚实的单元测试基础。
• 不要吝啬集成测试。
• 对关键用户旅程执行端到端测试。
• 了解并实施其他测试层级。
• 了解您的代码和功能覆盖范围。
• 使用来自现场的反馈来改进您的流程。

记录您的流程或策略

如果您已经在测试您的产品，请记录整个过程。这对于能够为以后的版本重复测试并对其进行分析以进行进一步改进至关重要。如果这是您的第一个版本，最好有一个书面的测试计划或策略。事实上，任何产品设计都应该有书面的测试计划或策略。

有坚实的单元测试基础

一个很好的起点是编写伴随代码的单元测试。单元测试测试在功能单元级别编写的代码。对外部服务的依赖要么被模拟，要么被伪造。

模拟具有与生产依赖项相同的接口，但仅检查对象是否根据设定的期望使用和/或返回测试控制的值，而不是其正常功能的完整实现。

另一方面，a *fake是依赖项的浅层实现，但理想情况下应该没有它自己的依赖项。*Fakes 提供了比模拟更广泛的功能，并且应该由提供依赖项的生产版本的团队维护。这样，随着依赖项的发展，伪造者和单元测试编写者可以确信伪造品反映了生产依赖项的功能。

在包括 Google 在内的许多公司中，都有要求任何代码更改以使相应的单元测试用例通过的最佳实践。随着代码库的扩展，在提交代码之前执行大量此类测试是在错误潜入代码库之前捕获错误的重要部分。这可以节省以后编写集成测试、调试和验证对现有代码的修复的时间。

不要吝啬集成测试

随着代码库的增长并达到可以作为一个组进行测试的功能单元数量的地步，是时候建立一个坚实的集成测试基础了。集成测试需要一小部分单元，通常只有两个单元，并作为一个整体测试它们的行为，验证它们是否可以连贯地协同工作。

开发人员通常认为集成测试可以被取消优先级甚至跳过，以支持完整的端到端测试。毕竟，后者真正测试了用户会使用它的产品。然而，拥有一套全面的集成测试与拥有坚实的单元测试基础同样重要（请参阅早期的 Google 博客文章，修复测试沙漏）。

原因在于集成测试比完整的端到端测试具有更少的依赖性。因此，具有较小环境的集成测试将比具有全套依赖关系的完整端到端测试更快、更可靠（请参阅早期的 Google 博客文章，Test Fakiness - One of the Main自动化测试的挑战）。

对关键用户旅程执行端到端测试

到目前为止的讨论涵盖了在其组件级别测试产品，首先作为单个组件（单元测试），然后作为组件和依赖项组（集成测试）。现在是时候像用户使用它一样端到端地测试产品了。这非常重要，因为不仅要测试独立的功能，还要测试包含各种功能的整个工作流程。在谷歌，这些工作流程——关键目标和用户为实现该目标而执行的任务旅程的组合——被称为关键用户旅程 (CUJ)。了解 CUJ，记录它们，然后使用端到端测试（希望以自动化方式）验证它们完成了测试金字塔。

了解并实施其他测试层

单元、集成和端到端测试解决了产品的功能级别。了解其他测试层级很重要，包括：

• 性能测试 - 测量应用程序或服务的延迟或吞吐量。
• 负载和可扩展性测试 - 在越来越高的负载下测试您的应用程序或服务。
• 容错测试 - 测试您的应用程序的行为，因为不同的依赖关系要么失败，要么完全崩溃。
• 安全测试 - 测试您的服务或应用程序中的已知漏洞。
• 可访问性测试 - 确保每个人都可以访问和使用该产品，包括各种残障人士。
• 本地化测试 - 确保产品可以在特定语言或地区使用。
• 全球化测试——确保产品可以被世界各地的人们使用。
• 隐私测试 - 评估和减轻产品中的隐私风险。
• 可用性测试 - 测试用户友好性。

同样，重要的是要在您的审查周期中尽早进行这些测试过程。较小的性能测试可以更早地检测到回归并在端到端测试期间节省调试时间。

了解您的代码和功能覆盖范围

到目前为止，已经从定性的角度研究了多少测试就足够的问题。对不同类型的测试进行了审查，并提出较小和较早的论点比较大或较晚更好。现在将从定量的角度研究这个问题，同时考虑代码覆盖技术。

Wikipedia 有一篇关于代码覆盖率的精彩文章，概述并讨论了不同类型的覆盖率，包括语句、边缘、分支和条件覆盖率。有几种开源工具可用于测量大多数流行编程语言（如 Java、C++、Go 和 Python）的覆盖率。下表包含部分列表：

Language	Tool
Java	JaCoCo
Java	JCov
Java	OpenClover
Python	Coverage.py
C++	Bullseye
Go	Built in coverage support (go -cover)

表 1 - 不同语言的开源覆盖工具

这些工具中的大多数都以百分比形式提供摘要。例如，80% 的代码覆盖率意味着大约80% 的代码被覆盖，大约20% 的代码未被覆盖。同时，重要的是要理解，仅仅因为你覆盖了特定的代码区域，这段代码仍然可能有错误。

覆盖的另一个概念称为变更列表覆盖。更改列表覆盖率测量更改或添加的行中的覆盖率。对于积累了技术债务并且在整个代码库中覆盖率低的团队来说，它很有用。这些团队可以制定一项政策，增加他们的增量覆盖范围将导致整体改进。

到目前为止，覆盖讨论集中在测试（函数、行等）对代码的覆盖。另一种类型的覆盖是特征覆盖或行为覆盖。对于功能覆盖，重点是识别特定版本中已提交的功能并为其实现创建测试。对于行为覆盖，重点是识别 CUJ 并创建适当的测试来跟踪它们。同样，了解您“未发现”的特征和行为可能是您了解风险的有用指标。

使用现场反馈来改进您的流程

了解和改进您的资格认证过程的一个非常重要的部分是软件发布后从现场收到的反馈。拥有一个跟踪中断、错误和其他问题的流程，以改进资格的行动项目的形式，对于最大限度地减少后续版本中的回归风险至关重要。此外，行动项目应该（1）强调在资格认证过程中尽早填补测试空白，（2）解决战略问题，例如缺乏特定类型的测试，例如负载或容错测试. 同样，这就是为什么记录您的资格认证过程很重要，以便您可以根据从现场获得的数据重新评估它。

概括

创建全面的资格认证流程和测试策略来回答“多少测试才足够？”这个问题。可能是一项复杂的任务。希望这里给出的提示可以帮助您。总之：

• 记录您的流程或策略。
• 有坚实的单元测试基础。
• 不要吝啬集成测试。
• 对关键用户旅程执行端到端测试。
• 了解并实施其他测试层级。
• 了解您的代码和功能覆盖范围。
• 使用来自现场的反馈来改进您的流程。

原文链接：https://testing.googleblog.com/2021/06/how-much-testing-is-enough.html?m=1