测试设计.docx
- 文档编号:6708159
- 上传时间:2023-01-09
- 格式:DOCX
- 页数:28
- 大小:88.17KB
测试设计.docx
《测试设计.docx》由会员分享,可在线阅读,更多相关《测试设计.docx(28页珍藏版)》请在冰豆网上搜索。
测试设计
1描述
1.1测试用例粒度划分
将测试需求的树形结构转换为测试用例的树形结构。
一般而言,测试需求叶子节点与测试用例的对应关系为1:
1。
对于部分项目,为了达到测试需求与测试用例的一比一的对应关系,测试用例会被分割得很细,每个用例中可能仅包含很少的几个测试步骤,追求这种一一对应关系也许并不合适,而是追求测试用例的规模适中。
对于另一些项目,即使达到测试需求与测试用例的一比一的对应关系,测试用例的粒度过粗,每个测试用例所包含的测试步骤可能过多,需要对测试用例的粒度进行进一步划分。
1.2测试用例设计思路
1.2.1从软件开发的角度进行思考
1.2.1.1用户需求
用户需求指出系统或应用软件应当做什么和不应当做什么,软件开发过程中的需求定义阶段,由于没有进行交流、交流错误或者交流不充分,都给软件设计造成误导。
测试案例的设计首先必须从用户需求出发,我们在测试过程中发现许多争论不清的错误和矛盾正是出于用户需求的不明确。
不满足用户需求的软件,其它方面即使很完美,也不是一个合格的软件。
1.2.1.2软件特征
目前的软件系统和应用软件是比较复杂的,客户端/服务器、浏览器/服务器、数据通信、巨大的关系数据库技术的利用以及规模庞大,所有这一切都造成系统/软件的复杂性提高,以至于没有一定基础的人不可能全面地掌握它。
系统/软件本身的复杂性和相互之间频繁的联系使软件的出错概率提高,也使测试的难度提高,给工程师的素质提出更高的要求。
广阔的技术领域和熟练的基础知识是设计高质量测试案例的必备条件。
1.2.1.3编程错误
编程的错误是造成软件功能错误和性能不能满足要求的主要因素,另外,软件开发工具例如:
类库、编译器、编辑工具等等,都会把本身的故障引入,从而导致更多故障的产生。
和所有的人一样,程序员也会犯错误,而且对于自己的错误经常视而不见。
软件测试工程师从编程的角度来挖掘错误的根源,设计测试案例有特殊的优势。
1.2.1.4需求变化
客户要改变需求多数是合理的,但其恐怕没有意识到改变需求造成的影响,可能会导致重新软件设计、波及其他项目、对已完成工作的否认、硬件需求的改变等等。
例如需求的改变可能会使项目中出现许多小改变或一个大改变,出现已知、未知的问题以及相互影响导致出现的问题。
在一些特殊的环境里,持续变更需求的影响是致命的,可能会导致大量致命错误的出现。
软件测试工作必须与此变更相适应,重视测试案例在回归测试中的设计与使用,进行持续的广泛的测试,不让需求变化带来的问题漏网。
1.2.1.5人为因素
人们通常喜欢这样说:
“没问题”、“太简单”、“修改老代码是不难的事”、“我用很短的时间就能完成”,而不是说:
“我们没有太多把握”、“新增加的工作很复杂,可能会出现无法预料的错误”、“我们不能估计修改旧代码是否能成功”、“我在实际工作之前,无法估计需要多长时间完成”。
忠言虽然逆耳,但太多的“没问题”,必然会出问题。
测试案例的设计多从细小、经常被大家“不放在眼里”的问题考虑,经常会发现意想不到的错误。
1.3测试用例设计方法
1.3.1功能测试用例的设计
1.3.1.1功能测试基本概念
功能测试主要针对产品需求说明书的测试,主要是验证功能是否符合需求,包括原定功能的检查、是否有冗余功能、遗漏功能;逻辑是否正确。
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。
这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。
此类测试基于黑盒技术,该技术通过图形用户界面(GUI)与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。
功能测试的主要参考为类似于功能说明书之类的文档。
比如一个对电子商务系统,前台用户浏览商品-放入购物车-进入结账台,后台处理订单,配货,付款,发货,这一系列流程必须正确无误的走通,不能存在任何的错误。
1.3.1.2有多级权限设置的功能测试
在很多系统中,都有多种用户权限,依次拥有不同的功能权限,针对此类功能如何进行测试,以下举例说明:
在某一个系统中,有这样的权限说明:
⏹用户A1、A2、A3:
录入权限
⏹用户B1、B2、B3:
普通管理权限
⏹用户C1、C2、C3:
高级管理权限
系统功能:
⏹用户在录入系统中添加留言信息,提交给管理员回复审核。
(未回复)
⏹普通管理员可以对留言进行回复,但是必须经过高级管理员审核才能最终回复。
(回复提交)
⏹普通管理员可以对留言直接进行拒绝。
(银行退回)
⏹高级管理员可以对留言回复进行授权发布。
(已回复)
⏹高级管理员可以驳回留言回复。
(回复驳回)
⏹用户A只能看到自己的留言信息
⏹用户B可以看到所有用户A的留言信息
⏹用户C可以看到所有用户B回复的信息
设计用例:
按功能设计用例:
⏹添加留言信息:
留言状态
⏹留言回复:
留言状态
⏹留言拒绝:
留言状态
⏹留言回复授权:
留言状态
⏹留言回复驳回:
留言状态
按用户权限设计用例
⏹录入员添加新留言:
可以查看那些状态的留言
⏹普通管理员回复、拒绝留言:
可以查看那些状态的留言,并进行回复拒绝操作
⏹高级管理员授权、驳回留言回复:
可以查看那些状态的留言,并进行授权驳回操作
1.3.1.3安装卸载用例的设计
安装测试主要检查软件是否可以正确安装,安装文件的各项设置是否有效,安装后能否影响原系统;反安装是逆过程,测试是否删除干净,是否会影响原系统等。
安装测试有两个目的。
第一个目的是确保该软件在正常情况和异常情况的不同条件下:
例如,进行首次安装、升级、完整的或自定义的安装_都能进行安装。
异常情况包括磁盘空间不足、缺少目录创建权限等。
第二个目的是核实软件在安装后可立即正常运行。
这通常是指运行大量为功能测试制定的测试。
安装测试包括测试安装代码以及安装手册。
安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。
1.3.2单元测试用例的设计
1.3.2.1单元测试基本概念
单元测试任务包括:
⏹模块接口测试;
⏹模块局部数据结构测试;
⏹模块边界条件测试;
⏹模块中所有独立执行通路测试;
⏹模块的各条错误处理通路测试
编码阶段主要完成的工作是根据详细设计说明书编写程序源代码,包括必要的数据文件,并进行单元测试,单元测试的内容包括模块内程序的逻辑、功能、参数传递、变量引用、出错处理、需求和设计中有具体的要求等方面测试。
对于结构化的编程语言,程序单元:
程序中定义的函数或者子程序。
单元测试是指对函数或者子程序所进行的测试。
对于面向对象的编程语言,程序单元:
特定的一个具体的类,或者相关的多个类,单元测试主要是对类方法的测试。
单元测试包括:
静态的代码审查和动态测试两个阶段
⏹静态的代码审查
代码审查是按照《代码审查单》中的条项对单元模块进行逐项检查。
⏹动态测试
动态测试阶段首先编写驱动模块和桩模块后,在驱动模块和桩模块中设计相应的测试用例,对所有的测试用例进行统一编号,在源代码中进行注释标识。
测试用例应该覆盖单元模块的所有功能项,如果单元模块有性能、余量等其他测试特性要求,则必须设计相应的测试用例测试这些特性。
1.3.2.2单元测试的实施
按照单元测试规范进行实施,进行代码审查和动态测试。
⏹单元测试或者集成测试涉及的源程序三种:
被测类/被测单元、已通过的类/桩模块、测试单元。
只需对被测类进行测试设计、进行代码覆盖率分析和代码性能分析,用多种优化编译选项进行编译和测试。
⏹不需为已通过的类/桩模块进行测试设计,这些模块单元和测试单元本身都进行代码不需要使用一些工具要求的编译选择和编译优化选项进行编译,也不需要为其生成代码覆盖率报告。
对于各种运行平台下,都需要使用-00,-02,-033种编译优化选项对测试单元进行编译,并运行一个测试单元中的所有测试用例,生成测试报告。
1.3.3黑盒测试的用例设计
黑盒测试法主要注重测试软件的功能需求,试图发现下列几类错误:
⏹功能不对或者遗漏
⏹界面错误
⏹数据结构或外埠数据库访问错误
⏹性能错误
⏹初始化和终止错误
具体的黑盒测试方法包括等价类划分、因果图、正交试验设计法、边界值分析、判定表驱动发、功能测试等。
1.3.3.1等价类划分
等价类划分是一种典型的黑盒测试方法,用这一方法设计测试用例完全不考虑程序的内部结构,只根据对程序的要求和说明,即《需求规格说明书》。
必须仔细分析和推敲说明书的各项需求,特别是功能需求。
把说明中对输入的要求和输出的要求区别开来并加以分解。
等价类划分的办法是把程序的输入域划分成若干部分,然后从每个部分中选取少数代表性数据当作测试用例。
每一类的代表性数据在测试中的作用等价于这异类中的其它值,也就是说,如果某一类中的一个例子发现了错误,这一等价类中的其他例子也能发现同样的错误;反之,如果某异类中的一个例子没有发现错误,则这一类中的其他例子也不会查出错误。
在考虑等价类划分时,先从程序的功能说明中找出各个输入条件,然后为每个输入条件划分两个或更多等价类。
等价类可以分为两种情况:
有效等价类和无效等价类。
有效等价类是指对程序的规格说明是有意义的、合理的输入数据所构成的集合。
无效等价类是指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。
⏹如果输入条件规定了取值的范围或值的个数,则可确定一个有效等价类和两个无效等价类。
如数据值是从1到99,则可以划分一个合理等价类(大于1而小于99)和两个无效等价类(小于1的数,以及大于99的数)
⏹如果一个输入条件说明了一个“必须成立”的情况(如变量名必须以字母开头),可划分一个有效等价类(第一个字符是字母)和一个无效等价类(第一个字符不是字母)
⏹如果输入条件规定了输入数据的一组可能的值,而且程序是用不同的方式处理每种值,则可以为每一种值划分一个有效等价类,并划分一个无效等价类。
⏹如果我们确知,已划分的某等价类中的各元素在程序中的处理方式是不同的,则应据此将此等价类进一步划分成更小的等价类。
1.3.3.2边界值分析
边界值分析是一种补充等价划分的测试用例设计技术,他不是选择等价类的任何元素,而是选择等价类边界的测试用例。
实践证明,在设计测试用例时,对半截附近的处理必须给予足够的重视,为检验边界附近的处理专门设计测试用例常常取得良好的效果。
⏹如果输入条件规定了取值范围,应以该范围的边界内及刚刚超过范围的边界外的值作为测试用例。
如以a和b为边界,测试用例应当包含a和b、略大于a、略小于b的值。
⏹若规定了值的个数,分别以最大、最小个数及稍小于最小、稍大于最大个数作为测试用例。
⏹针对每个输出条件使用前面的第一和第二条原则
⏹如果程序规格说明书中提到的输入或输出域是个有序的集合、顺序文件、表格等就应该有意选取有序集的第一个和最后一个元素作为测试用例。
⏹分析规格说明,找出其他的可能边界条件。
1.3.3.3因果图
采用因果图方法的思路是,从用自然语言书写的程序规格说明书的描述中找出因(输入条件)果(输出或程序状态)的改变,通过因果图转换为判定表
⏹分析程序规格说明的描述中,那些是原因,那些是结果,原因常常是输入条件或者输入条件的等价类。
而结果是输出条件。
⏹分析程序规格说明的描述中语义的内容,并将其表示成连接各原因与各个结果的因果图。
⏹由于逾分或环境的限制,有些原因和结果的组合情况是不可能出现的,为表明这些特定的情况,在因果图上使用若干个特殊的标号标明约束条件。
⏹把因果图转换成判定表
⏹为判定表中每一列表示的情况设计测试用例。
以中国象棋中走马的测试用例设计为例
一、分析中国象棋中走马的实际情况(下面未注明的均指的是对马的说明):
1.如果落点在棋盘外,则不移动棋子;
2.如果落点与起点不构成日字型,则不移动棋子;
3.如果落点处有自己方棋子,则不移动棋子;
4.如果在落点方向的邻近交叉点有棋子(绊马腿),则不移动棋子;
5.如果不属于1-4条,且落点处无棋子,则移动棋子;
6.如果不属于1-4条,且落点处为对方棋子(非老将),则移动棋子并除去对方棋子;
7.如果不属于1-4条,且落点处为对方老将,则移动棋子,并提示战胜对方,游戏结束。
二、根据分析明确原因和结果
(一)原因:
1.落点在棋盘上;
2.落点与起点构成日字;
3.落点处为自己方棋子;
4.落点方向的邻近交叉点无棋子;
5.落点处无棋子;
6.落点处为对方棋子(非老将);
7.落点处为对方老将。
(二)结果:
1.不移动棋子;
2.移动棋子;
3.移动棋子,并除去对方棋子;
4.移动棋子,并提示战胜对方,结束游戏。
添加中间节点11,目的是作为导出结果的进一步原因,简化因果图导出的判定表:
图1因果图
考虑结果不能同时发生,所以对其施加唯一约束O。
原因5、6、7不能同时发生,所以对其施加异约束E。
三、根据因果图建立判定表:
(分为两表)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
原因
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
2
0
0
1
1
0
0
1
1
0
0
1
1
0
0
1
1
3
0
0
0
0
1
1
1
1
0
0
0
0
1
1
1
1
4
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
结果
11
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
21
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
用例
1
2
3
4
5
6
7
8
9
`0
11
12
13
14
15
16
原因
11
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
5
0
0
1
1
0
0
1
1
0
0
1
1
0
0
1
1
6
0
0
0
0
1
1
1
1
0
0
0
0
1
1
1
1
7
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
结果
22
0
0
1
0
0
0
0
23
0
0
0
0
1
0
0
24
0
0
0
0
0
0
1
用例
注:
1、以上判定表中由于表格大小限制没有列出最后所选的测试用例;2、第2表中部分列被合并表示不可能发生的现象;3、通过中间节点将用例的判定表简化为两个小表。
减少工作量。
四、根据判定表,写测试用例表
1.3.4白盒测试的用例设计
白盒测试是根据程序的控制结构设计测试用例,原则是:
2.保证一个模块中的所有独立路径至少被使用一次
3.对所有逻辑值均需测试true和false
4.在上下边界及可操作范围内运行所有循环
5.检查内部数据结构以确保其有效性
开发人员一定要认真调试代码,只有把自己负责的部分和其他模块的接口部分进行详细的测试。
这项由开发人员进行的基础测试是不可缺少的。
目标就是把尽可能多的缺陷消灭在开发阶段。
现代软件系统十分复杂,程序员写了程序不仔细检查代码,大多会有很多缺陷存在。
1.3.5性能测试用例的设计
在交替进行负荷和强迫测试时常用的术语。
性能测试关注的是系统的整体。
他和通常所说的强度、压力/负载测试有密切的关系。
所以压力和强度测试应该于性能测试一同进行。
例如:
针对一个网站进行测试,模拟10到50个用户就是在进行常规性能测试,用户增加到1000乃至上万,就变成了压力/负载测试。
如果同时对系统进行大量的数据查询操作,就包含了强度测试。
压力测试注重的是外界不断施压,强度测试注重的是极限或者异常情况下系统的测试。
性能测试主要测试软件的性能,包括负载测试,强度测试,数据库容量测试,基准测试以及基准测试。
1.3.6用例场景的设计
1.3.6.1用例场景设计基本概念
现在的软件几乎都是由事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果形成事件流。
这种在软件设计方面的思想也可被引入到软件测试中,生动的描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时测试用例也更容易的得到理解和执行。
提出这种测试思想的是Rational公司,在RUP2000中文版当中有其详尽的解释和应用,用例场景贯穿其中。
下图中经过用例的每条不同路径都反映了基本流和备选流,都用箭头来表示。
基本流用直黑线来表示,是经过用例的最简单的路径。
每个备选流自基本流开始,之后,备选流会在某个特定条件下执行。
备选流可能会重新加入基本流中(备选流1和3),还可能起源于另一个备选流(备选流2),或者终止用例而不再重新加入某个流(备选流2和4)。
图2使用用例场景进行分析
遵循上图中每个经过用例的可能路径,可以确定不同的用例场景。
从基本流开始,再将基本流和备选
流结合起来,可以确定以下用例场景:
场景1基本流
场景2基本流备选流1
场景3基本流备选流1备选流2
场景4基本流备选流3
场景5基本流备选流3备选流1
场景6基本流备选流3备选流1备选流2
场景7基本流备选流4
场景8基本流备选流3备选流4
注:
为方便起见,场景5、6和8只描述了备选流3指示的循环执行一次的情况。
1.3.6.2用例场景设计实例
一台ATM机器的主角和用例。
图3ATM用例场景设计实例
下表包含了上图中提款用例的基本流和某些备选流:
表1基本流与备选流分析
基本流
本用例的开端是ATM处于准备就绪状态。
准备提款-客户将银行卡插入ATM机的读卡机。
验证银行卡-ATM机从银行卡的磁条中读取账户代码,并检查它是否属于可以接收的银行卡。
输入PIN-ATM要求客户输入PIN码(4位)验证账户代码和PIN-验证账户代码和PIN以确定该账户是否有效以及所输入的PIN对该账户来说是否正确。
对于此事件流,账户是有效的而且PIN对此账户来说正确无误。
ATM选项-ATM显示在本机上可用的各种选项。
在此事件流中,银行客户通常选择“提款”。
输入金额-要从ATM中提取的金额。
对于此事件流,客户需选择预设的金额(10美元、20美元、50美元或100美元)。
授权-ATM通过将卡ID、PIN、金额以及账户信息作为一笔交易发送给银行系统来启动验证过程。
对于此事件流,银行系统处于联机状态,而且对授权请求给予答复,批准完成提款过程,并且据此更新账户余。
出钞-提供现金。
返回银行卡-银行卡被返还。
收据-打印收据并提供给客户。
ATM还相应地更新内部记录。
用例结束时ATM又回到准备就绪状态。
备选流1-银行卡无效
在基本流步骤2中-验证银行卡,如果卡是无效的,则卡被退回,同时会通知相关消息。
备选流2-ATM内没有现金
在基本流步骤5中-ATM选项,如果ATM内没有现金,则“提款”选项将无法使用。
备选流3-ATM内现金不足
在基本流步骤6中-输入金额,如果ATM机内金额少于请求提取的金额,则将显示一则适当的消息,并且在步骤6-输入金额处重新加入基本流。
备选流4-PIN有误
在基本流步骤4中-验证账户和PIN,客户有三次机会输入PIN。
如果PIN输入有误,ATM将显示适当的消息;如果还存在输入机会,则此事件流在步骤3-输入PIN处重新加入基本流。
如果最后一次尝试输入的PIN码,仍然错误,则该卡将被ATM机保留,同时ATM返回到准备就绪状态,本用例终止。
备选流5-账户不存在
在基本流步骤4中-验证账户和PIN,如果银行系统返回的代码表明找不到该账户或禁止从该账户中提款,则ATM显示适当的消息并且在步骤9-返回银行卡处重新加入基本流。
备选流6-账面金额不足
在基本流步骤7-授权中,银行系统返回代码表明账户余额少于在基本流步骤6-输入金额内输入的金额,则ATM显示适当的消息并且在步骤6-输入金额处重新加入基本流。
备选流7-达到每日最大的提款金额
在基本流步骤7-授权中,银行系统返回的代码表明包括本提款请求在内,客户已经或将超过在24小时内允许提取的最多金额,则ATM显示适当的消息并在步骤6-输入金额上重新加入基本流。
备选流x-记录错误
如果在基本流步骤10-收据中,记录无法更新,则ATM进入“安全模式”,在此模式下所有功能都将暂停使用。
同时向银行系统发送一条适当的警报信息表明ATM已经暂停工作。
备选流y-退出
客户可随时决定终止交易(退出)。
交易终止,银行卡随之退出。
备选流z-“翘起”
ATM包含大量的传感器,用以监控各种功能,如电源检测器、不同的门和出入口处的测压器以及动作检测器等。
在任一时刻,如果某个传感器被激活,则警报信号将发送给警方而且ATM进入“安全模式”,在此模式下所有功能都暂停使用,直到采取适当的重启/重新初始化的措施。
第一次迭代中,根据迭代计划,我们需要核实提款用例已经正确地实施。
此时尚未实施整个用例,只实施了下面的事件流:
基本流-提取预设金额(10美元、20美元、50美元、100美元)
备选流2-ATM内没有现金
备选流3-ATM内现金不足
备选流4-PIN有误
备选流5-账户不存在/账户类型有误
备选流6-账面金额不足
以从这个用例生成下列场景:
表2场景表
场景1-成功的提款
基本流
场景2-ATM内没有现金
基本流
备选流2
场景3-ATM内现金不足
基本流
备选流3
场景4-PIN有误(还有输入机会)
基本流
备选流4
场景5-PIN有误(不再有输入机会)
基本流
备选流4
场景6-账户不存在/账户类型有误
基本流
备选流5
场景7-账户余额不足
基本流
备选流6
注:
为方便起见,备选流3和6(场景3和7)内的循环以及循环组合未纳入上表。
对于这7个场景中的每一个场景都需要确定测试用例。
可以采用矩阵或决策表来确定和管理测试用例。
下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。
本示例中,对于每个测试用例,存在一个测试用例ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。
通过从确定执行用例场景所需的数据元素入手构建矩阵。
然后,对于每个场景,至少
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 设计