HTTP API 自动化测试从手工测试到平台的演变

不管是 Web 系统,还是移动 APP,前后端逻辑的分离设计已经是常态化,相互之间通过 API 调用进行数据交互。在基于 API 约定的开发模式下,如何加速请求 / 响应的 API 测试,让研发人员及早参与到调试中来呢?既然 API 是基于约定开发,为何不按照这个规范编写测试用例,直接进入待测试状态,使用自动化的方式来推进研发过程的质量改进呢?遵循:测试 -> 重构 -> 测试 -> 重构,这样的闭环,过程产出的质量会更加可控,在重构的同时进行快速的功能回归验证,大大提高效率。下面主要讲解基于 HTTP 协议的 API 测试,从手工测试到平台的演变过程。
  
  手工测试带来的困惑
  
  测试团队采用《敏捷脑图用例实践之路》的方式编写测试用例:
  
  图 -1- 分计费单元查询带宽
  
  图 -1- 分计费单元查询带宽
  
  优点:
  
  要点清晰简洁展现
  
  所有测试故事点经过用例评审,产生质量高,研发参与感强;
  
  版本同步保持一份
  
  API 测试脑图带来的问题:
  
  脑图用例对测试人员的素质要求相当高
  
  完善的脑图用例编写,需要有资深的测试人员,对业务精通、对测试技能精通,很强的思维能力;如果研发人员仅仅参考这个脑图用例进行测试,往往很多时候需要花费大量的沟通时间,其中有很多测试 API 的过程、措施,在脑图里面没有具体体现,造成一些信息丢失。
  
  重复执行不变的是规则,变的只是参数,要消灭重复部分
  
  还可以深度优化脑图用例,API 接口规范,再怎么天马行空,也得有个度,应当把重复思考的部分交给工具去做,需要发挥创造力、值得关注部分,交给人工完成;按照这个测试流程,,测试人员编写完用例,去验证 API 接口,如果失败了,打回给研发人员重新修改,但是下一次研发人员提交测试,测试人员又得重新验证一遍,这一遍中实际没有多少有价值的思考,是重复工作,要去挖掘测试价值。另外,如果测试人员请假了,那是不是测试就需要延期了呢?消除等待、消除单点作业,改变是唯一出路,尝试过如下方式:
  
  图 -2-Chrome DHC 组件
  
  图 -2-Chrome DHC 组件
  
  组员通过使用 Chrome DHC(是一款使用 chrome 模拟 REST 客户端向服务器发送测试数据的谷歌浏览器插件),进行 API 自动化测试,用例文件保存到本地并且同步到 svn,简单粗暴解决重复请求问题,注意强调的是解决重复请求,并没有包括参数和结果的自动化验证的过程,还是需要人工参与,至少前进了一步,当然我们也解决了单点问题,其他组员可以更新用例本地运行,还差参数校验,数据校验等等一堆关键业务点要用自动化去突破。
  
  俗话说:术业有专攻,DHC 只是玩玩而已,并不擅长做那么多活,也做不好,更期望的是平台化。
  
  平台雏形:没有经验,多么痛的领悟
  
  经历了手工测试的繁琐操作,丢弃了简单的 DHC,决定另寻新路,API 测试最简单的场景请求参数组合产生各类别的测试用例。思路很简单,做一个 WEB 平台,登记 API 接口,填写请求参数,对响应结果进行校验,初期进行了技术选型,使用 Django 做 Python Web 开发,后台脚本执行使用开源框架 RobotFramework,RF 优点如下:
  
  是一个通用的关键词驱动自动测试框架;
  
  易于使用的表格数据展现形式,采用关键字驱动的测试方法,使用在测试库中实现的关键词来在测试中运行程序。
  
  是灵活和可扩展的,适合用于测试用户接口;
  
  在这个平台中,RobotFramework 主要用于后台执行 Robot 关键字脚本,而关键字脚本,是平台通过读取 YAML 文件生成,该文件是通过笛卡尔乘积产生的用例,工作原理如图所示:
  
  图 -3- 工作原理
  
  图 -3- 工作原理
  
  那话说回来,YAML 干什么呢?为什么不是 XML 呢?
  
  YAML 的可读性好
  
  YAML 和脚本语言的交互性好
  
  YAML 使用实现语言的数据类型
  
  YAML 有一个一致的信息模型
  
  YAML 易于实现
  
  听起来 YAML 试图用一种比 XML 更敏捷的方式,来完成 XML 所完成的任务。下面通过一段实际例子说明配置生成的 YAML 代码段:
  
  主接口配置界面:
  
  图 -4- 接口配置页面
  
  图 -4- 接口配置页面
  
  设置 API 参数:
  
  图 -5- 设置 API 参数
  
  图 -5- 设置 API 参数
  
  配置文件 byChannelsDaily.yaml(列举一个参数示例):
  
  - byChannelsDaily: # 接口名称
  
  method: get # 与服务器交互的方法
  
  format: json #API 数据格式
  
  url: /reportdata/flux/byChannelsDaily #API 的 URL,与奇台配置文件里面的 host 变量组成整个 URL 的前半部分。
  
  url_path:
  
  url_params: #URL 参数部分,固定写法。
  
  username: #API 的参数名。
  
  required: true # 该参数是否必须(true/false)。
  
  value: chinacache # 该参数的值。如此值是从另一个接口获取的,可在 from_api 设置,此处可不填。如果值是 Boolean,必须加双引号。
  
  type: string # 该参数值的类型。
  
  len: 10 # 该参数值的长度。
  
  max: -100 # 该参数值的最大值。-100 相当于忽略此参数
  
  min: -100 # 该参数值的最小值。-100 相当于忽略此参数
  
  from_api: # 如参数的值是从另一个接口、global.yaml 中获取的,请设置 from_api,如 global
  
  jsonpath: # 可通过 jsonpath 来指定取值范围,如 $.version[2:4]
  
  range:
  
  response: # 期望结果
  
  verification:
  
  success: [] #success 是一个 list, 它的元素也是 list,success[0] = [ RF 关键字 ,验证字段,正则匹配]
  
  failure: []
  
  error_msg: [] # 错误信息集合</pre>
  
  测试报告:
  
  图 -6-rf 测试报告
  
  图 -6-rf 测试报告
  
  按照这个思路做下来,得到什么收益呢?
  
  自动化
  
  自动化
  
  说到这里,其实,真没有带来多少收益,思路对了,但是方向有偏差了,主要体现在:
  
  使用了笛卡尔乘积来生成不同参数的测试用例,发现一堆的测试用例生成文件是 M 的单位,而且也给测试服务器带来性能问题,数量 4980 个中占 95% 的用例都是没有实际意义的,对服务器频繁请求造成压力;
  
  图 -7- 庞大的测试用例文件
  
  图 -7- 庞大的测试用例文件
  
  通过 WEB 配置将 YAML 文件转为 robot 可以识别的,这种做法坑太深、维护难,参数越多, 文件越臃肿,可读性差;
  
  后来尝试将笛卡尔乘积换成全对偶组合算法,效果改进显著,无效用例数明显下降,有效用例数显著提升;
  
  败了,就是败了,没什么好找借口,关键问题是:
  
  有效的测试用例占比例很低,无效的占了大部分;
  
  没有化繁为简,前端隐藏了配置,复杂的配置还是需要在后端处理;
  
  没有实际测试参与动脑过程,测试人员不会穷举,会根据业务编写实际用例;
  
  平台易用性很重要:需要测试人员直接在上面编写,合理的逻辑步骤,有利于引导测试参与;
  
  重构:发现测试的价值
  
  回到起点,测试要解决什么问题,为什么要做 API 自动化测试平台?做这个平台,不是为了满足老板的提倡全民自动化的口号,也不是为了浮夸的 KPI,更不是宣传自动化可以解决一切问题,发现所有 bug。叔本华说过一句话:由于频繁地重复,许多起初在我们看来重要的事情逐渐变得毫无价值。如果 API 测试仅仅依靠纯手工的执行,很快将会面临瓶颈,因为每一个功能几乎都不能是第一次提交测试后就测试通过的,所以就需要反复 bug 修复、验证,以及回归的过程。另外,很多的 API 测试工作手工做起来非常的繁琐,甚至不便,比如针对接口协议的验证、针对返回数据格式的验证,这些都依赖于测试自动化的开展。因此,真正的目的是解放测试人员重复的手工生产力,加速回归测试效率,同时让研发人员在开发过程及早参与测试(自测、冒烟测试),驱动编码质量的提升。
  
  回顾以往,重新梳理头绪,更加清晰的展现:
  
  图 -8-HTTP API 自动化测试图解
  
  图 -8-HTTP API 自动化测试图解
  
  HTTP API 传统手工测试
  
  重复请求参数基础校验、正确参数查询返回数据校验,测试工程师没有新的创造价值,不断重复工作,甚至可能压缩其中的测试环节,勉强交付;
  
  HTTP API 自动化测试
  
  重复步骤(请求接口是否有效、参数校验可以作为冒烟测试,研发参与自测)用自动化解决,关键业务步骤数据对比人工参与和 schema 自动化校验;
  
  如果对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣可以175317069,群内会有不定期的发放免费的资料链接,这些资料都是从各个技术网站搜集、整理出来的,如果你有好的学习资料可以私聊发我,我会注明出处之后分享给大家。
  
  最大的收益,重复步骤自动化后,不管是研发人员自测,还是执行功能回归测试,成本可以很快收回(前提是你这个项目周期长,构建频繁;如果仅仅是跑几个月的项目,真没那个必要凑热闹去自动化,当然有平台的另当别论),测试的关注点会落实到更加关键的业务环节去;
  
  总体规划如下:
  
  [
  
  图 -9-HTTP API 重构规划
  
  图 -9-HTTP API 重构规划
  
  技术选型
  
  由于原来的测试平台使用 Python 编写,为了保持风格一致,从界面录入到文件生成处理依然采用 Python、Django,去掉了全对偶组合算法,改为根据测试人员思维去产生用例;去掉了后台 RobotFramework 框架,采用 Python 的 HTTP 类库封装请求。
  
  HTTP API 项目管理 Web 前台
  
  使用 Python+Django+MySQL 进行开发,分为项目首页、项目配置、API 配置、全局配置四大部分
  
  图 -10- 管理 Web
  
  图 -10- 管理 Web
  
  项目首页
  
  介绍:列出 API 规范、API 测试用例、定时任务数量,以及某段时间内的测试结果趋势图形。
  
  图 -11- 项目首页
  
  图 -11- 项目首页
  
  项目配置
  
  重点介绍:全局变量、常用方法、验证器。
  
  全局变量
  
  设计思路:在 API 测试过程中,可以切换生产、测试环境进行对比校验,如果写两套测试用例是冗余,全局变量功能,是一种在执行测试用例时动态改变用例属性的方法。
  
  作用范围:当前项目内
  
  使用方法:{变量名}
  
  能在以下测试用例属性中使用:URL、请求头、请求参数
  
  图 -12- 全局变量配置页
  
  图 -12- 全局变量配置页
  
  在 API 用例库的 URL 可以直接填写:{host}/reportdata/monitor/getChannelIDsByUserName;当运行测试用例的时候,可以选择不同的参数套件,后台代码执行会直接替换,这样子可以分别快速验证生产环境和测试环境的 API 接口执行结果的差异。
  
  图 -13- 用例执行页
  
  图 -13- 用例执行页
  
  常用方法
  
  图 -14- 常用方法列表页
  
  图 -14- 常用方法列表页
  
  √ 设计思路:常用方法是一个 Python 函数,对入参进行处理并且返回结果,例如:
  
  gen_md5 作用是生成 MD5,对应代码直接填写:
  
  import hashlib
  
  def gen_md5(raw_str):
  
  m = hashlib.md5()
  
  m.update(raw_str)
  
  md5_str = m.hexdigest()
  
  return md5_str
  
  √ 应用场景:
  
  在 API 请求中,有些参数例如 pass 需要加密处理,可以通过引入 [常用方法] 来解决。
  
  在参数 pass 的值中直接填写:
  
  {{get_apipwd("{123456}","ChinaCache")}}</pre>
  
  图 -15- 接口配置页
  
  图 -15- 接口配置页
  
  验证器
  
  √ 设计思路
  
  验证器是一个 Python 函数,如果函数返回 True,则测试通过;返回 False,则测试失败。平台默认提供一个默认验证器。
  
  默认验证器是验证期望结果与实际结果(response body)是否完全一致。如果结果不一致则判断为失败,默认验证器只适用于静态的响应结果对比。
  
  自义定验证器,如果默认验证器不能满足某些特殊的测试需求,用户可以在“项目配置 - 验证器”中添加自定义的验证器。
  
  √ 应用场景:在 API 测试的返回结果中,可以添加自定义验证器对数据进行校验,判断测试是否通过。
  
  图 -17- 测试用例验证展示页
  
  图 -17- 测试用例验证展示页
  
  API 配置
  
  重点介绍:通用响应配置、API 依赖库、API 用例库、定时任务、测试报告
  
  通用响应配置
  
  图 -18- 通用响应配置列表页
  
  图 -18- 通用响应配置列表页
  
  √ 设计思路
  
  在合理的 API 设计中,存在通用的错误响应码,[用户名错误,返回期望响应内容],如果所有 API 的响应结果中都需要重复写是相当繁琐的,作为共同配置调用即可。
  
  √ 应用场景
  
  查询接口遇到用户名密码为空,可以自定义写返回内容,以及选择 [通用响应配置] 下的相关错误类型,例如:用户名密码为空 (计费单元),自动填充期望的返回值:
  
  <BillingIDs>
  
  <Result>fail<www.michenggw.com /Result>
  
  <DetailInfo>invalid userName or password</DetailInfo>
  
  </BillingIDs>
  
  图 -19- 期望返回值校验页
  
  图 -19- 期望返回值校验页
  
  API 依赖库
  
  √ 设计思路 & 应用场景
  
  API-A 的参数 r_id 依赖与 API-B 返回结果的某个参数(多个参数同样道理),这里登记 API-B,并且提取返回参数。除了特有的变量提取器,基本信息与请求,与后面提到的 API 接口一致的
  
  填写方式 :
  
  图 -20- 变量提取器展示页
  
  图 -20- 变量提取器展示页
  
  该接口返回数据如下;
  
  {
  
  "r_id": "567bbc3f2b8a683f7e2e9436"
  
  }
  
  通过 [变量提取器],可以获取 r_id 的值,以供依赖 API-A 作为参数使用。
  
  图 -21- 用例中参数包含 r_id 变量展示页
  
  图 -21- 用例中参数包含 r_id 变量展示页
  
  其中请求参数的获取如下:
  
  图 -22- 请求参数变量提取设置
  
  图 -22- 请求参数变量提取设置
  
  测试结果:
  
  1- 显示依赖接口;2- 显示为需要测试的接口,依赖接口返回的 r_id 会传入作为测试接口的参数;
  
  图 -23- 测试结果中展示运行时变量提取结果
  
  图 -23- 测试结果中展示运行时变量提取结果
  
  API 用例库
  
  图 -24- 用例库设计脑图
  
  图 -24- 用例库设计脑图
  
  如果对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣可以175317069,群内会有不定期的发放免费的资料链接,这些资料都是从各个技术网站搜集、整理出来的,如果你有好的学习资料可以私聊发我,我会注明出处之后分享给大家。
  
  √ 设计思路
  
  通过自助配置:请求头、请求参数,响应头、响应结果校验,来聚合测试人员日常思考产生的测试用例。
  
  √ 应用场景
  
  支持 HTTP1.1 协议的 7 种请求方法:GET、POST、HEAD、OPTIONS、PUT、DELETE 和 TARCE。最常用的方法是 GET 和 POST:
  
  支持 query(问号后)带参数、www.yigouyule2.cn path 的 GET|POST 请求
  
  Query:http://192.168.1.11/internal/refresh?username=ChinaCache&password=123456
  
  Path:http://192.168.1.11/internal/refresh/username/password
  
  POST 请求支持 application/json、text/xml
  
  示例如下:
  
  请求头设置:Content- www.mhylpt.com/ Type:application/json
  
  请求体设置:保存为 JSON 格式
  
  {
  
  "username": www.meiwanyule.cn"ChinaCache",
  
  "password": "123456",
  
  "task": {
  
  "dirs": [ 如果对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、
  
  "" 面试经验交流。感兴趣可以175317069,群内会有不定期的发放免费
  
  ], 的资料链接,这些资料都是从各个技术网站搜集、整理出来的,如果
  
  "callback": { 你有好的学习资料可以私聊发我,我会注明出处之后分享给大家。
  
  "url": "",
  
  "email": []
  
  },
  
  "urls": [
  
  "http://www.chinacache.com/news/test.html"
  
  ]
  
  }
  
  }

原文地址:https://www.cnblogs.com/qwangxiao/p/10011466.html

时间: 2024-10-30 08:26:02

HTTP API 自动化测试从手工测试到平台的演变的相关文章

【转账】API自动化测试

随着公司各部门对质量的日益重视,API测试已成为日常的测试任务之一,为了提高测试效率,减少重复的手工操作,API自动化测试也逐渐变得愈加重要,本文是自己在API自动化测试方面的一些经验积累和心得.汇总成文,以飨读者.    什么是API,个人认为狭义理解API就是系统对外暴露的一些接口,供系统内部其他模块或者外部系统进行调用,如TD.harvest都有自己对外暴露的一些API,以供在其基础上进行二次开发,本文仅针对loushang平台的API进行讲述,目前loushang平台主要的API主要集中

Postman+Newman+jenkins实现API自动化测试

最近自己在学习用postman+newman+jenkins实现API自动化测试,这里做个回顾和记录.(此次是在windows上进行的环境搭建) 一.说明 1.大致思路:利用postman做接口调试所搜集的collection导出.json文件,再利用newman命令运行.json文件和得出测试结果,最后集成到jenkins实现自动化. 2.环境说明:postman基于JavaScript语言,postman的脚本(json文件)运行依赖newman环境,而newman环境依赖JavaScrip

Python Web中REST API使用示例——基于云平台+云服务打造自己的在线翻译工具

做为一个程序员可能在学习技术,了解行业新动态,解决问题时经常需要阅读英文的内容:而像我这样的英文小白就只能借助翻译工具才能理解个大概:不禁经常感慨,英文对学习计算机相关知识太重要了!最近发现IBM的云平台Blumemix,并且提供语言翻译的服务,感觉不错,就拿来研究学习一下:这里就分享一下我的研究学习过程,如何使用Python调用REST API打造自己的在线翻译工具,并演示如何把它发布到云平台上,让每个人都可以通过网络访问使用它. 应用效果展示 您可以通过点击效果图片的链接访问它. 构建一个类

Ruby On Rails中REST API使用示例——基于云平台+云服务打造自己的在线翻译工具

做为一个程序员可能在学习技术,了解行业新动态,解决问题时经常需要阅读英文的内容:而像我这样的英文小白就只能借助翻译工具才能理解个大概:不禁经常感慨,英文对学习计算机相关知识太重要了!最近发现IBM的云平台Blumemix,并且提供语言翻译的服务,感觉不错,就拿来研究学习一下:这里就分享一下我的研究学习过程,如何使用Ruby On Rails调用REST API打造自己的在线翻译工具,并演示如何把它发布到云平台上,让每个人都可以通过网络访问使用它. 应用效果展示 您可以通过点击效果图片的链接访问它

Node.js中REST API使用示例——基于云平台+云服务打造自己的在线翻译工具

做为一个程序员可能在学习技术,了解行业新动态,解决问题时经常需要阅读英文的内容:而像我这样的英文小白就只能借助翻译工具才能理解个大概:不禁经常感慨,英文对学习计算机相关知识太重要了!最近发现IBM的云平台Blumemix,并且提供语言翻译的服务,感觉不错,就拿来研究学习一下:这里就分享一下我的研究学习过程,如何使用Node.js调用REST API打造自己的在线翻译工具,并演示如何把它发布到云平台上,让每个人都可以通过网络访问使用它. 应用效果展示 您可以通过点击效果图片的链接访问它. 构建一个

REST API 自动化测试 利器Rest Assured(API接口自动化测试框架体系)

现在,越来越多的 Web 应用转向了 RESTful 的架构,很多产品和应用暴露给用户的往往就是一组 REST API,这样有一个好处,用户可以根据需要,调用不同的 API,整合出自己的应用出来.从这个角度来讲,Web 开发的成本会越来越低,人们不必再维护自己的信息孤岛,而是使用 REST API 互联互通 那么,作为 REST API 的提供者,如何确保 API 的稳定性与正确性呢?全面系统的测试是必不可少的.Java 程序员常常借助于 JUnit 来测试自己的 REST API,不,应该这样

API自动化测试指南

我相信自动化技能已经成为高级测试工程师总体技能的标配.敏捷和持续测试破坏了传统的测试自动化实践,导致测试工程师重新考虑自动化的完成方式.当今的自动化工程师需要在GUI的下方深入到API级别完成软件质量的保护. 导致转向API测试的第二个变化是物联网.物联网是具有嵌入式功能的日常对象,允许它使用HTTP或HTTPS在Web上进行通信以与远程后端服务进行通信. 下面分享一下API测试的基础使用指南: 什么是API测试? 应用程序编程接口(API)是充当软件组件接口的规范.大多数功能测试都涉及测试网页

Postman + newman + jenkins 的API自动化测试应用

一.环境配置 Postman postman 的具体使用可以参考另外一篇文章:postman 做接口测试之学习笔记 Newman 第一步,安装nodejs. 第二步,在nodejs命令行安装newman,即命令行输入如下命令: npm install -g newman jenkins 去官网(https://jenkins.io/index.html)下载jenkins 二.Postman + Newman + jenkins 的使用 1. 在postman中导出testcase 文件夹(即存

以WSA开头的API,结合了Windows平台特性

Windows Sockets为了支持Windows消息驱动机制,使应用程序开发者能够方便地处理网络通信,对网络事件采用了基于消息的异步存取策略: 1.WSAAsyncSelect 该函数为指定的套接字(socket)请求基于Windows消息的网络事件通知,并自动将该套接字设置为非阻塞模式: int WSAAsyncSelect ( SOCKET s, HWND hWnd, unsigned int wMsg, long lEvent ); s:标识请求网络事件通知的套接字: hWnd:标识一