测试覆盖与需求验证的核心，是把每条需求拆成可验证的验收条件，再为每个条件指定测试用例、执行结果和判定证据，最后按“需求—验收条件—用例—执行结果”四层核对覆盖情况。落地时先确定覆盖判定口径，再明确需求负责人、测试负责人和评审人的分工，用一张覆盖核对表逐条记录状态，以未覆盖项清零或书面豁免作为完成标志。本文围绕这套流程展开，涉及需求与测试状态在同一处流转时，可借助ONES承载需求条目、用例与执行结果的对应关系。
要点总览（TL;DR）
- 先书面确认覆盖判定口径：按需求条目、按验收条件或按风险等级，三种口径的粒度与适用项目不同，口径变更需留痕。
- 把每条需求拆成可观察、有前提、单一意图、可正可反的验收条件，并与需求负责人逐条确认，形成需求—验收条件对照清单。
- 用覆盖核对表逐条记录需求编号、验收条件、用例编号、执行状态、证据与豁免原因，状态只取未执行、通过、失败、阻塞四个值。
- 需求负责人、测试负责人、评审人分别负责条件确认、用例与核对表维护、评审与豁免批准，三个交接节点都要留记录。
- 完成标志是未覆盖项清零或有书面豁免，失败项复测通过，需求变更已同步，评审人对照清单给出结论并留痕。
先定口径：测试覆盖按什么单位判定
测试覆盖的第一步是统一“覆盖”的计量单位。同一批用例，按需求条目统计可能显示全部覆盖，按验收条件统计却可能暴露出若干条件从未被执行。口径不统一，覆盖率的数字就失去比较意义，评审时也容易各说各话。因此，动手建表之前，团队应先书面确认采用哪一种口径，并写明选择理由。
常见的三种口径差别如下：
| 判定口径 | 计量单位 | 优点 | 局限 | 适用项目类型 |
|---|---|---|---|---|
| 按需求条目 | 一条需求是否至少有一个用例执行通过 | 统计简单，适合向上汇报进度 | 粒度粗，一条需求内的多个条件可能被一个用例“代表” | 需求条目少、变更频繁的迭代型项目 |
| 按验收条件 | 每个验收条件是否有对应用例且执行有结论 | 粒度细，能定位到具体未验证点 | 维护成本较高，需要先完成条件拆分 | 需求质量要求高、验收严格的项目，如对外交付、合规相关系统 |
| 按风险等级 | 高、中、低风险需求分别设定覆盖要求 | 资源投入与风险匹配，避免平均用力 | 风险评级本身需要依据，评级偏差会传导到覆盖结论 | 需求量大、资源有限、核心链路与边缘功能差异明显的项目 |
选择口径时可参考两条依据：一是需求本身的可拆解程度，验收条件能写清楚的项目适合按条件判定；二是交付风险的集中度，核心交易、资金、权限类需求适合叠加风险等级要求。三种口径也可以组合使用，例如整体按验收条件统计，同时对高风险需求额外要求用例评审记录。
口径确定后应形成一份简短的说明文档，写明选定单位、统计规则（例如“执行通过”是否包含已知缺陷挂起的情况）、适用项目范围和生效时间，由需求负责人与测试负责人共同确认。口径变更需要留痕，避免中途换算法导致前后数据不可比。
从需求到验收条件：拆出可验证的条目
验收条件是覆盖核对的最小对象，它的质量直接决定后续核对能否进行。拆解时的输入是需求描述、业务规则说明和相关的界面或接口约定；动作是把需求中的每一条业务意图转写成“在什么前提下、执行什么操作、得到什么可观察结果”的陈述；输出是一份需求—验收条件对照清单，每条条件有独立编号并挂回原需求。
一条合格的验收条件通常具备以下特征：
- 可观察：结果能通过界面、接口返回、日志或数据状态直接看到，避免“体验流畅”“性能良好”这类无法判定的表述。
- 有前提：写明初始数据状态、用户权限或环境条件，使不同人执行时结论一致。
- 单一意图：一条条件只验证一个业务规则，便于定位失败原因，也便于单独标记覆盖状态。
- 可正可反：关键规则同时给出正常路径与异常路径的条件，例如金额校验既要覆盖合法输入，也要覆盖超限输入。
拆分粒度以“能被一个或一组用例完整验证”为准。粒度过粗会让覆盖状态含糊，过细则会产生大量重复条件，增加维护负担。拆分完成后需要与需求负责人逐条确认：条件是否完整表达了需求意图、是否存在遗漏的业务分支、异常场景是否覆盖到位。确认后的清单即作为后续用例设计与覆盖核对的基准，需求变更时同步更新并标注版本。
建立覆盖核对表：字段与填写规则
覆盖核对表是把口径和验收条件落到可追踪记录上的载体。表以验收条件为行，逐条记录其验证状态，结构建议如下：
| 字段 | 填写内容 | 填写规则 |
|---|---|---|
| 需求编号 | 需求管理系统中的唯一标识 | 与需求条目一一对应，不手写临时编号 |
| 验收条件 | 条件编号与简述 | 编号规则固定，如“需求号-序号” |
| 用例编号 | 覆盖该条件的测试用例标识 | 一个条件可对应多条用例，全部列出 |
| 执行状态 | 未执行 / 通过 / 失败 / 阻塞 | 只取这四个值，失败与阻塞需在备注说明原因 |
| 证据 | 执行记录、截图、日志或报告链接 | 失败与阻塞项必须附证据，通过项按项目要求留存 |
| 豁免原因 | 不验证的理由与批准人 | 仅在评审批准后填写，写明批准日期 |
| 更新人 / 更新时间 | 最近一次修改的责任人与日期 | 每次状态变化都要更新，保留可追溯性 |
填写责任按字段划分：用例编号与执行状态由测试执行人维护，验收条件内容由需求负责人确认，豁免原因由评审人批准后由测试负责人登记。更新时点建议固定在三个节点——用例设计完成时填入用例编号，每轮测试执行后更新状态与证据，版本发布前完成全表复核。状态取值要保持稳定，避免出现“基本通过”“待观察”这类无法统计的中间态；确有未决事项时，用阻塞状态加备注表达。
当需求、用例与执行结果分散在不同工具中时，核对表的维护成本主要来自手工同步。ONES的需求管理与测试管理可以将需求条目、测试用例与执行结果关联在同一工作项体系内，使覆盖核对表中的状态能够随执行进展更新，减少跨表比对的工作量；具体字段配置需按团队实际流程设定。
角色分工与交付物
覆盖验证涉及三类角色，职责与交付物需要事先写清，避免出现“需求改了没人通知测试”“豁免没人拍板”的情况。
| 角色 | 主要职责 | 输入 | 输出 |
|---|---|---|---|
| 需求负责人 | 确认验收条件完整、准确；需求变更时同步更新条件并通知测试 | 需求描述、业务规则 | 确认后的需求—验收条件对照清单、变更记录 |
| 测试负责人 | 设计并分配用例；维护覆盖核对表；组织覆盖评审；判定完成状态 | 验收条件清单、测试环境 | 用例集、覆盖核对表、覆盖评审结论 |
| 评审人 | 审核验收条件与用例的对应关系；批准豁免；确认完成标准达成 | 覆盖核对表、执行证据 | 评审意见、豁免批准记录、完成确认 |
交接时点有三个关键节点：验收条件确认后，需求负责人向测试负责人移交清单，测试侧据此设计用例；用例执行完成后，测试负责人向评审人提交覆盖核对表与证据；发布前，评审人对照完成标准给出通过或返工结论。每个节点的交接都应有记录，注明移交内容、时间和接收人，使责任链条完整可查。
示例：一条需求的覆盖验证全过程
以下为演示情景，用于说明流程如何连续走通。需求为“用户提交报销单时，系统校验单笔金额不超过5000元，超限时提示并阻止提交”。
第一步，拆验收条件。需求负责人与测试负责人共同拆出三条条件：条件1，金额为5000元时提交成功；条件2，金额为5000.01元时提交被阻止并显示超限提示；条件3，金额为空或非数字时提交被阻止并提示格式错误。
第二步，设计用例并登记。测试人员为条件1设计用例TC-101（边界值5000元），为条件2设计TC-102（边界外5000.01元），为条件3设计TC-103（空值）与TC-104（字母输入），全部填入覆盖核对表的用例编号列。
第三步，执行并记录。第一轮执行中，TC-101通过并留存提交成功截图；TC-102失败，系统未阻止提交，附接口返回与截图作为证据；TC-103通过；TC-104阻塞，因测试环境表单校验脚本未部署，备注环境原因。此时条件2状态为失败，条件3部分阻塞。
第四步，修复与复测。开发修复金额校验逻辑后，测试人员复测TC-102，状态更新为通过并替换证据；环境修复后执行TC-104，通过。全表复核时三条条件均为通过，无豁免项，该需求覆盖验证完成。若某条件因业务调整确认不再需要验证，则由需求负责人提出、评审人批准后在豁免原因列登记理由与日期，该条件方可视为已处理。
完成检查：覆盖验证何时算通过
覆盖验证的完成标准应写成可逐项核对的清单，而不是笼统的“测试完成”。建议在发布前按以下条目检查：
- 覆盖核对表中每条验收条件都有明确状态，不存在空白或未执行项。
- 所有失败项已完成修复并复测通过，状态与证据同步更新。
- 未覆盖项要么清零，要么有评审人批准的书面豁免，豁免原因与批准日期齐全。
- 执行证据按项目要求留存，失败与阻塞项的证据可回溯到具体执行记录。
- 需求变更已同步到验收条件与用例，变更记录与核对表版本一致。
- 评审人已对照上述条目给出完成结论并留痕。
出现以下情况应阻断发布并返工：存在无状态的验收条件；失败项未复测即被标记通过；豁免未经评审批准或理由无法对应到具体条件；需求已变更但核对表未更新，导致覆盖结论基于过期条件。返工后需重新执行受影响条件的用例，并再次走完复核流程，确认清单全部满足后方可判定通过。
常见问题
需求条目很多、测试资源有限时，覆盖口径怎么选才不至于平均用力？
可以整体按验收条件统计，同时对高风险需求叠加更严格的覆盖要求，例如核心交易、资金、权限类需求额外要求用例评审记录。风险评级本身要有依据，评级偏差会直接传导到覆盖结论，因此评级标准应事先写明并由需求负责人与测试负责人共同确认。资源紧张时优先保证高风险条件的用例执行与证据留存，低风险条件可按项目约定简化证据要求，但状态仍需如实填写。
验收条件拆分到什么程度算合适？拆得太细会不会增加维护负担？
以“能被一个或一组用例完整验证”为准。一条条件只验证一个业务规则，便于定位失败原因和单独标记覆盖状态；粒度过粗会让覆盖状态含糊，过细则产生大量重复条件。关键规则同时给出正常路径与异常路径的条件。拆分完成后与需求负责人逐条确认完整性与业务分支覆盖情况，确认后的清单作为用例设计与覆盖核对的基准，需求变更时同步更新并标注版本。
执行状态里出现“基本通过”“待观察”这类中间态怎么处理？
建议把状态取值固定为未执行、通过、失败、阻塞四个值，避免出现无法统计的中间态。确有未决事项时，用阻塞状态加备注说明原因，例如环境未就绪、依赖未部署。失败与阻塞项必须附证据，备注写清具体原因和后续动作。状态取值稳定后，覆盖核对表才能直接用于统计和评审，前后轮次的数据也具备可比性。
需求在中途变更了，已经填好的覆盖核对表怎么衔接？
需求变更时由需求负责人同步更新验收条件并通知测试负责人，核对表相应行标注版本或变更记录。受影响的用例需要重新执行，不能沿用变更前的执行结论。发布前复核时，若发现需求已变更但核对表未更新，应作为阻断项处理，返工后重新走完受影响条件的用例执行与复核流程。变更留痕的目的，是让覆盖结论始终基于当前有效的验收条件。
豁免是不是意味着这条需求可以不验证？豁免需要谁批准、记录什么？
豁免表示该验收条件经评审确认不再需要验证，属于已处理状态，与遗漏不同。流程上由需求负责人提出，评审人批准后由测试负责人在豁免原因列登记理由与批准日期，理由要能对应到具体条件。未经评审批准的未覆盖项不能视为已处理，发布前应作为阻断项返工。豁免记录与执行证据一并留存，便于后续回溯当时的判定依据。
