什么是测试用例覆盖率
你在写代码的时候，是不是也常听到同事说‘这个功能测过了’？但到底测得全不全，有没有漏掉某个分支逻辑，光靠嘴说可不行。这时候就得看数据——测试用例覆盖率就是告诉你，你的测试到底跑了多少代码的一个量化指标。
简单讲，测试用例覆盖率就是已执行的代码占总代码的比例。比如一段函数有10行，测试跑了8行，那覆盖率为80%。数字一出来，谁也糊弄不了。
常见的覆盖率类型
别以为覆盖率就一个数字，其实它分好几种：
- 语句覆盖率：看每一行代码有没有被执行过。
- 分支覆盖率：判断 if、else 这种分支条件是否都走了一遍。
- 条件覆盖率：比如 (a > 0 || b < 5)，两个条件是否各自被测试过真假情况。
- 路径覆盖率：所有可能的执行路径都跑通了吗？这个最难达到100%。
日常开发中，分支和语句覆盖率最常用，工具支持也最成熟。
怎么算？举个实际例子
假设你写了这样一个函数：
function checkUserAge(age) {
if (age < 0) {
return '年龄不能为负';
} else if (age < 18) {
return '未成年';
} else {
return '成年';
}
}现在你只写了两个测试用例：
- 输入 -1，期望输出“年龄不能为负”
- 输入 20，期望输出“成年”
看起来好像没问题，但中间那个“未成年”的分支压根没测。语句覆盖率可能很高，但分支覆盖率只有66.7%（3个分支走了2个）。漏了这一条，上线后万一有人输15岁却显示成年，问题就大了。
工具有哪些？怎么上手
主流语言基本都有配套工具。比如 JavaScript 可以用 Istanbul（配合 Jest），Java 用 JaCoCo，Python 用 coverage.py。这些工具运行完测试后，会生成一份可视化报告，清楚标出哪些代码块是绿色（已覆盖），哪些是红色（未覆盖）。
以 Jest 为例，命令行运行：
npx jest --coverage就会自动生成覆盖率统计，还能设置最低阈值，低于标准就报错，强制开发者补全测试。
覆盖率越高越好吗
不是。100% 覆盖率听起来很完美，但也可能只是“形式主义”。比如你写了个测试，调用了函数，传了个参数，看似覆盖了，但根本没有验证返回值对不对。这种“假覆盖”比没覆盖还危险，给人虚假安全感。
更合理的做法是结合业务重点来评估。核心支付流程哪怕只有80%覆盖也要严查，而一些日志打印函数就算没覆盖也不必强求。
小团队也能用起来
别觉得这是大厂才玩得起的东西。你现在就可以在项目里加一行配置，让 CI 在每次提交代码时自动跑测试并检查覆盖率变化。发现问题早提醒，远比上线后半夜被叫起来修 bug 强。
把覆盖率当成一面镜子，照出你测试里的盲区。数字不会撒谎，代码也不敢偷懒。