场景法测试用例ATM机

场景法测试用例ATM机
场景法测试用例ATM机

测试用例设计--场景法

1.定义

现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设用例场景用来描述流经用例的路径,从用例开始到结束遍历这条路径上所有基本流和备选流。

右图中经过用例的每条路径都用基本流和备选流来表示:

基本流用黑色表示,是经过用例的最简单的路径。

备选流用不同的彩色表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1 和3);也可能起源于另一个备选流(如备选流2),或者终止用例而不再重新加入到某个流(如备选流2 和4)。

1.应用的范围

1) 基本上每个软件都会用到这种方法,因为每个软件后面都有业务的支撑

2) 比较常见的有: 网上购物流程, ATM机取款流程等

1.步骤

1) 画出需要测试路径的流程图(一般选择工具Office Visio)

2) 分析基本流和备选流

3) 根据基本流和备选流设计测试用例

1.案例

基本事件流:

1、用户向ATM提款机中插入银行卡,如果银行卡是合法的,ATM提款机界面提示用户输入提款密码;

用户输入该银行卡的密码,ATM提款机与MainFrame传递密码,检验密码的正确性。如果输入密码正确,提示用户输入取钱金额,提示信息为,“请输入您的提款额度”;

用户输入取钱金额,系统校验金额正确,提示用户确认,提示信息为“您输入的金额是xxx,请确认,谢谢!”,用户按下确认键,确认需要提取的金额;

系统同步银行主机,点钞票,输出给用户,并且减掉数据库中该用户帐户中的存款金额。

用户提款,银行卡自动退出,用户取走现金,拔出银行卡,ATM提款机界面恢复到初始状态;

备选事件流(考虑可能失败的地方):

1.在基本事件流1中:

a) 如果插入无效的银行卡,那么,在ATM提款机界面上提示用户“您使用的银行卡无效!”,3秒钟后,自动退出该银行卡。

1.在基本事件流2中:

a) 如果用户输入的密码错误,则提示用户“您输入的密码无效,请重新输入”;

b) 如果用户连续3次输入错误密码,ATM提款机吞卡,并且ATM提款机的界面恢复到初始状态。此时,其他提款人可以继续使用其他的合法的银行卡在ATM提款机上提取现金。

c) 用户输入错误的密码后,也可以按“退出”键,则银行卡自动退出。

1.在基本事件流3中:

a) 如果用户输入的单笔提款金额超过单笔提款上限,ATM提款机界面提示“您输入的金额错误,单笔提款上限金额是1500RMB,请重新输入”;

b) 如果用户输入的单笔金额,不是以50RMB为单位的,那么提示用户“您输入的提款金额错误,请输入以50为单位的金额”;

c) 如果用户在24小时内提取的金额大于4500RMB,则ATM提款机提示用户,“24小时内只能提取4500RMB,请重新输入提款金额”输入提取的金额超过了系统的设定的限制;

d) 如果用户输入正确的提款金额,ATM提款机提示用户确认后,用户取消提款,则ATM提款机自动退出该银行卡;

e) 如果ATM提款机中余额不足,则提示用户,“抱歉,ATM提款机中余额不足”,3秒钟后,自动退出银行卡。

1.在基本事件流4中:

a) 如果用户银行户头中的存款小于提款金额,则提示用户“抱歉,您的存款余额不足!”,3秒钟后,自动退出银行卡;

1.在基本事件流5中:

a) 如果用户没有取走现金,或者没有拔出银行卡,ATM提款机不做任何提示,直接恢复到界面的初始状态;

场景法--分析过程

1.总结

1) 流程图可以参考需求规格说明书中的相关流程图

2) 如果没有需求文档,和需求和开发沟通,确保了解被测试软件的流程

3) 流程有大流程和小流程,大流程是指大功能的跳转,小流程是指功能内的调整,大小流程需要都被覆盖到.

功能测试用例的设计

功能测试用例的设计 LG GROUP system office room 【LGA16H-LGYY-LGUA8Q8-LGA162】

一、实验目的 1.用因果图法分析原因结果,并决策表设计测试用例。 2.使用场景法设计测试用例。 二、实验内容 1. 将三角形问题的可能结果扩展为:一般三角形、等腰三角形、等边三角形、直角三角形、等腰直角三角形和非三角形,考虑用因果图法设计测试用例,给出完整步骤。 2. 有一个在线购物的实例,用户进入一个在线购物网站进行购物,选购物品后,进行在线购买,这时需要使用帐号密码登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。使用场景法设计上述问题的测试用例。 三、实验环境 Windows XP系统 四、实验步骤和结果 1. 将三角形问题的可能结果扩展为:一般三角形、等腰三角形、等边三角形、直角三角形、等腰直角三角形和非三角形,用因果图法设计测试用例,给出完整步骤。具体如下: 1)输入的三边分别为a,b,c(斜边) 且a

2. 行在线购买,这时需要使用帐号密码登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。使用场景法设计上述问题的测试用例。

(注:在下面的矩阵中,V(有效)用于表明这个条件必须是 VALID(有效的)才可执行基本流,而 I(无效)用于表明这种条件下将激活所需备选流,“n/a”(不适用)表 对生成的所有测试用例重新复审,去掉多余的测试用例,测试用例确定后,对每一个测

五、实验结果和讨论 成功使用因果图法、场景法设计了测试用例。 六、总结 1.因果图法的定义是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。 2.在事件触发机制中场景法用得最多。在测试一个软件的时候,先确定基本流也就是测试流程中软件功能按照正确的事件流实现的一条正确流程,接着去确定备选流也就是那些出现故障或缺陷的过程,用备选流加以标注。然后可以采用矩阵或决策表来确定和管理测试用例。

实验七-黑盒测试之场景法测试实验(参考答案)

实验七黑盒测试之场景法测试实验 1.1 实验目的 1、通过对简单程序进行黑盒测试,熟悉测试过程,对软件测试形成初步了解,并养成良好的测试习惯。 2、掌握黑盒测试的基础知识,能熟练应用场景法进行测试用例的设计。1.2 实验平台 操作系统:Windows 7或Windows XP 1.3 实验内容及要求 1、练习1 软件系统几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。场景法就是通过用例场景描述业务操作流程,从用例开始到结束遍历应用流程上所有基本流(基本事件)和备选流(分支事件)。下面是对某IC卡加油机应用系统的基本流和备选流的描述。 基本流A;

备选流: (1)使用场景法设计测试案例,指出场景涉及到的基本流和备选流,基本流用字母A表示,备选流用题干中描述的相应字母表示。 场景1:A 场景2:A、B 场景3:A、C 场景4:A、D 场景5:A、E (2)场景中的每一个场景都需要确定测试用例,一般采用矩阵来确定和管理测试用例。如下表所示是一种通用格式,其中行代表各个测试用例,列代表测试用例的信息。本例中的测试用例包含测试用例、ID、场景涤件、测试用例中涉及的所有数据元素和预期结果等项目。首先确定执行用例场景所需的数据元素(本例中包括账号、是否黑名单卡、输入油量、账面金额、加油机油量),然后构建矩阵,最后要确定包含执行场景所需的适当条件的测试用例。在下面的矩阵中,V 表示有效数据元素,I表示无效数据元素,n/a表示不适用,例如C01表示“成功加油”基本流。请按上述规定为其它应用场景设计用例矩阵。 测试用例表

实验七-黑盒测试之场景法测试实验(参考答案)

实验七-黑盒测试之场景法测试实验(参考答案)

实验七黑盒测试之场景法测试实验 1.1 实验目的 1、通过对简单程序进行黑盒测试,熟悉测试过程,对软件测试形成初步了解,并养成良好的测试习惯。 2、掌握黑盒测试的基础知识,能熟练应用场景法进行测试用例的设计。 1.2 实验平台 操作系统:Windows 7或Windows XP 1.3 实验内容及要求 1、练习1 软件系统几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。场景法就是通过用例场景描述业务操作流程,从用例开始到结束遍历应用流程上所有基本流(基本事件)和备选流(分支事件)。下面是对某IC卡加油机应用系统的基本流和备选流的描述。 基本流A; 序号用例 名称 用例描述 1 准备 加油 客户将IC加油卡插入加油机 2 验证 加油 加油机从加油卡的磁条中读取账户代码,并检查它是否属于

卡可以接收的加油卡 3 验证 黑名 单 加油机验证卡账户是否存在于黑名单中,如果属于黑名单, 加油机吞卡 4 输入 购油 量 客户输入需要购买的汽油数 量 5 加油加油机完成加油操作,从加油卡中扣除相应金额 6 返回 加油 卡 退还加油卡 备选流: 序号用例名 称 用例描述 B 加油卡 无效 在基本流A2过程中,该卡不能够识别 或是非本机可以使用的IC 卡,加油 机退卡,并退出基本流 C 卡账户 属于黑 在基本流A3过程中,判断该卡账产属 于黑名单,例如:已经挂失,加油机

名单吞卡退出基本流 D 加油卡 账面现 金不足 系统判断加油卡内现金不足,重新加 入基本流A4,或选择退卡 E 加油机 油量不 足 系统判断加油机内油量不足,重新加 入基本流A4,或选择退卡 (1)使用场景法设计测试案例,指出场景涉及到的基本流和备选流,基本流用字母A表示,备选流用题干中描述的相应字母表示。 场景1:A 场景2:A、B 场景3:A、C 场景4:A、D 场景5:A、E (2)场景中的每一个场景都需要确定测试用例,一般采用矩阵来确定和管理测试用例。如下表所示是一种通用格式,其中行代表各个测试用例,列代表测试用例的信息。本例中的测试用例包含测试用例、ID、场景涤件、测试用例中涉及的所有数据元素和预期结果等项目。首先确定执行用例场景所需的数据元素(本例中包括账号、是否黑名单卡、输入油量、账面金额、加油机油量),然后构建矩阵,最后要确定包含执行场景所需的适当条件的测试用例。在下面的矩阵中,V表示有效数据元素,I表示无效数据元素,n/a表示不适用,例如C01表示“成功加油”基本流。请按上述规定为其它应用场景设计用例矩阵。 测试用例表 测试用例场景 账 号 是否黑 名单卡 输 入 账 面 加油 机 预期 结果

[生活]场景法测试用例ATM机

[生活]场景法测试用例ATM机 测试用例设计--场景法 1. 定义 现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设用例场景用来描述流经用例的路径,从用例开始到结束遍历这条路径上所有基本流和备选流。 右图中经过用例的每条路径都用基本流和备选流来表示: 基本流用黑色表示,是经过用例的最简单的路径。 备选流用不同的彩色表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流 1 和 3);也可能起源于另一个备选流(如备选流 2),或者终止用例而不再重新加入到某个流(如备选流 2 和 4)。 1. 应用的范围

1) 基本上每个软件都会用到这种方法,因为每个软件后面都有业务的支撑 2) 比较常见的有: 网上购物流程, ATM机取款流程等 1. 步骤 1) 画出需要测试路径的流程图(一般选择工具Office Visio) 2) 分析基本流和备选流 3) 根据基本流和备选流设计测试用例 1. 案例 基本事件流: 1、用户向ATM提款机中插入银行卡,如果银行卡是合法的,ATM提款机界面提示用户输入提款密码; 参数1 银行密码 参数类型字符串 参数范围字符串为0,9之间的阿拉伯数字组合,密码长度为6位 备注 用户输入该银行卡的密码,ATM提款机与MainFrame传递密码,检验密码的正确性。如果输入密码正确,提示用户输入取钱金额,提示信息为,“请输入您的提款额度”; 用户输入取钱金额,系统校验金额正确,提示用户确认,提示信息为“您输入的金额是xxx,请确认,谢谢~”,用户按下确认键,确认需要提取的金额; 参数1 取款金额 参数类型整数 参数范围 50~1500 RMB,单笔取款额最高为1500RMB;每24小时之内,取款的最 高限额是4500RMB

李龙: 测试用例:场景法设计测试用例

场景法设计测试用例 在面向对象的软件开发中,事件触发机制是编程中经常遇到的。 (一)场景法原理 现在的软件几乎都是用事件触发来控制流程的。像GUI软件、游戏等。事件触发时的情景形成了场景,而同一事件不同的触发顺序和处理结果就形成了事件流。这种在软件设计方面的思想可以引入到软件测试中,可以生动地描绘出事件触发时的情景,有利于设计测试用例,同时使测试用例更容易理解和执行。 在测试一个软件的时候,在场景法中,测试流程是软件功能按照正确的事件流实现的一条正确流程,那么我们把这个称为该软件的基本流;而凡是出现故障或缺陷的过程,就用备选流加以标注,这样的话,备选流就可以是从基本流来的,或是由备选流中引出的。所以在进行图示的时候,就会发现每个事件流的颜色是不同的。 基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流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 下面是场景法的基本设计步骤: 根据说明,描述出程序的基本流及各项备选流

使用用例场景设计测试用例

使用用例场景 设计测试用例 作者:周毅 EMAIL:foralanzhou@https://www.360docs.net/doc/948944069.html,

概念和定义 不完全、不彻底是软件测试的致命缺陷,任何程序只能进行少量而有限的测试。测试用例在此情况下产生,同时它也是软件测试系统化、工程化的产物。而测试用例的设计一直是软件测试工作的重点和难点,那么 什么是测试用例? 为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据,称之为测试用例。 我们不可能进行穷举测试,为了节省时间和资源、提高测试效率,必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。 怎样的用例算是好用例? 一个好的测试用例是在于它能发现至今未发现的错误。 使用测试用例的好处 在开始实施测试之前设计好测试用例,可以避免盲目测试并提高测试效率。 测试用例的使用令软件测试的实施重点突出、目的明确。 在软件版本更新后只需修正少部分的测试用例便可展开测试工作,降低工作强度、缩短项目周期。 功能模块的通用化和复用化使软件易于开发,而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展,并随着测试用例的不断精化其效率也不断攀升。 设计测试用例的方法 黑盒测试: 等价类划分法 边界值分析法 错误推测法 因果图法 白盒测试: 逻辑覆盖法 基本路径测试法 测试用例的设计过程 测试设计员(分析设计员)依据不同阶段的测试计划、设计模型和实施模型来设计该阶段测试用例。 测试设计员是具有丰富测试经验或具有软件分析设计能力的高级测试工程师。如果没有测试设计员,则可用分析设计员代替。 针对白盒,还应有驱动程序和桩模块。 测试点的确定 ISO质量体系: 在概要设计或详细设计中应明确指出每个单元模块的测试要点、指标和方法。 CMM质量体系: 在系统的用例模型描述中应明确指出每个用例模型的优先级及用例工作流程,每一个用例模型为 一个测试点,用例模型中每一个测试需求至少应有两个测试用例。 理解上的误区 测试用例应由测试设计员或分析设计员来制定,而不是普通的测试员。 测试点应由分析设计员确立,与测试人员无关。 测试工作展开于项目立项后,而不是代码开发完成之后。 测试对象不仅仅是源代码,还包括需求分析、需求规格说明书、概要设计、概要设计说明书、详细设计、详细设计说明书、使用手册等各阶段的文档。

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

设计测试用例方法--场景设计方法 1方法简介 1.1 定义 通过运用场景来对系统得功能点或业务流程得描述,从而提高测试效果。场景法一般包含基本流与备用流,从一个流程开始,通过描述经过得路径来确定得过程,经过遍历所有得基本流与备用流来完成整个场景。 1.2 产生背景 为什么场景法能如此清晰得描述整个事件?因为,现在得系统基本上都就是由事件来触发控制流程得。如:我们申请一个项目,需先提交审批单据,再由部门经理审批,审核通过后由总经理来最终审批,如果部门经理审核不通过,就直接退回。每个事件触发时得情景便形成了场景。而同一事件不同得触发顺序与处理结果形成事件流。这一系列得过程我们利用场景法可以清晰得描述清楚。

1.3 实例图 在这个图中,有一个基本流与四个备选流。 每个经过用例得可能路径,可以确定不同得用例场景。从基本流开始,再将基本流与备选流结合起来,可以确定以下用例场景: 场景 1 基本流 场景 2 基本流备选流 1 场景 3 基本流备选流 1 备选流 2 场景 4 基本流备选流 3 场景 5 基本流备选流 3 备选流 1

场景 6 基本流备选流 3 备选流 1 备选流 2 场景 7 基本流备选流 4 场景 8 基本流备选流 3 备选流 4 从上面得实例我们就可以了解场景就是如何利用基本流与备用流来确定得。 基本流:采用直黑线表示,就是经过用例得最简单得路径(无任何差错,程序从开始直接执行到结束) 备选流:采用不同颜色表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中,也可以起源于另一个备选流,或终止用例,不在加入到基本流中;(各种错误情况) 1.4 基本设计步骤 1. 根据说明,描述出程序得基本流及各项备选流 2. 根据基本流与各项备选流生成不同得场景 3. 对每一个场景生成相应得测试用例 4. 对生成得所有测试用例重新复审,去掉多余得测试用例,测试用例确定后,对每一 个测试用例确定测试数据值 2实战演习 2.1 ATM机问题 下图所示就是ATM例子得流程示意图。

场景法测试用例ATM机(1)

一.方法简介 现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。 基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1和3);也可能起源于另一个备选流(如备选流2),或者终止用例而不再重新加入到某个流(如备选流2和4)。

二.实战演习 1. 例子描述 下图所示是ATM例子的流程示意图。

2.场景设计:下表所示是生成的场景。 表3-8 场景设计 注:为方便起见,备选流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 警告消息,卡予保 留,用例结束

软件测试-场景法介绍

通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果。场景法一般包含基本流和备用流,从一个流程开始,通过描述经过的路径来确定的过程,经过遍历所有的基本流和备用流来完成整个场景。 为什么场景法能如此清晰的描述整个事件?因为,现在的系统基本上都是由事件来触发控制流程的。如:我们申请一个项目,需先提交审批单据,再由部门经理审批,审核通过后由总经理来最终审批,如果部门经理审核不通过,就直接退回。每个事件触发时的情景便形成了场景。而同一事件不同的触发顺序和处理结果形成事件流。这一系列的过程我们利用场景法可以清晰的描述清楚。 下图来展示一下网上最长见的场景法基本情况的一个实例图。 在这个图中,有一个基本流和四个备选流。 每个经过用例的可能路径,可以确定不同的用例场景。从基本流开始,再将基本流和备选流结合起来,可以确定以下用例场景: 场景 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)设计测试用例值。 1)录系统用例的事件流 基本流: 1.进入登录界面 2.输入有效的登录名 3.输入密码正确 4.输入验证码正确 5.点击登录按钮,成功登入 备选流1:上次选择自动登录,通过验证,成功登录; 备选流2:上次未选择自动登录,登陆名未通过验证; 备选流3:上次未选择自动登录,密码不正确,还有输入机会; 备选流4:上次未选择自动登录,密码不正确,没有输入机会; 备选流5:上次未选择自动登录,验证码不正确; 备选流6:上次未选择自动登录,忘记密码; 2)登录系统的场景列表 场景描述基本流备选流场景1:成功登录基本流 场景2:自动登录成功基本流备选流1 场景3:登录名未通过验证基本流备选流2 场景4:密码不正确,有输入机会基本流备选流3 场景5:密码不正确,没有输入机会基本流备选流4 场景6:验证码不正确基本流备选流5 场景7:忘记密码基本流备选流6 3)登录系统的用例矩阵 V表示这个条件必须是有效的才可执行基本流,I表示条件无效,N/A 表示这个条件不适用于测试用例

标识场景自动 登录 登录名登录 密码 验证 码 忘记 密码 预期结果账号邮箱 R1 1账号登陆I V I V V I 成功登入 R2 1邮箱登陆I I V V V I 成功登入 R3 2自动登录V N/A N/A V I 成功登入 R4 3登录名有误I I N/A N/A I 提示登录名有误 R5 4没机会输入 密码I V I N/A I 提示密码与登录名不 匹配且账号已锁定 R6 5有机会输入 密码I V I N/A I 提示密码与登录名不 匹配可再次登录 R7 6自动登录验 证码有误 V N/A N/A I I 提示输入验证码有误R8 6非自动登录 验证码有误 I N/A N/A I I 提示输入验证码有误R9 7忘记密码N/A V I N/A V 出现忘记密码界面4)登录系统的测试用例: 标识场景自动 登录 登录名登录 密码 验证 码 忘记 密码 预期结果账号邮箱 R1 1账号登陆未选 择输入 账号 不输 入 正确 密码 输入 正确 未选成功登入 R2 1邮箱登陆未选 择不输 入 输入 邮箱 正确 密码 输入 正确 未选成功登入 R3 2自动登录选择N/A N/A 输入 正确 未选成功登入 R4 3登录名有误未选 择输入不正确登 录名 N/A N/A 未选提示登录名有误 R5 4没机会输入 密码未选 择 输入正确登录 名 错误 密码 N/A 未选提示密码与登录名不 匹配且账号已锁定 R6 5有机会输入 密码未选 择 输入正确登录 名 错误 密码 N/A 未选提示密码与登录名不 匹配可再次登录 R7 6自动登录验 证码有误选择N/A N/A 输入 错误 未选提示输入验证码有误 R8 6非自动登录 验证码有误未选 择 N/A N/A 输入 错误 未选提示输入验证码有误 R9 7忘记密码N/A 输入正确登录 名 N/A N/A 选择出现忘记密码界面

测试用例设计-场景法

测试用例设计-场景法(个人见解与学习)

目录 1、引言 (3) 2、基本测试 (3) 2.1、测试优缺点 (3) 2.2、黑盒功能测试分解法 (3) 2.3、个人简介篇 (3) 3、场景法用例 (4) 1、什么是场景法? (4) 2、场景法特点 (4) 3.1、基本流 (6) 3.2、分支流 (6) 3.3、验证流 (7) 3.4、异常 (7) 3.4.1、个人简介 (7) 4、场景法用例设计 (7) 文档中红色字体的为理解的重点 黄色背景的为个人简介和思路 同时提出:这里只是说明一组方法。具体如何使用,可以结合自己的标准来做。

1、引言 文档属于个人的见解,个人看法。因为我当时看到同样的一个项目,一个软件需求。就是使用方法不一样;我们就写的用例覆盖率就出现了这么多的偏差。 2、基本测试 如按照如下的方法去分解: 功能测试、界面测试、性能测试、安全测试、数据库测试等等测试2.1、测试优缺点 能够按照软件的功能块,一组一组的来做相应的模块测试。但对整体业务场景考虑的不是很好,可能遗漏模块A与模块B之间的用例,因为该方法是从软件本身出发。实际做测试时需要考虑的不是软件本身,还有对应的系统场景等情况。不容易做回归测试,一旦回归需要考虑到用例的回归量。。后续测试时间会很长。 2.2、黑盒功能测试分解法 ?在任何情况下都必须使用边界分析发,经验表明用这种方法设计出的测试用例发现程序错误的能力最强(边界法) ?必要时用等价类划分方法补充一些测试用例(等价类法) ?用错误推测法再追加一些测试用例(错误推测法) ?如果程序的功能说明中含有输入条件的组合情况,则已开始可选用因果图法(因果图法) ?对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到要求的覆盖标准,应当再补充足够的测试用例(功能图) 其实这个经验就是方法,以上是一套方法。。 2.3、个人简介篇 上面的做法其实需要我们前期对功能的分解细密,在后期考虑到执行或者回归的时候。安排妥当,不然每次回归或者执行测试都需要执行那么多用例,人员安排上不行,时间上也是不允许。 通俗点来解释: 基本流:就是正常的,正确场景 备选流:分支流+中断

场景法测试用例ATM机

测试用例设计--场景法 1.定义 现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设用例场景用来描述流经用例的路径,从用例开始到结束遍历这条路径上所有基本流和备选流。 右图中经过用例的每条路径都用基本流和备选流来表示: 基本流用黑色表示,是经过用例的最简单的路径。 备选流用不同的彩色表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1 和3);也可能起源于另一个备选流(如备选流2),或者终止用例而不再重新加入到某个流(如备选流2 和4)。 1.应用的范围 1) 基本上每个软件都会用到这种方法,因为每个软件后面都有业务的支撑 2) 比较常见的有: 网上购物流程, ATM机取款流程等 1.步骤 1) 画出需要测试路径的流程图(一般选择工具Office Visio) 2) 分析基本流和备选流 3) 根据基本流和备选流设计测试用例 1.案例

基本事件流: 1、用户向ATM提款机中插入银行卡,如果银行卡是合法的,ATM提款机界面提示用户输入提款密码; 用户输入该银行卡的密码,ATM提款机与MainFrame传递密码,检验密码的正确性。如果输入密码正确,提示用户输入取钱金额,提示信息为,“请输入您的提款额度”; 用户输入取钱金额,系统校验金额正确,提示用户确认,提示信息为“您输入的金额是xxx,请确认,谢谢!”,用户按下确认键,确认需要提取的金额; 系统同步银行主机,点钞票,输出给用户,并且减掉数据库中该用户帐户中的存款金额。 用户提款,银行卡自动退出,用户取走现金,拔出银行卡,ATM提款机界面恢复到初始状态; 备选事件流(考虑可能失败的地方): 1.在基本事件流1中: a) 如果插入无效的银行卡,那么,在ATM提款机界面上提示用户“您使用的银行卡无效!”,3秒钟后,自动退出该银行卡。 1.在基本事件流2中: a) 如果用户输入的密码错误,则提示用户“您输入的密码无效,请重新输入”; b) 如果用户连续3次输入错误密码,ATM提款机吞卡,并且ATM提款机的界面恢复到初始状态。此时,其他提款人可以继续使用其他的合法的银行卡在ATM提款机上提取现金。 c) 用户输入错误的密码后,也可以按“退出”键,则银行卡自动退出。 1.在基本事件流3中:

场景法设计测试用例

如何使用场景法设计测试用例 通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果。场景法一般包含基本流和备用流,从一个流程开始,通过描述经过的路径来确定的过程,经过遍历所有的基本流和备用流来完成整个场景。 为什么场景法能如此清晰的描述整个事件?因为,现在的系统基本上都是由事件来触发控制流程的。如:我们申请一个项目,需先提交审批单据,再由部门经理审批,审核通过后由总经理来最终审批,如果部门经理审核不通过,就直接退回。每个事件触发时的情景便形成了场景。而同一事件不同的触发顺序和处理结果形成事件流。这一系列的过程我们利用场景法可以清晰的描述清楚。 下图来展示一下网上最长见的场景法基本情况的一个实例图。 在这个图中,有一个基本流和四个备选流。 每个经过用例的可能路径,可以确定不同的用例场景。从基本流开始,再将基本流和备选流结合起来,可以确定以下用例场景: 场景 1 基本流

场景2 基本流备选流1 场景3 基本流备选流1 备选流 2 场景4 基本流备选流3 场景 5 基本流备选流3 备选流 1 场景 6 基本流备选流3 备选流 1 备选流2 场景7 基本流备选流4 场景8 基本流备选流3 备选流 4 从上面的实例我们就可以了解场景是如何利用基本流和备用流来确定的。 基本流:采用直黑线表示,是经过用例的最简单的路径(无任何差错,程序从开始直接执行到结束) 备选流:采用不同颜色表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中,也可以起源于另一个备选流,或终止用例,不在加入到基本流中;(各种错误情况) 下面是场景法的基本设计步骤 1. 根据说明,描述出程序的基本流及各项备选流 2. 根据基本流和各项备选流生成不同的场景 3. 对每一个场景生成相应的测试用例 4. 对生成的所有测试用例重新复审,去掉多余的测试用例,测试用例确定后,对每一个测试用例确定测试数据值 好了。说了一些场景法的基本概念和设计方法。想必大家已经有了一些了解了。再举一个简单例子来讲解下。这里,我就不用网上很流行的A TM的例子了。我结合以前项目中遇到的情况。设计一个简单的例子来讲解下。 有一个在线购物的实例,用户进入一个在线购物网站进行购物,选购物品后,进行在线购买,这时需要使用帐号登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。 第一步我们来确定基本流和备选流:

测试用例设计与编写规范

测试用例设计与编写规范

目录 1本系统功能测试 (2) 1.1模块功能测试 (2) 1.1.1测试用例属性 (2) 1.1.2测试用例功能设计原则 (2) 1.2模块间数据交互测试 (7) 1.2.1关联点(前置条件、后置条件) (7) 1.2.2数据交互 (7) 1.3兼容、安全、UI测试 (7) 1.3.1兼容测试 (7) 1.3.2UI测试 (7) 1.3.3安全测试 (8) 2系统间接口测试 (8) 3测试用例执行 (8) 4附录 (10) 4.1场景法设计 (10) 4.1.1定义 (10) 4.1.2场景设计 (10) 4.1.3设计步骤 (15) 4.2边界值设计 (15) 4.2.1定义 (15) 4.2.2设计方法 (15) 4.3等价类划分设计 (15) 4.3.1定义 (15) 4.3.2设计方法 (16)

1本系统功能测试 1.1模块功能测试 1.1.1测试用例属性 1.1.2测试用例功能设计原则 设计测试用例的方法参考本文档的附录 1.根据需求文档划分测试场景,按照测试场景命名测试步骤名称。如下图所示:

2.用例编号的命名规则为“模块名称(缩拼)”+“-”+“4位编号”,编号自0001号开始。例如:基础 信息模块的用例编号,JCXX-0001;【注】该条为EXCEL测试用例书写规则 3.对于XX点的测试需求,至少需要确定两个测试用例。一个测试用例代表预期的条件,它可用于核实 行为是否正确或符合预期结果(正面测试)。另一个测试用例代表不可接受的、异常的或意外的条件,它可用于核实是否以预期结果实现(负面测试); 4.每条测试用例是该页面中唯一的检查项; 5.每条用例描述的系统默认状态、默认数据也是该页面唯一的检查项。 1.1. 2.1数据输入 本系统中需输入的类型包括:文本框、下拉框、复选框、单选框、日期控件 ◆公共用例 A.文本框/文本域(100、1000个字符):长度校验、类型校验、是否必填项校验 1)超出数据库长度、页面定义的长度均不允许输入 2)当定义的长度“数据库长度>页面长度”时,超出页面长度则不允许输入 3)禁止输入的文本框,默认禁灰显示 B.下拉框:选择数据后是否有联动效果、点击后下拉显示数据内容、点击空白后下拉框收缩 C.单选框:选中、更换 D.复选框:选中、取消 E.日期控件:弹出位置、选中后日期按格式要求显示在日期输入框、输入日期后点击日期控件自动 定位到所选择的的日期 F.分页:下拉框条数选择、首页、上一页、下一页、尾页、GO、输入框页数 ◆各模块需书写的用例

功能测试用例的设计

实验目的 1.用因果图法分析原因结果,并决策表设计测试用例。 2.使用场景法设计测试用例。 实验内容 1.将三角形问题的可能结果扩展为:一般三角形、等腰三角形、等边三角形、直 角三角形、等腰直角三角形和非三角形,考虑用因果图法设计测试用例,给出完整步骤。 2.有一个在线购物的实例,用户进入一个在线购物网站进行购物,选购物品后, 进行在线购买,这时需要使用帐号密码登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。使用场景法设计上述问题的测试用例。 实验环境 Win dows XP 系统 四、实验步骤和结果 1.将三角形问题的可能结果扩展为:一般三角形、等腰三角形、等边三角形、直角三角形、等腰直角三角形和非三角形,用因果图法设计测试用例,给出完整步骤。具体如下: 1)输入的三边分别为a,b,c(斜边)且a

2 2 2 c5 : a +b =c & a=b e5 :等腰直角三角形 e6 :非三角形 3)因果图 4)将因果图转化为决策表 条件 c1: a+b>c 5测试用例编号 输入数据 预期输出 1 a=1 b=3 c=5 非三角形 2 a=4 b=5 c=8 一般三角形 3 a= 4 b=4 c= 5 等腰三角形 4 a=4 b=4 c=4 等边三角形 c2: a=b c3: b=a = c , 2 I 2 2 c4: a +b =c Y 0 0 0 0 Y Y 0 0 0 Y 0 Y 0 0 Y Y 0 Y 0 Y 0 0 0 Y Y Y 0 0 Y 2 2 2 c5: a +b =c & a=b e1 一般三角形 e2等腰三角形 e3等边三角形 e4直角三角形 e5等腰直角三角形 e6非三角形 不可能 测试用例 a=1 b=3 c=5 a=4 b=8 a=4 b=4 c=5 a=4 b=4 c=4 等边 直角 a=3 b=4 c=5 a=1 b=1 c=V 5 1

测试用例的几种常用设计方法

测试用例的几种常用设计方法 一、等价类划分 等价类划分主要适用于单个输入条件,输入为数值型的情况,如果输入规定了输入区间,可划分出一个有效等价类,两个无效等价类;如果输入只规定了输入范围,可划分出一个有效等价类,一个无效等价类。 二、边界值 边界值方法也是适用于单个输入条件的情况,输入类型可以数值、字符等,要测试的边界包括上点、下点、离点。 三、错误推测法 错误推测法主要是测试设计人员的测试经验相关,测试经验不同,设计出来的测试用例也区别很大。 四、因果图法 因果图方法考虑输入的组合,特别适用于多个输入条件相关有关联又相互约束的情况。 设计步骤: 1)罗列出输入与输出; 2)根据输入与输出画出因果图; 3)标出约束跟限制; 4)把因果图转化成判定表; 5)根据判定表的每一列设计测试用例。 五、判定表驱动法 判定表适合于解决多个逻辑条件的组合。将各种逻辑的组合罗列出来,避免遗漏。不能表达重复的操作。 判定表包括条件桩、条件项、动作桩、动作项。 条件桩:列出所有条件,次序无关; 条件项:列出所对应条件的所有可能情况下的取值; 动作桩:列出可能采取的操作,次序无关; 动作项:列出条件项各种取值情况下采取的操作。 设计步骤: 1)确定规则个数,条件及各条件取值的组合; 2)列出条件桩、动作桩; 3)列出条件项; 4)列出动作项; 5)初始化判定表; 6)规则简化、合并。 六、正交法 当输入条件很多时,因果图等设计方法设计出来的用例数往往多的惊人,用正交法可有效减少用例数。正交法的核心思想是从大量测试数据中选取有代表性的点来测试,从而减少测试用例数。 设计步骤: 1)确定因子并画出正交表草图; 2)填充各因子的状态值;

实验七黑盒测试之场景法测试实验(参考答案)

实验七黑盒测试之场景法测试实验 1.1实验目的 1、通过对简单程序进行黑盒测试,熟悉测试过程,对软件测试形成初步了解,并养成良好的测试习惯。 2、掌握黑盒测试的基础知识,能熟练应用场景法进行测试用例的设计。 1.2实验平台 操作系统:Windows 7 或Windows XP 1.3实验内容及要求 1、练习1 软件系统几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。场景法就是通过用例场景描述业务操作流程,从用例开始到结束遍历应用流程上所有基本流(基本事 件)和备选流(分支事件)。下面是对某IC卡加油机应用系统的基本流和备选流的描述。 基本流A;

备选流: (1)使用场景法设计测试案例,指出场景涉及到的基本流和备选流,基本流用 场景1: 场景2: 场景3: 场景4: 场景5: (2) 场景中的每一个场景都需要确定测试用例,一般采用矩阵来确定和管理测 试用例。如下表所示是一种通用格式,其中行代表各个测试用例,列代表测试用 例的信息。本例中的测试用例包含测试用例、ID 、场景涤件、测试用例中涉及的 所有数据元素和预期结果等项目。首先确定执行用例场景所需的数据元素 (本例 中包括账号、是否黑名单卡、输入油量、账面金额、加油机油量 ),然后构建矩 阵,最后要确定包含执行场景所需的适当条件的测试用例。在下面的矩阵中, 表示有效数据元素,I 表示无效数据元素,n/a 表示不适用,例如C01表示“成 功加油”基本流。请按上述规定为其它应用场景设计用例矩阵。 测试用例表 字母A 表示, 备选流用题干中描述的相应字母表 示。

相关文档
最新文档