接口测试仅仅掌握 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 的话，可以让加密方提供远程解析服务，这样算法仍然是保密的。
本文主要讲的是在了解使用加密算法的情况下，如何处理这样的解密算法。但是封装的思路都是相通的，不管是面对哪种情况，都可以通过格式化的数据，指明数据的内容，并通过一层逻辑的封装，将加解密或者选择的协议封装进去。
首先在做用例分析之前，可以通过追查公司一年来所有的故障原因，定位问题起因，或者通过与 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 的话，可以让加密方提供远程解析服务，这样算法仍然是保密的。
本文主要讲的是在了解使用加密算法的情况下，如何处理这样的解密算法。但是封装的思路都是相通的，不管是面对哪种情况，都可以通过格式化的数据，指明数据的内容，并通过一层逻辑的封装，将加解密或者选择的协议封装进去。
