接口测试｜从0不到1的心路历程

在众多建议中，频率最高的就是"pytest+requests+allure"的组合了，随后我就学习了pytest和allure的相关知识，并且在项目中进行了实践。本次我就总结一下基于这个框架的阶段性成果，希望伙伴们继续纠偏指点。

书接上文 - 第三代测试框架

第三代测试框架是基于unittest+requests实现的，使用ddt库实现了数据驱动测试，使用excel管理测试数据，以及使用excel持久化接口响应的相关信息，具体细节感兴趣的小伙伴可以点击查看上篇文章：接口测试 - 从0不到1的心路历程。依据这个模式写了30个接口的case，发现如下问题：

1.编写测试数据生成函数时，不光要写数据生成逻辑的代码，还要写将测试数据写入excel的代码，导致整个函数冗长，函数职能不单一。

2.使用excel保存接口响应的相关信息，每个接口单独占据一个sheet页，这种方式一旦接口数量过多，最终查阅起来并不方便 (首先打开 excel，然后查找目标sheet，然后再查找目标case)。

学习allure之后，发现allure可以记录接口的入参及接口响应等信息，基于此就可以完美解决上述问题，测试数据生成函数仅需要编写数据生成逻辑，无需再写处理excel相关代码。接口响应等信息直接使用 allure.attach() 方法就可以记录在报告中，所以也就不用再像版本三一样编写收集接口响应信息并写入到 excel 的函数了。先上两张excel报告和allure报告的效果对比图，然后再叙述第四版框架的堆砌过程。

初识pytest

我主要是通过《pytest 测试实战》这本书学习pytest的，这是一本工具书，整书不厚，看完前四章就可以动手实战了，有兴趣的伙伴也可以看一下。pytest的优势在此就不过多赘述了，不过我认为还是很有必要了解一下pytest和unittest 的区别的，我在网上借了一张对比图，刚了解pytest的伙伴可以参考下。

在pytest使用过程中，有三点优势是我切实感受到的：

1.pytest使用assert关键字来进行断言，相比unittest的断言就四个字：简洁明了

2.pytest提供的失败重跑插件"pytest-rerunfailures"。

例举一个使用场景：case1为新建商品，新建成功后保存商品 id，case2为编辑商品，需要使用case1保存的商品id。在运行测试脚本时，case2有一定概率会报错，提示被测系统中不存在此商品id，但事后手动执行case2发现并没有问题。究其原因可能是case1的新建接口新建完商品后需要一定的时间进行数据落库等操作，但运行测试脚本时，case1和case2的衔接时间又很短，导致case2有一定概率会报错。在使用 unittest 框架时，对于这种场景，我一般会在case2发送请求前强行休眠1秒：sleep(1) ，不过像这种蠢呆呆的代码我都会用遮羞布盖住，生怕别人看见。不过接触到"pytest-rerunfailures"插件后，再也不用担心这个问题了，只能用四个字形容：极其好用！

前提条件：pytest (>=5.3) 和 python >=3.6
 

安装：

• pip install pytest-rerunfailures

• pip show pytest-rerunfailures

使用：

• 命令行参数：