UML软件工程组织

 

 

单元测试的基本理论
 
 作者:不详  来源:http://www.csai.cn
 

基本概念

单元测试:单元测试又称模块测试,属于白盒测试,是最小单位的测试。模块分为程序模块和功能模块。功能模块指实现了一个完整功能的模块(单元),一个完整的程序单元具备输入、加工和输出三个环节。而且每个程序单元都应该有正规的规格说明,使之对其输入、加工和输出的关系做出名明确的描述。

测试驱动:驱动被测试模块正常运行起来的实体

测试桩:代替被测模块调用的子模块的实体,该实体一般为桩函数。

测试覆盖:评测测试过程中已经执行的代码的多少。

覆盖率:代码的覆盖程度,一种度量方式。针对代码的测试覆盖率有许多种度量方式,定义如下:
语句覆盖(StatementCoverage):也称为行覆盖(linEC),段覆盖(segmentcoverage)和基本块覆盖(bAS)。它度量每一个可执行语句是否被执行到了。icblockcoverageoverage
判定覆盖(DecisionCoverage):也被称为分支覆盖(branchcoverage),所有边界覆盖(all-edgescoverage),基本路径覆盖(basispathcoverage),判定路径覆盖(decision-decision-path或DDPtesting)。它度量是否每个BOO型的表达式取值true和false在控制结构中都被测试到了。

条件覆盖(ConDI):它独立的度量每一个子表达式,报告每一个子表达式的结果的true或false。这个度量和判定覆盖(decisioncoverage)相似,但是对控制流更敏感。不过,完全的条件覆盖并不能保证完全的判定覆盖。tionCoverage

路径覆盖(PathCoverage):也称为断言覆盖(prEDI),它度量了是否函数的每一个可能的分支都被执行了。路径覆盖的一个好处是:需要彻底的测试。但有两个缺点:一是,路径是以分支的指数级别增加的,例如:一个函数包含10个IF语句,就有1024个路径要测试。如果加入一个IF语句,路径数就达到2048;二是,许多路径不可能与执行的数据无关。catecoverage

循环覆盖(LOOP):这个度量报告你是否执行了每个循环体零次、只有一次还是多余一次(连续地)。对于do-while循环,循环覆盖报告你是否执行了每个循环体只有一次还是多余一次(连续地)。这个度量的有价值的方面是确定是否对于while循环和for循环执行了多于一次,这个信息在其它的覆盖率报告中是没有的。

测试的内容

单元测试的对象是软件设计的最小单位——模块或函数,单元测试的依据是详细设描述。测试者要根据详细设计说明书和源程序清单,了解模块的I/O条件和模块的逻辑结构。主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理和不合理的输入都能鉴别和响应。要求对所有的局部和全局的数据结构、外部接口和程序代码的关键部分进行桌面检查和代码审查。在单元测试中,需要对下面5个方面的内容进行测试,也是构造测试用例的基础。


 模块接口:测试模块的数据流。如果数据不能正确地输入和输出,就谈不上进行其他测试。因此,对于模块接口需要如下的测试项目:

·调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配;

·所测模块调用子模块时,它输入个子模块的参数与子模块的形式参数在个数、属性、顺序上是否匹配;

·是否修改了只做输入用的形式参数;

·输出给标准函数的参数在个数、属性、顺序上是否匹配;

·全局变量的定义在各模块中是否一致;

·限制是否通过形式参数来传送。

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

·检查不正确或不一致的数据类型说明;

·使用尚未赋值或尚未初始化的变量;

·错误的初始值或错误的默认值;

·变量名拼写错误或书写错误;

·不一致的数据类型。

路径测试:对基本执行路径和循环进行测试会发现大量的错误。根据白盒测试和黑盒测试用例设计方法设计测试用例。设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
常见的不正确的计算有:

· 运算的优先次序不正确或误解了运算的优先次序;

·运算的方式错误(运算的对象彼此在类型上不相容);

· 算法错误;

· 初始化不正确;

·运算精度不够;

·表达式的符号表示不正确等。

常见的比较和控制流错误有:

·不同数据类型的比较;

·不正确的逻辑运算符或优先次序;

·因浮点运算精度问题而造成的两值比较不等;

· 关系表达式中不正确的变量和比较符;

·“差1错”,即不正确地多循环或少循环一次;

·错误的或不可能的循环终止条件;

·当遇到发散的迭代时不能终止循环;

·不适当地修改了循环变量等。

错误处理测试:比较完善的模块设计要求能预见出错的条件,并设置适当的出错处理对策,以便在程序出错时,能对出错程序重新做安排,保证其逻辑上的正确性。这种出错处理也是模块功能的一部分。表明出错处理模块有错误或缺陷的情况有:

· 出错的描述难以理解;

·出错的描述不足以对错误定位和确定出错的原因;

· 显示的错误与实际的错误不符;

·对错误条件的处理不正确;

·在对错误进行处理之前,错误条件已经引起系统的干预;

·如果出错情况不予考虑,那么检查恢复正常后模块可否正常工作。

边界测试:边界上出现错误上常见的。设计测试用例检查:

·在n次循环的第0次、1次、n次是否有错误;

· 运算或判断中取最大最小值时是否有错误;

·数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误。

测试的环境构成

何时进行单元测试?单元测试在编码阶段进行。在源程序代码编制完成、经过评审和验证、确认没有语法错误之后,就可以开始进行单元测试的测试用例设计。要利用软件设计文档,设计可以验证程序功能、找出程序错误的多个测试用例。

对于每一组输入,应该有预期的正确结果。在单元测试时,如果模块不是独立的程序,需要辅助测试模块,有两种辅助模块:

驱动模块(Driver):所测模块的主程序。它接收测试数据,把这些数据传递给所测试模块,最后再输出测试结果。当被测试模块能完成一定功能时,也可以不要驱动模块。

桩模块(Stub):用来代替所测模块调用的子模块。

被测试模块、驱动模块和桩模块共同构成了一个测试环境,如下图所示:



 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号