开头很多团队都有覆盖率报告。每次测试结束后平台会生成一个数字行覆盖率78% 分支覆盖率52% 方法覆盖率81%这些数字看起来很专业但一到发版决策时测试负责人真正想问的是这次改动有没有测到没测到的地方风险大不大如果覆盖率报告回答不了这个问题它就只是统计结果而不是测试决策依据。1. 总量覆盖率的问题总量覆盖率最大的问题是太粗。一个系统有 10000 行代码本次只改了 20 行。总覆盖率从 76% 变成 77%对本次发版决策的帮助非常有限。因为你不知道本次修改的 20 行有没有被覆盖。核心分支有没有被执行。高风险链路有没有被回归。未覆盖代码是不是本次变更相关。总量覆盖率适合看长期趋势不适合直接指导一次发布。2. 增量覆盖率更接近发版决策精准测试更关注增量覆盖率。也就是只看本次变更相关代码有没有被测试覆盖。示例本次变更方法5 个 已覆盖方法3 个 未覆盖方法2 个 增量方法覆盖率60%这比“系统总体覆盖率 78%”更有价值。如果未覆盖的两个方法都只是后台查询的小分支风险可能可接受。如果未覆盖的是支付回调、库存扣减、订单状态流转那即使总覆盖率很高也不能放心上线。3. 覆盖率要和 Diff 关联覆盖率本身没有方向Diff 才给它方向。一个好的报告应该这样展示变更方法PaymentCallbackService#handleCallback 覆盖状态已覆盖 未覆盖分支重复回调异常分支 关联入口POST /pay/callback 历史缺陷重复回调导致订单状态异常 风险等级中 建议补充重复回调场景注意这里不是只展示数字而是解释风险。覆盖率一旦和 Diff、入口、历史缺陷关联起来就会变成测试决策工具。4. 未覆盖不一定都是问题很多团队看到未覆盖就焦虑其实未覆盖要分类。可接受未覆盖例如防御性代码。废弃路径。非本次变更相关代码。低风险后台查询。很难构造且已有其他监控兜底的异常分支。这些可以记录原因不一定必须补测。必须补测未覆盖例如本次变更核心方法。核心交易链路。历史缺陷相关路径。支付、库存、权限、资金相关逻辑。异常分支可能导致数据不一致。这些未覆盖就应该进入补测清单。精准测试不是追求 100% 覆盖而是让未覆盖风险可解释、可关闭。5. AI 如何解释覆盖率AI 很适合做覆盖率解释但前提是输入要结构化。不要只给 AI覆盖率 78%帮我分析风险。这没有意义。应该给它本次变更方法OrderService#cancelOrder 影响入口POST /order/cancel, Job: close-timeout-order 覆盖情况接口取消订单已覆盖定时关闭订单未覆盖 历史缺陷超时关闭订单曾出现库存未释放 业务风险订单状态和库存一致性然后让 AI 输出已覆盖风险。未覆盖风险。是否可接受。补测建议。需要研发确认的问题。AI 的作用是把覆盖率数字翻译成测试能执行的建议。6. 覆盖率报告应该长什么样一个更有价值的覆盖率报告可以包含这些字段版本v1.2.3 变更方法数12 已覆盖变更方法数9 未覆盖变更方法数3 高风险未覆盖1 中风险未覆盖2 关联入口5 个 建议补测场景4 个再往下展开每个风险项风险项InventoryService#releaseStock 未覆盖 影响入口POST /order/cancel, Job: close-timeout-order 风险原因库存释放失败会导致库存数据不一致 建议补测取消订单、超时关闭订单、重复取消订单 责任确认研发确认是否修改库存幂等逻辑这样的报告才会被测试和研发真正使用。7. 总结覆盖率不是越高越好而是越能解释风险越好。对一次发版来说最重要的不是系统总体覆盖率而是本次变更有没有被覆盖。未覆盖部分是不是高风险。未覆盖原因能不能解释。补测建议能不能执行。测试结论能不能复盘。下一篇我会讲让 AI 推荐回归范围前必须先给它哪些上下文。