软件测试中基于状态转换的测试

软件测试中基于状态转换的测试

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

　　测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

　　不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

　　随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。

　　要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。

　　既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。

　　确定测试用例之所以很重要，原因有以下几方面。

　　测试用例构成了设计和制定测试过程的基础。 测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。 判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成 95 % 的测试”更有意义。 测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。 测试设计和开发的类型以及所需的资源主要都受控于测试用例。 测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例：

　　·一个测试用例用于证明该需求已经满足，通常称作正面测试用例； ·另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。

世间万物，缘起缘灭，每天都在经历着各种各样的状态转换。

作为一个测试人员，在工作过程中，经常会碰到软件中事物具有多个状态，各个状态在满足某些条件时，实现状态的转换。

软件中事物状态间的转换一般可分为两类：一类是各个状态之间转换有一定的序列关系，如工作流，必须先发生A状态，才能到B状态，状态A和B之间有先后顺序；一类是各个状态是并列关系，各个状态间可以相互转换，如状态C和D，可以由C转换成D，也可以由D转换成C。这两种类型的状态转换，都需要注意用户角色权限。

所谓状态转换的测试，是指在测试过程对于软件中事物状态的转换，我们需要模拟使状态发生转换的各种用户操作场景，以及通过一些非正常手段来校验不允许发生的状态流转。基本上对状态转换的测试，我们设计的用例需要涵盖允许的状态转换和不允许的状态转换、以及用户角色权限的校验。

对于那些只有2个状态转换的情况，往往在基于主流程或备选流程的用例中添加状态校验项来实现；而对于那些有复杂的流转过程或者有多种状态的情况，只是通过用例中添加的状态校验项来，很容易遗漏状态的转换关系，更主要的各个状态的转换被拆分到各个功能模块的用例中，非常的零碎，如果希望就针对状态转换的一个回归，筛选用例将会是一件非常麻烦的事情，而不存在的状态转换校验则没有办法体现，由此我们很是需要专门针对状态的流转做一个测试设计。

无论是序列关系还是并列关系的状态转换，我们都可以从需求说明书（PRD）中获取状态的流转信息，为了更清晰的描述这种状态流转，我们可以通过状态图来表达。有了状态图，我们就可以从用户使用的角度、结合用户的实际需求去考虑，这些状态的流转是否符合用户的操作习惯，检查是否有冗余或者缺失的状态；程序的实现是否可以让用户操作尽可能的简单易用；状态流转路径末端节点是否是终结状态，终结状态是否存在逆向的状态流转。

下面就这两种类型的进行实例说明。

序列关系的状态转换：spu编辑状态的转换。

Spu编辑状态的转换，是一个有序的过程，在一个生命周期内，某个状态下，满足要求才会流转到下一个状态，大部分状态的流转是单向的，任意一个状态流转分支都是从初始状态出发，到终结状态终止。

并列关系的状态转换：商品状态的转换。

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

从两个实例，根据状态图，我们可以看到我们需要关注的内容：

状态：状态图中的每一个状态，都必须进行测试，校验该状态下，向其他状态的转换是否如状态图中展示的一致。

状态之间允许的转换：可能是如下情况，相同数据，不同操作引起不同转换；不同数据（前置条件不一样），相同操作引起的不同转换；不同数据，不同操作引起的不同转换。对每一个允许的状态转换进行验证，设置状态转换的前置条件，操作使状态发生转换的功能，验证操作是否正常、状态是否如预期变化。对使用频率特别高、或者特别容易出错的转换、以及最不常使用的转换，需要构造更多的测试数据，做尽可能多的覆盖。

状态之间不允许的转换：状态之间不允许的转换测试，关注系统返回的错误信息和状态值是否变更，不需要对所有的不可能进行验证，应该挑选那些特别容易发生的转换进行测试。

状态转换的角色权限：状态之间的转换操作，是有用户角色要求的，我们不仅要验证有权限的角色能够正常操作，还需要验证没有权限的角色是否能操作，对于没有权限的角色验证，在不可能全部验证的情况下，也是挑选相对容易出错的操作进行。

状态的转换，在软件中是非常普遍的，通过状态图梳理各个状态转换的关系，并在状态图的基础上按照状态和状态转换的覆盖原则进行测试设计，可以有效的保证软件状态转换的正确性。测试过程中，还可以进行随机的状态转换测试。