测试覆盖缺口检查清单要回答两个问题：查哪些项、记哪些字段。检查项围绕需求条目、验收标准、测试用例、执行结果、缺陷与风险五类对象展开；记录字段则要保证每条缺口都能被独立复核，包括对象标识、覆盖判定、缺口描述、影响范围、证据链接、负责人、检查时点和关闭条件。这份清单适合在用例评审前、提测前、发布评审前和缺陷关闭复核时使用，只判断测试覆盖是否充分，不涉及插桩实现与覆盖工具源码，需求到研发全链路的追溯管理由其他主题承担。缺口记录需要落到工作项和文档中留痕时，ONES 的测试管理与知识库可以作为承载方式。
要点总览（TL;DR）
- 清单围绕需求、用例、执行、缺陷四层设置检查项，每项配通过标准、证据形式、负责人、检查时点和阻断标记，可直接作为核查工作表使用。
- 记录字段分必填与选填：对象标识、覆盖判定、缺口描述、影响范围、证据链接、负责人、检查时点、关闭条件为必填，覆盖判定只用已覆盖、部分覆盖、未覆盖三档。
- 核心需求未覆盖、验收标准无对应用例、阻断级缺陷未复测、执行记录缺失四类为阻断项，未关闭前不得判定覆盖通过。
- 完成条件为阻断项全部关闭并有复核记录、缺口记录必填字段完整、复核人签字确认；未关闭时只能延期发布或缩小范围并留痕。
- 缺口记录可作为工作项与需求、用例、缺陷关联，检查结论在文档中留痕，按用例评审前、提测前、发布评审前、缺陷关闭复核四个时点组织。
谁在什么时点使用这份清单
这份清单不是测试团队内部的备忘录，而是多个角色在关键节点共同使用的判定工具。不同角色关注的检查对象不同，使用时点也不同，提前约定清楚可以避免检查流于形式。
| 角色 | 使用时点 | 主要职责 |
|---|---|---|
| 用例设计者 | 用例评审前 | 自查每条需求与验收标准是否有对应用例，补齐异常流、边界值等场景 |
| 测试负责人 | 提测前、发布评审前 | 组织逐项核查，汇总缺口记录，判定阻断项是否关闭 |
| 需求负责人 | 用例评审前、缺口确认时 | 确认需求条目与验收标准的完整性，对缺口影响范围给出业务判断 |
| 发布评审人 | 发布评审前 | 依据清单结论决定是否放行，对带条件通过的情形签字确认 |
适用边界需要写进清单抬头：本清单只判断测试覆盖是否充分，检查对象是需求、用例、执行记录和缺陷；插桩实现、覆盖工具源码、覆盖率工具的技术选型不在检查范围内。需求条目与用例之间的链路追溯由需求追溯管理主题负责，本清单只引用追溯结果作为证据，不重复建设追溯体系。
准备阶段：先把检查对象和字段备齐
逐项核查开始前，必须先确认输入材料齐全、字段模板已下发。缺少输入时强行检查，得到的结论无法复核。
必备输入包括五类：需求清单（含需求编号与优先级）、验收标准（逐条可验证的表述）、用例库（含用例编号与关联需求）、执行记录（含执行结果与执行时间）、缺陷列表（含缺陷状态与严重程度）。这五类材料分别对应后续四个层次的检查项，缺任何一类都会导致对应检查项无法判定。
记录字段模板在准备阶段统一下发，字段口径如下：
| 字段 | 填写口径 | 是否必填 |
|---|---|---|
| 对象标识 | 需求编号、用例编号或缺陷单号，保证可定位到唯一对象 | 必填 |
| 覆盖判定 | 只使用“已覆盖 / 部分覆盖 / 未覆盖”三档，不写模糊描述 | 必填 |
| 缺口描述 | 说明缺什么场景、缺哪条验收标准，一句话可读 | 必填 |
| 影响范围 | 涉及的功能模块、用户角色或发布范围 | 必填 |
| 证据链接 | 指向用例、执行记录或缺陷单的链接或编号 | 必填 |
| 负责人 | 缺口关闭的责任人，具体到人 | 必填 |
| 检查时点 | 本次检查所处的阶段：用例评审前、提测前、发布评审前或缺陷关闭复核 | 必填 |
| 关闭条件 | 写明补齐用例、复测通过或评审确认等可验证的关闭标准 | 必填 |
准备阶段的通过条件是：五类输入齐全且版本一致，字段模板已下发给所有参与角色，检查分工已明确到人。三项都满足才进入逐项核查。
分阶段检查项：从需求到执行逐层核对
检查项按需求、用例、执行、缺陷四个层次组织，每层设置可判断的通过标准和证据形式。下表可直接作为核查工作表使用。
| 层次 | 检查项 | 通过标准 | 证据形式 | 负责人 | 检查时点 | 阻断标记 |
|---|---|---|---|---|---|---|
| 需求层 | 每条需求是否有对应用例 | 需求清单中每条需求至少关联一条用例，无孤立需求 | 需求与用例的关联记录 | 用例设计者 | 用例评审前 | 核心需求未覆盖为阻断 |
| 需求层 | 验收标准是否逐条映射 | 每条验收标准都能找到对应用例或明确标注不适用及理由 | 验收标准与用例的映射表 | 需求负责人 | 用例评审前 | 验收标准无对应用例为阻断 |
| 用例层 | 正常流是否覆盖 | 每条需求的主流程至少一条正向用例 | 用例库中的正向用例 | 用例设计者 | 用例评审前 | 非阻断 |
| 用例层 | 异常流与边界值是否覆盖 | 关键需求的异常分支和边界条件有用例，或记录不覆盖的理由 | 用例库中的异常与边界用例 | 用例设计者 | 用例评审前 | 核心需求缺失为阻断 |
| 用例层 | 权限与兼容场景是否覆盖 | 涉及多角色权限或指定终端、浏览器范围的需求有对应用例 | 权限矩阵、兼容范围说明及用例 | 测试负责人 | 提测前 | 非阻断，可带条件通过 |
| 执行层 | 用例是否执行 | 计划内用例均有执行状态，未执行项有原因记录 | 执行记录 | 测试负责人 | 发布评审前 | 执行记录缺失为阻断 |
| 执行层 | 结果是否记录、失败项是否有缺陷单 | 失败用例均关联缺陷单，无悬空失败项 | 执行结果与缺陷单关联记录 | 测试负责人 | 发布评审前 | 阻断级失败无缺陷单为阻断 |
| 缺陷层 | 缺陷是否复测 | 已修复缺陷有复测记录和结论 | 缺陷单中的复测记录 | 测试负责人 | 缺陷关闭复核 | 阻断级缺陷未复测为阻断 |
| 缺陷层 | 回归范围是否明确 | 每个修复缺陷标注回归范围，回归用例已执行 | 缺陷单中的回归范围与执行记录 | 测试负责人 | 缺陷关闭复核 | 非阻断 |
使用这张表时，每一行都要落到具体对象编号，不能只勾选“已检查”。例如需求层第一项，证据形式应写成“需求 PRD-012 关联用例 TC-045、TC-046”，而不是“已关联”。
缺口记录字段怎么填：一份可核验的记录格式
缺口记录是清单的核心产物，每条记录都要能被另一个不参与检查的人独立复核。必填字段保证可定位、可判断、可追责，选填字段补充处置信息。
| 字段 | 说明 | 必填/选填 |
|---|---|---|
| 缺口编号 | 唯一编号，便于在评审和复盘中引用 | 必填 |
| 关联需求或用例 | 写明需求编号或用例编号，指向具体对象 | 必填 |
| 缺口类型 | 需求未覆盖、验收标准未映射、场景缺失、执行缺失、缺陷未复测等 | 必填 |
| 影响范围 | 功能模块、用户角色、发布范围 | 必填 |
| 严重程度 | 阻断、严重、一般三档，与阻断项判定挂钩 | 必填 |
| 发现人 | 具体到人 | 必填 |
| 发现时点 | 检查阶段与日期 | 必填 |
| 建议补充用例 | 给出可执行的补测方向 | 选填 |
| 预计关闭时间 | 与发布计划对齐 | 选填 |
| 关联缺陷单 | 已有缺陷单时填写单号 | 选填 |
填写示例：缺口编号 GAP-007；关联需求 PRD-023“订单退款审批”；缺口类型为验收标准未映射；影响范围为退款审批模块、财务角色；严重程度为阻断；发现人为测试负责人张某；发现时点为提测前检查，2025 年 3 月 10 日；缺口描述为“验收标准第 3 条‘超时未审批自动升级’无对应用例”；证据链接指向需求文档对应条目；负责人为用例设计者李某；关闭条件为“补充升级场景用例并评审通过”。
常见填写错误有三类：只写“覆盖不足”而不写对象标识，导致无法定位；覆盖判定写成“基本覆盖”“差不多”，脱离三档口径；证据链接指向整个用例库而非具体用例，复核时无法确认。发现这类记录应退回重填，不计入已关闭缺口。
阻断项与完成条件：什么情况下不能判定通过
清单需要明确哪些条目一旦不满足就不能判定覆盖通过。阻断项设置四类：核心需求未覆盖、验收标准无对应用例、阻断级缺陷未复测、执行记录缺失。这四类问题直接决定发布质量底线，未关闭前不得在评审结论中写“覆盖通过”。
非阻断项包括权限与兼容场景的部分缺失、非核心需求的异常流缺失、一般缺陷的回归范围记录不完整等。这类问题可以带条件通过，条件要写清楚：补齐时限、责任人、补测范围，并在发布评审记录中留痕。
整份清单的完成条件有三条：阻断项全部关闭并有复核记录；所有缺口记录的必填字段完整；复核人签字确认。三条同时满足才算完成。存在未关闭阻断项时，处置方式只有两种：延期发布，或缩小发布范围并在记录中写明被排除的功能与对应缺口编号。缩小范围的决定需要发布评审人确认，不能由测试团队单方面判定。
把清单落到协作流程里：记录、复核与留痕
清单要真正发挥作用，缺口记录需要作为工作项登记，并与需求、用例建立关联，检查结果需要在文档中留痕，复核与关闭状态需要可流转、可查询。
在 ONES 中，测试用例可以与产品需求、研发任务关联，测试计划与迭代关联，形成测试流程闭环；未通过的用例可以快速创建缺陷任务，缺陷任务在测试与研发团队之间流转。这意味着清单中的“关联需求或用例”“关联缺陷单”字段可以直接指向系统中的工作项，缺口记录不必另建一套编号体系。检查结果和评审结论可以在知识库文档中留痕，评审时按清单逐项确认，复核人依据缺口记录的关闭条件逐条核对后变更状态。ONES 测试管理还支持为不同用户组配置权限、为用例库和测试计划单独配置权限，便于把复核与关闭操作限定在相应角色。测试报告可自动生成并支持自定义模板，可作为发布评审的附件材料。
落地时建议按四个时点组织：用例评审前由用例设计者自查并登记缺口；提测前由测试负责人汇总阻断项；发布评审前由发布评审人依据清单结论决定放行方式；缺陷关闭复核时由测试负责人确认复测记录并关闭缺口工作项。每个时点的检查结果都保留在文档或工作项中，下一次迭代可以直接复用这份清单作为模板。
常见问题
清单里的覆盖判定只有三档，遇到“大部分覆盖”这类情况怎么处理？
三档口径的目的是让判定可复核，遇到介于两者之间的情况，按缺口是否影响验收标准来归类：验收标准能全部找到对应用例的记为已覆盖；验收标准部分条目无对应用例的记为部分覆盖，并在缺口描述中写明缺哪几条；整条需求无对应用例的记为未覆盖。不要新增“基本覆盖”“大部分覆盖”等中间档，否则不同人填出的结论无法比较。如果确实需要更细的区分，可以在缺口描述里补充缺失比例或缺失条目编号，判定字段仍保持三档。
需求在检查过程中发生变更，已经填好的缺口记录怎么处理？
需求变更后，原缺口记录不应直接删除，而应保留并标注失效原因，同时按变更后的验收标准重新核对一次。具体做法是：在缺口记录中补充变更说明和变更后的需求版本号，将原记录状态改为已失效或已重开，再针对新版本重新判定覆盖情况。如果变更导致原缺口不再成立，关闭条件改为“需求变更后重新核对确认”；如果变更扩大了范围，则按新范围补充检查项和缺口记录。这样在发布评审时能看清每条缺口的来龙去脉，避免出现记录与实际需求对不上的情况。
非阻断项带条件通过后，条件没有按期完成怎么办？
带条件通过的前提是条件可验证、有时限、有责任人。到了约定时限仍未完成时，应把该条目重新提交发布评审，由评审人判断是升级为阻断项、继续延期，还是调整发布范围。处理结果要写回缺口记录，包括新的关闭条件、责任人和时限，并在评审记录中留痕。实践中容易出问题的是条件写得含糊，例如“后续补齐”，这类条件无法判断是否完成，应在填写时就改成“某日期前补充某场景用例并通过评审”这样的可验证表述。
小团队人手有限，这份清单能否简化使用？
可以按风险裁剪，但裁剪的是检查项的覆盖广度，不是记录字段的完整性。建议保留四类阻断项和必填字段，这是判定能否放行的底线；用例层的权限与兼容场景、缺陷层的回归范围记录等非阻断项，可以根据本次发布涉及的范围决定是否展开。角色也可以合并，例如用例设计者与测试负责人由同一人承担，但自查与复核两个动作仍要分开做，并在记录中体现检查时点。团队规模、发布频率不同，清单的展开程度可以不同，判定口径保持一致即可。
缺口记录放在工作项里还是放在文档里更合适？
两者承担的作用不同，通常配合使用。缺口需要有人跟进关闭、需要与需求或用例关联、需要变更状态时，放在工作项里更合适，状态流转和责任人一目了然；检查结论、评审意见、按清单逐项确认的过程记录，放在文档里更便于评审时对照阅读和后续复用为模板。在 ONES 中，测试用例可以与产品需求、研发任务关联，未通过的用例可以创建缺陷任务并在测试与研发团队间流转，检查结论可在知识库文档中留痕，两类载体可以互相引用。关键是缺口编号在两边保持一致，避免同一缺口出现两套记录。
