测试覆盖缺口检查表由两部分组成：检查项回答“覆盖是否成立”，记录列回答“缺口如何被记录、判断和关闭”。它适合在用例评审前、提测前、版本发布前和回归收尾时使用，判定范围限定在需求、用例、执行、缺陷与风险、回归五个层面。本文给出一张可直接套用的检查表，每项都配可判断的通过标准和证据要求。
要点总览（TL;DR）
- 检查表分两部分：检查项判断覆盖是否成立，记录列记录缺口如何定位、判断和关闭。
- 检查项按需求覆盖、用例覆盖、执行覆盖、缺陷与风险覆盖、回归覆盖五个阶段展开，每项配可判断的通过标准和证据要求。
- 记录列至少包含需求编号、用例编号、版本号、模块、覆盖状态、缺口类型、影响范围、风险等级、是否阻断发布、负责人、检查时点、用例链接、执行记录、关闭条件。
- 核心需求未覆盖且无不测理由、高风险模块计划用例未执行、阻断级缺陷未关闭且无回归用例，属于阻断发布项。
- 检查表完成需满足必填记录列无空缺、阻断项清零或经评审豁免、每个未关闭缺口都有负责人和关闭条件。
谁在什么时点使用这张检查表
这张检查表服务于覆盖判定，不承担研发流程审计的职责。使用前先明确角色分工和检查时点，可以避免同一张表在不同环节被反复填写、结论互相矛盾。
| 使用角色 | 主要动作 | 对应时点 |
|---|---|---|
| 测试负责人 | 组织检查、判定阻断项、确认豁免 | 提测前、版本发布前 |
| 用例设计者 | 核对需求与用例的对应关系，补充缺失场景 | 用例评审前 |
| 执行测试人员 | 填写执行状态、未执行说明和缺陷单号 | 提测后至回归收尾 |
| 需求方代表 | 确认“不测”理由是否成立，参与豁免评审 | 用例评审前、发布前 |
四个时点的检查重点不同：用例评审前看需求覆盖和用例覆盖是否成立；提测前看用例是否就绪、执行计划是否分配；版本发布前看执行覆盖、缺陷与风险覆盖是否达标；回归收尾看变更影响范围和回归集是否更新。判定范围到此为止，插桩实现、覆盖率工具源码以及需求到研发全链路的追溯管理不在本文展开，后者属于需求追溯与覆盖管理的范畴。
分阶段检查项：从需求到回归逐项核对
检查项按五个阶段组织，每项只回答一个可以判断“是或否”的覆盖问题。勾选前先看通过标准，标准不满足时勾选无效。
| 阶段 | 检查项 | 通过标准 | 证据 | 负责人 | 检查时点 |
|---|---|---|---|---|---|
| 需求覆盖 | 每条需求是否有对应用例或明确的不测理由 | 需求清单中每条需求都能指向至少一个用例，或指向一条经需求方确认的不测理由 | 需求与用例关联记录、不测理由说明 | 用例设计者 | 用例评审前 |
| 需求覆盖 | 新增或变更需求是否已进入本次覆盖范围 | 变更单中的需求均有覆盖结论，无“待补充”状态遗留 | 变更记录、覆盖结论 | 测试负责人 | 提测前 |
| 用例覆盖 | 正常场景是否覆盖 | 每条需求的主流程至少有一个正向用例 | 用例链接 | 用例设计者 | 用例评审前 |
| 用例覆盖 | 异常、边界场景是否覆盖 | 需求涉及的输入校验、失败分支、临界值均有对应用例或说明不适用 | 用例链接、不适用说明 | 用例设计者 | 用例评审前 |
| 用例覆盖 | 权限与兼容场景是否覆盖 | 涉及多角色权限或指定终端、浏览器、系统版本的需求，有对应用例或明确排除理由 | 用例链接、兼容范围说明 | 用例设计者 | 用例评审前 |
| 执行覆盖 | 计划用例是否全部执行 | 计划内用例执行状态无“未开始”，执行率可统计 | 执行记录 | 执行测试人员 | 版本发布前 |
| 执行覆盖 | 未执行项是否有说明 | 每条未执行用例都写明原因、责任人和补测计划 | 未执行说明 | 执行测试人员 | 版本发布前 |
| 缺陷与风险覆盖 | 缺陷修复是否补用例 | 每个已修复缺陷都关联回归用例，或注明无需补用例的理由 | 缺陷单、关联用例 | 执行测试人员 | 回归收尾 |
| 缺陷与风险覆盖 | 高风险模块是否加测 | 风险清单中的高等级模块有用例增量或专项测试记录 | 风险清单、加测记录 | 测试负责人 | 版本发布前 |
| 回归覆盖 | 变更影响范围是否识别 | 每个变更点都列出受影响模块，并对应回归用例 | 影响范围分析记录 | 测试负责人 | 提测前 |
| 回归覆盖 | 回归集是否更新 | 本次新增或修改的用例已纳入回归集，旧用例已清理失效项 | 回归集版本记录 | 用例设计者 | 回归收尾 |
表中“不测”与“不适用”是两种不同结论：不测指需求方确认本次不验证，不适用指该场景在本次变更中不存在。两者都要留下书面理由，否则按未覆盖处理。
记录列：缺口如何被写清楚
记录列的作用是让每个缺口都能被定位、判断和关闭。字段按标识、状态、判断、责任、证据、关闭六类组织，必填字段空缺时该行记录视为无效。
| 类别 | 字段名 | 填写说明 | 必填/选填 | 示例值 |
|---|---|---|---|---|
| 标识 | 需求编号 | 填写需求管理系统中的唯一编号 | 必填 | REQ-1042 |
| 标识 | 用例编号 | 对应用例的唯一编号，无对应用例时填“无” | 必填 | TC-2087 |
| 标识 | 版本号 | 本次检查对应的提测或发布版本 | 必填 | V3.6.0 |
| 标识 | 模块 | 需求所属功能模块 | 必填 | 订单结算 |
| 状态 | 覆盖状态 | 在已覆盖、部分覆盖、未覆盖、不测四个取值中选择 | 必填 | 部分覆盖 |
| 状态 | 缺口类型 | 标明缺的是用例、执行、缺陷回归还是回归集更新 | 必填 | 缺异常场景用例 |
| 判断 | 影响范围 | 说明缺口影响的功能、用户角色或数据范围 | 必填 | 影响退款金额校验 |
| 判断 | 风险等级 | 按团队约定分级，与阻断判断挂钩 | 必填 | 高 |
| 判断 | 是否阻断发布 | 填是或否，填是时须在阻断项清单中登记 | 必填 | 是 |
| 责任 | 负责人 | 缺口关闭的第一责任人 | 必填 | 张工 |
| 责任 | 检查时点 | 记录本次检查发生的阶段 | 必填 | 版本发布前 |
| 责任 | 复核人 | 对覆盖结论做二次确认的人 | 选填 | 李工 |
| 证据 | 用例链接 | 可打开的用例地址，无用例时填不测理由文档 | 必填 | 用例库链接 |
| 证据 | 执行记录 | 执行结果或测试计划链接 | 必填 | 测试计划链接 |
| 证据 | 缺陷单号 | 关联缺陷的编号，无缺陷时填“无” | 选填 | BUG-3311 |
| 证据 | 评审记录 | 用例评审或不测理由确认的记录链接 | 选填 | 评审纪要链接 |
| 关闭 | 关闭条件 | 写明满足什么条件可以关闭该缺口 | 必填 | 补充异常用例并通过评审 |
| 关闭 | 关闭日期 | 实际关闭时间，未关闭时留空 | 选填 | 2025-03-18 |
| 关闭 | 遗留说明 | 转入下个版本或长期保留的缺口，写明处理安排 | 选填 | 转入 V3.7 补测 |
记录列落地时，需求、用例、缺陷和评审记录往往分散在不同系统中，手工维护容易断链。ONES 测试管理支持用例与产品需求、研发任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，用例属性支持自定义和筛选。团队可以把覆盖状态、缺口类型等字段配置成用例属性，让检查表的记录列与实际工作项保持同一份数据，减少重复誊写。
通过标准与证据：每项如何判断合格
判断合格的关键是证据可核验，而不是勾选动作本身。覆盖类检查项看对应关系是否成立，执行类检查项看数据是否齐全，记录列看字段是否完整、取值是否在约定范围内。
| 检查类别 | 通过标准 | 证据要求 |
|---|---|---|
| 需求覆盖 | 需求与用例可一一对应，或有不测理由且经需求方确认 | 关联记录可打开，不测理由有确认人和日期 |
| 用例覆盖 | 正常、异常、边界、权限、兼容场景均有对应用例或明确排除说明 | 用例链接有效，排除说明写明依据 |
| 执行覆盖 | 计划用例执行完毕，未执行项均有原因和补测安排 | 执行记录可统计，未执行说明逐条对应 |
| 缺陷与风险覆盖 | 已修复缺陷有回归用例，高风险模块有加测记录 | 缺陷单与用例双向可查，加测记录有结论 |
| 回归覆盖 | 变更影响范围已识别，回归集已更新 | 影响范围分析有版本记录，回归集有变更日志 |
| 记录列完整性 | 必填字段无空缺，覆盖状态取值在约定范围内 | 抽查记录行，字段值与实际工作项一致 |
抽样复核建议按模块或风险等级分层进行：高风险模块全量核对，中低风险模块按比例抽取，每个阶段至少复核一次。复核发现记录与实际不符时，以实际工作项为准修正记录，并追溯该行此前的判断是否受到影响。评审类证据要有明确结论，只写“已评审”而无结论的记录不计为有效证据。
阻断项与完成条件：什么情况下不能放行
阻断项是发布前必须清零或经评审豁免的条目。以下三类属于阻断项：核心需求未覆盖且无不测理由；高风险模块的计划用例未执行且无补测安排；阻断级缺陷未关闭且没有对应回归用例。出现任一条，版本不放行。
低风险模块部分覆盖、遗留缺口已有明确责任人和计划的情况，属于非阻断但需记录项，写入遗留说明并纳入下个版本的检查范围即可。检查表整体完成需同时满足：所有必填记录列填写完整；阻断项清零或经评审豁免；每个未关闭缺口都有负责人和关闭条件。
| 判定项 | 处理方式 | 记录要求 |
|---|---|---|
| 核心需求未覆盖且无不测理由 | 阻断发布 | 登记缺口行，补齐用例或取得需求方确认 |
| 高风险模块计划用例未执行 | 阻断发布 | 写明未执行原因与补测时间 |
| 阻断级缺陷未关闭且无回归用例 | 阻断发布 | 关联缺陷单，补充回归用例 |
| 低风险模块部分覆盖 | 记录后放行 | 写明责任人与计划完成时间 |
| 遗留缺口转入下版本 | 记录后放行 | 写明遗留说明与承接版本 |
豁免需要留下完整记录：豁免人、豁免理由、豁免期限三项缺一不可。豁免期限到期后，该缺口重新进入检查范围，按新版本重新判定是否阻断。测试负责人可在发布前用测试报告汇总执行情况和缺陷分布，作为阻断判定的依据；ONES 测试管理支持自动生成测试报告并提供项目缺陷分布统计，便于把检查结论与版本质量数据放在一起评审。
常见问题
需求方确认“本次不测”后，这条需求还需要在检查表里记录吗？
需要记录。不测属于覆盖结论的一种，记录列中覆盖状态填“不测”，并写明需求方确认人、确认日期和不测理由。检查表按未覆盖处理的情形是既没有对应用例、也没有经确认的不测理由。把不测理由留档，后续版本重新评估覆盖范围时可以直接复用这条判断。
用例执行到一半发现需求变更，检查表应该怎么处理？
先更新需求覆盖和用例覆盖两段检查项：把变更后的需求重新对照用例，补充或调整用例，并在记录列中更新需求编号、用例编号和覆盖状态。已执行但对应旧需求的用例，执行记录保留，覆盖结论按新需求重新判定。变更影响范围同时进入回归覆盖检查，确认回归集是否需要同步更新。
低风险模块的覆盖缺口可以带着发布吗？
可以，但要满足记录条件：缺口行填写负责人、关闭条件和计划完成时间，并在遗留说明中写明承接版本。这类缺口属于非阻断但需记录项，发布前由测试负责人确认记录完整即可放行。如果缺口涉及核心需求或高风险模块，则按阻断项处理，需要补齐用例或经评审豁免后才能发布。
豁免记录需要写哪些内容，豁免到期后怎么办？
豁免记录至少包含豁免人、豁免理由和豁免期限三项，缺一项视为记录不完整。豁免期限到期后，该缺口重新进入检查范围，按当前版本的覆盖情况重新判定是否阻断。建议在检查表中保留原豁免记录，并新增一条到期复核记录，避免历史结论被覆盖后无法追溯。
检查表的记录列能不能直接放在测试管理工具里维护？
可以。把覆盖状态、缺口类型、风险等级等配置成用例或工作项的自定义属性，检查表记录与实际用例、缺陷保持同一份数据，能减少手工誊写和状态不一致。ONES 测试管理支持自定义用例属性并支持筛选，用例可与产品需求、研发任务关联，未通过的用例可快速创建缺陷任务，测试报告可自动生成并汇总缺陷分布，便于把检查结论和版本质量数据放在一起评审。
