模块测试（单元测试）是对程序中的单个子程序，子程序或过程进行测试的过程。也就是说，一开始并不是对整个程序进行测试，而是首先将注意力集中在对构成程序的较小模块的测试上面。这样做的动机有三个：
第一，由于模块测试的注意力一开始集中在程序的较小单元上，因此它是一种管理组合的测试元素的手段。
第二，模块测试减轻了调试的难度。
第三，模块测试通过为我们提供同时测试多个模块的可能，将并行工程引入软件测试中。
模块测试的目的是将模块的功能预定义模块的功能规格说明或接口规格说明进行比较。
这里的测试目标不是为了说明符合规格说明，而是为了说明模块与规格说明存在矛盾。
1.1测试用例设计
在为模块测试设计的测试用例时，需要使用两种类型的信息：模块的规格说明和模块的源代码。规格说明一般都规定了模块的输入和输出参数以及模块的功能。
模块测试总体上是面向白盒测试的。其中一个原因是如果对大一点的软件进行测试，例如，一个完整的程序，白盒测试不容易展开。第二个原因是，后续的测试过程局限于发现其他类型的错误。因此，模块测试的测试用例的设计过程如下：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。
1.2增量测试
在执行模块测试的过程中，主要有两点考虑：第一，如何设计一个有效的测试用例集；第二，将模块组装成工作程序的方式。
增量测试：先将下一步要测试的模块组装到测试完成的模块集合中，然后再进行测试。
下面是几个显而易见的结论：
1，非增量测试所需的工作量要多一些。
2，如果使用了增量测试，可以较早地发现模块中与不匹配接口，不正确假设相关的编程错误。
3，如果使用了增量测试，调试会进行得容易一些。
4，增量测试会将测试进行得更彻底。
5，非增量测试所占用的机器时间显得少一些。
6，模块测试阶段开始时，如果使用的是非增量测试，就会有更多的机会进行并行操作。
总的来说，第1~4条结论是增量测试的优点，第5，6条结论是其不利之处。
1.3自顶向下测试与自底向上测试
1.3.1自顶向下的测试
自顶向下的测试是从程序的顶部或初始模块开始。测试开始之后，挑选哪一个后续模块进行增量测试没有惟一正确的方法，惟一的原则是：要成为合乎条件的下一个模块，至少一个该模块的从属模块实现经过了测试。
如果可以进行并行测试，可有其他的选择，总的来说，不存在最佳的模块序列，但却有下面可供考虑的两项指南：
1，如果程序中存在关键部分，那么在设计模块序列时就应将这些关键模块金可能早地添加进去。所谓“关键部分”可能是某个复杂的模块，某个采用新算法的模块或某个被怀疑容易发生错误的模块。
2，在设计模块序列时，应将I/O模块尽可能地添加进来。
1.3.2自底向上的测试
自底向上的策略开始于程序中的终端模块（此类模块不再调用其他任何模块）。测试完这些模块之后，没有最佳的方法来挑选要进行增量测试的下一个模块，惟一的原则是：要成为合乎条件的下一个模块，该模块的所有从属模块都已经事先经过了测试。自底向上策略的一个不足是，它没有早期程序框架的概念。
1.3.3比较
自顶向下测试与自底向上测试的比较
自顶向下 |
测试 |
优点 |
缺点 |
1，如果主要的缺陷发生在程序的顶层将非常有利 |
1，必须开发桩模块 |
2，一旦引入I/O功能提交测试用例会更容易 |
2，桩模块要比最初表现的更复杂 |
3，早期的程序框架可以进行演示，并可激发积极性 |
3，再引入I/O功能之前，向桩模块中引入测试用例比较困难 |
4，创建测试环境可能很难，甚至无法实现。 |
|
5，观察测试输出很困难 |
|
6，使人误解设计和测试可以交迭进行 |
|
7，会导致特定模块测试的完成延后 |
自底向上 |
测试 |
优点 |
缺点 |
1，如果主要的缺陷发生在程序的顶层将非常有利 |
1，必须开发驱动模块 |
2，测试环境比较容易建立 |
2，直到最后一个模块添加进去，程序才形成一个整体 |
3，观察测试输出比较容易 |
1.4执行测试
当测试用例造成模块输出的实际结果与预期结果不匹配的情况时，存在两个可能的解释：
要么该模块存在错误，要么预期的结果不正确（测试用例不正确）。为了将这种混乱降低到最小程度。应在测试执行之前对测试用例集进行审核或检查（也就是说，应对测试用例进行测试）。
使用自动化测试工具可以试测试过程中的枯燥劳动减至最小。在执行测试时，应该查找程序的副作用（即模块执行了某些不该执行的操作情况）。一般情况下，这些情况都是很难发现的，但如果在测试用例执行完之后，检查那些不应有变动的模块输入，可能会发现一些错误实例。
因个人试图测试自己编写的程序所带来的心理学问题，也适用于模块测试。程序员不应测试自己编写的模块，而应交换模块进行测试，编写调用模块的程序员始终是测试被调用模块的最佳候选人。注意，这仅仅适用于测试，对模块的调试一般应当由编程人员本人进行。应避免随意丢弃测试用例，应将它们按某种格式记录下来，以便将来可以重新使用它们。最后，记住模块测试的目的不是证明模块能够正确地运行，而是证明模块中存在着错误。