白盒测试案例

软件测试用例测试

测试用例由测试输入数据以及与之对应的输出结果组成. 测试用例设计的好坏直接决定了测试的效果和结果.

以说在软件测试活动中最关键的步骤就是设计有效的测试用例.

测试用例可以针对黑盒测试设计用例,也可以针对白盒测试设计用例,我们今天只讲针对白盒测试的用例设 语句覆

:语句覆盖就是设计若干个测试用例,运行被测试程序,使得每一条可执行语句至少执行一次;

判定覆盖(也称为分支覆盖):设计若干个测试用例,运行所测程序,使程序中每个判断的取真分支和取假分支至少执行一次;

条件覆盖:设计足够多的测试用例,运行所测程序,使程序中每个判断的每个条件的每个可能取值至少执行一次;

判定-条件覆盖:设计足够多的测试用例,运行所测程序,使程序中每个判断的每个条件的所有可能取值至少执行一次,并且每个可能的判断结果也至少执行一次,换句话说,即是要求各个判断的所有可能的条件取值组合至少执行一次;

条件组合测试:设计足够多的测试用例,运行所测程序,使程序中每个判断的所有可能的条件取值组合至少执行一次;

路径测试:设计足够多的测试用例,运行所测程序,要覆盖程序中所有可能的路径. 下面以例子进行分析讲解: void DoWork(int x,int y,int z) {

int k=0,j=0; if((x>3)&&(z5)) {

j=x*y+10; //语句块2 }

j=j%3; //语句块3 }

画出上面函数的流程图如下: 语句覆盖:

为了说明简略,分别对各个判断的取真,取假分支编号为b,c,d,e.

为了测试语句覆盖率只要设计一个测试用例就可以把三个执行语句块中的语句覆盖了. 测试用例输入为:{ x=4,y=5,z=5} 程序执行的路径是:abd

该测试用例虽然覆盖了可执行语句,但并不能检查判断逻辑是否有问题,例如在第一个判断中把&&错误的写成了||,则上面的测试用例仍可以覆盖所有的执行语句.可以说语句覆盖率是最弱的逻辑覆盖准则. 分支覆盖

对于上面的程序,如果设计两个测试用例则可以满足条件覆盖的要求. 测试用例的输入为: { x=4,y=5,z=5} { x=2,y=5,z=5}

上面的两个测试用例虽然能够满足条件覆盖的要求,但是也不能对判断条件进行检查,例如把第二个条件y>5错误的写成y3 取真值为T1,取假值为-T1 条件z5 取真值为T4,取假值为-T4

则可以设计测试用例如下 cd

T1,-T2,T3,-T4 acd

x=4,y=5,z=15 ce

-T1,T2,-T3,-T4 ace

x=2,y=5,z=5 bd

T1,T2,T3,T4 abd

x=4,y=6,z=5 覆盖分支 条件取值 通过路径 测试用例

上面的测试用例不但覆盖了所有分支的真假两个分支,而且覆盖了判断中的所有条件的可能值.

但是如果设计了下面的测试用例,则虽然满足了条件覆盖,但只覆盖了第一个条件的取假分支和第二个条件的取真分支,不满足分支覆盖的要求. cd

T1,-T2,T3,-T4 acd

x=4,y=5,z=5 cd

-T1,T2,-T3,T4 acd

x=2,y=6,z=5 覆盖分支 条件取值 通过路径 测试用例 分支条件覆盖:

分支条件覆盖就是设计足够的测试用例,使得判断中每个条件的所有可能取值至少执行一次,同时每个判断的所有可能判断结果至少执行,即要求各个判断的所有可能的条件取值组合至少执行一次. 根据定义只需设计以下两个测试用例便可以覆盖8个条件值以及4个判断分支. ce

-T1,-T2,-T3,-T4 ace

x=2,y=5,z=11 bd

T1,T2,T3,T4 abd

x=4,y=6,z=5

覆盖分支 条件取值 通过路径 测试用例

分支条件覆盖从表面来看,它测试了所有条件的取值,但是实际上某些条件掩盖了另一些条件.例如对于条件表达式(x>3)&&(z3)为假则一般的编译器不在判断是否z5)来说,若x==4测试结果为真,就认为表达式的结果为真,这时不再检查(y>5)条件了.因此,采用分支条件覆盖,逻辑表达式中的错误不一定能够查出来了. 条件组合覆盖:

条件组合覆盖就是设计足够的测试用例,运行被测试对象,使得每一个判断的所有可能的条件取值组合至少执行一次.

现在对例子中的各个判断的条件取值组合加以标记如下: x>3,z3,z>=10 记做T1 -T2, 第一个判断的取假分支 x<=3,z<0 记做-T1 T2, 第一个判断的取假分支 x=10 记做-T1 -T2,第一个判断的取假分支 x=4,y>5 记做T3 T4, 第二个判断的取真分支 x=4,y5 记做-T3 T4, 第二个判断的取真分支 x!=4,y 0) 5 {

6 if(0= =iType) 7 x=y+2; 8 else

9 if(1= =iType) 10 x=y+10; 11 else 12 x=y+20; 13 } 14 }

第一步:画出控制流图

c/c++语句中的控制语句表示含义如下:

图中的每一个圆称为流图的结点,代表一条或多条语句.流图中的箭头称为边或连接,代表控制流.

为了说明流图的用法,我们采用过程设计表示法,此处,流程图用来描述程序控制结构.可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件).在流图中,每一个圆,称为流图的结点,代表一个或多个语句.一个处理方框序列和一个菱形决测框可被映射为一个结点,流图中的箭头,称为边或连接,代表控制流,类似于流程图中的箭头.一条边必须终止于一个结点,即使该结点并不代表任何语句(例如:参见if-else-then结构的符号).由边和结点限定的范围称为区域.计算区域时应包括图外部的范围. 任何过程设计都要被翻译成控制流图. 画出其程序流程图和对应的控制流图如下:

程序设计中遇到复合条件时,生成的流图变得更为复杂.当条件语句中用到一个或多个布尔运算符(逻辑OR,AND,NAND,NOR)时,就出现了复合条件.下图为语句IF a OR b中的每一个a和b创建了一个独立的结点,包含条件的结点被称为判定结点,从每一个判定结点发出两条或多条边.例如: 1 if a or b 2 x 3 else 4 y

对应的逻辑为: 第二步:计算圈复杂度

圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量,将该度量用于计算程序的基本的独立路径数目,为确保所有语句至少执行一次的测试数量的上界.独立路径必须包含一条在定义之前不曾用到的边. 有以下三种方法计算圈复杂度: 流图中区域的数量对应于环型的复杂性;

给定流图G的圈复杂度-V(G),定义为V(G)=E-N+2,E是流图中边的数量,N是流图中结点的数量; 给定流图G的圈复杂度-V(G),定义为V(G)=P+1,P是流图G中判定结点的数量. 对应上面图中的圈复杂度,计算如下: 流图中有四个区域;

V(G)=11条边-9结点+2=4; V(G)=3个判定结点+1=4. 第三步:导出测试用例

根据上面的计算方法,可得出四个独立的路径: 路径1:4-14 路径2:4-6-7-14

路径3:4-6-8-10-13-4-14 路径4:4-6-8-11-13-4-14

根据上面的独立路径,去设计输入数据,使程序分别执行到上面四条路径. 第四步:准备测试用例

为了确保基本路径集中的每一条路径的执行,根据判断结点给出的条件,选择适当的数据以保证某一条路径可以被测试到,满足上面例子基本路径集的测试用例是: 路径1:4-14

输入数据:iRecordNum=0,或者取iRecordNum<0的某一个值 预期结果:x=0 路径2:4-6-7-14

输入数据:iRecordNum=1,iType=0 预期结果:x=2

路径3:4-6-8-10-13-4-14

输入数据:iRecordNum=1,iType=1 预期结果:x=10

路径4:4-6-8-11-13-4-14

输入数据:iRecordNum=1,iType=2 预期结果:x=20 工具方法:图形矩阵

导出控制流图和决定基本测试路径的过程均需要机械化,为了开发辅助基本路径测试的软件工具,称为图形矩阵(graph matrix)的数据结构很有用.

利用图形矩阵可以实现自动地确定一个基本路径集.一个图形矩阵是一个方阵,其行/列数控制流图中的结点数,每行和每列依次对应到一个被标识的结点,矩阵元素对应到结点间的连接(即边).在图中,控制流图的每一个结点都用数字加以标识,每一条边都用字母加以标识.如果在控制流图中第i个结点到第j个结点有一个名为x的边相连接,则在对应的图形矩阵中第i行/第j列有一个非空的元素x.

对每个矩阵项加入连接权值(link weight),图矩阵就可以用于在测试中评估程序的控制结构,连接权值为控制流提供了另外的信息.最简单情况下,连接权值是 1(存在连接)或0(不存在连接),但是,连接权值可以赋予更有趣的属性:

执行连接(边)的概率. 穿越连接的处理时间. 穿越连接时所需的内存. 穿越连接时所需的资源.

根据上面的方法对例子画出图形矩阵如下:

连接权为\表示存在一个连接,在图中如果一行有两个或更多的元素\则这行所代表的结点一定是一个判定结点,通过连接矩阵中有两个以上(包括两个)元素为\的个数,就可以得到确定该图圈复杂度的另一种算法. 小结:

从上面的概念和例子可以看出要进行上面的白盒测试是需要投入巨大的测试资源,包括人力,物力和时间等.但是为什么还要进行白盒测试呢 原因如下:

逻辑错误和不正确假设与一条程序路径被运行的可能性成反比.当我们设计和实现主流之外的功能,条件或控制时,错误往往开始出现在我们的工作中.日常处理往往被很好地了解(和很好地细查),而\特殊情况\的处理则难于发现.

我们经常相信某逻辑路径不可能被执行,而事实上,它可能在正常的基础上被执行.程序的逻辑流有时是违反直觉的,这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误,只有路径测试才能发现这些错误.

印刷上的错误是随机的.当一个程序被翻译为程序设计语言源代码时,有可能产生某些打印错误,很多将被语法检查机制发现,但是,其他的会在测试开始时才会被发现.打印错误出现在主流上和不明显的逻辑路径上的可能性是一样的.

上述任何一条原因都是该进行白盒测试的论据,黑盒测试,不管它多么全面,都可能忽略前面提到的某些类型的错误.正如Beizer所说:\错误潜伏在角落里,聚集在边界上\白盒测试更可能发现它们.

前面所述的基本路径测试技术是控制结构测试技术之一.尽管基本路径测试简单高效,但是,其本身并不充分.下面讨论控制结构测试的其他变种,这些测试覆盖并提高了白盒测试的质量. 包括: 条件测试 数据流测试 循环测试. 1,条件测试

条件测试是检查程序模块中所包含逻辑条件的测试用例设计方法.一个简单条件是一个布尔变量或一个可能带有NOT(\操作符的关系表达式.关系表达式的形式如: E1E2

其中E1和E2是算术表达式,而是下列之一:\或\复杂条件由简单条件,布尔操作符和括弧组成.我们假定可用于复杂条件的布尔算子包括OR\和NOT\不含关系表达式的条件称为布尔表达式.所以条件的成分类型包括布尔操作符,布尔变量,布尔括弧(括住简单或复杂条件),关系操作符或算术表达式. 如果条件不正确,则至少有一个条件成分不正确,这样,条件的错误类型如下: 布尔操作符错误(遗漏布尔操作符,布尔操作符多余或布尔操作符不正确); 布尔变量错误; 布尔括弧错误; 关系操作符错误; 算术表达式错误.

条件测试方法注重于测试程序中的条件.条件测试策略主要有两个优点: 首先,测度条件测试的覆盖率是简单的;

其次,程序的条件测试覆盖率为产生另外的程序测试提供了指导.

搜索“diyifanwen.net”或“第一范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，第一范文网，提供最新高中教育白盒测试案例 全文阅读和word下载服务。