当前位置:   article > 正文

在接口自动化测试过程中,如何开展接口自动化测试?单个模块和多个模块关联又怎么去做测试?

在接口自动化测试过程中,如何开展接口自动化测试?单个模块和多个模块关联又怎么去做测试?

简介:接口自动化测试过程中,如何开展接口自动化测试?单个模块和多个模块关联又怎么去做测试?

(一)接口自动化如何开展?

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. 现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
  2. 如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
  3. 可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
  4. 分享他们的经验,还会分享很多直播讲座和技术沙龙
  5. 可以免费学习!划重点!开源的!!!
  6. qq群号:691998057【暗号:csdn999

(二)单个模块怎么去做测试的呢?

单模块测试:在测试工作中主要用于检查单个业务功能的接口实现,或者调试测试数据。

第一步:梳理上下游调用链

1)为什么要梳理上下游调用链?
目前互联网产品的后端服务,基本上都是分布式部署 的,一个接口可能会调用其他接口,也有可能被其他接口调用,接口与接口之间,具有千丝万缕的依赖关系。
如果只是单独的调调参数,就希望把接口测试做好,显然是不可能的。(开发自己都能调(tiao)接口参数,还要测试做什么?)
2)怎么梳理上下游调用链?
1、看项目wiki、产品文档和开发文档
2、看开发写的代码,阅读代码
3、梳理出上下游调用关系,手绘一份系统流程图,如果还有不明确的地方,可以找PM、开发沟通确认

第二步:编写接口测试用例

如果说要做接口自动化接口测试用例也是很有帮助的。
这里给出一个接口测试用例的案例:

image.png

第三步:测试接口文档&调试接口

在项目开发之初,前端开发和后端开发会共同去约定一套接口规范,然后由后端开发去编写接口文档,然后前后端就可以按照约定去进行协同开发。
接口文档的管理和编辑有多种方式:

  • 有的团队习惯用wiki或者在线文档去编写接口文档;
  • 有的团队喜欢用专业的接口文档工具,比如:Swagger、Yapi等去生成接口文档。

测试接口文档可以参考以下测试点:

  1. 确保开发必须提供接口文档。如果开发没有写接口文档的习惯,应push开发去写接口文档。
  2. 检查接口文档的格式内容等是否完备,包括:URL、请求方法、Header、入参、返回值、示例Demo等。
  3. 检查接口设计是否符合公司规范。包括接口命名、接口格式、字段命名、字段类型、响应状态码、接口容错、字段是否冗余、接口是否鉴权、是否做版本区分等等。

后端开发完成接口的开发工作时,我们就可以提前开始对接口进行初步测试了。
步骤如下:

  1. 后端代码部署到测试环境上。
  2. 通过postman或swagger去对接口文档提到的接口进行测试。

第四步:前端接口测试&Mock数据(接口层面的测试)

前面的步骤只是利用测试工具去发起网络请求,来模拟接口调用。

但在真实的场景下,搜索网关的接口实际上是提供给 APP/WEB/小程序 进行调用的。

我们同样也需要关注前端调用过程是否是正常的。(需要等待前端开发完毕,才能介入测试)

可以利用Charles来对前端发送的请求进行抓包,

  1. 验证前端调用接口的传参是否正确;
  2. 验证后端的接口响应是否符合预期;
  3. 前端拿到数据之后,交互和UI展示是否正确。

当有些数据有多种状态,并且数据比较难以构造时,我们可以通过Mock数据去进行测试。

常见的Mock数据的方式有

  1. 用 Fiddler 或者 Charles 去篡改请求和响应。
  2. 如果是PHP或者Python等动态语言,可以直接在后端代码里面去更改条件。
  3. 数据库中去修改数据。
  4. 用专业的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、开发沟通确认

第二步:编写接口测试用例

如果说要做接口自动化接口测试用例也是很有帮助的。
这里给出一个接口测试用例的案例:

image.png

第三步:测试接口文档&调试接口

在项目开发之初,前端开发和后端开发会共同去约定一套接口规范,然后由后端开发去编写接口文档,然后前后端就可以按照约定去进行协同开发。
接口文档的管理和编辑有多种方式:

  • 有的团队习惯用wiki或者在线文档去编写接口文档;
  • 有的团队喜欢用专业的接口文档工具,比如:Swagger、Yapi等去生成接口文档。

测试接口文档可以参考以下测试点:

  1. 确保开发必须提供接口文档。如果开发没有写接口文档的习惯,应push开发去写接口文档。
  2. 检查接口文档的格式内容等是否完备,包括:URL、请求方法、Header、入参、返回值、示例Demo等。
  3. 检查接口设计是否符合公司规范。包括接口命名、接口格式、字段命名、字段类型、响应状态码、接口容错、字段是否冗余、接口是否鉴权、是否做版本区分等等。

后端开发完成接口的开发工作时,我们就可以提前开始对接口进行初步测试了。
步骤如下:

  1. 后端代码部署到测试环境上。
  2. 通过postman或swagger去对接口文档提到的接口进行测试。

第四步:接口场景化设计

背景:现有平台对单服务单接口自动化测试流程相对成熟,而对于复杂的跨服务的自动化用例配置的需求反馈日益增多,所以,增加对于复杂测试场景的支持

什么样的用例适合场景化
也可称为业务流,例如:举个电商类case,下单购买-支付-验证支付状态-查看权限-退款-验证退款状态

  1. 无论是否跨应用,步骤有前后有强依赖关系
  2. 核心兜底业务场景,比如,下单-支付-履约-退款

基于以上背景,此次项目对应的功能点如下:

  • 增加【场景集】概念,等同于原有的【项目】
  • 增加【测试场景】概念,与原有的【用例集】类似
  • 触发关联的测试场景

第五步:前端接口测试&Mock数据(接口层面的测试)

前面的步骤只是利用测试工具去发起网络请求,来模拟接口调用。

但在真实的场景下,搜索网关的接口实际上是提供给 APP/WEB/小程序 进行调用的。

我们同样也需要关注前端调用过程是否是正常的。(需要等待前端开发完毕,才能介入测试)

可以利用Charles来对前端发送的请求进行抓包,

  1. 验证前端调用接口的传参是否正确;
  2. 验证后端的接口响应是否符合预期;
  3. 前端拿到数据之后,交互和UI展示是否正确。

当有些数据有多种状态,并且数据比较难以构造时,我们可以通过Mock数据去进行测试。

常见的Mock数据的方式有

  1. 用 Fiddler 或者 Charles 去篡改请求和响应。
  2. 如果是PHP或者Python等动态语言,可以直接在后端代码里面去更改条件。
  3. 数据库中去修改数据。
  4. 用专业的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,目前采用这种方式去做。(小而美,方便定制化)

下面是配套资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!

最后: 可以在公众号:程序员小濠 ! 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享!,其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

如果我的博客对你有帮助、如果你喜欢我的博客内容,请 “点赞” “评论” “收藏” 一键三连哦!

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/知新_RL/article/detail/301683
推荐阅读
相关标签
  

闽ICP备14008679号