测试覆盖率

名称	分母	分子	示例
手工测试覆盖率	所有测试用例	手工测试执行的用例	A系统目前3个测试工程师参与了4个月，写了近300条测试用例，那目前的300条就作为整个测试覆盖率的分母
接口覆盖率	接口总数	测试涉及的接口总数	系统有10个接口，对其中8个做了接口自动化测试，那么覆盖率就是80%
自动化测试覆盖率	测试用例总数	自动化测试涉及的测试用例总数	系统有100条测试用例，其中有60条用例已经被自动化脚本化测试，那么覆盖率是60%
测试用例覆盖率	测试功能点总数	自动化测试涉及的测试功能点	系统有100条测试用例，400个测试功能点（checkpoint），其中200个Checkpoint已经被自动化测试脚本测试，那么覆盖率是50%
需求覆盖率	所有用户故事或任务	已被测试的用户故事或任务	目的：测试的行为覆盖了每一个需求
缺陷覆盖率	已被发现并修复的缺陷数量	对缺陷进行自动化测试的数量	A系统上线前共发现了70个缺陷，测试工程师将这70个“已经被修复”的缺陷写成了自动化测试用例
代码行覆盖率	代码总行数	被执行过的代码行数	一个Java应用有10W行代码，执行了一次手工回归测试，同时也触发了自动化测试脚本，然后利用Jacoco组件查看看测试覆盖率，发现10W行代码中，有3W行代码已经被覆盖了，那么代码行覆盖率就是30%
代码分支覆盖率	代码总分支数	被执行过的代码分支数	本质上与代码行覆盖率一样，只是统计的维度不一样

 

自动化测试覆盖率的案例分享

思路：剔除无意义的套路代码，结合不同的覆盖率指标，综合得出一个相对有价值的覆盖率数据。

做法：

1，搭建测试覆盖率环境

Java使用的是Jacoco组件，其他编程语言可以使用其他覆盖率统计组件

2，执行自动化测试脚本

触发自动化测试脚本执行，等待执行完毕。

 

 

上图说明：

• 绿色区域：代码行覆盖率充分，100%覆盖了该代码。
• 黄色区域：代码行覆盖不充分。

• 红色区域：代码行未经过覆盖。
• 绿色钻石：代码分支覆盖率充分，100%覆盖了该代码分支。

• 黄色钻石：代码分支覆盖率不充分。
• 红色钻石：代码分支未经过覆盖。

请注意，此时请勿打开测试环境的系统页面、接口调用等操作，保证数据的真实性。

 

 

3，筛选掉无意义的套路代码

以SpringBoot框架为例，如bean、model、entity、util、mapper、dao、constant、config等目录，大部分都是套路的代码统统过滤掉。

留下有业务意义的代码目录：controller、service目录和自己封装的业务函数类，服务端代码的业务逻辑运算、接口的代码逻辑都在这里，这才是代码的核心部分。

自动化脚本执行完成后，Jacoco测试覆盖率从0%变成了多少，那么目前的自动化测试脚本覆盖率就是多少。

 

重点：

代码覆盖率本身具有局限性，因为100%的代码覆盖率并不能说明系统质量没有问题。所以除了关注已被测试行为覆盖的代码，更重要的是观察未被覆盖的代码，因为这部分是没有测试用例覆盖到的，让测试工程师自己发现思维的不足、遗漏的用例，这才更有价值。