搞代码覆盖率？一次性解锁7种套路

代码覆盖率分析几乎现在已经成为DevOps平台的标配能力，也是所谓精准测试等服务的基础能力。那么除了做版本的覆盖率之外还能做哪些事情呢？正值年底了，笔者梳理了一下，供大家编写明年的工作规划时参考。

1. 增量代码覆盖率

在团队形成了代码覆盖率的基础能力之后，通常首先会考虑的就是增量代码覆盖率。这是应用场景最为广泛的一项能力。譬如在开发人员合并代码时，可以使用增量代码覆盖率作为代码合入的门禁，作为初步的质量保障。也有些团队会将增量代码覆盖率作为版本发布和上线的一个要求，在发布环节使用。

2. 测试用例/人员的覆盖率

除了开发团队关注代码覆盖率之外，目前也有越来越多的测试团队从证明自身测试效果的角度来关注代码覆盖率了，并投资建立了所谓的测试覆盖率平台，除了提供基本的全量、增量代码覆盖率之外，还研究多版本的覆盖率合并等问题，以应对手工测试过程中换版或者是全回归慢无法一次跑完等。在解决这些问题之后，通常就会瞄准“精准测试”，建设所谓的精准测试平台，实现单个测试用例的覆盖率，并进而实现所谓的正向追溯（用例->代码）、反向追溯（代码->用例），进而实现从全量的用例根据代码的变动遴选出增量覆盖率角度与全量用例执行几乎一致的精简用例集，以达到测试提效的目的。

在这个基础上，通常测试管理者就会提出了测试人员覆盖率，也就是希望能知道每个测试人员的测试执行效果，该人员所执行的测试用例的测试覆盖率。

3. 整体代码覆盖率（开发+测试）

相对于关注测试用例/人员的覆盖率，笔者更建议关注 开发+测试的整体代码覆盖率。这背后其实是关注开发、测试的协同。在“开猿节流、降本增笑”的当下，开发和测试团队如果分头去搞代码覆盖率，甚至内卷代码覆盖率，无疑是一种巨大的浪费，因为很有可能 80%+80%=8x%。

因此，如果制订一个整体代码覆盖率，就实现了双方目标的共享，真正能让代码覆盖率报告成为一个查漏补缺的抓手，开发测试也会去考虑最低成本地实现整体覆盖率的目标，进而促成所谓的测试左移、用例下沉等等真正能实现质量内建的工作。

4. 开发人员的覆盖率

无论是某个特性分支上的所谓增量代码覆盖率，或者是整个发布版本的（增量）代码覆盖率，如果这些工作涉及到多个开发人员的协作，而这些场景下的覆盖率门禁指标没有达成，那么这个结果有的时候就是一笔糊涂账，因为理不清楚每位开发人员的具体数据，也就没有办法去搞清楚谁应该为此负责。因此，也就提出了开发人员覆盖率的概念，也就是目前的（增量）代码中，有某个开发人员最后修改的代码的覆盖率。笔者曾经写过一篇文章《终于把个人覆盖率统计搞清楚了，还一鱼两吃》，介绍了如何结合git blame的结果来实现这一覆盖率的统计。感兴趣的读者可以参考。

5 需求的覆盖率

需求的代码覆盖率是指实现某个需求时所新增代码的覆盖率。在原先整体增量覆盖率的前提下，再下钻到各个需求的增量代码覆盖率，有助于了解每个需求的测试情况。这个指标通常可以用于开发人员提测的环节，通过约定一个需求覆盖率门禁来给提测版本一个基本的保障。在实现方式上，如果团队试试了需求和特性分支绑定等分支管理实践，那么这个问题就转换成了该特性分支上的增量代码覆盖率了。

6. 接口的覆盖率

之前的覆盖率都是关于代码的，在工作中也有同学提出过接口覆盖率的概念，也就是某个微服务对外提供的接口的覆盖率。这个概念与通常覆盖率中的“方法覆盖率“的概念，只是针对于接口方法的一个子集而已。一般这个数据也可以用于度量系统测试的效果。

7. 链路覆盖率

在行覆盖和方法覆盖之外，常用的还有分支覆盖率的概念。单元测试中也推荐开发人员关注分支密集的代码区域，因为这些地方圈复杂度高，业务复杂度也高，是风险密集的地方。在微服务间的链路分析时，也提出了类似的概念，称为链路覆盖率。网易严选的同学在《严选精准测试实践（进阶篇）》一文中提出了这个概念，结合链路的线上调用情况，评判系统测试的覆盖结果是否符合预期。

怎么样，这些覆盖率指标你学废了吗？