第4章 编写验收标准的标准句式结构与模板

验收标准要具备可衡量性，首先必须使用统一的句式结构。本章给出两种经过工业验证的标准句式模板——Given-When-Then（GWT）与条件-行为-结果（CBR），并围绕适用场景、前置条件、操作步骤、输入输出物、责任边界、记录材料、异常处理展开SOP固化。

适用场景

• Given-When-Then：用户故事、功能验收、端到端测试场景。例如：“Given 订单已支付，When 用户点击退款，Then 退款金额立即释放至账户余额。”
• 条件-行为-结果：服务响应、接口契约、定时任务、异常降级。例如：“条件：线程池队列超过80%，行为：触发熔断窗口，结果：返回503状态码并在日志中记录fallback条目。”
• 混合场景（如复杂业务规则）：将GWT中的Then扩展为条件-行为-结果分支链条。

前置条件

1. 验收需求已结构化：功能点、入口、预期输出、边界值均已确定。
2. 指标定义已对齐：关键绩效指标（KPI）、服务等级目标（SLO）、精度阈值已被产品、开发、测试三方签字确认。
3. 术语表已锁定：团队内使用完全一致的术语（如“结算金额”不可混用“支付金额”）。
4. 模板版本号已确定：本次编写遵循的句式模板版本应记录在《验收标准样式文档》中。

操作步骤

1. 确定验收粒度：每个验收标准只描述一个独立的行为路径。若某功能有3条不同路径则写出3条标准。
2. 选择句式模板：
   - 用户操作场景 → GWT
   - 系统自动/条件驱动场景 → CBR
3. 填充主语与参数：主语必须是具体对象（“用户”“订单系统”“网关”），参数必须使用实际数值或变量名。
   反例：“When 查询超时” → 缺少主语、超时值未定义。
   正例：“When 订单查询耗时超过3000ms” → 主语+具体值。
4. 动词替换为可测量动作：避免“确保”“应能”“应该支持”等模糊词。替换为“返回状态码”“弹出按钮”“减少库存”“写入日志”。
5. 结果绑定阈值或断言：每个Then/结果必须有确切的可通过/不通过判断方式。例如：“订单状态变更为‘已退款’，且退款金额精确到分，精度不得超过0.01元偏差”。
6. 同态复核：由另一个人按照输入输出物清单逐字段核验句式的完整性。

输入输出物

责任边界

• 产品经理：提供业务上下文，确保GWT中的Given反映真实用户前置条件。
• 开发工程师：检查CBR中的条件是否在代码中已有精确的if/else对应。
• 测试工程师：为每条验收标准编写可执行的断言，并将结果写入测试用例管理系统。
• 质量保证负责人：最终签字前使用“可衡量性扫描矩阵”检查每条标准是否满足主语+动词+阈值三要素。

记录材料

异常处理

1. 条件之间存在交叉：当单个CBR中的条件分支超过3个时，必须拆分成多行独立标准；否则评审不通过。
2. 数值边界未定义：如果验收标准中出现“大量”“较快”“合理”等定性词，立即退回至产品经理处，补充精确数值后重新提交。
3. GWT中Given缺失上下文：When动作所需的前置状态必须在Given中完整声明；若无法声明则切换到CBR句式。
4. 责任边界冲突：当两条标准对同一指标有不同断言（例如“订单超时2s返回错误” vs “订单超时3s返回错误”），质量保证负责人介入优先级裁定。

验收标准组织正文（两种句式实操模板）

以下为实际项目中使用的标准填充模板与示例对比：

Given [前置上下文，具体化]
When [用户/系统] [可观察动作] [输入参数]
Then [可测量结果] [断言阈值]

Given 结算系统时间在每天 23:50:00–23:59:59
When 用户发起【当日订单汇总】请求
Then 返回的 totalBonus 精确到 0.01 元，且与数据库 sum 偏差 ≤ 0.01 元

Given 结算时间
When 用户请求汇总
Then 返回正确结果

条件：[外部或内部条件] [指标+上限/下限]
行为：[系统/模块] [响应的动作/API调用]
结果：[可验证状态/日志/返回值] [断言阈值]

条件：网关接收缓存队列深度 > 5,000 条
行为：网关启动请求降级（返回 200 与 {“status”: “degraded”}）
结果：5 秒内日志打印 “DEGRADE_TRIGGERED”，且非降级请求全部收到 200 正常响应

条件：队列太满
行为：系统降级
结果：请求没问题