验收标准的 Given-When-Then 写法
把验收标准写成 Given-When-Then 三段式：明确前置条件、操作与可观察结果。编写过程本身就是需求澄清：写不出 Given、When、Then 的条目，通常意味着需求存在歧义或缺失规则；三段式条目还能直接映射自动化用例，评审与验收共用同一套语言。
基本信息
| 结构 | Given 前置事实、When 单一操作、Then 可观察结果 |
|---|---|
| 写法要点 | 前置用已发生事实、操作单一、结果可观察 |
| 与用例联动 | 验收标准直接映射自动化用例名 |
| 评审时机 | 与用户故事同行评审，实现前确认 |
| 常见反例 | 写不可验证的形容词（友好、快速） |
反例与正例
反例与正例
# 反例：不可验证
# 登录要做得友好、快速
# 正例：
Given 用户已注册且状态正常
When 使用正确账号密码登录
Then 跳转到首页且显示用户名典型使用场景
- 用户故事评审：逐条确认可测试性，暴露缺失规则。
- 自动化映射：每条标准对应一条用例，覆盖可核对。
- 验收执行：验收人与开发对同一条款达成一致理解。
- 范围控制：异常与权限规则写成独立条目，防止漏项。
- 示例驱动：用具体例子补全规则边界，比抽象描述更准。
- 回归追踪：需求变更时按条目评估受影响用例。
三段职责
| 要素 | 写什么 | 常见错误 |
|---|---|---|
| Given | 已发生的前置事实与状态 | 塞入动作，前置难复现 |
| When | 单一操作 | 多个动作连写，触发点不清 |
| Then | 可观察、可断言的结果 | 写主观形容词，无法判定 |
验收标准与用户故事同行：评审时逐条确认可测试性，避免实现完成后再补标准。
一个故事的标准数量要可控；条目过多通常说明故事本身需要拆分。
Given 写状态而不是动作：把「用户点击了注册」这类过程写进前置，会让复现条件变得模糊。