高测试覆盖率的问题

测试覆盖率的含义

测试成本

风险层面

利益相关者层面

务实之道

上周我参加了 Dan North 的“更快测试”研讨会。Dan North 是“行为驱动开发”（BDD）这一术语的创始人。整个研讨会非常精彩，但有一件事让我非常惊讶。由于 BDD 本质上是测试驱动开发（TDD）的另一种形式，我原本以为 Dan 编写软件时的目标之一就是拥有高测试覆盖率。但我了解到，他实际上并不关心整体测试覆盖率。他对此的解释非常令人信服。在这篇文章中，我记录了我对测试覆盖率的了解。

测试覆盖率的含义

测试覆盖率（也称为代码覆盖率）是一个数字，它告诉你有多少生产代码被自动化测试覆盖。如果你没有任何自动化测试，那么测试覆盖率就是 0%。如果你的每一行生产代码都至少被一个自动化测试执行，那么覆盖率就是 100%。高覆盖率可能感觉很棒，但即使 100% 也不意味着你的代码中没有 bug。它只能告诉你，你编写的测试用例是否按预期工作。

测试成本

自动化测试可以帮你省下不少钱！它们可以在部署到生产系统之前检测出错误，从而避免重大损失。它们还能帮助你设计代码，使其易于维护和未来扩展。但编写测试并非免费。它需要时间，而这些时间也可以用来做其他事情。Dan 称之为机会成本。别误会我的意思。我并不是说测试是个坏主意。测试本身就很好。事实上，测试可能非常重要。但我想鼓励你思考一下，哪些测试有意义，哪些测试没有意义。

风险层面

那么我们如何决定测试什么呢？想象一个如下所示的软件系统：

组件众多，它们之间又存在依赖关系。现在，让我们在图表中添加一个坐标系。组件越靠近图表右侧，其发生故障的可能性就越大。某个组件故障的影响越大，我们在纵轴上绘制的坐标就越高。让我们看一下风险平面：

现在假设我们系统的测试覆盖率是 80%。听起来是个不错的数字。但请看一下右上角的组件。该组件很可能出现故障，而且故障的影响会非常大。考虑到这一点，80% 对于该部件来说实际上相当低。另一方面：左下角的组件不太可能出现故障。即使出现故障，影响也很小。那么，为了保持高测试覆盖率，花费这么多时间测试这个组件真的有意义吗？把时间花在为右上角的组件编写测试甚至构建新功能上不是更有用吗？我们花在编码上的每一小时都意味着公司投入的金钱。作为软件开发人员，我们有责任合理地决定如何使用这些资金。

利益相关者层面

Dan North 说：“测试的目标是通过证据增强利益相关者的信心”。我们的测试可以提供证据。增加并不一定意味着要达到 100%。需要一些实用主义来决定在什么情况下需要投入多少精力。我们为谁做这件事？是利益相关者！仅仅告诉他们我们是优秀的开发人员，一切都会好起来是不够的。我们应该给他们证据。他们应该知道哪些行为是由测试保证的。开发人员往往有一个盲点。大多数开发人员认为他们的代码很棒并且可以正常工作。但利益相关者通常对开发人员没有那么大的信心，这就是他们需要证据的原因。

通常，利益相关者有很多种。他们可能是用户、安全部门人员、客服人员等等。我们可以开发出不太可能出错的软件，但如果它是非法的，我们仍然无法发布。这就是为什么我们必须用另一个轴来扩展我们的模型。我们必须为利益相关者添加平面：

通常，利益相关者会从不同的角度看待软件。有时，你甚至想不到的方面对他们来说却至关重要。例如，某些用户角色必须禁止访问某些数据，这一点至关重要。这需要更大的测试工作量。与各种利益相关者沟通非常有帮助。问问他们，你应该集中精力的最重要的事情是什么。他们会在哪个部分投入最多的精力。如果你对每个利益相关者都这样做，你就能清楚地知道应该在风险平面的哪个位置绘制组件，以及应该在哪个组件上投入多少测试工作量。

务实之道

Dan North 向我明确指出，测试覆盖率并不能充分反映软件的质量。80% 对于某个组件来说可能太低，而对于另一个组件来说则可能是浪费时间。编写代码时，我们首先应该了解利益相关者。什么才是真正重要的？我们应该评估潜在 bug 的影响和可能性，并务实地决定在哪个组件上投入多少精力。我们必须牢记，我们付出的劳动是值得的。我们花在编码上的每一个小时都是金钱的。作为专业的软件开发人员，我们有责任明智地使用这笔钱。

本文最初发表于team-coder.com。