前言
在团队中，像面向底层的测试工作，像服务端测试这块，对交付的结果质量没有一个比较好的规范化的衡量标准。在了解开发团队的交付结果衡量方式后，发现代码覆盖率统计可以作为接口测试工作的衡量标准，通过统计结果映射出接口测试的覆盖度。这里总结下代码覆盖率的内容。
什么是代码覆盖率
代码覆盖率就是测试过程中已经被执行过的代码占准备测试总代码量的比例和程度，它关注的是在执行用例时，有哪些代码被执行到了，有哪些代码没有被执行到。
代码覆盖率统计的价值
- 发现未测试代码。可以帮助识别出哪些部分的代码没有被测试用例覆盖。
- 评估测试完整性。可以帮助测试人员确定是否需要增加新的测试用例来覆盖未被覆盖的代码区域。
- 利于精准回归。通过构建代码调用关系，精准的确定回归测试范围，避免了全量回归造成的测试资源浪费。
代码覆盖率统计的实现
-
一般被测服务是java技术栈居多，可以使用jacoco工具实现代码覆盖率统计。
-
前置条件：必须有稳定的接口自动化脚本，被测服务没什么缺陷，差不多达到测试通过的指标
-
实现步骤
step1：部署统计工具在被测服务所在服务器上
step2：启动统计工具和服务
step3：执行测试脚本
step4：获取统计结果
step5：分析结果是否达到阈值
step6：未到阈值需要开发对齐未覆盖到的场景，分析是否存在冗余的代码或者是否存在未覆盖到的场景，如果是冗余代码需要优化代码，如果是场景未覆盖到需要增加相关的测试用例，完善完再重新统计。
step7：达到阈值后，将代码覆盖率的统计结果整合在测试报告上
如何确定代码覆盖率
- 我们刚开始落地代码覆盖率统计时，拿一个项目来实践，根据规范化的测试策略和测试方法最终统计出来的结果是90%，我们在这基础上增加5%的容错，把阈值暂时定在85%，线上环境也没发现遗留的测试场景，所以这个阈值定义也具备一定的可靠性。
- 如果低于85%，可配合开发定位未覆盖到的内容，明确问题，如果是代码冗余导致的问题可提交缺陷给研发进行代码优化，如果是业务场景未覆盖到应补齐测试用例并执行，测试结束后还得完善用例的设计方法。
- 代码覆盖率为什么不是100%？有些场景不需要做到全覆盖，因为实现起来会需要较大的人力成本，通常达到85%即可认定为可靠。而如果剔除掉未能覆盖场景，也能做到100%。这要看团队内对代码覆盖率的要求。
- 以下是可能测不到的场景：（*表示优先关注程度，*越多关注度越高）
1）高并发 比方说某个接口遇到高并发时会进行队列处理，或者拦截其他请求。解： 压测 **
2）特殊的异常 panic null指针 raise - 忽略
a. 服务自身启动的异常 port被占用、依赖服务没起来 启动异常。解：不需要覆盖
b. 服务重启 恢复，比方说运行内存达到某个阈值，直接重启。 解：不需要覆盖
c. 异常的冗余代码，完全命中不到的异常 解：让开发删掉冗余代码 *
d. 开发自定义的异常 解： 需要找开发对齐信息 *
3）三方服务没覆盖全所有的code解：你要主动去对齐三方异常的信息，再覆盖 **
4）中间件的问题，比方说服务对kafka多节点的处理机制 - redis、kafka、公共配置、etcd *
5）冗余代码
a. 代码下个版本的还没用上 - 解：不保留 **
b. 不确定用不用的代码 - 解：让他去确定 **
c. 重复代码 - 解： 删掉 **
6）底层配置 - 根据业务情况去分析，如果是功能开关 支持热更新，那就需要覆盖 **
7）未覆盖到的业务场景***
评论区