制定覆盖率考核标准应分层设定：核心业务函数分支覆盖率≥85%，公共工具方法行覆盖≥90%且函数覆盖100%，UI层分支覆盖≥70%，日志监控等不强制覆盖；以分支覆盖为红线，嵌入PR流程与开发节奏，并接受合理缺口、杜绝虚假测试。
制定适合团队的覆盖率考核标准，关键不是定一个“必须90%”的数字，而是让标准能真实反映测试对业务风险的覆盖程度。盲目追求高数字，容易催生无效用例；完全不设门槛，又会让关键逻辑长期裸奔。
按代码类型分层设定目标值
不同位置的代码，承担的风险不同，覆盖率要求也应有区分：
- 核心业务函数（如支付确认、权限校验、数据提交）：分支覆盖率 ≥ 85%。这些地方一个未覆盖的 else 或 catch 就可能引发资损或越权
- 公共工具方法（如格式化日期、深克隆、URL解析）：行覆盖率 ≥ 90%，函数覆盖率 100%。它们被多处调用，但逻辑相对稳定，重点是确保每个函数都被触发过
- UI 展示层（如组件渲染、loading 状态切换）：分支覆盖率 ≥ 70%。可结合快照测试或 E2E 覆盖部分状态组合，不必强求每个 if 都单独断言
- 日志、监控打点、兜底默认值（如 console.warn、name || '未知'）：不强制覆盖，或归入低优先级任务。它们不影响主流程，可在集成测试中顺带验证
用分支覆盖率作为核心红线
行覆盖率容易虚高——只要某行执行过就算覆盖，哪怕只走了 if 的 true 分支。而分支覆盖率直接暴露逻辑缺口：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- CI 中强制校验
nyc check-coverage --branches 75，低于即阻断 PR 合并 - 报告里重点关注 “% Branch
- 对每个标红的
if、switch、三元运算符，明确写出缺失场景（例如：if (user.token)缺少 token 为空的测试）
把标准嵌入日常开发节奏
标准只有落到动作里才有效，而不是贴在 wiki 上：
- 每次 PR 描述中增加一项：“本次修改涉及哪些判断逻辑？对应测试是否已补充？”
- 新功能开发时，要求测试用例先写分支路径再写主流程，例如先 mock 一个 401 响应，再测正常成功流
- 每月导出一次“长期分支覆盖率
接受合理缺口，拒绝虚假覆盖
有些代码确实不适合单元测试覆盖，硬补只会降低可维护性：
- React 组件中纯 JSX 渲染逻辑（无条件判断）、CSS 类名拼接等，可用快照测试替代
- 第三方 SDK 回调包装层（如微信 JS-SDK 的 success/fail），重点测自己写的错误转换逻辑，而非模拟整个 SDK
- 禁止出现
expect(true).toBe(true)或只调用方法不校验结果的“空气测试”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
