上一篇文章针对软件的人工测试做了简单的讲解，本次内容主要是分享构建大型程序测试的额第一个步骤：模块测试，也叫做单元测试。
顾名思义，模块测试是对程序中的单个子程序、子程序或过程进行测试的过程。之所以详见注意力集中在小模块的测试上，主要有三个原因，首先，模块测试是一种管理组合的测试元素手段。其次，模块测试减轻了调试的难度。再次，模块测试为同时测试多个模块提供了可能，这将并行工程引入软件测试中。
下面，主要从三个方面来讨论模块测试：
1. 测试用例的设计方式
模块测试中测试用例的设计过程如下，使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。
无论采用哪一种逻辑覆盖方法，第一步都是要列举出程序中所有的条件判断。如对象中所有的IF和DO语句。得到数量较少的判断后，我们可能会选择多重条件覆盖，但应该检查所有的逻辑覆盖准则，看他们的效果如何。例如，我们需要设计充足的测试用例来触发上面的判断并输出结果。实际上，任何逻辑覆盖准则尚不足以胜任为生成模块测试用例的唯一手段，因此，后面还需要用一组黑盒测试用例来补充上面缺失的测试用例。
2. 模块测试及集成的顺序
上一节是讨论如何设计一个有效的测试用例集，那么作为模块测试环节中，模块组装成工作程序的方式也很重要。可以将它分成两类，增量测试和非增量测试。
简言之，非增量测试是指软件测试线单独地测试每个模块，然后在将这些模块组装成完整的测试。增量测试是先将下一步要测试的模块先组装到测试完成的模块集合中。
正常进行测试时，非增量测试所需的工作量要多一些，而所占用机器的时间显得少一些，并且会有更多的机会进行并行操作，对大型软件来讲，十分重要。
如果使用增量测试，可以较早的发现模块中与不匹配的借口，不正确假设相关的编程错误，因此，调试进行的容易一些。增量模式使用先前测试过的模块，取代了非增量测试中使用的桩模块或驱动模块，因此测试会更加彻底。
从计算机行业趋势、人工劳动成本，综合上面的优缺点，增量测试要更好一些。
3. 对执行模块测试的建议
当测试用例造成模块输出的实际结果与预期结果不匹配时，要么该模块存在错误，要么预期的结果不正确。为了降低这种混乱，应在测试执行之前对测试用例集中进行审核或检查。其中流程分析工具可以列举出程序中的路径、找出从未被执行的语句。
小结
单元测试是开发者编写可靠程序的重要技术，尤其是那些面向对象语言的开发者。单元测试是大规模的白盒测试，但这只不过是刚刚开了一个头，后面还讨论更高级别的测试。
