请使用等价类划分法为NextDate函数列出输入域等价类表,并设计相应的测试用例

请使用等价类划分法为NextDate函数列出输入域等价类表,并设计相应的测试用例,第1张

1、 等价类划分:

等价类表

输入条件

有效等价类

唯一标识

无效等价类

唯一标识

三个数

三个数

1

输入0个数

2

输入1个数

3

输入2个数

4

整数

三个整数

5

一个不是整数

6

两个不是整数

7

都不是整数

8

取值范围

1812=<y<=2500&&

1<=m<=12&&

1<=d

9

y<1812

10

y>2500

11

m<1

12

m>12

13

d<1

14

m=2

(满足1,5,9)

D<=28&&平年

15

d>28&&平年

16

D<=29&&闰年

17

d>29&&闰年

18

大月 (m=1,3,5,7,8,10,12)

(满足1,5,9

D<=31

19

d>31

20

小月

(m=4,6,9,11)

(满足1,5,9

D<=30

21

d>30

22

等价类划分测试举例

序号

输入数据

期望输出

覆盖有效/无效等价类

实际输出

1

日期不合法

2

等待继续输入

2

1999

日期不合法

3

等待继续输入

3

1991,1

日期不合法

4

等待继续输入

4

1991,11,1

日期不合法

6

不合法死循环

5

191,11,1

日期不合法

7

不合法死循环

6

11,11,11

日期不合法

8

不合法死循环

7

1111,6,15

日期不合法

10

日期不合法

8

2501,6,15

日期不合法

11

日期不合法

9

1999,0,15

日期不合法

12

日期不合法

10

1999,13,15

日期不合法

13

日期不合法

11

1999,6,0

日期不合法

14

日期不合法

12

1999,2,15

1999-2-16

1,5,9,15

1999-2-16

13

1999,2,29

日期不合法

16

日期不合法

14

2000,2,15

2000-2-16

1,5,9,17

2000-2-16

15

2000,2,30

日期不合法

18

日期不合法

16

1999,1,15

1999-1-16

1,5,9,19

1999-1-16

17

1999,1,32

日期不合法

20

日期不合法

18

1999,4,15

1999-4-16

21

1999-4-16

19

1999,4,31

日期不合法

22

日期不合法

#include <stdioh>

#include <mathh>

//  自己根据需求换函数

double f(double x)

{

    return xxx - 15;

}

int main(void)

{

    double P = 1e-4;

    double a, b, c;

    printf("Please input a,b: ");

    while( scanf("%lf %lf",&a,&b) && (b-a)>P && f(a)f(b)>=0 ){

        printf("f(a)f(b) >= 0, please input again: ");

    }

    printf("Please input eps: ");

    scanf("%lf", &P);

    do{

        c = (a+b) / 20;

        if( fabs(f(c)) < P ){

            break;

        }else if( f(a)f(c) > 0 ){

            a = c;        

        }else{

            b = c;

        }

    }while( b-a >= P );   

    printf("x0 = %lf\n", c);  

    return 0;

}

一、 单元测试的概念

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

测试的覆盖种类

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 = 0;

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_flag=0,或者是i_flag<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=0; 假如开发人员一不小心写错了,变成了int i_temp=1; 根据程序导出的预期结果就会是一个错误的值,但是单元测试不出来问题,那单元测试就失去了意义。

有人也许会问这么简单的函数就有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都可以。

接下来根据测试结果编写测试报告,测试人,时间,结果,用例,是否通过,格式网上一大把,每个公司的格式也不一样就不说了。

在 app_utcpp 中添加测试流程和测试用例,为 Counter 类添加了三个测试用例,测试的执行顺序是按照定义顺序执行的。完成了测试用例的创建,我们需要编译测试项目,生成用于测试的可执行文件。编译框架可以根据自己的偏好选择,本例子中我们使用 cmake 管理代码编译,关于 cmake 的用法可以参照官方文档。

软件测试是软件开发过程中必不可少的一步,而单元测试是软件测试中最基础的一种形式。单元测试中,单元可以指代码中的一个模块、一个函数或者一个类;单元测试就是为每个单元编写测试用例,对该单元进行正确性检验,测试逻辑是否正确,确保每个单元的行为符合预期。因此单元测试的添加能够很大程度上降低软件或服务上线后出现问题的概率。

随着微服务、容器、云计算的发展,近些年 DevOps、CI/CD 等概念越来越多地映入大家的眼帘。DevOps 是现在流行的一种软件开发方法,将持续开发、持续测试、持续集成、持续部署、持续监控等贯穿到软件开发的生命周期中,用于提高软件的开发质量,被当前几乎所有顶级公司采用。

假设有一段钢轨 膨胀度=f 白天是x∈1-12 夜晚是y∈1-31

推论:对于一个含有n个变量的程序,采用边界值分析法测试程序会产生4n+1个测试用例(一个变量取最小值,略高于最小值,正常值,略低于最大值,最大值外,其余变量取正常值。对每个变量都重复进行 )。

以下是函数的相关介绍:

函数(function)的定义通常分为传统定义和近代定义,函数的两个定义本质是相同的,只是叙述概念的出发点不同,传统定义是从运动变化的观点出发,而近代定义是从集合、映射的观点出发。

函数的近代定义是给定一个数集A,假设其中的元素为x,对A中的元素x施加对应法则f,记作f(x),得到另一数集B,假设B中的元素为y,则y与x之间的等量关系可以用y=f(x)表示,函数概念含有三个要素:定义域A、值域B和对应法则f。其中核心是对应法则f,它是函数关系的本质特征。 

函数,最早由中国清朝数学家李善兰翻译,出于其著作《代数学》。之所以这么翻译,他给出的原因是“凡此变数中函彼变数者,则此为彼之函数”,也即函数指一个量随着另一个量的变化而变化,或者说一个量中包含另一个量。

以上资料参考——函数

1 语句覆盖指的是:代码中的所有语句都至少执行一遍,用于检测测试用例是否有遗漏。

首先画出程序流程图

为了是每个语句都执行一次,程序的执行路径应该是两条:abcefij ,abdfgij;

设计的测试用例只要覆盖这两条路径,就能将所有语句执行一遍;

a=1  b=-1  c=1

a=-1  b=1  c=1

2 条件判定覆盖指的是:设计足够的测试用例,是的判定中的每个条件的所有可能的取值至少出现一次,并且每个判定取到的各种可能的结果也至少出现一次。

由于条件判定覆盖是条件覆盖和判定覆盖的组合,所以只要取条件覆盖和判定覆盖测试用例的并集就可以。

条件覆盖:每个判断的条件的每一种可能至少执行一次。

对于判断语句 a>0 || b<0 :

条件 a>0 : 取真 T1 ,取假 -T1

条件 b<0: 取真 T2 ,取假 -T2

对于判断语句 c>0 :

条件 c>0: 取真 T3 ,取假 -T3

设计测试用例如表1所示:

判定覆盖的死性是使每个判断的真分支和假分支至少执行一次。

对于判断语句 a>0 || b<0 :  取真 M ,取假 -M

对于判断语句 c>0 : 取真 N ,取假 -N

设计测试用例如表2所示:

本回答以ECShop前台应用中用户注册、用户登陆、商品搜索等功能为例介绍测试用例设计活动。

1 用户注册

用户注册功能需求如图1所示。

 

图1用户注册需求

用户注册需求共涉及4个输入项和1个选择项。针对于输入项,利用等价类及边界值用例设计方法进行设计,选择项则无须设计在步骤中,在测试执行时分别执行勾选与不勾选即可。

01用户名

用户名共有三个条件:必填、不少于3个字符、不能重复,分别构造有效等价类及无效等价类,具体如表4-1所示。

 敏捷测试用例根据实际测试需要,不一定写的非常细致,如“用户名”包含字符类型,此处无须再划分纯字母、纯汉字、特殊符号等,构造数据时可混搭。

02email

email有两个条件:必填、符合规定格式,分别构造有效等价类及无效等价类,如表4- 2所示。

    

03密码

密码有两个条件:必填、不少于6个字符,分别构造有效等价类及无效等价类,如表4- 3所示。

   

04确认密码

确认密码有两个条件:必填、与密码一致,分别构造有效等价类及无效等价类,如表4- 4所示。

  测试工程师利用禅道设计用例,如图4- 5所示。

图4- 5用户注册功能测试用例

2 用户登录

用户登陆需求如图4- 6所示。

图4- 6用户登陆需求

用户登陆共有三个字段:用户名、密码、保存登陆信息,其中用户名、密码为输入框,保存登陆信息为选择框。因该需求比较简单,故无须分析过程,直接进行用例设计,如图4- 7所示。

 

图4- 7用户登陆功能测试用例

3 商品搜索

商品搜索需求如图4- 8所示。

图4- 8商品搜索需求

通过需求分析,商品搜索功能较为简单,测试用例设计时只需考虑一个搜索条件的测试,测试工程师从搜索功能开发角度考虑。

对于系统而言,如果数据库中存在某个关键字的商品,则应该显示,否则应当提示没有匹配的商品,故搜索用例设计不需要使用复杂的用例设计方法,测试工程师只需根据经验设计用例即可。

对于显示方式,存在显示方式、排序条件、排序方式三种,显示方式又分为小图列表、大图列表、文字,排序条件有按上架时间、按价格、按更新时间,排序方式有升序与降序,如果完全组合则有332=18种组合,测试工程师可利用正交试验用例设计方法进行设计。

通过分析,共有3个参数,每个参数分别有3、3、2个取值,因此需选择因子数、水平数都3,且试验次数最少的正交表。查询正交表,4因子3水平正交表符合条件,如表4- 5所示。

替换参数,得到表4- 6。

 多余因子4舍弃不用,排序方式中的3,可使用升序或降序任意填充,由于4因子3水平表中没有全部取2与3的情况,因此根据经验再补充两条,最终得到表4- 7所示的正交表。

表4- 7优化后的商品显示测试组合

结合搜索条件,利用禅道设计用例如图4- 9所示。

图4- 9商品搜索功能测试用例

通过上述过程,测试工程师完成测试用例的设计工作,评审通过后等待测试版本发布,然后进行测试用例执行、跟踪处理缺陷等活动。

现在比较常用的有cppunit,visualunit,c++testcppunit是开源软件,C++test是parasoft公司的,试用麻烦,而且价钱比较贵,没用过。visualunit是国产的C/C++单元测试工具,我用过觉得很不错,该公司的技术支持也很到位,在使用过程中遇到问题都能及时帮用户解决。

Visual unit最新的版本是21。

部分功能清单如下:

具有完善的桩功能,从开始编码到升级维护的各个阶段,均可对任意层次、范围的代码实施分割测试;

自动生成测试代码和用例框架;

可视化编辑测试用例,用简单语法判断各种输出,还可自动判断中间变量;

可在用例中随意模拟、控制子函数的行为,包括设定返回值、输出参数、成员变量、全局变量的值,多次调用同一子函数可以设置不同的行为;

自动统计语句、条件、分支、路径覆盖;

显示参数、成员变量、返回值等输入输出数据;

显示每个用例所执行的代码;

自动画出逻辑结构图,显示每个用例的执行路径;

显示逻辑结构图中任一语句块、分支、分支结构、路径的代码;

逻辑结构图可自由裁剪,语句块、分支、分支结构、路径均可删除/恢复;

用例设计器可轻松找出遗漏用例,实现100%的语句、条件、分支、路径覆盖;

自动描述程序行为,帮助整理、验证编程思路提高编程效率,快速排除程序错误;

增强调试器功能,自动支持后退、重复、可视化选择输入、调试中切换输入;

自动生成HTML格式的测试报告。

详细的资料,楼主可以上http://wwwkailesoftcn查找

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/langs/12188090.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-21
下一篇 2023-05-21

发表评论

登录后才能评论

评论列表(0条)

保存