评估关键路径测试覆盖需聚焦影响业务正确性与稳定性的决策点，而非整体覆盖率数字；应识别支付、权限、表单等跨函数的关键链，通过Jest+Istanbul检查分支覆盖，补全if/else、try/catch等所有路径，并按风险等级设定分层验收标准。
评估关键路径的测试覆盖情况，不能只看整体覆盖率数字，而要聚焦代码中真正影响业务正确性与稳定性的决策点是否被充分验证。
识别关键路径：从调用链和业务风险出发
关键路径不是语法上的“热门函数”，而是那些一旦出错就会导致功能中断、数据异常或资损的逻辑链。例如：
- 支付流程中的风控校验、余额扣减、订单状态更新三步调用链
- 权限拦截中间件里对 token 解析、角色比对、拒绝响应的完整分支
- 表单提交时的前端校验（空值、格式、长度）→ API 调用 → 成功跳转/失败提示
这些路径往往横跨多个函数，但核心判断集中在 if、switch、三元运算符、try/catch 等分支语句上。Jest + Istanbul 报告中，% Branch 明显低于 % Lines 的文件，大概率就藏有未触达的关键分支。
用覆盖率报告反向定位未覆盖分支
打开 HTML 覆盖率报告后，重点做三件事：
立即学习“Java免费学习笔记（深入）”；
- 找标红行：不是某一行没执行，而是它所在的整个分支（如 if 块的 true 或 false 分支）从未进入
- 查函数详情页：点击具体函数，看每处 if 右侧是否显示 “2/2 branches covered”——只有双路径都走通才算覆盖
- 盯异步逻辑：fetch 调用后的 .then/.catch、async 函数里的 try/catch 都是典型双分支，必须分别写 resolve 和 reject 场景的测试
验证是否真覆盖：不止调用，还要走通逻辑
函数被调用 ≠ 关键路径被验证。比如一个权限函数：
function checkAccess(user) {
if (!user || !user.token) return false;
if (user.role === 'admin') return true;
return user.permissions?.includes('edit');
}
只传 { role: 'admin' } 测试，能拉高行覆盖和函数覆盖，但漏掉了 token 为空、permissions 为 undefined、无 edit 权限三种关键失败路径。补全需覆盖：
- user = null → 触发第一个 if
- user = { token: 'xxx', role: 'user' } → 进入最后一行，但 permissions 缺失
- user = { token: 'xxx', role: 'user', permissions: ['read'] } → 最后一行返回 false
设定分层验收标准，避免一刀切
不同路径的风险等级不同，覆盖率要求也应区分：
- 高风险路径（资金操作、权限控制、数据删除）：分支覆盖 ≥ 85%，且每个 if/else、case/default、try/catch 必须有对应用例
- 中风险路径（API 错误处理、用户输入提示）：覆盖常见异常组合，如空字符串、null、超长文本、401/500 响应
- 低风险路径（默认文案、日志上报、loading 状态）：可接受行覆盖达标，不强求分支全覆盖
CI 中用 nyc check-coverage 设置分支阈值，让关键路径覆盖成为合码硬门槛。
