接口测试策略（四、代码示例框架的生成过程）

概述

---

前面几章介绍了接口测试的各种好处、流程、造数策略等等，但都是理论的内容，本篇用代码的形式，一步一步阐述接口框架的由来。 

 

pytest+requests最简接口测试

---

 

 

由上述代码可见，直接测试一个接口功能很简单，通过接口请求地址、接口请求头、请求体达成一个请求，再通过接口响应报文的断言判断该接口是否测试成功或失败。

但实际情况中的接口测试，往往是多个接口串联成一个场景，或者是有大量的接口要测试，这个时候，为了避免测试接口生成过多的脏数据，往往会对测试的前置和后置都做一些条件，一来避免重复工作，二来避免让脏数据干扰到后续的测试。这时候就用pytest的setup 和teardown方法可以改善。

如下所示：

 

公共方法

---

事实上在一个类里面很少会单独写一个接口的测试，更多的是像下面那样：

 

这时候我们发现，每次测试一个接口都要写日志，拉数据，做一样的步骤，那么，是不是可以简化一下，于是乎，就有了公共方法

 

有了公共方法后，我们的用例可以简化成下面那样：

 

对比之前的，是不是简化了许多，同样的，像读取excel数据、读取json、xml之类的数据的方法都可以归到公共方法里面去。

测试数据

---

多数接口在测试的时候会遇上这样一种情况，接口的内容几乎不变，变的只有接口里面的测试数据，像登录用例这种，一个登录接口，我们按等价类划分和安全考量去写用例会有如下场景：

用例1：账号密码正确，登录成功

用例2：账号正确、密码错误，登录失败

用例3：账号为空、密码为空，登录失败

用例4：账号错误，密码正确，登录失败

用例5：账号密码输入框输入xss攻击脚本，无法生效

用例6：账号密码输入框输入sql注入脚本，无法生效

这个时候发现，这6条用例都是共同用的一个登录接口，唯一的区别只是数据不一样罢了，这个时候，如果写6个方法去测试就有大量的重复工作。像下面那样：

 

好在我们做测试的时候有数据驱动的测试方法，pytest里面也支持。

如下所示：

 

通过@pytest.mark.parametrize装饰器可以大幅度简化我们的用例编写，同样的，如果遇到同个接口需要输入1000条数据呢，而且这1000条数据可能会被不断的维护更新呢？这1000条数据写在脚本里面就有些庞大且维护困难了，因此，很多时候这1000多条数据是作为一个数据文件存储起来的，如excel、xml等，这时候就需要建立个测试数据的目录存储这些文件，并利用读取这些文件的公共方法将数据读取到@pytest.mark.parametrize中。这就是测试数据目录的由来

测试用例

---

由上面的内容可以看到，通过上面那些方法可以进行大多数的接口用例测试了，但是当用例多了的时候，就不太直观的看到我们准备要执行哪些用例，执行的内容具体怎么样，都需要一一翻阅代码才能看出来，另一方面，由于测试人员的能力参差不齐，写出来的用例质量也难以评估，因此市面上的很多接口测试框架为了解决这一难题，做了一些变动，来看下比较受欢迎的httprunner的框架是怎么样的：

 

由上面可以看出，用例是可以通过录制然后经过脚本转化成接口用例的，这就解决了不会写代码人员的问题，但是，我并不推荐这么做，作为接口测试人员还是需要会一点编码知识的，这不仅仅便于维护我们的用例脚本，也可以更加深入明白我们的测试过程。

Allure测试报告

---

测试报告也是工作中很重要的一环，很幸运的是，Allure已经提供了很完美的报告。

实际工作中，我们还需要定期统计用例执行效率、用例的覆盖程度、用例的通过率、用例与禅道的关联等等，故上述的用例已经无法满足我们当前的需求，需要在这基础上进行深入的分析。

好处是，这一块已经不再需要我们自己重复造轮子了，已经有可以用的Allure模块供我们调用。调用效果如下所示：