本文共 3321 字，大约阅读时间需要 11 分钟。

7.0 前言

本章的重点包括：

• 什么是动态白盒测试
• 调试和动态白盒测试之间的区别
• 单元和集成测试是什么
• 如何测试底层功能
• 底层测试所需的数据范围
• 如何强制软件以某种方式运行
• 衡量测试完整性的各种方法

7.1 动态白盒测试

用一句话来概括，动态白盒测试是指利用查看代码功能（做什么）和实现方式（怎么做）得到的信息来确定哪些需要测试、哪些不需要测试、如何开展测试。动态白盒测试的另一个常用名称是结构化测试，因为软件测试员可以查看并使用代码的内部结构，从而设计和执行测试。

动态白盒测试不仅查看代码的运行情况，还包括直接测试和控制软件。动态白盒测试包括以下4个部分：

• 直接测试底层函数、过程、子程序和库。在Microsoft Windows中这称为应用程序编程接口（API）。
• 以完整程序的方式从顶层测试软件，但是根据对软件运行的了解调整测试用例。
• 从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时，强制软件以正常测试难以实现的方式运行。
• 估算执行测试时“命中”的代码量和具体代码，然后调整测试，去掉多余的测试用例，补充遗漏的测试用例。

7.2 动态白盒测试和调试

这两项技术表面上很相似，因为它们都包括处理软件缺陷和查看代码的过程，但是它们的目标大不相同。

动态白盒测试的目标是寻找软件缺陷，调试的目标是修复缺陷。然而，它们在隔离软件缺陷的位置和原因上确实存在交叉现象。软件测试员应该把问题缩减为能够演示软件缺陷的最简化测试用例。如果是白盒测试，甚至还要包括那些值得怀疑的代码行信息。进行调试的程序员从这里继续，判断到底是什么导致软件缺陷，并设法修复。

7.3 分段测试

7.3.1

在底层进行的测试称为单元测试或者模块测试。单元经过测试，底层软件缺陷被找出并修复之后，就集成在一起，对模块的组合进行集成测试。这个不断增加的测试过程继续进行，加入越来越多的软件片段，直至整个产品——至少是产品的主要部分——在称为系统测试的过程中一起测试。

采取这种测试策略很容易隔离软件缺陷。在单元级发现问题时，问题肯定就在那个单元中。如果在多个单元集成时发现软件缺陷，那么它一定与模块之间的交互有关。当然也有例外，但是总的说来，测试和调试比一起测试所有内容要有效得多。

这种递增测试有两条途径：自底向上和自顶向下。在自底向上测试中，要编写称为测试驱动的模块调用正在测试的模块。测试驱动模块以和将来真正模块同样的方式挂接，向处于测试的模块发送测试用例数据，接受返回结果，验证结果是否正确。采取这种方式，可以对整个软件进行非常全面的测试，为它提供全部类型和数量的数据，甚至高层难以发送的数据。

自顶向下测试有点像小规模的大爆炸测试。毕竟，如果更高层软件已经完成，测试其下层的模块就一定太晚了，对啊？其实并不完全正确。请看下图。

与其通过设法控制温度计的温度来测试温度显示模块，不如编写一小段称为桩的代码充当接口模块，从文件中把温度值直接提供给显示模块。显示模块将会读取数据并显示温度，就像直接从实际温度计接口模块中读取数据一样。它不可能有何不同。有了这个测试桩配置，就可以快速从头到尾试验各种测试值，验证显示模块的操作。

7.3.2 单元测试示例

7.4 数据覆盖

白盒测试应该像黑盒测试那样把软件代码分成数据和状态（或者程序流程）。从同样的角度看软件，可以相当容易地把得到的白盒信息映射到已经写完的黑盒测试用例上。

首先考虑数据。数据包括所有的变量、常量、数组、数据结构、键盘和鼠标输入、文件、屏幕输入/输出，以及调制调解器、网络等其他设备的输入和输出。

7.4.1 数据流

数据流覆盖主要是指在软件中完全跟踪一批数据。如果在底层测试函数，就会使用调试器观察变量在程序运行时的数据。通过黑盒测试，只能知道变量开始和结束的值。通过动态白盒测试，还可以在程序运行期间检查变量的中间值。根据观察结果就可以决定更改某些测试用例，保证变量取得感兴趣的、甚至具有风险的中间值。

7.4.2 次边界

软件的各个部分都有自己的次边界，下面是一些例子：

• 计算税收的模块在某些财务结算处可能从使用数据表转向使用公式。
• 在RAM底端运行的操作系统也许开始把数据移到硬盘上的临时存储区。这种次边界甚至无法确定，它随着磁盘上剩余空间的数量而发生变化。
• 为了获得更高的精度，复杂的数值分析程序根据数字大小可能切换到不同的等式以解决问题。

如果进行白盒测试，就需要仔细检查代码，找到次边界条件，并建立能测试它们的测试用例。询问编写代码的程序员是否知道这些条件，并对内部数据表给予特别的注意，因为这里聚集了大量的次边界条件。

7.4.3 公式和等式

技巧：撇开代码中的公式和等式，查看它们使用的变量，在程序正常输入和输出之外，为其建立测试用例和等价划分。

7.4.4 错误强制

如果执行在调试器中测试的程序，不仅能够观察到变量的值——还可以强制改变变量的值。注意：在使用错误强制时，小心不要设置现实世界中不可能出现的情况。如果仔细选择了错误强制情况，并和程序员一起反复检查以确认它们是合法的，错误强制就是一个有效的工具。借此可以执行其他方式难以实现的测试用例。

强制显示错误提示信息：使用错误强制的上好方法是迫使软件中的所有错误提示信息显示出来。大多数软件使用内部错误代码表示错误提示信息。当内部错误条件标志被置位时，错误处理程序读取存放错误代码的变量，在表中查找代码，并显示相应的信息。

许多错误情况是难以建立的——例如挂接2049台打印机。但是如果只是想测试错误提示信息是否正确（拼写、语言、格式等），那么使用错误强制是最有效的查看方式。然而要记住，这不是测试检验错误的代码，而是显示错误的代码。

7.5 代码覆盖

与黑盒测试一样，测试数据只是一半工作。为了全面地覆盖，还必须测试程序的状态以及程序流程，必须设法进入和退出每一个模块，执行每一行代码，进入软件每一条逻辑和决策分支。这种类型的测试叫作代码覆盖测试。

代码覆盖测试最简单的形式是利用编译环境的调试器通过单步执行程序查看代码。对于小程序或者单独模块，使用调试器一般就足够了。然而，对于大多数程序进行代码覆盖测试要用到称为代码覆盖率分析器的专门工具。

代码覆盖率测试器挂接在正在测试的软件中，当执行测试用例时在后台执行。每当执行一个函数、一行代码或一个逻辑决策分支时，分析器就记录相应的信息。从中可以获得指示软件哪些部分被执行，哪些部分未被执行的统计结果。利用该数据可以得到：

• 测试用例没有覆盖软件的哪些部分。如果某个模块中的代码从未执行，就需要额外编写测试该模块函数的用例。
• 哪些测试用例是多余的。如果执行一系列测试用例，而未增加代码覆盖率的百分比，那么这些测试用例就可能处于同一个等价划分。
• 为了使覆盖率更好，需要建立什么样的新测试用例。通过观察覆盖率低的代码，看它如何工作，做了什么，从而建立可以更彻底地测试它的新测试用例。

此外还可以得到软件质量的大致情况。如果测试用例覆盖了软件的90%而未发现任何软件缺陷，就说明软件质量非常好。相反，如果测试只覆盖了软件的50%仍然发现了一些软件缺陷，就说明软件还要大加改进。

7.5.1 程序语句和代码行覆盖

代码覆盖最直接的形式称为语句覆盖或者代码行覆盖。如果在测试软件的同时监视语句覆盖，目标就是保证程序中每一条语句最少执行一次。

有人可能认为这是完全测试程序的最好办法，可以边进行测试，边补充测试用例，直至程序中的每一条语句都不漏掉为止。遗憾的是语句覆盖是一种误导。可以说即使是全部语句都被执行了，但是不能说走遍了软件的所有路径。

7.5.2 分支覆盖

试图覆盖软件中的所有路径称为路径覆盖。路径测试最简单的形式称为分支覆盖测试。

7.5.3 条件覆盖

条件覆盖测试将分支语句的条件考虑在内。

转载地址：http://qdyki.baihongyu.com/