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

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

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

本文选自：http://www.spasvo.com/news/html/20141216133723.html

基于状态转换的测试