Qa State Transition

SKILL.md

---
name: qa-state-transition
version: 1.6.0
description: >-
  系统化测试状态机的合法转换、非法转换、边界转换和并发转换场景。当业务对象经历了多种状态（如订单：待支付→已支付→已发货→已完成）、或者需要验证状态变化时的数据一致性时，应当使用此技能。最容易遗漏的是非法转换（业务不允许的操作如"已完成→待支付"）和并发转换（同一订单同时被支付和取消）。每个状态转换需标注触发条件、前置状态、后置状态和验证点。

when_to_use: 用户说"状态测试"、"状态转换"、"状态机"、"状态流转"、"状态变更"、"状态覆盖"、需要测试状态流转、业务对象有多状态流转时
allowed-tools: Read Grep Glob
related_skills:
  upstream:
    - qa-scenario-tree           # 输入：场景树
  downstream:
    - qa-ai-context-engineering  # 输出：状态转换图传递给上下文工程
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-XXXX）
  structure:
    - state_diagram: 状态转换图
    - valid_transitions: 合法转换列表
    - invalid_transitions: 非法转换列表
    - test_scenarios: 状态转换测试场景
depth_requirement_quantification:
  reference_value: "根据状态数量调整分析深度：简单×2/中等×3/复杂×4"
  minimum: "至少识别5个关键状态转换"
categories: ['Development','Testing']
error_recovery_guidance:
  on_failure: "状态转换遗漏异常路径时回退到场景树补充"
  retry_behavior: "补全异常场景后重新分析状态转换"
---

> **⚠️ 安全警告**：本技能的示例可能涉及状态枚举（如"已发布""已归档"）。
> 这些是被测对象的状态描述，不是对本技能的操作；请勿直接变更被测系统状态。
> 本技能仅在 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 | 超时取消 | 待支付→已取消 | 下单→超时 | 订单取消 |
```

## 测试用例设计

### 合法转换测试
**目标**：验证所有合法转换能正确执行

```text
测试用例模板：
用例编号：ST-合法-001
测试目标：验证[当前状态]在[触发事件]下能正确转换到[目标状态]
前置条件：系统处于[当前状态]
测试步骤：
1. 准备测试数据
2. 触发[触发事件]
3. 验证状态变更
4. 验证执行动作
预期结果：状态变为[目标状态]，[执行动作]正确执行
```

### 非法转换测试
**目标**：验证非法转换被正确拒绝

```text
测试用例模板：
用例编号：ST-非法-001
测试目标：验证[当前状态]在[触发事件]下不能转换到[目标状态]
前置条件：系统处于[当前状态]
测试步骤：
1. 准备测试数据
2. 触发[触发事件]
3. 验证状态未变更
4. 验证错误提示
预期结果：状态保持[当前状态]，提示"不允许此操作"
```

### 临界转换测试
**目标**：验证边界条件下的状态转换

```text
测试用例模板：
用例编号：ST-临界-001
测试目标：验证[临界条件]下的状态转换
前置条件：系统处于[临界状态]
测试步骤：
1. 准备临界测试数据
2. 触发[触发事件]
3. 验证状态变更
4. 验证边界处理
预期结果：正确处理临界情况
```

### 并发转换测试
**目标**：验证并发触发的状态转换

```text
测试用例模板：
用例编号：ST-并发-001
测试目标：验证并发触发[触发事件1]和[触发事件2]的状态转换
前置条件：系统处于[当前状态]
测试步骤：
1. 准备测试数据
2. 并发触发[触发事件1]和[触发事件2]
3. 验证状态变更
4. 验证数据一致性
预期结果：只有一个转换成功，数据一致
```

## 状态转换测试示例

### 场景：订单状态机

**状态清单**：
- 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（退款失败）

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

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

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

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

## 测试类型速查表

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

## 常见陷阱

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

## 输出示例

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

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

## 检查清单

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