Given-When-Then验收场景与测试用例设计 - 第1节
1.1 起源与背景：从行为驱动到验收标准的结构化革命
Given-When-Then（GWT）并不是凭空诞生的理论模型。它最早出现在 行为驱动开发（BDD, Behavior-Driven Development） 方法论中，由 Dan North 在21世纪初提出，旨在解决“需求与分析人员在文档里写长篇大论、开发与测试在代码里各自猜意”这一经典协作断裂问题。
传统验收标准的常见写法是：
系统应具备用户登录功能。
用户输入正确凭证后可以成功登录。
对于无效凭证系统应给出错误提示。问题很明显——谁触发？在什么上下文？期望什么结果？边界含糊不清。Given-When-Then 通过固定的“前置条件→操作触发→结果验证”结构，将验收标准从散文体转为“可执行剧本”，彻底消除了歧义。
要点： GWT 不是测试用例，而是验收剧本——它描述的是系统外在可见的行为结果，而非内部实现细节。
1.2 核心三要素解构
每一条 Given-When-Then 验收标准都必须包含三个部分，缺一不可：
| 要素 | 英文 | 含义 | 回答的问题 |
|---|---|---|---|
| Given | 上下文与前置条件 | 系统处于什么初始状态？有哪些前置数据、权限或配置已就位？ | “故事发生前，世界是怎样的？” |
| When | 操作或事件 | 用户（或其他参与者）执行了哪个具体动作？或外部触发了什么事件？ | “发生了什么？” |
| Then | 期望结果 | 系统应产生哪些可见的输出、状态变更或返回值？ | “世界变成了什么样子？” |
完整示例（用户注册功能）：
Given 系统邮箱“test@example.com”尚未被注册
And 用户已同意平台服务协议
When 用户在注册页面填写邮箱“test@example.com”
And 用户设置密码“Pass@123456”
And 用户点击“注册”按钮
Then 系统为该用户创建账户，状态为“待激活”
And 系统向“test@example.com”发送一封确认邮件
设计提示： 一个 When 至多对应 1 个核心触发动作。如果一条验收标准里出现了多个连续操作（如“点击保存，然后点击提交”），应拆为多条 GWT 场景，或使用 And/But 显式连接。
1.3 适用验收场景
GWT 格式并非万能，但它在六个领域表现出极强的结构化优势：
- 用户故事验收（BDD + Scrum） —— 作为 Sprint 验收的“通过/失败”判定依据。
- 接口/API 契约测试 —— 定义请求触发与响应结构的精确匹配规则。
- 状态机与工作流 —— 验证触发事件后状态迁移是否符合设计。
- 配置类与开关类功能 —— “当功能开关为 ON 时，行为应为 X”。
- 异常与错误边界 —— “Given 余额不足，When 扣款，Then 返回错误码”。
- 数据管道/ETL 校验 —— 描述输入数据格式、转换动作与输出表断言。
避免滥用： 纯 UI 排版检查、非功能性需求（性能/安全性规程）以及跨系统长链路集成场景，GWT 格式会让验收标准变得笨重。这些场景应优先选用检查表或工作流图，而非硬套 GWT 句式。
1.4 GWT 三要素关系结构图
1.5 本章总结：GWT 作为验收标准域语言
Given-When-Then 的结构优势在于它强制每一个验收标准都回答三个问题：
- 起点（Given）—— 把隐性假设显式化，消除“我以为系统已经登录/配置了XXX”的幻觉。
- 触发（When）—— 锁定唯一的动作边界，防止一个验收标准包含多个潜在的判定路径。
- 终点（Then）—— 只关心外部可见反馈，不绑死内部实现。