需求验证要回答的是“这条需求是否被满足”，判定依据来自可检验的验收条件，完成标志是每条需求都有覆盖结论和证据。本文按拆条件、建映射、判覆盖、处置未覆盖项的顺序给出操作步骤，并说明需求方、开发、测试的交付物；需求条目、用例与执行结果可以在ONES中关联管理。
要点总览（TL;DR）
- 需求验证验证的是需求是否被满足，判定依据是带预期结果的验收条件，完成标志是每条需求都有覆盖结论和证据。
- 把需求按正常路径、边界、异常、权限、约束条件拆成编号的验收条件，经需求方确认后作为后续判定基准。
- 每条验收条件至少对应一条用例，用例标注条件编号，形成需求—条件—用例的可核查对应关系。
- 覆盖判定以验收条件为单位，结论分为已覆盖、部分覆盖、未覆盖，执行记录和缺陷关联作为证据。
- 未覆盖项先补用例再评估放行，带风险放行需记录原因、影响、缓解措施和接受人，并与结论一并归档。
需求验证先回答哪三个问题
开始验证前先把三个问题定下来，后续的用例编写和覆盖判定才有统一口径。三个问题分别对应验证对象、判定依据和完成标志。
第一，验证什么。需求验证的对象是需求本身是否被满足，包括功能行为、业务规则、约束条件和权限边界。代码被执行、接口被调用只是过程现象，不能直接当作需求被满足的证据。一条需求如果只验证了主流程能跑通，边界和异常没有结论，这条需求仍处于未验证状态。
第二，凭什么判定。判定依据是可检验的验收条件。验收条件要写成“在什么前提下，执行什么操作，得到什么可观察的预期结果”。无法写出预期结果的需求，先回到需求方澄清，不进入用例编写。判定依据缺失时，测试执行得再多也无法得出覆盖结论。
第三，什么时候算完成。完成标志是每条需求都有一条明确的覆盖结论，并附有支撑证据。结论可以是已覆盖、部分覆盖或未覆盖，未覆盖的要有处置记录。只有用例执行完毕、没有结论汇总，不能算本轮需求验证结束。
| 问题 | 回答内容 | 产出物 |
|---|---|---|
| 验证什么 | 需求是否被满足，含正常、边界、异常、权限 | 需求验证范围清单 |
| 凭什么判定 | 带预期结果的验收条件 | 验收条件列表 |
| 何时算完成 | 每条需求有覆盖结论和证据 | 覆盖结论汇总与证据 |
把需求拆成可验证的验收条件
验收条件拆解是把需求描述转成可判定的检查项。输入是需求条目、业务规则和约束条件；输出是每条需求对应的一组验收条件，每条都带明确预期结果。
拆解时按维度展开，避免只覆盖主流程：
- 正常路径：在合法输入和正常操作下，系统应产生什么结果。
- 边界：取值的上下限、长度上限、时间临界点、数量为零或最大时分别应如何表现。
- 异常：输入非法、依赖服务失败、重复提交、并发操作时应给出什么提示或状态。
- 权限：不同角色能看到什么、能操作什么，越权访问应被拒绝。
- 约束条件：业务规则中写明的互斥、依赖、时效等限制是否被遵守。
每条验收条件建议编号，格式如“需求编号-序号”，并写明预期结果。以“优惠券下单抵扣”为例，可拆出：满足门槛时按面额抵扣且订单金额正确；订单金额恰好等于门槛时可抵扣；低于门槛时不可用并提示原因；优惠券过期时不可用；同一订单不可叠加两张同类型券；无权限角色不可手动修改抵扣金额。这样一组条件既覆盖主流程，也覆盖边界和异常，后续可以直接逐条判定。
拆解完成后交需求方确认。需求方确认的是“这些条件是否完整表达了需求意图”，确认后的条件作为后续用例和覆盖判定的基准。
建立需求与用例的对应关系
对应关系的作用是让覆盖情况可核查：给定一条验收条件，能立刻找到验证它的用例和执行结果；给定一条用例，能说清它服务于哪条需求。
建立映射的基本规则：
- 每条验收条件至少对应一条测试用例，不允许出现没有用例的条件。
- 每条用例标注所覆盖的条件编号，一个用例覆盖多条条件时全部列出。
- 一条条件需要多个用例才能验证时（如不同角色分别验证），允许多条用例对应同一条件，条件是覆盖判定的最小单位。
- 一条用例同时验证多条条件时，执行失败要记录哪条条件未通过，避免一条失败掩盖其他条件的结论。
对应表建议包含以下字段，便于后续统计和追溯：
| 字段 | 说明 |
|---|---|
| 需求编号 | 需求条目的唯一标识 |
| 验收条件编号 | 需求编号加序号，含预期结果 |
| 用例编号 | 覆盖该条件的用例，可多条 |
| 执行结果 | 通过、失败、阻塞、未执行 |
| 证据 | 执行记录、截图、日志或报告位置 |
| 覆盖结论 | 已覆盖、部分覆盖、未覆盖 |
在ONES测试管理中，测试用例可以与产品需求、研发任务关联，用例属性支持自定义，可以把验收条件编号作为属性维护，使需求、条件与用例的对应关系随需求变更一起更新。
判定测试覆盖是否充分
覆盖是否充分，按验收条件逐条判定，不用用例数量或执行率代替。一百条用例全部通过，如果某条边界条件没有对应用例，这条需求仍然存在未覆盖部分。
判定规则可以统一为三类结论：
- 已覆盖：该条件有对应用例，且执行结果为通过，证据可查。
- 部分覆盖：条件有对应用例但执行失败、阻塞或未执行；或条件被拆成多个检查点，只验证了其中一部分。
- 未覆盖：条件没有对应用例，或对应用例尚未编写完成。
识别部分覆盖时重点看三种情况：用例存在但本轮未执行；执行失败后缺陷未关闭；条件包含多个角色或多个数据状态，只验证了其中一个。这三种情况都不能标为已覆盖。
执行结果作为覆盖证据，需要满足可追溯要求：记录执行时间、执行人、实际结果与预期结果的比对，失败项关联缺陷编号。仅有“已测试”的口头结论不构成证据。测试计划执行完成后，可用测试报告汇总各需求的覆盖结论；ONES测试管理支持自动生成测试报告并自定义报告模板，便于把覆盖结论随版本一并归档。
角色分工与各环节交付物
需求验证涉及需求方、开发和测试三方，每个环节都要有明确的交付物，避免出现“条件没人确认、失败没人跟进、结论没人签收”的情况。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 需求方 | 提供需求条目、业务规则与约束；确认验收条件完整表达意图 | 确认后的验收条件列表 | 用例编写前完成确认 |
| 开发 | 说明实现范围与已知限制；提供自测结果和环境说明 | 实现说明、自测记录、提测版本 | 提测时移交测试 |
| 测试 | 编写用例并标注条件编号；执行并记录结果；汇总覆盖结论 | 用例、执行记录、覆盖结论汇总 | 测试报告提交评审 |
| 三方共同 | 评审覆盖结论，对未覆盖项确定处置方式 | 评审记录与签收结论 | 版本发布前完成签收 |
交接节点要落到具体动作：验收条件确认以需求方书面确认为准；提测以开发提交自测结果和版本说明为准；覆盖结论评审以测试报告为输入，输出签收或退回意见。缺陷在测试与研发之间的流转也应有明确责任人，未通过的用例创建缺陷任务后，由开发修复、测试回归，回归结果回填到原用例。
一个需求验证的完整示例
以下为演示情景，用一条需求走完整个流程，说明各环节的产物形态。
需求描述：用户提交退款申请后，系统在 24 小时内自动审核，符合条件的自动退款，不符合的转人工处理。
第一步，拆验收条件。拆出六条：①提交后状态变为“审核中”；②金额在自动退款额度内且订单已支付，24 小时内转为“已退款”；③金额超过额度，转“人工处理”并通知客服；④订单未支付时提交退款被拒绝并提示原因；⑤重复提交同一订单退款，只生成一条申请；⑥非订单所属用户不可发起退款。
第二步，建映射。条件①②③各对应一条主流程用例，条件④⑤⑥各对应一条异常或权限用例；条件②另加一条边界用例，验证金额恰好等于额度上限的情况。每条用例标注对应条件编号。
第三步，执行与判定。执行后条件①②④⑤⑥通过，标为已覆盖；条件③的用例执行失败，转人工的通知未发出，标为部分覆盖并创建缺陷；条件②的边界用例本轮未执行，同样标为部分覆盖。
第四步，处置。缺陷修复后回归条件③，通过则改为已覆盖；边界用例补执行后回填结果。若版本发布前仍无法执行，则在覆盖结论中记录未执行原因、影响范围和风险接受人，随测试报告归档。
这个示例的关键在于：覆盖结论落在条件上，而不是落在“用例通过率”上；部分覆盖被显式识别，而不是被整体通过率掩盖。
未覆盖项怎么处置与留痕
出现未覆盖或部分覆盖时，先补齐再评估放行，顺序如下：
- 优先补写缺失用例并执行，尤其是涉及资金、权限、数据一致性的条件。
- 无法在本轮执行的条件，评估是否可缩小范围验证，例如先验证核心分支，边界项排入下一轮。
- 确实无法验证的，记录风险并明确接受人，不以“后续再测”作为结论。
带风险放行的记录至少包含：未覆盖的条件编号、未覆盖原因、可能影响的业务场景、临时缓解措施、风险接受人和接受时间、计划补测的版本或时间点。记录要放在覆盖结论同一位置，便于评审时一并查看。
结论与证据的归档位置应统一：验收条件列表、用例与执行记录、覆盖结论汇总、缺陷记录、风险接受记录放在同一需求或同一版本的验证档案下。ONES测试管理支持用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发之间流转，覆盖结论和缺陷状态可以在同一处追溯。
完成检查：需求验证收尾核对项
收尾时逐项核对，全部满足才可结束本轮需求验证。
| 核对项 | 通过标准 |
|---|---|
| 每条需求均有覆盖结论 | 结论为已覆盖、部分覆盖或未覆盖，无空白项 |
| 每条验收条件有对应用例 | 条件编号可在用例中找到，无孤立条件 |
| 执行结果可查 | 通过项有执行记录，失败项关联缺陷 |
| 未覆盖项均有处置记录 | 补测计划或风险接受记录完整，接受人明确 |
| 验收条件经需求方确认 | 有确认记录，变更后的条件已同步更新用例 |
| 证据可被后续查阅 | 条件、用例、执行结果、结论归档在同一验证档案下 |
| 评审与签收完成 | 测试报告经评审，签收或退回意见已记录 |
核对中发现空白项，回到对应环节补齐：条件缺失回到需求方澄清，用例缺失回到测试补写，执行缺失安排补测，结论缺失补充判定。全部核对通过后，本轮需求验证即可关闭，验证档案随版本留存，供后续回归和审计查阅。
常见问题
需求描述本身写不出预期结果，还能进入用例编写吗？
建议先回到需求方澄清，把需求补成可观察的结果再进入用例编写。可以换一种问法推进：这个需求上线后，用户或业务方看到什么现象才算做对了；在什么数据、什么角色、什么时间条件下结果会不同。澄清后仍无法写出预期结果的部分，先记为待确认项，不作为已覆盖处理。
一条验收条件需要多个角色分别验证，覆盖结论怎么给？
把这条条件拆成带角色前缀的检查点，例如“管理员可操作”“普通成员不可操作”，每个检查点各自对应用例并单独判定。汇总时以条件为单位给出结论：所有检查点都通过才标为已覆盖；只验证了部分角色，标为部分覆盖，并在结论中写明已验证和未验证的角色。
版本发布前确实来不及补测，风险放行记录要写到什么程度？
记录至少覆盖五项：未覆盖的条件编号、未覆盖原因、可能影响的业务场景、临时缓解措施、风险接受人和接受时间，并注明计划补测的版本或时间点。记录放在覆盖结论同一位置，评审时与测试报告一并查看。接受人应是对该业务风险有决策权的角色，测试人员单方面标注放行不构成有效记录。
需求在验证过程中发生变更，已经建好的条件和用例怎么处理？
变更后先更新验收条件列表，标注新增、修改和作废的条件，再同步调整对应用例：新增条件补写用例，修改条件更新用例预期结果，作废条件对应的用例停用但保留记录。已执行的旧结果不覆盖，作为历史证据留存。变更后的条件需重新经需求方确认，覆盖结论按新条件重新判定。
用ONES管理需求、用例和执行结果，能支撑覆盖判定吗？
ONES测试管理支持测试用例与产品需求、研发任务关联，用例属性可自定义，可以把验收条件编号作为属性维护；测试计划可分配执行人，未通过的用例可快速创建缺陷任务并在测试与研发之间流转，测试报告支持自动生成和自定义模板。覆盖结论仍需要按验收条件逐条判定，工具承担的是关联、记录和归档，判定规则由团队自己定。
