业务状态流转测试实战教程

当前状态决定接下来允许做什么

订单处于“待支付”时可以支付或取消；进入“已支付”后可以履约或退款，却不应回到普通待支付。把当前状态、触发操作和目标状态整理成规则，专业上称为“状态迁移测试”，部分资料也称“状态机测试”。

建模步骤

1. 找出订单、支付单、退款单三个状态主体。
2. 列出每个主体所有可观察状态。
3. 标出用户操作、超时任务和渠道回调事件。
4. 为每次迁移写前置、目标状态和副作用。
5. 补上失败、重复、乱序和人工处理路径。

订单合法迁移表

合法迁移用例

• 当待支付订单完成支付时，订单进入已支付且支付记录成功。
• 当待支付订单超过有效期时，订单关闭并释放库存。
• 当已支付订单满足退款条件时，创建退款单并进入退款中。
• 当退款渠道返回成功时，订单进入已退款且金额一致。

每条迁移至少验证

• 事件前状态与权限满足前提。
• 接口返回 HTTP 200 后，业务码说明本次业务是否受理。
• 主体进入唯一目标状态。
• 库存、金额、优惠券和消息副作用正确。
• 页面能够展示最新状态且操作入口同步变化。

非法迁移与预期防线

执行方式

1. 通过测试接口或可控工具准备指定状态。
2. 发起在当前状态不允许的事件。
3. 确认接口拒绝且返回明确业务原因。
4. 核对订单及关联数据完全不变。
5. 检查审计日志和告警是否满足设计。

关键并发用例

• 当支付成功和超时关闭几乎同时发生时，订单只进入一个合法终态。
• 当用户 A 与客服同时发起退款时，只创建一笔有效退款。
• 当两个设备同时提交最后一件库存时，只允许一笔订单占用成功。
• 当支付回调与用户查询并发时，查询不得展示不存在的中间组合。

幂等检查

故障场景

• 当订单创建后库存扣减失败时，订单不进入可支付状态或被可靠关闭。
• 当支付成功但订单更新失败时，补偿任务根据支付事实推进订单。
• 当退款成功但消息发送失败时，可重试消息且不重复退款。
• 当补偿连续失败时，系统告警并进入可人工处理状态。

终态一致性断言

可执行核对

1. 保存订单号、支付单号和退款单号。
2. 查询接口返回的当前状态和业务码。
3. 核对数据库中的主体版本、金额和更新时间。
4. 检查库存、优惠券、消息和账务副作用。
5. 在最终一致性时间窗后再次查询。
6. 超时仍不一致时保存证据并触发告警。

练习

1. 画出待支付、已支付、已取消、退款中和已退款。
2. 为每条合法流转写一条“当……时，……”用例。
3. 补充四条非法流转并验证数据不变。
4. 设计支付与关单、退款与重复回调两个竞争场景。
5. 验证下单、支付和退款的幂等键。
6. 模拟订单更新失败并检查补偿与告警。