精准补全未测试异常分支需先定位再覆盖最后验证，重点识别throw、reject、try/catch中未覆盖的错误路径，借助Istanbul/nyc开启分支覆盖率，结合函数签名与边界值设计反向用例，并用Mock强制触发异常以验证错误处理健壮性。
直接补全未测试的异常分支，核心是先定位、再覆盖、最后验证。重点不是写更多用例，而是精准识别哪些 throw、reject、try/catch 中被忽略的错误路径 真正没被测到。
用覆盖率工具暴露“假绿”分支
很多项目跑完测试显示 90%+ 行覆盖，但异常分支实际为 0 覆盖——因为测试只走正常流程。用 Istanbul/nyc 启用分支覆盖率（branches: true），重点关注标红的 else 分支、catch 块、throw 语句前的条件判断。例如：
- if (x < 0) throw new Error('invalid') → 如果所有测试 x 都 ≥ 0，这行永远不执行
- catch (e) { log(e); rethrow; } → 没有测试让 try 块抛错，整个 catch 是盲区
从函数签名和边界值反推异常触发点
不靠猜，看输入约束和内部逻辑。例如一个函数声明为 function parseJSON(str: string): object，那以下情况必须补用例：
- 传
null、undefined、数字、对象等非字符串类型（类型校验分支） - 传空字符串、含非法字符的字符串（
JSON.parse会 throw） - 模拟网络请求失败（如 Axios 的
response.status === 500）
关键：每个 显式 throw 或 可能隐式抛错的 API 调用（如 JSON.parse、fs.readFileSync），都对应至少一个反向用例。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
用测试替身强制触发异常路径
真实环境难复现错误？用依赖注入 + Mock 控制异常出口：
- Node.js 文件操作：用
jest.mock('fs')让readFileSync抛错 - HTTP 请求：用
jest.mock('axios')让get返回 rejected Promise - 第三方 SDK：把实例方法替换成
jest.fn().mockRejectedValue(new Error())
注意：不要只 mock 错误消息，要确保 整个异常处理链被运行（比如 catch 里调用的 cleanup 函数是否执行）。
检查错误处理本身是否健壮
补异常用例不只是“让它抛”，更要验证“抛了之后系统是否稳住”。例如：
- 异步函数中
catch是否吞掉错误而不 re-throw？补用例验证错误是否透出或转成业务错误 - 资源清理逻辑（如
finally关闭连接）是否在异常下仍执行？加断言检查状态 - 用户提示是否准确？比如捕获
NetworkError却显示“参数错误”，需补断言校验提示文案
