常见分布式系统 Mock+Proxy在SDK项目的自己主动化测试实战(4)

说了那么多。再回到我们之前提到的设计策略几个需求，能够觉得pairwise算法的特征基本满足了我们的需求。

难点三：测试用例自己主动化生成

确定了用例设计的算法策略后，我们信心十足的准备开始设计我们的response返回值case了，我们套用文献中的排列分布方式应用到实际接口json中，悲伤的发现我们要组合的字段不是3个。而是20-35个左右，假设通过人工的方式来进行case设计的话，就算仅仅考虑最多两个字段的值发生变化。数量也是非常惊人的，WWWWWWhat？？？

本着“偷懒是人类进步的第一动力”的想法，我们自然不会前功尽弃，自己主动化测试是我们的必选之路，接下来要做的就是调研眼下已经存在的基于pairwise算法的工具有哪些，以下是经过调研后得到的工具列表。

基于pairwise算法的工具如此之多，那么同样模型设定下产生的结果是否存在差异呢？我们看一下这张图：

综合比较各工具产生的数据结果后，我们能够发现不同工具之间的结果差异并不大，基本上能够满足我们现有的需求。经过一番讨论后，我们决定采用微软的PICT（https://github.com/Microsoft/pict）作为case生成工具。原因有几点：

1. 代码开源可扩展

2. 源代码依旧在维护。贡献比较活跃

3. 产品成熟，语法丰富

4. 基于贪心算法。局部最优解

难点四：测试用例生成的设计

用例生成过程分为五个步骤：

1. 准备字段值

依据Wiki的接口文档，测试人员理清字段结构。字段类型，字段取值范围后，结合传统的case设计理念。构造出每一个字段的赋值。存放到整理好的excel中。大概是这种：

有的同学可能会问：你这样整理也挺麻烦。感觉人工也没省多少事儿。这样设计的优点是，当字段发生变化的时候。仅仅须要从源头改动字段属性、值、层级、甚至删除，后面整个流程中的case都会统一生效，字段集中管理。牵一发而动全身。和UI自己主动化用到的page-object设计相似。

2. 构建模型

有了面粉了。还须要加工一下才干变成我们想要的面包，我们须要把准备的数据整理成能够批量生成的可识别文件，即模型文件。PICT的模型文件有自己的格式。相似这样：

参数定义
[子模型定义]
[约束定义]

举个样例，前面提到的订票系统的样例加工成模型文件是这种。后面会给大家介绍语法含义：

Destination:  Canada, Mexico, USA
Class:  Coach, Business Class, First Class
Seat Preference:  Aisle, Window
{Destination, Class} @ 2

3. 生成Case

通过pairwise工具将模型文件组装成我们想要的case，那么上面的模型生成的case会是这样：

Destination Class Seat Preference

注：选择强度为2，因此上面的矩阵是两两变化的。

如前面所说，这里生成的矩阵内容不是固定的！

4. 准备期望结果

输入数据已经准备好了，那么相对于case而言，是不是还缺一个期望结果呢？在这里我们碰到了一个难题，可能做过case自己主动生成的同学都会遇到的，就是生成排列组合是非常easy的，怎样让这些组合变得有意义，体如今我们的期望结果上。那么一次性生成如此多的case，怎样让输入值和期望结果对号入座呢？

我们的做法是：拆分了postive testing 和 negative testing（合法输入测试和非法输入测试或负面测试）。通过整理接口case我们不难发现。合法输入的case事实上占整个case的比重并不大。工作量比较大的是各种参数的异常数据输入，相应的会产生error code或二次请求。仅仅须要我们在整理数据的时候给出相应的error code就可以，如图所看到的：

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-81263-4.html