如何自动生成测试用例方案

资料参考：

组合测试设计PK正交设计总结：https://www.testwo.com/blog/6376

组合测试工具集：http://www.pairwise.org/tools.asp

组合测试方法-配对测试实践：https://www.cnblogs.com/leeboke/p/5035892.html

 

一、目的

受体：测试经理，测试主管，质量管理员，技术经理

做测试的，不能这样说，应该是致力于软件质量监控，就应该清楚的知道一个项目哪些是可测的，哪些是无法测试的，这些可测和不可测的其实都应该得到监控，可以实时观察到各个监控点的健康正常的运行，而这篇文章就是针对可测的监控。

测试行业，又错了，应该是质量监控行业，肯定是要有一个指标的，要不然怎么确定哪些是达标的 呢？所以对于测试用例的监控就至关重要，测试的执行结果就是依据测试用例，怎么保证测试用例的质量呢？俗话说啊，一千个人就是一千个哈姆雷特，每个的观念啊，审美啊都TM的各种奇葩，所以用例制定的再怎么规范，人家就是不去执行，就是搞个小脾气、小动作之类的，你又能怎么样呢？把他灭了吧，换个新人，还会面临这个问题，所以如果能够自动控制用例的质量就好办了。所以就有了这篇文章，如何进行“自动测试用例生成”就是这篇文章的目的。

达到自动生成用例，就要分析用例的组成，注意啊，这里说的用例都是API用例，包含：URL、parameters、response

URL就不说了就是一个地址，parameters、response是要自动的对象，还有业务逻辑其实就是URL的组合。

对于parameters，是用例的各种场景组合的依据，parameter会有很多个且每个都会多个值，术语呢是：因素数、水平数

对于response，就是测试后的结果检查，是用例的最后一个部分。

 

二、parameters组合方法

我通过自己笨拙的Goole搜索，只找到两种具体方法进行parameters组合：

组合分析方法和正交实验设计法。

 

一）、组合分析法

组合分析方法(组合测试)，依据的是多因素组合测试可以生成测试用例集，以覆盖任意N个因素的所有取值组合，在理论上可以发现由N个因素共同作用引发的缺陷。简单的理解就是每一个参数的每一个值只需要和其他参数至少配对一次就够了。

 

pairwise算法

Pairwise是L. L. Thurstone(29 May1887 – 30 September 1955)在1927年首先提出来的。他是美国的一位心理统计学家。Pairwise也正是基于数学统计和对传统的正交分析法进行优化后得到的产物。

 

Pairwise基于如下2个假设：

（1）每一个维度都是正交的，即每一个维度互相都没有交集。

（2）根据数学统计分析，73%的缺陷（单因子是35%，双因子是38%）是由单因子或2个因子相互作用产生的。19%的缺陷是由3个因子相互作用产生的。因此，pairwise基于覆盖所有2因子的交互作用产生的用例集合性价比最高而产生的。

 

那么我们选择比较好的测试组合的原则就是:

 每个因子的水平值都能被测试到；

 任意两个因子的各个水平值组合都能被测试到，这就叫配对测试法。

 

 

《微软的软件测试之道》，里面也有关于组合测试的介绍，书中建议组合分析从两因素组合测试开始，逐渐提高组合维度，直至6因素组合测试，因为有研究表明6因素组合测试可以发现绝大多数的程序缺陷。

可以使用工具完成：PICT

The Pairwise Independent Combinatorial Testing tool 

https://github.com/Microsoft/pict

 

二）、正交实验设计法

正交试验法，就是从大量的试验点中挑选出适量的，有代表性的点，合理的安排试验。也是组合测试法的一种。

 

评价：这种方法对于软件行业，太不靠谱了，一个接口生成后的用例太TM的少了，还要认为去排查看要加上那些参数组合，太鸡肋了

 

可以使用工具完成，常用的工具有：Allpairs（有点像PICT工具使用，dos命令下运行）和ACTS。

Allpairs下载：www.satisfice.com/tools.shtml

 

三）、两种方法的总结：

说了那么多，其实首选就是组合分析法来组合parameter，生成测试用例，这样测试用例数量和质量比正交法都TM高的多，具体高多少，待我做下实验，后文再讲啦。(人家是人啦，不可能一直研究技术，生活这么美好，技术那里有家人好呢)

 

三、response判断

执行用例有了，那如何对用例结果判断呢？要实现自动化做好的解决办法，就是规范用例的response判断，什么场景用什么状态码，响应内容去哪个值可以做到对结果的校验，这些肯定要后端写清楚，难道要让我们看代码啊，那要后端干什么呢。

总结下接口文档或者是mockAPI需要规定的东东吧：参数是否可选、参数的类型|长度|特殊字符的response、参数的限制是在哪里(尽量是后端限制参数的所有东西)、是否需要token、response信息(不要只是code，还有具体的那个json值)...

比如：查询用户信息，我们除了校验code，还要对查询的内容是否正确啊。

 

四、组装战车(自动生成用例)

1，从mockAPI或接口文档，获取UIL、,参数对应的response(使用if,elif,else判断语言来进行参数组合返回的response的描述，简单易懂)

(if账户为空，返回A；

elif密码为空，返回B；

elif密码为错误，返回C；)

2，利用PICT工具，组合参数，这里叫参数对

3，编写工具：对参数对的结果进行逻辑判断，映射到response

4，编写工具：自动对用例进行执行