高覆盖率本身不能直接减少线上Bug，但高分支覆盖率能显著降低因未测试逻辑引发的故障概率，它强制每个if/else、switch等布尔分支都执行一次，堵住“代码写了但从未运行”的漏洞，比行覆盖率更贴近真实决策路径，需配合关键模块聚焦、红标语句归因和CI强绑定才能真正提升线上稳定性。
高覆盖率本身不能直接减少线上 Bug，但它能显著降低因“未测试逻辑”引发的故障概率——前提是覆盖的是关键路径，而非机械堆砌用例。
高分支覆盖率对线上稳定性最实在的作用
线上问题大量集中在条件分支的遗漏场景：权限判断失败、空值未处理、网络超时分支未走、状态机跳转缺失等。分支覆盖率 ≥90% 意味着绝大多数 if/else、switch case、三元表达式都至少被触发过一次，这直接堵住了“代码写了但从来没人跑过”的漏洞口。
- 例如
if (user && user.role === 'admin')，行覆盖率可能显示已覆盖，但若只测了user存在的情况，漏掉user为null的分支，就可能在线上触发Cannot read property 'role' of null - 支付模块中
if (amount > 0 && isCurrencyValid(currency))，若只验证了正常金额，未覆盖amount === 0或currency === 'XYZ'的拒绝路径，就可能绕过校验逻辑
为什么 95% 分支覆盖率比 95% 行覆盖率更有意义
行覆盖率容易“注水”：一个含多个子条件的 if 语句只要进入一次就整行变绿；而分支覆盖率强制要求每个布尔结果（true/false）都被执行。这意味着它更贴近真实运行时的决策树，也更容易暴露“看起来走了，其实只走了一半”的隐患。
- 某登录函数有 3 个嵌套判断，行覆盖率达 98%，但分支覆盖率仅 72% → 至少有 1/4 的组合路径（如 token 过期 + 网络失败 + 输入非法）从未被模拟
- 历史数据显示，Google 内部将核心服务分支覆盖率从 70% 提升至 92% 后，P0 级异常中由“未执行分支”导致的比例下降了约 55%
高覆盖率真正起效的前提条件
它不是万能解药，必须配合三项实践才能转化为线上稳定性：
立即学习“Java免费学习笔记（深入）”；
- 聚焦关键模块设更高阈值：权限校验、数据序列化、错误上报、API 响应解析等模块，分支覆盖率建议硬性 ≥95%，普通工具函数可适当放宽
-
红标语句必须归因分类：标红不等于要补测试——是死代码就删，是环境依赖就配 mock，是异步时机问题就加
jest.runAllTimers()，是边界输入就补null/undefined/''用例 - 和 CI 流程强绑定但不唯数字论：CI 拒绝合并分支覆盖率低于阈值的 PR，但需配套人工复核报告——比如发现某个文件分支覆盖率骤降，要查是新增逻辑没测，还是旧逻辑被重构后遗漏
本质上，高覆盖率的价值不在那个百分数，而在于它把“我不知道有没有测全”的模糊焦虑，转化成了“我清楚哪几行哪几个分支还没碰”的明确待办。这种确定性，才是减少线上 Bug 的第一步。
