2.2 白盒测试
白盒测试的概念
2.2.1 概念
白盒测试作为测试人员常用的一种测试方法越来越受到测试工程师的重视，它并不是简单地按照代码设计测试用例，而是需要根据不同的测试需求并结合不同的测试对象，使用适合的方法进行测试。因为不同复杂的代码逻辑可以衍生出多种执行路径，所以只有适当试方法才能正确地分析代码。
白盒测试又称为“结构化测试”和“基于代码的测试”，是一种测试用例设计方法。它把软件看成装在一个透明的白盒子里，其结构和处理过程完全可见。按照软件的内部逻辑测试软件，以检查其中的每条通路是否都能按照预先要求正确工作。它从软件的控制结构导出测试用例，是针对被测单元内部是如何进行工作的测试。该测试根据软件的控制结构设计测试用例，主要用于软件验证。
采用白盒测试必须遵循以下原则才能达到测试的目标。
（1）保证一个模块中的所有独立路径至少被测试一次。
（2）所有逻辑值均需测试真（true）和假（false）两种情况。
（3）检查软件的内部数据结构，保证其有效性
（4）在上下边界及可操作范围内运行所有循环。
满足白盒测试的测试覆盖率意味着被测试对象已不需要基于此技术再进行额外的测试，但是可以继续应用其他测试技术。白盒测试通常需要测试工具的支持，如一些代码覆盖工具可以用来获取基于机构的测试覆盖率。
2.2.2 基本方法
白盒测试的基本方法
测试人员了解白盒测试技术的基本原理有助于更好地开发白盒测试。本节主要根据代码结构讲解白盒测试的6种逻辑覆盖测试方法。
2.2.2.1 语句覆盖
1.基本思想
语句覆盖的基本思想是设计若干个测试用例运行被测试软件，使软件的每一个执行语句至少被执行一次。
2.案例分析
实现一个简单算术运算的代码如下：
以上代码简化前后的软件流程图如图2-18所示。
图2-18 简化前后的软件流程图
由图（b）可以看出该软件有两个判定，即判定M={x＞0&&y＞0}和判定N={x＞1||z＞1}。
该软件模块有4条不同的路径。
P1：（1-2-4）
P2：（1-2-5）
P3：（1-3-4）
P4：（1-3-5）
按照语句覆盖的测试用例设计原则，可以使用P2或P3来设计测试用例，如表2-23所示。
表2-23 语句覆盖测试用例
3.优势
语句覆盖可以很直观地从源代码得到测试用例，不必细分每个判定表达式。
4.不足
由于这种测试方法仅仅针对软件逻辑中显式存在的语句（即可执行语句），因此无法测试隐藏的条件和可能到达的隐式逻辑分支。
5.语句覆盖率
语句覆盖的覆盖率定义为至少被执行一次的语句数量/可执行语句的总数量。
尽管语句覆盖率是一个比较弱的评判标准，但是有时实现100%的语句覆盖率也是不容易的。
2.2.2.2 判定覆盖
1.基本思想
判定覆盖的基本思想是设计若干个测试用例运行被测试软件，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假值均曾被满足。
2.案例分析
按照判定覆盖的基本原理可以针对上面提到的测试用例进行设计，可以设计两次测试用例使判定M、N分别为真和假，从而达到判定覆盖。具体如下。
当x=1，y=2，z=-2时，判定M为真，N为假。
当x=2，y=-2，z=6时，判定M为假，N为真。
如表2-24所示。
表2-24 判定覆盖测试用例
同理，也可以让测试用例测试路径是P1和P4。
3.优势
判定覆盖比语句覆盖要多几乎一倍的测试路径，当然具有比语句覆盖更强的测试能力。判定覆盖也具有和语句覆盖一样的简单性，不必细分每个判定就可以得到测试用例。
4.不足
往往大部分判定语句由多个逻辑条件组合而成（如判定语句中包含AND、OR、CASE），若仅仅判断其最终结果而忽略每个条件的取值情况，必然会遗漏部分测试路径。
5.判定覆盖率
判定覆盖的覆盖率定义为判定结果被评价的次数/判定结果的总数。
2.2.2.3 条件覆盖
1.基本思想
条件覆盖的基本思想是设计若干个测试用例，运行被测试软件使得每个判断中每个条件的可能取值至少满足一次。
2.案例分析
按照条件覆盖的基本原理可以针对上面提到的测试用例进行设计。
判定M包含下列两个条件。
条件x＞0：取真时为T1，取假时为F1。
条件y＞0：取真时为T2，取假时为F2。
判定N包含下列两个条件。
条件x＞1：取真时为T3，取假时为F3。
条件z＞1：取真时为T4，取假时为F4。
如表2-25所示。
表2-25 条件覆盖测试用例
3.优势
显然条件覆盖比判定覆盖增加了对符合判断情况的测试，增加了测试路径。
4.不足
要达到条件覆盖需要足够多的测试用例，但条件覆盖并不能保证判断覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。
5.条件覆盖率
条件覆盖的覆盖率定义为条件操作数值至少被评价一次的数量/条件操作数值的总数量。
2.2.2.4 判定-条件覆盖
1.基本思想
判定-条件覆盖是判定覆盖和条件覆盖设计方法的交集，其基本思想是设计足够多的测试用例使得判定条件中的所有条件可能取值至少执行一次，并且所有判定的可能结果至少执行一次。
2.案例分析
按照判定-条件测试用例的设计思想，结合前面例子中应该至少保证条件M和N各区真/假一次；同时要保证8个条件取值至少执行一次，如表2-26所示。
表2-26 判定-条件覆盖测试用例
3.优势
判定-条件覆盖满足判定覆盖和条件覆盖准则，弥补了两者的不足。
4.不足
判定-条件覆盖原则未考虑条件的组合情况。
5.判定-条件覆盖率
判定-条件覆盖的覆盖率定义为条件操作数组或判断结果值至少被评价一次的数量/（条件操作数值总数量+判断结果总数量）。
2.2.2.5 条件组合覆盖
1.基本思想
条件组合覆盖的基本思想是设计足够的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时所有判断的可能结果至少执行一次。
2.案例分析
按照条件组合覆盖的基本思路，对于前面的例子采用设计条件组合覆盖设计的测试用例，如表2-27所示。
表2-27 条件组合覆盖测试用例
针对以上8种条件组合，设计所有能覆盖这些组合的测试用例，如表2-28所示。
表2-28 所有能覆盖条件组合的测试用例
3.优势
条件组合覆盖原则满足判定覆盖、条件覆盖和判定-条件覆盖要求设计足够多的测试用例，从而使得判定中每个条件的所有可能结果至少出现一次，以及每个判定本身的所有可能结果也至少出现一次，并且每个条件都能单独影响判定结果。
4.不足
条件组合覆盖线性地增加了测试用例的数量。
5.条件组合覆盖率
条件组合覆盖的覆盖率定义为条件操作数值至少被评价一次的数量/条件操作数组所有组合总数量。
2.2.2.6 路径覆盖
1.基本思想
路径覆盖的基本思想是设计所有的测试用例来覆盖软件中所有可能执行的路径。
2.案例分析
按照路径覆盖的基本思路设计覆盖所有路径的测试用例，如表2-29所示。
表2-29 路径覆盖测试用例
3.优势
路径覆盖测试方法可以彻底测试软件，比前面几种方法测试的覆盖面更广。
4.不足
由于路径覆盖需要对所有可能路径进行测试（包括循环、条件组合、分支判断等），所以需要设计大量且复杂的测试用例，使得工作量呈现指数级增长。对于比较简单的小软件，实现路径覆盖是可能做到的。如果软件中出现较多判断和循环，可能的路径数目将会急剧增加，要在测试中覆盖所有路径是无法实现的。为了解决这个难题，只有把覆盖路径数量压缩到一定限度内。
在实际测试过程中即使对路径数较少的软件已经做了路径覆盖，仍然不能保证测试的正确性，还需要采用其他测试方法进行补充。
总之，路径覆盖的出发点是完善合理的，但是做不到完全无遗漏的覆盖。
2.2.3 选择策略
白盒测试的选择策略如下，可在实际应用过程中参考。
（1）应尽量首先使用工具进行静态结构分析。
（2）可采取先静态后动态的测试实施方式，即先进行静态结构分析和代码检查，再进行覆盖率测试。
（3）利用静态分析的结果作为导引，通过代码检查和动态测试的方式对静态发现结果进一步确认，使测试工作更为有效。
（4）覆盖率测试是白盒测试的重点，一般可使用基本路径测试法达到语句覆盖要求。对于软件的重点模块，应使用多种覆盖率标准衡量其覆盖率。
（5）在不同的测试节点测试的侧重点不同，在单元测试阶段以代码检查、逻辑覆盖为主；在集成测试阶段需要增加静态结构分析等；在系统测试阶段则应根据黑盒测试的结果采取相应的白盒测试。