白盒测试
上周谢了关于黑盒测试的内容，这周的实验是白盒测试，那么这周就对白盒测试做一些总结啦~
1.白盒测试概述：白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。又称结构测试，它一般用来测试程序的内部结构(Control Flow , Data Flow)。并判定其结果是否与预期的结果一致。
2.白盒测试的种类：有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。
(1)静态分析测试（Static Analysis Test，Code Inspection）
(2)语句分支覆盖测试（Ctrl Flow Test）
(3)其他
3.软件人员对软件进行白盒测试时要满足以下4个要求：
(1)保证一个模块中的所有独立路径至少被使用一次。
(2)对所有逻辑值均需测试 true 和 false。
(3)在上下边界及可操作范围内运行所有循环。
(4)检查内部数据结构以确保其有效性。
4.白盒测试的实施步骤：
(1)测试计划阶段：根据需求说明书，制定测试进度。
(2)测试设计阶段：依据程序设计说明书，按照一定规范化的方法进行软件结构划分和设计测试用例。
(3)测试执行阶段：输入测试用例，得到测试结果。
(4)测试总结阶段：对比测试的结果和代码的预期结果，分析错误原因，找到并解决错误。
5.白盒测试的目的：通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试;在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
6.白盒测试的一定局限性：
(1)穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。
(2)穷举路径测试不可能查出程序中因遗漏路径而出错。
(3)穷举路径测试可能发现不了一些与数据相关的错误。
7.白盒测试的测试方法：
有了测试环境 ,重要的是设计测试用例 ,基本路径、判断条件、数据划分、边界值分析是从不同角度设计测试用例的有效方法。
六种覆盖方法（从网上借鉴，以便同学们学习和参考）
首先为了下文的举例描述方便，这里先给出一张程序流程图。（以1995年软件设计师考试的一道考试题目为例，图中红色字母代表程序执行路径）。
1、语句覆盖
1）主要特点：语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。
2）用例设计：（如果此时将A路径上的语句1—〉T去掉，那么用例如下）
| X | Y | 路径 | |
| 1 | 50 | 50 | OBDE |
| 2 | 90 | 70 | OBCE |
3）优点：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。
4）缺点：由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐 式逻辑分支，是无法测试的。在本例中去掉了语句1—〉T去掉，那么就少了一条测试路径。在if结构中若源代码没有给出else后面的执行分支，那么语句覆 盖测试就不会考虑这种情况。但是我们不能排除这种以外的分支不会被执行，而往往这种错误会经常出现。再如，在Do-While结构中，语句覆盖执行其中某 一个条件分支。那么显然，语句覆盖对于多分支的逻辑运算是无法全面反映的，它只在乎运行一次，而不考虑其他情况。
2、判定覆盖--判定覆盖只关心判定表达式的值（真/假),又叫分支覆盖，实际上是<>判定的结果一次为真一次为假！！
1）主要特点：判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。
2）用例设计：
| X | Y | 路径 | |
| 1 | 90 | 90 | OAE |
| 2 | 50 | 50 | OBDE |
| 3 | 90 | 70 | OBCE |
3）优点：判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。
4）缺点：往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。
3、条件覆盖--判定表达式的每个条件的值（真/假）(一个判定中往往包含了若干个条件)
1）主要特点：条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。
2）用例设计：
| X | Y | 路径 | |
| 1 | 90 | 70 | OBC |
| 2 | 40 | OBD |
3）优点：显然条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加了测试路径。
4）缺点：要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。
4、判定/条件覆盖
1）主要特点：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。
2）用例设计：
| X | Y | 路径 | |
| 1 | 90 | 90 | OAE |
| 2 | 50 | 50 | OBDE |
| 3 | 90 | 70 | OBCE |
| 4 | 70 | 90 | OBCE |
3）优点：判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。
4）缺点：判定/条件覆盖准则的缺点是未考虑条件的组合情况。
5、组合覆盖
1）主要特点：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。
2）用例设计：
| X | Y | 路径 | |
| 1 | 90 | 90 | OAE |
| 2 | 90 | 70 | OBCE |
| 3 | 70 | 90 | OBCE |
| 4 | 90 | 30 | OBDE |
| 5 | 30 | 90 | OBDE |
| 6 | 70 | 70 | OBDE |
| 7 | 50 | 50 | OBDE |
备注：OBDE
| X+Y>=140 | X>=90 or Y>=90 | |||
| 1 | F 30 | T 90 or 90,30 | ||
| 2 | T 70 | F 70 | ||
| 3 | F 50 | F 50 |
3）优点：多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。
4）缺点：线性地增加了测试用例的数量。
6、路径覆盖
1）主要特点：设计足够的测试用例，覆盖程序中所有可能的路径。
2）用例设计：
| X | Y | 路径 | |
| 1 | 90 | 90 | OAE |
| 2 | 50 | 50 | OBDE |
| 3 | 90 | 70 | OBCE |
| 4 | 70 | 90 | OBCE |
3）优点：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广。
4）缺点：由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的，如：
If （!A）B++；
If （!A）D--；
这两个语句实际只包括了2条执行路径，即A为真或假时候对B和D的处理，真或假不可能都存在，而路径覆盖测试则认为是包含了真与假的4条执行路径。这样不仅降低了测试效率，而且大量的测试结果的累积，也为排错带来麻烦。
总结
白盒测试是一种被广泛使用的逻辑测试方法，是由程序内部逻辑驱动的一种单元测试方法。只有对程序 内部十分了解才能进行适度有效的白盒测试。但是贯穿在程序内部的逻辑存在着不确定性和无穷性，尤其对于大规模复杂软件。因此我们不能穷举所有的逻辑路径， 即使穷举也未必会带来好运（穷举不能查出程序逻辑规则错误，不能查出数据相关错误，不能查出程序遗漏的路径）。
那么正确使用白盒测试，就要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。任何一个高效的测试用例，都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。