首页/开发/软件测试速查/状态迁移测试(State Transition Testing)
用例设计方法62 条

状态迁移测试(State Transition Testing)

系统行为由当前状态与事件决定时,用状态机描述合法迁移,再设计用例覆盖合法路径与非法迁移;适合订单、支付、工单等有状态流程。

软件测试速查开发更新于 2026-10-13

状态迁移测试是什么

状态迁移测试用于行为由「当前状态 + 收到的事件」共同决定的系统:先用状态机把合法迁移画出来,再设计用例覆盖所有状态、合法迁移与重点非法迁移。订单、支付、工单、账号、设备生命周期这类有状态流程都适用。它补上的正是普通用例容易漏掉的一块:同一操作在不同状态下结果完全不同。

基本信息

四要素状态、事件、迁移(状态转移)、动作与守卫条件
表达形式状态图(直观)与状态表(逐行核对,便于测试设计)
覆盖策略覆盖全部状态、全部合法迁移,并选测高风险的非法迁移
适用对象行为依赖历史状态、同一输入在不同状态下结果不同的系统
配套方法与判定表配合覆盖迁移上的条件组合

示例:订单状态

当前状态事件新状态
待支付支付成功已支付
待支付取消已取消
已支付发货已发货
已发货签收已完成
已取消支付成功非法:应拒绝并保持原状态
已完成取消非法:应拒绝并保持原状态

典型使用场景

  • 订单与支付:支付、取消、退款、关闭全链路迁移。
  • 工单流转:新建、分派、处理中、待确认、关闭与重开。
  • 账号状态:正常、冻结、注销中、已注销的流转约束。
  • 设备与订阅:激活、续费、停机、恢复等生命周期管理。
  • 审批流程:驳回后重提、撤回等回环路径。
  • 缓存一致:状态同时存在于缓存与数据库时的同步迁移。

迁移路径示意

迁移路径示意
# 合法路径:按状态图逐条覆盖
待支付 --支付成功--> 已支付 --发货--> 已发货 --签收--> 已完成
待支付 --取消--> 已取消

# 非法迁移:也要设计用例,断言拒绝且状态不变
已取消 --支付成功--> 应拒绝:返回明确错误提示,状态仍为已取消
非法迁移用例要验证三件事:操作被拒绝、给出明确错误提示、原状态保持不变——只断言报错不核对状态,状态被悄悄改写也发现不了。
状态机先与业务对齐再开始设计用例:把它当作活文档维护,需求变更时先更新状态图,再补用例。
检查状态列完整性:每个状态都应可达、可退出,孤立状态往往意味着需求遗漏或实现缺环。
行为不依赖历史状态的系统不必套用本方法:那属于条件组合问题,用判定表更直接。

易错点

  • 只测合法路径:错误状态下的事件被接受而无人发现,业务流程出现不可能状态。
  • 缓存与实际状态不一致的迁移未覆盖:页面显示与后端判断打架,用户看到的状态错乱。
  • 孤立状态未被发现:某些状态无法到达或进入后无法退出,卡单问题上线后才暴露。
  • 并发事件在同一状态下重复到达未测试:双击提交或重试请求导致重复迁移,产生脏数据。
  • 把状态与角色权限混成一个维度设计:用例数量暴涨且覆盖交叉场景的真实组合被漏掉。

数据来源与参考

  • ISTQB CTFL 4.0 大纲(状态迁移测试)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌