4、覆盖率目标设定：如何制定合理的覆盖率目标
说到覆盖率目标，我见过太多团队在这个问题上栽跟头。
有的团队上来就喊「覆盖率必须到90%」，结果开发天天补测试用例，补出来的全是无效用例。有的团队压根没目标，测到哪算哪，上线前心里完全没底。
这两种极端，我都经历过。今天聊聊我的经验。
4.1 覆盖率目标不是拍脑袋定的
先讲个真实案例。我之前带过一个项目，产品经理拍板说「覆盖率必须85%」。结果呢？
开发为了凑数字，把 getter/setter 方法全测了，核心业务逻辑反而没覆盖到。上线后出了个严重 bug，恰好就在没测到的那段代码里。
所以我的第一个建议是：覆盖率目标要跟风险挂钩，不是跟数字较劲。
核心原则：
- 覆盖率是手段，不是目的
- 目标要可衡量、可追踪、可落地
- 不同模块、不同阶段，目标不同
4.2 不同项目的目标差异
你想想看，一个金融交易系统和一个小型内部工具，能用同一个覆盖率标准吗？显然不能。
| 项目类型 | 建议行覆盖率 | 建议分支覆盖率 | 说明 |
|---|---|---|---|
| 金融/医疗/航天 | 85% - 95% | 80% - 90% | 核心逻辑必须全覆盖 |
| 电商/社交/内容 | 70% - 85% | 65% - 80% | 主流程优先，边缘场景酌情 |
| 内部工具/原型 | 50% - 70% | 40% - 60% | 保证核心功能可用即可 |
| 遗留系统重构 | 逐步提升 | 逐步提升 | 先补核心模块，再逐步扩展 |
我个人习惯把项目分成三类：
- 保命型：出问题会死人、赔钱、坐牢的。这类项目，覆盖率低就是犯罪。
- 赚钱型：出问题影响收入、用户体验。这类项目，主流程必须稳。
- 工具型：出问题影响不大。这类项目，别在覆盖率上浪费太多时间。
我的经验： 别试图用一个数字管所有模块。核心支付模块我要求90%，用户注册模块70%就够了。差异化对待，才是务实做法。
4.3 目标分解方法
定好总目标后，怎么拆下去？我常用的方法是「三层分解法」。
4.3.1 按模块分解
把系统拆成模块，每个模块单独定目标。举个例子：
- 订单模块：行覆盖率85%，分支覆盖率80%
- 支付模块：行覆盖率90%，分支覆盖率85%
- 用户模块：行覆盖率70%，分支覆盖率65%
- 日志模块：行覆盖率50%，分支覆盖率40%
这样做的好处是，团队能聚焦在真正重要的地方。我曾经有个项目，日志模块占了30%的代码量，但全是简单打印。如果一刀切要求80%，那才是真浪费。
4.3.2 按阶段分解
覆盖率不是一步到位的。我一般分三个阶段：
- 第一阶段（1-2周）：先跑起来，摸清现状。目标：达到当前覆盖率的1.2倍。
- 第二阶段（1个月）：补齐核心模块。目标：核心模块达到目标值。
- 第三阶段（持续）：逐步提升边缘模块。目标：整体达到最终目标。
说白了，别想一口吃成胖子。我见过太多团队，第一个月冲得太猛，第二个月就崩了。
4.3.3 按优先级分解
代码不是平等的。有些代码死了都不能出问题，有些代码出问题也无所谓。我习惯用「红黄绿」标记：
- 红色：必须覆盖，不覆盖不能上线
- 黄色：尽量覆盖，实在来不及可以豁免
- 绿色：随缘覆盖，有时间就补
注意： 红色区域不能超过总代码量的20%。否则团队会被压垮。我曾经犯过这个错，把50%的代码标成红色，结果开发直接摆烂了。
4.4 目标设定的常见误区
嗯，这里我要多说几句。我踩过的坑，希望你别再踩。
- 误区一：追求100%覆盖率 —— 100%覆盖率意味着你花了大量时间在无关紧要的代码上。边际效益递减，懂吧？
- 误区二：只看行覆盖率 —— 行覆盖率100%，分支覆盖率可能只有30%。分支覆盖率才是真正考验逻辑覆盖的指标。
- 误区三：目标定完就不管了 —— 覆盖率目标要定期回顾。项目迭代了，代码变了，目标也得跟着调。
- 误区四：拿覆盖率考核个人 —— 千万别！这会导致开发写一堆无效测试来凑数。覆盖率是团队指标，不是个人KPI。
4.5 一个实用的目标设定流程
最后，分享一个我目前在用的流程。你可以直接拿去用：
- 摸底：先跑一次全量测试，拿到当前覆盖率数据
- 分类：按模块和优先级，把代码分成红黄绿三类
- 定标：根据项目类型和风险，给每个模块定目标
- 分解：按阶段拆解，明确每个迭代要提升多少
- 追踪：每周看一次覆盖率趋势，发现问题及时调整
- 复盘：每个迭代结束，回顾目标是否合理，要不要调整
记住： 覆盖率目标不是锁死的。它应该随着项目进展、团队能力、业务变化而动态调整。灵活一点，务实一点，比死磕一个数字强得多。
这张图总结了我上面说的三层分解法。从上到下，从总目标到具体动作，每一步都清晰可执行。
最后一个小建议： 目标定好后，把它贴在团队看板上。每周站会花30秒看一眼覆盖率趋势。别让它变成一个没人记得的数字。