测试覆盖率强迫症

我曾经服务于这样的客户，开发团队由于需求不明晰，验收条件缺乏，导致返工严重；知识分享的缺乏，导致人员间不能相互替换，工作无法合理分配，进度缓慢；架构划分的不合理，又没有频繁的在各团队间进行集成，导致发布难度大，周期长。内忧外患下，团队领导人却仅对于测试覆盖率表现出异乎寻常的热情，与之形成鲜明对比的是对于其它的问题冷漠和麻木。人们似乎很容易犯这样的错误，由于不确定应该做什么，或者不知道如何去做最重要的事情，最终将注意力放在了易于提升的次等重要的事情上。

很多团队的领袖不遗余力地提升测试覆盖率，以至于患上了“测试覆盖率大于 90 强迫症”，89.99% 的测试覆盖率也会让他们寝食难安，并发明了自动化测试覆盖率检查工具 (当测试覆盖率达不到 90%，测试便会失败) 来减轻自己的症状。在我看来，这一强迫症的病因在于对项目控制的力不从心引发的压力无法排除，加强对于测试覆盖率 (或者项目其它生命体征) 的要求从技术决策变成了心理上的减压渠道。面对可能的项目失败，他蛮可以说：“技术职位上我尽了最大的努力，看看测试覆盖率！项目的失败应归罪于愚蠢的合同 (销售)，不清晰的需求 (业务分析师)，又或者是不切实际的进度安排 (项目管理者)。”

抛开管理因素不谈， 从技术上讲，高测试覆盖率和高质量的软件能够被等同起来么？看看下面的例子：

 
public class Calculator {
  public static Decimal Divide(Decimal operand1, Decimal operand2) {
     operand1.Divide(operand2)
  }
}
 
[Test]
public void two_divide_one_should_return_two() {
  Assert.AreEqual(2, Calculator.Divid(2, 1));
}

NCover 会告诉我们测试已经完全覆盖了功能 (测试覆盖率 100%)。可事实果真如此么？现有的测试至少不能回答系统在如下情况下对于“除法”这个功能的期待是什么？

• 除数为 Null
• 被除数为 Null
• 被除数为 0

测试覆盖率仅仅能够告诉团队什么没有被测试，根本就回答不了软件是否经过了有效测试！

舌苔厚重反映的是消化问题，治疗方案当然不是刷刷舌头这么简单，同样，测试覆盖率低的病灶常常是：

• 团队成员没有写测试的习惯，没有意识到写测试的重要性，不想写
• 代码难于测试，不会写
• 赶进度，没有时间写

相对于提升测试覆盖率，这些问题解决起来就要复杂的多，也棘手的多。我不确定特定环境上述问题的解决问题是什么，但是我很确定补测试不是良方，它往往会催生出没有 Assert 的畸形测试以及大量针对 getter/setter 的无用测试。

检查覆盖率得到好的结果可以增强团队信心，巩固测试实践；而得到坏的结果则需要综合分析，找到原因，制定改进方案。这是团队积累经验，提升能力的一种有效途径，单纯要求提高覆盖率则是头疼医头，脚疼医脚的可笑方法。测试不是为了代码需要被测试的需求而存在，它存在的原因是市场需要以低成本生产高质量软件。补测试无法满足测试实践的内在需求。在我看来，利用覆盖率的分析结果在团队中引发一个话题，讨论系统模型的可测试性、设计的合理性，并藉此改善产品才是更加可取的做法，单纯追求覆盖率常常反映出团队将流程和目标混淆起来，甚至误将流程当作了目标。

如果不再要求所有的组件必须被覆盖，我们就必须回答一个新的问题：“哪些组件应该被覆盖？ 多少覆盖率比较合适？”。以我的经验，在考虑测试策略时至少需要参考业务价值，功能变化趋势以及缺陷率这三个因素：业务价值是核心，讨论清楚业务流程和价值，优先针对高业务价值的功能分析和设计测试。其次是根据组件的变化趋势有重点的投资测试。系统中一定存在常常变化的组件，对于这些组件多投入一些测试有助于减少破坏已完成功能的风险，并进而提高团队的信心。Bug 则是另一个风向标，向我们指明系统的哪些部分比较薄弱。对 Bug 进行一下分类整理，我们就能很容易的发现系统的这些薄弱区域；在这些区域添加测试、修补有缺陷的功能，将有助于提高产品的质量。

去解决数据掩盖之下的问题难度更大也更令人恐惧，没人清楚我们可以走多远，但重要的是我们已经出发。恐惧和无所适从是因为我们所面对的新领域再没有绝对的对错，再没有容易做出的决策，我们需要更多经验，承担更多的风险，它迫使我们驶出了心理舒适区，开始在心理学习区锻炼自我，挑战自我，只有这样数据强迫症才会被清除治愈。

关于作者

胡凯， ThoughtWorks 公司的敏捷咨询师，官方认证的 Spring Framework 讲师，近 2 年一直从事持续集成工具 Cruise 以 及 CruiseControl 的设计开发工作。 创造和参与了开源测试框架 junit-ext ，网格测试工具 test-load-balancer 以及用于分析 CruiseControl 构建的报表工具 iAnalyse , 对于 Web 开发，敏捷实践，开源软件与社区活动有浓厚的兴趣，可以访问他的个人博客进行更多的了解。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。