jmeter单接口和多接口测试

　最近接触到了多接口串联，接口串联的技术会在其他帖子有说明，其核心技术点就是通过正则表达式和变量来实现接口的关联。目前为止呢笔者用到的地方还只有一个，就是关于session保持的时候。但是看到很多资料都说测试过程中经常遇到b接口需要用a接口的返回数据，但是笔者到目前都没怎么遇到过，思来想去，是笔者打开方式不对吗？于是专门找了一块流程上有前后关系的地方进行实践，以下就详细说说这次学习成果。

在本系统中有一个类似如下的业务场景：

业务场景：电商平台中，客户退货流程。客户提出退货申请-退货申请发送至商家-商家处理退货申请-客户确认退货成功
待测功能：查询该用户进行中的退货进度

难点1：商家回复处理过程在商家平台
难点2：无法从上一接口的相应信息提取有用字段，提交申请返回就一个true，连id都没有，等于接口没办法关联，但是实际又是存在业务逻辑的前后关系

针对以上场景我设计了两种测试方案：

方案1：单接口测试，数据写死，固定测试数据，针对性设计不同的订单数据，对基础数据要求比较高
　　自动化流程：1先手动生成各类型，处于各阶段的退货订单
　　　　　　　　2调用查询退货进度接口查询对应客户的退货订单，并断言与步骤1生成的数据是否一致

　　优点：单个工作量小，接口独立，稳定性高。
　　缺点：数据维护成本高，真实性差，每个接口都需要大量数据测试

方案2：接口关联，模拟业务流程，通过接口控制数据的传递，只需要给出初始订单数据，即可模拟出业务流程中的动态数据流。
　　自动化流程：1 调用新增退货申请接口，新增退货申请并发送商家
　　　　　　　　2 调用查询退货进度接口查询步骤1生成的订单，断言是否查询到步骤1生成的数据，是否处于对应进度（已提交）
　　　　　　　　3调用商家回复接口回复申请
　　　　　　　　4 调用查询退货进度接口查询步骤1生成的订单，断言订单是否正确（商家已处理）
　　　　　　　　5 调用用户确认接口，确认退货成功
　　　　　　　　6 调用查询退货进度接口查询步骤1生成的订单，断言订单是否正确（退货完成，订单关闭）

　　优点：真实性强，数据易于管理，更清晰更流程化
　　缺点：工作难度大，工作复杂，代码维护成本高，稳定性差

总结

方案一偏向接口功能测试，测试接口对于不同数据的处理情况。方案二偏向业务流程测试，测试不同的业务流程中数据的变化及接口的处理情况，更真实模拟实际场景

笔者做完后发现，这不就有点像单元和集成的关系嘛。最终笔者选择了方案一，因为笔者公司不止一个人，除了待测的查询进行中订单状态接口外的其他接口并不在我负责范围，所以我只需要针对我的接口进行针对性测试即可。其实选择哪种测试方式并不重要，自动化的目标旨在降低测试成本，提高测试效率，适合自己的方式，就是最好的了。

【2023性能测试完整版】这可能是B站讲得最好的软件测试课程（Jmeter 接口测试实战 Loadrunner Tomcat综合教程）软件测试面试、自动化测试。

总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

文档获取方式：点击右边链接领取：软件测试全套资料分享