1 Given-When-Then 概念
Given-When-Then（常被称为 GWT）是一种用于描述系统行为的写作与测试场景结构模板。它把一次业务交互或系统处理拆解为三段：前置条件、触发动作与预期结果，从而让“要发生什么”与“应该发生什么”形成清晰对应，便于团队在需求沟通、测试设计与质量验收之间达成一致。
在实践中，Given 关注测试或验证发生前的上下文；When 描述触发交互或系统事件；Then 则给出可核验的期望。该结构既能用于自然语言形式的规格说明，也能映射到自动化测试框架中的步骤（step），从而将语义从需求层贯通到执行层。
1.1 三段式结构定义（Given/When/Then）
- Given：建立上下文。通常包含数据准备、环境条件、初始状态或前提规则等，使后续触发动作具备确定的起点。
- When：触发行为。用于描述用户操作、调用请求或系统事件，并尽量明确输入参数、操作顺序及触发对象。
- Then：表达期望。强调“可验证”的结果，例如状态变化、输出内容、返回码、调用结果或不变量约束。
1.2 与 BDD/验收测试的关系
GWT 与行为驱动开发（BDD）在语义上高度契合。BDD 强调用可读的场景来表达业务意图，并让非技术角色也能理解“在什么前提下发生什么以及应得到什么结果”。GWT 的 Given/When/Then 三段式恰好服务于这种场景化表达。
在验收测试中，GWT 常用于把验收口径落到可执行的检查点：Given 固化前提与数据，When 体现实际触发，Then 对应验收所需的可核验结论。这样做有助于减少“口头理解一致但结果落地不一致”的风险。
1.3 相比传统用例的优势与适用场景
与传统“输入—处理—输出”或更偏实现细节的用例相比，GWT 的优势主要体现在可读性与可维护性：
- 语义更贴近业务叙述：前提、动作、期望的顺序符合人类理解习惯。
- 更易进行测试与需求的对照：每个 Then 都能直接关联验收点或业务规则。
- 便于复用上下文：相同的 Given 可在多场景中复用，从而减少重复工作。
- 易于定位问题：失败时通常能快速判断是前置条件错误、触发动作偏离还是期望断言不匹配。
适用场景包括：接口验收、交互型业务规则测试、状态机或流程类系统的行为验证、以及需要让业务侧参与理解的场景。
2 Given（前置条件）
Given 用于定义“在执行触发动作之前，系统处于怎样的世界”。它决定了场景的起点是否明确，因此 Given 的质量直接影响测试是否可靠、是否能被复现。
2.1 上下文与数据准备
Given 往往包含必要的数据与状态，例如：
数据准备应覆盖触发动作所需的最小集合，避免为了“看起来更完整”而引入与验证无关的大量字段。
2.2 系统状态与环境条件
除了数据，Given 还可包含环境与系统状态，例如：
- 当前服务处于某个模式（如只读/可写、开关开启或关闭）
- 时间或时区相关条件（如过期边界、定时任务时刻）
- 权限或角色相关条件（如具备特定访问能力）
- 外部依赖的可用性与基础行为（在自动化中可通过模拟或固定响应实现）
当环境条件会影响结果时，应把关键差异显式写进 Given，而不是隐含在测试框架默认配置里。
2.3 前置条件的边界与可复用性
良好 Given 具备边界清晰与可复用性：
- 边界清晰：Given 不应包含与特定验证点无关的复杂推导或过度准备，避免让读者难以判断哪部分与业务相关。
- 可复用：对于多个场景共享的上下文，可抽取为公共步骤或数据构建器，减少重复代码与复制粘贴带来的漂移。
同时，Given 也应避免“过度一般化”。如果 Given 太宽，场景的意义会变得模糊，最终导致 Then 难以对齐具体业务规则。
3 When（触发动作）
When 用于描述触发“发生变化的那一步”。其核心目标是可复现地说明：系统在什么条件下、如何被刺激、触发了哪些行为。
3.1 用户行为或系统事件
When 可以来自用户操作，也可以来自系统事件或消息触发，例如：
无论来源如何，When 都应尽可能贴近业务语言，不必纠结内部实现细节。
3.2 输入与操作参数描述
When 通常需要明确输入与参数，尤其是会影响结果的部分，例如：
- 请求体关键字段与取值
- 路由参数或标识符（如订单号、用户ID）
- 触发对象与范围（对哪一笔数据、对哪个资源进行操作）
参数描述应保持一致性：同一字段在不同场景中的命名与语义应保持对齐，避免读者误解。
3.3 多步骤触发与顺序表达（单次/多次 When）
有些场景需要多次交互或多种事件依序发生。此时可以采用单次 When 覆盖一个动作链，或通过多次 When 分段表达。选择通常取决于团队约定与可读性目标：
- 单次 When：适合步骤之间强耦合且整体属于同一业务动作的短链路。
- 多次 When：适合每一步都有明确业务意义或会引入中间状态变化的过程。
无论采用哪种方式，顺序表达应清楚，避免读者无法判断事件先后关系。
4 Then（预期结果）
Then 用于表达“应该出现什么”。它强调可验证性，因此 Then 往往对应断言（assertion）或验收检查点。
4.1 可验证的结果（断言思路）
Then 的断言通常围绕以下几类：
- 返回值或响应内容：响应码、错误信息、字段取值
- 系统状态变化：数据库记录是否新增/更新、状态字段是否切换
- 副作用与外部交互：是否发起回调、是否写入日志或触发下游动作
- 不变量与约束：例如总额守恒、权限限制不被破坏
建议优先断言业务关键信息，而不是捕捉易变的实现细节。
4.2 状态变化与输出校验
当系统涉及状态转移，Then 应明确校验对象与期望状态，例如：
- 某资源从“待处理”变为“已完成”
- 金额相关字段是否符合规则
- 列表或查询结果是否包含/不包含特定项
输出校验同样应聚焦业务意义：校验字段值的组合关系通常比单字段完全相等更贴近业务规则。
4.3 异常/失败场景的 Then 表达
失败场景同样适用 Given-When-Then，只是 Then 更偏向异常结果的可验证表达，例如：
对于异常场景，应避免在 Then 中只写“抛错即可”这类不可核验表述，而应写明可观测结果的细节口径。
4.4 验收标准与验收口径一致性
验收测试的核心是口径一致。Then 所体现的期望应与验收标准一一对应，确保：
- 期望的含义没有多解
- 字段、状态与错误处理规则与验收文档一致
- “成功/失败”的判定条件清晰可计算或可观察
如果存在指标或阈值，Then 应写出明确的判定规则或边界条件。
5 从需求到测试的落地方式
把需求转成 GWT 场景时，关键是建立“从自然语言到可执行步骤”的映射关系，同时保持语义稳定。
5.1 规格说明到测试步骤的映射
常见做法是将每段话对应到测试步骤或代码模块：
- Given：调用数据构建函数、初始化环境、准备依赖桩或配置
- When：执行页面操作、调用接口、触发消息或事件
- Then：执行查询、校验响应、检查数据库或验证外部交互
通过映射，规格中的每个关键点都能在自动化层落到“真的检查了”的动作上，从而减少“写了但没验证”的空转。
5.2 编写规则：命名、粒度与可读性
为了让场景可读且可维护，通常会遵循以下规则：
- 命名：Given/When/Then 的句子应体现领域含义，避免仅描述技术实现（如“调用方法X”）。
- 粒度：每条步骤应聚焦一个业务要点，避免长句混入多种含义。
- 可读性：使用清晰的关键短语组织句子结构，并保持字段名、单位、边界条件的统一。
当场景需要更复杂的准备或校验时，可以把内部复杂逻辑封装在步骤实现里，但对外仍保持清楚的业务表达。
5.3 维护策略：避免脆弱断言与步骤膨胀
维护性是 GWT 长期可用的关键。常见策略包括：
- 避免脆弱断言：不要因非关键字段或顺序敏感项导致频繁失败；优先断言业务关键字段。
- 控制步骤数量：Given/Then 不宜堆叠过多细碎检查；过多步骤会造成场景冗长、理解成本上升。
- 统一断言口径：建立公共断言工具或校验器，保证同类规则在不同场景中保持一致。
此外，应当定期审视场景与代码的漂移：当需求变化导致 Then 频繁改动时，可能提示场景粒度或口径表达需要调整。
6 书写范式与示例要点
本节聚焦如何把 GWT 写得更像“规格”，而不是仅仅像“测试脚本”。关键在于句式稳定、参数表达清晰、覆盖意图可见。
6.1 常见句式模板（自然语言风格）
自然语言风格通常采用直观模板，例如：
- Given：在……的前提下，……
- When：当……时，……
- Then：应当……，并且……
这些模板的目的在于让读者无需理解底层代码也能读懂场景逻辑。句子长度不宜过长，关键条件与关键结果应尽量落在同一句中。
6.2 处理数据表与参数化用例
当同一业务规则需要多组输入与期望时，可使用参数化或数据表，把“变化的部分”作为表格行来描述：
- Given 中可参数化不同的初始数据组合
- When 中可参数化请求参数
- Then 中可参数化预期结果或错误类型
参数化有助于减少重复场景，同时保持口径一致。需要注意的是：表格维度过多会降低可读性，应控制参数数量并确保每组输入与期望有明确业务意义。
6.3 用例组合与覆盖思路（正向/反向/边界）
覆盖思路通常包括：
- 正向：验证在合法输入和满足前提时的正确行为
- 反向：验证在不满足规则或条件冲突时的拒绝与错误处理
- 边界：围绕阈值、最大/最小值、空值或临界状态进行验证
组合时可优先围绕业务规则拆分场景，而不是围绕实现路径堆叠场景。边界与反向用例的 Then 应同样可验证，避免只写“应该失败”而缺少可核验口径。
7 常见问题与反模式
实践中常见的问题往往不是 GWT 结构本身的问题，而是写作与校验策略偏差导致的维护负担。
7.1 Given/When/Then 混写的典型问题
混写常表现为：
- 将断言写进 Given：导致 Given 不再只是上下文
- 把动作写进 Then：让 Then 变成“再执行一次”而非“验证结果”
- 用 When 描述数据准备：触发动作与准备阶段界限模糊
当这种问题发生时，读者很难判断哪一段在定义前提，哪一段在触发系统，哪一段在做验证。
7.2 Then 过度细化或过度泛化
- 过度细化：Then 校验过多与业务无关的实现细节，导致改动频繁、失败原因难以解释。
- 过度泛化：Then 只写“结果正确”或“状态正常”，缺少可核验条件，使测试无法真正提供保障。
平衡点通常是：校验业务关键信息、关键约束与可观察的结果，同时避免“装配式全量断言”。
7.3 场景过大导致难维护
当一个 Scenario 覆盖多个业务规则或多条相互独立的链路，容易出现：
- 场景长度过长，Given/Then 混杂
- 失败定位困难：需要回溯才能知道是哪一条规则不成立
- 复用性变差：同一大段场景难以被拆分或组合
通常应把场景按业务规则拆分成更小的、语义清晰的单元，并保持 Given/When/Then 的职责分离。
8 术语与相关概念
理解相关概念有助于把 GWT 放到整体测试与规格体系中讨论，从而避免术语混用。
8.1 Feature/Scenario/Step 的对应关系（概念层面）
在 BDD 常见的组织方式中：
- Feature：描述一个业务能力或主题的总目标（例如“用户下单”）
- Scenario：描述围绕该 Feature 的具体场景（对应一次 Given-When-Then 的组合）
- Step：Scenario 中的最小可读单元，通常体现为 Given/When/Then 的若干句
因此，Scenario 通常由多条 Step 组成，但核心语义仍围绕 Given/When/Then 展开。
8.2 GWT 与其他用例结构（如 Arrange-Act-Assert）的对比
Arrange-Act-Assert（AAA）也用于组织测试思路：
- Arrange 对应准备与上下文，与 Given 相近
- Act 对应触发与执行，与 When 相近
- Assert 对应断言与期望，与 Then 相近
差别更多体现在表达风格与团队约定上：GWT 更强调面向业务叙述的可读性，AAA 则更偏通用测试组织命名。在实践中，两者可以互相映射，但写作目标与受众侧重点可能不同。
8.3 可观测性与行为验证的基本原则
无论采用哪种结构，行为验证都依赖可观测性原则：
- 能从系统外部或可查询的状态中看到预期结果
- 断言应建立在稳定的可观测信号上
- 验证范围应与需求一致，避免验证“内部实现细节”而不是业务行为
在写 Then 时，如果某个期望无法被稳定观测，往往意味着要么口径不完整，要么需要引入合适的观测手段（例如暴露查询接口、记录审计信息或改进事件输出）。