通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果。场景法一般包含基本流和备用流,从一个流程开始,通过描述经过的路径来确定的过程,经过遍历所有的基本流和备用流来完成整个场景。
为什么场景法能如此清晰的描述整个事件?因为,现在的系统基本上都是由事件来触发控制流程的。如:我们申请一个项目,需先提交审批单据,再由部门经理审批,审核通过后由总经理来最终审批,如果部门经理审核不通过,就直接退回。每个事件触发时的情景便形成了场景。而同一事件不同的触发顺序和处理结果形成事件流。这一系列的过程我们利用场景法可以清晰的描述清楚。
下图来展示一下网上最长见的场景法基本情况的一个实例图。
在这个图中,有一个基本流和四个备选流。
每个经过用例的可能路径,可以确定不同的用例场景。从基本流开始,再将基本流和备选流结合起来,可以确定以下用例场景:
场景 1 基本流
场景 2 基本流 备选流 1
场景 3 基本流 备选流 1 备选流 2
场景 4 基本流 备选流 3
场景 5 基本流 备选流 3 备选流 1
场景 6 基本流 备选流 3 备选流 1 备选流 2
场景 7 基本流 备选流 4
场景 8 基本流 备选流 3 备选流 4
从上面的实例我们就可以了解场景是如何利用基本流和备用流来确定的。
基本流:采用直黑线表示,是经过用例的最简单的路径(无任何差错,程序从开始直接执行到结束)
备选流:采用不同颜色表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中,也可以起源于另一个备选流,或终止用例,不在加入到基本流中;(各种错误情况)
下面是场景法的基本设计步骤
- 1. 根据说明,描述出程序的基本流及各项备选流
- 2. 根据基本流和各项备选流生成不同的场景
- 3. 对每一个场景生成相应的测试用例
- 4. 对生成的所有测试用例重新复审,去掉多余的测试用例,测试用例确定后,对每一个测试用例确定测试数据值
好了。说了一些场景法的基本概念和设计方法。想必大家已经有了一些了解了。再举一个简单例子来讲解下。这里,我就不用网上很流行的ATM的例子了。我结合以前项目中遇到的情况。设计一个简单的例子来讲解下。
有一个在线购物的实例,用户进入一个在线购物网站进行购物,选购物品后,进行在线购买,这时需要使用帐号登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。
第一步我们来确定基本流和备选流:
基本流 | 登录在线购物网站,选择物品,登录帐号,付钱交易,生成订购单 |
备选流1 | 帐号不存在 |
备选流2 | 帐号或密码错误 |
备选流3 | 用户帐号余额不足 |
备选流4 | 用户帐号没有钱 |
备选流x | 用户退出系统 |
第二步我们根据基本流和备选流来确定场景:
场景1-成功购物 | 基本流 | |
场景2-帐号不存在 | 基本流 | 备选流1 |
场景3-帐号或密码错误 | 基本流 | 备选流2 |
场景4-用户帐号余额不足 | 基本流 | 备选流3 |
场景5-用户帐号没有钱 | 基本流 | 备选流4 |
第三步我们来设计用例
对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。
下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。
本例中,对于每个测试用例,存在一个测试用例ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。
通过从确定执行用例场景所需的数据元素入手构建矩阵。然后,对于每个场景,至少要确定包含执行场景所需的适当条件的测试用例。例如,在下面的矩阵中,V(有效)用于表明这个条件必须是 VALID(有效的)才可执行基本流,而 I(无效)用于表明这种条件下将激活所需备选流。下表中使用的“n/a”(不适用)表明这个条件不适用于测试用例。
测试用例ID | 场景/条件 | 帐号 | 密码 | 用户帐号余额 | 预期结果 |
1 | 场景1:成功购物 | V | V | V | 成功购物 |
2 | 场景2:帐号不存在 | I | n/a | n/a | 提示帐号不存在 |
3 | 场景3:帐号或密码错误(帐号正确,密码错误) | V | I | n/a | 提示帐号或密码错误,返回基本流步骤3 |
4 | 场景3:帐号或密码错误(帐号错误,密码正确) | V | I | n/a | 提示帐号或密码错误,返回基本流步骤3 |
5 | 场景4:用户帐号余额不足 | V | V | I | 提示帐号余额不足请充值 |
6 | 场景5:用户帐号没有钱 | V | V | I | 提示帐号余额请充值 |
第四步我们来设计数据,把数据填入上面的用例表中。
测试用例ID | 场景/条件 | 帐号 | 密码 | 用户帐号余额 | 预期结果 |
1 | 场景1:成功购物 | Sue | 1s2 | 200 | 成功购物,帐号余额减少200元 |
2 | 场景2:帐号不存在 | Jim | n/a | n/a | 提示帐号不存在 |
3 | 场景3:帐号或密码错误(帐号正确,密码错误) | Sun | 1234zxc | n/a | 提示帐号或密码错误,返回基本流步骤3 |
4 | 场景3:帐号或密码错误(帐号错误,密码正确) | Suns | 123456 | n/a | 提示帐号或密码错误,返回基本流步骤3 |
5 | 场景4:用户帐号余额不足 | Van | 1v2 | 1 | 提示帐号余额不足请充值 |
6 | 场景5:用户帐号没有钱 | Tom | 12zxcdd | 0 | 提示帐号余额请充值 |
以上写到的测试用例只是购物的一部分测试用例。需要的其他测试用例。
我们可以在写完后再进行补充和扩展,达到比较好的覆盖。
场景法就介绍到这里了。估计大家也都了解了。希望这些多大家有所帮助。