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