测试覆盖率到底在测什么
很多人写完代码，跑一遍测试用例就以为万事大吉。可你有没有遇到过这种情况：测试全通过，上线后却频繁出 bug？问题可能就出在“测得不够全”。测试覆盖率就是帮你回答这个问题——你的测试到底覆盖了多少真实逻辑。
它不是万能指标，但确实是个有用的“探照灯”，能照出那些被忽略的角落。
行覆盖率：最基础的起点
这是最常见的统计方式，看的是代码中有多少行被执行过。比如你写了 100 行业务逻辑，测试跑完发现只有 70 行被运行到，那行覆盖率就是 70%。工具像 JaCoCo（Java）、Istanbul（JavaScript）都能自动生成报告。
不过要注意，行覆盖高不代表质量高。一行 if 判断就算只走了 true 分支，也算“覆盖”了，可 false 的情况万一出问题呢？
分支覆盖率：关注逻辑走向
比起单纯数行数，分支覆盖更进一步。它关心的是 if、else、switch 这些控制结构的每个路径有没有被走到。比如下面这段代码：
if (user.isLogin()) {
sendWelcomeMessage();
} else {
redirectToLogin();
}如果你的测试只模拟了已登录用户，那 else 分支就没被触发，分支覆盖率就会低于 100%。这时候你就知道还得补个未登录的测试场景。
函数与方法覆盖率
这个比较简单，就是看项目里定义的函数有多少被调用过。有些工具默认会统计，比如单元测试没调到某个工具函数，报告里就会标红。适合用来发现废弃代码或漏测模块。
实际工作中怎么用
别一上来就追求 100%。有些边界条件很难模拟，强行凑数字反而浪费时间。建议的做法是：核心模块定高标准（比如支付流程要求分支覆盖 ≥90%），普通功能可以宽松些。
把覆盖率工具集成进 CI 流程也很实用。比如每次提交代码，自动跑测试并生成报告，如果覆盖率下降就告警。这样团队成员都会下意识去补测试。
别被数字骗了
有个同事曾经秀过自己 98% 的覆盖率，结果一查发现全是“走过场”式测试：只调用接口不验证结果，或者数据都是 mock 死的。这种覆盖等于没覆盖。
真正的价值不在数字高低，而在于通过覆盖率报告反向检查测试设计是否合理。看到低覆盖区域，问问自己：这里真测了吗？逻辑完整吗？有没有隐藏的风险？
工具只是镜子，照出的是你对质量的态度。