43 条验收标准全绿，第一条用户旅程还是挂了：跨模块主流程的 5 项旅程级验收与状态机不变量清单

结论先行：每个模块的验收标准写得再漂亮，也拦不住"合法状态 + 合法状态 = 非法组合"这类跨模块缺陷。单需求验收回答的是"这个功能对不对"，旅程级验收回答的才是"用户这条主路通不通"——后者在绝大多数团队的验收单上根本没有 owner。这篇给一套可直接抄进迭代验收流程的 5 项旅程级验收动作，核心是把状态机不变量写成可执行断言。

一、现象与背景：模块全绿 ≠ 主流程可用

先给规模。我带过一个 9 人产研小组（4 后端、3 前端、2 测试），维护一套 B 端 SaaS 采购系统：选品 → 购物车 → 优惠券 → 支付 → 发票，共 5 个模块、6 个微服务（Java 17 + Spring Boot 3.2 + MySQL 8.0）。

2024 年 Q4 一个 6 周迭代，累计提了 18 个需求、43 条验收标准（AC），每条都按 Given-When-Then 写了四要素（前置数据 / 触发动作 / 可观测结果 / 失败行为，写法参考 postId 900 的那套模板）。验收会上 43 条全过，我们排了上线。

结果上线前最后一次"真用户走一遍"的 smoke 里，主流程第 1 条就挂了：选品页选了 3 个 SKU → 加购物车 → 用了一张满减券 → 进支付页，应付金额和购物车页显示差 2.5 元，且这个差异 100% 复现。当时离周五封版还有 1 天，最后定位、修复、回归花了 1.5 人天，整个版本顺延 2 天。

更扎心的是复盘数据：那 43 条 AC 全部落在 5 个模块的各自边界内，没有一条 AC 的输入域跨了两个模块的边界。而这次事故的根因恰恰长在两个模块的边界上。

二、原理：为什么"每个模块都验收了"主流程还是漏

拆成三个机制，每个都能对应到具体翻车方式：

1. 状态组合爆炸，验收只覆盖了"单维合法"。 拿这次 2.5 元差异举例：优惠券模块的口径是"满减后金额向下取整到 0.5 元"（99.99 − 20 = 79.99 → 79.5），支付模块的口径是"实付金额保留 2 位小数、四舍五入"（79.5 → 79.50，但支付网关侧又对 79.5 做了一次"最小单位 1 分向上取整"）。两个模块各自的 AC 都验证了"自己取整规则正确"，但没有任何一条 AC 断言"购物车展示价 = 支付页应付价 = 网关扣款价"这条跨模块等式。单维合法 × 单维合法，组合起来非法——这是分布式系统里最经典的"局部正确、全局错误"。

2. 状态机有 11 个合法态，但跨模块的非法组合没人断言。 把 5 个模块的关键状态拉出来：购物车 EMPTY/FULL/LOCKED、券 UNUSED/LOCKED/USED/EXPIRED、订单 CREATED/PAID/SHIPPED/COMPLETED/CANCELLED、支付 INIT/PROCESSING/SUCCESS/FAILED、发票 NONE/APPLIED/ISSUED。单模块内每个态的转移都合法，但跨模块存在至少 5 个"各自合法、组合非法"的组合，比如：

| 订单状态 | 支付状态 | 组合含义 | 是否合法 | |---|---|---|---| | PAID | PROCESSING | 订单已确认但支付未终态 | 非法（30s 窗口内会触发发票模块误申请） | | CANCELLED | SUCCESS | 订单取消但钱已扣 | 非法（退款链路没接） | | CREATED | SUCCESS | 未创建订单却支付成功 | 非法（网关回调乱序） |

我们的发票模块 AC 里写的是"Given 订单状态 = PAID，When 申请发票，Then 成功"——这条 AC 本身没错，但它默认了 PAID 必然蕴含支付已终态，这个蕴含关系没有任何模块负责维护，也没有任何 AC 断言它。

3. 验收的"判定主体"停在模块 owner，没有人对旅程负责。 43 条 AC 分属 4 个后端 + 3 个前端 + 2 个测试，每条都有 owner、都能判定。但"选品→支付→发票"这条旅程没有 owner：它不属于任何一条 AC，于是它不属于任何人。这不是测试的问题（测试 2 个人已经扛了 43 条 AC 的翻译与执行），是产品侧没有把"旅程"定义成一等验收对象。

三、具体做法：5 项旅程级验收动作（可直接抄进迭代流程）

3.1 动作一：画状态组合矩阵，把非法组合写成断言

每个迭代评审前，对涉及状态流转的需求，把跨模块状态两两配对，输出组合矩阵。判定标准：每个"非法组合"必须对应一条可执行断言（不是"要注意"，是断言）。这次事故对应的断言长这样：

# journey-invariants.yaml —— 挂进 CI，主流程回归时逐条执行
journey: select-cart-coupon-pay-invoice
invariants:
  - id: J-INV-01
    name: 价格三处一致
    assert: cart.display_amount == checkout.payable_amount == gateway.charge_amount
    tolerance_cents: 0          # 资金类差异容忍度必须为 0
  - id: J-INV-02
    name: 发票申请前置蕴含
    rule: order.status == PAID => payment.status in (SUCCESS, REFUNDED)
    violation_action: reject_invoice_apply_and_alert
  - id: J-INV-03
    name: 取消后无终态扣款
    rule: order.status == CANCELLED => payment.status != SUCCESS
    violation_action: trigger_refund_job

关键细节：tolerance 对资金类必须是 0。我见过一个团队把"金额差异 ≤ 1 分"写成可接受，理由是"四舍五入误差"——这个口子开出去，三个月后一定会长出 2.5 元。

3.2 动作二：给每条主旅程指定一个"旅程 owner"，且必须是产品侧

规则很简单：旅程 owner 不是测试（测试负责执行），是写需求的那个 PM。判定标准是"这条旅程上任何一个断言挂了，owner 要在 30 分钟内说清楚哪个模块的哪条 AC 漏了"。说不清楚，说明这条旅程的 AC 分解有问题，回评审。

落地成本比想象低：我们 5 条主旅程，每条 owner 只多花 30 分钟画组合矩阵 + 认领 3~5 条不变量断言，比事后 1.5 人天事故修复便宜一个量级。

3.3 动作三：旅程回归脚本，断言"最终态"而不是"每步 200"

用 Playwright（我们用的是 1.45，Node 20）写端到端脚本，但断言全部打在状态终态和不变量上，不逐步断言 HTTP 200：

// e2e/checkout-main-flow.spec.ts
test('主流程：选品→用券→支付→发票，终态自洽', async ({ page }) => {
  await page.goto('/select');
  await page.getByTestId('sku-1001').click();
  await page.getByTestId('sku-1002').click();
  await page.getByRole('button', { name: '加入购物车' }).click();

  const cartAmount = await page.getByTestId('cart-total').innerText();

  await page.getByTestId('coupon-50').click();          // 用券
  await page.getByRole('button', { name: '去支付' }).click();

  const payAmount = await page.getByTestId('payable').innerText();

  // 核心断言：跨模块等式，而不是"支付页渲染成功"
  expect(parseCents(payAmount)).toBe(parseCents(cartAmount));

  await page.getByRole('button', { name: '确认支付' }).click();
  await page.waitForURL('**/pay-result**', { timeout: 15000 });

  // 终态蕴含断言：发票可申请 ⇒ 支付已终态
  const inv = await api.get(`/api/invoice/status?order=${orderId}`);
  const pay = await api.get(`/api/payment/status?order=${orderId}`);
  expect(pay.data.status).toBe('SUCCESS');
  expect(inv.data.applicable).toBe(true);
});

挂在 CI 的 journey-regression job，每个 PR 必跑，不是发布前才跑。这条 job 我们平均跑时 96 秒，5 条旅程共 14 个终态断言。

3.4 动作四：造数清单里加"旅程级种子数据"

单模块造数（边界值、临界态，方法可参考 postId 1588 的三清单）解决"模块内不漏"，但旅程级还差一层：同一条旅程必须用 3 组种子数据各跑一遍——

| 组 | 数据特征 | 本次踩的坑 | |---|---|---| | A 组 | 金额整元、无券、单人单 SKU | 全绿（假绿） | | B 组 | 金额带小数（99.99）、用券、多 SKU | 2.5 元差异在这组复现 | | C 组 | 券在旅程中途过期（造一个 expire_at = now() + 2min 的券，走到支付页时已过期） | 支付页显示可用、下单时 400 |

A 组全绿是必然的——常规值走的是所有模块都测过的主干。真正的信号在 B/C 组。

3.5 动作五：上线后 48h 的"旅程指标"，不是大盘指标

大盘 DAU、错误率对主流程事故迟钝（2% 流量挂了大盘只抖 2 个点，这个机制站内 postId 1620 讲得很透）。给主流程加两个专属指标：

旅程完成率：pay_success_uv / cart_enter_uv，我们基线 61.3%，告警阈值 < 55% 持续 15 分钟；
旅程卡死率：进入某步骤后 5 分钟无后续动作的 UV 占比，阈值 > 8%。

这两个指标是旅程粒度的漏斗，比"支付模块错误率"敏感得多——因为跨模块差异（比如价格不一致）往往不产生错误，只产生"用户犹豫后离开"，只有漏斗指标能接住。

四、踩过的坑（4 个反直觉之处）

"每个模块都说没问题"恰恰是最危险的信号。 它意味着问题长在模块之间——而模块之间没有任何模块负责。我们复盘 5 起跨模块事故，4 起的复盘结论都是"两边代码单独看都没错"。
旅程 owner 给测试是错的。 测试没有动力把一条旅程的 AC 分解问题抛回产品侧（那是"打脸"），而 PM 作为需求作者有义务对"旅程级 AC 分解完整性"负责。我们试过让测试当 owner，3 个迭代里有 2 个的非法组合断言漏写了，没人发现。
只测 happy path 的旅程脚本 = 没用。 真实流量里 B/C 组（带券、带小数、券中途失效）占 34%（我们拉了 30 天埋点统计），但 happy path 脚本只覆盖 A 组。旅程脚本的价值就在非主干分支，主干各模块 AC 已经覆盖了。
用同一个测试账号跑旅程回归会掩盖并发态问题。 支付回调乱序（CREATED + SUCCESS 组合）只有两个请求并发 300ms 窗口内才复现，单线程脚本永远跑不出来。我们后来在 C 组造数里显式注入了"回调延迟 200ms"的故障注入（Chaos Mesh 的 delay 规则），这个组合才第一次被断言拦住。

五、结论与可复用清单

一句话：验收的对象从"需求"升一级到"旅程"，判定标准从"每步对"升到"终态自洽 + 不变量成立"，owner 从模块 owner 升到旅程 owner（PM）。三者缺一，跨模块缺陷还是会漏。

可复用清单（可直接抄进迭代 checklist）：

[ ] 每条主旅程有且仅有一个 PM 侧 owner，评审会上点名认领
[ ] 跨模块状态组合矩阵已画，每个非法组合有对应断言（YAML 挂 CI）
[ ] 资金类金额等式断言的 tolerance = 0
[ ] 旅程回归脚本断言终态而非逐步 200，每个 PR 必跑
[ ] 旅程种子数据至少 3 组（整元无券 / 小数带券 / 临界态失效）
[ ] 并发窗口组合（回调乱序等）有故障注入用例
[ ] 上线后 48h 盯旅程完成率 + 卡死率，不是大盘错误率
[ ] 任一不变量断言挂了，owner 能在 30 分钟内定位到漏掉的 AC

最后补一句取舍：这套动作会增加每个迭代约 0.5~1 人天的评审与造数成本，但按我们 6 个季度 5 起跨模块事故、平均每起 1.5~3 人天修复 + 2 天版本顺延算，账是划算的。如果你们团队单迭代跨模块需求 < 3 个，可以先只做 3.1（组合矩阵 + 不变量断言）这一项，成本最低、收益最直接。

0赞 0收藏 0评论 0浏览