第4章 When触发动作定义原则：用户操作、系统事件、接口调用
核心要点：When 子句必须描述一个可观察、可测的触发动作，该动作必须来源于三类合法来源之一——用户操作、系统事件或接口调用。任何模糊、不可重复或非确定性的事件描述均视为不合格。
4.1 适用场景
以下场景中必须严格使用三类触发动作之一定义 When 子句：
| 触发来源 | 适用场景示例 | 不可用描述 |
|---|---|---|
| 用户操作 | 点击按钮、选择下拉项、提交表单、拖拽文件 | “用户希望…”“用户突然…” |
| 系统事件 | 定时任务触发、状态机跳转、日志达到阈值 | “系统自动…”“可能发生…” |
| 接口调用 | HTTP POST 请求、MQ 消息、RPC 调用 | “某个服务调用…”“接口偶尔…” |
4.2 前置条件
- 已经完成 Given 上下文的状态描述（见第3章）。
- 参与验收的各方（产品、开发、测试）已对齐触发动作的来源类型。
- 被测系统（SUT）的边界已明确，外部接口和内部事件渠道已文档化。
4.3 触发动作定义流程
- 识别来源：判断该行为是用户主动发起、系统自身触发还是外部调用。
- 命名触发动作：使用动词+名词的精确短语，如
提交退款申请、收到支付回调。 - 补充参数（可选）：如时间范围、金额、消息体等，用结构化方式表达。
- 标注预期响应：明确触发后系统应表现的 Observable 行为（此时不写 Then，仅确认触发可被观察）。
最佳实践：推荐在 When 子句后添加
（来源：用户操作） 或 （来源：系统事件） 注释，便于评审时快速归类。
4.4 输入/输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 需求文档 | 用户故事、用例描述 | 触发动作定义列表 |
| 接口规范 | API 文档、事件 schema | 触发动作与接口映射表 |
| 验收标准初稿 | 未拆分的 GWT 草稿 | 带有来源标签的 When 子句 |
4.5 责任边界
- 业务分析师（BA）：界定触发动作的业务含义，确保术语一致。
- 开发人员：确认触发在技术层面可被唯一监听或捕获。
- 测试人员：设计触发动作的模拟方案，例如通过 Selenium 模拟用户操作、Mock 接口调用。
- 质量工程师：审核 When 子句是否符合三类来源规则，并排除歧义。
4.6 记录材料
每次验收标准定义后，需填写 触发动作登记表，模板如下：
# 触发动作登记表（示例）
- 验收标准 ID： AC-0047
- When 子句原文： When 用户点击“立即支付”按钮
- 来源： 用户操作
- 触发介质： 鼠标点击（DOM 事件）
- 可观察前置窗口： 按钮在 2 秒内变为可点击状态
- 备注： 需禁用重复点击4.7 异常处理
| 异常场景 | 处理方法 |
|---|---|
| 同一动作可从多个来源触发 | 拆分为多个 When 子句，每个标注单一来源 |
| 动作非原子性（如“填写表单并提交”） | 拆分为“填写完成”和“提交”两个独立 When |
| 系统事件无精确触发时钟 | 使用 When 系统收到事件队列中的消息X 代替模糊时间 |
| 接口调用有重试或超时 | 将重试/超时纳入 Given 上下文，When 只描述第一次触发 |
常见错误：将触发动作与预期结果混写。例如 “When 用户点击提交，系统显示成功” 是错误的，正确的写法是 When 子句只到“点击提交”为止，然后另起 Then 子句描述“系统显示成功”。
4.8 验收标准
- 每个 When 子句必须明确从三类来源（用户操作/系统事件/接口调用）中选择一个。
- 触发动作描述必须包含可观察或可模拟的具体事件，不允许用“如果”“可能”“打算”等模糊词。
- 当动作来源是接口调用时，必须指明协议（HTTP、MQ、gRPC 等）和端点标识。
- 当动作来源是系统事件时，需指明事件名称和触发频次（单次/周期/条件触发）。
- 验收标准评审通过前，When 子句必须附带来源标注。