测试盲区关键在未触发的关键业务分支，而非单纯语句覆盖；需通过分支覆盖率缺口定位逻辑盲区，分类处理标红分支，并优先补全支付、权限等高风险函数的关键路径。
分析测试盲区不是比数字高低，而是看哪些关键判断路径始终没被触发。真正要补的不是“没跑过的行”，而是“业务上必须走通却从未验证过的分支”。
盯住分支覆盖率缺口定位逻辑盲区
语句覆盖高但分支覆盖低，是典型盲区信号。比如一个 if (user.role === 'admin' && user.status === 'active')，测试只覆盖了 true && true，却漏掉 false && true、role 为空 或 status 被设为 'blocked' 的场景。
- 打开 HTML 报告，筛选“Branch”列明显低于“Statements”的文件
- 点进函数详情页，聚焦标红的 if / else if / switch case / ?: / || / && 所在行
- 对每个红色分支反问：“用户在什么真实操作下会走到这里？”——答案就是下一个测试用例的输入方向
区分三类红语句，决定补测还是清理
标红不等于缺陷，需分类归因：
- 测试遗漏路径：如 if (!data) throw new Error() 标红 → 补 data = null 或 data = undefined 的用例
- 死代码：如 if (false) { ... }、if (ENV === 'legacy') {...} 且 ENV 永远不为 'legacy' → 直接删除
- 动态不可达逻辑：如基于 process.env.NODE_ENV 或 mock 不足的 API 响应 → 补环境变量配置或改用 jest.mock() 触发
优先补全高风险函数的关键分支
不是所有未覆盖都同等重要。按业务影响分级处理：
立即学习“Java免费学习笔记（深入）”；
- 高风险层：支付校验、权限拦截、数据写入函数。例如 submitOrder() 中的风控开关、库存扣减失败回滚、网络超时重试，每条分支必须有对应用例
- 中风险层：表单校验（空值/超长/特殊字符）、API 错误响应（401/500）、UI 状态切换（loading → error → success）
- 低风险层：默认文案（name || '未知用户'）、日志上报、纯展示逻辑 → 可延后，或靠集成测试覆盖
用最小输入撬动隐藏路径
补测不是堆数量，而是用精准输入激活分支：
- 对 if (a && b)，只需两组输入：a=true, b=true（走真分支）和 a=false, b=anything（走假分支）
- 对 switch (type)，准备 'create'、'update'、'unknown' 三种值，确保每个 case 和 default 都点亮
- 对循环内分支（如 list.forEach(item => { if (item.valid) {...} })），提供 []、[{valid: true}]、[{valid: false}, {valid: true}] 三类输入
