吴鸿韬
cshongtaowu@gmail
白盒测试
白盒测试概念
白盒测试的发展
测试覆盖标准
逻辑驱动测试
基本路径测试
白盒测试概念
白盒测试也称结构测试或逻辑驱动测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。
白盒测试使用被测单元内部如何工作的信息，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。
白盒测试的主要目的:
保证一个模块中的所有独立路径至少被执行一次；
对所有的逻辑值均需要测试真、假两个分支；
对程序进行边界检查(常见的如数据结构越界检查)；
检查内部数据结构以确保其有效性。
白盒测试的发展
白盒测试的发展
“是否评估测试效果”指是否有覆盖率或其它评估测试效果的指标，
“是否自动测试”指是否形式化描述测试操作并将它用于再次测试，
“是否持续测试”指是否以按持续集成的模式开展测试，
“是否调测一体”指是否将测试设计高效的融入产品编码与调试的日常实践之中。
白盒测试的发展
第1代白盒测试
在测试发展初期，测试工具很不成熟，人们通常以单步调试代替测试，或采用assert断言、print语句等简单方式的组织测试体系，即我们所谓的第1代白盒测试，这一时期的测试是半手工的，没实现自动化，测试
效果也严重依赖测试者（或者调试者）的个人能力，缺少统一规范的评判标准。
白盒测试的发展
第1代白盒测试方法存在严重缺陷，主要有：测试过程难以重用，成功经验无法拷贝，测试结果也难以评估并用于改进，这些对于团队运作是非常致命的
白盒测试的发展
第2代白盒测试，将测试操作改用一种形式化语言（通常称为测试脚本）来表述，脚本可以组合成用例，用例可组合成测试集，用例与测试集再统一到测试工程中管理，把测试脚本保存到文件，重用问题解决了。另外，代码覆盖率功能使测试结果可以评估，能直观的看到哪些代码或分支未被覆盖，然后有针对性的增加测试设计。
白盒测试的发展
目前市面上有大量商用工具，如RTRT、CodeTest、VisualTester、C++Tester等都属于这第2代白盒测试工具。
白盒测试的发展
第2代白盒测试解决了重复测试问题，但没解决持续测试问题。简单来说，重复测试使测试操作能以规范格式记录，当被测对象没变化（或变化很少）时，测试用例是可重用的，但如果源码大幅调整（甚至重构），或者按迭代模式不停追加新功能时，如何维持用例同步增长，并与源码一起同步更新，已经不是简单的增强用例复用能力就能解决的。因为代码更新与用例更新交织进行，测试用例与被测源码一样对等的成为日常工作对象，必然促使原有工作模式与测试方法产生变革，概括而言，白盒测试过程要从一次测试模式过渡到持续测试模式。
白盒测试的发展
某通信产品在V1版本编码完成时，进行过规范的单元测试活动，之后V2、V3要不断增加功能、修改功能，就放弃单元测试了，当V3最后市场交付时统计发现，相对V1版本，代码修改量已达到40%。QA从其中两个模块随机抽取100个问题单做缺陷分析，结果发现：第一个模块有50%的问题是在V1版本单元测试结束后引入的，而另一模块也有30%问题是单元测试后引入的。
白盒测试的发展
第3代白盒测试工具以xUnit为代表，包括JUnit、DUnit、CppUnit等
区别第2代方法与第3代方法，主要是测试理念上差别
白盒测试的发展
第4代白盒测试尝试解决软件测试的深层次矛盾：测试的投入产出比问题。
白盒测试的发展
研发资源总是有限的，你可以把测试人员与开发人员的比例配到1:1，也可以配到2:1，甚至5:1，但你做不到10:1、100:1，如果你有钱，也有人，完全可以按100:1或更高比例配置，这时所有测试瓶颈都没了，你可以让测试人员边喝咖啡边干活，因为每新写1行代码总有人编出100行脚本测试它，还怕产品不稳定吗？
白盒测试的发展
第4代白盒测试方法相对第3代方法，增加了将测试过程（包括测试设计、执行与改进）高效的融入开发全过程
4GWM在3个关键领域的9项关键特征
A.第一关键域：在线测试
1、在线测试驱动
2、在线脚本桩
3、在线测试用例设计、运行，及评估改进
4GWM在3个关键领域的9项关键特征
B.第二关键域：灰盒调测
4、基于调用接口
5、调试即测试
6、集编码、调试、测试于一体
4GWM在3个关键领域的9项关键特征
C.第三关键域：持续测试
7、测试设计先行
8、持续保障信心
9、重构测试设计
参考资料
waynechan，第4代白盒测试方法介绍—理论篇
http://blog.csdn.net/wayne_chan/
http://.eztester/领测科技
VcSmith&VcTester
白盒测试的发展
所谓在线测试，是指被测程序启动后，用例在线设计、调试、运行，运行结果在线查看的测试方法。因为所有测试操作都在线进行，测试用例不必编译链接，被测程序也不用复位重起，被测环境（被测系统的变量、函数等属性）在线可查看，所以该测试模式非常高效，另外，各测试步骤所见即所得，人性化的操作过程很容易被广大开发人员接受。脚本语言具有在线更新功能，比如定义一个脚本函数，调用一次后，发现某个地方处理不对，于是重写这个函数，然后在线的更新这个函数定义。
测试覆盖标准
白盒法特点：以程序的内部逻辑为基础设计测试用例，所以又称为逻辑覆盖法。应用白盒法时，手头必须有程序的规格说明以及程序清单。
白盒法考虑的是测试用例对程序内部逻辑的覆盖程度。
测试覆盖标准
测试覆盖标准
流程图中包括了一个执行达20次的循环。那么它所包含的不同执行路径数高达520条，若要对它进行穷举测试，覆盖所有的路径。假使测试程序对每一条路径进行测试需要1毫秒，同样假定一天工作24小时，一年工作365天，那么要想把如图所示的小程序的所有路径测试完，则需要3170年。
测试覆盖标准
语句覆盖：是一个比较弱的测试标准，它的含义是：选择足够的测试用例，使得程序中每个语句至少都能被执行一次。
它是最弱的逻辑覆盖，效果有限，必须与其它方法交互使用。
测试覆盖标准
判定覆盖（也称为分支覆盖）：执行足够的测试用例，使得程序中的每一个分支至少都通过一次。
判定覆盖只比语句覆盖稍强一些，但实际效果表明，只是判定覆盖，还不能保证一定能查出在判断的条件中存在的错误。因此，还需要更强的逻辑覆盖准则去检验判断内部条件。
条件覆盖
条件覆盖：执行足够的测试用例，使程序中每个判断的每个条件的每个可能取值至少执行一次；
条件覆盖深入到判定中的每个条件但可能不能满足判定覆盖的要求。
测试覆盖标准
判定/条件覆盖：执行足够的测试用例,使得判定中每个条件取到各种可能的值,并使每个判定取到各种可能的结果。
判定/条件覆盖有缺陷。从表面上来看，它测试了所有条件的取值。但是事实并非如此。往往某些条件掩盖了另一些条件。会遗漏某些条件取值错误的情况。为彻底地检查所有条件的取值，需要将判定语句中给出的复合条件表达式进行分解，形成由多个基本判定嵌套的流程图。这样就可以有效地检查所有的条件是否正确了。
测试覆盖标准
条件组合覆盖：执行足够的例子，使得每个判定中条件的各种可能组合都至少出现一次。
这是一种相当强的覆盖准则，可以有效地检查各种可能的条件取值的组合是否正确。它不但可覆盖所有条件的可能取值的组合，还可覆盖所有判断的可取分支，但可能有的路径会遗漏掉。测试还不完全。
白盒测试的主要方法
逻辑驱动测试
语句覆盖
判定覆盖
条件覆盖
判定/条件覆盖
条件组合覆盖
基本路径测试
逻辑驱动测试
语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次
判定覆盖（也称为分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次；
条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次；
逻辑驱动测试
判定/条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的所有可能取值至少执行一次，并且每个可能的判断结果也至少执行一次，换句话说，即是要求各个判断的所有可能的条件取值组合至少执行一次；
条件组合覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的所有可能的条件取值组合至少执行一次；
基本路径测试
设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径。这是最强的覆盖准则。但在路径数目很大时，真正做到完全覆盖是很困难的，必须把覆盖路径数目压缩到一定限度。
在程序控制流程的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例
语句覆盖
语句覆盖”是一个比较弱的测试标准，它的含义是：选择足够的测试用例，使得程序中每个语句至少都能被执行一次。
float M (float A，float B，float X){
if ((A>1) && (B==0)) X=X/A；
if ((A==2) || (X>1)) X=X+1；
return X;
语句覆盖
为使程序中每个语句至少执行一次，只需设计一个能通过路径ace的例子就可以了，例如选择输入数据为：
A=2，B=0，X=3
就可达到“语句覆盖”标准。
语句覆盖
语句覆盖
从上例可看出，语句覆盖实际上是很弱的，如果第一个条件语句中的AND错误地编写成OR，上面的测试用例是不能发现这个错误的；又如第三个条件语句中X＞1误写成X＞0，这个测试用例也不能暴露它，此外，沿着路径abd执行时，X的值应该保持不变，如果这一方面有错误，上述测试数据也不能发现它们。
语句覆盖
void DoWork(int x,int y,int z){
int k=0,j=0;
if((x>3)&&(z
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
判定覆盖
往往大部分的判定语句是由多个逻辑条件组合而成，若仅仅判断其整个最终结果，而忽略每个条件的取值情况，比然会遗漏部分测试路径
条件覆盖
“条件覆盖”的含义是：执行足够的测试用例，使得判定中的每个条件的可能取值至少满足一次。
条件覆盖
例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，取假值为F1
条件z
对于第二个判断：
条件x=4 取真值为T3，取假值为F3
条件y>5 取真值为T4，取假值为F4
条件覆盖
则可以设计测试用例如下
上面的测试用例不但覆盖了所有分支的真假两个分支，而且覆盖了判断中的所有条件的可能值。
条件覆盖
“条件覆盖”通常比“判定覆盖”强，因为它使一个判定中的每一个条件都取到了两个不同的结果，而判定覆盖则不保证这一点。
“条件覆盖”并不包含“判定覆盖”，如对语句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)&&(z3）为假则一般的编译器不在判断是否z5）来说，若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就没有执行，因此，条件组合覆盖标准仍然是不彻底。
条件组合覆盖
1 x>3,z
2 x>3,z>=10记做T1 F2，第一个判断的取假分支
3 x5 记做T3 T4，第二个判断的取真分支
6 x=4,y5 记做F3 T4，第二个判断的取真分支
8 x!=4,y 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
预期结果：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
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;
基本路径测试
必须注意，一些独立的路径，往往不是完全孤立的，有时它是程序正常的控制流的一部分，这时，这些路径的测试可以是另一条路径测试的一部分。
工具方法：图形矩阵
导出控制流图和决定基本测试路径的过程均需要机械化，为了开发辅助基本路径测试的软件工具，称为图形矩阵(graph matrix)的数据结构很有用。
利用图形矩阵可以实现自动地确定一个基本路径集。一个图形矩阵是一个方阵，其行/列数控制流图中的结点数，每行和每列依次对应到一个被标识的结点，矩阵元素对应到结点间的连接（即边）。在图中，控制流图的每一个结点都用数字加以标识，每一条边都用字母加以标识。如果在控制流图中第i个结点到第j个结点有一个名为x的边相连接，则在对应的图形矩阵中第i行/第j列有一个非空的元素x。