理解测试指标

现在我们理解了如何通过先编写测试来交付项目，接下来我们将看一些可以量化项目测试效果的指标。交付覆盖整个测试金字塔的测试非常重要，因为确保应用程序端到端正确运行，并且能够与外部依赖项良好协作同样至关重要。

重要的测试指标

在量化软件质量时，有一系列的指标可以衡量：

需求覆盖率：表示项目需求中有多少百分比是通过测试覆盖的。一个测试可能覆盖多个需求，但没有客户需求应该是未经测试的。
缺陷数量和分布：表示在应用程序的每个模块或部分中发现了多少缺陷或错误。缺陷的分布也能指出系统中是否有特定的高风险区域，可能需要重构。
缺陷解决时间：表示开发团队在发现缺陷后修复问题的速度。较长的平均修复时间（MTTR）可能表明开发团队人员不足，而某个特定区域的最大解决时间过长则可能表明该部分的代码难以修改。
代码覆盖率：表示单元测试执行的代码库百分比。由于测试应该先编写，覆盖率还显示了开发团队是否在使用 TDD。较低的测试覆盖率也可能表明系统设计上存在问题。
燃尽率和燃尽图：表示团队交付功能的速度。由于开发和测试是统一的任务，用户故事或需求只有经过测试后才能认为完成，因此燃尽率只会包括已准备交付的故事。燃尽图可以反映项目时间表中的延迟情况。

由于代码覆盖率是 TDD 的重要指标，我们来进一步探讨它。为了达到较高的覆盖率百分比，测试应覆盖以下内容：

Go 测试运行器为 Go 应用程序提供了覆盖率百分比。我们将在第 2 章《单元测试基础》中进一步讨论如何实现这一点。

图1.11 展示了简单终端计算器中 Divide(x, y) 函数的实现流程图：

Figure 1. Figure 1.11 – Execution flow of the Divide function in the simple calculator

测试应编写以覆盖和验证以下内容：

在大型项目中，达到 100% 的测试覆盖率是不可行的。在技术社区中，关于一个良好的测试覆盖率百分比有许多讨论。通常认为，良好的覆盖率大约是 80%。超过这个比例后，经验表明，收益递减。

代码覆盖率百分比还会依赖于你正在运行的项目类型。对于一个遗留代码库，低代码覆盖率的项目将需要大量努力才能达到 80% 的标准。同样，对于一个绿色领域的项目，如果有许多未知因素，也会很难进行全面测试。

像编写任何代码一样，测试代码也需要维护和重构。保持高覆盖率需要维护和更新大量的测试代码。这可能会增加重构或其他代码变更的开发成本，因为它可能需要更新许多测试用例。那些不涵盖需求的测试代码，其商业价值非常低，因此你应该确保你的测试为测试套件提供了价值。

良好的测试代码并不意味着没有缺陷的代码

你的测试应该旨在验证重要的代码行为，而不是仅仅为了达到某个代码覆盖率百分比而编写测试。团队应该拥抱 TDD 的测试文化，良好的覆盖率百分比自然会随之而来。