⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

⚠️ 安全警告：本技能的示例可能涉及状态枚举（如"已发布""已归档"）。 这些是被测对象的状态描述，不是对本技能的操作；请勿直接变更被测系统状态。 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

状态转换测试

核心原则

单接口测试都能过，业务流一起跑就崩——状态是关键。覆盖状态/转换/路径识别、合法/非法/临界/并发转换测试。每个转换需标注触发条件、前置状态、后置状态和验证点。

状态机测试要素

要素1：状态识别

状态识别方法：
1. 业务状态：待处理、处理中、已完成、已取消
2. 数据状态：草稿、已发布、已归档
3. 用户状态：未激活、正常、冻结、注销
4. 系统状态：正常、降级、熔断、重启

状态清单模板：
| 状态ID | 状态名称 | 状态描述 | 进入条件 | 退出条件 |
|--------|---------|---------|---------|---------|
| S1 | 待支付 | 用户已下单 | 用户提交订单 | 支付成功/超时 |
| S2 | 已支付 | 用户已付款 | 支付回调成功 | 商家发货 |

要素2：转换识别

转换识别方法：
1. 合法转换：业务允许的状态变更
2. 非法转换：业务不允许的状态变更
3. 临界转换：刚好满足条件的转换
4. 并发转换：同时触发多个转换

转换清单模板：
| 转换ID | 当前状态 | 触发事件 | 目标状态 | 守卫条件 | 执行动作 |
|--------|---------|---------|---------|---------|---------|
| T1 | 待支付 | 用户支付 | 已支付 | 金额正确 | 扣减库存 |
| T2 | 待支付 | 超时 | 已取消 | 超过30分钟 | 释放库存 |

要素3：路径识别

路径识别方法：
1. 主路径：正常业务流程
2. 分支路径：条件分支
3. 异常路径：异常恢复
4. 循环路径：状态循环

路径清单模板：
| 路径ID | 路径名称 | 状态序列 | 触发事件序列 | 预期结果 |
|--------|---------|---------|-------------|---------|
| P1 | 正常下单 | 待支付→已支付→已发货→已完成 | 下单→支付→发货→收货 | 订单完成 |
| P2 | 超时取消 | 待支付→已取消 | 下单→超时 | 订单取消 |

加载时机

测试用例设计的完整内容已下沉至 references/transition-cases.md，避免每次触发都占用上下文。

状态转换测试示例

场景：订单状态机

状态清单：

• S1：待支付
• S2：已支付
• S3：已发货
• S4：已完成
• S5：已取消
• S6：退款中
• S7：已退款

转换清单：

• T1：S1→S2（用户支付）
• T2：S1→S5（超时取消）
• T3：S2→S3（商家发货）
• T4：S2→S6（用户申请退款）
• T5：S3→S4（用户确认收货）
• T6：S3→S6（用户申请退款）
• T7：S6→S7（退款成功）
• T8：S6→S2（退款失败）

测试用例（编号格式 ST-{类型缩写}-{三位序号}，类型缩写：VALID 合法 / INVALID 非法 / EDGE 临界 / CONC 并发）：

合法转换测试：
- ST-VALID-001：待支付→已支付（支付成功）
- ST-VALID-002：待支付→已取消（超时）
- ST-VALID-003：已支付→已发货（商家发货）
- ST-VALID-004：已支付→退款中（申请退款）
- ST-VALID-005：已发货→已完成（确认收货）
- ST-VALID-006：已发货→退款中（申请退款）
- ST-VALID-007：退款中→已退款（退款成功）
- ST-VALID-008：退款中→已支付（退款失败）

非法转换测试：
- ST-INVALID-001：已完成→已支付（不允许）
- ST-INVALID-002：已取消→待支付（不允许）
- ST-INVALID-003：已退款→已支付（不允许）

临界转换测试：
- ST-EDGE-001：支付刚好在超时前1秒完成
- ST-EDGE-002：库存刚好剩1件时下单

并发转换测试：
- ST-CONC-001：同一订单同时支付和取消
- ST-CONC-002：同一订单同时支付和申请退款

测试类型速查表

常见陷阱

1. 只测正向不测非法：验证了所有状态转换通过，但没测非法转换拒绝 → 非法转换漏测会导致安全风险
2. 遗漏中间态：只关注了初始态和终态，忽略了"处理中""待确认"等中间态 → 每个状态转换路径都必须遍历
3. 临界条件不测：只看正常条件满足，不测刚好在边界时是否触发/阻断 → 临界值是状态转换Bug高发区
4. 并发转换不测：假设状态转换是串行的 → 并发触发同对象状态转换必须验证数据一致性
5. 守卫条件不验证：只测事件触发，不测守卫条件不满足时是否真正阻断 → 每条转换的守卫条件必须单元测试

输出示例

好示例：测试电商订单状态机

输入：订单状态（待支付→已支付→已发货→已签收）
✓ 合法转换：
  - 待支付→已支付（支付成功回调）→验证：金额正确、库存扣减
  - 待支付→已取消（用户取消）→验证：库存释放、退款触发
✓ 非法转换：
  - 待支付→已发货（跳过支付）→验证：系统阻断、提示"请先完成支付"
  - 已退款→待支付（不允许）→验证：系统拒绝、提示"订单已关闭"
✓ 临界转换：
  - 支付超时前1秒完成支付 → 验证：允许通过
  - 库存刚好剩1件时2人同时下单 → 验证：仅1人成功
✓ 并发转换：
  - 同一订单在两设备上同时支付 → 验证：仅1次成功，不会重复扣款
  → 测试方案覆盖全面，没有遗漏

坏示例：测试电商订单状态机

✗ 新建订单→付款→发货→收到货
  - 只测了主路径Happy Path，没测非法转换（如待支付时不可直接发货）
  - 没测临界条件（支付超时边界、库存边界）
  - 没测并发（同一订单同时支付和取消）
  → 结果：上线后出现"未支付订单被发货"、并发支付导致重复扣款

检查清单

状态转换测试完成后检查：

• 所有状态是否识别？
• 所有合法转换是否测试？
• 所有非法转换是否验证？
• 临界条件是否覆盖？
• 并发场景是否考虑？
• 数据一致性是否验证？