BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

测试覆盖率强迫症

| 作者 胡凯 关注 1 他的粉丝 发布于 2010年7月3日. 估计阅读时间: 6 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

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

很多团队的领袖不遗余力地提升测试覆盖率,以至于患上了“测试覆盖率大于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中文站用户讨论组中与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

其实这是无可奈何的折中方案 by Huang Joe

测试覆盖率是一个"量化" 的指标,当复杂度把人(所有的项目参与者)打败的时候,就只能依靠这些所谓量化的指标,也就很难避免这些“畸形”的行为。

头痛医头只不过是缓解压力的自欺欺人的花招而已。 by Tseng Joseph

看到“他蛮可以说:...”这段,用温伯格的系统方法分析一下,头痛医头只不过是短暂缓解压力的自欺欺人的花招而已,压力会像飞去来器一样在远方盘旋一次,再次飞回来击中大家的脑袋。 这时候大家的缓解压力的办法可能会成为“这个(敏捷)方法论是个狗屎。”

Re: 头痛医头只不过是缓解压力的自欺欺人的花招而已。 by 胡 凯

可惜大多数的团队都没有直面问题的勇气,不敢提意见,不能实施有效的沟通,这样的团队实施敏捷只是空谈。

Re: 头痛医头只不过是缓解压力的自欺欺人的花招而已。 by victor cai

要提高测试覆盖率,必须提高测试用例的覆盖率,单单只是通过哪些地方测了,哪些地方没有测试,这个不是正确的覆盖率统计方法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

4 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT