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

匿名 · 2016年10月11日 · 最后由大风回复于 2017年06月16日 · 4131 次阅读

作者：张丽颖 ##

从吃货的角度观察组合

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

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

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

肉类（蛋白质类）: 牛肉, 猪肉, 鱼, 鸡肉, 羊肉, 豆腐

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

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

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 的默认设置。事实上，大多数用户几乎不修改默认配置，测试用例集没有覆盖最常用、也是最重要的取值组合，所以建议使用 “基于选择的覆盖” 方法。这揭示了组合测试的一个潜在风险：如果测试人员不仔细分析被测试对象，只依赖组合测试工具，他可能错过用户最常见的测试用例。