代码覆盖率是衡量测试用例执行源代码比例的指标，反映代码运行痕迹而非测试质量；核心类型包括行、分支、函数和语句覆盖率；JavaScript 中常用 nyc（istanbul）配合 Jest 或 Mocha 获取，并需结合业务设定合理阈值与关注未覆盖逻辑。
代码覆盖率是衡量测试用例执行了多少源代码的指标，它不表示测试质量高低，只反映有多少代码被运行过。
代码覆盖率的核心类型
常见覆盖维度包括：
- 行覆盖率（Line Coverage）：有多少行代码被执行过。最常用，但容易产生“假高分”——比如某行只执行了 if 的真分支，else 分支没走，这行仍算“已覆盖”。
- 分支覆盖率（Branch Coverage）：每个 if、else、三元表达式、switch 的所有可能路径是否都走过。比行覆盖更严格，能发现逻辑遗漏。
- 函数覆盖率（Function Coverage）：每个声明的函数是否至少被调用一次。简单直接，但无法反映函数内部执行深度。
-
语句覆盖率（Statement Coverage）：以语句为单位（如赋值、return、throw），比行覆盖更细粒度，尤其在一行含多个语句时有意义（例如
a = 1; b = 2;算两条语句）。
如何在 JavaScript 中实际获取覆盖率
主流方案是使用 istanbul（现由 nyc 命令行工具驱动），配合测试框架如 Jest 或 Mocha：
- Jest 默认集成 nyc，运行
jest --coverage即可生成 HTML 报告，打开coverage/lcov-report/index.html查看各文件的行/分支/函数覆盖详情。 - 若用 Mocha，需安装
nyc：npm install --save-dev nyc，然后执行nyc mocha。 - 关键配置项（如
nyc.config.js）可指定忽略文件（exclude）、设定阈值（branches: 80表示分支覆盖率低于 80% 则 CI 失败）。
覆盖率数字背后的注意事项
高覆盖率≠高质量测试：
立即学习“Java免费学习笔记（深入）”；
- 一个空的
test('should do something', () => { myFunc(); });可能让函数和行覆盖率飙升，但完全没断言，毫无验证意义。 - 边界值未测（如数组为空、参数为 null）、异常路径未触发（try/catch 中的 catch 块）、异步逻辑未 await，都会让覆盖率失真。
- 过度追求 100% 容易导致为覆盖而写测试，比如给纯计算函数加一堆无意义输入，反而增加维护成本。
实用建议：让覆盖率真正有用
把覆盖率当作反馈工具，而不是目标：
- 关注“未覆盖部分”：报告里标红的行或分支，优先补上对应测试，尤其是条件判断和错误处理路径。
- 结合业务逻辑设合理阈值：核心模块建议分支覆盖 ≥ 90%，工具类函数可适当放宽；CI 中设置最低要求（如整体行覆盖 ≥ 75%），避免倒退。
- 定期看趋势而非单点数值：用
codecov或coveralls集成到 GitHub，观察 PR 引入的覆盖率变化，及时拦截低覆盖提交。
基本上就这些。覆盖率本身不复杂，但容易忽略它只是“执行痕迹”的统计，真正的完整性还得靠人对逻辑的理解和有针对性的用例设计。
