单元测试集中检测软件设计的最小单元——模块。通常单元测试和编码属于软件过程的同一个阶段。在编写出源程序代码并通过了编译程序的语法检查之后,就可以用详细设计描述作指南,对重要的执行通路进行测试,以便发现模块内部的错误。可以应用人工测试和计算机测试这样两种不同类型的测试方法,完成单元测试工作。这两种测试方法各有所长,互相补充。通常,单元测试主要使用白盒测试技术,而且对多个模块的测试可以并行地进行。
在单元测试期间着重从下述5个方面对模块进行测试。
1.模块接口
首先应该对通过模块接口的数据流进行测试,如果数据不能正确地进出,所有其他测试都是不切实际的。
在对模块接口进行测试时主要检查下述几个方面:参数的数目、次序、属性或单位系统与变元是否一致;是否修改了只作输入用的变元;全局变量的定义和用法在各个模块中是否一致。
2.局部数据结构
对于模块来说,局部数据结构是常见的错误来源。应该仔细设计测试方案,以便发现局部数据说明、初始化、默认值等方面的错误。
3.重要的执行通路
由于通常不可能进行穷尽测试,因此,在单元测试期间选择最有代表性、最可能发现错误的执行通路进行测试就是十分关键的。应该设计测试方案用来发现由于错误的计算、不正确的比较或不适当的控制流而造成的错误。
4.出错处理通路
好的设计应该能预见出现错误的条件,并且设置适当的处理错误的通路,以便在真的出现错误时执行相应的出错处理通路或干净地结束处理。不仅应该在程序中包含出错处理通路,而且应该认真测试这种通路。当评价出错处理通路时,应该着重测试下述一些可能发生的错误。
(1)对错误的描述是难以理解的。
(2)记下的错误与实际遇到的错误不同。
(3)在对错误进行处理之前错误条件己经引起系统干预
(4)对错误的处理不正确。
(5)描述错误的信息不足以帮助确定造成错误的位置。
5.边界条件
边界测试是单元测试中最后的也可能是最重要的任务。软件常常在它的边界上失效,例如,处理n元数组的第n个元素时,或做到i次循环中的第i重复时,往往会发生错误。使用刚好小于、刚好等于和刚好大于最大值或最小值的数据结构、控制量和数据值的测试方案,非常可能发现软件中的错误。
人工测试源程序可以由编写者本人非正式地进行,也可以由审查小组正式进行。后者称为代码审查,它是一种非常有效的程序验证技术,对于典型的程序来说,可以查出30%-70%的逻辑设计错误和编码错误。审查小组最好由下述4人组成。
(1)组长,应该是一个很有能力的程序员,而且没有直接参与这项工程。
(2)程序的设计者。
(3)程序的编写者。
(4)程序的测试者。
如果一个人既是程序的设计者又是编写者,或既是编写者又是测试者,则审查小组中应该再增加一个程序员。
审查之前,小组成员应该先研究设计说明书,力求理解这个设计。为了帮助理解,可以先由设计者扼要地介绍他的设计。在审查会上由程序的编写者解释他是怎样用程序代码实现这个设计的,通常是逐个语句地讲述程序的逻辑,小组其他成员仔细倾听他的讲解,并力图发现其中的错误。审查会上进行的另外一项工作,是对照类似于上一小节中介绍的程序设计常见错误清单,分析审查这个程序。当发现错误时由组长记录下来,审查会继续进行(审查小组的任务是发现错误而不是改正错误)。
审查会还有另外一种常见的进行方法,称为预排:由一个人扮演“测试者”,其他人扮演“计算机”。会前测试者准备好测试方案,会上由扮演计算机的成员模拟计算机执行被测试的程序。当然,由于人执行程序速度极慢,因此测试数据必须简单,测试方案的数目也不能过多。但是,测试方案本身并不十分关键,它只起一种促进思考引起讨论的作用。在大多数情况下,通过向程序员提出关于他的程序的逻辑和他编写程序时所做的假设的疑问,可以 发现的错误比由测试方案直接发现的错误还多。
代码审查比计算机测试优越的是:一次审查会上可以发现许多错误;用计算机测试的方法发现错误之后,通常需要先改正这个错误才能继续测试,因此错误是一个一个地发现并改正的。也就是说,采用代码审查的方法可以减少系统验证的总工作量。
实践表明,对于查找某些类型的错误来说,人工测试比计算机测试更有效;对于其他类型的错误来说则刚好相反。因此,人工测试和计算机测试是互相补充,相辅相成的,缺少其中任何一种方法都会使查找错误的效率降低。
模块并小是一个独立的程序,因此必须为每个单元测试开发驱动软件和(或)存根软件。通常驱动程序也就是一个“主程序”,它接收测试数据,把这些数据传送给被测试的模块,并且印出有关的结果。存根程序代替被测试的模块所调用的模块。因此存根程序也可以称为“虚拟子程序”。它使用被它代替的模块的接口,可能做最少量的数据操作,印出对入口的检验或操作结果,并且把控制归还给调用它的模块。
例如,图6.2是一个正文加工系统的部分层次图,假定要测试其中编号为3.0的关键模块——正文编辑模块。因为正文编辑模块不是一个独立的程序,所以需要有一个测试驱动程序来调用它。这个驱动程序说明必要的变量,接收测试数据——字符串,并且设置正文编辑模块的编辑功能。因为在原来的软件结构中,正文编辑模块通过调用它的下层模块来完成具体的编辑功能,所以需要有存根程序简化地模拟这些下层模块。为了简单起见,测试时可以设置的编辑功能只有修改(CHANGE)和添加(APPEND)两种,用控制变量CFUNCT标记要求的编辑功能,而且只用一个存根程序模拟正文编辑模块的所有下层模块。下面是用伪码书写的存根程序和驱动程序。
图6.2 正文加工系统的层次图
I.TEST STUB(*测试正文编辑模块用的存根程序*)
初始化;
输出信息“进入了正文编辑程序”;
输出“输入的控制信息是”CFUNCT;
输出缓冲区中的宇符串;
IF CFUNCT=CHANGE
THEN
把缓冲区中第二个字改为***
ELSE
在缓冲区的尾部加???
END IF;
输出缓冲区中的新字符串;
END TEST STUB
II.TEST DRIVER(*测试正文编辑模块用的驱动程序*)
说明长度为2500个字符的一个缓冲区;
把CFUNCT置为希望测试的状态;
输入字符串;
调用正文编辑模块;
停止或再次初启;
输出缓冲区中的新字符串;
END TEST STUB
驱动程序和存根程序代表开销,也就是说,为了进行单元测试必须编写测试软件,但是通常并不把它们作为软件产品的一部分交给用户。许多模块不能用简单的测试软件充分测试,为了减少开销可以使用下节将要介绍的渐增式测试方法,在集成测试的过程中同时完成对模块的详尽测试。
模块的内聚程度高可以简化单元测试过程。如果每个模块只完成一种功能,则需要的测试方案数目将明显减少,模块中的错误也更容易预测和发现。