覆盖率基本概念：五大门派，你搞清楚了吗？

刚开始接触覆盖率的时候，我也觉得挺懵的。行覆盖率、分支覆盖率、方法覆盖率……光名字就好几个，到底看哪个？

其实啊，它们就像五把不同功能的尺子，量的是代码的不同纬度。今天我就把这五把尺子掰开揉碎了讲给你听。

1. 行覆盖率：最老实的“考勤表”

行覆盖率，说白了就是“这一行代码有没有被执行到”。

公式很简单：

行覆盖率 = 已执行代码行数 / 总可执行代码行数 × 100%

我习惯先看这个指标。为什么？因为它最直观。一个1000行的文件，行覆盖率只有30%——那说明大部分逻辑根本没测。

避坑指南： 我曾经以为行覆盖率90%就够好了，结果漏了一个边界条件，线上出了bug。后来才发现——行覆盖率高不代表分支都走全了。举个例子：

if (x > 0) {
    doSomething();  // 这一行跑了
} else {
    doOther();      // 这一行没跑
}
// 但行覆盖率显示 doSomething 行已覆盖，算100%？不对，else分支没测。

所以行覆盖率只能当“体检初筛”，不能当满分标准。

2. 分支覆盖率：条件的“双面胶”

分支覆盖率看的是if、while、switch这些控制语句的每个分支是否都走到过。

比如上面那个if-else，行覆盖率只管doSomething那一行有没有执行，但分支覆盖率会告诉你：true分支走了，false分支没走。两个分支都要测到，才算100%分支覆盖。

分支覆盖率有两种计算方式：

• 分支百分比： 覆盖的分支数 / 总分分支数
• 条件组合覆盖： (仅在某些工具中) 考虑复合条件的真值表

3. 方法覆盖率：函数的“打卡记录”

方法覆盖率问的是：项目里所有方法（函数），有多少个被调用过至少一次。

公式：

方法覆盖率 = 被调用的方法数 / 总方法数 × 100%

这个指标对衡量“接口级别”的测试覆盖很有用。比如你有个工具类有10个方法，单元测试只调了3个——那方法覆盖率就是30%。剩下7个到底能不能用？不好说。

我遇到过的事： 有一次重构老代码，准备删一个“看起来没用”的私有方法，结果方法覆盖率一查——那个方法从来没被调用过。好家伙，直接删掉。但如果没有方法覆盖率，我可能会犹豫半天。

不过注意，方法覆盖率不关心方法内部逻辑的完整度。一个方法被调用了，但里面复杂的if-else只走了一条路——方法覆盖率依然显示100%。所以它需要和其他指标配合使用。

4. 指令覆盖率：Java字节码的“显微镜”

这个名词听起来高大上，其实就是JaCoCo里最底层的统计单位。指令覆盖率数的是Java字节码指令的数量，而不是源代码的行数。

为什么看这个？因为源代码一行可能编译成多条字节码指令。比如：

// Java源码
int a = b + c * d;
// 编译后的字节码指令可能有：加载b、加载c、加载d、乘法、加法、赋值……至少5条指令

指令覆盖率会统计这些指令中有多少被执行了。它比行覆盖率更精细，能发现行覆盖率“误判”的情况。

5. 圈复杂度：代码的“迷宫难度”

圈复杂度不是覆盖率，但它和测试设计强相关。它的含义是：代码中独立路径的数量。

圈复杂度越高，意味着代码的条件分支越多，越容易出bug。

圈复杂度值	风险等级	我建议的测试策略
1 - 10	低风险	基本路径覆盖即可
11 - 20	中等风险	需要更多边界测试
21 - 50	高风险	考虑拆分为小方法
50+	极高风险	必须重构，否则测试不可能完整

计算方式很简单：对于单函数，圈复杂度 = 决策节点数 + 1。决策节点包括if、while、case等。

小技巧： 我在CI流水线里加了圈复杂度阈值检查，超过15就打标记告警。新人不理解，我说“你想想看，一个函数有15条分支，你能保证每条都测到吗？大概率不能。拆开！”

这些指标怎么组合用？

实战中我一般这样搭配：

1. 第一步：看行覆盖率 —— 快速评估整体覆盖情况
2. 第二步：看分支覆盖率 —— 聚焦逻辑分支遗漏
3. 第三步：看方法覆盖率 —— 检查有没有未测的公共方法
4. 第四步：看圈复杂度 —— 决定需要追加多少测试用例
5. 第五步：指令覆盖率 —— JaCoCo底层数据，一般作为辅助参考

举个例子：线上出bug了，我第一件事就是打开增量覆盖率报告。如果增量代码的行覆盖率100%但分支覆盖率只有60%，那问题大概率在分支遗漏。我顺着分支去补测试，很快就能复现bug。