如何设计单元测试用例

如何编写单元测试用例(白盒测试)。

一、 单元测试的概念

单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常,并且返回了正确的输出。
        测试的覆盖种类
        1.语句覆盖:语句覆盖就是设计若干个测试用例,运行被测试程序,使得每一条可执行语句至少执行一次。
        2.判定覆盖(也叫分支覆盖):设计若干个测试用例,运行所测程序,使程序中每个判断的取真分支和取假分支至少执行一次。
        3.条件覆盖:设计足够的测试用例,运行所测程序,使程序中每个判断的每个条件的每个可能取值至少执行一次。
        4.判定——条件覆盖:设计足够的测试用例,运行所测程序,使程序中每个判断的每个条件的每个可能取值至少执行一次,并且每个可能的判断结果也至少执行一次。
        5.条件组合测试:设计足够的测试用例,运行所测程序,使程序中每个判断的所有条件取值组合至少执行一次。
        6.路径测试:设计足够的测试用例,运行所测程序,要覆盖程序中所有可能的路径。
        用例的设计方案主要的有下面几种:条件测试,基本路径测试,循环测试。通过上面的方法可以实现测试用例对程序的逻辑覆盖,和路径覆盖。

二、开始测试前的准备
        
        在开始测试时,要先声明一下,无论你设计多少测试用例,无论你的测试方案多么完美,都不可能完全100%的发现所有BUG,我们所需要做的是用最少的资源,做最多测试检查,寻找一个平衡点保证程序的正确性。穷举测试是不可能的。   所以现在进行单元测试我选用的是现在一般用的比较多的基本路径测试法。

三、开始测试

基本路径测试法:设计出的测试用例要保证每一个基本独立路径至少要执行一次。

函数说明 :当i_flag=0;返回     i_count+100
                                当i_flag=1;返回   i_count  *10
                                否则  返回   i_count  *20

输入参数:int i_count ,  
                            int i_flag
        输出参数: int  i_return; 
        
       
        代码:

1  int Test(int i_count, int i_flag)
 2         {
 3             int i_temp = 1;
 4             while (i_count>0)
 5             {
 6                 if (0 == i_flag)
 7                 {
 8                     i_temp = i_count + 100;
 9                     break;
10                 }
11                 else
12                 {
13                     if (1 == i_flag)
14                     {
15                         i_temp = i_temp * 10;
16                     }
17                     else
18                     {
19                         i_temp = i_temp * 20;
20                     }
21                 }
22                 i_count--;
23             }
24             return i_temp;
25         }

1.画出程序控制流程图
        
    图例:
  

事例程序流程图:

圈中的数字代表的是语句的行号,也许有人问为什么选4,6,13,8......作为结点,第2行,第3行为什么不是结点,因为选择结点是有规律的。让我们看程序中;第2行,第3行是按顺序执行下来的。直到第4行才出现了循环操作。而2,3行没有什么判断,选择等分支操作,所以我们把2,3,4全部合并成一个结点。其他的也是照这个规则合并,然后就有了上面的流程图。

2.计算圈复杂度
            
            有了图以后我们要知道到底我们有写多少个测试用例,才能满足基本路径测试。
            这里有有了一个新概念——圈复杂度
            圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。将该度量用于计算程序的基本独立路径数目。为确保所有语句至少执行一次的测试数量的上界。
            公式圈复杂度V(G)=E-N+2,E是流图中边的数量,N是流图中结点的数量。
            公式圈复杂度V(G)=P+1 ,P是流图G中判定结点的数量。
            通俗的说圈负责度就是判断单元是不是复杂,是不是好测试的标准。一般来说如果圈复杂度如果大于20就表示这个单元的可测试性不好,太复杂(也许有人觉得无所谓,但是如果你们公司实行了CMMI5的话,对这个是有规定的)。
            从图中我们可以看到,
            V(G)=10条边-8结点+2=4
            V(G)=3个判定结点+1=4
            上图的圈复杂图是4。这个结果对我们来说有什么意义呢?它表示我们只要最多4个测试用例就可以达到基本路径覆盖。

3.导出程序基本路径。
            
            现在我们知道了起码要写4个测试用例,但是怎么设计这4个测试用例?
            导出程序基本路径,根据程序基本路径设计测试用例子。

程序基本路径:基本独立路径就是从程序的开始结点到结束可以选择任何的路径遍历,但是每条路径至少应该包含一条已定义路径不曾用到的边。(看起来不好理解,让我们看例子)。
             让我们看上面的流程图:从结点4到24有几条路径呢?
             1 B(4,24)
             2 C,E,J(4,6,8,24)
             3 C,D,F,H,A,B(4,6,13,15,22,4,24)
             4 C,D,G,I,A,B(4,6,13,19,22,4,24)
             还有吗??
             5 C,D,C,I,A,C,E,J(4,6,13,19,22,4,6,8,24)算吗?
            不算,为什么?因为上面的4条路径已经包括了所有的边。第5条路径已经不包含没有用过的边了。所有的路径都遍历过了。
            好了,现在我们有了4条基本独立路径根据独立路径我们可以设计测试用例。

1 B(4,24)
            输入数据:i_count=0,或者是i_count<0的某一个值。
            预期结果:i_temp=0.

2 C,E,J(4,6,8,24)
            输入数据: i_count =1;i_flag=0 
            预期结果:i_temp=101.

3 C,D,F,H,A,B(4,6,13,15,22,4,24)
            输入数据: i_count =1;i_flag=1 
            预期结果:i_temp=10.

4 C,D,G,I,A,B(4,6,13,19,22,4,24)
             输入数据: i_count =1;i_flag=2     
             预期结果:i_temp=20.
            
            这里的输入数据是由路径和程序推论出来的。而要注意的是预期结果是从函数说明中导出,不能根据程序结构中导出。
            
            为什么这么说?
            让我们看程序中的第3行。
            int i_temp=1;假如开发人员一不小心写错了,变成了int i_temp=0;根据程序导出的预期结果就会是一个错误的值,但是单元测试不出来问题。
            那单元测试就失去了意义。

有人也许会问这么简单的函数就有4个测试用例,如果还复杂一些的怎么办?上面的测试用例还可以简化吗?答案是可以。
            我们来看 路径    1 B(4,24)和   4 C,D,G,I,A,B(4,6,13,19,22,4,24),路径1是路径4的真子集,     所以1是可以不必要的。上图的圈复杂度是4。这个结果对我们来说有什么意义呢?它表示我们只要最多4个测试用例就可以达到基本路径覆盖。所以说圈复杂度标示是最多的测试用例个数,不是一定要4个测试用例才可以。不过有一点要申明的是测试用例越简化代表你的测试越少,这样程序的安全性就越低了。

四、完成测试
            
            接下来根据测试用例使用工具测试NUNIT,VS2005都可以。
            接下来根据测试结果编写测试报告,测试人,时间,结果,用例,是否通过,格式网上一大把,每个公司的格式也不一样就不说了。

时间: 2024-10-11 00:54:47

如何设计单元测试用例的相关文章

SpringTest框架JUnit单元测试用例获取ApplicationContext实例的方法

JUnit单元测试用例中使用Spring框架,之前我的使用方式很直接. /** * 用于需要用到Spring的测试用例基类 * * @author lihzh * @alia OneCoder * @blog http://www.coderli.com */ @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = { "/spring/applicationContext.xml" }) pu

按照所给的程序流程图,分别写出语句覆盖、分支覆盖的测试用例,以及它所覆盖的路径,根据程序流程图,写出代码,用JUnit生成单元测试,并利用前面设计的测试用例进行测试。

语句覆盖:路径:abc ,测试用例:x=3,y=2 分支覆盖:路径:aeg ,测试用例:x=4,y=-1 /** * 2016-04-09 * @author 吴思婷 * DoWork类用来根据程序流程图,写出代码(定义一个类和方法来实现) */ public class DoWork { public void doWork(int x,int y){ int k=0,j=0; if((x<4 || y>0)&&(y>1)){ y=y+1; } else { if(x&

一些设计黑盒测试用例方法的总结

一些设计黑盒测试用例方法的总结 黑盒测试 黑盒测试是在不知道代码或程序的内部结构的情况下,测试软件的方法,这种测试方法在实际中经常用到. 黑盒测试主要包括以下几种方法: 边界值分析 等价类划分 依照决策表测试 因果图法 错误猜测 这里总结了其中一些方法. 等价类划分 等价类划分是一种把软件的输入数据划分为不同的等价数据类的测试用例设计技术.测试用例依照等价数据类设计,等价分区经常由影响试验对象处理的输入数据的需求规范决定.这种方法能减少测试软件所必需的测试时间,并且让测试用例更有效. 它可用于测

SWTBOK测试实践系列(9) -- 设计的测试用例是否越详细越好?

测试人员设计测试用例的时候,面临的第一个问题就是测试用例的步骤是否越详细越好?或者如何把握测试用例的详细步骤?在这个问题上,赞成测试用例详细化的人肯定有不少,因为详细测试用例可以提供如下优点: 1)缺乏经验或者技能的测试人员,可以按照测试用例的步骤顺利开展测试执行工作.这是脚本化测试实践中的思维:有经验与技能的测试人员设计测试用例,而缺乏经验的人员去执行测试用例. 2)缺乏经验的测试人员,按照详细测试用例的步骤执行的过程,不仅可以帮助他们了解测试对象的功能与业务知识,也可以帮助他们了解测试设计技

我的测试用例设计-01测试用例的个人见解

刚入行的时候,看了很多关于测试相关的文章,记得有一篇说到测试用例是测试灵魂让我印象深刻.如今,我入行几年了,越发深感测试用例的设计重要性,可以这么说,测试用例的设计与管理是测试工程师的核心技能.我发现很多测试的同行都向往去追求新的测试工具,测试技术手段而忽视测试用例的设计,测试用例的设计其实是测试方法.测试思路的体现,如果一面追求技术手段而忽视方法思路的锻炼,本人就觉得有点本末倒置. 说到此,突然就联想到一个武侠小说的例子.武侠小说里华山派有分剑宗和气宗两个派别,网络上也很多在讨论究竟剑宗厉害还

命令行运行Android Robotium自动化用例或单元测试用例

本文目录 1.运行所有的测试用例 2.运行单个测试类或某个TestSuite 3.运行某个测试类里面的某个测试方法 4.运行两个不同的测试类或类中的方法 命令行运行Android Robotium自动化用例或单元测试用例 1.运行所有的测试用例 举个栗子:运行测试工程下的所有用例 1 adb shell am instrument -w com.taobao.taobao.test/android.test.InstrumentationTestRunner 2.运行单个测试类或某个TestSu

如何设计接口测试用例

接口测试是项目测试的一部分,正如其名,它测试的主要对象是接口,是测试系统组件间接口的一种测试.接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点.测试的重点是检查数据交互.传递.和控制管理过程以及系统间的相互依赖关系等. 如何设计接口测试用例? 首先,明确出发点.和所有的测试一样,接口测试出发点是你要证明所测的程序是错误的.以这个出发点为导向,你的设计行为就会尽量朝这个方向发展,更易发现问题,不会出现大方向的偏差. 其次,选择好测试对象.对于一个系统做接口测试选择好的测试对象是

【转】SpringTest框架JUnit单元测试用例获取ApplicationContext实例的方法

转自:http://www.coderli.com/junit-spring-test-applicationcontext JUnit单元测试用例中使用Spring框架,直接方式如下. @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = { "/spring/applicationContext.xml" }) public class SpringTest {} 想要获取Applicat

如何简单设计接口测试用例

接口测试是项目测试的一部分,它测试的主要对象是接口 ,是测试系统组件间接口的一种测试.接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点.测试的重点是检查数据交互.传递.和控制管理过程以及系统间的相互依赖关系等. 如何设计接口测试用例?首先,明确出发点,和所有的测试一样 ,接口测试出发点是你要证明所测的程序是错误的.以这个出发点为导向,你的设计行为就会尽量朝这个方向,更易发现问题 其次,选择好测试对象.对于一个系统做接口测试选择好的测试对象是接口测试关键.一个系统有无数的接口