FavoriteLoading
0

[腾讯 TMQ] 组合测试从理论到实践——从吃货的角度实现组合测试用例的自动设计

作者:张丽颖##

从吃货的角度观察组合

作为一名合格的吃货,小编我每天为了吃的健康着实费了不少心思,每周我都会根据应季蔬果来定制一周的饮食,以下是我这周的定制计划:

蔬菜类: 豆角, 土豆, 莴笋, 青椒, 西红柿, 圆白菜, 芹菜

水果类: 葡萄, 西瓜, 苹果, 柑橘, 菠萝, 柚子, 香蕉, 李子

肉类(蛋白质类): 牛肉, 猪肉, 鱼, 鸡肉, 羊肉, 豆腐

汤类: 菠菜汤, 西红柿汤, 紫菜汤, 五谷粥

在不得不考虑食物相克相生的前提下,这些定制计划中必须要进行适当的搭配才不会把小编自己吃趴下,在上面的食谱中,不能同时食用的食物有:

l 羊肉和西瓜

l 李子和鸡肉

l 鸡肉和芹菜

l 土豆和香蕉

l 豆腐和菠菜

因此在做每日菜品的搭配组合时必须要考虑这些约束,不知道看到这里的你是不是开始头大了?别急别急,小编有秘密武器可以教你简单应对~

一、是什么?

就像上面介绍的故事一样,测试过程中我们也会遇到这样的场景:

有m个参数、且每个参数有多个离散但有限的取值N1、N2...Nm(其中Ni可以个数不等,1<=i<=m),为了覆盖参数的全部取值组合,需要N1*N2*...*Nm个测试用例。

譬如经过对需求的分析,得出我们需要验证IE在不同硬件配置的PC上的兼容性测试,且经过数据统计,主要用户占比的PC信息如下图所示:

并且需要验证的IE版本如下图所示:

在这种场景下,要达到对参数的所有取值组合的覆盖,共需要3*3*4*2*4*4=1152条用例,若按120条/人日的执行力计算,这个需求的测试执行需要耗时9.6人日,这在敏捷迭代节奏的项目中是不太可行的,所以这种情况下我们可以考虑测试成本和错误检测能力上能达到较好平衡的组合测试方法。

像上面测试场景中提到的有多个参数、且每个参数有多个离散但有限的值,致使可能组合的参数值总数非常大,我们称之为组合爆炸。

而组合测试的目的,抽象的说就是为组合爆炸提供一种解决方案,简单地说就是在保证错误检出率的前提下采用较少的测试用例生成方法,它将被测系统或被测系统的模块抽象成一个受到多个因素影响的系统,并提取出每个因素的可能取值,结合组合测试方法,生成最终的测试用例。

根据上面的分析,我们可以了解到组合测试需要解决的最大问题就是:没有足够的测试资源来执行全部的测试用例,因此提出了基于一个数学模型和一个假设的解决方法,如下:

一个数学模型:产品的功能被抽象为函数f,产品的输入被抽象为函数的变量x1,x2,…,xm,且xi(1≤i≤m)的可能取值是有限的,产品的输出被抽象为函数的返回值y1,y2,…,yn;

一个假设:如果测试覆盖了任意t个(2≤t≤m)输入变量的取值组合,那么该测试可以发现函数f的大部分错误。

常用的组合测试方法包括:

1、两因素组合测试(也称配对测试、全对偶测试)

生成的测试集可以覆盖任意两个变量的所有取值组合。在理论上,该用例集可以暴露所有由两个变量共同作用而引发的缺陷。

2、多因素(t-way,t>2)组合测试

生成的测试集可以覆盖任意t个变量的所有取值组合。在理论上,该测试用例集可以发现所有t个因素共同作用引发的缺陷。

3、基于选择的覆盖

要满足基于选择的覆盖,第一步是选出一个基础的组合,且基础组合中包含每个参数的基础值,建议选择最常用的有效值作为基础值。基于基础组合,每次只改变一个参数值,来生成新的组合用例。

关于多因素组合测试在缺陷检出率方面的贡献,IEEE文章提到早期的一些回顾性研究结果:

从上图可以看出,两因素组合最多能发现95%的缺陷、平均缺陷检出率也达到了86%,而对于三因素组合甚至更高因素的组合能发现的缺陷是非常有限的,一般情况下,超过90%的软件缺陷,都是由3个或更少的参数值触发的。因此任何测试设计中都应该至少保证两因素组合的100%的覆盖测试。有着高可靠性需求的应用,比如医疗设备或者航空电子设备,应该保证至少3-way因素组合的100%的覆盖测试。

由于两因素组合测试在测试用例个数和错误检测能力上达到了较好的平衡,它是目前主流的组合测试方法。

接下来小编带你进入快捷的利用工具进行用例生成的阶段~~

二、怎么做?

在利用组合测试方法生成测试用例的过程中,小编推荐使用PICT工具(下载地址:http://download.csdn.net/source/3078728PICT工具是一个从2000年开始在微软被使用的测试用例生成工具,它实现了t组合测试策略,可以有效地按照两两测试的原理,进行测试用例设计。在使用PICT时,需输入与测试用例相关的所有参数,以达到全面覆盖的效果。),

PICT的使用相对简单,PICT是一个命令行工具,接受纯文本模型文件作为输入,并输入一系列测试用例。PICT的可选参数如下:

更详细的说明详见PICT安装目录下的PICTHelp.htm文件

PICT安装时会自动加入环境变量path中,因此你可以在任何目录下执行。

参考我们在“是什么”部分中提到的案例,接下来小编将使用PICT工具边介绍边实践。

PICT接受一个输入文本模型文件,你可以使用Windows的记事本来保存(假设保存为ModelFile.txt),如下图:

其中每个参数占一行,参数和参数值之间以英文冒号分隔、参数值之间以英文逗号分隔。

通过“>”符号可以将输出重定向到xls文件中(假设输出文件为OutputFile.xls),使用如下命令运行PICT:

生成的结果如下:

每一行即为一条测试用例,通过此方式生成了共计20条测试用例,若按120条/人日的执行力计算,仅需0.17人日,相对于“是什么”部分的9.6人日的测试耗时,测试成本大大降低,组合测试的优势不言自明。

事实上,如果这六个参数中的某两个参数值的任意不同的组合会触发一个bug的话,那表格上的那组测试用例也可以发现该bug。当三个特殊的值组合在一起触发的某个bug,那表格上的那组测试用例不一定能发现该bug,但是至少我们覆盖了所有的两因素组合。相对于所有组合情况来说,两因素组合的测试覆盖率要容易很多。例如,如果你想测试10个参数且都有26个值的功能,所有组合情况将生成141,167,095,653,376个测试用例。而两因素组合就只要测试1094个测试用例就可以。

三、精彩在这里!

看到这里,你是不是已经迫不及待要找一份需求来练手了呢?别急,精彩还在继续!

1、定义因素之间的约束关系

上文的例子中参数之间是互相独立的,但大多数被测试应用的因素之间存在约束关系。如果不考虑约束关系,组合测试用例集将包含大量的无效测试用例。这些无效的测试用例,包含一些无效的取值组合,也有可能包含一些有效的取值组合。仅仅删除无效测试用例,会导致最终的测试用例集不能实现两因素或多因素组合覆盖。面对因素之间存在约束关系的被测试应用,应该明确定义约束关系,让组合测试工具根据约束来生成有效的测试用例集。

因此我们需要在设计PICT输入模型时,加入约束限制,好在PICT工具很强大并在设计之初就考虑到了这点,以本文最开始的故事为例,除了多参数、多值以外,还存在着参数值之间的约束关系,修改我们在上文中的输入文本文件如下:

即如果肉类是羊肉,则水果类不能选择西瓜,其他以此类推。当PICT读取模型文件时,它会解析约束规则,并将其应用于测试用例生成过程。生成的测试用例集既满足对有效取值组合的覆盖,又不包含无效取值组合。

执行PICT命令行,生成的食谱合理搭配如下:

共计58种组合选择,完全满足一周的营养健康搭配需要了(yeah!!!)

2、引入随机种子

看到这里,资深吃货一定会问:上面的58种组合最多只能吃一阵子,然后就不得不重复食谱了-_-|||,针对这个问题,PICT也提供了随机种子来应对。PICT采用的是伪随机算法,输入不变的情况下,输出的测试用例是相同的,因此引入随机种子,在测试成本相同的情况下,改变组合次序,测试执行可以执行更多的路径,覆盖更广大的状态空间,发现隐藏缺陷的概率也会提高。

在PICT中,参数"/r[:N]"可以为测试用例生成引入随机种子(N是作为随机种子的整数),以生成不同的测试用例。譬如我们分别尝试不带种子、和带种子100的食谱搭配结果:

结果如下:

从上图可以看出,在引入随机种子后,组合次序发生了变化,但是组合个数一样。这样大家可以在不提高测试成本的前提下,提高覆盖率。

3、覆盖最最重要的组合,即基于选择的覆盖

追求完美的吃货可能还会发现,上面那么多食谱组合,竟然没有组合到他最爱的搭配,例如:豆角 香蕉 猪肉 五谷粥,即组合测试可能会错过最重要的取值组合。

上图是Word 2010“高级”设置的一部分,每个复选框都是一个因素,每个因素都有“勾选、未勾选”两个选择,为了测试Word在不同设置下的行为,对所有因素生成组合测试用例集。但是该测试用例集很可能没有覆盖Word的默认设置。事实上,大多数用户几乎不修改默认配置,测试用例集没有覆盖最常用、也是最重要的取值组合,所以建议使用“基于选择的覆盖”方法。这揭示了组合测试的一个潜在风险:如果测试人员不仔细分析被测试对象,只依赖组合测试工具,他可能错过用户最常见的测试用例。

4、警惕卫哨语句

为了设计更合理的测试用例,大家不光要从需求分析输入、更要从代码层次分析输入,因为许多软件会利用卫哨语句来“过滤”无效的输入。例如,在如下代码中,if语句会“过滤”掉所有A<=0的输入。

如果不了解代码中的卫哨语句,可能会将输入定义为:

生成的输出中

在这10条测试用例中,因为A<=0,有6条测试用例会被if语句过滤掉。所以如果忽视了卫哨语句对执行流的中断,组合测试用例集将不能达成两因素或多因素覆盖的目标 。

面对此类问题,测试人员要仔细阅读规格说明或源代码,发现会导致执行流中断的“负面”取值。在PICT的模型中,支持用特殊符号"~"标记出非法值,例如在上述模型中将A的取值0标记为非法值。

PICT会保证所有有效值的取值组合都会被覆盖,此外任意非法值与有效值的组合也会被覆盖。以上模型将生成如下测试用例集。

5、多因素组合

如果你觉得两因素组合不能满足需求,可以利用多因素组合和子模型来定义不同的强度组合。

PICT通过参数/o:N支持多因素组合,譬如上图中的案例,未定义/o参数则默认采用的是两两组合,一共生成了12条用例;改成三因素组合的话:

会生成27条测试用例:

在提高覆盖率的同时,测试成本同时也增加了100%以上,因此大家在考虑提高覆盖率的同时必须将测试成本加入考量。

或者大家若可以确定在M个参数中有N个参数的组合是非常重要的,那么这种情况下,小编推荐使用子模型,着重对N参数的组合加大覆盖率:

如下输入中有ABCDE共5个参数,每个参数的值都是0, 1,小编定义了”(B, C, D) @ 3”子模型并设置为3因素覆盖,

生成的组合展示如下:

该模型除了所有因素的两两覆盖外,还着重对BCD三个因素做更高阶的覆盖,而且测试成本也相对没有提高太高,具有可执行性。

四、写在最后

工具的使用说了这么说,其实重点还在于大家对需求的透彻理解和分析,总结起来就是:

1、 一定要注意分析元素间的约束条件,避免生成多条无效测试用例,还增加了测试成本。

2、 确定建模的输入时,需要重点分析各个参数的值,尤其是一些有代表性的值,着重分析各类参数值对结果的影响。

3、 PICT还有更多的属性可以应用,请参考PICT安装目录下的PICTHelp.htm文件。

本章完~

原文链接:http://tmq.cs0309.3g.qq.com/2016/09/combination-test-from-theory-to-practice-from-the-angle-of-version-combination/


TMQ(腾讯移动品质中心)是腾讯最早专注在移动APP测试的团队
我们专注于移动测试技术精华,饱含腾讯多款亿级APP的品质秘密,文章皆独家原创,我们不谈虚的,只谈干货!

扫码关注我们


声明:本文转载自 TesterHome 移动测试社区,作者为 TesterHome 移动测试社区,原文网址:https://testerhome.com/topics/6092

最后编辑于:2016/11/16作者: 聚合

聚合类文章源自互联网, 感谢原作者的无私分享。

关注微信公众号 – 聚合软件测试类精华

关注微信公众号 – 聚合软件测试类精华