测试覆盖率 100% 是目标吗
项目上线前，总有同事盯着测试报告问：覆盖率到 85% 了吗？有没有可能冲到 100%？好像只要数字够高，代码就足够安全。但真有这么简单？
写过单元测试的人都遇到过这种情况：某个工具函数三行代码，逻辑清晰，一行返回一个计算结果。为了覆盖它，你写了一堆 describe 和 it，传了几组参数，断言输出正确。没问题。可另一个函数，涉及异常处理、边界判断、异步回调，写完测试发现才覆盖了六成。这时候你会想，是不是该花两小时补全剩下的？
覆盖率数字背后的真相
测试工具统计的是“被执行的代码行数”，而不是“被正确验证的行为”。你可以写出一堆测试，让每行代码都跑一遍，但这些测试可能根本没检查结果对不对。
比如这段代码：
function divide(a, b) {
if (b === 0) {
throw new Error('Cannot divide by zero');
}
return a / b;
}写个测试调用 divide(4, 2)，能覆盖大部分行。但如果没专门测试 divide(4, 0)，那个 if 分支依然没被触及。而即使你写了，覆盖率到了 100%，也不能说明你在真实场景里不会因为参数类型错误出问题。
为凑数字而写的测试反而有害
见过太多项目里，有人为了提升那几个百分点，在 CI 报告前临时补测试。补的不是核心逻辑，而是日志打印、setter/getter 包装器这类“容易覆盖但不关键”的代码。这种测试写得越多，维护成本越高，改个名字就得同步七八个文件。
更麻烦的是，这些测试往往只走流程，不验证行为。时间一长，团队开始忽略测试失败，反正“只是覆盖率低了点”“不影响主流程”。信任一旦崩塌，测试就成了摆设。
真正该关心的是什么
比起追求 100%，不如先问：最关键的三个功能有没有被覆盖？用户最常走的路径有没有测试保障？支付失败时会不会多扣钱？提交表单后数据有没有正确落库？
有些团队采用“核心路径全覆盖 + 边界 case 明确标注”的策略，不强求整体数字，但要求所有重要分支都有对应测试。他们接受覆盖率 80%，但那 20% 漏掉的是日志、工具类、自动生成代码等低风险部分。
也有的公司在重构前会临时提高覆盖率要求，确保改动过程中不会误伤原有逻辑。等稳定后，再回归常态维护节奏。这说明，覆盖率是手段，不是目的。
别被数字牵着走
就像健身不是为了在体脂秤上看到某个数字，写测试也不是为了让仪表盘变绿。你愿意花时间的地方，应该取决于风险高低，而不是哪段代码更容易被覆盖。
下次有人问“能不能做到 100%”，不妨反问一句：你觉得我们现在最怕出问题的是哪块？先把它守住，比什么都强。”,"seo_title":"测试覆盖率 100% 真的有必要吗？别被数字骗了","seo_description":"测试覆盖率 100% 是很多团队追求的目标，但这是否真的必要？探讨覆盖率背后的实质意义与常见误区。","keywords":"测试覆盖率, 单元测试, 软件测试, 测试策略, 代码质量"}