白盒测试方法以及归纳

白盒测试基本概念

　　白盒测试（white-box testing）又称透明盒测试（glass box testing）、结构测试（structural testing）等，软件测试的主要方法之一，也称结构测试、逻辑驱动测试或基于程序本身的测试。测试应用程序的内部结构或运作，而不是测试应用程序的功能（即黑盒测试）。在白盒测试时，以编程语言的角度来设计测试案例。测试者输入数据验证数据流在程序中的流动路径，并确定适当的输出，类似测试电路中的节点。测试者了解待测试程序的内部结构、算法等信息，这是从程序设计者的角度对程序进行的测试。
　　白盒测试可以应用于单元测试（unit testing）、集成测试（integration testing）和系统的软件测试流程，可测试在集成过程中每一单元之间的路径，或者主系统跟子系统中的测试。尽管这种测试的方法可以发现许多的错误或问题，它可能无法检测未使用部分的规范。

白盒测试中的六种覆盖方法

　　白盒测试用例设计的一个很重要的评估标准就是对代码的覆盖度。白盒测试中常见的覆盖方法有六种：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖。下面我们就分别看看这几种不同的覆盖吧。

一、语句覆盖（Statement Coverage）

　　主要特点：语句覆盖是最起码的结构覆盖要求，语句覆盖需要选择足够的测试用例，使我们设计出来的测试用例要保证程序中的每一个语句至少被执行一次。
　　优点：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。
　　缺点：由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐 式逻辑分支，是无法测试的。
　　举例：
　　public int foo(int a,int b)
　　{
　　　 return a/b;
　　}
　　这是一个求两数之商的函数。如果我们设计如下的测试用例：
TestCase: a =2, b =1
此时，该函数的代码覆盖率达到了100%，并且设计的case可以顺利通过测试。但是显然该函数有一个很明显的bug：当 b=0 时，会抛出异常。

二、判定覆盖（Decision Coverage）

　　主要特点：判定覆盖又称为分支覆盖，它要求选择足够的测试用例，使得运行这些测试用例时，每个判定的所有可能结果至少出现一次。
　　优点：判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。
　　缺点：往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。
　　举例：
　　
- X Y 路径
90 90 OAE
50 50 OBDE
90 70 OBCE

三、条件覆盖（Condition Coverage）

　　主要特点：要求所设计的测试用例能使每个判定中的每一个条件都获得可能的取值，即每个条件至少有一次真值、有一次假值。
　　优点：显然条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加了测试路径。条件覆盖使得判定中的每一个条件都取到了不同的结果，这一点判定覆盖则无法保证。
　　缺点：要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。
　　举例：
- X Y 路径
90 70 OBC
40 OBD

四、判定条件覆盖（Decision/Condition Coverage）

　　判定条件覆盖，说白了就是我们设计的测试用例可以使得判断中每个条件所有的可能取值至少执行一次（条件覆盖），同时每个判断本身所有的结果也要至少执行一次（判定覆盖）。不难发现判定条件覆盖同时满足判定覆盖和条件覆盖，弥补了两者各自的不足，但是判定条件覆盖并未考虑条件的组合情况。

五、组合覆盖（Branch Condition Combination Coverage）

　　组合覆盖也叫做条件组合覆盖。意思是说我们设计的测试用例应该使得每个判定中的各个条件的各种可能组合都至少出现一次。显然，满足条件组合覆盖的测试用例一定是满足判定覆盖、条件覆盖和判定条件覆盖的。
　　针对前文提到的流程图，做条件组合覆盖时我们可以设计如下用例：
TestCase1: a=1, b=1 (路径：ab)
TestCase1: a=-1, b=-1 (路径：acd)
TestCase1: a=-1, b=0 (路径：ace)
TestCase1: a=1, b=-1 (路径：ace)
条件组合覆盖能够同时满足判定、条件和判定条件覆盖，覆盖度较高，但是组合覆盖的测试用例数量相对来说也是比较多的。

六、路径覆盖

　　路径覆盖，意思是说我们设计的测试用例可以覆盖程序中所有可能的执行路径。这种覆盖方法可以对程序进行彻底的测试用例覆盖，比前面讲的五种方法覆盖度都要高。那么这种方法是不是就一定最好呢？当然不能讲得这么绝对，它的缺点也是显而易见的：由于需要对所有可能的路径全部进行覆盖，那么我们需要设计数量非常巨大的而且较为复杂的测试用例，用例数量将呈现指数级的增长。所以理论上来讲路径覆盖是最彻底的测试用例覆盖，但实际上很多时候路径覆盖的可操作性不强。

总结
　　以上简单描述了几种不用的逻辑覆盖方法的原则和优劣。在实际的操作中，要正确使用白盒测试的代码覆盖方法，就要从代码分析和代码调研入手，根据调研的结果，可以选择上述方法中的某一种，或者好几种方法的结合，设计出高效的测试用例，尽可能全面地覆盖到代码中的每一个逻辑路径。