世间万物,缘起缘灭,每天都在经历着各种各样的状态转换
  作为一个测试人员,在工作过程中,经常会碰到软件中事物具有多个状态,各个状态在满足某些条件时,实现状态的转换。
  软件中事物状态间的转换一般可分为两类:一类是各个状态之间转换有一定的序列关系,如工作流,必须先发生A状态,才能到B状态,状态A和B之间有先后顺序;一类是各个状态是并列关系,各个状态间可以相互转换,如状态C和D,可以由C转换成D,也可以由D转换成C。这两种类型的状态转换,都需要注意用户角色权限。
  所谓状态转换的测试,是指在测试过程对于软件中事物状态的转换,我们需要模拟使状态发生转换的各种用户操作场景,以及通过一些非正常手段来校验不允许发生的状态流转。基本上对状态转换的测试,我们设计的用例需要涵盖允许的状态转换和不允许的状态转换、以及用户角色权限的校验。
  对于那些只有2个状态转换的情况,往往在基于主流程或备选流程的用例中添加状态校验项来实现;而对于那些有复杂的流转过程或者有多种状态的情况,只是通过用例中添加的状态校验项来,很容易遗漏状态的转换关系,更主要的各个状态的转换被拆分到各个功能模块的用例中,非常的零碎,如果希望针对状态转换的一个回归,筛选用例将会是一件非常麻烦的事情,而不存在的状态转换校验则没有办法体现,由此我们很是需要专门针对状态的流转做一个测试设计。
  无论是序列关系还是并列关系的状态转换,我们都可以从需求说明书(PRD)中获取状态的流转信息,为了更清晰的描述这种状态流转,我们可以通过状态图来表达。有了状态图,我们可以从用户使用的角度、结合用户的实际需求去考虑,这些状态的流转是否符合用户的操作习惯,检查是否有冗余或者缺失的状态;程序的实现是否可以让用户操作尽可能的简单易用;状态流转路径末端节点是否是终结状态,终结状态是否存在逆向的状态流转。
  下面这两种类型的进行实例说明。
  序列关系的状态转换:spu编辑状态的转换。
  Spu编辑状态的转换,是一个有序的过程,在一个生命周期内,某个状态下,满足要求才会流转到下一个状态,大部分状态的流转是单向的,任意一个状态流转分支都是从初始状态出发,到终结状态终止。

  并列关系的状态转换:商品状态的转换。
  商品各个状态间的转换,也有起始状态和终止状态,不同于序列状态,几乎每个状态都和多个状态存在在转换关系,且状态之间的转换是相互的,犹如蜘蛛网一样,面对这种网状的状态图,测试的时候需要特别注意状态之间不允许发生的转换是否存在。

  从两个实例,根据状态图,我们可以看到我们需要关注的内容:
  状态:状态图中的每一个状态,都必须进行测试,校验该状态下,向其他状态的转换是否如状态图中展示的一致。
  状态之间允许的转换:可能是如下情况,相同数据,不同操作引起不同转换;不同数据(前置条件不一样),相同操作引起的不同转换;不同数据,不同操作引起的不同转换。对每一个允许的状态转换进行验证,设置状态转换的前置条件,操作使状态发生转换的功能,验证操作是否正常、状态是否如预期变化。对使用频率特别高、或者特别容易出错的转换、以及不常使用的转换,需要构造更多的测试数据,做尽可能多的覆盖。
  状态之间不允许的转换:状态之间不允许的转换测试,关注系统返回的错误信息和状态值是否变更,不需要对所有的不可能进行验证,应该挑选那些特别容易发生的转换进行测试。
  状态转换的角色权限:状态之间的转换操作,是有用户角色要求的,我们不仅要验证有权限的角色能够正常操作,还需要验证没有权限的角色是否能操作,对于没有权限的角色验证,在不可能全部验证的情况下,也是挑选相对容易出错的操作进行。
  状态的转换,在软件中是非常普遍的,通过状态图梳理各个状态转换的关系,并在状态图的基础上按照状态和状态转换的覆盖原则进行测试设计,可以有效的保证软件状态转换的正确性。测试过程中,还可以进行随机的状态转换测试。