重点是识别未执行的分支而非追求覆盖率数字，需通过HTML报告的“Branch”列定位未覆盖的if/else、switch、try/catch等逻辑路径，并将其转化为可执行测试用例。
直接看 HTML 报告里的红色高亮行，重点不是“覆盖率数字”，而是“哪些分支没走、哪些语句根本没执行”。可视化报告是定位问题的放大镜，不是交差用的截图。
盯紧“Branch”列，别被“Lines”高分骗了
语句或行覆盖率 95%，但分支覆盖率只有 60%？说明大量 if/else、switch、三元表达式只走了其中一条路。比如：
- if (user.role === 'admin' && user.status === 'active') —— 可能只测了 true && true，漏掉 role 是 guest 或 status 是 pending 的组合
- try/catch 块中的 throw new Error(...) —— 错误路径几乎永远不红在行覆盖率里，但在分支覆盖率里会明确标出未覆盖的 catch 分支
- 打开报告后，按“Branch”降序排列文件，优先处理那些分支覆盖率明显偏低的核心模块（如支付校验、权限判断）
点进函数，逐行反推业务场景
HTML 报告里点击某个标红的 if 行，跳转到具体代码位置。不要只想着“怎么让这行变绿”，先问：
- 这个条件成立时，对应用户什么操作？比如输入空邮箱、上传超大文件、切换深色模式
- 这个 else 分支触发，是不是代表某种失败反馈？比如网络超时后显示重试按钮，或 token 过期跳登录页
- 那个标红的 switch case，是不是对应一个尚未模拟的第三方状态码（如 429 频率限制）？
把每个红点翻译成一句可执行的测试描述，比如：“当用户角色为 'guest' 且 status 为空时，应禁止进入管理页并提示权限不足”——这就成了一个清晰的测试用例目标。
立即学习“Java免费学习笔记（深入）”；
区分红字类型，行动方式完全不同
不是所有标红语句都要补测试。先分类再决策：
- 测试遗漏路径：如参数为 null 时的 guard 判断、数组 length === 0 的边界处理 → 补写输入边界值的测试用例
- 死代码：比如 if (process.env.NODE_ENV === 'dev') { ... } 在测试环境永远不执行，或已注释掉但未删除的老逻辑 → 直接删，避免干扰
- 配置驱动分支：如 if (ENABLE_FEATURE_X) { ... }，当前测试未开启该开关 → 在测试 setup 中 mock 环境变量或配置项
- 异步时机问题：setTimeout、Promise.then 内部语句标红 → 在测试中加 await waitFor 或 jest.runAllTimers()
对关键模块设更高分支阈值，CI 卡住退化
全局设 80% 分支覆盖率意义有限。更有效的是在 jest.config.js 或 nyc 配置中单独约束核心路径：
- 支付流程相关文件：branches: 95%
- 权限校验工具函数：branches: 100%
- 数据解析与格式转换模块：branches: 90%
CI 流程中一旦这些模块分支覆盖率下降，就阻断合并。这不是为了数字好看，而是确保每次改动都经过关键路径的显式验证。
