白盒测试技术-单元测试理论篇

白盒测试技术-单元测试理论篇

作者：张元礼
http://blog.csdn.net/vincetest

 

2.1 单元测试概念

• 单元测试：单元测试又称模块测试，属于白盒测试，是最小单位的测试。模块分为程序模块和功能模块。功能模块指实现了一个完整功能的模块（单元），一个完整的程序单元具备输入、加工和输出三个环节。而且每个程序单元都应该有正规的规格说明，使之对其输入、加工和输出的关系做出明确的描述。
• 测试驱动：驱动被测试模块正常运行起来的实体
• 测试桩：代替被测模块调用的子模块的实体，该实体一般为桩函数。
• 测试覆盖：评测测试过程中已经执行的代码的多少。

覆盖率：代码的覆盖程度，一种度量方式。针对代码的测试覆盖率有许多种度量方式，定义如下：

1、语句覆盖（StatementCoverage）:它度量每一个可执行语句是否被执行到了。
void  DoWork(int x,int y,int z)
{  【文章来源：张元礼的博客 http://blog.csdn.net/vincetest】
   int  k=0,j=0;
   if((x>3)&&(z<10))
   {      
       k=x*y-1;     //语句块1
       j=sqrt(k);
   }
   if((x= =4)||(y>5))
   {      
       j=x*y+10;   //语句块2
   }
       j=j%3;      //语句块3
}

2、判定覆盖（DecisionCoverage）：它度量是否每个BOOL型的表达式取值true和false在控制结构中都被测试到了。

if(a)   //当a取true和false
{
    ...
}
else
{
    ...
}

 

3、条件覆盖（ConDItionCoverage）：它独立的度量每一个子表达式，报告每一个子表达式的结果的true或false。这个度量和判定覆盖（decisioncoverage）相似，但是对控制流更敏感。不过，完全的条件覆盖并不能保证完全的判定覆盖。

if(a>b&&c>d) 【文章来源：张元礼的博客 http://blog.csdn.net/vincetest】
{
    ...
} 
例子中a>b和c>d为2个不同的条件表达式，与if()判断独立。

 

4、路径覆盖（PathCoverage）：它度量了是否函数的每一个可能的分支都被执行了。路径覆盖的一个好处是：需要彻底的测试。但有两个缺点：一是，路径是以分支的指数级别增加的，例如：一个函数包含10个IF语句，就有1024个路径要测试。如果加入一个IF语句，路径数就达到2048；二是，许多路径不可能与执行的数据无关。

如下图具有的路径有：abd、abe、acd、ace

 

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

for（i=0;i>Max;i++）
{
    ...
}

while（a）
{
    ...
}

do
{
    ...
}
while(a)

• 测试环境构成

1、驱动模块（Driver）：所测模块的主程序。它接收测试数据，把这些数据传递给所测试模块，最后再输出测试结果。当被测试模块能完成一定功能时，也可以不要驱动模块。【文章来源：张元礼的博客 http://blog.csdn.net/vincetest】

2、桩模块（Stub）：用来代替所测模块调用的子模块。

 

2.2 单元测试内容

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

一、模块接口：测试模块的数据流。如果数据不能正确地输入和输出，就谈不上进行其他测试。因此，对于模块接口需要如下的测试项目：
1、调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；

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

3、是否修改了只做输入用的形式参数；

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

5、全局变量的定义在各模块中是否一致；

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

二、局部数据结构测试：模块的局部数据结构是最常见的错误来源，应设计测试用例以检查以下各种错误：
1、检查不正确或不一致的数据类型说明；

2、使用尚未赋值或尚未初始化的变量；

3、错误的初始值或错误的默认值；

4、变量名拼写错误或书写错误；

5、不一致的数据类型。

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

1、常见的不正确的计算有：
1）运算的优先次序不正确或误解了运算的优先次序；
2）运算的方式错误（运算的对象彼此在类型上不相容）；
3）算法错误；【文章来源：张元礼的博客 http://blog.csdn.net/vincetest】
4）初始化不正确；
5）运算精度不够；
6）表达式的符号表示不正确等。

 

一个案例：火箭爆炸

1996年6月4日欧洲阿丽亚娜系列火箭Ariane-5 发射后仅仅37秒，火箭偏离它的飞行路径，解体并爆炸。火箭上载有价值5亿美元的通信卫星，6亿美元付之一炬。【文章来源：张元礼的博客 http://blog.csdn.net/vincetest】

原因：将一个64位浮点数转换成16位有符号整数时，产生了溢出。

 

2、常见的比较和控制流错误有：
1）不同数据类型的比较；
2）不正确的逻辑运算符或优先次序；
3）因浮点运算精度问题而造成的两值比较不等；
4）关系表达式中不正确的变量和比较符；
5）“差1错”，即不正确地多循环或少循环一次；
6）错误的或不可能的循环终止条件；
7）当遇到发散的迭代时不能终止循环；
8）不适当地修改了循环变量等。

 

四、错误处理测试：比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理对策，以便在程序出错时，能对出错程序重新做安排，保证其逻辑上的正确性。这种出错处理也是模块功能的一部分。表明出错处理模块有错误或缺陷的情况有：
1、出错的描述难以理解；
2、出错的描述不足以对错误定位和确定出错的原因；
3、显示的错误与实际的错误不符；
4、对错误条件的处理不正确；
5、在对错误进行处理之前，错误条件已经引起系统的干预；
6、如果出错情况不予考虑，那么检查恢复正常后模块可否正常工作。

 

五、边界测试：边界上出现错误上常见的。设计测试用例检查：
1、在n次循环的第0次、1次、n次是否有错误；
2、运算或判断中取最大最小值时是否有错误；
3、数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误。
 

2.3 走出测试误区【文章来源：张元礼的博客 http://blog.csdn.net/vincetest】

误区一：完全依赖于测试工具
误区二：追求测试环境的真实性
误区三：盲目提高覆盖率
误区四：单元测试太耗时间，不值得一做
误区五：个人能力强的不必做白盒测试
误区六：单元测试仅证明该怎么跑的代码是这样跑了
你有这些想法么？

 

相关文章：

白盒测试技术-白盒测试理论篇

白盒测试技术-方法与实践篇

欢迎转载此文，转载时请注明文章来源：张元礼的博客 http://blog.csdn.net/vincetest