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