第 5 章 模块（单元）测试
对于完全没有编程基础的人来说，第五章和第四章一样难懂。
不过好在都是比较简单明了的单词和运算符号组成的，差不多也能猜到是什么意思。
作者同样使用了详细的例子来说明，本章依然仅引用理论部分。
模块测试（或单元测试）是对程序中的单个子程序、子程序或过程进行测试的过程，也就是说，一开始并不是对整个程序进行测试，而是首先将注意力集中在对构成程序的较小模块的测试上面。
使用模块测试的动机：
- 由于模块测试的注意力一开始集中在程序的较小单元上，因此它是一种管理组合的测试元素的手段。
- 模块测试减轻了调试（准确定位并纠正某个已知错误的过程）的难度，这是因为一旦某个错误被发现出来，我们就知道它在哪个具体的模块中。
- 模块测试通过为我们提供同时测试多个模块的可能，将并行工程引入软件测试中。
模块测试的目的是将模块的功能与定义模块的功能规格说明或接口规格说明进行比较。
5.1 测试用例设计
在为模块测试设计测试用例时，需要使用两种类型的信息：模块的规格说明和模块的源代码。规格说明一般都规定了模块的输入和输出参数以及模块的功能。
模块测试的测试用例的设计过程如下：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。
5.2 增量测试
非增量测试或“崩溃（big-bang ) ”测试：软件测试先独立地测试每个模块，然后再将这些模块组装成完整的程序。
增量测试或集成：先将下一步要测试的模块组装到测试完成的模块集合中，然后再进行测试。
二者比较的结论，各自的优缺点：
- 非增量测试所需的工作量要多一些。
- 如果使用了增量测试，可以较早地发现模块中与不匹配接口、不正确假设相关的编程错误。
- 因此如果使用了增量测试，调试会进行得容易一些。
- 增量测试会将测试进行得更彻底。
- 非增量测试所占用的机器时间显得少一些。
- 模块测试阶段开始时，如果使用的是非增量测试，就会有更多的机会进行并行操作（也就是说，所有的模块可以同时测试）。
5.3 自顶向下测试与自底向上测试
5.4 执行测试
- 当测试用例造成模块输出的实际结果与预期结果不匹配的情况时，存在两个可能的解释：要么该模块存在错误，要么预期的结果不正确（测试用例不正确）。
- 为了将这种混乱降低到最小程度，应在测试执行之前对测试用例集进行审核或检查（也就是说，应对测试用例进行测试）。
- 使用自动化测试工具可以使测试过程中的枯燥劳动减至最小。
- 在执行测试时，应该查找程序的副作用（即模块执行了某些不该执行操作的情况）。一般情况下，这些情况都是很难发现的，但如果在测试用例执行完之后，检查那些不应有变动的模块输入，可能会发现一些错误实例。
- 因个人试图测试自己编写的程序所带来的心理学问题，也适用于模块测试。
- 程序员不应测试自己编写的模块，而应交换模块进行测试。编写调用模块的程序员始终是测试被调用模块的最佳候选人。注意，这仅仅适用于测试，对模块的调试一般应当由编程人员本人进行。
- 应避免随意丢弃测试用例，应将它们按某种格式记录下来，以便将来可以重新使用它们。
- 最后，记住模块测试的目的不是证明模块能够正确地运行，而是证明模块中存在着错误。