模块测试也叫单元测试，是对程序中的单个子程序、子程序或过程进行测试的过程，也就是说，一开始并不是对整个程序进行测试，而是先将注意力集中在对构成程序的较小模块的测试上面。这样做的动机有三个。首先，由于模块测试的注意力一开始集中在程序的较小单元上，因此它是一种管理组合的测试元素的手段。其次，模块测试减轻了调试（准确定位并纠正某个已知错误的过程）的难度，这是因为一旦某个错误被发现出来，我们就知道它在哪个具体的模块中。再次，模块测试为同时测试多个模块提供了可能，这将并行工程引入软件测试中。
模块测试的目的是将模块的功能与定义模块的功能规格说明或接口规格说明进行比较。这里的测试目的不是为了说明模块符合其规格说明，而是为了揭示出模块与其规格说明存在着矛盾。

1.测试用例的设计

在为模块测试设计的测试用例时，需要使用两种类型的信息：模块的规格说明和模块的源代码。规格说明一般都规定了模块的输入和输出参数以及模块的功能。
模块测试总体上是面向白盒测试的。其中一个原因是如果对大一点的软件进行测试，例如一个完整的程序（其实是后续的测试过程所针对的对象），白盒测试不容易展开。第二个原因是，后续的测试过程着眼于发现其他类型的错误（比如这些错误不一定与程序的逻辑结构有关，比如程序未能满足其用户需求）。因此模块测试中测试用例的设计过程如下：

使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明书以补充测试用例。

2.增量测试

在执行模块测试过程中，主要考虑两点：第一，如何设计一个有效的测试用例集；第二，将模块组装成工作程序的方式。
第二点涉及了：模块测试用例的编写形式；可能用到的测试工具类型；模块编码与测试顺序；生成测试用例的成本以及调试的成本。
考虑一个问题：软件测试是否应先独立地测试每个模块，然后再将这些模块组装成完整的程序？还是先将下一步要测试的模块组装到测试完成地模块集合中，然后再测试？第一种称为非增量测试或崩溃（big-bang）测试，第二种称为增量测试或集成。
例子：下图表示6个模块，A调用B，C，D；B调用E；D调用F。

作为传统方法的非增量测试流程：

首先，对6个模块中的每一个模块进行单独的模块测试，将每个模块视为一个独立实体。根据环境（人机交互，还是用批处理工具）和参与人数，这些模块可以同时或按次序进行测试。最后，将这些模块组装或集成为完整程序。
测单独模块需要一个特殊的驱动模块（driver module）和一个或多个桩模块（stub module）。比如，测试B，首先要设计测试用例，然后将测试用例作为输入参数由驱动模块传给B。驱动模块用来将测试用例驱动或传输到被测模块中（也可以用测试工具代替）。驱动模块还必须向测试人员显示模块B的结果。此外，由于模块B调用了模块E，还必须使用额外的组件，在B调用E时接受B的控制指令。这由桩模块完成，它是一个被命名为E的特殊模块，用来模拟E的功能。

驱动模块：用来模拟被测试模块的上一级模块，相当于被测模块的主程序。它接收数据，将相关数据传送给被测模块，启用被测模块并输出相应结果。可以通过模拟一系列用户操作行为，自动调用被测模块中的函数。通过驱动模块设置，使对模块的测试不必与用户界面真实交互。
桩模块：指模拟被测模块所调用的模块。主模块作为驱动模块，与之直接相连的模块用桩模块代替。在集成测试之前要为被测模块编写一些模拟其下级模块功能的替身，以代替被测模块的接口，接收或传递被测模块数据，这些专供测试的假模块称为被测模块的桩模块。
如果被测试的单元测试需要调用其他模块中的功能或者函数（method），就应该设计一个和被调用模块名称相同的桩模块来模拟被调用模块。这个桩模块本身不执行任何功能仅在被调用时返回静态值来模拟被调用模块的行为。比如：如果被测模块中需要调用另一个模块customer函数getCustomAddress(customID:Integer)，应该查数据库后返回地址。可以设计同名桩模块中的同名函数模拟这一行为，直接返回一个静态值。
桩模块的使命除了使得程序能够编译通过之外，还需要模拟返回被代替的模块的各种可能返回值(什么时候返回什么值需要根据测试用例的情况来决定)。
驱动模块的使命就是根据测试用例的设计去调用被测试模块，并且判断被测试模块的返回值是否与测试用例的预期结果相符

增量测试流程

第一步先测E，C和F，可以并行测试（三个人进行），也可以串行进行。必须要为每个模块准备一个驱动模块而不是桩模块。下一步是测试模块B和D，分别将其与模块E和F组装。以此类推直到测完最后一个模块为止。

结论

1，非增量测试工作量多点。以上图为例，需要5个驱动模块和5个桩模块（假设顶部的模块不需要驱动模块）。自底向上的增量测试需要5个驱动模块，不要桩模块。自顶向下的增量测试需要5个桩模块，不要驱动模块。增量测试工作量少一些因为使用了前面测试过的模块替代非增量测试中所需的驱动模块。
2，使用增量测试能较早发现模块中与不匹配接口、不正确假设相关的编程错误。因为尽早对模块组合进行了集成测试。非增量测试，到了最后阶段模块之间才能相互看见。
3，使用增量测试，调试更容易些。因为发生了错误很可能与最近添加的模块有关。
4，增量测试将测试进行得更彻底。因为增量测试使用先前测试过的模块，取代了非增量测试使用的驱动模块或桩模块。因为，到最后一个模块测试完成时，实际的模块经受到了更多的检验。
所以增量测试比非增量测试好一些。

3.自顶向下和自底向上测试

自顶向下和自底向上测试都是增量测试

3.1.自顶向下测试

自顶向下的测试是从程序的顶部或初始模块开始。挑选哪个后续模块进行增量没有唯一，原则是：要成为符合条件的下一个模块，至少一个该模块的从属模块（调用它的模块）事先经过了测试。

3.2.自底向上测试

在大多数情况下，自底向上的策略与自顶向下的策略是相对立的；自顶向下测试的优点成为自底向上测试的缺点，而自顶向下测试的缺点又成为自底向上测试的优点。
自底向上的策略开始于程序中的终端模块（此类模块不再调用其他任何模块）。测试完这些模块之后，同样没有最佳的方法来挑选要进行增量测试的下一个模块；原则是，要成为合乎条件的下一个模块，该模块所有的从属模块（它调用的模块）都已经事先经过了测试。

3.3.比较

自顶向下测试

优点：
    1，如果主要的缺陷发生在程序的顶层将非常有利
    2，一旦引入I/O功能，提交测试用例会更容易
    3，早期的程序框架可以进行演示，并可激发积极性
缺点：
    1，必须开发桩模块
    2，桩模块要比最初表现的更复杂
    3，在引入I/O功能之前，向桩模块中引入测试用例比较困难
    4，创建测试环境可能很难，甚至无法实现
    5，观察测试输出很困难
    6，使人误解设计和测试可以交迭进行
    7，会导致特定模块测试的完成延后

自底向上测试

优点：
    1，如果主要的缺陷发生在程序的低层将非常有利
    2，测试环境比较容易建立
    3，观察测试输出比较容易
缺点：
    1，必须开发驱动模块
    2，直到最后一个模块添加进去，程序才形成一个整体