可验证的验收条件，核心是把“做完”变成“能判定”：每条条件写清前提、动作和可观察结果，让需求提出人、开发、测试对同一条款得出相同结论。本文按编写顺序给出判定标准、拆解步骤、句式字段模板、角色分工、完整改写示例和定稿自检清单，适用于用户故事进入评审与测试衔接阶段的需求表达工作。
要点总览（TL;DR）
- 可验证的验收条件要写清前提、动作和可观察结果，一条只对应一个业务结果，让需求方、开发、测试得出相同判定。
- 编写顺序是：先识别故事的关键场景与角色，再写正常路径条件，补充边界与例外，标注判定依据和数据，最后三方评审定稿。
- 句式以“给定—当—则”为主，多组数据对应关系改用示例表；条件编号、关联场景、判定依据等字段便于评审和用例追溯。
- 需求提出人对业务结果负责，开发补充技术边界，测试把关可测性，评审记录和定稿版本要留存。
- 定稿前逐条自检：能否用一次测试或演示判定通过与否、有无主观描述、边界例外是否覆盖、三方是否一致、用例对应是否建立。
验收条件写到什么程度才算可验证
一条验收条件达到可验证，最低要求是：换一个人按条款操作，能得到明确的“通过”或“不通过”，不需要再向作者追问。可以用三个要素来检查：前提是否交代了起始状态和数据，动作是否说明了谁做了什么，结果是否给出了可观察的现象或数值。三者缺一，判定就会落到个人理解上。
可验证验收条件的判定标准清单：
- 前提明确：写明角色、账号状态、数据状态、环境条件等起始信息，读者能据此复现场景。
- 动作单一：一条条件只描述一个操作或一组不可分割的操作，避免“提交并审批并通知”这类复合动作。
- 结果可观察：结果是页面状态、数据变化、消息内容、接口返回、日志记录等能被看到或查到的事实，并写明判定依据。
- 一条一个业务结果：同一条条件不混装两个独立结论，否则部分通过时无法判定整条是否通过。
- 三方口径一致：需求提出人认可业务结果，开发认可技术可行，测试认可可以据此设计用例。
用户故事正文与验收条件承担不同任务。故事正文说明“谁、为了什么价值、要什么能力”，帮助团队理解为什么做；验收条件说明“在什么情况下、做什么、看到什么算完成”，帮助团队判断做到没有。故事可以保留业务语言和背景，验收条件则应尽量收敛为可判定的表述。两者分开写，评审时也便于分别讨论价值是否成立、判定是否清楚。
需要说明的是，可验证不等于必须自动化测试。一次手工演示、一次数据核对、一次接口调用记录，只要判定依据明确、结论可复核，同样构成验证。关键在于判定动作是否被写清楚，而不是验证手段的先进程度。
从用户故事拆出验收条件的操作步骤
从故事到条件是一个逐层收敛的过程：先找场景，再写主路径，然后补边界和例外，接着标注判定依据，最后共同评审。每一步都有明确的输入和输出，完成后才进入下一步，可以减少返工。
第一步：识别关键场景与角色
输入是用户故事正文和相关业务背景。动作是列出这个故事涉及的角色、触发时机和主要业务分支，标出哪些是核心场景、哪些是次要场景。输出是一份场景清单，每个场景有简短名称和涉及角色。完成标志是团队能指着清单说“这个故事要覆盖这几个场景”。场景识别不充分，后面的条件就会漏写。
第二步：为每个场景写正常路径条件
输入是场景清单。动作是针对每个核心场景，写出顺利走通时的前提、动作和预期结果。输出是每个场景至少一条正常路径条件。完成标志是每条条件都能对应回某个场景，且结果描述具体到可观察对象。正常路径是验收的基础，先写清楚它，边界和例外才有参照。
第三步：补充边界值与例外条件
输入是正常路径条件和业务规则。动作是逐条追问：数据为空、达到上限、重复提交、权限不足、依赖服务不可用、并发操作时分别应发生什么。输出是边界条件和例外条件，每条同样包含前提、动作和结果。完成标志是主要业务规则都有对应的边界或例外条款，且没有把多个例外塞进同一条。
第四步：为每条条件标注判定依据与数据
输入是已写出的条件草稿。动作是为每条条件补上判定依据，例如查看哪个页面、核对哪张表、比对哪个返回值，并给出具体的数据示例或阈值。输出是带判定依据的完整条件。完成标志是测试人员不看作者解释也能知道去哪里看结果、拿什么数据比对。
第五步：与需求方、测试共同评审定稿
输入是完整条件集合。动作是组织需求提出人、开发和测试逐条过，确认业务结果、技术可行性和可测性，记录修改意见并形成定稿版本。输出是评审通过的验收条件及评审记录。完成标志是三方对每条条件的判定结论没有分歧，且定稿版本可追溯。
验收条件的写法模板与字段
最常用的句式是“给定—当—则”：给定某前提，当执行某动作，则出现某可观察结果。它适合大多数有明确触发动作的场景，读起来接近测试步骤，便于直接转成用例。当判定依赖多组输入与输出的对应关系时，逐条文字会变得冗长，此时改用示例表更清楚：一行一组数据，列出输入、操作和预期结果，表头固定，评审时逐行核对。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 条件编号 | 唯一且稳定，便于评审和用例引用 | AC-03 |
| 关联场景 | 指向场景清单中的场景名称 | 优惠券重复使用 |
| 前提 | 角色、数据状态、环境条件 | 用户已使用优惠券完成一笔订单 |
| 动作 | 单一操作或不可分割的操作组 | 再次提交同一优惠券码 |
| 预期结果 | 可观察的状态、数值或提示内容 | 页面提示“该优惠券已使用”，订单金额不发生变化 |
| 判定依据 | 去哪里看、比对什么 | 订单详情页金额字段与优惠券状态字段 |
| 数据示例 | 具体数值或样本，标明口径 | 订单原价 200 元，优惠 20 元，应付 180 元 |
模糊词是验收条件最常见的失效点。“快速”“友好”“正常”“合理”这类词无法判定，替换方法是把它们落到可观察的对象上：把“加载快速”替换为“在约定网络条件下，列表首屏在指定时间内出现”；把“提示友好”替换为“提示文案包含原因和下一步操作，且不遮挡提交按钮”；把“显示正常”替换为“字段值与来源数据一致，空值显示为短横线”。替换时同时写明判定阈值和数据口径，避免把主观感受换成另一个无法核对的数字。
句式模板不必强求统一。对于状态流转类场景，“给定—当—则”最直接；对于批量数据处理，示例表更易维护；对于规则组合较多的场景，可以先列规则表，再用少量条件覆盖关键组合。选择的标准是评审者能否快速核对，而不是形式是否整齐。
角色分工与交付物
验收条件由多方共同完成，但每类角色有主责范围。需求提出人对业务结果和判定依据负责，因为只有他们能说明这个结果对业务意味着什么；开发负责技术可行性和边界补充，指出哪些条件在当前实现下需要明确约定；测试负责可测性和用例衔接，判断每条条件能否转化为可执行的验证动作。三方各写各的容易产生口径差异，主责加共同评审更稳妥。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 需求提出人 | 确认业务结果、判定依据和优先级 | 场景清单、正常路径条件、业务规则说明 |
| 开发 | 补充技术边界、异常处理和可行性意见 | 边界与例外条件、技术约束说明 |
| 测试 | 检查可测性，建立条件与用例的对应关系 | 可测性意见、用例映射、验证数据准备 |
| 团队共同 | 逐条评审并确认定稿 | 评审记录、定稿版本及变更说明 |
评审记录和定稿版本需要留存，原因很实际：验收条件在开发过程中会被修改，后续测试和回归需要知道当时确认的是哪一版、改了什么、谁同意的。留存方式可以是工作项中的评论与版本记录，也可以是需求文档中的变更说明，关键是能追溯到具体条款和确认人。
当验收条件定稿后需要与测试用例建立对应关系时，可以在同一工作项体系中承载。ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，用例属性也可按业务场景自定义，便于把条件编号、关联场景和用例对应起来；未通过的用例可创建缺陷任务并在测试与研发团队间流转。具体字段配置以实际使用版本为准。
示例：一条用户故事的验收条件改写
假设用户故事是：“作为注册用户，我希望使用优惠券抵扣订单金额，以便降低购物成本。”原始验收描述写成：“用户可以正常使用优惠券，系统快速校验并友好提示，异常情况要正确处理。”这段描述的问题很典型：没有前提数据，没有说明校验什么，“正常”“快速”“友好”“异常情况”都无法判定，测试人员只能凭经验猜测，需求方和开发对“正确处理”的理解也可能不同。
按场景拆分后，可以得到正常、边界、例外三类条件。以下为演示情景，数据为示例值。
- 正常路径 AC-01：给定用户持有一张未使用、未过期的满 100 减 20 优惠券，当用户在订单金额 200 元的结算页选择该券并提交，则订单应付金额变为 180 元，优惠券状态变为已使用，订单详情页显示优惠金额 20 元。
- 边界条件 AC-02：给定订单金额恰好为 100 元，当用户使用同一张满 100 减 20 优惠券，则应付金额为 80 元，优惠正常生效。
- 边界条件 AC-03：给定订单金额为 99.99 元，当用户尝试使用该券，则页面提示未达到使用门槛，订单金额保持 99.99 元，优惠券状态保持未使用。
- 例外条件 AC-04：给定优惠券已过有效期，当用户在结算页选择该券，则页面提示优惠券已过期，订单金额不发生变化。
- 例外条件 AC-05：给定用户已使用该券完成一笔订单，当再次提交同一优惠券码，则页面提示该优惠券已使用，订单金额不发生变化。
逐条看判定依据如何落地：AC-01 的判定依据是订单详情页的应付金额字段、优惠金额字段和优惠券状态字段，测试时核对这三个值即可；AC-02 和 AC-03 用 100 元与 99.99 元这组相邻数据验证门槛判断，判定依据是金额字段和提示文案；AC-04 和 AC-05 的判定依据是提示内容与订单金额是否保持不变。每条条件只对应一个业务结果，前提、动作、结果齐全，需求方可以确认业务含义，开发可以确认校验逻辑，测试可以直接据此设计用例。
完成检查：验收条件定稿前的自检项
定稿前逐条核对下面的清单，任何一项不通过，就回到对应条款修改，而不是带着模糊表述进入开发。
| 检查项 | 核对方法 | 通过标准 |
|---|---|---|
| 可判定性 | 对每条条件问：能否用一次测试或一次演示判定通过或不通过 | 每条都有明确结论，无需追问作者 |
| 结果可观察 | 检查结果描述是否指向页面、数据、消息或接口返回 | 不存在“正常”“友好”“快速”等主观描述 |
| 一条一个结果 | 检查单条条件是否混装多个独立结论 | 部分失败时能明确判定该条不通过 |
| 边界与例外覆盖 | 对照业务规则，检查空值、上限、重复、权限、依赖异常 | 主要规则均有对应条款 |
| 三方一致 | 需求提出人、开发、测试逐条确认 | 对判定结论无分歧，评审记录留存 |
| 用例对应 | 检查每条条件是否已映射到测试用例或验证方式 | 条件编号可在用例中追溯 |
这份清单适合在评审会上逐条过，也适合作者定稿前自查。自检通过后，验收条件与用户故事一起进入开发和测试环节；后续如果业务规则变化，按条件编号更新并保留变更记录，测试用例同步调整，判定口径才不会在迭代中走样。
常见问题
验收条件必须写成自动化测试才能算可验证吗？
不必。可验证的关键是判定动作写清楚、结论可复核，一次手工演示、一次数据核对或一次接口调用记录都可以构成验证。自动化测试能提高回归效率，但它属于验证手段的选择，与验收条件本身是否可判定是两件事。编写时先把前提、动作和可观察结果写明确，再根据场景频次和风险决定是否自动化。
一个用户故事要写多少条验收条件才合适？
数量由场景决定，没有统一标准。实用的做法是先覆盖核心场景的正常路径，再为影响业务结果的边界值和例外各写一条，次要场景可以合并或延后。判断是否够用的依据是：主要业务规则是否都有对应条款、每条条件是否只对应一个业务结果。条件过多往往说明故事本身偏大，可以考虑拆分用户故事，而不是继续堆条款。
验收条件定稿后业务规则变了，怎么处理？
按条件编号更新，并保留变更记录，说明改了什么、谁确认的。与条件关联的测试用例同步调整，避免判定口径在迭代中走样。如果变更影响业务结果本身，需要重新组织需求提出人、开发和测试确认，而不是由单方直接修改条款。
验收条件和测试用例是什么关系，需要重复写吗？
两者分工不同：验收条件说明“什么算完成”，用业务语言表达判定标准；测试用例说明“怎么验证”，包含具体步骤、数据和预期。验收条件不应直接复制成用例，但每条条件应能映射到至少一个用例，条件编号可在用例中追溯。这样回归时能快速确认哪些条件被覆盖。
团队规模小、角色兼任时，验收条件的分工怎么落地？
角色可以兼任，主责不能缺位。即使一个人同时承担需求和测试工作，也建议在评审时分别以业务结果和可测性两个视角检查条款，并留下评审记录。开发参与边界与例外条件的补充仍然必要，因为技术约束往往只有实现方最清楚。分工的目的是让不同视角都过一遍，而不是增加流程环节。
