在软件开发过程中，单元测试和编码共属实现阶段，编码完成并编译通过后才开始进行单元测试。进行动态的单元测试前要先对程序进行静态分析和代码审查。

　　这是因为：第一，使用动态测试技术要准备测试用例，进行结果记录和分析，工作量大，发现错误太多会降低动态测试效率；第二，目前的动态测试技术局限性比较大，有相当类型的错误靠动态测试是难以发现的。因此，先使用静态分析和代码审查技术，能充分地发挥人的判断和思维优势，检查出对机器而言很难发现的错误。典型的包括代码和设计规格的一致性，代码逻辑表达式的正确性。这些检查在动态测试阶段将会是非常繁琐而又非常困难的；第三，有些错误在动态测试时是无法检查的；第四，使用代码审查技术，一旦发现错误，知道错误的性质和位置，调试代价较低；第五，使用静态分析方法一次能揭示一批错误，并且随后可以立即纠正错误。

　　由于单元测试针对程序单元，而程序单元并不是一个独立可运行的程序，因此，在考虑测试模块时，同时要考虑到它和外界其他模块的联系，用一些辅助模块去模拟与被测模块关联的其他模块。这些模块分为两种：

　　● 驱动模块。相当于所测模块的主程序。它接收测试数据，把这些测试数据传送给被测模块，后再输出实测结果。

　　● 桩模块。由被测模块调用，用以代替由被测单元所调用的模块的功能，返回适当的数据或进行适当的操作使被测单元能继续运行下去，同时还要进行一定的数据处理，如打印入口和返回等，以便检验被测模块与其下级模块的接口。

　　驱动模块和桩模块为程序单元的执行构成了一个完整的环境。如图下所示。驱动模块用以模拟被测单元的上层模块，测试执行时由驱动模块调用被测单元使其运行，桩模块模拟被测单元执行过程中所调用的模块，测试执行时桩模块使被测单元能完整闭合地运行。

　　驱动模块和桩模块在软件开发结束后不使用了，但是为了单元测试，两者都要进行开发，但是不需要与终产品以其交付用户。因此驱动模块和桩模块的设计要尽量简单，避免因其错误而干扰被测单元的运行及测试结果判断。实际上许多程序单元不能用简单的驱动模块和桩模块进行充分的单元测试，完全的测试可以放到组装测试时再进行。

　　如果一个模块要完成多种功能，可以将这个模块看成由几个小程序组成，必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。

　　在单元测试中，测试用例的设计与测试集合的准备是至关重要的。首先要构造测试用例的运行环境，即确定用例运行的前提条件，明确被测模块/单元所需的程序环境（全局变量赋值或初始化实体），启动测试驱动，设置桩，调用被测模块，设置预期输出条件判断，后恢复环境 （包括清除桩）。然后，设计黑盒测试用例，即接口测试用例。

　　第一步设计基本功能测试用例，证明被测单元至少在某种正常情况下能够运行了；

　　第二步设计功能正面测试用例，找出被测单元对于设计要求的正确输入可能做出的不正确处理；

　　第三步设计功能反面测试用例，找出被测单元对于设计要求的错误输入可能做出的不正确处理；

　　后一步设计性能测试用例，找出单元对于设计要求的性能可能做不到的错误。

　　后，设计白盒测试用例，即覆盖测试用例，找出单元内部控制结构和数据使用可能存在的问题。

　　注意，在进行白盒测试期间，不要匆忙地删除所发现的死代码或者冗余代码，因为这很可能导致错误的产生。因为在测试别人代码的时候，很可能由于测试用例不够，或者没有对被测程序整体结构的把握，而出现错误理解。