共计 1510 个字符，预计需要花费 4 分钟才能阅读完成。
接口测试仅仅把握 Requests 或者其余一些功能强大的库的用法，是远远不够的，还须要具备能依据公司的业务流程以及需要去定制化一个接口自动化测试框架的能力。所以，接下来，咱们次要介绍下接口测试用例剖析以及通用的流程封装是如何实现的。
首先在做用例剖析之前，能够通过追究公司一年来所有的故障起因，定位问题起因，或者通过与 CTO、产品经理、研发、运维、测试考察，失去品质痛点，还能够剖析业务架构、流程调用，以及监控零碎理解到业务的应用数据，从而失去品质需要。
失去品质需要之后，通过与产品经理、项目经理、研发总监等对接后得悉待测业务范围、业务场景用例、业务接口分析，从而确定公司的测试计划。将测试计划与品质需要联合进行剖析，就能够开始进行业务用例的设计，而接口测试用例剖析，也在其内。
接口封装思维次要分为 3 个大维度：配置、接口封装、业务流程。其中：
- 配置次要用作依据配置文件获取初始配置和依赖；
- 接口封装遵循 APIObject 设计模式，对接口的调用进行形象封装；
- 业务流程则负责数据初始化、业务用例设计，蕴含有多个 API 造成的流程定义，不要再蕴含任何接口实现细节、以及断言。
上面将会与实战案例联合，进行具体的介绍。
因为信息安全起因，许多接口在传输的时候会对申请与响应进行加密解决，如果间接对这部分数据做断言显然是行不通的。还须要对这部分接口额定进行解密的解决之后，才能够对已解密的接口进行断言。
在进行实战之前，须要先筹备一个对响应加密的接口。对它发动一个 get 申请后，失去一个加密过后的响应信息。
先筹备一个 JSON 格局 demo：
应用 base64 对其做加密，失去一个加密后的文件 demo64.txt
应用 Python 命令在“demo64.txt”所在目录启动一个服务
启动后的样子如图：
如果申请胜利的话就代表环境曾经筹备胜利
调用 base64，间接对返回的申请做解密，即可失去解密后的响应，将解密后的响应转为 JSON 格局，此时就能够对这个返回值做断言且不会报错了。
这样的写法显然不够优雅，如果被测接口的协定发生变化，Requests 库无奈反对扭转后的协定，须要调用别的第三库发送申请信息，则还是须要批改底层的源码。碰到这种状况，能够减少一层封装，结构一层更加通用的发送办法。
首先须要通过一个字典的构造体，保留所有的申请信息，包含发送的协定、解码形式、申请 method 等等，而这种字典模式的构造体也为前面的数据驱动革新做好了一个重要的铺垫。
通过申请信息的构造体中的 schema，增加判断条件，去抉择不同的申请协定。举个例子，如果 schema 为“http”的话，就抉择调用被封装的 requests 库。
调用在 ApiRequest 类中的 send 办法发送申请并进行断言
如果面对不同的算法，还须要批改底层的源码，所以须要把算法封装。须要应用哪个算法，就应用哪个。封装的思维与下面雷同。首先在字典构造体中增加一个 encoding 字段，用来判断抉择的不同的加密条件。
还是通过申请信息的构造体中的 encoding，增加判断条件，去抉择不同的解密形式。
首先须要明确在面对一个加密的响应后果，能够应用什么样的解决形式：
1. 如果晓得应用的是哪个通用加密算法的话，能够自行解决。
2. 如果不理解对应的加密算法的话，能够让研发提供加解密的 lib。
3. 如果既不是通用加密算法、研发也无奈提供加解密的 lib 的话，能够让加密方提供近程解析服务，这样算法依然是窃密的。
本文次要讲的是在理解应用加密算法的状况下，如何解决这样的解密算法。然而封装的思路都是相通的，不论是面对哪种状况，都能够通过格式化的数据，指明数据的内容，并通过一层逻辑的封装，将加解密或者抉择的协定封装进去。
举荐学习