【测试】通过状态机梳理业务流程的测试点

---

1）什么是状态机？

状态机（State Machine）是有限状态自动机的简称，是现实事物运行规则抽象而成的一个数学模型。

简单来说，状态机其实就是状态转换图，可以很清晰地表达整个状态的流转。

• 如果流程围绕某个事物的状态变化进行，就该用到状态机图。
• 一个状态机图中只描述一个事物，该事物有多个状态，不同的动作作用到状态上导致状态的转换。

从PM的角度：状态机用来表示业务实体的全部状态以及相互间如何转移。

• 其中，业务实体是指客观上可以相互区分的事物，比如订单、优惠券、商品、活动……

1.1 四个要素

• 状态（state）：

  一个状态机至少要包含两个状态。
  • 例如，自动门有 open 和 closed 两个状态。

• 事件（event）：

  事件就是执行某个操作的触发条件或者口令。
  • 例如，对于自动门，“按下开门按钮”就是一个事件。

• 动作（Action）：

  事件发生以后要执行动作。
  • 例如事件是“按开门按钮”，动作是“开门”。
  • 编程的时候，一个 Action 一般就对应一个函数。

• 变换（transaction）：

  从一个状态变化为另一个状态。
  • 例如，“开门过程”就是一个变换。

从PM的角度：状态机可归纳为4个要素，即现态、条件、动作、次态。

• 现态：是指当前所处的状态。
• 条件：又称为“事件”。
  • 当一个条件被满足，将会触发一个动作，或者执行一次状态的迁移。
• 动作：条件满足后执行的动作，动作执行完毕后，可以迁移到新的状态，也可以仍旧保持原状态。
  • 动作不是必需的，当条件满足后，也可以不执行任何动作，直接迁移到新状态。
• 次态：条件满足后要迁往的新状态。
  • “次态”是相对于“现态”而言的，“次态”一旦被激活，就转变成新的“现态”了。
    
    

这样的归纳，主要是出于对状态机的内在因果关系的考虑。

• “现态”和“条件”是因
• “动作”和“次态”是果

*状态机图VS业务流程图

1、概念上的区别

• 流程图：用于表示完成某件事情中的各个活动过程。

  • 其中最重要的部分是处理（process）单元。
    
    

• 状态图：描述一个特定对象的所有可能状态，以及由于各种事件的发生而引起的状态之间的转移。

  • 其最主要的就是程序目前的状态，每一个状态总结记录程序由开始到目前所有接到的输入。

2、节点内容的区别

• 流程图的节点为动作，状态机的节点为状态。

3、关注点的区别

• 流程图更在意动作是如何完成的，状态图更重视动作的完成，相较不在意是哪一个程序完成的。
  • 因此，当状态图中某一个状态下少考虑了哪一个输入事件，我们可以很快地检查出来，但如果在流程图上，我们就无法分辨了。

4、适用场景的区别

• 因此，状态图比较适合对象导向的程序，流程图则比较适合描述程序导向或是数据处理的程序。

1.2 应用

可以应用到各个层面上，例如硬件设计，编译器设计，以及编程实现各种具体业务逻辑的时候。

【举例】自动售货机

做一下简化，假设这是一台只卖2元一瓶的汽水的售货机，只接受五毛和一块的硬币。

• 初始状态是”未付款“，中间状态有”已付款5毛“，”已付款1块“，”已付款1.5块“，”已足额付款“，四个状态。
• 状态切换的触发条件是”投一块硬币“和”投5毛硬币“两种，”到达足额付款“状态。
• 还要进行余额清零和弹出汽水操作。
  
  

所以如果画出一张完整的状态转换图，也会是比较复杂的一张图了。

• 而实际中的售货机对应的状态机就会更加复杂了。

1.3 画图

要素的表示：

• 开始：一般用实心黑圆点表示，代表状态图的起始位置。
• 结尾：一般用实心黑圆点外包一个圆圈表示，是一个状态的终止点。
• 状态：使用圆角矩形表示。
• 条件：使用有向线条上的文字表示，比如系统怎么样，或者用户执行xx动作。
• 状态迁移：用有向线条表示。

要素的命名：

• 状态：建议以”已+动词”的结构来命名，比如已付款、已发货。
• 条件：建议以”动作+结果”的动宾结构或者”表达式”来命名，以明确状态迁移的具体条件。
  • 比如支付失败、下单时间>72小时。
• 注意命名一般站在用户立场，尽量命名标准化。

设计：

• 理解业务实体有多少种状态
  • 不需要的状态尽量去除
  • 注意不要遗漏状态
  • 明确只有一个初始状态，终止状态可能有多个
• 考虑每一个状态因为什么条件而变化
  • 合理实现各个状态之间的切换
• 将状态和状态之间用条件有向连接
• 形成状态机图
  • 方便扩展，状态有可能会增加，有可能会有子状态机

注意：不要搞混动作和状态的区别，命名本身就不一样。而本质上动作是不稳定的，一旦执行完毕就结束了；而状态是稳定的，只要没有外部条件触发。

---

2）实例训练

2.1 外卖订单的简单状态机图

外卖app为例：制作了一个订单的简单的状态机图，以订单的状态变更推动。

1、确定包含哪些状态：

• 待付款
• 订单关闭
• 待接单
• 待配送
• 待评价
• 待退款

2、相关的条件：

• 付款
• 超时
• 取消
• 商家接单与否
• 配送成功与否
• 退款成功与否

2.2 电商订单状态图

1、状态：

• 待付款
• 已付款
• 订单关闭
• 待发货
• 待收货
• 申请退货
• 待退款
• 待评价

2、条件：

• 是否付款
• 是否发货
• 是否退货
• 退款成功与否
• 退货同意与否

测试点梳理：

1、正常场景：

• 选择商品创建订单，订单状态更改为：待付款状态
• 待付款订单进行支付，订单状态更改为：待发货状态
• 后台选择待发货状态的订单填写快递公司、快递单号进行发货，订单状态更改为：待收货状态
• 前台点击确认收货，订单状态更改为：待评价状态
• 前台提交评价，订单状态更改为：已完成状态

2、异常场景：

• 待支付的订单超过三天未支付，订单状态更改为：已取消状态
• 待支付状态的订单后台操作取消订单，订单状态更改为：已取消状态
• 待支付状态的订单前台操作取消订单，订单状态更改为：已取消状态
• 待支付状态的订单前台修改订单信息，修改成功
• 待支付状态的订单后台修改订单信息，修改成功
• 待发货状态的订单后台操作取消订单，订单状态更改为：待退款状态
• 待发货状态的订单前台操作取消订单，订单状态更改为：待退款状态
• 待发货状态的订单前台修改订单信息，修改成功
• 待发货状态的订单后台修改订单信息，修改成功
• 待收货状态的订单超过15天未确认收货，订单状态更改为：待评价状态
• 待评价的订单超过七天未评价，默认好评，订单状态更改为：已完成状态
• 待收货状态的订单操作退还货，生成退还货单
• 待评价状态的订单操作退还货，生成退还货单

3、安全性：订单信息的篡改等

4、兼容性：web、app

5、性能：

• 多用户并发下单
• 提交订单、取消订单、申请退款、申请退货的响应时间

6、可靠性：

• 多用户长时间运行多次提交订单等功能

7、模块关联：

• 优惠券
• 库存
• 物流
• 第三方平台支付

---

【部分内容参考自】

• 什么是状态机？：https://zhuanlan.zhihu.com/p/47434856
• 流程图、顺序图、状态图他们三者分别解决什么样的问题？：https://www.zhihu.com/question/23356888
• 如何绘画状态机来描述业务的变化：http://www.woshipm.com/pd/594751.html?winzoom=1
• 电商项目订单状态变更的测试点：https://blog.csdn.net/qq_33180069/article/details/113338577