行覆盖率看“代码有没有被执行”，分支覆盖率看“逻辑分支有没有被走全”；前者统计触达的可执行行占比，后者统计每个if/else等决策点的真假分支覆盖比例。
行覆盖率和分支覆盖率是两个不同维度的指标，回答的是完全不同的问题：前者看“代码有没有被执行”，后者看“逻辑分支有没有被走全”。光看行覆盖高，不代表测试充分；分支覆盖低，往往意味着关键判断逻辑存在盲区。
行覆盖率关注的是“哪几行代码跑过了”
它统计测试执行时实际触达的可执行源码行数占比。空行、注释、纯花括号这些不可执行的行不计入分母。比如下面这段 JavaScript：
function calc(x, y) {
if (x > 0) {
return x + y;
}
return y - x;
}
如果只用 calc(-2, 5) 测试，会执行第 1、2、4、5 行（跳过第 3 行），行覆盖是 4/5 = 80%。但这个结果掩盖了一个事实：if 的真分支（第 3 行）完全没被验证。
- 适合快速发现明显未执行的代码块
- 容易被“只调用不校验”的测试拉高（比如只调函数不检查返回值）
- 对 if/else、三元运算符、循环条件等内部路径无感知
分支覆盖率聚焦在“每个判断的真假方向是否都走到了”
它把每个控制流决策点（如 if、else if、switch case、三元运算符 ?:、while/for 的条件）拆成独立分支，统计被触发的比例。上面例子中，if (x > 0) 构成 2 个分支（true 和 false），只测了 false 分支，分支覆盖就是 1/2 = 50%。
- 能暴露“条件写反”“边界遗漏”“异常路径未测”等问题
- 一个
if (a && b)算作 1 个分支点，但有 4 种组合路径；工具通常按“判定覆盖”（DC）处理，即至少让 a&&b 整体为 true 和 false 各一次 - 金融、支付类项目建议分支覆盖不低于 80%，否则易漏掉超时重试、权限校验失败等关键路径
实际报告里怎么看区别
主流工具（如 Jest + Istanbul）生成的 HTML 报告中，同一文件会并列显示多个百分比：
File: calc.js
% Statements: 90% % Branch: 60% % Functions: 100% % Lines: 90%
当“% Branch”明显低于“% Lines”或“% Statements”时，说明大量代码虽被执行，但条件分支未被穷尽。这时要重点检查带 if/else、switch、三元运算符的函数，补全真假场景的测试用例。
不要只盯着总分——分支覆盖才是检验逻辑健壮性的硬尺子。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
