本迭代接口测试总结

接口测试前期准备：

1. 了解本期迭代涉及到的接口有哪写，其中哪些是新增的，哪些是修改的，让服务端开发提供接口文档，查看涉及到的接口的接口文档。
2. 了解接口相关业务，了解除了新增和修改的接口之外本迭代业务需要用到的接口，哪些业务及操作会触发哪些接口，使用抓包工具了解已有的相关接口，找前端或客户端开发沟通，了解并确认相关的业务都调用了哪些接口。
3. 整理接口测试的业务逻辑，列出大致思路，不用预先在jmeter中编写，本迭代预先编写了一些接口测试用例，后来都删除重新写了，因为业务涉及到的接口没有了解的很详细，而且实际接口测试过程中使用的具体数据和返回的具体数据事先不能完全确定，由此会导致事先写的用例会有很多要修改的地方
4. 在jmeter中添加业务涉及到的每个接口的http请求，已有的接口可以运行一下，将要新增的接口先填写好协议、服务、端口号、方法、路径、badydata、返回，只需对每一个接口写一个http请求，方便后续写接口用例时用到

接口测试中注意的：

1. 对于qa和正式的变量不一致的情况（不是过程生成的变量或时随机变量），不要写死这些数据，需要将这些变量写到csv文件中，方便后期的修改，csv不用的变量需要删除
2. 对于多人协作的情况，可以合理拆分成几个小模块，然后及时同步使用到的相同的变量及变量名称，最后整理到一起，本地运行没有问题后，再上传到git上
3. 写完接口用例后进行检查，检查逻辑、请求参数、返回校验是否合理正确，尤其是拷贝用例修改的时候要对请求及返回进行检查
4. 可以在每个线程组添加查看结果树及Debug Sampler，方便查看每个线程组的结果或问题定位
5. 对异常的考虑，比如必填为空，必填参数类型不正确，重复发送等，本期出现了请求参数填写不正确的时候，消息一直没有消费的情况，导致rabbitmq消息堆积的情况
6. 对于不同的操作可能对同一个数据进行修改的情况，需要考虑并发的情况，这种有可能造成数据错误的情况
7. 对于可能频繁请求接口的情况，需要使用压力测试，在线程组中设置线程数及循环次数

关于循环控制器的使用：

对于变量循环的情况，可以考虑使用循环控制器，例如下面X代表0或1或2，表单ocr审核状态有3种情况，表单人工审核状态需要3种情况，这样组合总数有9个，每个都需要有查询，总共18条http请求，如果采用循环控制器，则减少了编写的http请求数，这里采用两层循环，外层的循环数是3，内层的循环数是3，外层的变量每次加1，内层循环测变量也是每次加1，注意这里需要使用BeanShell Sampler，不能使用BeanShell PreProcessor，因为BeanShell PreProcessor是每个http请求前都会执行

image.png
image.png
image.png
image.png
image.png