白盒测试（一）

1.1 什么是白盒测试

借助生活中的自动售货机为例：

在对一个自动售货机进行测试时，我们可以准备大量纸币和硬币，如10元的，5元的，1元的，5角的，甚至还有游戏币来对自动售货机进行黑盒测试和白盒测

试。

如果进行黑盒测试：

       自动售货机内部的机械机构测试人员并不清楚，但是售货机实现的功能测试人员是很清楚的。例：

       当投入10元时，购买价值5元的货物时，售货机会送出货物并且找零。

       当投入5元时，购买价值5元的货物时，售货机只会送出货物。

       当投入游戏币时，售货机会识别并退出游戏币。

       ......

       对于测试人员而言，只要了解了售货机的功能，就完全可以站在用户即消费者的角度上进行测试。

       给售货机投入不同组合的纸币和硬币，分别选择不同的货物，然后观察自动售货机将送出什么？将售货机的输入和输出一一对应起来，检测售货机的功能是否正

确。

这就是对自动售货机的黑盒测试。

然后测试人员换个角度，对自动售货机进行白盒测试。这时需要把自动售货机外围的一层铁皮全部拿走，售货机内部的机械结构将会被看得清清楚楚，有多少个

机械结构，每个机械结构由哪些零配件组成零配件和零配件之间的触发会否正常，这就需要我们针对每个机械结构展开测试，这种测试方法，可以将每种机械结构都

能进行遍历，一般不会存在漏测的可能。

这就是对自动售货机的白盒测试。

回到软件测试领域，对一个被测对象，如函数在进行测试时，也可以分别采用黑盒方法和白盒方法进行检测。

从黑盒的角度来讲，函数内部的逻辑结果不需要了解，只需要测试人员了解其功能即可，如该函数实现的是排序的功能，从黑盒的角度来讲，不关心排序是如何

实现的，用了什么样的算法。只需要输入若干数据，检测函数处理后的结果是不是进行了排序就可以了。

而从白盒的角度来测试，需要分析函数内部的逻辑结构，包括函数的结构，内部局部数据的定义引用，函数内部各个控制语句组成的不同路径等是否合法。

在测试类书籍中，白盒测试（White Box Testing）有多种称法，如玻璃盒测试（Glass Box Testing），透明盒测试（Clear Box Testing），开放盒测试（Open

 Box Testing），结构化测试（Structured Testing），基于代码的测试（Code-Based Testing），逻辑驱动测试（Logisc-Driven Testing）等。白盒测试是一种测

试用例设计方法，在这里盒子指的是被测试的软件，白盒，顾名思义即盒子是可视的，你可以清楚盒子内部的东西以及里面是如何运作的，因此白盒测试需要你对系

统内部的结构和工作原理有一个清楚的了解，并且基于这个知识来设计你的用例。

使用白盒测试方法产生的测试用例能够：

1、保证一个模块中的所有独立路径至少被使用一次；

2、对所有逻辑值均需测试 true 和 false；

3、在上下边界及可操作范围内运行所有循环；

4、检查内部数据结构以确保其有效性。

1.2 为什么要进行白盒测试

“我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？”

答案在于软件自身的缺陷：

• 逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。

当我们设计和实现主流之外的功能、条件和控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而“特殊情况”的处理则难于发现。

• 我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。

程序的逻辑流有时时违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。

• 笔误是随机的。

当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上

和不明显的逻辑路径上的几率是一样的。

正如 Beizer 所说的：“错误潜伏在角落里，聚集在边界上”，而白盒测试更可能发现它。