> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（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 |
> 测试用例设计的完整内容已下沉至 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：同一订单同时支付和申请退款
测试类型速查表
| 测试类型 | 覆盖目标 | 数量参考 | 未覆盖风险 |
|---|---|---|---|
| 合法转换 | 所有正向状态流转 | 状态数×2 | 功能不可用 |
| 非法转换 | 所有不允许的操作 | 状态数×1.5 | 安全漏洞 |
| 临界转换 | 刚好满足/不满足转换条件 | 每条转换×1 | 边界Bug |
| 并发转换 | 同时触发多个转换 | 高并发状态×2 | 数据不一致 |
常见陷阱
- 只测正向不测非法：验证了所有状态转换通过，但没测非法转换拒绝 → 非法转换漏测会导致安全风险
- 遗漏中间态：只关注了初始态和终态，忽略了"处理中""待确认"等中间态 → 每个状态转换路径都必须遍历
- 临界条件不测：只看正常条件满足，不测刚好在边界时是否触发/阻断 → 临界值是状态转换Bug高发区
- 并发转换不测：假设状态转换是串行的 → 并发触发同对象状态转换必须验证数据一致性
- 守卫条件不验证：只测事件触发，不测守卫条件不满足时是否真正阻断 → 每条转换的守卫条件必须单元测试
输出示例
好示例：测试电商订单状态机
输入：订单状态（待支付→已支付→已发货→已签收）
✓ 合法转换：
- 待支付→已支付（支付成功回调）→验证：金额正确、库存扣减
- 待支付→已取消（用户取消）→验证：库存释放、退款触发
✓ 非法转换：
- 待支付→已发货（跳过支付）→验证：系统阻断、提示"请先完成支付"
- 已退款→待支付（不允许）→验证：系统拒绝、提示"订单已关闭"
✓ 临界转换：
- 支付超时前1秒完成支付 → 验证：允许通过
- 库存刚好剩1件时2人同时下单 → 验证：仅1人成功
✓ 并发转换：
- 同一订单在两设备上同时支付 → 验证：仅1次成功，不会重复扣款
→ 测试方案覆盖全面，没有遗漏
坏示例：测试电商订单状态机
✗ 新建订单→付款→发货→收到货
- 只测了主路径Happy Path，没测非法转换（如待支付时不可直接发货）
- 没测临界条件（支付超时边界、库存边界）
- 没测并发（同一订单同时支付和取消）
→ 结果：上线后出现"未支付订单被发货"、并发支付导致重复扣款
检查清单
状态转换测试完成后检查：
- [ ] 所有状态是否识别？
- [ ] 所有合法转换是否测试？
- [ ] 所有非法转换是否验证？
- [ ] 临界条件是否覆盖？
- [ ] 并发场景是否考虑？
- [ ] 数据一致性是否验证？
