API研发管理与自动化平台不可兼容?

2022-09-26  微不足道 

工具和框架这两件事看起来互不相干,甚至有些互相排斥,可是如果这两种接口测试技术手段能相互支持,能融合到一起吗?下面让我们一起来深入的讨论下这个问题;

其实,工具和框架,这两条通向罗马的路可以并成一条快速通道,可以让我们大踏步进军罗马。所以我们需要掌握一款好用的工具比如 Eolink,或者建议用自己的技术沉淀出自己的框架,如果我们正确地混合使用它们,实质上就可以搭建起一个接口测试平台,能帮助我们更快速地完成测试任务并且顺利的交付。
在这个设计过程中,这样做有两个显而易见的好处。
一是能充分发挥 Eolink 界面化的优势,快速完成大量的脚本撰写工作;二是通过自己的框架完成测试脚本的执行,所有的过程代码都会存储到自己的代码仓,这样,既可以留下测试的过程资产,也便于版本控制,这也为持续集成、持续交付等平台提供了无人值守的、按需驱动测试的途径。

其实,这样做最大的好处就是可以提升整个团队的工作效率。

在我的团队中,有一些小伙伴很不喜欢写代码,相反,他们更喜欢使用工具,工具用得也非常得心应手,我相信每个团队中都会存在这样的情况。但是,仅仅依靠工具,只能一个人完成一件事情,这并不方便团队内部的团队合作、交接和技术积累。

但是,我们又没有办法让所有人一下子都喜欢上写代码,那么该如何降低代码编写门槛呢?通过工具和框架搭建接口测试平台,其实就是一个很好的解决方案。这样的话,既然可以让团队有技术积累,又能给团队中一些编码能力比较薄弱的小伙伴学习时间,最重要的一点是,这不会影响整个工作的进度。

写到这里我试着回想了一下,使用 Eolink做接口测试的整个流程,与大家一起分享一下:

● 设计API
API设计意味着需要提供一个有效的接口,帮助API使用者(内部和外部)更好的使用和了解,API Studio 能够详细、规范地记录API的所有信息,我们内部团队一般通过它来设计、统一 API 的开发规范。系统会自动根据设计好的 API 文档生成预览的请求、返回数据。

● 通过工具规范管理API流程
在我们内部的API 文档中会清晰体现 API 的创建人、负责人、最后修改时间等具体的操作信息,并且能够自定义 API 的 Tags,在具体的工作过程中来帮助我们更好地管理 API的开发工作。

● 通过Eolink对wagger、Postman 数据进行导入
不同的项目对数据有着严禁的数据要求,因为不同的数据直接对应着bug的产生和数量,我们在开发或测试过程中通过API Studio 一键导入并兼容Swagger、Postman、Rap、Yapi 这些不同数据,并无缝迁移类型不同的项目数据,省去了一些繁琐的步骤也不用担心数据迁移成本,重要是节省了项目的研发时间。

● 对代码仓库进行绑定,病一键生成接口文档
在项目的研发期间对 Github、Gitlab、码云等代码仓库进行绑定,同时兼容Swagger 代码注解生成API文档的方式,实现一键自动生成接口文档。

● 像管理代码一样对 API 进行版本管理
Eolink工具实时记录了接口文档的每一次修改,并且自动生成版本信息。通过版本对比功能准确无误的明白各个接口版本之间的差异;当API发生变动时通知相关人员,在日常工作中,设置 API 的通知事件,如当 API 变为测试状态时通知测试人员、当 API 出现异常时通知相关人员。

● 发起 API 测试
当开发人员编写好 API 文档后,我们测试团队自主切换到 API 测试页面一键发起测试,并通过自动生成测试数据,并且能够通过 Javascript 代码对请求参数、返回结果进行二次加工,实现业务场景较为复杂的测试工作。

● 编写 JSON、XML 请求数据生成各语言测试代码
使用测试编辑器在开展测试工作过程中直接编写 JSON、XML等数据结构。系统能够自动根据请求信息生成主流语言的测试代码,复制代码后应用于开展具体的工作中。

● 集中管理用例,一键批量测试
使用Eolink特有的测试控制台功能,对多个 API 的测试用例进行批量测试,并且在控制台中能够直接查看测试结果。

● 设置断言规则后判断返回结果
我们通过设置返回结果的断言规则,让系统自动根据规则判断返回结果
通过生成的测试报告快速定位接口的错误原因。

● Mock API 实现前后端同步
开发人员通过创建 Mock API 的触发条件,系统会自动根据请求参数的不同返回相应的结果,可以真实地模拟后端数据,当后端还没开发完成的情况下,前端开发人员可以通过 Mock 数据预防联调过程中的错误,加速开发进程。

● 了解所有 API 的状态和质量情况
通过对API不同状态进行统计,清晰了解当前API 的状态分布,通过关联bug实时的了解Bug 状态以及bug负责人。通过测试用例覆盖率、测试用例覆盖系数等统计数据,了解测试工作的当前完成情况,帮我煮我们更加完善测试相关工作。

● 0 代码 API 自动化测试
跟着项目不断的迭代,接口数量越来越多,但是每次迭代回归测试任务也越来越重。测试人员熟练的使用Eolink的界面来创建 API 自动化测试,一键发起自动化测试并实时得到测试结果,极大的提高回归测试效率。

● 在接口之间传递参数
组内零代码基础测试人员在使用Eolink做测试过程中,并不需要学习变量和脚本语法,通过界面可以直接设置复杂的参数传递规则,如将注册后的 Token 传递给登录 API,将登录后的 Cookie 传递给后续API进行多个接口的测试工作,并且直接对JSON和XML的结果进行校验。

● 对数据库直接进行操作
Eolink工具在测试过程中可以直接对数据库进行操作,方便在测试之前写入测试数据、测试中校验数据、测试后清空脏数据避免因为由于数据造成必要的影响。

● 通过 Javascript 编写复杂的测试用例
有代码基础的测试人员通非常会使用Javascript 脚本模式。通过非常简单的脚本来编写复杂的 API 测试用例,实现自动化测试中复杂的流程跳转、数据加解密的操作辅助当前的测试任务。

● 通过导入 API 文档直接生成测试代码
导入文档后一键生成调用代码,帮助测试快速的完成请求参数以及校验规则。

● 通过定时任务自动发起自动化测试
系统会记录每一次的请求历史,您可以看到详细的测试时间、请求
及返回信息等。

● 自动生成测试报告
每次测试都可以生成详细测试报告,支持在线查看和离线下载;
报告中会显示API的请求时间、请求参数、返回结果、校验结果、错
误原因等信息,方便对API进行排查。

● 自动将 API 文档变更同步到测试用例中
当API文档发生变化时,可以一键将最新的API文档内容同步到测试
用例中,减少维护测试用例的时间成本。

讲到这你肯定会问:“你把用 Eolink 类工具完成API研发管理与自动化测试,以及自我封装测试框架这两种方法各打五十大板,那它们到底哪个好?”

这也是 UI 操作和低代码(工具)操作的区别之一,UI 操作更加直观,可以在你的脑海里留下更深刻的印象;而低代码(工具)操作给人留下的印象就比较模糊,但是,通过用低代码(工具)写脚本来完成接口测试流程并结合自动化平台方式,比较便于维护、团队合作以及留存。

其实我的目的并不是想让你分出个好坏,好坏之分都是相对的,每个人的习惯和喜好都不相同,但是我们却可以把它们的优点都利用好,把这两种技术的优势都发挥出来。

我们利用 Eolink 设计整个接口流程规范模式更加直观、快速的优势,将它变成接口测试脚本的初始脚本的编写工具,联动前端、后端与测试人员,构建敏捷团队,通过与其他系统对接,强化 DevOps 能力。

所以我就不在这里详细讲解了,如果你感兴趣,可参照官网
https://www.eolink.com/ 课后可以自行学习。

106°/1063 人阅读/0 条评论 发表评论

登录 后发表评论