代码覆盖率最佳实践
引言
测试覆盖率是衡量软件测试完整性的一个重要指标。掌握测试覆盖率数据,有利于客观认识软件质量,正确了解测试状态,有效改进测试工作。那么如何度量测试覆盖率呢,最常用的手段是统计代码的覆盖率,如何定义代码覆盖率,它又是如何统计的呢?业界对于代码覆盖率的看法也有不少争议,我们如何正确看待这个问题,并找到各种观点中的共同点,从而有效获取覆盖率数据,进而提高代码健康度呢?今天就让我们来聊一聊。
一、什么是代码覆盖率?
代码覆盖(Code coverage)是软件测试中的一种度量,描述源代码被测试的比例和程度,所得比例称为代码覆盖率。代码覆盖率是对整个测试过程中被执行的代码的衡量。在单元测试中,代码覆盖率常常被拿来作为衡量测试好坏的指标。
二、代码覆盖率的指标种类
代码覆盖率工具通常使用一个或多个标准来确定你的代码在被自动化测试后是否得到了执行,常见的覆盖率报告中看到的指标包括:
语句覆盖:又称行覆盖,是最常见的覆盖方式,度量被测代码中可执行语句有多少被执行到了。选择不同的测试数据,使被测程序中每条语句至少被执行一次。语句覆盖是很弱的逻辑覆盖,它只管覆盖代码中的执行语句,不考虑各种分支的组合。
分支覆盖:又称判定覆盖,它度量程序中每一个判定的分支是否都被测试到了。设计足够多的测试用例 ,使程序中每一个取真分支和取假分支至少执行到一次。
条件覆盖:它度量判定中的每个子表达式结果真值和假值是否都被测试到了。条件覆盖与判定覆盖非常容易混淆,条件覆盖不是将判定中的每个条件表达式的结果进行排列组合,而是只要每个条件表达式的结果 true 和 false 测试到了就可以了。因此,完全的条件覆盖并不能保证完全的判定覆盖。
路径覆盖:又称断言覆盖,它度量了是否函数的每一个分支都被执行了。就是所有可能的分支都执行一遍,有多个分支嵌套时,需要对多个分支进行排列组合,路径覆盖被很多人认为是“最强的覆盖”。
此外,还有函数覆盖率、条件判定组合覆盖等指标。
三、主流的代码覆盖率工具
代码覆盖率的工具有很多,以下是不同编程语言的代码覆盖率工具。在选择工具时,力求去选择那些开源、活跃、好用的工具。
四、代码覆盖率最佳实践
统计代码覆盖率可以检测出程序中哪些代码未被执行到,但高百分比并不等于高质量的有效测试。所以在覆盖率问题上常常会有很多完全不同的看法。我们应该求同存异,正确看待该问题,以此来帮助有效地开发出高质量的代码。下面是我们总结借鉴的行业中的一些最佳实践。
代码覆盖率提供了一个客观、可操作的标准,但不是一个针对测试质量的完美度量指标。他的度量不需要人工,有相当多的覆盖率工具支持大多数编程的语言,可以支持代码覆盖率的度量。但代码覆盖率不应该是唯一的度量指标。我们应该结合其他技术,对测试工作进行更全面的评估。
工程师应该努力提高代码覆盖率,形成一种追求卓越的工程文化 。追求代码覆盖率从长远来看,能够减少产品缺陷。也会引导团队开发出更高质量的代码,更具模块化,更干净的 API 规范,更容易管理的代码评审流程等等。
代码覆盖率低肯定说明产品的大部分代码没有经过充分的自动化测试。因此每次部署前统计覆盖率,帮助我们发现哪些代码还没有被覆盖到,比代码行覆盖率的百分比更重要的是,对未被覆盖的代码行(和行为)进行分析,判断质量风险是否可以接受。另外针对代码覆盖率低的系统,应该采取具体的措施来循序渐进地改善它。
不必痴迷于让代码覆盖率一定要达到 100%,高水平的代码覆盖率并不能保证高质量的测试覆盖率。代码覆盖率不能保证所覆盖的代码行或分支都已经被充分测试,它只是保证了测试已经覆盖到这部分代码,不必为了达到某个数字而增加没有实际价值的测试。但可以探索其他的技术,如变异测试。
代码覆盖率的要求依业务情况而定。对于业务重要性高,影响性大的核心代码,要求更高的代码覆盖率。一般来说,很多产品的代码覆盖率会低于标准,我们应该致力于提高代码覆盖率。虽然没有一个 "理想的代码覆盖率"目标值,可以可以参考行业中的优秀企业,如谷歌,提供的一般准则是 60%为 "可接受",75%为 "值得赞扬"。另外一个较好的实践是,确保经常变更的代码的代码覆盖率是 100%。
单元测试的代码覆盖率只是拼图的一部分,集成/系统测试的代码覆盖率也很重要。
本期内容就到这里了,如果喜欢就点个关注吧,微信公众号搜索“数 新 网 络 科 技 号”可查看更多精彩内容~
版权声明: 本文为 InfoQ 作者【数新网络官方账号】的原创文章。
原文链接:【http://xie.infoq.cn/article/88f42321c1c86a7cb28cc58a2】。文章转载请联系作者。
评论