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

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

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

一、单元测试的概念

单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常,并且返回了正确的输出。

测试的覆盖种类

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;

代码:

1int Test(int i_count, int i_flag)

2 {

3int i_temp = 1;

4while (i_count>0)

5 {

6if (0 == i_flag)

7 {

8 i_temp = i_count + 100; 9break;

10 }

11else

12 {

13if (1 == i_flag)

14 {

15 i_temp = i_temp * 10;

16 }

17else

18 {

19 i_temp = i_temp * 20;

20 }

21 }

22 i_count--;

23 }

24return 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都可以。

白盒与黑盒测试的测试用例设计(20210110002601)

第 5 章白盒与黑盒测试的测试用例设计 5.1 覆盖率的概念 覆盖率是用来度量测试完整性的一个手段逻辑覆盖和功能覆盖 覆盖率=(至少被执行一次的item 数)/item 总数 5.2 白盒测试的测试用例设计 5.2.1 逻辑覆盖逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计技术,属白盒测试。为了衡量测试的覆盖程度,需要建立一些作为测试彻底度的定量衡量标准。目前常用的覆盖标准是:语句覆盖;判定覆盖;条件覆盖;判定/ 条件覆盖;条件组合覆盖;路径覆盖 一、语句覆盖语句覆盖就是设计若干个测试用例,运行所测的程序,使得每一可执行语句至少执行一次。 二、判定覆盖判定覆盖就是设计若干个测试用例,使程序中的每个判断至少出现一次“真值”和一次“假值”,即程序中的每个分支都至少执行一次。 三、条件覆盖条件覆盖是指利用若干个测试用例,使被测试的程序中,对应每个判断中每个条件的所有可能情况均至少执行一次。 四、判定/ 条件覆盖 判定/ 条件覆盖就是设计足够多的测试用例,使得程序中每个判断条件的所有可能的结果至少取到一次,又使每次判断的每个分支至少通过一次。 五、条件组合覆盖 解决上述问题的新标准是条件组合覆盖。条件组合覆盖就是设计足够多的测试用例,使得每个判断的所有可能的条件取值组合至少执行一次。 六、逻辑覆盖举例 [例1]试用逻辑覆盖测试法为采用冒泡排序(bubble sorting )法进行数据排序的C 程序设

计测试用例。 本例是一个对k 个整数进行升序排序的C 程序,采用的算法是冒泡排序。基 本步骤是: (1)从数组中取出第2 个元素; (2)如果新取出的元素大于等于其前邻元素,则转向第(4)步; (3)如果新取出的元素小于其前邻元素,则与其前邻元素交换位置; (4)将新元素与新的前邻元素比较,若仍小于新的前邻元素,则重复第(3)步; (5)取下一个元素。如果数组中元素已取完则结束排序,否则转向第(2)步。 下面将给出本例的C程序。图2则是排序部分的流程图。 main() { int a[11],i,j,k,temp; scanf(“%d”,k); printf(“input numbers: n”); for(i=1;i<=k;i++) scanf(“ %d”,&a[i]);

白盒测试用例设计方法

1白盒测试用例设计方法 1.1白盒测试简介 白盒测试又称结构测试、逻辑驱动测试或基于程序的测试,一般多发生在单元测试阶段。白盒测试方法主要包括逻辑覆盖法,基本路径法,程序插装等。 这里重点介绍一下常用的基本路径法,对于逻辑覆盖简单介绍一下覆盖准则。 1.2基本路径法 在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出独立路径集合,从而设计测试用例,设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。 在介绍基本路径测试方法(又称独立路径测试)之前,先介绍流图符号: 图1 如图1所示,每一个圆,称为流图的节点,代表一个或多个语句,流程图中的处理方框序列和菱形决策框可映射为一个节点,流图中的箭头,称为边或连接,代表控制流,类似于流程图中的箭头。一条边必须终止于一个节点,即使该节点并不代表任何语句,例如,图2中两个处理方框交汇处是一个节点,边和节点限定的范围称为区域。 图2

任何过程设计表示法都可被翻译成流图,下面显示了一段流程图以及相应的流图。 注意,程序设计中遇到复合条件时(逻辑or, and, nor 等),生成的流图变得更为复杂,如(c)流图所示。此时必须为语句IF a OR b 中的每一个a 和b 创建一个独立的节点。

(c)流图 独立路径是指程序中至少引进一个新的处理语句集合,采用流图的术语,即独立路径必须至少包含一条在定义路径之前不曾用到的边。例如图(b)中所示流图的一个独立路径集合为: 路径1:1-11 路径2:1-2-3-4-5-10-1-11 路径3:1-2-3-6-8-9-10-1-11 路径4:1-2-3-6-7-9-10-1-11 上面定义的路径1,2,3 和4 包含了(b)流图的一个基本集,如果能将测试设计为强迫运行这些路径,那么程序中的每一条语句将至少被执行一次,每一个条件执行时都将分别取true 和false(分支覆盖)。应该注意到基本集并不唯一,实际上,给定的过程设计可派生出任意数量的不同基本集。如何才能知道需要寻找多少条路径呢?可以通过如下三种方法之一来计算独立路径的上界: 1. V=E-N+2,E 是流图中边的数量,N 是流图节点数量。 2. V=P+1,P 是流图中判定节点的数量 3. V=R,R 是流图中区域的数量 例如,(b)流图可以采用上述任意一种算法来计算独立路径的数量 1. V=11 条边-9 个节点+2=4 2. V=3 个判定节点+1=4 3. 流图有4 个区域,所以V=4 由此为了覆盖所有程序语句,必须设计至少4 个测试用例使程序运行于这4 条路径。 在采用基本路径测试方法中,获取测试用例可参考以下方式:

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

如何编写单元测试用例(白盒测试)。 一、单元测试的概念 单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常,并且返回了正确的输出。 测试的覆盖种类 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; 代码: 1int Test(int i_count, int i_flag) 2 {

软件测试方案模板(by LJ.)

测试方案模板 Edit by LJ. 1 概述 1.1 编写目的 [说明编写本测试方案的目的是为软件开发项目管理者、软件工程师、系统维护工程师、测试工程师提供关于**系统整体系统功能和性能的测试指导。] 1.2 读者对象 [本测试方案可能的合法读者对象为软件开发项目管理者、软件工程师、测试组、系统维护工程师] 1.3 项目背景 [可以如下那样简单说明,根据项目的具体情况,方案编写者也可以进行详细说明 项目名称:*** 简称:*** 项目代号:*** 委托单位:*** 开发单位:*** 主管部分:***] 1.4 测试目标 [说明进行项目测试的目标或所要达到的目的] 1.5 参考资料 [列出编写本测试方案时参考的资料和文献]

2 测试配置要求 2.1 网络环境 [在此说明应用系统的网络环境,如果应用系统是网络版的,必须具有本节内容。] 2.1.1 网络硬件 [此处给出网络硬件的拓扑图、名称、规格、数量、配置等信息。] 2.1.2 网络软件 [此处给出网络软件的名称、协议、通讯和连接方式等信息。] 2.2 服务器环境 2.2.1 服务器硬件 [此处给出服务器硬件的名称、规格、数量、配置等信息。] 2.2.2 服务器软件 [此处给出服务器软件名称、协议和版本等信息。] 2.3 工作站环境 2.3.1 工作站硬件 [此处给出工作站硬件的拓扑图、名称、规格、数量、配置等信息。] 2.3.2 工作站软件 [此处给出工作站软件的名称、协议和版本等信息。] 2.4 测试手段 [在此参照《测试计划》说明测试方法和工具,注明执行测试时,必须同时填写《测试记录表》]

2.5 测试数据 [在此简要说明测试数据的形成,如以客户单位具体的业务规则和《***系统需求分析说明书》,参考《***系统概要设计说明书》、《***系统详细设计说明书》和《数据规格说明书》中规定的运行限制,设计测试用例,作为整个**系统的测试数据。] 2.6 测试策略 [在此说明测试策略,可以如下这样说明: 测试过程按三个步骤进行,即单元测试、组装、系统测试,根据不同阶段测试的侧重点不同,分别介绍测试策略: A)单元测试 首先按照系统、子系统和模块进行划分,但最终的单元必须是功能模块,或面向对象过程中的若干个类。单元测试是对功能模块进行正确检验的测试工作,也是后续测试的基础。目的是在于发现各模块内部可能存在的各种差错,因此需要从程序的内部结构出发设计测试用例,着重考虑以下五个方面: 1)模块接口:对所测模块的数据流进行测试。 2)局部数据结构:检查不正确或不一致的数据类型说明、使用尚未附值或尚未初始化的变量、错误的初始值或缺省值。 3)路径:虽然不可能做到穷举测试,但要设计测试用例查找由于不正确的计算(包括算法错、表达式符号表示不正确、运算精度不够等)、不正确的比较或不正常的控制流(包括不同数据类型量的相互比较、不适当地修改了循环变量、错误的或不可能的循环终止条件等)而导致的错误。 4)错误处理:检查模块有没有对预见错误的条件设计比较完善的错误处理功能,保证其逻辑上的正确性。 5)边界:注意设计数据流、控制流中刚好等于、大于或小于确定的比较值的用例。 B)集成测试 集成测试也叫组装测试或联合测试。通常,在单元测试的基础上需要将所有的模块按照设计要求组装成系统,这时需要考虑的问题: 1)在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失。

白盒测试:路径测试及测试用例设计

20 14 —20 15 学年第 2 学期 软件测试技术课程 实验报告 学院:计算机科学技术 专业:软件工程 班级:软件12401 姓名:李晶宇 学号:041240134 任课教师:刘玉宝

实验日期:2015年 6 月16 日实验题目实验5、白盒测试:路径测试及测试用例设计 实验目的1、掌握独立路径,程序基本路径测试的概念。 2、掌握独立路径测试法。 实验内容 程序int binsearch(int array[],int key)实现折半查找的功能。数组array元素按升序排列,length为数组array的长度,key为要查找的值。 试用独立路径集测试法测试该程序,撰写实验报告。 关键代码如下(Java实现) public static int binsearch(int array[],int key) { int low = 0; int high = array.length - 1; int middle; while(low <= high) { middle = (low+high)/2; if(array.[middle] == key) { return middle; }else if(array.[middle] < key) { low = middle +1; }else { high = middle - 1; } } return -1; } 实验步骤: 1)画出程序的流图(控制流程图)。

程序入口(数组元素升序) low <= high (low+high)/2 array[middle] == key Y N array[middle] < key key=middle Y N low=middle+1 high=middle-1 程序出口 2)计算流图G 的圈复杂度V(G)。 封闭区域:○2→○3→○4→○6→○7→○2→○10 ○2→○3→○4→○6→○8→○9→○2→○10 还有一个区域是这两个区域以外的区域,共有三个区域,即独立路径数的上界 是3,V(G)=3。 3)确定只包含独立路径的基本路径集。 V(G)值正好等于该程序的独立路径的条数。 程序的独立路径是: Path1:○1→○2→○3→○4→○5→○10 Path2:○1→○2→○3→○4→○6→○7→○2→○10 Path3:○1→○2→○3→○4→○6→○8→○9→○2→○10 4)根据上面的独立路径,设计测试用例,得到测试用例表。 为了确保基本路径集中的每一条路径的执行,根据判断结点给出的条件,选择适当的数据以保证每一条路径可以被测试到,满足上面例子基本路径集的测试用例表如下: 2 10 1 4 6 5 7 8 9 3

测试用例范例

讨论用TestDirector管理测试用例 编制时间:2007-03-16 编制部门:测试组 编制人:郭宏元 “测试用例”虽有国标作蓝本,但实际中,一直以来“测试用例”是所有测试人员有争议的地方,此所谓“仁者见仁,智者见智”。而“法无定法,则无定则”,所有的规范与标准都是围绕更适应人们的工作环境而创建。在此,我就我的一些体会在此与大家分享。 一般来说,“测试用例”的编写主要分三大类,贯彻的原则与基本架构如下: 分类: 1、对验证过程的一个记录; 2、展现一个功能; 3、描述一个场景步骤; 原则: 1、有“对象”属性的描述; 2、阐述了某个“对象”的方法或事件。 3、对属性、方法或事件有详细的定义。 基本架构: 1、目的; 2、前提条件; 3、输入步骤(输入动作或数据,预期结果) 以下总结了一些针对测试用例的“编写要点”作出一些较简单的规范。以方便统一测试用例的编写,并保证使用最用效的测试用例来保证测试质量。我们都知道根据详细设计文档编写测试用例的目的不在于验证软件达到的功能,而在于验证软件应该达到的功能,这样可以去除软件开发过程中的随意性。所以下面就明确测试用例的“目的”、“范围”、“原则”是什么?以及采用的方法做了一点描述。 1、目的: 围绕测试名称或满足实现测试功能而进行。 2、范围:

适用于所要测试的质检项目。 3、功能测试用例编写原则 3.1单元测试功能用例的编写目的 单元测试用例的目的在于验证单个模块是否达到了详细设计说明书中规定的功能,由于是单个模块所以无法检验关联性,可能会牵扯到数据库的操作,例如:删除时,需要查看数据库是否完全删除了数据。 3.2集成测试功能用例的编写目的 集成测试功能用例的目的在于验证软件连接时,模块的连接是否正确(及数据的传递是否正确)。.我们的软件中体现出来的是,是否正确调用界面,界面之间显示的数据是否正确,特别是财务、费用、数据方面的。 集成测试用例的编写过程中,经常将功能用例与业务流程混合编写,因为在集成测试时需验证业务流程中的数据正确性,以及界面之间的数据传递的准确无误。 3.3系统测试业务流程用例的编写目的 系统测试业务流程用例的目的在于验证软件最终数据的准确性,我们的软件体现为,手工数据与报表数据的一直性。用例与用例之间有着一定的关系,目的性十分明确。 4、测试用例设计的原则 4.1全面性 指编写的测试用例应该覆盖所有的“概要设计文档”或“需求文档”以及“测试申请文档”中描述的功能。 4.1.1数据库程序基本的增、删、改功能 增、改测试用例重点在于数据合法性、正确性的检验和提示信息的正确性的检验。输入的数据可能有无限种组合,此时可以采用等价类划分和边界值法,下面有较详细的说明。 删除的测试用例比较简单,只有操作没有数据的输入,但是应该在“备注”中注明,删除的限制条件,以及数据库中应该删除的表的情况,有条件限制时,测试用例应该包含各种删除条件,必要时在添加或修改的测试用例后面或中间紧跟删除的测试用例。 4.1.2对于无输入的操作,应该详细描述其具体的操作步骤和结果

白盒测试用例练习题(1)

白盒测试用例练习 1.为以下所示的程序段设计一组测试用例,要求分别满足语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖,并画出相应的程序流程图。 void DoWork (int x,int y,int z) { int k=0,j=0; if ( (x>3)&&(z<10) ) { k=x*y-1; j=sqrt(k); //语句块1 } if ( (x==4)||(y>5) ) { j=x*y+10; } //语句块2 j=j%3; //语句块3 } a Y c N b e Y N d x>3 and z<10 x=4 or y>5 j=j%3 j=x*y+10 k=x*y-1 j=sqrt(k) k=0 j=0

由这个流程图可以看出,该程序模块有4条不同的路径: P1:(a-c-e) P2:(a-c-d) P3:(a-b-e) P4:(a-b-d) 将里面的判定条件和过程记录如下: 判定条件M={x>3 and z<10} 判定条件N={x=4 or y>5} 1、语句覆盖 测试用例输入输出判定M的取值判定N的取值覆盖路径x=4,z=5,y=8 k=31,j=0 T T P1(a-c-e) 2、判定覆盖 p1和p4可以作为测试用例,其中p1作为取真的路径,p4作为取反的路径。 测试用例输入输出判定M的取值判定N的取值覆盖路径x=4,z=5,y=8 k=31,j=0 T T P1(a-c-e) x=2,z=11,y=5 k=0,j=0 F F P4(a-b-d) 也可以让测试用例测试路径P2和P3。相应的两组输入数据如下: 测试用例输入输出判定M的取值判定N的取值覆盖路径x=5,z=5,y=4 k=19,j=sqrt(19)%3 T F P2(a-c-d) x=4,z=11,y=6 k=0,j=1 F T P3(a-b-e) 3、条件覆盖 对于M:x>3取真时T1,取假时F1; z<10取真时T2,取假时F2; 对于N:x=4取真时T3,取假时F3; y>5取真时T4,取假时F4。 条件:x>3,z<10,x=4,y>5 条件:x<=3,z>=10,x!=4,y<=5 根据条件覆盖的基本思路,和这8个条件取值,组合测试用例如表所示: 测试用例输入输出取值条件具体取值条件覆盖路径x=4,z=5,y=8 k=31, j=0 T1,T2,T3,T4 x>3,z<10,x=4,y>5 P1(a-c-e) x=3,z=11,y=5 k=0, j=0 F1,F2,F3,F4 x<=3,z>=10,x!=4,y<=5 P4(a-b-d) 4、判定/条件覆盖 测试用例输入输出取值条件具体取值条件覆盖路径x=4,z=5,y=8 k=31, j=0 T1,T2,T3,T4 x>3,z<10,x=4,y>5 P1(a-c-e) x=3,z=11,y=5 k=0, j=0 F1,F2,F3,F4 x<=3,z>=10,x!=4,y<=5 P4(a-b-d)

酒店管理系统+单元测试用例

酒店管理系统+单元测试用例 客房预订系统测试用例 测试编号设计者1测试需求项客房预订测试需求标号设计日期001 2008. 9. 4测试目标状态和测完成散客预订、团体预订、客房预订、预订未到处理、预售查询等项功能试数据状态 测试项输入说明(操作)输出说明(预期结果)序号 姓名性别预付押金付款方式入住 1类型证件类型和号码地址联系电话酒店个人押金凭证散客预订 预订入住日期和预离日期 主宾姓名主宾性别预付押金付款方 式入住类型证件类型和号码地址2酒店团体押金凭证团体预订联系电话 预定入住日期和预离日期 主客房间宾客人数 3客房预订根据用户需求预订房间宾客预订信息 预订未到处注销预定信息输出注销成功4理 当前时间酒店预售一览表可售房间数以及某房间的5预售查询预订情况前台接待系统测试用例 测试编号设计者2测试需求项前台接待测试需求标号设计日期002 2008. 9. 4测试LI标状态和测完成散客入住登记、合约入住、团体自动入住和手动入住、补填客单、修改客人信息、试数据状态预订客房查询、可售房间查询等项功能 测试项输入说明(操作)输出说明(预期结果)序号

姓名性别预付押金付款方式入住散客入住登6类型证件类型和号码地址联系电话客人相关信息记入住日期和预离日期 姓名性别证件号预订入住时间期限7客人相关信息合约入住预离时间 姓名性别预付押金付款方式入住类 团体自动入型证件类型和号码地址联系电话8住和手动入团体入住相关信息入住日期和预离日期宾客人数入住住 方式 9填补客单输入用户信息修改后的用户信息 修改客人信10姓名性别证件号所需修改信息显示修改后客户信息息 预订客房查11姓名性别证件号显示预订相关信息或者是无结果询 可售房间查12当前时间空闲房间号询 前台收银系统测试用例 测试编号设计者3测试需求项前台收银测试需求标号设计日期003 2008. 9. 4测试口标状态和测完成记帐查帐转帐个人或团体埋单限制客人消费等项功能试数据状态 序号测试项输入说明(操作)输出说明(预期结果) 记帐查帐13姓名性别证件号当前消费转帐 14酒店消费清单埋单姓名性别证件号 帐务系统测试用例 测试编号设讣者4测试需求项帐务管理测试需求标号设计日期004 2008. 9.4 测试LI标状态和测具备收银功能外,设置纠错报表输出等项功能试数据状态测试项输入说明(操作)输出说明(预期结果)序号

白盒测试及用例设计

白盒测试 白盒测试(White-box Testing,又称逻辑驱动测试,结构测试) 是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时,需要测试软件产品的内部结构和处理过程,不需测试软件产品的功能。白盒测试又称为结构测试和逻辑驱动测试。 白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。 六种覆盖标准:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。语句覆盖每条语句至少执行一次。判定覆盖每个判定的每个分支至少执行一次。条件覆盖每个判定的每个条件应取到各种可能的值。判定/条件覆盖同时满足判定覆盖条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖使程序中每一条可能的路径至少执行一次。 白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。 "白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。第二,穷举路径测试不可能查出程序中因遗漏路径而出错。第三,穷举路径测试可能发现不了一些与数据相关的错误。

酒店管理系统 测试用例

酒店管理系统 测试用例 姓名:王运飞 学号:08111423 文件状态: [√] 草稿 [ ] 正式发布 [ ] 正在修改文件标 识: 东华理工大学-酒店管理系统-测试报 告 当前版 本: 2.0 作 者: 王运飞 完成日 期: 2010-10-26 版本/状态作者参与者起止日期备注 1.0 王运 飞 王运飞 2.0 王运 飞王运飞修复了一下bug,程序运 行更加稳定了

目录

0文档介绍 0.1 文档目的 该测试文档实现的目的为,给所有测试用例的说明提供测试方法步骤,同时为进一步开放测试脚本提供依据。 0.2 文档范围 本文档为酒店管理系统,其中包含了酒店订餐,消费方式,现金或刷卡,打折优惠,等基本功能的测试用例。 0.3 读者对象 本文档面向的对象主要有两类,一是测试人员,另一类是开发人员。 0.4 参考文献 《酒店管理系统软件规格需求说明书》 0.5 术语与缩写解释 缩写、术语解释 订餐提前向餐厅预订餐饭,有可能需要交一部分费用 结账就餐后支付就餐费,须向客户开发票 刷卡就餐后使用银行卡支付餐费 包厢顾客单独在一间房子内就餐 1. 接口-路径测试用例 1.1 被测试对象(单元)的介绍 测试对象这里测试对象主要是该软件所实现的几个功能,也可称为接口,这里主要接口有顾客订餐,顾客就餐后刷卡支付餐费,顾客预订包厢,顾

客结账。 1.2 测试范围与目的 测试目的通过测试了解各个接口的正确性,比如顾客能否顺利的订到餐饭,能否联网刷卡,能否订到包厢。 1.3 接口测试用例 接口订餐函数原型 输入/动作期望的输出/相应实际情况 典型值…餐位充足可以订餐成功 边界值…餐位紧张订餐成功或失败成功或失败 异常值…餐位不足订餐失败失败 接口刷卡函数原型 输入/动作期望的输出/相应实际情况 典型值…卡内余额足够刷卡成功成功 边界值…卡内余额不多刷卡成功或失败成功或失败 异常值…卡内余额不够刷卡失败失败 … 接口包厢函数原型 输入/动作期望的输出/相应实际情况 典型值…包厢充足可以预定包厢成功 边界值…包厢较少预订成功或失败成功或失败 异常值…包厢紧张失败失败 … 1.4 路径测试的检查表 检查项结论 数据类型问题 (1)变量的数据类型有错误吗?(2)存在不同数据类型的赋值吗?(3)存在不同数据类型的比较吗?没有不存在不存在 变量值问题 (1)变量的初始化或缺省值有错误吗?没有没有

软件测试中如何编写单元测试用例(白盒测试)

软件测试中如何编写单元测试用例(白盒测试) 测试用例(T est Case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。 测试用例(T est Case)目前没有经典的定义。比较通常的说法是:指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。 不同类别的软件,测试用例是不同的。不同于诸如系统、工具、控制、游戏软件,管理软件的用户需求更加不统一,变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。 随着中国软件业的日益壮大和逐步走向成熟,软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括:编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之,并有向第三方专业测试公司发展的趋势。 要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述,以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而,核实这些需求可能通过不同的方式并由不同的测试员来实施。例如,执行软件以便验证它的功能和性能,这项操作可能由某个测试员采用自动测试技术来实现;计算机系统的关机步骤可通过手工测试和观察来完成;不过,市场占有率和销售数据(以及产品需求),只能通过评测产品和竞争销售数据来完成。 既然可能无法(或不必负责)核实所有的需求,那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。 确定测试用例之所以很重要,原因有以下几方面。 测试用例构成了设计和制定测试过程的基础。测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流,因而,随着测试用例数量的增加,您对产品质量和测试流程也就越有信心。判断测试是否完全的一个主要评测方法是基于需求的覆盖,而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明:“95 % 的关键测试用例已得以执行和验证”,远比“我们已完成95 % 的测试”更有意义。测试工作量与测试用例的数量成比例。根据全面且细化的测试用例,可以更准确地估计测试周期各连续阶段的时间安排。测试设计和开发的类型以及所需的资源主要都受控于测试用例。测试用例通常根据它们所关联关系的测试类型或测试需求来分类,而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例:·一个测试用例用于证明该需求已经满足,通常称作正面测试用例;·另一个测试用例反映某个无法接受、反常或意外的条件或数据,用于论证只有在所需条件下才能够满足该需求,这个测试用例称作负面测试用例。 前段时间公司进行有关测试的培训,集成测试,性能测试,压力测试说了很多。由于本人还处于Coder阶段,只是对单元测试有了些了解。写下来怕以后自己忘记了。都是些自己的看法,不一定准确,欢迎高手指教。 一、单元测试的概念 单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用

白盒测试和黑盒测试

白盒测试 白盒测试,又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,你清楚盒子部的东西以及里面是如何运作的。"白盒"法全面了解程序部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时,测试者必须检查程序的部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。 采用什么方法对软件进行测试呢?常用的软件测试方法有两大类:静态测试方法和动态测试方法。其中软件的静态测试不要求在计算机上实际执行所测程序,主要以一些人工的模拟技术对软件进行分析和测试;而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序,而达到发现程序错误的过程。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。 中文名:白盒测试 外文名:white-box testing 别称:结构测试、透明盒测试 白盒测试测试方法 白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。 白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化: 1.语句覆盖每条语句至少执行一次。 2.判定覆盖每个判定的每个分支至少执行一次。 3.条件覆盖每个判定的每个条件应取到各种可能的值。 4.判定/条件覆盖同时满足判定覆盖条件覆盖。 5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。 6.路径覆盖使程序中每一条可能的路径至少执行一次。 白盒测试要求

单元测试用例设计

一、概述 (1) 二、基本概念 (1) 2.1正面测试(Positive Testing) (1) 2.2负面测试(Negative Testing) (2) 2.3分支测试 (2) 2.4黑盒测试 (2) 2.5白盒测试 (2) 三、单元测试范围 (3) 四、常见测试用例设计方法及举例 (3) 4.1 用于语句覆盖的基路径法 (3) 4.2 用于MC/DC的真值表法 (9) 4.3 边界值法 (11) 4.4 等价类法 (12) 4.5循环测试法 (17) 4.6错误推测法 (18) 五、相关注意事项 (18) 5.1独立性 (18) 5.2尽量脱离被测代码的束缚 (18)

5.3面向对象的语言单元测试特点 (18) 5.4单元测试的命名标准 (19) 1.单元测试的命名标准 (19) 2.单元测试中的变量命名规范 (19) 3.断言和操作分离 (19) 4.避免滥用setup和teardown (19)

一、概述 单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。该文档从测试角度出发,去讨论如何设计单元测试的测试用例。 这里强调,单元测试用例的设计是进入实际编码之前的,测试用例设计在前,更能体现出灵活性,如果已经编码完成再进行测试用例的补充,这样很容易进入一个仅仅是测试了被测代码段功能的怪圈,所以希望所有的单元测试工作,可以放在前面完成。同时单元测试用例是一个不断完善的过程,前期设计好的用例,在代码已经实现完成后,会发现覆盖的并不是很全面,有良好的习惯是需要将对应的测试用例进行补充,而在提交测试后发现的重要的bug,也需要进行单元测试用例的补充,使单元测试和各种测试方法相结合,实现测试质量的充分保证。 二、基本概念 2.1正面测试(Positive Testing) 测试被测对象的正确功能实现无误,即正常流程功能。往往需要根据设计说明进行用例导出,严格按照设计说明编写即可,用例划分注意等价类区分等方法。 例如:接口返回小于等于24个中文字的offer标题(这里标题控制不

软件测试白盒测试用例练习题

白盒测试用例练习 一、为以下所示的程序段设计一组测试用例,要求分别满足语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖,并画出相应的程序流程图。 void DoWork (int x,int y,int z) { int k=0,j=0; if ( (x>3)&&(z<10) ) { k=x*y-1; j=sqrt(k); //语句块1 } if ( (x==4)||(y>5) ) { j=x*y+10; } //语句块2 j=j%3; //语句块3 }

由这个流程图可以看出,该程序模块有4条不同的路径: P1:(a-c-e) P2:(a-c-d) P3:(a-b-e) P4:(a-b-d) 将里面的判定条件和过程记录如下: 判定条件M={x>3 and z<10} 判定条件N={x=4 or y>5} 1、语句覆盖 2、判定覆盖 p1和p4可以作为测试用例,其中p1作为取真的路径,p4作为取反的路径。 也可以让测试用例测试路径P2和P3。相应的两组输入数据如下:

3、条件覆盖 对于M:x>3取真时T1,取假时F1; z<10取真时T2,取假时F2; 对于N:x=4取真时T3,取假时F3; y>5取真时T4,取假时F4。 条件:x>3,z<10,x=4,y>5 条件:x<=3,z>=10,x!=4,y<=5 根据条件覆盖的基本思路,和这8个条件取值,组合测试用例如表所示: 4、判定/条件覆盖

5、组合覆盖 条件组合 1)x>3,z<10 2)x>3,z>=10 3) x<=3,z<10 4)x<=3,z>=10 5)x=4,y>5 6)x=4,y<=5 7)x!=4,y>5 8)x!=4,y<=5 6、路径覆盖

常见的测试用例设计方法都有哪些

常见的测试用例设计方法都有哪些 常见的测试用例设计方法都有哪些? 请分别以具体的例子来说明这些方 法在测试用例设计工作中的应用。 1. 等价类划分常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并 合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2. 边界值分析法边界值分析方法是对等价类划 分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入

输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 3. 错误推测法基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0 的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例. 4. 因果图方法前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查

系统单元测试用例测试报告

学生信息管理系统单元测试报告 [二零一零年十二月二日]

1编写目的 1.1为了保证学生信息管理系统的各项功能可靠的实现,特编写了此测试计划,对所开发软件的各功能模块和事例进行测试。 1.2学会使用简单的单元测试工具,对系统模块进行测试分析,并编写测试用例。 1.3为软件单元的评审验收提供依据. 2.单元模块概述 2.1功能需求分析 本系统由系统用户管理、学生管理、班级信息管理、课程设置和成绩管理几个模块组成。 2.1.1 系统用户管理模块 系统用户管理模块主要是对用户信息的管理,它包括用户登录、添加用户、修改用户密码。 2.1.1.1 用户登录 用户的登录限于已注册的用户,只有已注册的用户才能登录系统。其实现过程: 输入:用户名(用于登录账号); 输入:密码。 点击:登录按钮。 处理:1)输入信息的合法性。 2)操作成功,登录系统。否则,给出出错提示。 输出:登录成功或者登录失败的提示。 2.1.1.2 添加用户信息 增加一个新的用户。其实现过程如下: 输入:用户名(用于登录帐号),姓名,密码,权限。 处理:1)数据有效性检验。 2)将用户信息保存到数据库对应的数据表中 3)操作成功,给出成功提示,否则给出出错提示。 输出:操作结果。成功给予成功提示,失败给予失败提示,并且给出失败原因。 2.1.1.3 修改用户密码 修改密码用于用户对自己的密码进行修改。 输入:旧密码,新密码,确认密码 处理:1)输入数据有效性的验证,密码长度为6-20。 2)判断新密码与确认密码是否相同,如果不相同,给出出错提示。 3)新密码与确认密码相同,判断旧密码是否正确,如果不正确给出出错提示。 4)新密码与确认密码相同,旧密码正确,用新密码替换原来旧密码。操作成功,给出成功提示,否则给出出错信息。 输出:操作成功,系统提示密码修改成功,反之,系统提示密码修改错误,显示失败的原因

软件工程白盒测试练习及解答

白盒测试练习 1、什么是白盒测试? 白盒测试也称结构测试或逻辑驱动测试,它是按照程序内部的结构测试程序,通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行,检验程序中的每条通路是否都能按预定要求正确工作。这一方法是把测试对象看作一个打开的盒子,测试人员依据程序内部逻辑结构相关信息,设计或选择测试用例,对程序所有逻辑路径进行测试,通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。 2、什么是测试用例? 一组由前提条件、输入、执行条件、预期结果等组成,以完成对某个特定需求或者目标测试的数据,体现测试方案、方法、技术和策略的文档 3、写出以上程序的所有路径; L1(1->2->3) L2(1->4->5->3) L3(1->2->6->7) L4(1->4->5->6->7) 4、尝试用表格的形式描述满足以下情况的测试用例:

a)写出满足语句覆盖需要的测试用例; 解:语句覆盖就是程序中每一个语句至少能被执行一次 运行结果 b)写出满足判定覆盖(分支覆盖)需要的测试用例; 解:判定覆盖就是程序中每个判定至少有一次为真值,有一次为假值,使得程序中 每个分支至少执行一次 运行结果

c) 写出满足条件覆盖需要的测试用例; 解:条件覆盖是程序各判定中的每个条件获得各种可能的取值至少满足一次 运行结果 d) 写出满足判定/条件覆盖需要的测试用例; 解:判定/条件覆盖是程序中每个判定至少有一次为真值,有一次为假值,使得程序中每个分支至少执行一次,且使得各判定中的每个条件获得各种可能的取值至少满足一次。

运行结果 e) 写出满足条件组合覆盖需要的测试用例。 解:条件组合覆盖是判定中条件的各种组合都至少被执行一次 运行结果

白盒测试练习及答案

1、在白盒测试用例设计中,有语句覆盖、分支覆盖、条件覆盖、路径覆盖等,其中( A )是最强的覆盖准则。为了对如下图所示的程序段进行覆盖测试,必须适当地选取测试用例组。若x, y是两个变量,可供选择的测试用例组共有Ⅰ、Ⅱ、Ⅲ、Ⅳ四组,如表中给出,则实现判定覆盖至少应采取的测试用例组是( B )或( C );实现条件覆盖至少应采取的测试用例组是( D );实现路径覆盖至少应采取的测试用例组是( E )或( F )。 供选择的答案 A: ① 语句覆盖② 条件覆盖③ 判定覆盖④ 路径覆盖 B~F: ① Ⅰ和Ⅱ组② Ⅱ和Ⅲ组③ Ⅲ和Ⅳ组④ Ⅰ和Ⅳ组 ⑤ Ⅰ、Ⅱ、Ⅲ组⑥ Ⅱ、Ⅲ、Ⅳ组⑦ Ⅰ、Ⅲ、Ⅳ组 ⑧ Ⅰ、Ⅱ、Ⅳ组 解答:A. ④ B. ⑤ C. ⑧ D. ④ E. ⑤ F. ⑧ 2. 阅读下面这段程序,使用逻辑覆盖法进行测试,请问哪一组关于(a,b,c)的输入值可以达到条件覆盖。( B ) int func(int a,b,c) { int k=1; if ( (a>0) || (b<0) || (a+c>0) ) k=k+a; else k=k+b; if (c>0) k=k+c; return k; } A. (a,b,c) = (3,6,1)、(-4,-5,7) B. (a,b,c) = (2,5,8)、(-4,-9,-5) C. (a,b,c) = (6,8,-2)、(1,5,4) D. (a,b,c) = (4,9,-2)、(-4,8,3) 3. 阅读下面这段程序,使用逻辑覆盖法进行测试,请问哪一组关于(a,b,c)的输入值可以达到判定覆盖。( D )

int func(int a,b,c) { int k=1; if ( (a>0) &&(b<0) && (a+c>0) ) k=k+a; else k=k+b; if (c>0) k=k+c; return k; } A. (a,b,c) = (3,6,1)、(-4,-5,7) B. (a,b,c) = (2,5,8)、(-4,-9,-5) C. (a,b,c) = (6,8,-2)、(1,5,4) D. (a,b,c) = (4,-9,-2)、(-4,8,3) 4. 阅读下面这段程序,使用逻辑覆盖法进行测试,请问哪一组关于(a,b,c)的输入值可以达到判定条件覆盖。( B ) int func(int a,b,c) { int k=1; if ( (a>0) || (b<0) || (a+c>0) ) k=k+a; else k=k+b; if (c>0) k=k+c; return k; } A. (a,b,c) = (3,6,1)、(-4,-5,7) B. (a,b,c) = (2,-5,8)、(-4,9,-5) C. (a,b,c) = (6,8,-2)、(1,5,4) D. (a,b,c) = (4,9,-2)、(-4,8,3) 5、下面是一段求最大值的程序,其中datalist是数据表,n是datalist的长度。 int GetMax(int n, int datalist[ ]) { int k=0; for ( int j=1; j datalist[k] ) k=j; return k; } (1)画出该程序的控制流图,并计算其McCabe环路复杂性。 (2)用基本路径覆盖法给出测试路径。 (3)为各测试路径设计测试用例。 答: 1 int k = 0; 2 int j = 1; 3 while ( j < n ) 4 { 5 if ( datalist[j] > datalist[k] ) 6 k = j; 7 j++; 8 }

相关文档
最新文档