代码覆盖率是测试执行时源码被触达的比例，包括行、函数、分支、语句等类型；它反映测试广度而非正确性，100%覆盖不等于无bug，关键在围绕业务主干与异常分支设计有意义的测试。

JS 中代码覆盖率不是语言原生概念，而是测试工程中的实践指标，面试官问它，通常不是考你工具命令，而是想确认你是否真写过可测、可维护的代码，以及是否理解测试驱动开发的基本逻辑。

什么是代码覆盖率？别被术语吓住

代码覆盖率指测试用例执行时，源码中被“触达”的比例，常见类型有：

• 行覆盖率（Line）：哪些行被执行过
• 函数覆盖率（Function）：哪些函数被调用过
• 分支覆盖率（Branch）：if/else、三元表达式等不同路径是否都走过
• 语句覆盖率（Statement）：比行更细，比如一行含两个赋值，要分别覆盖

注意：100% 覆盖 ≠ 没 bug。它只说明“代码跑过了”，不保证逻辑正确、边界处理得当或异常路径被验证。

dmap-jsapi-skill

DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。

下载

面试常问的 3 类实操题怎么答

这类问题重在展现你的测试意识和工程习惯，不是背定义：

• “如何提升某个模块的覆盖率？”——先看缺失在哪：是没测分支？没覆盖错误抛出？还是异步回调没 await？接着补用例，而不是堆断言
• “某个函数覆盖率只有 60%，可能原因是什么？”——重点检查：条件判断的 else 分支、try/catch 的 catch 块、默认参数未触发场景、Promise reject 路径
• “用 Jest 测一个带 setTimeout 的函数，怎么写？”——必须用 jest.useFakeTimers() + jest.runAllTimers() 或 await waitFor，否则测试会超时或跳过定时逻辑

别踩的坑：覆盖率误区三连

面试官最爱从这里追问深度：

• 把覆盖率当 KPI：为凑数字写无意义测试（如只调用函数不 assert），反而掩盖真实风险
• 忽略集成与 E2E：单元测试覆盖率高，但组件间协作或用户流程没测，照样线上翻车
• 不关注“有意义的覆盖”：比如只测正常流程，却漏掉空数组、null 输入、网络失败等关键边界

真正有价值的覆盖率，是围绕业务逻辑主干 + 显著异常分支来设计的，不是数字游戏。