业务覆盖率度量——阿里测试之道(14)

发表于:2022-5-05 09:28

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:阿里巴巴技术质量小组    来源:51Testing软件测试网原创

  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。

查看《阿里测试之道》全部连载章节
版权声明:51Testing软件测试网获得作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号