@@@@@@@@@@@@@@@
# 路漫漫其修远
最近接触到了多接口串联，接口串联的技术会在其他帖子有说明，其核心技术点就是通过正则表达式和变量来实现接口的关联。目前为止呢笔者用到的地方还只有一个，就是关于session保持的时候。但是看到很多资料都说测试过程中经常遇到b接口需要用a接口的返回数据，但是笔者到目前都没怎么遇到过，思来想去，是笔者打开方式不对吗？于是专门找了一块流程上有前后关系的地方进行实践，以下就详细说说这次学习成果。
在本系统中有一个类似如下的业务场景：
业务场景：电商平台中，客户退货流程。客户提出退货申请-退货申请发送至商家-商家处理退货申请-客户确认退货成功
待测功能：查询该用户进行中的退货进度
难点1：商家回复处理过程在商家平台
难点2：无法从上一接口的相应信息提取有用字段，提交申请返回就一个true，连id都没有，等于接口没办法关联，但是实际又是存在业务逻辑的前后关系
针对以上场景我设计了两种测试方案：
- 方案1：单接口测试，数据写死，固定测试数据，针对性设计不同的订单数据，对基础数据要求比较高
自动化流程：1先手动生成各类型，处于各阶段的退货订单
2调用查询退货进度接口查询对应客户的退货订单，并断言与步骤1生成的数据是否一致
优点：单个工作量小，接口独立，稳定性高。
缺点：数据维护成本高，真实性差，每个接口都需要大量数据测试
- 方案2：接口关联，模拟业务流程，通过接口控制数据的传递，只需要给出初始订单数据，即可模拟出业务流程中的动态数据流。
自动化流程：1 调用新增退货申请接口，新增退货申请并发送商家
2 调用查询退货进度接口查询步骤1生成的订单，断言是否查询到步骤1生成的数据，是否处于对应进度（已提交）
3调用商家回复接口回复申请
4 调用查询退货进度接口查询步骤1生成的订单，断言订单是否正确（商家已处理）
5 调用用户确认接口，确认退货成功
6 调用查询退货进度接口查询步骤1生成的订单，断言订单是否正确（退货完成，订单关闭）
优点：真实性强，数据易于管理，更清晰更流程化
缺点：工作难度大，工作复杂，代码维护成本高，稳定性差
总结
方案一偏向接口功能测试，测试接口对于不同数据的处理情况。方案二偏向业务流程测试，测试不同的业务流程中数据的变化及接口的处理情况，更真实模拟实际场景
笔者做完后发现，这不就有点像单元和集成的关系嘛。最终笔者选择了方案一，因为笔者公司不止一个人，除了待测的查询进行中订单状态接口外的其他接口并不在我负责范围，所以我只需要针对我的接口进行针对性测试即可。其实选择哪种测试方式并不重要，自动化的目标旨在降低测试成本，提高测试效率，适合自己的方式，就是最好的了。
--以上内容均为笔者原创，转载请注明出处，如有不当欢迎指正