首页 白盒测试

白盒测试

举报
开通vip

白盒测试null白盒测试白盒测试白盒测试白盒测试白盒测试概念 测试覆盖标准 逻辑驱动测试 基本路径测试白盒测试概念白盒测试概念白盒测试也称结构测试或逻辑驱动测试,是一种测试用例设计方法,它从程序的控制结构导出测试用例。(测试用例由测试输入数据以及与之对应的输出结果组成。 测试用例设计的好坏直接决定了测试的效果和结果。所以说在软件测试活动中最关键的步骤就是设计有效的测试用例。) 白盒测试使用被测单元内部如何工作的信息,允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例,对程序的逻辑路径进行测试。基于一个应用代码的...

白盒测试
null白盒测试白盒测试白盒测试白盒测试白盒测试概念 测试覆盖 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 逻辑驱动测试 基本路径测试白盒测试概念白盒测试概念白盒测试也称结构测试或逻辑驱动测试,是一种测试用例设计 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 ,它从程序的控制结构导出测试用例。(测试用例由测试输入数据以及与之对应的输出结果组成。 测试用例设计的好坏直接决定了测试的效果和结果。所以说在软件测试活动中最关键的步骤就是设计有效的测试用例。) 白盒测试使用被测单元内部如何工作的信息,允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例,对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识,测试是基于覆盖全部代码、分支、路径、条件。 白盒测试的主要目的:白盒测试的主要目的:保证一个模块中的所有独立路径至少被执行一次; 对所有的逻辑值均需要测试真、假两个分支; 在上下边界及可操作范围内运行所有循环; 检查内部数据结构以确保其有效性。 测试覆盖标准测试覆盖标准白盒法特点:以程序的内部逻辑为基础设计测试用例,所以又称为逻辑覆盖法。应用白盒法时,手头必须有程序的规格说明以及程序清单。 白盒法考虑的是测试用例对程序内部逻辑的覆盖程度。最彻底的白盒法是覆盖程序中的每一条路径,但是由于程序中一般含有循环,所以路径的数目极大,要执行每一条路径是不可能的,只能希望覆盖的程度尽可能高些。 测试覆盖标准测试覆盖标准测试覆盖标准测试覆盖标准上页小程序的 流程 快递问题件怎么处理流程河南自建厂房流程下载关于规范招聘需求审批流程制作流程表下载邮件下载流程设计 图,其中包括了一个执行达20次的循环。那么它所包含的不同执行路径数高达520(=1013)条,若要对它进行穷举测试,覆盖所有的路径。假使测试程序对每一条路径进行测试需要1毫秒,同样假定一天工作24小时,一年工作365 天, 那么要想把如图所示的小程序的所有路径测试完,则需要3170年。测试覆盖标准测试覆盖标准为了衡量测试的覆盖程度,需要建立一些标准,目前常用的一些覆盖标准从低到高分别是: 语句覆盖:是一个比较弱的测试标准,它的含义是:选择足够的测试用例,使得程序中每个语句至少都能被执行一次。 它是最弱的逻辑覆盖,效果有限,必须与其它方法交互使用。 判定覆盖(也称为分支覆盖):执行足够的测试用例,使得程序中的每一个分支至少都通过一次。 判定覆盖只比语句覆盖稍强一些,但实际效果 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 明,只是判定覆盖,还不能保证一定能查出在判断的条件中存在的错误。因此,还需要更强的逻辑覆盖准则去检验判断内部条件。 条件覆盖:执行足够的测试用例,使程序中每个判断的每个条件的每个可能取值至少执行一次; 条件覆盖深入到判定中的每个条件,但可能不能满足判定覆盖的要求。 测试覆盖标准测试覆盖标准判定/条件覆盖:执行足够的测试用例,使得判定中每个条件取到各种可能的值,并使每个判定取到各种可能的结果。 判定/条件覆盖有缺陷。从表面上来看,它测试了所有条件的取值。但是事实并非如此。往往某些条件掩盖了另一些条件。会遗漏某些条件取值错误的情况。为彻底地检查所有条件的取值,需要将判定语句中给出的复合条件表达式进行分解,形成由多个基本判定嵌套的流程图。这样就可以有效地检查所有的条件是否正确了。 条件组合覆盖:执行足够的例子,使得每个判定中条件的各种可能组合都至少出现一次。 这是一种相当强的覆盖准则,可以有效地检查各种可能的条件取值的组合是否正确。它不但可覆盖所有条件的可能取值的组合,还可覆盖所有判断的可取分支,但可能有的路径会遗漏掉。测试还不完全。白盒测试的主要方法:白盒测试的主要方法:逻辑驱动测试 语句覆盖:语句覆盖就是设计若干个测试用例,运行被测试程序,使得每一条可执行语句至少执行一次; 判定覆盖(也称为分支覆盖):设计若干个测试用例,运行所测程序,使程序中每个判断的取真分支和取假分支至少执行一次; 条件覆盖:设计足够多的测试用例,运行所测程序,使程序中每个判断的每个条件的每个可能取值至少执行一次; 判定/条件覆盖:设计足够多的测试用例,运行所测程序,使程序中每个判断的每个条件的所有可能取值至少执行一次,并且每个可能的判断结果也至少执行一次,换句话说,即是要求各个判断的所有可能的条件取值组合至少执行一次; 条件组合覆盖:设计足够多的测试用例,运行所测程序,使程序中每个判断的所有可能的条件取值组合至少执行一次; 基本路径测试 设计足够多的测试用例,运行所测程序,要覆盖程序中所有可能的路径。这是最强的覆盖准则。但在路径数目很大时,真正做到完全覆盖是很困难的,必须把覆盖路径数目压缩到一定限度。 语句覆盖 语句覆盖 语句覆盖”是一个比较弱的测试标准,它的含义是:选择足够的测试用例,使得程序中每个语句至少都能被执行一次。 如,例1: PROCEDURE  M(VAR A,B,X:REAL);   BEGIN IF (A>1) AND (B=0)  THEN X:=X/A; IF (A=2) OR (X>1)   THEN X:=X+1; END.语句覆盖语句覆盖 为使程序中每个语句至少执行一次,只需设计一个能通过路径ace的例子就可以了,例如选择输入数据为: A=2,B=0,X=3 就可达到“语句覆盖”标准。 语句覆盖 语句覆盖语句覆盖 从上例可看出,语句覆盖实际上是很弱的,如果第一个条件语句中的AND错误地编写成OR,上面的测试用例是不能发现这个错误的;又如第三个条件语句中X>1误写成X>0,这个测试用例也不能暴露它,此外,沿着路径abd执行时,X的值应该保持不变,如果这一方面有错误,上述测试数据也不能发现它们。 语句覆盖语句覆盖例2: void DoWork(int x,int y,int z) { int k=0,j=0; if((x>3)&&(z<10)) { k=x*y-1; //语句块1 j=sqrt(k); } if((x= =4)||(y>5)) { j=x*y+10; //语句块2 } j=j%3; //语句块3 }语句覆盖语句覆盖 为了测试语句覆盖率只要设计一个测试用例就可以把三个执行语句块中的语句覆盖了。测试用例输入为: x=4、y=5、z=5 程序执行的路径是:abd语句覆盖语句覆盖 该测试用例虽然覆盖了可执行语句,但并不能检查判断逻辑是否有问题,例如在第一个判断中把&&错误的写成了||,则上面的测试用例仍可以覆盖所有的执行语句。 一般认为“语句覆盖”是很不充分的一种标准,是最弱的逻辑覆盖准则。分支覆盖 分支覆盖 比“语句覆盖”稍强的覆盖标准是“分支覆盖”(或称分支覆盖)标准。含义是:执行足够的测试用例,使得程序中的每一个分支至少都通过一次。 分支覆盖分支覆盖 对例1的程序,如果设计两个例子,使它们能通过路径ace和abd,或者通过路径acd和abe,就可达到“判定覆盖”标准,为此,可以选择输入数据为: ① A=3,B=0,X=1 (沿路径acd执行);   ② A=2,B=1,X=3(沿路径abe执行)      分支覆盖分支覆盖判定覆盖 判定覆盖 A=3,B=0,X=1 (沿路径acd执行)   A=2,B=1,X=3 (沿路径abe执行)分支覆盖分支覆盖 对于例2的程序,如果设计两个测试用例则可以满足条件覆盖的要求。 测试用例的输入为: x=4、y=5、z=5 x=2、y=5、z=5 上面的两个测试用例虽然能够满足条件覆盖的要求,但是也不能对判断条件进行检查,例如把第二个条件y>5错误的写成y<5,、上面的测试用例同样满足了分支覆盖。 分支覆盖分支覆盖 程序中含有判定的语句包括IF-THEN-ELSE、DO-WHILE、REPEAT-UNTIL等,除了双值的判定语句外,还有多值的判定语句,如PASCAL中的CASE语句、FORTRAN中带有三个分支的IF语句等。所以“分支覆盖”更一般的含义是:使得每一个分支获得每一种可能的结果。 “分支覆盖”比“语句覆盖”严格,因为如果每个分支都执行过了,则每个语句也就执行过了。但是,“分支覆盖”还是很不够的,例如例1两个测试用例未能检查沿着路径abd执行时,X的值是否保持不变。 条件覆盖 条件覆盖 一个判定中往往包含了若干个条件,如例1的程序中,判定 (A>1) AND (B=0)包含了两个条件: A>1以及 B=0,所以可引进一个更强的覆盖标准——“条件覆盖”。“条件覆盖”的含义是:执行足够的测试用例,使得判定中的每个条件获得各种可能的结果。 条件覆盖条件覆盖例1的程序有四个条件:          A>1、 B=0、A=2、X>1 为了达到“条件覆盖”标准,需要执行足够的测试用例使得在a点有:          A>1、A≤1、B=0、B≠0 等各种结果出现,以及在b点有:        A=2、A≠2、X>1、X≤1 等各种结果出现。 现在只需设计以下两个测试用例就可满足这一标准: ① A=2,B=0,X=4  (沿路径ace执行); ② A=1,B=1,X=1   (沿路径abd执行)。    条件覆盖条件覆盖条件覆盖条件覆盖A=2,B=0,X=4  (沿路径ace执行) A=1,B=1,X=1  (沿路径abd执行)条件覆盖条件覆盖对例2中的所有条件取值加以标记。 对于第一个判断: 条件x>3 取真值为T1,取假值为-T1 条件z<10 取真值为T2,取假值为-T2 对于第二个判断: 条件x=4 取真值为T3,取假值为-T3 条件y>5 取真值为T4,取假值为-T4 条件覆盖条件覆盖则可以设计测试用例如下 上面的测试用例不但覆盖了所有分支的真假两个分支,而且覆盖了判断中的所有条件的可能值。 条件覆盖条件覆盖“条件覆盖”通常比“分支覆盖”强,因为它使一个判定中的每一个条件都取到了两个不同的结果,而判定覆盖则不保证这一点。 “条件覆盖”并不包含“分支覆盖”,如对语句IF(A AND B)THEN S 设计测试用例使其满足"条件覆盖",即使A为真并使B为假,以及使A为假而且B为真,但是它们都未能使语句S得以执行。 条件覆盖条件覆盖 如对例2设计了下面的测试用例,则虽然满足了条件覆盖,但只覆盖了第一个条件的取假分支和第二个条件的取真分支,不满足分支覆盖的要求。 分支/条件覆盖分支/条件覆盖针对上面的问题引出了另一种覆盖标准——“分支 /条件覆盖”,它的含义是:执行足够的测试用例,使得分支中每个条件取到各种可能的值,并使每个分支取到各种可能的结果。 对例1的程序,前面的两个例子 ① A=2,B=0,X=4 (沿ace路)                       ② A=1,B=1,X=1 (沿abd路径)   是满足这一标准的。分支/条件覆盖分支/条件覆盖 对例2,根据定义只需设计以下两个测试用例便可以覆盖8个条件值以及4个判断分支。 分支/条件覆盖分支/条件覆盖分支/条件覆盖从表面来看,它测试了所有条件的取值,但是实际上某些条件掩盖了另一些条件。 例如对于条件表达式(x>3)&&(z<10)来说,必须两个条件都满足才能确定表达式为真。如果(x>3)为假则一般的编译器不在判断是否z<10了。对于第二个表达式(x==4)||(y>5)来说,若x==4测试结果为真,就认为表达式的结果为真,这时不再检查(y>5)条件了。因此,采用分支/条件覆盖,逻辑表达式中的错误不一定能够查出来了。 条件组合覆盖 条件组合覆盖 针对上述问题又提出了另一种标准——“条件组合覆盖”。它的含义是:执行足够的例子,使得每个判定中条件的各种可能组合都至少出现一次。显然,满足“条件组合覆盖”的测试用例是一定满足“分支覆盖”、“条件覆盖”和“分支/条件覆盖”的。 条件组合覆盖条件组合覆盖 再看例1的程序,我们需要选择适当的例子,使得下面 8种条件组合都能够出现: 1)A>1, B=0    2) A>1, B≠0 3) A≤1, B=0 4) A≤1, B≠0 5) A=2, X>1 6) A=2,X≤1 7) A≠2, X>1 8) A≠2, X≤1 5)、 6)、 7)、8)四种情况是第二个 IF语句的条件组合,而X的值在该语句之前是要经过计算的,所以还必须根据程序的逻辑推算出在程序的入口点X的输入值应是什么。 条件组合覆盖条件组合覆盖 下面设计的四个例子可以使上述 8种条件组合至少出现一次: ① A=2,B=0,X=4 使 1)、5)两种情况出现; ② A=2,B=1,X=1 使 2)、6)两种情况出现; ③ A=1,B=0,X=2 使 3)、7)两种情况出现; ④ A=1,B=1,X=1 使 4)、8)两种情况出现。条件组合覆盖条件组合覆盖 上面四个例子虽然满足条件组合覆盖,但并不能覆盖程序中的每一条路径,例如路径acd就没有执行,因此,条件组合覆盖标准仍然是不彻底。 条件组合覆盖条件组合覆盖 现对例2中的各个判断的条件取值组合加以标记如下: 1、x>3,z<10 记做T1 T2,第一个判断的取真分支 2、x>3,z>=10 记做T1 -T2,第一个判断的取假分支 3、x<=3,z<10 记做-T1 T2,第一个判断的取假分支 4、x<=3,z>=10 记做-T1 -T2,第一个判断的取假分支 5、x=4,y>5 记做T3 T4,第二个判断的取真分支 6、x=4,y<=5 记做T3 -T4,第二个判断的取真分支 7、x!=4,y>5 记做-T3 T4,第二个判断的取真分支 8、x!=4,y<=5 记做-T3 -T4,第二个判断的取假分支条件组合覆盖条件组合覆盖根据定义取4个测试用例,就可以覆盖上面8种条件取值的组合。 测试用例如下表: 上面的测试用例覆盖了所有条件的可能取值的组合,覆盖了所有判断的可取分支,但是却丢失了一条路径abe。白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试例3:工资管理程序BONUS的输入数据是职员表(Employee Table)和部门表(Department Table)(如图)。职员表由姓名(Name)、职务(Job Code)、部门(Dept.)和工资(Salary)四项组成,部门表由部门(Dept)和销售量(Sales)两项组成。白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试 程序的功能是;“为销售量最大的部门中每一个职员增加200元工资,但是,如果某个职员的原有工资已达15000元,或者他的职务是经理,则只给他增加100元,如果程序能正常地完成,则输出出错码0;如果输入表格中没有任何条目,则输出出错码 1;如果没有职员在部门表中销售量最大的部门中工作,则输出出错码2”。白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试 下面是BONUS的源程序,参数表中EMPTAB、DEPTTAB分别是职员表和部门表,ESIZE、DSIZE分别是两个表的长度,ERRCODE是出错码。 PROCEDURE BONUS(EMPTAB,DEPTTAB:TABLE; ESIZE,DSIZE,ERRCODE:                           INTEGER); …… null1   BEGIN MAXSALERS:=0; ERRCODE:=0; 2         IF  (ESIZE≤0)OR (DSIZE≤0) 3         THEN ERRCODE:=1 4         ELSE 5             BEGIN FOR I:=1 TO DSIZE DO 6                  IF SALES(I)>MAXSALES 7                   THEN MAXSALES:=SALES(I); 8          FOR J:=1 TO DSIZE DO 9               IF SALES(J):=MAXSALES 10            THEN 11             BEGIN FOUND:=FALSE; 12                       FOR K:=1 TO ESIZE DO 13                               IF (EMPTAB.DEPT(K)=DEPTTAB.DEFT(J)) 14                                             THEN 15                                             BEGIN FOUND:=TRUE; 16                                                     IF (SALARY(K)≥15000.00) 17                                                            OR (JOB(K)=“M”) 18                                                     THEN SALARY(K):=SALARY(K)+100.00 19                                                     ELSE SALARY(K):=SALARY(K)+200.00 20                                             END; 21                                             IF(NOT FOUND)THEN ERRCODE:=2 22                             END 23            END 24   END. 白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试 现用白盒法设计测试用例。 首先列出程序中的判定,考虑所有的条件句和循环句。本例中只要输入表格不空,循环句总会经历进入循环体和跳过循环体这两种情况(因为循环终值都大于等于循环初值),所以就不必专门考虑了,需要分析的只是六个条件语句中的判定。 2         IF (ESIZE≤0) OR (DSIZE≤0) 6         IF(SALES(I)>MAXSALES) 9         IF(SALES(J)=MAXSALES) 13        IF(EMPTAB.DEPT(K)=DEPTTAB.DEFT(J)) 16        IF(SALARY(K)≥15000.00) OR (JOB(K)=“M”) 21        IF(NOT FOUND)白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试1.采用“判定覆盖”标准,使得上述 6个判定都取到两种结果,这就需要以下12种情况出现。 白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试 设计下面的两个测试用例可以满足“判定覆盖” (图中“职务”一栏,“E”表示是一般职员,“M”表示是经理)。ESIZE=DSIZE=3   EMPTAB                     DEPTTABERRCODE=2 ESIZE,DSIZE,DEPTTAB 不变 EMPTABESIZE=DSIZE=3   EMPTAB                     DEPTTABERRCODE=2 ESIZE,DSIZE,DEPTTAB 不变 EMPTAB白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试 虽然这两个例子满足“判定覆盖”标准,但是它们不能发现程序中许多其他可能的错误,例如没有检查ERRCODE为0、职员是经理、部门表为“空”等情况。 白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试2.采用“条件覆盖”标准,则必须使判定中的每一个条件取到两种可能的值,这就需要以下16种情况出现。白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试 设计下面的两个测试用例可以满足“条件覆盖” 。ESIZE=DSIZE=3   EMPTAB                     DEPTTABERRCODE=2 ESIZE,DSIZE,DEPTTAB 不变 EMPTABESIZE=DSIZE=3   EMPTAB                     DEPTTABERRCODE=2 ESIZE,DSIZE,DEPTTAB 不变 EMPTAB白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试 尽管上面的测试用例满足“条件覆盖”标准,但是它们可能比满足“判定覆盖”标准的测试用例差,因为它们不能执行每一个语句(如语句19),而且它们起的作用也不比满足“判定覆盖”的测试用例多许多,如未能使ERRCODE=0,如果语句2误写成(ESIZE=O) AND (DSIZE=0),这个错误也不能被发现。 白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试3.采用“判定/条件覆盖”标准,就可克服“条件覆盖”中例子的弱点,我们需要提供足够的测试用例使得所有判定和条件都取到两个不同的值,这里只需使“条件覆盖”测试用例中的职员JONES为经理,而使LORIN不是经理,则判定 16就可取到两种结果,语句19因而得以执行。 白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试 问题:如果所用的编译系统将含有“OR”的表达式处理成:遇到第一项为“真”就不再检查后面的项,则这样的两个测试用例并不能检查到 JOB(K)=“M”这一部分。 白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试4.最后考虑“条件组合覆盖”标准,它需要足够的例子,使得每个判定中条件的各种组合情况都出现一次。本例中判定6、9、13和 21各有两种组合,判定2和16各有 4种组合。可以先选一个测试用例使其包含尽可能多的组合情况。再选另一测试用例使其包含尽可能多的余下的组合情况...,直至得到一组测试用例能包含所有的组合情况。 下面是满足“条件组合覆盖”标准的一组测试用例,它比前面几组测试用例都全面。 白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试 可以看出:即使是满足“条件组合覆盖”标准的例子仍不能发现BONUS中许多其他的错误。例如: 没有检查 ERRCODE=0的情况,所以如果语句1中的 ERRORCODE:=0; 被遗漏了就查不出; 如语句16中 15000.00误写成 15000.01也是发现不了的, 如SALARY(K)>=15000误写成SALARY(K)>15000也是发现不了的; 如果 BONUS程序没有对部门表或职员表的最后一行进行处理,这个错误也不一定能发现。 白盒法测试举例 - 工资管理程序测试白盒法测试举例 - 工资管理程序测试 通过前面例子的讨论,可以得到两点结论: “条件组合覆盖”标准比其他标准优越。 即使达到任何一种覆盖标准,其测试效果仍然是不彻底的,我们还需要用其他的测试方法作补充。 下面来讨论一下用黑盒法补充测试用例:综合策略 - 黑盒法补充测试用例综合策略 - 黑盒法补充测试用例白盒法和黑盒法各有长处和短处,每种方法都可提供一组有用的测试用例,这组测试用例容易发现某种类型的错误,但不易发现其他类型的错误,然而没有一种方法能提供一组“完整的”测试用例。因此,实际软件测试 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 设计是不同方法的综合应用。 一个参考的黑盒法补充策略是: 1) 在任何情况下都需使用边界值分析(这个方法应包括对输入和输出的边界值进行分析)。 2) 必要的话,再用等价分类法补充一些测试用例。 3) 再用错误推测法附加测试用例。 4) 检查上述例子的逻辑覆盖程度,如果未能满足某些覆盖标准,则再增加足够的测试用例。 5) 如果功能说明中含有输入条件的组合情况,则一开始就可先用因果图(判定表)法。 以工资管理为例: (用黑盒法补充测试用例) 该例不必检查输入条件的组合情况,所以不需要用因果图(判定表)法,这里我们先用边界值分析法,该程序中输入的边界情况有:黑盒法补充测试用例 - 工资管理程序测试黑盒法补充测试用例 - 工资管理程序测试1) EMPTAB具有 1个记录。 2) EMPTAB具有最大个数的记录(如 65535个记录)。 3) EMPTAB具有零个记录。 4) DEPTAB具有 1个记录。 5) DEPTTAB具有 65535个记录。 6) DEPTTAB具有零个记录, 7) 销售量最大的部门有1个职员。 8) 销售量最大的部门有 65535个职员。 9) 销售量最大的部门没有职员。 10) 所有部门的销售量相等。 11) DEPTTAB中,第一个部门的销售量最大。 12) DEPTTAB中,最后一个部门的销售量最大。 13) EMPTAB中,第一个职员在销售量最大的部门工作。 14) EMPTAB中,最后一个职员在销售量最大的部门工作。 15) 销售量最大的部门中有一个职员是经理。 16) 销售量最大的部门中有一个职员不是经理。 17) 销售量最大的部门中有一个职员(不是经理)的工资是 14 999.99。 18) 销售量最大的部门中有一个职员(不是经理)的工资是 15 000.00。 19) 销售量最大的部门中有一个职员(不是经理)的工资是 15 000.01。黑盒法补充测试用例 - 工资管理程序测试黑盒法补充测试用例 - 工资管理程序测试输出的边缘情况是: 20) ERRCODE=0。 21) ERRCODE=1。 22) ERRCODE=2。 23) 增加后的工资为 99999.99(即数据项SALARY的最大允许值)。 再用错误推测法还可增加一个测试用例。 24) DEPTTAB中,在销售量最大但没有职员的部门之后,有一个销售量最大但有职员的部门(检查程序在产生ERRCODE=2后是否会错误地终止对输入文件的处理)。 上述24种情况中,看来第 2)、5)、8)种情况是不会发生的,所以可以不考虑,再将用白盒法设计的测试用例与余下的21种情况作比较,可以看出许多情况巳包括在这4个测试用例中了,尚未包括的情况是 1)、4)、7)、10)、14)、17)、18)、19)、20)、23)和24)等11种。 因此再增加的测试用例如下:黑盒法补充测试用例 - 工资管理程序测试黑盒法补充测试用例 - 工资管理程序测试路径测试路径测试路径测试就是设计足够多的测试用例,覆盖被测试对象中的所有可能路径。 对于例1,下面的测试用例则可对程序进行全部的路径覆盖。null对于例2,下面的测试用例则可对程序进行全部的路径覆盖。基本路径测试基本路径测试 例1、例2都是很简单的程序函数,只有四条路径。但在实践中,一个不太复杂的程序,其路径都是一个庞大的数字,要在测试中覆盖所有的路径是不现实的。为了解决这一难题,只得把覆盖的路径数压缩到一定限度内,例如,程序中的循环体只执行一次。 下面介绍的基本路径测试就是这样一种测试方法,它在程序控制图的基础上,通过分析控制构造的环行复杂性,导出基本可执行路径集合,从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。 基本路径测试基本路径测试前提条件 测试进入的前提条件是在测试人员已经对被测试对象有了一定的了解,基本上明确了被测试软件的逻辑结构。 测试过程 过程是通过针对程序逻辑结构设计和加载测试用例,驱动程序执行,以对程序路径进行测试。测试结果是分析实际的测试结果与预期的结果是否一致。 基本路径测试基本路径测试在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。包括以下4个步骤和一个工具方法: 程序的控制流图:描述程序控制流的一种图示方法。 程序圈复杂度:McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数,这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。 导出测试用例:根据圈复杂度和程序结构设计用例数据输入和预期结果。 准备测试用例:确保基本路径集中的每一条路径的执行。 工具方法: 图形矩阵:是在基本路径测试中起辅助作用的软件工具,利用它可以实现自动地确定一个基本路径集。控制流图的符号控制流图的符号在介绍基本路径方法之前,必须先介绍一种简单的控制流表示方法,即流图。流图是对待测试程序过程处理的一种表示。流图使用下面的符号描述逻辑控制流,每一种结构化构成元素有一个相应的流图符号。控制流图控制流图流图只有二种图形符号 图中的每一个圆称为流图的结点,代表一条或多条语句。 流图中的箭头称为边或连接,代表控制流。 任何过程设计都要被翻译成控制流图。 控制流图控制流图在将程序流程图简化成控制流图时,应注意: 在选择或多分支结构中,分支的汇聚处应有一个汇聚结点。 边和结点圈定的区域叫做区域,当对区域计数时,图形外的区域也应记为一个区域。 如下页图所示控制流图控制流图控制流图控制流图如果判断中的条件表达式是由一个或多个逻辑运算符 (OR, AND, NAND, NOR) 连接的复合条件表达式,则需要改为一系列只有单条件的嵌套的判断。 例如: 1 if a or b 2 x 3 else 4 y 对应的逻辑为:独立路径独立路径独立路径:至少沿一条新的边移动的路径1762,38910114,5路径1:1-11 路径2:1-2-3-4-5-10-1-11 路径3:1-2-3-6-8-9-10-1-11 路径4:1-2-3-6-7-9-10-1-11对以上路径的遍历,就是至少一次地执行了程序中的所有语句。基本路径测试基本路径测试第一步:画出控制流图 流程图用来描述程序控制结构。可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)。在流图中,每一个圆,称为流图的结点,代表一个或多个语句。一个处理方框序列和一个菱形决测框可被映射为一个结点,流图中的箭头,称为边或连接,代表控制流,类似于流程图中的箭头。一条边必须终止于一个结点,即使该结点并不代表任何语句(例如:if-else-then结构)。由边和结点限定的范围称为区域。计算区域时应包括图外部的范围。基本路径测试基本路径测试例4:有下面的C函数,用基本路径测试法进行测试 void Sort(int iRecordNum,int iType) { int x=0; int y=0; while (iRecordNum-- > 0) { if(0= =iType) { x=y+2; break;} else if (1= =iType) x=y+10; else x=y+20; } }基本路径测试基本路径测试画出其程序流程图和对应的控制流图如下基本路径测试 - 计算圈复杂度基本路径测试 - 计算圈复杂度第二步:计算圈复杂度 圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量,将该度量用于计算程序的基本的独立路径数目,为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。 有以下三种方法计算圈复杂度: 流图中区域的数量对应于环型的复杂性; 给定流图G的圈复杂度V(G),定义为V(G)=E-N+2,E是流图中边的数量,N是流图中结点的数量; 给定流图G的圈复杂度V(G),定义为V(G)=P+1,P是流图G中判定结点的数量。 基本路径测试 - 计算圈复杂度基本路径测试 - 计算圈复杂度对应上面图中的圈复杂度,计算如下: 流图中有四个区域; V(G)=10条边-8结点+2=4; V(G)=3个判定结点+1=4。 基本路径测试 - 导出测试用例基本路径测试 - 导出测试用例第三步:导出测试用例 根据上面的计算方法,可得出四个独立的路径。(一条独立路径是指,和其他的独立路径相比,至少引入一个新处理语句或一个新判断的程序通路。V(G)值正好等于该程序的独立路径的条数。) 路径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=20void Sort(int iRecordNum,int iType) { int x=0; int y=0; while (iRecordNum-- > 0) { if(0= =iType) {x=y+2; break;} else if(1= =iType) x=y+10; else x=y+20; } }基本路径测试再举例基本路径测试再举例 例5:下例程序流程图描述了最多输入50个值(以–1作为输入结束标志),计算其中有效的学生分数的个数、总分数和平均值。nullnull步骤1:导出过程的流图。基本路径测试再举例基本路径测试再举例步骤2:确定环形复杂性度量V(G): 1)V(G)= 6 (个区域) 2)V(G)=E–N+2=16–12+2=6 其中E为流图中的边数,N为结点数; 3)V(G)=P+1=5+1=6 其中P为谓词结点的个数。在流图中,结点2、3、5、6、9是谓词结点。基本路径测试再举例基本路径测试再举例步骤3:确定基本路径集合(即独立路径集合)。于是可确定6条独立的路径: 路径1:1-2-9-10-12 路径2:1-2-9-11-12 路径3:1-2-3-9-10-12 路径4:1-2-3-4-5-8-2… 路径5:1-2-3-4-5-6-8-2… 路径6:1-2-3-4-5-6-7-8-2…基本路径测试再举例基本路径测试再举例步骤4:为每一条独立路径各设计一组测试用例,以便强迫程序沿着该路径至少执行一次。 1)路径1(1-2-9-10-12)的测试用例: score[k]=有效分数值,当k < i ; score[i]=–1, 2≤i≤50; 期望结果:根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average。基本路径测试再举例基本路径测试再举例2)路径2(1-2-9-11-12)的测试用例: score[ 1 ]= – 1 ; 期望的结果:average = – 1 ,其他量保持初值。 3)路径3(1-2-3-9-10-12)的测试用例: 输入多于50个有效分数,即试图处理51个分数,要求前51个为有效分数; 期望结果:n1=50、且算出正确的总分和平均分。基本路径测试再举例基本路径测试再举例4)路径4(1-2-3-4-5-8-2…)的测试用例: score[i]=有效分数,当i<50; score[k]<0, k< i ; 期望结果:根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average。 5)路径5的测试用例: score[i]=有效分数, 当i<50; score[k]>100, k< i ; 期望结果:根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average。基本路径测试再举例基本路径测试再举例6)路径6(1-2-3-4-5-6-7-8-2…)的测试用例: score[i]=有效分数, 当i<50; 期望结果:根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average。基本路径测试基本路径测试必须注意,一些独立的路径,往往不是完全孤立的,有时它是程序正常的控制流的一部分,这时,这些路径的测试可以是另一条路径测试的一部分。工具方法:图形矩阵工具方法:图形矩阵导出控制流图和决定基本测试路径的过程均需要机械化,为了开发辅助基本路径测试的软件工具,称为图形矩阵(graph matrix)的数据结构很有用。 利用图形矩阵可以实现自动地确定一个基本路径集。一个图形矩阵是一个方阵,其行/列数控制流图中的结点数,每行和每列依次对应到一个被标识的结点,矩阵元素对应到结点间的连接(即边)。在图中,控制流图的每一个结点都用数字加以标识,每一条边都用字母加以标识。如果在控制流图中第i个结点到第j个结点有一个名为x的边相连接,则在对应的图形矩阵中第i行/第j列有一个非空的元素x。 工具方法:图形矩阵工具方法:图形矩阵 对每个矩阵项加入连接权值(link weight),图矩阵就可以用于在测试中评估程序的控制结构,连接权值为控制流提供了另外的信息。最简单情况下,连接权值是 1(存在连接)或0(不存在连接),但是,连接权值可以赋予更有趣的属性: 执行连接(边)的概率。 穿越连接的处理时间。 穿越连接时所需的内存。 穿越连接时所需的资源。工具方法:图形矩阵工具方法:图形矩阵根据上面的方法对例4画出图形矩阵如下:工具方法:图形矩阵工具方法:图形矩阵 连接权为“1”表示存在一个连接,在图中如果一行有两个或更多的元素“1”,则这行所代表的结点一定是一个判定结点,通过连接矩阵中有两个以上(包括两个)元素为“1”的个数,就可以得到确定该图圈复杂度的另一种算法。 控制结构测试的变种控制结构测试的变种 前面所述的基本路径测试技术是控制结构测试技术之一。尽管基本路径测试简单高效,但是,其本身并不充分。下面讨论控制结构测试的其他变种,这些测试覆盖并提高了白盒测试的质量。包括: 条件测试 数据流测试 循环测试。条件测试条件测试 条件测试方法注重于测试程序中的条件。是检查程序模块中所包含逻辑条件的测试用例设计方法。 条件 程序中的条件分为简单条件和复合条件。 简单条件是一个布尔变量或一个可能带有NOT(“!”)操作符的关系表达式。关系表达式的形式如: E1<关系操作符>E2 其中E1和E2是算术表达式,而<关系操作符>是下列之一:“<”、“≤”、“=”、“≠”(“!=”)、“>”、或“≥”。 复合条件由简单条件通过逻辑运算符(AND、OR、NOT)和括号连接而成,不含关系表达式的条件称为布尔表达式。 所以条件的成分类型包括布尔操作符、布尔变量、布尔括弧(括住简单或复杂条件)、关系操作符或算术表达式。条件测试条件测试条件的错误类型 如果条件不正确,则至少有一个条件成分不正确,这样,条件的错误类型如下: 布尔操作符错误(遗漏布尔操作符,布尔操作符多余或布尔操作符不正确); 布尔变量错误; 布尔括弧错误; 关系操作符错误; 算术表达式错误。 条件测试条件测试条件测试的目的 条件测试是测试程序条件错误和程序的其他错误。如果程序的测试集能够有效地检测程序中的条件错误,则该测试集可能也会有效地检测程序中的其他错误。此外,如果测试策略对检测条件错误有效,则它也可能有效地检测程序错误。条件测试条件测试条件测试策略 穷举测试 (条件组合) 有n个变量的布尔表达式需要2n个可能的测试(n>0)。这种策略可以发现布尔操作符、变量和括弧的错误,但是只有在n很小时实用。 分支测试 分支测试可能是最简单的条件测试策略,它是真假分支必须至少执行一次的路径策略,对于复合条件C,C的真分支和假分支以及C中的每个简单条件都需要至少执行一次。条件测试 - 分支测试条件测试 - 分支测试域测试(Domain testing) 域测试是对于大于、小于和等于值的测试路径策略。 域测试要求从有理表达式中导出三个或四个测试,有理表达式的形式如: E1<关系操作符>E2 需要三个测试分别用于计算E1的值是大于、等于或小于E2的值。如果<关系操作符>错误,而E1和E2正确,则这三个测试能够发现关系算子的错误。 为了发现E1和E2的错误,计算E1小于或大于E2的测试应使两个值间的差别尽可能小。 条件测试条件测试BRO(branch and relational)测试 如果在一个判定的复合条件表达式中每个布尔变量和关系运算符最多只出现一次,而且没有公共变量,应用一种称之为BRO(分支与关系运算符)的测试法可以发现多个布尔运算符或关系运算符错,以及其他错误。 BRO策略引入条件约束的概念。设有n个简单条件的复合条件C,其条件约束为D= (D1,D2,…,Dn) ,其中Di(0<i≤n)是条件C中第i个简单条件的输出约束。如果在C的执行过程中,其每个简单条件的输出都满足D中对应的约束,则称条件C的条件约束D由C的执行所覆盖。 对于布尔变量或布尔表达式B,B的输出约束必须是真(t)或假(f);对于关系表达式,其输出约束为符号>、=、<。 条件测试条件测试 作为简单的例子,考虑条件 C1∶B1&B2 其中B1和B2是布尔变量。C1的输出约束为(D1,D2),其中D1和D2是“T”或“F”,值(T,F)是C1可能的一个约束,覆盖此约束的测试(一次运行)将令B1为t,B2为f。BRO测试策略要求约束集{(t,t),(f,t),(t,f),(f,f)}由C1的执行所覆盖。如果布尔运算符有错,这四组测试用例的运行结果必有一组导致C1失败。 条件测试条件测试 作为第二个例子,考虑 C2∶B1&(E3=E4) 其中B1是布尔表达式,而E3和E4是算术表达式。C2的条件约束形式如(D1,D2),其中D1是“T”或“F”,D2是<,=或>。除了C2的第二个简单条件是关系表达式以外,C2和C1相同,所以可以修改C1的约束集{(T,T),(F,T),(T,F),(F,F)},得到C2的约束集,注意(E3=E4)的“T”意味着“=”,而(E3=E4)的“F”意味着“>”或“<”。分别用(T,=)和(F,=)替换(T,T)和(F,T),并用(T,<)和(T,>)替换(T,F),用(F,<)和(F,>)替换(F,F),就得到C2的约束集: {(T,=),(F,=),(T,<),(T,>) ,(F,<),(F,>) }。 上述条件约束集的覆盖率将保证检测C2的布尔和关系算子的错误。条件测试条件测试 作为第三个例子,考虑 C3∶(E1>E2)&(E3=E4) 其中E1、E2、E3和E4是算术表达式。C3的条件约束形式如(D1,D2),其中D1和D2是<、=或>。除了C3的第一个简单条件是关系表达式以外,C3和C2相同,所以可以修改C2的约束集得到C3的约束集,结果为 {(>,=),(=,=),(<,=),(>,<),(>,>), (>,<),(=,<),(<,<), (>,>),(=,>),(<,>) } 去掉重复,结果为: {(>,=),(=,=),(<,=),(>,<),(>,>),(=,<),(<,<), (=,>),(<,>) } 上述条件约束集能够保证检测C3的关系操作符的错误。 数据流测试数据流测试 数据流测试方法按照程序中的变量定义和使用的位置来选择程序的测试路径。 为了说明数据流测试方法,假设程序的每条语句都赋予了独特的语句号,而且每个函数都不改变其参数和全局变量。对于语句号为S的语句, DEF(S)={X|语句S包含X的定义} USE(S)={X|语句S包含X的使用} 如果语句S是if或循环语句,它的DEF集为空,而USE集取决于S的条件。如果存在从S到S′的路径,并且该路径不含X的其他定义,则称变量X在语句S处的定义在语句S′仍有效。 数据流测试数据流测试 变量X的定义—使用链(或称DU链)形式如[X,S,S′],其中S和S′是语句号,X在DEF(S)和USE(S′)中,而且语句S定义的X在语句S′有效。 一种简单的数据流测试策略是要求覆盖每个DU链至少一次。我们将这种策略称为DU测试策略。已经证明DU测试并不能保证覆盖程序的所有分支,但是,DU测试不覆盖某个分支仅仅在于如下之类的情况:if-then-else中的then没有定义变量,而且不存在else部分。这种情况下,if语句的else分支并不需要由DU测试覆盖。 数据流测试策略可用于为包含嵌套if和循环语句的程序选择测试路径,为此,考虑使用DU测试为如下的伪程序片段选择测试路径:数据流测试数据流测试proc x B1; do while C1 if C2 then if C4 then B4; else B5; endif; else if C3 then B2; else B3; endif; endif; enddo; B6; end proc;数据流测试数据流测试 为了用DU测试选择控制流图的测试路径,需要知道程序中条件或块中的变量定义和使用。假设变量X定义在块B1,B2,B3,B4和B5的最后一条语句之中,并在块B2,B3,B4,B5和B6的第一条语句中使用。DU测试策略要求执行从每个Bi(0<i≤5)到Bj(0<j≤6)的最短路径(这样的测试也覆盖了条件C1,C2,C3和C4中的变量使用)。尽管有25条X的DU链,只需5条路径覆盖这些DU链。原因在于可用5条从Bi(0<i≤5)到B6的路径覆盖X的链,而这5条链包含循环的迭代就可以覆盖其他的DU链。 数据流测试数据流测试 注意如果要用分支测试策略为上述的程序选择测试路径,并不需要另外的信息。为了选择BRO测试的路径,只需知道每个条件和块的结构。(选择程序的路径之后,需要决定该路径是否实用于该程序,即是否存在执行该路径的至少一个输入)。 由于变量的定义和使用,程序中的语句都彼此相关,所以数据流测试方法能够有效地发现
本文档为【白盒测试】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑, 图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
下载需要: 免费 已有0 人下载
最新资料
资料动态
专题动态
is_853137
暂无简介~
格式:ppt
大小:518KB
软件:PowerPoint
页数:0
分类:互联网
上传时间:2009-09-29
浏览量:82