制定测试补全计划需聚焦分支覆盖率缺口，优先补全高风险业务函数的关键未覆盖路径，并通过精准用例、ci 阈值管控和流程闭环确保可持续提升。
制定测试补全计划不能只看“覆盖率数字高不高”，而要从报告里找真实缺口——尤其是分支覆盖明显偏低的函数，往往藏着没验证的关键逻辑路径。
盯住分支覆盖率低的文件和函数
在 Jest + Istanbul 生成的 HTML 报告中，重点筛选 % Branch 明显低于 % Lines 或 % Statements 的文件。比如某文件行覆盖 92%，但分支覆盖只有 45%，说明大量 if/else、三元运算符或 switch 的某个分支从未被执行。
- 打开对应文件的详细报告，查看标红（未覆盖）的判断语句，例如
if (user.role === 'admin')只测了 false 分支，就缺一个 role 为 admin 的用例 - 对每个未覆盖分支，明确写出缺失场景：是边界值（如
x === 0）、异常输入（如null）、还是特定状态（如网络超时） - 优先处理核心业务函数（如支付校验、权限拦截、表单提交），这些地方分支遗漏容易引发线上问题
按风险等级分层补测
不是所有未覆盖代码都同等重要。结合业务影响和调用位置，把补测任务分级：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
高风险层：涉及资金、权限、数据写入的函数，分支覆盖必须 ≥ 80%。例如
transferMoney()中的风控开关、重试逻辑、失败回滚路径，每条都要有对应测试 - 中风险层：UI 交互逻辑、API 错误处理（如 401/500 响应分支）、用户输入校验。补全常见错误场景，比如空字符串、超长文本、非法字符
-
低风险层：纯展示逻辑、兜底默认值（如
name || '未知用户'）、日志打点等。可暂缓，或用集成测试间接覆盖
用最小用例触发关键分支
补测不等于堆砌用例，而是用精准输入撬动隐藏路径。例如：
- 一个
if (a && b)，只需两个用例：一个让整体为 true（a=true, b=true），一个为 false（a=false, b=anything）即可满足判定覆盖 - 对
switch (status)，确保每个 case 和 default 都有对应 status 值；若 status 来自后端，就 mock 不同响应体 - 循环中的分支（如
for (let i = 0; i ），准备空数组、单条有效数据、混合有效/无效数据三种输入
把补全动作纳入开发流程闭环
避免补完即丢，让覆盖率提升可持续：
- 在 CI 流程中配置
nyc check-coverage，对分支覆盖设硬性阈值（如--branch 75），低于则阻断合并 - 每次 PR 描述中注明“本次修改涉及哪些分支逻辑，已补充对应测试”，推动开发者关注自身代码的路径完整性
- 定期导出覆盖率衰减报告，识别长期未覆盖的“死角模块”，安排专项攻坚
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
