写代码的时候，总有人说‘你的测试覆盖全了吗’，这时候很多人一头雾水。其实代码覆盖率并不是什么神秘指标，它只是告诉你，写的测试到底跑过了多少行代码。
从工具报告里看数字
最常见的做法是用测试工具生成覆盖率报告。比如用 Jest 做前端测试，在命令行加上 --coverage 参数，运行后就会看到一个表格，列出每个文件的语句、分支、函数和行的覆盖比例。
jest --coverage执行完之后，终端会输出类似这样的信息：
-----------------|---------|----------|---------|---------|
File | % Stmts | % Branch | % Funcs | % Lines |
-----------------|---------|----------|---------|---------|
src/utils.js | 85.71 | 75.00 | 83.33 | 85.71 |
src/index.js | 100.00| 100.00 | 100.00 | 100.00 |
-----------------|---------|----------|---------|---------|这里的百分比就是覆盖率。如果某文件只有 60% 的行被执行过，那剩下的 40% 就是没被测试触达的地方。
打开 HTML 报告看细节
光看数字不够直观，多数工具还能生成带颜色标记的 HTML 页面。运行完测试后，会在项目里生成一个 coverage 文件夹，里面有个 index.html，浏览器打开就能看到具体哪一行被覆盖了。
绿色代表这行代码被执行过，红色表示完全没跑过，黄色可能是条件判断只走了一条分支。点进某个文件，可以直接看到源码高亮显示，哪里漏测一目了然。
关注分支和函数，不只是行数
有时候你看着行数覆盖了 90%，但关键逻辑在 if else 里拆成多个分支，而测试只走了 true 的情况。这时候分支覆盖率可能才 50%。真正重要的不是“有没有执行”，而是“各种情况有没有都测到”。
比如一段处理用户权限的代码：
function checkAccess(user) {
if (user.isAdmin) {
return grantFullAccess();
} else if (user.isEditor) {
return grantEditOnly();
} else {
return denyAccess();
}
}如果测试只用了管理员账号跑了一遍，那虽然看起来几行都执行了，但后面两个 else 分支根本没验证。这种情况下，即使行覆盖率很高，实际风险依然存在。
结合 CI 看趋势变化
很多团队把覆盖率检查集成到持续集成流程中。每次提交代码，自动跑测试并生成报告。有些还会设置阈值，比如不允许覆盖率下降超过 2%。这样能避免有人提交大量无测试的新代码。
你在 Git 提交记录里点开 CI 构建日志，经常能看到一行提示：Coverage: 87.3% (–1.2%) ❌，这就说明这次改动让整体覆盖率掉了，需要补测试才能合并。
别被高数字骗了
有项目显示覆盖率 98%，但上线照样出 bug。原因很简单——覆盖率只反映“是否执行”，不保证“是否正确”。测试可能调了函数，但没检查返回值对不对；或者模拟数据太理想，没覆盖边界情况。
就像备份系统，哪怕每行代码都跑了一遍，但如果没模拟磁盘写满、网络中断这些异常场景，真出事时还是扛不住。覆盖率是个参考，不能当护身符。