一、方法简介
现在的软件几乎都是用事件触发来控制流程的，时间触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就是形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。
可确定以下用例场景：
场景1：基本流
场景2：基本流 备选流1
场景3：基本流 备选流1 备选流2
场景4：基本流 备选流3
场景5：基本流 备选流3 备选流1
场景6：基本流 备选流3 备选流1 备选流2
场景7：基本流 备选流4
场景8：基本流 备选流3 备选流4
二、实战演习
ATM取款
1.例子描述
下图所示是ATM例子的流程示意图
2.场景设计：下表所示是生成的场景
|
场景1---成功提款 |
基本流 |
|
|
场景2---ATM内没有现金 |
基本流 |
备选流2 |
|
场景3---ATM内现金不足 |
基本流 |
备选流3 |
|
场景4---PIN有误（还有输入机会） |
基本流 |
备选流4 |
|
场景5---PIN有误（不再有输入机会） |
基本流 |
备选流4 |
|
场景6---账户不存在/账户类型有误 |
基本流 |
备选流5 |
|
场景7---账户余额不足 |
基本流 |
备选流6 |
注：为方便起见，备选流3和6（场景3和7）内的循环
3.用例设计
对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（说明）、测试用例中设计的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。
测试用例表
|
TC（测试用例号）ID |
场景/条件 |
PIN |
帐号 |
输入（或选择）的金额 |
账面金额 |
ATM内的金额 |
预期结果 |
|
CW1 |
场景1：成功提款 |
V |
V |
V |
V |
V |
成功提款 |
|
CW2 |
场景2：ATM内没有现金 |
V |
V |
V |
V |
I |
提款项不可用，用例结束，警告信息 |
|
CW3 |
场景3：ATM内现金不足 |
V |
V |
V |
V |
I |
返回基本流步骤6，输入金额 |
|
CW4 |
场景4：PIN有误（还有不止一次输入机会） |
I |
V |
n/a |
V |
V |
警告消息，返回基本流步骤4，输入PIN |
|
CW5 |
场景4：PIN有误（还有一次输入机会） |
I |
V |
n/a |
V |
V |
警告消息，返回基本流步骤4，输入PIN |
|
CW6 |
PIN有误（不再有输入机会） |
I |
V |
n/a |
V |
V |
警告消息，卡保留，用例结束 |
4.数据设计
一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。
测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中），并且设定测试数据
|
TC（测试用例号）ID |
场景/条件 |
PIN |
帐号 |
输入（或选择）的金额 |
账面金额 |
ATM内的金额 |
预期结果 |
|
CW1 |
场景1：成功提款 |
|
|
|
|
|
成功提款 4987 809-498 50 500.00 2000 |
|
CW2 |
场景2：ATM内没有现金 |
|
|
|
|
|
4987 809-498 100 500.00 0.00 |
|
CW3 |
场景3：ATM内现金不足 |
|
|
|
|
|
4987 809-498 100 500.00 70 |
|
CW4 |
场景4：PIN有误（还有不止一次输入机会） |
|
|
|
|
|
警告消息，返回基本流步骤4，输入PIN |
|
CW5 |
场景4：PIN有误（还有一次输入机会） |
|
|
|
|
|
警告消息，返回基本流步骤4，输入PIN |
|
CW6 |
PIN有误（不再有输入机会） |
|
|
|
|
|
警告消息，卡被保留，用例结束 |