qa-state-transition

SKILL.md

---
name: qa-state-transition
description: >-
  系统化测试状态机的合法转换、非法转换、边界转换和并发转换场景。当业务对象经历了多种状态（如订单：待支付→已支付→已发货→已完成）、或者需要验证状态变化时的数据一致性时，应当使用此技能。最容易遗漏的是非法转换（业务不允许的操作如"已完成→待支付"）和并发转换（同一订单同时被支付和取消）。每个状态转换需标注触发条件、前置状态、后置状态和验证点。 触发场景：状态测试、状态转换、状态机、状态流转、状态变更、状态覆盖、业务对象有多状态流转时。 Use when the user asks about: state machine testing — legal, illegal, boundary, and concurrent state transitions, and data consistency across them.
license: MIT
allowed-tools: Read Grep Glob
metadata:
  display-name: "State Transition"
  version: "1.8.0"
  when-to-use: "用户说\"状态测试\"、\"状态转换\"、\"状态机\"、\"状态流转\"、\"状态变更\"、\"状态覆盖\"、需要测试状态流转、业务对象有多状态流转时"
  related-skills: "{\"upstream\":[\"qa-scenario-tree\"],\"downstream\":[\"qa-ai-context-engineering\"]}"
  references: "[\"references/transition-cases.md\"]"
  input-format: "{\"required\":[{\"name\":\"场景树\",\"type\":\"object\",\"description\":\"来自qa-scenario-tree的场景树\"},{\"name\":\"需求解构表\",\"type\":\"object\",\"description\":\"来自qa-req-deconstruction的需求解构结果\"}],\"optional\":[{\"name\":\"风险评估\",\"type\":\"object\",\"description\":\"来自qa-risk-intuition的风险评估\"}]}"
  output-format: "{\"traceability\":[\"每个状态转换带唯一ID（ST-XXXX）\",\"关联场景ID：SC-{场景模块缩写}-{序号}\"],\"structure\":[\"覆盖率：标注口径（基于现有需求/输入文档），禁止\\\"全覆盖/100%\\\"绝对化表述；缺失模块标注\\\"未覆盖+原因\\\"\",{\"state_diagram\":\"状态转换图\"},{\"valid_transitions\":\"合法转换列表\"},{\"invalid_transitions\":\"非法转换列表\"},{\"test_scenarios\":\"状态转换测试场景\"}]}"
  error-recovery-guidance: "{\"on_failure\":\"状态转换遗漏异常路径时回退到场景树补充\",\"retry_behavior\":\"补全异常场景后重新分析状态转换\"}"
  categories: "[\"Development\",\"Testing\"]"
  depth-requirement: "{\"reference_value\":\"根据状态数量调整分析深度：简单×2/中等×3/复杂×4\",\"minimum\":\"至少识别5个关键状态转换\"}"
---

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

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

# 状态转换测试

## 核心原则

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

## 状态机测试要素

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

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

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

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

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

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

## 加载时机

| 什么时候读 | 读哪个 |
|-----------|--------|
| 设计合法/非法/临界/并发转换用例时 | [`references/transition-cases.md`](references/transition-cases.md) |

> `测试用例设计`的完整内容已下沉至 `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 并发）：
```text
合法转换测试：
- 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：同一订单同时支付和申请退款
```

## 测试类型速查表

| 测试类型 | 覆盖目标 | 数量参考 | 未覆盖风险 |
|---------|---------|---------|---------|
| 合法转换 | 所有正向状态流转 | 状态数×2 | 功能不可用 |
| 非法转换 | 所有不允许的操作 | 状态数×1.5 | 安全漏洞 |
| 临界转换 | 刚好满足/不满足转换条件 | 每条转换×1 | 边界Bug |
| 并发转换 | 同时触发多个转换 | 高并发状态×2 | 数据不一致 |

## 常见陷阱

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

## 输出示例

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

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

## 检查清单

状态转换测试完成后检查：
- [ ] 所有状态是否识别？
- [ ] 所有合法转换是否测试？
- [ ] 所有非法转换是否验证？
- [ ] 临界条件是否覆盖？
- [ ] 并发场景是否考虑？
- [ ] 数据一致性是否验证？