【软件测试】白盒测试和黑盒测试

一般地，我们将软件测试活动分为以下几类：黑盒测试、白盒测试、静态测试、动态测试、手动测试、自动测试等等。

黑盒测试

黑盒测试又叫功能测试、数据驱动测试或给予需求规格说明书的功能测试。这种测试注重于测试软件的功能性需求。

采用这种测试方法，测试工程师把测试对象看作一个黑盒子，不需要考虑程序内部的逻辑结构和特性，只需要依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试能更好更真实的从用户角度来考察被测系统的功能性需求实现情况。在软件测试的各个阶段，如单元测试、集成测试、系统测试及确认测试等阶段都发挥着重要作用。尤其在系统测试和确认测试中，其作用是其他测试方法无法取代的。

白盒测试

白盒测试又称结构测试、逻辑驱动测试或基于程序代码内部结构的测试。此时，需要深入考察程序代码的内部结构、逻辑设计等等。白盒测试需要测试工程师具备很深的软件开发工地，精通相应的开发语言，一般的软件测试工程师难以胜任该工作。

静态测试

静态测试，顾名思义，就是静态的、不执行被测对象程序代码而寻找缺陷的过程。通俗地讲，静态测试就是用眼睛看，阅读程序代码，文档资料等，与需求规格说明书中的需求进行比较，找出程序代码中设计的不合理，以及文档资料中的错误。

在进行代码的静态测试时，可以采用一些代码走查的工具，如 QA C++、C++ Test等。

动态测试

动态测试即为实际的执行被测对象的程序代码，输入事先设计好的测试用例，检查程序代码运行的结果与测试用例中设计的预期结果之间是否差异，判定实际结果与预期结果是否一致，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能状况。

动态测试由四部分组成：设计测试用例、执行测试用例、分析比较输出结果、输出测试报告。

动态测试结合使用白盒测试和黑盒测试。

对于白盒测试，常用的测试方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖等等。黑盒测试较为知名的测试方法有：等价类划分、边界值分析、因果图分析、错误猜测等。本章将对这些测试方法进行一些简单的介绍。

白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构（源代码） 的程度。如完全的白盒测试是将程序中每条路径都执行到，然而对一个带有循环的程序来说，完全的路径测试并不切合实际。

​

图 2‑1被测试的小程序

如果完全从路径测试中跳出来看，那么有价值的目标似乎就是将程序中的每条语句至少执行一次。遗憾的是，这恰是合理的白盒测试中较弱的准则。图2‑1描述了这种思想。假设图2‑1 代表了一个将要进行测试的小程序，其等价的代码段如下：

Public void foo(int a, int b, int x)

{

if (a > 1 &&b == 0)

{

x = x/ a;

}

if (a == 2 || x > 1)

{

X = x +1;

}

}

通过编写单个的测试用例遍历程序路径 ace，可以执行到每一条语句。也就是说，通过在点 a 处设置 A=2，B=0，X=3，每条语句将被执行一次（实际上，X 可被赋任何值）。

遗憾的是，这个准则相当不足。举例来说，也许第一个判断应是“或”，而不是 “与” 。 如果这样， 这个错误就会发现不到。另外， 可能第二个判断应该写成 “X>0” ，这个错误也不会被发现。还有，程序中存在一条 X 未发生改变的路径（路径 abd），如果这是个错误，它也不会被发现。换句话说，语句覆盖这条准则有很大的不足，以至于它通常没有什么用处。

判定覆盖或分支覆盖是较强一些的逻辑覆盖准则。该准则要求必须编写足够的测试用例，使得每一个判断都至少有一个为“真”和为“假”的输出结果。换句话说，也就是每条分支路径都必须至少遍历一次。分支或判定语句的例子包括switch，do-while 和 if-else 语句。

判定覆盖通常可以满足语句覆盖。由于每条语句都是在要么从分支语句开始，要么从程序入口点开始的某条子路径上，如果每条分支路径都被执行到了，那么每条语句也应该被执行到了。但是，仍然有些例外情况：

• 程序中不存在判断。

• 程序或子程序/方法有着多重入口点。只有从程序的特定入口点进入时，某条特定的语句才能执行到。

我们的探讨仅针对有两个选择的判断或分支，当程序中包含有多重选择的判断时，判定/分支覆盖准则的定义就必须有所改变。典型的例子有包含select(case)语句的 Java 程序，包含算术 （三重选择） IF 语句、计算或算术 GOTO 语句的 FORTRAN 程序，以及包含可选 GOTO 语句或 GO-TO-DEFENDING-ON 语句的 COBOL 程序。对于这些程序，判定/分支覆盖准则将所有判断的每个可能结果都至少执行一次，以及将程序或子程序的每个入口点都至少执行一次。

在图2‑1 中，两个涵盖了路径 ace 和 abd，或涵盖了路径 acd 和 abe 的测试用例就可以满足判定覆盖的要求。如果我们选择了后一种情况，两个测试用例的输入是 A=3，B=0，X=3 和 A=2，B=1，X=1。

判定覆盖是一种比语句覆盖更强的准则，但仍然相当不足。举例来说，我们仅有 50%的可能性遍历到那条 X 未发生变化的路径（也即， 仅当我们选择前一种情况） 。

如果第二个判断存在错误（例如把 X>1 写成了 X1。因此需要足够的测试用例，使得在点 a 处出现 A=2、A1 及 X

i=1;

}

在存在循环的情况下，多重条件覆盖准则所需要的测试用例的数量通常会远远小于其路径的数量。

总的来说，对于包含每个判断只存在一种条件的程序，最简单的测试准则就是设计出足够数量的测试用例，实现：（1）将每个判断的所有结果都至少执行一次；（2）将所有的程序入口都至少调用一次，以确保全部的语句都至少执行一次。而对于包含多重条件判断的程序，最简单的测试准则是设计出足够数量的测试用例，将每个判断的所有可能的条件结果的组合，以及所有的入口点都至少执行一次（加入“可能”二字，是因为有些组合情况难以生成）。

在以上测试用例中，我们发现漏掉了路径acd。路径覆盖则要求覆盖程序所有可能的路径，路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等）。那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的。

从这个简单的例子可以看出，要想充分测试一个程序是很困难的。同时，测试条件越强，测试的代价越高。测试时应分主次，在测试代价和测试充分性之间做出平衡。

一个好的测试用例描述为具有相当高的可能性发现某个错误来，此外对程序的穷举输入测试是无法实现的。因此，当测试某个程序时，我们就被限制在从所有可能的输入中努力找出某个小的子集。理所当然，我们要找的子集必须是正确的，并且是可能发现最多错误的子集。确定这个子集的一种方法，就是要意识到一个精心挑选的测试用例还应具备另外两个特性：

1. 严格控制测试用例的增加，减少为达到“合理测试”的某些既定目标而必须设计的其他测试用例的数量。

2. 它覆盖了大部分其他可能的测试用例。也就是说，它会告诉我们，使用或不使用这个特定的输入集合，哪些错误会被发现，哪些会被遗漏掉。

虽然这两个特性看起来很相似，但描述的却是截然不同的两种思想。第一个特性意味着，每个测试用例都必须体现尽可能多的不同的输入情况，以使最大限度地减少测试所需的全部用例的数量。而第二个特性意味着应该尽量将程序输入范围进行划分，将其划分为有限数量的等价类，这样就可以合理地假设（但是，显然不能绝对肯定）测试每个等价类的代表性数据等同于测试该类的其他任何数据。也就是说，如果等价类的某个测试用例发现了某个错误，该等价类的其他用例也应该能发现同样的错误。相反，如果测试用例没能发现错误，那么我们可以预计，该等价类中的其他测试用例不会出现在其他等价类中，因为等价类是相互交迭的。

这两种思想形成了称为等价划分的黑盒测试方法。第二种思想可以用来设计一个“令人感兴趣的”输入条件集合以供测试，而第一个思想可以随后用来设计涵盖这些状态的一个最小测试用例集。

使用等价划分方法设计测试用例主要有两个步骤：（1）确定等价类； （2）生成测试用例。

表2‑1等价类列举表

输入条件

有效等价类

无效等价类

1．确定等价类

确定等价类是选取每一个输入条件（通常是规格说明中的一个句子或短语）并将其划分为两个或更多的组。可以使用表2‑1中的表格来进行划分。注意，我们确定了两类等价类：有效等价类代表对程序的有效输入，而无效等价类代表的则是其他任何可能的输入条件（即不正确的输入值）。这样，我们遵循了测试原则，即要注意无效和未预料到的输入情况。

在给定了输入或外部条件之后，确定等价类大体上是一个启发式的过程。下面给出了一些指导原则：

1. 如果输入条件规定了一个取值范围（例如，“数量可以是从1到999”)，那么就应确定出一个有效等价类 （1