在接口自动化测试过程中,如何开展接口自动化测试?单个模块和多个模块关联又怎么去做测试?
(一)接口自动化如何开展?
0、调研、前提准备和思考
a)前提:
1、正式设计用例的时候,结合postman/jmeter这样的工具
2、去设计不同的测试数据,发起请求,查看响应结果与设计是否一致
3、(要走一遍手工测试的) -- 发现的bug
b)用例的存储方式:
1、excel表格 - 配置json路径
2、json文件 - 请求参数比较多,写在json文件里
3、yaml文件 - httprunner3.0
4、数据库 - 创建表格
c) 自动化覆盖率怎么样
覆盖率:功能上/手工用例覆盖率 - 30% - 90%
1、你做这个项目的接口自动化多久了?
2、系统大不大?是否复杂?
3、覆盖率用例多少条?遇到什么困难(及解决方案)?
1、需求分析
了解项目的业务功能,bug较多的模块,比较稳定接口有哪些,核心功能有哪些
2、 了解接口
2.1 抓包看接口
2.2 通过接口文档了解
3、自动化框架、工具的选择
3.1 工作的可扩展性以及扩展语言 + 选几个复杂的接口试用
3.2 框架结构的比较
3.3 规范命名
4、写接口用例
4.1 写接口用例脚本
- 1、核心业务的先走 - 用户使用率最高
- 2、用例优先级 - 常用的功能场景/必填参数
- 3、参数的格式有效性-后端没有做校验
- 4、正常用例先设计、异常场景(全面)
4.2 尽早加入jenkins集成
4.3 定期汇报进度
4.4 测试报告,自动发送报告、分析用例失败原因
4.5 记录接口自动化开始到当前的bug
4.6 异常处理情况
5、持久化层构造
1、数据库直接插入数据
6、维护阶段
1、开发修改接口,测试同步修改接口脚本
2、新增接口,同步新增接口用例
3、脚本、日常框架优化
4、配置文件持续更新
(二)单个模块怎么去做测试的呢?
单模块测试:在测试工作中主要用于检查单个业务功能的接口实现,或者调试测试数据。
第一步:梳理上下游调用链
1)为什么要梳理上下游调用链?
目前互联网产品的后端服务,基本上都是分布式部署 的,一个接口可能会调用其他接口,也有可能被其他接口调用,接口与接口之间,具有千丝万缕的依赖关系。
如果只是单独的调调参数,就希望把接口测试做好,显然是不可能的。(开发自己都能调(tiao)接口参数,还要测试做什么?)
2)怎么梳理上下游调用链?
1、看项目wiki、产品文档和开发文档
2、看开发写的代码,阅读代码
3、梳理出上下游调用关系,手绘一份系统流程图,如果还有不明确的地方,可以找PM、开发沟通确认
第二步:编写接口测试用例
如果说要做接口自动化,接口测试用例也是很有帮助的。
这里给出一个接口测试用例的案例:
第三步:测试接口文档&调试接口
在项目开发之初,前端开发和后端开发会共同去约定一套接口规范,然后由后端开发去编写接口文档,然后前后端就可以按照约定去进行协同开发。
接口文档的管理和编辑有多种方式:
- 有的团队习惯用wiki或者在线文档去编写接口文档;
- 有的团队喜欢用专业的接口文档工具,比如:Swagger、Yapi等去生成接口文档。
测试接口文档可以参考以下测试点:
- 确保开发必须提供接口文档。如果开发没有写接口文档的习惯,应push开发去写接口文档。
- 检查接口文档的格式内容等是否完备,包括:URL、请求方法、Header、入参、返回值、示例Demo等。
- 检查接口设计是否符合公司规范。包括接口命名、接口格式、字段命名、字段类型、响应状态码、接口容错、字段是否冗余、接口是否鉴权、是否做版本区分等等。
当后端开发完成接口的开发工作时,我们就可以提前开始对接口进行初步测试了。
步骤如下:
- 把后端代码部署到测试环境上。
- 通过postman或swagger去对接口文档提到的接口进行测试。
第四步:前端接口测试&Mock数据(接口层面的测试)
前面的步骤只是利用测试工具去发起网络请求,来模拟接口调用。
但在真实的场景下,搜索网关的接口实际上是提供给 APP/WEB/小程序 进行调用的。
我们同样也需要关注前端调用过程是否是正常的。(需要等待前端开发完毕,才能介入测试)
可以利用Charles来对前端发送的请求进行抓包,
- 验证前端调用接口的传参是否正确;
- 验证后端的接口响应是否符合预期;
- 前端拿到数据之后,交互和UI展示是否正确。
当有些数据有多种状态,并且数据比较难以构造时,我们可以通过Mock数据去进行测试。
常见的Mock数据的方式有:
- 用 Fiddler 或者 Charles 去篡改请求和响应。
- 如果是PHP或者Python等动态语言,可以直接在后端代码里面去更改条件。
- 数据库中去修改数据。
- 用专业的Mock工具去构造数据,如:EasyMock、TestableMock、Mockjs等。
比较快速的方式,当然是直接用Charles去模拟。
第五步:后端接口测试&业务逻辑覆盖(看日志、看代码)
看日志
业务测试过程中,我们需要时刻关注后端日志状态。
有时候接口响应数据是正常的,但是后端日志可能正在报错,
看代码
推荐大家在做接口测试的时候,一定要去阅读开发的源码。
阅读源码可以对业务逻辑实现了解更加深入。
如果代码量很大怎么办?
告诉大家一个小诀窍:当开发提交代码之后,我们可以在Gitlab上看他的Commit记录,或者将他的开发分支和生产环境的分支做个diff,这样就能知道他改了哪些地方。
第六步:接口性能调优(Arthas)
排查过程 :
(1)先在APP上尝试复现
(2)通过Arthas的trace逐步去排查接口响应慢的原因:
进入Arthas命令行
java -jar arthas-boot.jar
trace 接口调用的方法
trace 类名 方法名
第七步:接口版本控制&diffy
一般接口都会区分版本,如果接口不是很规范,或者改了一些通用的逻辑,这个时候就需要对老版本进行一次回归测试。
最笨的方法就是拿新老版本的两个app对比测试。我们也可以用diffy这个工具来做回归测试。
第八步:开始做接口自动化
接口自动化一般常用于进行线上巡检回归、提测冒烟测试等场景。
实现接口自动化,采用一下方式:
coding:
python+pytest+requests,目前采用这种方式去做。(小而美,方便定制化)
(三)多个模块关联怎么去做测试的呢?
模块关联:是指将两个及以上相关API的出入参以参数化的形式达成动态关联,以实现整个事务的测试覆盖,达到基础的工具接口自动化测试。
第一步:梳理上下游调用链
1)为什么要梳理上下游调用链?
目前互联网产品的后端服务,基本上都是分布式部署 的,一个接口可能会调用其他接口,也有可能被其他接口调用,接口与接口之间,具有千丝万缕的依赖关系。
如果只是单独的调调参数,就希望把接口测试做好,显然是不可能的。(开发自己都能调(tiao)接口参数,还要测试做什么?)
2)怎么梳理上下游调用链?
1、看项目wiki、产品文档和开发文档
2、看开发写的代码,阅读代码
3、梳理出上下游调用关系,手绘一份系统流程图,如果还有不明确的地方,可以找PM、开发沟通确认
第二步:编写接口测试用例
如果说要做接口自动化,接口测试用例也是很有帮助的。
这里给出一个接口测试用例的案例:
第三步:测试接口文档&调试接口
在项目开发之初,前端开发和后端开发会共同去约定一套接口规范,然后由后端开发去编写接口文档,然后前后端就可以按照约定去进行协同开发。
接口文档的管理和编辑有多种方式:
- 有的团队习惯用wiki或者在线文档去编写接口文档;
- 有的团队喜欢用专业的接口文档工具,比如:Swagger、Yapi等去生成接口文档。
测试接口文档可以参考以下测试点:
- 确保开发必须提供接口文档。如果开发没有写接口文档的习惯,应push开发去写接口文档。
- 检查接口文档的格式内容等是否完备,包括:URL、请求方法、Header、入参、返回值、示例Demo等。
- 检查接口设计是否符合公司规范。包括接口命名、接口格式、字段命名、字段类型、响应状态码、接口容错、字段是否冗余、接口是否鉴权、是否做版本区分等等。
当后端开发完成接口的开发工作时,我们就可以提前开始对接口进行初步测试了。
步骤如下:
- 把后端代码部署到测试环境上。
- 通过postman或swagger去对接口文档提到的接口进行测试。
第四步:接口场景化设计
背景:现有平台对单服务单接口自动化测试流程相对成熟,而对于复杂的跨服务的自动化用例配置的需求反馈日益增多,所以,增加对于复杂测试场景的支持
什么样的用例适合场景化
也可称为业务流,例如:举个电商类case,下单购买-支付-验证支付状态-查看权限-退款-验证退款状态
- 无论是否跨应用,步骤有前后有强依赖关系
- 核心兜底业务场景,比如,下单-支付-履约-退款
基于以上背景,此次项目对应的功能点如下:
- 增加【场景集】概念,等同于原有的【项目】
- 增加【测试场景】概念,与原有的【用例集】类似
- 触发关联的测试场景
第五步:前端接口测试&Mock数据(接口层面的测试)
前面的步骤只是利用测试工具去发起网络请求,来模拟接口调用。
但在真实的场景下,搜索网关的接口实际上是提供给 APP/WEB/小程序 进行调用的。
我们同样也需要关注前端调用过程是否是正常的。(需要等待前端开发完毕,才能介入测试)
可以利用Charles来对前端发送的请求进行抓包,
- 验证前端调用接口的传参是否正确;
- 验证后端的接口响应是否符合预期;
- 前端拿到数据之后,交互和UI展示是否正确。
当有些数据有多种状态,并且数据比较难以构造时,我们可以通过Mock数据去进行测试。
常见的Mock数据的方式有:
- 用 Fiddler 或者 Charles 去篡改请求和响应。
- 如果是PHP或者Python等动态语言,可以直接在后端代码里面去更改条件。
- 数据库中去修改数据。
- 用专业的Mock工具去构造数据,如:EasyMock、TestableMock、Mockjs等。
比较快速的方式,当然是直接用Charles去模拟。
第六步:后端接口测试&业务逻辑覆盖(看日志、看代码)
看日志
业务测试过程中,我们需要时刻关注后端日志状态。
有时候接口响应数据是正常的,但是后端日志可能正在报错,
看代码
推荐大家在做接口测试的时候,一定要去阅读开发的源码。
阅读源码可以对业务逻辑实现了解更加深入。
如果代码量很大怎么办?
告诉大家一个小诀窍:当开发提交代码之后,我们可以在Gitlab上看他的Commit记录,或者将他的开发分支和生产环境的分支做个diff,这样就能知道他改了哪些地方。
第七步:接口性能调优(Arthas)
排查过程 :
(1)先在APP上尝试复现
(2)通过Arthas的trace逐步去排查接口响应慢的原因:
进入Arthas命令行
java -jar arthas-boot.jar
trace 接口调用的方法
trace 类名 方法名
第八步:接口异常机制(Chaosblade)
因为接口依赖的服务很多,经常需要调用其他接口。假如依赖的服务出现了异常,我们就需要考虑我们的接口是不是做了容错处理,或者是降级处理。
可以用Chaosblade去注入异常。(非必须,但有更好)
第九步:接口版本控制&diffy
一般接口都会区分版本,如果接口不是很规范,或者改了一些通用的逻辑,这个时候就需要对老版本进行一次回归测试。
最笨的方法就是拿新老版本的两个app对比测试。我们也可以用diffy这个工具来做回归测试。
第十步:开始做接口自动化
接口自动化一般常用于进行线上巡检回归、提测冒烟测试等场景。
实现接口自动化,采用一下方式:
coding:
python+pytest+requests,目前采用这种方式去做。(小而美,方便定制化)