如果接口测试仅仅只是掌握一些requests或者其他一些功能强大的库的用法,是远远不够的,还需要具有根据公司的业务以及需求去定制化一个接口自动化测试框架能力。所以在这个部分,会主要介绍接口测试用例分析以及通用的流程封装是如何完成的。
接口测试用例分析
首先在做用例分析之前,可以通过追查公司一年来所有的故障原因,定位问题起因,或者通过与CTO、产品经理、研发、运维、测试调查,得到质量痛点,还可以分析业务架构、流程调用,以及监控系统了解到业务的使用数据,从而得到质量需求。
得到质量需求之后,通过与产品经理、项目经理、研发总监等对接后得知待测业务范围、业务场景用例、业务接口分析,从而确定公司的测试计划。将测试计划与质量需求结合进行分析,就可以开始进行业务用例的设计,而接口测试用例分析,也在其内。
质量需求 |
样例 |
测试痛点 |
公司的接口一直不稳定影响用户的使用 |
质量反馈 |
最近半年来出现了几次大的故障 |
回归测试 |
每次升级都会影响老的功能 |
测试策略 |
目前公司没有可靠的测试体系 |
重构测试 |
微服务化改造需要有良好的测试体系保证 |
接口测试封装思想
接口封装思想主要分为3个大维度,配置、接口封装、业务流程。其中配置主要用作根据配置文件获取初始配置和依赖;接口封装遵循apiobject设计模式,对接口的调用进行抽象封装;业务流程则负责数据初始化、业务用例设计,包含有多个api形成的流程定义,不要再包含任何接口实现细节、以及断言。后面将会与实战案例结合,进行详细的介绍。
基于加密接口的测试用例设计
由于信息安全的原因,许多的接口在传输的时候会对请求与响应进行加密处理,如果直接对这部分数据做断言显然是行不通的。还需要对这部分接口额外进行解密的处理之后,才可以对已解密的接口进行断言。
环境准备
在进行实战之前,需要先准备一个对响应加密的接口。对它发起一个get请求后,得到一个加密过后的响应信息。
先准备一个json格式demo
使用base64对其做加密,得到一个加密后的文件demo64.txt
使用python命令在“demo64.txt”所在目录启动一个服务
启动后的样子如图:
使用curl命令对这个服务进行get请求
如果请求成功的话就代表环境已经准备成功
实战练习
调用base64,直接对返回的请求做解密,即可得到解密后的响应,将解密后的响应转为json格式,此时就可以对这个返回值做断言且不会报错了
这样的写法显然不够优雅,如果被测接口的协议发生变化,requests库无法支持改变后的协议,需要调用别的第三库发送请求信息,则还是需要修改底层的源码。碰到这种情况,可以增加一层封装,构造一层更加通用的发送方法。
首先需要通过一个字典的结构体,保存所有的请求信息,包括发送的协议、解码方式、请求method等等,而这种字典形式的结构体也为后面的数据驱动改造做好了一个重要的铺垫。
通过请求信息的结构体中的schema,添加判断条件,去选择不同的请求协议。举个例子,如果schema为“http”的话,就选择调用被封装的requests库。
调用在ApiRequest类中的send方法发送请求并进行断言
如果面对不同的算法,还需要修改底层的源码,所以需要把算法封装。需要使用哪个算法,就使用哪个。封装的思想与上面相同。首先在字典结构体中添加一个encoding字段,用来判断选择的不同的加密条件
还是通过请求信息的结构体中的encoding,添加判断条件,去选择不同的解密方式。
总结:
首先需要明确在面对一个加密的响应结果,可以使用什么样的处理方式:
- 如果知道使用的是哪个通用加密算法的话,可以自行解决。
- 如果不了解对应的加密算法的话,可以让研发提供加解密的lib。
- 如果既不是通用加密算法、研发也无法提供加解密的lib的话,可以让加密方提供远程解析服务,这样算法仍然是保密的。
本篇文章主要提供的就是在了解使用加密算法的情况下,如何处理这样的解密算法。但是封装的思路都是相通的,不管是面对哪种情况,都可以通过格式化的数据,指明数据的内容,并通过一层逻辑的封装,将加解密或者选择的协议封装进去。