是大型程序测试的第一个步骤【大型程序即超过500条语句的程序】
了解
模块测试是对程序中的单个程序、子程序/过程进行测试的过程【并非对整个程序】：
- 关注点在较小单元，是一种管理组合的测试元素的手段
- 减轻调试的难度，把错误定位到一个小范围
- 可同时测试多个模块，将并行工程引入软件测试
模块测试的目的在于将模块的功能与定义模块的功能规格说明或接口规格说明进行比较。揭示出模块与规格说明的矛盾
测试用例的设计
首先需要模块的规格说明与模块源代码
模块测试总体面向白盒测试【若对大的程序测试，不容易展开，也便于在后续测试中专心于其他类型的错误】
—>测试用例设计：使用一种或多种白盒测试方法分析模块的逻辑结构，然后用黑盒测试方法对照模块规格说明补充测试用例
黑盒方法：黑盒
白盒方法：
- 语句覆盖
每条语句都执行一次，过于粗超没啥用 - 判定覆盖
每条分支路径都至少执行一次(eg:if…else,switch等
判定覆盖通常满足语句覆盖 - 条件覆盖
将一个判断中的每个条件的所有可能结果至少执行一次 - 判定/条件覆盖
将一个判断中的每个条件的所有可能的结果至少执行一次，将每个判断的所有可能结果至少执行一次，将每个入口点至少调一次 - 多种条件覆盖
将每个判定中的所有可能的条件结果的组合，及所有的入口点都至少执行一次
增量测试
模块测试中主要考虑两点：
- 设计测试用例集
- 将模块组装成工作程序的方式----->涉及到测试用例编写形式、测试工具类型、模块编码、测试的顺序、生成测试用力的成本及调试的成本
这里思考：是否应该先独立测试每个模块，再组装成完整程序；或先把下一步要测试的模块组装到测试完毕的模块集合中再进行测试。第一种称为非增量测试或崩溃测试；第二种称为增量测试或集成
比如现在一程序有六个模块【子程序/过程】，分别以增量/非增量分析：
非增量：每一模块单独进行模块测试根据环境和参与人数，这些模块能同时/按次序进行测试，最后组装【集成】为完整程序
环境：如人机交互、使用批处理计算工具
测试单独一模块需要一个特殊的驱动模块和一个或多个桩模块。如测试B模块，发现在模块B中调用了模块E，就需要一个额外组件，在B调用E时接受B的控制指令。这由桩模块完成【命名为E的特殊模块，模拟完成E的功能】
驱动模块：人为编写的小模块，可将测试用例驱动或者传输到被测模块中【可以用测试工具代替】，最后显示测试模块的结果
增量：将下一步要测的模块先组装到前面测试过的集合。增量方法很多，这里从底部开始
- 测试E、C、F，可并行，可串行，需要为每一模块准备驱动模块
- 测试B、D，分别将其与E、F组合起来
将下一个要测试的模块组装到前面已经测试过的模块集合中
分析：
- 非增量测试工作量更大
对于上面程序，需要准备5个驱动模块和5个桩模块(假设顶部的模块不需要驱动模块)
自底向上的增量测试需要5个驱动模块,但不需要桩模块
自顶向下的增量测试需要5个桩模块,但不需要驱动模块 - 增量测试，可较早发现模块中不匹配接口、不正确假设相关的编程错误
由于尽早地对模块组合进行了集成测试；而采用非增量测试，只有到了测试过程的最后阶段，模块之间才能“互相看到” - 增量测试，调试更容易
假定存在与模块间接口或假设相关的编程错误，那么，如果使用非增量测试，直到整个程序组装之后，这些错误才会浮现出来。到了这个时候，我们就难以定位错误，因为它可能存在于程序内部的任何位置；相反，如果使用增量测试，这种类型的错误就很容易发现，因为该错误很可能与最近添加的模块有关 - 增量测试将测试进行得更彻底
如果当前正在测试模块B,要么是模块E,要么是模块A(取决干测试是从底部还是从顶部开始的)被当作结果而执行。虽然模块E或模块A先前已经进行了完全的测试，但将其作为B的模块测试结果而执行，则会诱发出-一个新的情况，可能会暴露出先前测试过模块中存在的新缺陷。另一方面，如果使用的是非增量测试，对模块B的测试仅影响到其本身。换言之，增量测试使用先前测试过的模块，取代了非增量测试中使用的桩模块或驱动模块。因此，到最后一模块测试完成时，实际的模块经受到了更多的检验 - 非增量测试所占用的机器时间显得少一些
如果使用自底向上的方法测试A，在执行A的过程中，模块B、C、D、E和F也会执行到。而在对模块A的非增量测试中，仅会执行模块B、C和E的桩模块。因此，完成一次增量测试所需执行的机器指令，显然多于采用非增量测试方法所需的指令。但此消彼长的是，非增量测试要比增量测试需要更多的驱动模块和桩模块，开发这些驱动模块和桩模块是要占用机器时间的 - 模块测试阶段开始时，如果使用的是非增量测试，就会有更多的机会进行并行操作
所有的模块可以同时测试，对于大型的软件项目(模块和人员都很多)，这可能十分重要，因为在模块测试开始之时，项目的人员数量常常处于最高峰
执行测试
当测试用例造成模块输出的实际结果与预期结果不匹配的情况时，存在两个可能的解释:
- 该模块存在错误
- 预期的结果不正确(测试用例不正确)
为将这种混乱降低到最小程度，应在测试执行之前对测试用例集进行审核或检查(也就是说，应对测试用例进行翻试)
在执行测试时，应该查找程序的副作用( 即模块执行了某些不该执行操作的情况)。一般情况下，这些情况都是很难发现的，但如果在测试用例执行完之后，检查那些不应有变动的模块输人，可能会发现一些错误实例
如果发现某一部分模块存在大量错误，那么很有可能这些模块甚至包含着更多的错误，只是尚未检查出来而已。这样的模块应该进行更进一·步的测试，可能还需要进行额外的代码走查或检查。最后，记住模块测试的目的不是证明模块能够正确地运行，而是证明模块中存在着错误
