接口阶段总结(上)
给你一个项目,接口自动化测试怎么开展的?
1、需求分析 -
1.了解业务/功能 -
2.项目现状TDD -
2.1 那些模块适合做自动化测试,那些不需要
2.2 如果这些项目只有半年时间,不需要做自动化
2.3 自动化项目都是一些长期迭代的项目适合做
2.4 项目有一定的周期,
2.5 历史功能的回归测试- 覆盖一些手工测试的旧功能,提高效率
2.6 TDD - 就是测试驱动开发,测试与开发保持同步,注意的是开发人员一定要做单元测试
2.7 接口自动化是自动化里面效率最高的,稳定性比较好
3.历史功能/稳定的功能/新的功能/线上问题最多的历史功能模块?核心功能/自己负责的部分
2、接口的了解 -
1.首先是要了解接口文档以及他的属性业务,可以通过一下方式来了解:
swagger:
1.1 swagger(可以自动生成接口文档):前提是开发人员要配合,开发人员要按照一定的规则来写,否则则是生成不出来的
swagger生成机制:根据开发人员的代码里面按照他的规则去识别到对应的接口,把他的信息拿过来
1.2 yapi:
抓包(不建议):
1. 需要花费较多的时间,特别是比较多的时候,会懵,
2. 这个方式只适合辅助你去了解接口的业务,并不能决定接口文档
向上抛出-
1. 找领导协商外部资源,开发提供接口
2. 领导之间协调比较好
3、自动化框架或者工具的选择:
1. 工具的可扩展性以及扩展语言
1.1 测试接口的工具:postman/soapui/HttpRunner
1.2 如果有指定用指定的,如果没有指定,使用自己最熟悉的那个工具
选择什么工具需要看所处的环境
1.3 还要确保几个复杂的接口这个工具可以实现,例如在:鉴权和断言方面的处理
4、写接口用例?
1.在面试的时候特别要注意一个问题:
比如有个面试官问你:你们项目做了多少个接口的自动化,你如何回答?
1.一般回答至少要50+个接口,少于10个没必要做接口的自动化
2.假设平均每个接口5个用例,50个接口也有至少也有1000条用例
3.写用例(excel里)花了多长时间?需要注意回答
3.1 初期可能接口业务不熟悉,进度比较慢,一天1-2个接口左右
3.2 后期做熟练了,速度自然而然就提升了,基于业务的理解,可能一天5-6个左右
3.3 还需要看接口的复杂程度,简单比较快,难得可能一天一个都有可能
4. 你一天写多少个用例?
4.1 一个接口至少15+个用例,写完需要进行运行调试,修改,都需要时间
4.2 一天至少5个用例,这里的用例是包括 excel的用例和加代码 一起
2.写接口用例脚本,要尽可能的早加入jenkins集成
2.1 一般来说做了1-2个接口的时候就要考虑进行jenkins集成
2.2 问题可以早点发现,进行调整优化
2.3 每天用例数量的增长过程,在jenkins平台上一清二楚,包括通过率,在一个持续的调试和优化中,
减少自己脚本的问题,如果出现错误,那就是接口那边的问题,可以看到整个接口自动化的的曲线,
可以有一个比较好的数据让领导看到
3.需要定期汇报
4.测试报告 -
1.需要去分析用例失败的原因,是接口还是脚本处理上的问题
5.从你最开始做自动化,到一直做自动化的一个过程中,你需要做:
1.需要按照日期记录下发现的bug,可以形成一个历史bug的曲线
2.用excel或者其他记录
5、所有的用例脚本写完了就进入——维护阶段
1.如果开发修改了接口,那么我们也需要同步修改我们写的用例,保持一致
2.新增接口,在现有的基础上新增新的接口
3.遇到了问题或者哟了新的方案,进行优化框架,使框架更加完善
4. 一个项目做自动化的时候,只是一个框架,不会是两个
自动化测试方案?
6、自动化框架提供了哪些功能
比如说我用你的框架,可以使用哪些功能?
1、编写用例(前置后置、断言)、执行用例、数据库校验,生成测试报告。
2、日志功能,回溯问题
针对接口测试:
1.配置文件的处理
2.excel用例数据的读取-数据参数化(数据驱动思想)实现
3.http请求封装:鉴权处理,请求头处理,url处理,data的处理,发送请求
4.接口关联的处理,接口之间的传递
5.提取响应的结果的提取
6.数据替换处理
7.连接数据库的处理
8.数据生成处理
9.路径的处理
7、框架的整体结构、结构设计
1.进行分层设计思想,每个py文件放在指定的目录下,避免路路径混乱
2.可以更加有效的进行操作,比较清晰明了
3.分层设计思想主要有以下几层:
3.1 Conf 配置层(这个是配置文件的)
1.数据库连接配置
2.全局变量url配置
3.日志配置
4.全局共用数据配置
3.2 Output 输出层
1 logs 文件夹(这个是输出的日志的路径)
1.主要是放日志文件的放置
2.reports 文件夹(这个是输出的测试报告的路径)
2.生成的测试报告的文件放置
3.3 Public 公共工具层:
1.配置文件的处理
2.excel用例数据的读取-数据参数化(数据驱动思想)实现
3.http请求封装:鉴权处理,请求头处理,url处理,data的处理,发送请求
4.接口关联的处理,接口之间的传递
5.提取响应的结果的提取
6.数据替换处理
7.连接数据库的处理
8.数据生成处理
9.路径的处理
10.读取日志的处理
3.4 TesatData 文件夹(这个是放测试用例的路径):
1.就是excel用例的
2.ini配置文件
3.脚本生成的数据
3.5 TesatCase 文件夹(这个是测试用例执行的路径和用例收集与测试报告生成的路径):
1.用例执行文件:
unittest实现
ddt模块
3.6 main.py文件
1.框架的入口文件
2.执行他,会自动收集用例执行用例生成报告
8.框架的运行流流程是怎样的的:
概念:先想明白用例逻辑/实现-步骤、断言、哪些数据是动态替换,才去写代码。
1.编写excel测试数据
用例步骤:
2.根据表单读取到用例数据
3.使用unittest框架定义测试类。并使用ddt模块应用数据驱动思想
4.类前置当中,清除环境变量类当中的动态属性
# 从第五步开始是每个数据都要做的事
5.替换请求数据当中,需要动态替换的数据(来自于接口返回值、配置文件、脚本生成的)。
6.如果有前置sql语句,还需要替换sql查询到的数据
7.发送请求
8.若有提取表达式,在响应结果当中,jsonpath提取数据,并设置为环境变量
9.若有断言表达式,则以字典的形式,比对期望和实际结果。
10.若有sql检查,则在数据库中执行sql数据,与期望结果比对。