最有效的测试用例优先级调整方式是直接看分支覆盖率缺口，优先补关键路径上未走通的true/false分支；盯住%branch偏低的函数，通过html报告定位标红判断语句，按业务风险分层补测，并用最小输入精准触发隐藏路径，将覆盖率变化纳入pr流程。
直接看分支覆盖率缺口，优先补关键路径上没走通的 true/false 分支——这是最有效的测试用例优先级调整方式。
盯住 % Branch 明显偏低的函数
行覆盖 90%、分支覆盖才 40%，说明大量 if/else、switch 或三元运算符只走了一边。打开 HTML 报告，点进这类文件，重点看标红的判断语句：
- if (status === 'success') {...} else {...} —— 若 else 块全红，就缺一个 status 为非 success 的用例
- switch (code) { case 200: ... case 500: ... default: ... } —— 缺哪个 case，就 mock 对应 code 值
- data?.items?.length ?? 0 —— 需分别测 data = null 和 data = { items: [1] }
按业务风险分层补测
不是所有未覆盖分支都值得立刻写用例。结合调用位置和影响范围分级处理：
- 高风险：支付校验、权限拦截、数据写入逻辑。比如 transferMoney() 中的风控开关、失败回滚、重试分支，每个都必须有对应测试
- 中风险：API 错误响应（401/500）、表单空值/超长输入、UI 状态切换（加载中→完成→失败）
- 低风险：日志上报、兜底默认值（name || '游客'）、纯展示计算。可延后，或靠集成测试间接覆盖
用最小输入撬动隐藏路径
补测不靠堆数量，而靠精准触发。例如：
- if (a > 0 && b !== null)，只需两组输入：a=5,b={}（true 路径）和 a=-1,b=null（false 路径）
- for (let i = 0; i
- 异步函数中的 try/catch，必须同时写 resolve 和 reject 场景的测试，不能只测成功流
把覆盖率变化纳入 PR 流程
每次提交前运行本地覆盖率检查，PR 描述中明确写出：
- 本次修改涉及哪些分支逻辑（如“新增了 token 过期时的跳转逻辑”）
- 已补充对应测试（如“添加 test('token expired → redirect to login'）”）
- CI 中配置 nyc check-coverage --branches 75%，低于即阻断合并
不复杂但容易忽略：覆盖率本身不是目标，而是帮你快速识别“哪条路还没走过”的导航图。真正重要的，是让每一条被标记为红色的分支，都有明确的业务场景与之对应。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
