周三下午，一个后端工程师盯着屏幕上的绿色进度条——测试覆盖率92%，团队阈值是80%。他点了合并，两周后，生产环境因为一个未覆盖的分支逻辑崩溃了。

这不是孤例。很多团队把覆盖率当质量门禁：75%、80%、85%，数字看起来专业，实则随意。高覆盖率等于高质量？我们用一段真实代码验证。

打开网易新闻 查看精彩图片

先看这个Go语言的折扣计算函数。逻辑很简单：未成年人打9折，非活跃用户打8折，两个条件独立判断。四个测试用例覆盖了所有分支组合——覆盖率100%。

但问题藏在细节里。测试用例用的是17岁和25岁、30岁，边界值18岁呢？浮点数比较用了固定精度epsilon，极端数值会不会溢出？代码没报错，但"覆盖"不等于"验证正确"。

更隐蔽的是，覆盖率只统计代码行是否被执行，不统计断言是否有效。你可以写一堆没有assert的测试，覆盖率照样好看。很多团队的门禁只检查数字，不检查测试质量。

那覆盖率还有用吗？有，但得换个用法。把它当探测工具，而非目标。每次覆盖率下降时追问：是新代码难测试，还是测试策略该调整？数字背后的原因比数字本身重要。

回到那个崩溃的案例。事后复盘发现，失败分支在覆盖率报告里是红色的——从未被执行。但团队习惯了"绿色即安全"，红色警告被当成技术债搁置了。门禁机制反而制造了虚假安全感。

真正有效的测试策略需要三样东西：针对边界的用例设计、对业务风险的优先级排序、以及定期人工审查测试本身的有效性。覆盖率可以是起点，但不该是终点。