当前位置: 首页>后端>正文

核心阶段1:软件测试设计(软件测试核心之用例设计)

5.1测试设计与测试用例

? ? ? ? ? ? ? ? ? ? ? ? ? ? ?破刀式—软件测试设计

5.1.1测试设计

定义:

? ? ? 测试设计是将概括的测试目标转化为具体的测试条件和测试用例的一系列活动。

5.1.2测试分析和设计的主要内容

①评审测试依据(需求,系统架构、设计和接口说明)。

②评估测试依据和测试对象的可靠性。

③通过对测试项、规格说明、测试对象行为和结构的分析,识别测试条件并确定优先级。

④设计测试用例,并确定优先级

⑤确定测试条件和测试用例所需要的必要的测试数据。

5.1.3确定测试条件

①依据在测试策略或测试计划中确定的测试技术。

②通过对测试依据和测试目标的分析,可以确定需要测试的内容,获得测试条件。

核心阶段1:软件测试设计(软件测试核心之用例设计),第1张

5.1.4测试用例

定义:

? ? ? ?测试用例是通过使用在测试计划中确定的测试技术,对于已确定的测试条件进行逐步推敲,精炼而设计出来的重点说明如何具体操作产生何种结果的文档。(指引我们测试的文档)

测试用例的前提条件(要求):

? ? ? 测试用例应该具有可重复性、可验证性和需求可追踪性。

5.1.5测试用例设计包括以下关键点

①前提条件,如项目或局部测试环境的需求,及其交付计划。

②测试步骤。

③测试数据。

④预期结果。

5.1.6测试用例案例

核心阶段1:软件测试设计(软件测试核心之用例设计),第2张

5.2等价类划分的特点—掌握特点,随处用

例子:测试一个两位数的加法计算器

测试需求:

①测试两个参数的值相加后的结果是否正确

②期中:输入的数值在-99到99之间,大于99或小于-99的输入应该被拒绝,并显示错误信息。

根据测试需求,我们开始测试:

①分别给第一个参数和第二个参数输入表中的值,得到的测试加过如表所示:

核心阶段1:软件测试设计(软件测试核心之用例设计),第3张

②如果我们对第一个参数的值分别取从-99到99的199个数,第二个参数的值分别取从-99到99的199个数,我们不可能对两位数相加的所有情况进行穷举测试。

③如果不能进行穷举测试,我们将面临以下的问题:

? ? ? ? ?在测试了1+1,1+2,1+(-1)和1+(-2)之后,还是否有必要测试1+3,1+4呢?

? ? ? ? 如果不对加法计算器程序进行穷举测试,是否放心的认为所有的参数组合都是正确的呢

对于以上两个问题,我们可以采用等价类划分法来进行解决。

5.2.1等价类划分法

①等价类划分的办法就是把程序的输入域划分成若干部分。

②从每个部分中选取少数代表性数据当做测试用例。

③每一类的代表性数据在测试中的作用等价于这一类中的其他值。

④也就是说,如果某一类中的一个例子发现了错误,这一等价类中的其他例子也能发现同样的错误。

⑤繁殖,如果某一类中的例子没有发现错误,则这一等价类中的其他例子也不会发现错误。

5.2.2等价类划分的原则

①如果输入条件规定了取值范围或值的个数,则可确定一个有效等价类和两个无效等价类。

②如果一个输入条件说明了一个“必须成立”的情况,则可划分一个有效等价类和一个无效等价类。

③如果输入条件规定了输入数据的一组可能的值,而且程序使用不同的方式处理每一种值,则可为每一种值划分一个有效等价类,并划分一个无效等价类。

④如果我们确定,已划分的某等价类中的各元素(例子)在程序中的处理方式是不同的,则应据此将此等价类进一步划分成更小的等价类。

⑤在确定了等价类之后,建立等价类表,列出所有划分出的等价类。

5.2.3基于等价类划分的用例设计

①明确测试对象,非测试对象保证正确。

②为每个等价类规定一个唯一的编号。

③设计一个测试用例,使其尽可能多的覆盖尚未覆盖的有效等价类。重复这一步,最后使得所有有效等价类均被测试用例所覆盖。

④设计一个新的测试用例,使其只覆盖一个无效等价类。重复这一步使所有的无效等价类均被覆盖。

5.2.4等价类划分实战

例子是前面的加法计算机

STEP1:根据测试需求可以划分为三个等价类:

①一个有效数据等价类,两个无效数据等价类。

有效数据等价类就是:由那些对程序的规格说明有意义的、合理的输入数据所构成的集合。

无效数据等价类就是:那些对程序的规格说明不合理的或无意义的输入数据所构成的集合。

核心阶段1:软件测试设计(软件测试核心之用例设计),第4张

STEP2:建立等价类表:

? ? ? ?在实际工作中,我们通常在确立了等价类以后,把程序中所有的等价类建立等价类表,一遍在编写测试用例的时候有所依据。

核心阶段1:软件测试设计(软件测试核心之用例设计),第5张
等价类表

STEP3:确定测试用例:

①为等价类表中的每一个等价类分配一个唯一的编号。

②设计一个新的测试用例,使他能够尽量覆盖尚未未覆盖的有效等价类。

③重复这一步骤,从而使所有有效等价类均被测试用例所覆盖。

④与上述类似,设计一个新的测试用例,使它只覆盖一个无效等价类。

⑤重复这一步骤,从而使所有无效等价类均被测试用例所覆盖。

核心阶段1:软件测试设计(软件测试核心之用例设计),第6张

STEP4:细化等价类划分:

①在测试“-99≤数值99”的这个等价类区间的时候,我们会发现如10+40,-20+30和-30+(-30)这类的正数相加,正数负数相加,负数相加也是不同的等价区间。因此我们可以使用更多的等价类划分。

②根据以上等价类划分的加过,得出下表的等价类表:

核心阶段1:软件测试设计(软件测试核心之用例设计),第7张

STEP5:完善测试用例:

根据上面划分的4个等价类,我们至少需要有5个测试用例:

核心阶段1:软件测试设计(软件测试核心之用例设计),第8张

5.3等价类划分法的原则—最常用最实用的方法

5.3.1等价类的特点

①测试相同的内容。

②如果等价类中的一个测试能够获取一个缺陷,那么选择该等价类中的其他测试也能获取该缺陷。

③如果等价类中的一个测试不能获取缺陷,那么选择该等价类中的其他测试也不能获取缺陷。

④如果正确的花粉都能加了,可以大大降低测试用例的数量,测试会准确有效。

⑤如果错误的将两个不同的等价类当作一个等价类,那就会遗漏一种测试情况。

⑥相反的,把同一个等价类看作了两个不同的等价类,那么测试就会是冗余的。

5.3.2等价类划分要注意的问题

①不但要考虑有效等价类,也要考虑无效等价类。

②仔细划分,审查划分。

③过于粗略可能会漏掉软件缺陷。

⑤组织评审。

5.3.3等价类用例设计练习

测试需求:

①余额宝体现到银行卡增加新规则:快速到账(2小时)日限额1W元。

②超过1W元只能选择普通到账。

③按照等价类划分方法设计测试用例。

核心阶段1:软件测试设计(软件测试核心之用例设计),第9张

分析过程:

①设计用例:

核心阶段1:软件测试设计(软件测试核心之用例设计),第10张
等价类划分表

②细致分析需求,日限额1W,所以要区分两个场景:

核心阶段1:软件测试设计(软件测试核心之用例设计),第11张

5.4边界值法—不怕测不全的方法

5.4.1边界值分析法

定义:

? ? ? ?边界值分析法是一种补充等价划分的测试用例设计技术,它不是选择等价类的任意元素,而是选择等价类便捷的测试用例。

? ? ? ?实践证明,在设计测试用例时,对边界附近的处理必给予足够的重视,为检验便捷附近的处理专门设计测试用例,常常去的良好的测试效果。

? ? ? 边界值分析法不仅重视输入条件边界,而且也从输出域导出测试用例。

5.4.2边界值设计的原则

边界值用例:

? ? ? ? 如果输入条件规定了取值范围,应以该范围的边界内及刚刚超范围的边界外的值作为测试用例。

eg1:以a和b为边界,测试用例应当包含a和b以及略大于a和略小于b的值。

eg2:根据以上计算器的例子,根据边界值分析的方法来看看如何对边界值进行测试:

核心阶段1:软件测试设计(软件测试核心之用例设计),第12张

? ? ? ? 由于允许输入的额数值在-99到99之间,所以我们可以把-99和99看做两个边界值。我们测试的时候可以去临近边界值的数值和边界值本身作为输入:

核心阶段1:软件测试设计(软件测试核心之用例设计),第13张

eg3:余额宝体现到一囊卡增加新规则:快速到账(2小时)日限额1W元:

核心阶段1:软件测试设计(软件测试核心之用例设计),第14张

5.5因果图与判定表—不用多但很重要

? ? ? ?等价类划分法和边界值分析方法都是着重考虑输入条件而不考虑输入条件的个各种组合、输入条件之间的相互制约关系。

? ? ? ?如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字;因此必须考虑采用一种适合于描述多种条件的组合、产生多个相应动作的测试方法,这就需要利用因果图(逻辑模型)。

5.5.1因果图—判定表

? ? ? ?因果图法基于这样的思想:一些程序的功能可以用决策表的形式来表示,并根据输入条件的组合情况规定相应的操作;因此,可以考虑为决策表中的每一列设计一个测试用例,以便测试程序早输入条件的某种组合下的输出是否正确。

? ? ? 概括的说,因果图方法就是从程序规格说明书的描述中找出因(输入条件)和果(输出结果或程序状态的改变)。将因果图转换为判定表,为决策表中的每一列设计一个测试用例。这种方法考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系。

5.5.2判定表

定义:

? ? ? 判定表(Decision Table)是分析和表达多逻辑条件下执行不同操作的工具。是编写程序的辅助工具,可以把复杂的逻辑关系和多种条件组合的情况表达得及具体又明确。

核心阶段1:软件测试设计(软件测试核心之用例设计),第15张
“读书指南”判定表

判定表通常由四个部分组成:

①条件桩(Condition? Stub):列出了问题的所有条件,通常认为列出的条件的次序无关紧要。

②动作桩(Action Stub):列出了问题规定可能采取的操作,这些操作的排列顺序没有约束。

③条件项(Confition? Entry):列出针对它左列条件的取值,在所有可能情况下的真假值。

④动作项(Action? Entry ):列出在条件项的各种取值取值情况下应该采取的动作。

5.5.3设计步骤

①分析软件规格说明中哪些是原因(即输入条件或输出条件的等价类),哪些是结果(即输出条件),并给每个原因和结果赋予一个标识符。

②分析软件规格说明中语义的内容,找出原因与结果之间、原因与原因之间的对应关系,根据这些关系画出因果图。

③由于语法或环境的限制,有些原因和原因之间、原因和结果之间的组合情况不可能出现。为表名这些特定的情况,在因果图上使用一些记号表名约束或限制条件。

④把因果图转换为判定表。

⑤根据判定表中的每一列设计测试用例。

5.5.4实战

eg:使用因果图+判定表设计测试用例测试两位数计算器。

核心阶段1:软件测试设计(软件测试核心之用例设计),第16张

1、分析输入条件和输出条件

①输入1:? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ②输入2:

条件1:0≤X≤99? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 条件1:0≤X≤99? ??

条件2:-99≤X<0? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??条件2:-99≤X<0

条件3:X<-99? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??条件3:X<-99

条件4:X>99? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?条件4:X>99

输出:

正确计算

错误提示

2、分析条件互斥

输入1:

? ? ?1、2、3、4互斥

输入2:

? ? 1、2、3、4互斥

输出:

输出结果正确和错误互斥

3、分析、简化并画出判定表

核心阶段1:软件测试设计(软件测试核心之用例设计),第17张

得到的测试用例:

核心阶段1:软件测试设计(软件测试核心之用例设计),第18张

5.6正交实验法—特殊场景必用

定义:

? ? ? ?正交实验设计法(Orthogonal experimental design),是从大量的试验点中挑选出适量的、有代表性的点,应用依据伽罗卡瓦理论导出的“正交表”,合理的安排试验的一种科学的试验设计方法。

核心阶段1:软件测试设计(软件测试核心之用例设计),第19张

5.6.1正交实验法设计步骤

1、提取功能说明,构造因子—状态表

核心阶段1:软件测试设计(软件测试核心之用例设计),第20张

2、加权筛选,生成因素分析表

? ? ? ?计算个因子和状态的权值,删去一部分权值较小,即重要性比较小的因子或状态,使最后生成的测试用例集缩减到允许的范围。

3、利用正交表构造测试数据集

? ① 如果每个因子的状态树是不统一的,几乎不可能出现均匀的情况,必须首先用逻辑命令来组织个因子的状态,作出布尔图。

②根据布尔图得到相应结束的正交表。

③依照因果图上根节点到叶子节点的顺序逐步替换正交表上的中间节点,得到最终的正交表。

4、利用正交表每行数据构造测试用例

正交表:

正交表的表示形式:Ln(t^c)其中:L为正交表的代号,n为行数(试验行数),t为水平数,c为列数(因素数)。

eg:L4(2^3),它表示需做四次实验,最多可观察3个因素,每个因素均为2水平:

核心阶段1:软件测试设计(软件测试核心之用例设计),第21张
正交表

1:正确

2:错误

eg:一个正交表中也可以割裂的水平数不相等,我们称它为混合型正交表,如L8(2^4 4^1):

核心阶段1:软件测试设计(软件测试核心之用例设计),第22张
正交表

根据正交表的数据结构可以看出吧,正交表是一个n行c列的表,其中第j行由数码1,2,....tj组成,这些数码均各出现n/t次。

第二列的数码个数为2,t=2,即由1、组成,各数码均出现2次。

5.6.2如何查找正交表

1、Technical Support (support.saa.com)

http://support.sas.com/techsup/technote/ts723_Designs.txt

2、查Dr.GenichiTaguchi设计的正交表,

http://www.york.ac.uk/depts/maths/tables/orthogonal.htm

3、数理统计、试验设计等方面的书及附录中

? ? 关注点:因素数和对应的水平数组组成的矩阵

5.6.3正交实验法例子

eg:测试支付宝web网站,该网站点有大量的服务器和操作系统。并且有许多具有各种插件的浏览器需要考虑:

WEB浏览器:IE11、chrome、FireFox

插件:无、Flash、支付宝插件

应用服务器:IIS、Apache、Jetty

操作系统:Windows2000、Windows NT、Linux

1、提取系统功能说明中的因子

①WEB浏览器? ? ? ??

②插件

③应用服务器

④操作系统

2、分析个因子的状态

①插件:1=None、2=Flash、3=FireFox

②WEB浏览器:1=IE11、2=Chrome、3=FireFox

③应用服务器:1=IIS、2=Apache、3=Jetty

④操作系统:1=Windows2000、2=Windows NT、3=Linux

3、选择正交表

正交表水平数为3,因素数为4。选择L9(3^4)

核心阶段1:软件测试设计(软件测试核心之用例设计),第23张
正交表

4、将因子、状态映射到上面正交表中

核心阶段1:软件测试设计(软件测试核心之用例设计),第24张
正交表


5.7测试场景设计—提高测试效率

5.7.1场景法原理:

? ? ? ?现在的软件几乎都是用事件出发来控制流程的。事件触发时的情景形成了场景,而同一事件不同的触发顺序和处理结果就形成了事件流。

? ? ? ?这种在软件设计方面的思想可以引入到软件测试中,可以生动的描绘出时间触发时的情景,有利于设计测试用例,同时使测试用例更容易理解和执行。

5.7.2场景法基础设计

? ? ? ?经过用例的每条路径都用基本流和备选流来表示,之黑线表示基本流,是经过用例的最简单的路径。

核心阶段1:软件测试设计(软件测试核心之用例设计),第25张

? ? ? ?备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流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

5.7.3场景法设计步骤

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

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

③对每一个场景生成相应的测试用例。

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

eg:在淘宝的购物过程:

? ? ? ?用户登录到网站后,进行商品的选择,当选好自己心仪的商品后进行购买,这时把所需商品放进购物车,等进行结账的时候,用户需要登录自己注册的账号,登录成功后,进行结账并生成订单,整个购物过程结束。

①通过以上的描述,从中确定哪些是基本流,哪些是备选流:

核心阶段1:软件测试设计(软件测试核心之用例设计),第26张

②根据基本流和备选流来确定场景:

核心阶段1:软件测试设计(软件测试核心之用例设计),第27张


5.8实际测试中用例设计的综合运用

5.8.1测试用例综合设计

1、测试用例项划分

? ? ? ?测试用例划分的经典方法就是瀑布模型,从上到下,逐渐细分,大模块包括小模块,小模块包括更小的模块。

? ? ? 要从更多的角度切入系统,把系统切分成一块一块的,来进行测试,从而确保测试大项的完整性。

2、切面设计

? ? ? ?功能点切面:最常见的切面,通常认为页面上的一个按钮就是一个功能点。根据功能的复杂程度,按每个功能进行用例的撰写。

? ? ? 隐含切面:完整业务流程的测试;从需求、业务角度进行编写。

3、功能点用例设计

①任何情况下都必须使用边界值分析方法,经验表明用这种方法设计出测试用例发现程序错误的能力最强。

②必要时用等价类划分方法不从以希望测试用例。

③如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法。

④如果程序业务复杂度比较高,则使用使用场景法补充一部分测试用例。

eg:共享单车充值

核心阶段1:软件测试设计(软件测试核心之用例设计),第28张

1、边界值考虑充值金额:0元,1元,负数,非金额参数,多位小数(小数后3位),银行卡限额。

2、由于充值时可以选择不同的银行支付渠道,所以针对支付宝、微信、通联、银联、银行直连等渠道分别设计测试用例。

3、考虑异常场景,如充值失败、银行卡余额不足、银行返回超时等。

4、如果场景中还包含更复杂的业务场景,如满减、满赠、增加抽奖次数等,还需要结合场景法进行测试。


https://www.xamrdz.com/backend/3sw1996080.html

相关文章: