单元测试由一组独立的测试构成，每个测试针对软件中的一个单独的程序单元。单元测试并非检查程序单元之间是否能够合作良好，而是检查单个程序单元行为是否正确。

在单元测试时，测试人员根据详细设计说明书和源程序清单，了解到该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理和不合理的输入都要能鉴别和响应。这要求对程序所有的局部和全局的数据结构、外部接口和程序代码的关键部分进行桌面检查和代码审查。

在单元测试中进行的测试工作主要在5个方面对被测模块进行检查：

1. 模块接口测试

在单元测试开始时，应该对通过所有被测模块的数据流进行测试。如果数据不能正常地输入及输出，那么其他的全部测试都说明不了问题。Myers在关于软件测试的书中为接口测试提出了一个检查表：

    模块输入参数的数目是否与模块形式参数数目相同。
    模块各输入的参数属性与对应的形参属性是否一致。
    模块各输入的参数类型与对应的形参类型是否一致。
    传到被调用模块的实参的数目是否与被调用模块形参的数目相同。
    传到被调用模块的实参的属性是否与被调用模块形参的属性相同。
    传到被调用模块的实参的类型是否与被调用模块形参的类型相同。
    引用内部函数时，实参的次序和数目是否正确。
    是否引用了与当前入口无关的参数。
    用于输入的变量有没有改变。
    在经过不同模块时，全局变量的定义是否一致。
    限制条件是否以形参的形式传递。
    使用外部资源时，是否检查可用性并及时释放资源，如内存、文件、硬盘、端口等。

当模块通过外部设备进行输入/输出操作时，必须扩展接口测试，附加如下的测试项目：

    文件的属性是否正确。
    Open与Close语句是否正确。
    规定的格式是否与I/O语句相符。
    缓冲区的大小与记录的大小是否相配合。
    在使用文件前，文件是否打开。
    文件结束的条件是否安排好了。
    I/O错误是否检查并做了处理。
    在输出信息中是否有文字错误。

2. 局部数据结构测试

模块的局部数据结构是常见的错误来源，应设计测试用例以检查以下各种错误：

    不正确或不一致的数据类型说明。
    使用尚未赋值或尚未初始化的变量。
    错误的初始值或错误的默认值。
    变量名拼写错或书写错—— 使用了外部变量或函数。
    不一致的数据类型。
    全局数据对模块的影响。
    数组越界。
    非法指针。

3. 路径测试

检查由于计算错误、判定错误、控制流错误导致的程序错误。由于在测试时不可能做到穷举测试，所以在单元测试时要根据“白盒”测试和“黑盒”测试用例设计方法设计测试用例，对模块中重要的执行路径进行测试。重要的执行路径指那些处在完成单元功能的算法、控制、数据处理等重要位置的执行路径，也指由于控制较复杂而易错的路径，有选择地对执行路径进行测试是一项重要的任务。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误，对基本执行路径和循环进行测试可发现大量的路径错误。

在路径测试中，要检查的错误有：死代码，错误的计算优先级，算法错误，混用不同类的操作，初始化不正确，精度错误—— 比较运算错误、赋值错误，表达式的不正确符号—— >、>=；=、==、！=，循环变量的使用错误—— 错误赋值以及其他错误等。

比较操作和控制流向紧密相关，测试用例设计需要注意发现比较操作的错误：

    不同数据类型的比较。
    不正确的逻辑运算符或优先次序。
    因浮点运算精度问题而造成的两值比较不等。
    关系表达式中不正确的变量和比较符。
    “差 1 错”，即不正常的或不存在的循环中的条件。
    当遇到发散的循环时无法跳出循环。
    当遇到发散的迭代时不能终止循环。
    错误的修改循环变量。

4. 错误处理测试

错误处理路径是可能引发错误处理的路径及进行错误处理的路径，错误出现时错误处理程序重新安排执行路线，或通知用户处理，或干脆停止执行使程序进入一种安全等待状态。测试人员应意识到，每一行程序代码都可能执行到，不能自己认为错误发生的概率很小而不去进行测试。一般软件错误处理测试应考虑下面几种可能的错误：

    出错的描述是否难以理解，是否能够对错误定位。
    显示的错误与实际的错误是否相符；
    对错误条件的处理正确与否；
    在对错误进行处理之前，错误条件是否已经引起系统的干预等。

在进行错误处理测试时，要检查如下内容：

    在资源使用前后或其他模块使用前后，程序是否进行错误出现检查。
    出现错误后，是否可以进行错误处理，如引发错误、通知用户、进行记录。
    在系统干预前，错误处理是否有效，报告和记录的错误是否真实详细。

5. 边界测试

边界测试是单元测试中后的任务。软件常常在边界上出错，例如，在一个程序段中有一个n次循环，当到达第n次循环时可能会出错；或者在一个有n个元素的数组中，第n个元素时是很容易出错的。因此，要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。

此外，如果对模块性能有要求的话，还要专门进行关键路径测试，以确定坏情况下和平均意义下影响运行时间的因素。下面是边界测试的具体要检查的内容：

    普通合法数据是否正确处理。
    普通非法数据是否正确处理。
    边界内接近边界的（合法）数据是否正确处理。
    边界外接近边界的（非法）数据是否正确处理等。
    在n次循环的第0次、第1次、第n次是否有错误。
    运算或判断中取大小值时是否有错误；
    数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误。

为了使单元测试能充分细致地展开，应在实施单元测试中遵守下述要求：

1）语句覆盖达到。

语句覆盖指被测单元中每条可执行语句都被测试用例所覆盖。语句覆盖是强度低的覆盖要求，要考虑语句覆盖的意义，只要想象一下用一段从没执行过的程序控制庞大的飞行器升上天空，然后设法使它精确入轨，这种轻率简直是荒唐。实际测试中，不一定能做到每条语句都执行到。第一，存在“死码”，即由于程序设计错误在任何情况下都不可能执行到的代码。第二，不是“死码”，但是由于要求的测试输入及条件非常难达到或单元测试的条件所限，使得代码没有得到运行。因此，在可执行语句未得到执行时，要深入程序作详细的分析。如果是属于以上两种情况，则可以认为完成了覆盖，但是对于后者，如果可能一定要尽量测试到，如果以上两者都不是，则是因为测试用例设计不充分，需要再设计测试用例。

2）分支覆盖达到。

分支覆盖指分支语句取真值和取假值各一次，分支语句是程序控制流的重要处理语句，在不同流向上测试可以验证这些控制流向的正确性。分支覆盖使这些分支产生的输出都得到验证，提高测试的充分性。

3）覆盖错误处理路径。

4）单元的软件特性覆盖。

软件的特性包括功能、性能、属性、设计约束、状态数目、分支的行数等。

5）对试用额定数据值、奇异数据值和边界值的计算进行检验，用假想的数据类型和数据值运行，测试排斥不规则输入的能力。

单元测试通常是由编写程序的人自己完成的，但是项目负责人应当关心测试的结果。所有的测试用例和测试结果都是模块开发的重要资料，需妥善保存。