场景法测试用例设计详解

一、定义:

场景法是通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果的一种方法。

场景法一般包含基本流和备用流,从一个流程开始,通过描述经过的路径来确定的过程,经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型:正常的用例场景,

备选的用例场景,异常的用例场景,假定推测的场景。

二、基本流备用流:

<ignore_js_op>

上图为,用例基本流和备选流(注意:备选流的起止点)

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

备选流:采用不同颜色表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如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.对每一个场景生成相应的[url=]测试用例[/url]

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

对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。

下面范例中显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。

本例中,对于每个测试用例,存在一个测试用例ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于[url=]数据库[/url]中)以及预期结果。

通过从确定执行用例场景所需的数据元素入手构建矩阵。然后,对于每个场景,至少要确定包含执行场景所需的适当条件的测试用例。例如,在下面的矩阵中,V(有效)用于表明这个条件必须是 VALID(有效的)才可执行基本流,

而 I(无效)用于表明这种条件下将激活所需备选流。下表中使用的“n/a”(不适用)表明这个条件不适用于测试用例。

四、场景法设计实例:

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

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

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

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

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

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

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

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

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

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

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

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

测试用例ID

场景/条件

账号

密码

余额

预期结果

1

场景1:无账号

I

n/a

n/a

提示无账号

2

场景2:账号或密码错误(账号错误,密码正确)

I

V

n/a

提示账号或密码错误重新输入

3

场景2:账号或密码错误(账号正确,密码错误)

V

I

n/a

提示账号或密码错误重新输入

4

场景3:账号余额不足

V

V

I

提示账号余额不足

5

场景4:账号没有钱

V

V

提示账号余额不足

场景5:购物成功

V

V

V

生成订单

场景6:操作中退出系统

V

V

  
  

用户退出系统

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

测试用例ID

场景/条件

账号

密码

余额

预期结果

1

场景1:无账号

n/a

n/a

提示无账号

2

场景2:账号或密码错误(账号错误,密码正确)

n/a

提示账号或密码错误重新输入

3

场景2:账号或密码错误(账号正确,密码错误)

ff

I

n/a

提示账号或密码错误重新输入

4

场景3:账号余额不足

ff

10

提示账号余额不足

5

场景4:账号没有钱

ff

提示账号余额不足

场景5:购物成功

ff

500

生成订单,余额减少

场景6:操作中退出系统

ff

  
  

用户退出系统

http://www.bcbxhome.com/bcbx/forum.php?mod=viewthread&tid=24&fromuid=27
(出处: 编测编学软件测试)

原文地址:https://www.cnblogs.com/zihkj/p/12432065.html

时间: 2024-10-05 14:10:27

场景法测试用例设计详解的相关文章

Java开源生鲜电商平台-Java后端生成Token架构与设计详解(源码可下载)

Java开源生鲜电商平台-Java后端生成Token架构与设计详解(源码可下载) 目的:Java开源生鲜电商平台-Java后端生成Token目的是为了用于校验客户端,防止重复提交. 技术选型:用开源的JWT架构. 1.概述:在web项目中,服务端和前端经常需要交互数据,有的时候由于网络相应慢,客户端在提交某些敏感数据(比如按照正常的业务逻辑,此份数据只能保存一份)时,如果前端多次点击提交按钮会导致提交多份数据,这种情况我们是要防止发生的. 2.解决方法: ①前端处理:在提交之后通过js立即将按钮

Dubbo架构设计详解【转】

Dubbo是Alibaba开源的分布式服务框架,它最大的特点是按照分层的方式来架构,使用这种方式可以使各个层之间解耦合(或者最大限度地松耦合).从服务模型的角度来看,Dubbo采用的是一种非常简单的模型,要么是提供方提供服务,要么是消费方消费服务,所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色.关于注册中心.协议支持.服务监控等内容,详见后面描述. 总体架构 Dubbo的总体架构,如图所示:Dubbo框架设计一共划分了10个层,而最上面的Servi

Dubbo架构设计详解

Dubbo是Alibaba开源的分布式服务框架,它最大的特点是按照分层的方式来架构,使用这种方式可以使各个层之间解耦合(或者最大限度地松耦合).从服务模型的角度来看,Dubbo采用的是一种非常简单的模型,要么是提供方提供服务,要么是消费方消费服务,所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色.关于注册中心.协议支持.服务监控等内容,详见后面描述. 总体架构 Dubbo的总体架构,如图所示:Dubbo框架设计一共划分了10个层,而最上面的Servi

Dubbo架构设计详解(转收藏)

转自:http://shiyanjun.cn/archives/325.html Dubbo是Alibaba开源的分布式服务框架,它最大的特点是按照分层的方式来架构,使用这种方式可以使各个层之间解耦合(或者最大限度地 松耦合).从服务模型的角度来看,Dubbo采用的是一种非常简单的模型,要么是提供方提供服务,要么是消费方消费服务,所以基于这一点可以抽象出服务提 供方(Provider)和服务消费方(Consumer)两个角色.关于注册中心.协议支持.服务监控等内容,详见后面描述. 总体架构 Du

dubbo初识(一)Dubbo架构设计详解

参见http://shiyanjun.cn/archives/325.html Dubbo是Alibaba开源的分布式服务框架,它最大的特点是按照分层的方式来架构,使用这种方式可以使各个层之间解耦合(或者最大限度地松耦合).从服务模型的角度来看,Dubbo采用的是一种非常简单的模型,要么是提供方提供服务,要么是消费方消费服务,所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色.关于注册中心.协议支持.服务监控等内容,详见后面描述. 总体架构 Dubbo

备份校验两不误,MySQL自动备份还原校验设计详解

作者介绍庞阔,优朋普乐传媒运维基础部经理.负责数据库运营管理及平台设计开发,监控设计改进,问题跟踪处理,机房网络维护管理,目前四个专利已在专利局申请中.擅长数据库运维管理及Shell.Perl.PHP编写. 最近关于数据库故障出现的问题较多,不论大小公司对数据的备份要求都很高,但对校验数据备份的有效性要求更为迫切,很多公司对于自动备份和还原都已经形成体系,但对于还原后的备份有效性校验可能都不太完善,而且目前网上也没有较为完善的检验机制(可能我没找到). 对数据库备份的有效性校验的方法或样例选择,

Java之用继承进行设计详解(附源码)

前言 学习了多态之后,看起来似乎所有东西都可以被继承,因为多态是一种如此巧妙的工具.事实上,当我们用现成的类来建立新类时,如果首先考虑使用继承技术,反倒会加重我们的设计负担,使事情变得不必要地复杂起来. 更好的方法是首先选择"组合",尤其是不能十分确定应该使用哪一种方式时.组合不会强制我们的程序设计进入继承的层次结构中.而且,组合更加灵活,因为它可以动态选择类型(因此也就选择了行为):相反,继承在编译时就需要知道确切类型.下面举例说明这一点: 示例源码 package com.mufe

BI项目中的ETL设计详解(数据抽取、清洗与转换 )

ETL是BI项目最重要的一个环节,通常情况下ETL会花掉整个项目的1/3的时间,ETL设计的好坏直接关接到BI项目的成败.ETL也是一个长期的过程,只有不断的发现问题并解决问题,才能使ETL运行效率更高,为项目后期开发提供准确的数据. ETL的设计分三部分:数据抽取.数据的清洗转换.数据的加载.在设计ETL的时候也是从这三部分出发.数据的抽取是从各个不同的数据源抽取到ODS中(这个过程也可以做一些数据的清洗和转换),在抽取的过程中需要挑选不同的抽取方法,尽可能的提高ETL的运行效率.ETL三个部

MVP框架设计详解

MVP MVP简介 Model View Presenter ActivityView MVP各层关系梳理 ?? Model与Presenter ?? View与Presenter ?? Presenter完成的交互 ?? Model与View之间的交互 MVP适用环境 MVPRetrofitRxJava 加入Retrofit 创建interface 修改Model层内容 修改Presenter层内容 加入RxJava 修改Interface 修改Model层 修改Presenter层 总结 M