1.7.2业务覆盖率度量
如果测试可以覆盖100%的代码(包括行覆盖、分支覆盖、条件覆盖等),是不是就测全了,不会遗漏曲线了?答案显然是“不”。以下面的代码为例:
public string Format(int month, int year)
{
return string.Format("{0}/{1}", month, year);
}
这段代码要做的事情是把月和年转化为信用卡的过期时间字符串(例如,06/2020)。信用卡过期日的格式是MM/YYYY,但对于2020年6月,这段代码返回的是错误的6/2020。正确的写法应该是string.Format("{0:00}/{1:0000}",month,year)。设计这段代码的测试用例时,如果只测了某些业务场景(例如11/2020),就无法发现这个Bug。
因此,我们除了度量测试的代码覆盖率,还必须关注业务场景的覆盖率。业务场景覆盖率的定义和业务形态相关度很大。信用卡过期时间转换的例子比较简单,在实际工作中有各种String类型或者复杂数据类型的参数,其取值和值的变化代表了业务对象的状态、状态的转移路径、事件序列、配置项的可能取值和取值组合、错误码和返回码等,有强业务语义并代表了不同的业务场景,需要从业务场景覆盖率角度去度量和覆盖。
1.8从测到不测
前面已经讲了如何把测试做得更好,但我们也认识到,做测试不能只把测试做好。
《黄帝内经》一书提出:“上工治未病,不治已病,此之谓也。”《孙子兵法》一书说:“是故百战百胜,非善之善者也;不战而屈人之兵,善之善者也。故上兵伐谋,其次伐交,其次伐兵,其下攻城。攻城之法,为不得已。”做医生的最高境界是不需要治病。打仗的最高境界是不需要打仗。同样的道理,做测试也要思考如何做到不需要测试,只有这样才能变被动为主动,不再跟在项目和需求的后面疲于奔命,像打地鼠一样面对层出不穷的问题。
从测到不测的方法有很多,主要包括下面两类。
防错设计:在架构、代码、交互等层面优化和加固设计,减少人为错误发生的可能性,或者降低人为错误可能导致的影响。
代码扫描:不写任何测试用例、不执行任何测试,直接对代码进行分析,找到代码中的问题,甚至自动修复Bug。