本文介绍了场景法与状态迁移图法在软件测试中的应用。场景法适用于安装程序、向导类功能及多界面切换完成的功能测试；状态迁移图法则适用于依赖数据状态的功能测试，如工作流系统。文章通过实例详细阐述了如何运用这两种方法设计有效的测试用例。
昨天我们介绍了正交实验法，那么正交实验法主要适用于一些配置功能的界面和兼容性测试，其他需要组合的界面。正交实验法也是针对有效等价类的。
在实际测试中，经常有这种情况，像安装程序向导，它是由多个界面组成的，并且他们之间彼此有联系，而且他们之间是有流程顺序的，在面对这种测试时，我们就可以使用今天介绍的场景法了。照例还是先看一下基本概念，基本流就是按照正确的事件流来实现的流程。备选流就是出现故障或缺陷的过程。场景就是若干事件流首尾拼接构成一个测试场景。来看一个场景图：
这里共有一个基本流和四个备选流，那么我们来确定一下场景：
场景1：基本流
场景2：基本流 备选流1
场景3：基本流 备选流1 备选流2
场景4：基本流 备选流3
场景5：基本流 备选流3 备选流1
场景6：基本流 备选流3 备选流1 备选流2
场景7：基本流 备选流4
场景8：基本流 备选流3 备选流4
备选流覆盖准则：(1)覆盖每个备选流(2)覆盖一个循环，这两种方法可以看自己的情况选择。到这基本测试用例就出来了，每个场景对应一个测试用例，对每个用例进行评审，删掉重复的就可以了。场景法最主要的就是能够分析出基本流和备选流。场景法主要适用于安装程序、向导类功能和多界面切换完成的功能。
下面来看一下状态迁移图法设计测试用例。在实际测试过程中有这么一种情况，就是被测系统的功能依赖于数据的状态，像常见的工作流系统（OA），对于这类软件状态迁移法就在合适不过了。所谓状态迁移法就是首先要找出所有的状态，然后再分析各个状态之间的转换，条件这些。根据这些来建立测试用例。还是用一个简单的例子来说明一下吧。
|
案例研究1：某航空公司的订票系统 |
|
|
|
|
|
|
|
|
|
| ||
|
客户提供机票信息，订票系统根据这些信息订票，将订单状态标记为Made |
|
|
|
|
|
|
| |||||
|
同时订票系统启动计时器，要求客户在指定时间内必须付费 |
|
|
|
|
|
|
|
|
| |||
|
计时器超时前，客户付费，订单状态标记为Paid |
|
|
|
|
|
|
|
|
|
| ||
|
客户可以打印处于Paid状态的订单机票，订单系统将为用户出票，订单状态标记为Ticketed |
|
|
|
|
|
| ||||||
|
客户使用机票登机后，订单状态标记为Used（结束订单） |
|
|
|
|
|
|
|
|
| |||
|
订票系统计时器超时后客户未付费，订票系统将取消本次机票预订，订单状态为CanceledNonPay |
|
|
|
|
| |||||||
|
若在计时器超时之前，客户要求取消本次订票，订票系统将取消本次机票预订，订单状态为CanceledByCustomer |
|
|
|
| ||||||||
|
若客户在付费后取消订票，订单状态标记为CanceledByCustomer，但需要将相关的机票款项按规定退还给客户 |
|
|
|
| ||||||||
|
若客户在拿到机票后取消订票，订单状态标记为CanceledByCustomer，客户需要将机票退回航空公司，航空公司收到退票后将相关的机票款项按规定退还给客户 | ||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
电子机票的状态 |
|
事件 |
|
|
|
|
|
|
|
|
|
|
|
Made初始创建 |
|
提交订单 |
|
|
|
|
|
|
|
|
|
|
|
Paid已付费 |
|
客户付费 |
|
|
|
|
|
|
|
|
|
|
|
Ticketed已出票 |
|
打印机票 |
|
|
|
|
|
|
|
|
|
|
|
Used已使用 |
|
登机使用 |
|
|
|
|
|
|
|
|
|
|
|
CanceledNonPay超时取消 |
|
计时器超时未付费 |
|
|
|
|
|
|
|
|
| |
|
CanceledByCustomer用户取消 |
客户取消 |
|
|
|
|
|
|
|
|
|
| |
|
|
|
客户已付费取消 |
|
|
|
|
|
|
|
|
| |
|
|
|
拿到机票后取消 |
|
|
|
|
|
|
|
|
| |
将这些状态和事件状态图表示
这样就形成测试用例了，在形成测试用例的时候有几个准则：
(1)至少覆盖所有状态一次啊
(2)至少覆盖所有事件一次
(3)至少覆盖所有转换一次
(4)至少覆盖所有路径一次
扫一扫
2702
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
