覆盖率目标陷阱是什么
把覆盖率当作单一考核目标，会诱发刷数字行为：无断言的测试、绕过真实调用路径的直调、为覆盖而写的冗余代码。数字上去了，质量没动。覆盖率应作为盲区雷达：指示哪些代码从没被执行过，帮助判断错误处理与边界分支的覆盖缺口。用增量门禁与盲区清单替代全库硬指标，才是可持续的用法。
典型陷阱与正确姿势
- 反例：为覆盖异常分支直接调用内部方法，绕过真实调用路径。
- 反例：断言写成 assertTrue(true)，执行了却没验证任何行为。
- 正确用法：为新增/变更代码设增量覆盖率基线，结合评审抽查断言质量。
- 健康信号：覆盖缺口集中出现在错误处理与边界分支，说明测试设计有方向。
- 反向指标：覆盖率骤升往往意味着刷数，先看 diff 里新增了什么。
基本信息
| 问题根源 | 覆盖率度量「执行过」，不度量「验证了」 |
|---|---|
| 替代指标 | 关键路径覆盖与断言质量抽查 |
| 触发动作 | 覆盖率下降时先查原因，再决定补测或调整 |
| 推荐机制 | 增量门禁 + 定期盲区审阅 |
| 团队文化 | 讨论覆盖缺口而不是比拼百分比 |
增量门禁示意
增量门禁示意
# CI 配置片段（示意，不同工具语法不同）
coverage:
mode: diff # 只看本次变更行
threshold: 80 # 变更代码覆盖率下限
allow_decrease: false # 不允许拉低既有水平设全库覆盖率硬指标容易催生数字游戏；增量门禁与盲区清单更适合持续改进。
覆盖率的作用是回答问题「哪里还没被测到」：把它当雷达扫描盲区，而不是当计分板发奖金。
断言质量靠评审抽查：定期人工阅读高风险模块的测试代码，检查断言强度与时序处理。