问答 你用过的最好用的接口自动化框架?

在路上 · 2018年01月30日 · 最后由 null 回复于 2019年08月30日 · 5587 次阅读

最近刚开始开发接口自动化框架,有一个雏形 (https://testerhome.com/topics/11823)。
但是今天尝试着写了一下业务流接口测试,发现还是不够简便,主要原因如下:

  • 参数化目前使用的是 excel,操作步骤较多;
  • 遇到类似 五种 request body, 对应三种 response body 时,会产生重复操作的情况。需要把三种 response body 写五次
  • 业务流测试中,操作繁杂,不够简便(没有商业性能测试工具的那种代码操作方便,本人没有用过商业接口测试工具)

请教大家,在测试职业生涯中,用过的最好用的接口自动化框架是什么?

  • 商业工具(最好包含介绍链接):
  • 开源工具(最好包含介绍链接和源码地址):
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
最佳回复
vball 回复

回复:go 的性能不错,但是比 wrk 的性能差一半,这些我都测试过。
Jmeter 应用场景:针对大部分普通性能测试来说,jmeter 够用且稳定。而且支持复杂场景和复杂业务。
针对大规模性能测试,比如电商全链路压测来说,单独用 jmeter 就不行了,需要多工具配合使用。
go 和 wrk:这类高性能工具或开发语言,当碰到复杂场景的时候,性能一样会出现瓶颈。这就跟说 python 比 java 简单一样,简单功能实现,python 是语法简单,但是对于复杂的后端业务来说,实现起来可能 python 更费劲。

合适的场景用合适的工具:价值百万的思博伦、二次开发的 wrk、go 开发的多线程压测工具、jmeter、loadrunner 等等,大部分性能工具我都使用过,拿最常用的商业或开源工具来做一下简单对比:

总而言之,当遇到复杂的业务场景时,商业工具也不例外,性能也会相对普通业务下降很多。
高性能压测场景,是一项复杂的工程,需要多工具、多团队配合,不是简单的一个工具就可以解决的

共收到 37 条回复 时间 点赞

为什么那么多人喜欢用 excel 来管理测试数据或者测试用例,我个人感觉 excel 不方便管理,而且阅读和编写都不友好,业务上对数据的动态要求,还要定义和增加解析的成本。站在测试数据动态要求的角度,感觉这是一个逆逻辑(代码本身可以动态生成,但是数据管理不支持,然后反过来定义再解析)我个人目前 是测试数据放在 java 对象中 (为了后期测试数据来源改变减少维护,目前测试数据动态生成,脚本关心逻辑,数据都由代码构造),测试脚本就直接 testng 写代码,然后写 listener 去监听运行, 然后产生 testsuite[testmethod1,testmethod2...] 的 json 数据,格式符合 postman v1,为了后期接口迁移减少维护 ,因为市面上很多 api 管理工具支持 postman 数据导入。

vball 回复

回复:go 的性能不错,但是比 wrk 的性能差一半,这些我都测试过。
Jmeter 应用场景:针对大部分普通性能测试来说,jmeter 够用且稳定。而且支持复杂场景和复杂业务。
针对大规模性能测试,比如电商全链路压测来说,单独用 jmeter 就不行了,需要多工具配合使用。
go 和 wrk:这类高性能工具或开发语言,当碰到复杂场景的时候,性能一样会出现瓶颈。这就跟说 python 比 java 简单一样,简单功能实现,python 是语法简单,但是对于复杂的后端业务来说,实现起来可能 python 更费劲。

合适的场景用合适的工具:价值百万的思博伦、二次开发的 wrk、go 开发的多线程压测工具、jmeter、loadrunner 等等,大部分性能工具我都使用过,拿最常用的商业或开源工具来做一下简单对比:

总而言之,当遇到复杂的业务场景时,商业工具也不例外,性能也会相对普通业务下降很多。
高性能压测场景,是一项复杂的工程,需要多工具、多团队配合,不是简单的一个工具就可以解决的

在路上 回复

无论什么工具,单个负载客户端同时要启 100+ 线程的时候我都会选择分布式执行,这点从 LR 时代就做了很好的设计,所以不需要纠结单个客户端能压多少线程上去,太多了本地也要排队、网络开销也大
机器不够多的场景我觉得不大需要考虑,谁家业务需要支撑 1000+ 并发的时候还提供不了 10 台 4C、8G、1Gbps 的 vm 呢

目前业界上用的比较多的是基于 java 的 testng,基于 python 的 robot framework 或者 pytest 也有人在用。Jmeter 或者 postman 主要是性能测试或者接口测试工具,可以用来做自动化,但拓展性不好。楼主如果会 java,推荐使用 testng,如果会 python,推荐使用 pytest,如果不会编码,可以尝试学习 python,比如好入门,但单纯的工具使用,可以用 Postman,当然,Postman 主要是基于 http 接口测试。

postman+newman+jenkins😆
当然啦,其实 python 的 requests 库也很好写

eolinker luckyframe doclever hitchhiker httprunner 自研

—— 来自 TesterHome 官方 安卓客户端

吕俊杰 回复

嗯嗯,原生的框架其实就那几个,我是想问二次开发或者优秀的开源框架

其实 jmeter 的接口测试封装的思路就很好,但是那套 ui 和设计逻辑实现的太复杂、太不友好了,操作起来和设计起接口来是不够方便的。
另外,jmeter 为了通用性设计做了很多过度设计,不过整体来看,jmeter 的思路和方向都是很完美的,可能再细节上别考虑太多通用,比如 if 控制器啥的,如果都用到这个功能了,干嘛不通过代码实现呢?或者伪代码的脚本来实现。

陈雷 回复

有道理,jmeter 作为功能和性能的开源测试工具,其实越来越完美了

在路上 回复

单比极限施压能力,基于 go 的压测工具的确比不上 wrk
不过,一个实例不行,就来多个实例

https://github.com/jacexh/ultron
这是一个基于 go 的分布式压测框架

在路上 回复

jmeter 作为客户端施压的并发性能不行。

vball 回复

请教一下,JMeter 是怎样的施压性能不行呢?能具体点吗

槽神 回复

普通机器单机并发线程 1000+,就会出现卡顿,对服务器造成的压力不够,当然你可以多台客户端。用 go 重写,单机就能轻松搞定。

vball 回复

那这 1000+ 个线程在本地(负载客户端)CPU 上是实际生成运行了呢还是没有?
用 go 写能轻松搞定是因为 1000+ 线程在 CPU 上不用排队还是只有一个线程 post 了 1000+ 请求?

然后谈下自动化测试框架,我目前觉得用代码编写的自动化 case 才是最高效简洁又能大规模应用的
但需要良好的设计

jacexh 回复

我想说的是,我们二次开发的 wrk 已经实现了,可惜不是我开发的

在路上 回复

我的建议是:

  • 测试数据没必要使用 excel 管理,臃肿,并且缺乏语义
  • 用例层屏蔽 raw body,关注业务逻辑本身
  • 高频业务流程适当的封装

然后根据题目 接口自动化框架 我觉得 https://github.com/YMFE/yapi 是我用过最好 用到,真正考虑到用户体验,优化业务逻辑的

rockyrock 回复

我们公司用的是去年做出来的 doclever,开源好用,功能齐全得很!

无论哪种,熟悉之后都挺好用,未来能组件化,可拓展就好,毕竟开发技术和架构也是不断在变

现在使用 python3 +unittest(@parameterized.expand)+excel ,很大众的一个框架。个人感觉适合自己产品业务逻辑,并且效率高的框架就是好用的框架。

一直用 Robot Framework + user keyword 做接口测试。
数据管理、用例执行,结果分析都特别方便,开发效率奇高。

null 回复

给我个邮箱,我把源码发你

在路上 回复

好的,非常感谢您

在路上 回复

好,非常感谢您。97618461@qq.com

null 回复

百度云盘给你吧,链接:https://pan.baidu.com/s/1w8NKkLI1gDKKG2fMb1c17Q 密码:zb36

jacexh 回复

是的,需要很好的设计,目前我自己做的一个自动化框架,就碰到了问题

rest-assured

在路上 回复

感谢大佬的分享,最近我也在研究 wrk+lua 的性能压测,想请教一下您,wrk 集群压测思路是什么,wrk 集群压测后的压测报告的合并的思路

postman 算不算

如果代码基础好,rest-assured

代码基础一般,好多分享里面的平台/框架看起来都挺好用(例如美团的 lego ,大疆的 HttpRunner),但没实际用过,不好评判。

陈恒捷 回复

坑了,基本上把 rest-assured 里面的基本功能自己写了一遍https://testerhome.com/topics/11823
发现早就有人写了使用情况:
https://testerhome.com/topics/7060
https://testerhome.com/topics/6451

在路上 关闭了讨论 02月08日 10:11
在路上 重新开启了讨论 02月08日 10:11

httprunner,根据实际再改改,非常适合公司自己用

postman+newman+jenkins

JSON 类 rest-assured,实际是 JSONPath 实现了一套处理 json 的 DSL。
业务逻辑基本上是 dsl,JVM 上很多互操作语言,那种熟悉用那种实现。 JAVA 没有模式匹配,造这种轮子,相当之蛋疼。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册