接口测试思考——应该怎么执行?
序言
接口测试的流程就相当于一个程序(交互式的程序);而程序开发前,得先确定需求,所以我们先来聊聊需求,即当有了接口测试脚本和框架时,怎么用(执行)的问题。
讨论要点:
1.前期准备
2.执行步骤
3.提BUG
前期准备
搭建本地测试环境本身是件很麻烦的事,但用docker的话就少了很多麻烦专注于测试本职工作
(1)搭建环境:
在docker设置中添加的镜像源路径,docker-compose.yml文件目录有用于构建mysql镜像的文件时,在该目录下执行:
docker-compose up -d
部署镜像(当没有对应镜像,就会拉取镜像源(包括本地)的镜像)
(2)更新表结构:
每次后台的数据库表结构有更新时(同时更新migration),就需要更新本地的表结构;
先更新用于构建本地镜像的sql文件(resotre),再构建新镜像部署
docker-compose stop mysql
docker-compose rm -f -v mysql
svn up mysql && docker-compose up -d --build mysql
最后需要进行数据初始化,因为数据库光有基础数据还不够,还需要一些常用数据:比如账号数据。(可以通过写SQL脚本或者接口测试脚本达到初始化的效果)
(3)更新代码
先需要更新最新的代码镜像(jenkins更新测试环境代码),再执行
docker-compose pull 服务名
docker-compose up -d
(4)其他常用
日志查看 : docker-compose logs --tail 200 -f 服务名
执行计划任务服务:
docker-compose exec schedule bash '' 对应修改计划任务配置的脚本''
docker-compose restart schedule
当然这些前期准备的命令最好使用jenkins执行脚本的方式,来方便执行,提高执行效率。
执行步骤
(1)接口第一轮测试
这种都是在后台代码完成后,前端和接口联调前执行的
为了编写和调试方便,所以是在IDE上命令行执行脚本;
要点:
1、独立的python运行环境
2、对应的路径下跑有不同效果,可以是测试集跑(suit)、测试用例(case)下跑
3、出现非接口的报错需调试时,可以在对应函数加上异常处理,或者在打印到测试报告中(这些处理最好是在写脚本时就有准备)
(2)接口第二轮测试
这种就是在功能测试时,需要做接口回归测试时跑
为了执行的方便,所以在jenkins上跑脚本(一般测试集的跑)
要点:
1、测试报告输出到jenkins日志上
2、支持修改配置跑不同的地方
提BUG
(1)确定是否为BUG
用例验证接口一般两种:接口的返回验证、数据库字段验证。
所以要点是明确期望和执行步骤,这执行步骤包括:造数据前请求的接口、测试对象接口的请求参数;
这些都是在脚本上已经确定好了的,所以很好明确
(2)定位BUG
根据步骤流程上数据产生来定位,比如:可以由错误的返回字段推导出是生成了错误数据的原因,从而找出产生错误数据的接口
(接口分类无非是增删改查)
(3)开发有疑问时
1、让开发通过访问本地数据库来调试代码
2、让开发在代码上加上日志,再跑一次脚本,查看日志