测试用例设计方法之场景设计法

 

基本流:采用直黑线表示,是经过用例的最简单的路径(无任何差错,程序从开始直接执行到结束)

备选流:采用不同颜色表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如1和3),也可以起源于另一个备选流(如2),或终止用例,不在加入到基本流中(如4);(各种错误情况)

生成的场景如下:

场景1:基本流

场景2:基本流 备选流1

场景3:基本流 备选流1 备选流2

场景4:基本流 备选流3

场景5:基本流 备选流3 备选流2

场景6:基本流 备选流3 备选流2 备选流1

场景7:基本流 备选流4

场景8:基本流 备选流3 备选流4

为什么场景法能如此清晰的描述整个事件?

因为,现在的系统基本上都是由事件来触发控制流程的.

如:我们申请一个项目,需先提交审批单据,再由部门经理审批,审核通过后由总经理来最终审批,如果部门经理审核不通过,

就直接退回。每个事件触发时的情景便形成了场景。而同一事件不同的触发顺序和处理结果形成事件流。这一系列的过程我们利用场景法可以清晰的描述清楚。

概念:

现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,是测试用例更容易理解和执行。
典型的应用是是用业务流把各个孤立的功能点串起来,为测试人员建立整体业务感觉,从而避免陷入功能细节忽视业务流程要点的错误倾向
 

优点:

涉及到业务场景,使用场景法有利于测试设计者设计测试用例,使测试用例更容易理解和执行。

缺点:

只验证业务流程,不验证单点功能。

使用场景:

一般先采用等价类划分、边界值分析、错误推断法、判定表法等对单点功能进行验证,验证通过后再采用场景法进行业务流程的验证。

主要用来测试软件的业务逻辑和业务流程。

使用场景法要注意什么?

基本上每个软件都会用到场景法,因为每个软件背后都有业务的支撑。
使用场景法,目的是用业务流把各个孤立的功能点串起来,为测试人员建立整体业务感觉,从而避免陷入功能细节忽视业务流程要点的错误倾向。
业务流程测试没有问题并不代表系统的功能都正确,还必须对单个功能进行详细的测试,这样才能保证测试的充分性。
场景法的核心就是“场景”二字,你所需要的就是要找出场景,场景找出来了,测试用例也就水到渠成。在很多流程图中,有不少备选流其实是隐藏的,大家一定要注意将他们都准确筛选出来。

场景法使用步骤:

1.根据说明,描述出程序的基本流及各项备选流

2.根据基本流和各项备选流生成不同的场景

3.对每一个场景生成相应的测试用例

4.对生成的所有测试用例重新复审,去掉多余的测试用例,测试用例确定后,为每一个测试用例添加测试数据值

案例:

用户进入一个在线购物网站进行购物,选购物品后,进行在线购买,这时需要使用帐号登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。

1. 根据说明,描述出程序的基本流及各项备选流

基本流:登录网站,选购物品,账号登录,付钱交易,生成订单

备选流:无账号,账号或密码错误,账号没有钱,账号余额不足 用户退出系统

2. 根据基本流和各项备选流生成不同的场景

场景1:登录网站,选购物品,账号登录,无账号

场景2:登录网站,选购物品,账号登录,账号或密码错误

场景3:登录网站,选购物品,账号登录,付钱交易,账号没有钱

场景4:登录网站,选购物品,账号登录,付钱交易,账号余额不足

场景5:登录网站,选购物品,账号登录,付钱交易,生成订单

场景6:登录网站,选购物品,账号登录,用户退出系统

3. 根据场景生成相应的测试用例

 

4. 根据上表,设计数据,填入数据

 

 

  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

阿瞒有我良计15

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值