可复用的验收标准示例

快速结论

把验收标准写成输入、触发、结果三段式。只要能让 QA 直接提取测试条件，这条验收标准才算真正可用。

你应该先看什么

• 主流程要说明成功信号。
• 失败路径要说明错误反馈和状态保持。
• 权限、重试和幂等要单独写，不要混在同一条里。

可直接复用的示例

- Given 用户有编辑权限
- When 提交有效表单
- Then 系统保存成功并记录审计日志

- Given 用户无编辑权限
- When 点击保存
- Then 返回 403 且数据不变

垂直领域示例

认证和数据更新的示例建立了基本模式。以下领域特定示例展示了相同结构在高风险流程中的应用——支付、搜索和异步通知。在这些场景中，精确表述至关重要。

# 支付授权
- Given 购物车金额为 ¥349.00，账户有有效绑定卡
  When 用户提交结账
  Then 支付网关被精确扣款 ¥349.00
  And order.status 变更为 payment_captured
  And 确认邮件事件被发布

- Given 卡片余额不足
  When 用户提交结账
  Then 返回 402 含 payment_failed 错误码
  And order.status 保持 pending
  And 不记录任何扣款

# 带过滤的搜索
- Given 200 个有效商品，其中 50 个标签为"促销"
  When 用户请求 GET /products?tag=促销
  Then 响应恰好包含 50 个商品
  And 每个商品的 tag 包含"促销"
  And total_count 字段等于 50

# 异步通知
- Given 用户的 email_notifications = enabled
  When 订单状态变更为已发货
  Then 5 秒内通知任务入队
  And 任务 payload 包含 orderId、userId 和快递单号

支付标准必须写明精确金额、状态流转和副作用（邮件事件、审计记录）。搜索标准必须写明返回什么、排除什么。异步标准必须写明时间约束和 payload 完整性——不能只写"已发送通知"。

非功能性验收标准

功能标准定义系统做什么，非功能标准定义系统做得怎样。两类标准都需要可观测、可判断通过/失败的陈述——但非功能标准经常用无法测试的语言书写，如"快速"、"可靠"、"可扩展"。

• 性能："Given 500 个并发用户，When 每人提交搜索请求，Then p95 响应时间低于 400ms。"
• 可用性："Given 30 天统计窗口，When 测量正常运行时间，Then 可用性达到或超过 99.5%。"
• 错误预算："Given 错误率超过 1%，When 持续超过 5 分钟，Then 2 分钟内触发 PagerDuty 告警。"
• 数据保留："Given 用户注销请求，When 处理完成，Then 24 小时内所有 PII 字段清零并在审计日志中确认。"

非功能标准应与行为标准写在同一份规格文档中——而非放在单独的"NFR 文档"里评审一次后就束之高阁。分离会导致实现团队将其视为可选项，最终在生产中以故障的形式被发现。

标准如何在 Sprint 中演进

实现前写下的标准是假设。它们不应在 Sprint 中随意变更，但当实现揭示规格阶段未能预见的约束时，需要走结构化的修订流程——不是悄悄弱化标准，而是记录变更并获得原始审批人的确认。

• 如果标准被收窄（覆盖的场景减少），必须通知 QA 并更新测试计划。
• 如果标准被扩展（增加更多行为），变更需要重新经过规格评审，而不仅仅是在 PR 里加一条评论。
• 如果标准被推迟，它应成为下一个 Sprint 的追踪事项——而非静默遗漏。

实现结束后标准保持不变，是前期规格工作质量高的体现。编码过程中标准频繁修改，则说明规格评审不够充分或过于仓促。

验收标准何时应该阻塞开发

不是每条验收标准都必须在编码前完美，但有些缺口应该直接阻塞实现：权限路径不清、状态变更没有失败结果、异步任务没有可观测信号、数据写入没有幂等规则，或产品目标和测试判断互相矛盾。继续开发只会把这些问题推迟到联调或上线阶段。

低风险的不确定项可以带条件推进，例如非关键文案、次要空状态或需要预发布环境测量的性能阈值。但条件必须写进 ticket，指定负责人和解决时间，不能只停留在会议口头约定里。

落地建议

从下次sprint开始，选一个觉得"说清楚了"的需求，把它改成三条 Given/When/Then，再让开发和QA各自理解一遍。如果理解不一致，说明验收标准确实起到了作用。

评审结束时，把每条标准后面补一个证据类型：自动化测试、手工验证、日志、截图、接口响应或监控指标。没有证据类型的标准，通常还不是可验收的标准。

这一步也能帮助团队区分“想要的行为”和“已经能验证的行为”。

相关文章

• Given/When/Then 模板
• 如何编写可测试软件规格
• 编写 QA 可测试的边界用例