JS代码覆盖率核心是理解“为什么测、怎么测、怎么看、怎么改进”：语句覆盖仅表执行与否，分支覆盖（≥80%）才反映逻辑路径是否充分验证，函数覆盖只确认调用；用jest --coverage生成HTML报告，优先分析业务核心模块的红色未覆盖行，聚焦异常路径与不可达分支，避免伪覆盖和100%即无bug的认知误区。
JS 代码覆盖率面试题，核心不是背定义，而是说清“为什么测、怎么测、怎么看、怎么改进”。面试官想确认你是否真用过、是否理解测试质量与工程落地的关系。
搞懂覆盖率类型和实际意义
别只说“行覆盖、函数覆盖、分支覆盖”，要讲清楚它们分别反映什么风险：
-
语句覆盖率（Line Coverage）：只说明每行是否执行过，但掩盖逻辑缺陷。比如
if (a && b)即使 a 为 false 跳过整个表达式，也算该行已覆盖，但 b 的情况完全没验证。 - 分支覆盖率（Branch Coverage）：要求每个 if/else、三元、循环的真假路径都走一遍。这才是判断条件逻辑是否被充分检验的关键指标。
- 函数覆盖率（Function Coverage）：仅确认函数是否被调用过，不关心内部逻辑——适合快速兜底，但不能替代更细粒度检查。
- 行+分支组合（Istanbul 默认）：真实项目中推荐关注 分支覆盖率 ≥ 80%，比单纯追求行覆盖更有价值。
知道怎么在项目里跑出靠谱数据
光会说概念不行，得能动手解释流程。以主流工具 jest + istanbul 为例：
- 运行
jest --coverage会自动生成 HTML 报告，默认输出到coverage/lcov-report/index.html； - 关键看
./coverage/coverage-summary.json里的branches和lines字段，不是只盯着总分； - 加
--coverageReporters=lcovtext,html可同时生成可读报告和 CI 友好文本； - 若用 Vitest，命令是
vitest run --coverage，配置项写在vitest.config.ts的coverage对象里。
遇到低覆盖率，怎么分析和提升
被问“覆盖率只有 40%，你怎么办？”时，避免说“赶紧补测试”。重点展示排查思路：
- 打开 HTML 报告，定位红色未覆盖区域——优先看 业务核心模块（如支付校验、权限判断），而非工具类或 mock 辅助函数；
- 检查是不是有 不可达分支：比如
if (process.env.NODE_ENV === 'development')在 test 环境下永远不进，应改用可注入的依赖或环境模拟； - 确认是否遗漏了 异常路径：比如 fetch 失败、Promise reject、输入非法值等，这些常是 bug 高发区，也是提升覆盖率的高性价比切入点；
- 警惕“伪覆盖”：用
expect(fn).toHaveBeenCalled()只验证调用，没验证行为；应配合mockReturnValue或断言返回值/副作用。
别踩常见认知坑
有些说法看似合理，实则暴露理解偏差：
- “100% 分支覆盖率 = 没 bug” —— 错。它只保证逻辑路径被执行，不保证结果正确、边界处理得当、异步时序合理；
- “UI 组件不用测覆盖率” —— 不准确。React/Vue 组件的 props 响应、事件触发、状态流转同样需要分支验证，可用 RTL + jest 实现；
-
“CI 里卡覆盖率红线没意义” —— 有意义，但需合理设置。建议对主干分支设
branches: 80红线，新 PR 要求增量覆盖达标，而不是一刀切 100%。
