把"体验流畅"改成可执行断言：我用 Given-When-Then 把一次迭代的验收扯皮从 23 次降到 3 次

本文从一个 11 人产研小组的真实迭代复盘出发，把"验收标准怎么写才能不被扯皮"这件事拆成可复现的步骤与模板。

一、现象与背景：验收会上一句"我觉得不够流畅"，能烧掉多少人天

先上数字。我们小组 5 后端、4 前端、2 测试，2024 年 Q3 一个 6 周迭代里，验收环节前后发生了 23 次"扯皮"——定义是：功能已按需求文档实现，但验收时仍被产品或测试打回、且双方各执一词、需要拉三方仲裁的对话。23 次里，17 次的根因是同一句话的变体："体验不够流畅""边界没处理""文案不对"。

这些词单拎出来都对，但它们没法判断"过还是不过"。一个被低估的成本是：23 次扯皮平均每次消耗 40 分钟三方时间，合计约 15.3 人时，外加 6 个需求被顺延到下个迭代，平均延期 2.5 天。真正贵的不是吵，是吵完还要回滚重做。

二、根因分析：为什么形容词一定会扯皮

拆开看，形容词型验收标准有三个结构性缺陷：

1. 判定主体是"人"而不是"规则"。"流畅"由谁定义、在什么机器上、加载多少数据时算流畅？没有主体，就没有可重复的判定。
2. 输入域是空的。"订单列表要正确"——多长的列表、有没有分页、空态、网络 200ms 抖动时都算"正确"吗？输入域不封闭，边界就永远补不完。
3. 可证伪性为零。"体验要好"没法写出一条测试用例去证明它"不好"。工程上凡是不可证伪的要求，最后都会退化成"领导觉得"。

对照一下反例：一条好的验收标准，本质上是一个三段式断言——给定某个前置状态（Given），执行某个动作（When），观察到某个可测量结果（Then）。它的判定不依赖任何人的主观感受，测试同学可以直接翻译成用例。

三、具体做法：一套可直接抄的模板

3.1 把每条需求翻译成"四要素"

我在迭代里推了一个硬性规则：需求文档里每条验收标准必须包含四个要素，缺一项打回。

| 要素 | 问题 | 反例 | 正例 | |---|---|---|---| | 前置数据规模 | 多少条数据？ | 列表要流畅 | 列表加载 500 条记录（P95 数据量） | | 触发动作 | 用户做什么？ | 支持搜索 | 输入"张"并按回车 | | 可观测结果 | 看到什么？ | 结果正确 | 首屏返回 ≤30 条，耗时 P95 ≤ 800ms | | 失败行为 | 出错时如何？ | 有提示 | Toast 显示"网络异常"，列表保留旧数据 |

3.2 一个真实需求的改写过程

原需求（迭代 #42，优惠券核销页）：

"用户核销优惠券时，体验要流畅，失败要有友好提示。"

改写后（进评审的版本）：

AC-1: Given 用户已登录且账户下有 ≥1 张可用券
      When  点击"立即核销"
      Then  按钮进入 loading 态，重复点击无效（防抖窗口 1000ms）
      And   接口 /coupon/redeem 返回 200 后 500ms 内跳转成功页

AC-2: Given 同一张券被并发核销（另一终端已先成功）
      When  本端接口返回 409 CONFLICT
      Then  展示 Toast"该券已被使用"，停留当前页，券列表实时刷新

AC-3: Given 接口超时（>3000ms 无响应）
      When  前端触发 timeout
      Then  展示"网络异常，请重试"，按钮恢复可点击，不自动跳走

三条 AC，覆盖正常路径、并发冲突、网络超时——这三类恰好是支付/券类场景 90% 以上的线上问题来源。

3.3 给测试同学的翻译约定

我们约定 AC 里每个 Then/And 子句都是一条独立用例，用例名直接抄 AC 编号 + 子句原文，比如 AC-2-Then-Toast。这样测试不用"理解意图"，只做机械翻译，用例编写时间从平均 25 分钟/条降到 9 分钟/条（2 个迭代抽样 40 条统计）。

四、踩过的坑（3 个，都很反直觉）

坑 1：标准写得太严，开发会"绕过"而不是"做到"。 最早我把首屏耗时定成 P95 ≤ 400ms，结果开发直接在本地缓存 5 分钟，"达标"了，但数据一致性被破坏。教训：可观测结果要锚定用户可感知的行为，而不是某个中间指标；耗时类指标必须同时写"数据新鲜度"作为约束。

坑 2：把实现细节写进 AC，等于锁死了重构空间。 曾写过"Then 后端调用 Redis 的 INCR 命令"，后来要换组件时被测试同学拿这条 AC 拦下来。AC 应该只描述边界上的输入输出，不描述内部用了什么。

坑 3：失败行为最容易漏，而线上事故 70% 出在失败路径。 23 次扯皮里 14 次是"出错时应该怎样"没说清。我把"每条 AC 必须配一条失败路径 AC"设为硬规则后，下一迭代失败路径相关扯皮从 14 次降到 2 次。

五、结论与可复用清单

结论一句话：验收标准不是给开发看的说明，而是给测试执行的断言。 判定权必须从"人"转移到"规则"，扯皮才会消失。

可复用清单（可以直接贴进你们的需求模板）：

1. 每条验收标准 = Given（前置 + 数据规模）+ When（动作）+ Then（可观测结果）+ 失败路径。
2. 每个 Then 子句必须可翻译成一条独立测试用例，不能依赖"体验""友好""流畅"这类词。
3. 耗时类指标必须同时约束数据新鲜度，防止用缓存"达标"。
4. AC 只写边界输入输出，不写内部实现（缓存策略、具体组件、SQL 写法都不写）。
5. 上线前用"23 次扯皮"这个指标复盘：目标是从两位数压到个位数。

我们的数据：落地两个迭代后，验收扯皮从 23 次降到 3 次，需求平均延期从 2.5 天降到 0.7 天，测试用例编写时间降 64%。数字不夸张，但足够让"怎么写验收标准"这件事从玄学变成工程。