软件测试笔记（七）- 动态白盒测试

了解如何通过代码评审或观察动态运行测试获得的信息来改进测试。

一、动态白盒测试

动态白盒测试 ：实质利用查看代码功能（做什么）和实现方式（怎么做）得到的信息来确认哪些需要测试、哪些不要测试、如何展开测试。又称为 结构化测试（structural testing） ，因为软件测试员可以查看并使用代码的内部结构从而设计和执行测试。

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

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

二、动态白盒测试和调试

一定不要不动态白盒测试和调试弄混了。

动态白盒测试 的目标是寻找软件缺陷， 调试（debugging） 的目标是修复缺陷。然而他们在隔离软件缺陷的位置和原因尚确实存在交叉现象。

注意：执行这些底层的测试，会用到许多和程序员使用的相同的工具。可能会使用代码级的调试器来单步跟踪程序，观察变量，设置断点，等等。

三、分段测试

• 单元测试和集成测试

1. 在底层进行的测试称为 单元测试（unit testing） ,或者 模块测试（module testing） 。
2. 单元经过测试，底层软件却下被找出并修复之后，就集成在一起，对模块的组合进行 集成测试（integration testing） 。
3. 这个不断增加的测试过程继续进行，加入越来越多的软件片段，直至整个产品——至少是产品的主要部分——在称为 系统测试（testing） 的过程中一起测试。
4. 在 自底向上测试（bottom-up） 中，要编写称为测试驱动的模块调用正在测试的模块。测试驱动模块以和将来真正模块同样的方式挂接，向处于测试的模式发送测试用例数据，接收返回结果，验证结构是否正确。采取这种方式，可以对整个软件进行非常全面的而测试，为它提供全部类型和数量的数据，甚至高层难以发送的数据。
5. 自顶向下测试(top-down) ：编写一小段称为 桩（Stub） 的代码充当接口模块，从文件中把信息直接提供给显示模块。显示模块读取数据并且显示。
6. ***测试驱动***可以有很多形式。由用户驱动的对话框的交互性和灵活性强——可以用来进行黑盒测试。而独立驱动可以及其快速地直接从文件中读写测试用例。

注意：在进行白盒测试之前，一定要根据说明书简历黑盒测试用例。根据白盒知识增减测试用例其实是根据程序内部的信息对等划分的进一步提炼。

四、数据覆盖

在进行白盒测试时，合理的方法是像黑盒测试一样，把软件代码分为数据和状态（或者程序流程）。从同样的角度看软件，可以相当容易地得到的白盒信息映射到已经写完的黑盒测试用例上。

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

• 数据流

数据流（Data flow） ：覆盖主要是指在软件中完全跟踪一批数据。在单元测试中，软件仅仅通过了一个模块或者函数。同样的跟踪方式可以用于多个集成模块，甚至整个软件产品——尽管这样做是非常耗时的。

在底层测试数据：

1. 通过黑盒测试，只能知道变量开始和结束的值。
2. 通过动态白盒测试，还可以在程序运行期间检查变量的中间值。根据观察结果就可以决定更改，某些测试用例，保证变量取得感兴趣、甚至是具有风险的中间值。

• 次边界

如果进行白盒测试，就需要仔细检查代码，找到次边界条件，并建立能测试它们的测试用例。

• 公式和等式

公式和等式通常深藏在代码中，从外部看，其形式和影响不是十分明显。撇开代码中的公式和等式，查看它们使用的变量，在程序正常输入和输出之外，为期简历测试用例和等价划分。

• 错误强制

强制错误（error forcing） ：如果执行在调试器中测试的程序，不仅嫩够观察到变量的值——还可以强制改变变量的值。

注意：在使用错误强制是，小心不要设置现实世界中不可能出现的情况。否则，是程序失败的此用例就是非法的。

五、代码覆盖

• 程序语句和代码行覆盖

代码覆盖(code coverage）测试 ：为了全面地覆盖，还必须测试程序的状态以及程序流程，必须设法进入和退出每一个模块，执行每一行代码，进入软件每一条逻辑和决策分支。

1. 代码覆盖测试是一种动态白盒测试，因为它要求通过完全访问代码以查看运行测试用例是经过了哪些部分。
2. 代码覆盖测试最简单的形式是利用编译环境的调试器通过单步执行程序查看代码。对于小程序或者单独模块，试用调试器一般就足够了。
3. 代码测试专用工具——“ 代码覆盖率分析器（code coverage analyzer） ”，可以得到的信息：
   （1）测试用例没有覆盖软件的哪些部分；
   （2）哪些测试用例是多余的。
   （3）为了使覆盖率更好，需要建立什么样的新测试用例。

• 程序语句和代码行覆盖

如果在测试软件的同时见识语句覆盖，目标就是保证程序中每一条语句最少执行一次，称为 语句覆盖（statement coverage） 或者 代码行覆盖（line coverage） 。

注意：即使全部语句都被执行了，但是不能说走遍了软件的所有路径。

• 分支覆盖

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

• 条件覆盖

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

注意：

1. 测试条件差覆盖，就能达到分支覆盖，顺带也能达到语句覆盖。
2. 即使想方设法测试所有的语句、分支和条件，也还没有做到完全测试软件，因为数据错误仍然可能出现。程序流程和数据共同构成了软件的操作。

五、小结

• 软件测试的基础：

1. 静态黑盒测试：是指检查软件产品说明书，并在软件编写之前找出问题。
2. 动态黑盒测试：是指再不理了解软件是如何工作的情况下进行测试。
3. 静态白盒测试：是指通过正式审查和检验检查代码的细节。
4. 动态白盒测试：是指在看到软件的工作方式，根据获得的信息对软件进行测试。

参考文献

1. 《软件测试（原书第2版）》
2. 《软件测试的艺术（原书第3 版）》