最近刚开始开发接口自动化框架，有一个雏形 (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 等等，大部分性能工具我都使用过，拿最常用的商业或开源工具来做一下简单对比：
总而言之，当遇到复杂的业务场景时，商业工具也不例外，性能也会相对普通业务下降很多。
高性能压测场景，是一项复杂的工程，需要多工具、多团队配合，不是简单的一个工具就可以解决的
rest-assured
postman 算不算
自己写
如果代码基础好，rest-assured
代码基础一般，好多分享里面的平台/框架看起来都挺好用（例如美团的 lego ，大疆的 HttpRunner），但没实际用过，不好评判。
陈恒捷
回复
坑了，基本上把 rest-assured 里面的基本功能自己写了一遍https://testerhome.com/topics/11823
发现早就有人写了使用情况：
https://testerhome.com/topics/7060
https://testerhome.com/topics/6451
eolinker luckyframe doclever hitchhiker httprunner 自研
—— 来自 TesterHome 官方 安卓客户端
postman+newman+jenkins
JSON 类 rest-assured，实际是 JSONPath 实现了一套处理 json 的 DSL。
业务逻辑基本上是 dsl，JVM 上很多互操作语言，那种熟悉用那种实现。 JAVA 没有模式匹配，造这种轮子，相当之蛋疼。
httprunner，根据实际再改改，非常适合公司自己用
postman+newman+jenkins
当然啦，其实 python 的 requests 库也很好写
其实 jmeter 的接口测试封装的思路就很好，但是那套 ui 和设计逻辑实现的太复杂、太不友好了，操作起来和设计起接口来是不够方便的。
另外，jmeter 为了通用性设计做了很多过度设计，不过整体来看，jmeter 的思路和方向都是很完美的，可能再细节上别考虑太多通用，比如 if 控制器啥的，如果都用到这个功能了，干嘛不通过代码实现呢？或者伪代码的脚本来实现。
vball
回复
那这 1000+ 个线程在本地（负载客户端）CPU 上是实际生成运行了呢还是没有？
用 go 写能轻松搞定是因为 1000+ 线程在 CPU 上不用排队还是只有一个线程 post 了 1000+ 请求？
vball
回复
回复：go 的性能不错，但是比 wrk 的性能差一半，这些我都测试过。
Jmeter 应用场景：针对大部分普通性能测试来说，jmeter 够用且稳定。而且支持复杂场景和复杂业务。
针对大规模性能测试，比如电商全链路压测来说，单独用 jmeter 就不行了，需要多工具配合使用。
go 和 wrk：这类高性能工具或开发语言，当碰到复杂场景的时候，性能一样会出现瓶颈。这就跟说 python 比 java 简单一样，简单功能实现，python 是语法简单，但是对于复杂的后端业务来说，实现起来可能 python 更费劲。
合适的场景用合适的工具：价值百万的思博伦、二次开发的 wrk、go 开发的多线程压测工具、jmeter、loadrunner 等等，大部分性能工具我都使用过，拿最常用的商业或开源工具来做一下简单对比：
总而言之，当遇到复杂的业务场景时，商业工具也不例外，性能也会相对普通业务下降很多。
高性能压测场景，是一项复杂的工程，需要多工具、多团队配合，不是简单的一个工具就可以解决的
在路上
回复
单比极限施压能力，基于 go 的压测工具的确比不上 wrk
不过，一个实例不行，就来多个实例
https://github.com/jacexh/ultron
这是一个基于 go 的分布式压测框架
然后谈下自动化测试框架，我目前觉得用代码编写的自动化 case 才是最高效简洁又能大规模应用的
但需要良好的设计
在路上
回复
无论什么工具，单个负载客户端同时要启 100+ 线程的时候我都会选择分布式执行，这点从 LR 时代就做了很好的设计，所以不需要纠结单个客户端能压多少线程上去，太多了本地也要排队、网络开销也大
机器不够多的场景我觉得不大需要考虑，谁家业务需要支撑 1000+ 并发的时候还提供不了 10 台 4C、8G、1Gbps 的 vm 呢
在路上
回复
我的建议是：
- 测试数据没必要使用 excel 管理，臃肿，并且缺乏语义
- 用例层屏蔽 raw body，关注业务逻辑本身
- 高频业务流程适当的封装
为什么那么多人喜欢用 excel 来管理测试数据或者测试用例，我个人感觉 excel 不方便管理，而且阅读和编写都不友好，业务上对数据的动态要求，还要定义和增加解析的成本。站在测试数据动态要求的角度，感觉这是一个逆逻辑（代码本身可以动态生成，但是数据管理不支持，然后反过来定义再解析）我个人目前 是测试数据放在 java 对象中 (为了后期测试数据来源改变减少维护,目前测试数据动态生成,脚本关心逻辑，数据都由代码构造)，测试脚本就直接 testng 写代码，然后写 listener 去监听运行， 然后产生 testsuite[testmethod1,testmethod2...] 的 json 数据，格式符合 postman v1，为了后期接口迁移减少维护 ,因为市面上很多 api 管理工具支持 postman 数据导入。
然后根据题目 接口自动化框架 我觉得 https://github.com/YMFE/yapi 是我用过最好 用到，真正考虑到用户体验，优化业务逻辑的
目前业界上用的比较多的是基于 java 的 testng，基于 python 的 robot framework 或者 pytest 也有人在用。Jmeter 或者 postman 主要是性能测试或者接口测试工具，可以用来做自动化，但拓展性不好。楼主如果会 java，推荐使用 testng，如果会 python，推荐使用 pytest，如果不会编码，可以尝试学习 python，比如好入门，但单纯的工具使用，可以用 Postman，当然，Postman 主要是基于 http 接口测试。
无论哪种，熟悉之后都挺好用，未来能组件化，可拓展就好，毕竟开发技术和架构也是不断在变
现在使用 python3 +unittest(@parameterized.expand)+excel ，很大众的一个框架。个人感觉适合自己产品业务逻辑，并且效率高的框架就是好用的框架。
一直用 Robot Framework + user keyword 做接口测试。
数据管理、用例执行，结果分析都特别方便，开发效率奇高。
这里的评论我看了一遍感觉极其困惑，看看标题 “你用过的最好用的接口自动化框架？” 感觉里面一部分人在说接口测试，一部分然再说接口压力测试，然后细节上几乎没有人说框架的结构原理实现，都是在探讨工具...，接口测试只是个宏观的是测试方法概念，真正想听的应该是在一些业务场景中的产出的针对接口的测试方案以及工具辅助选择
在路上
回复
感谢大佬的分享，最近我也在研究 wrk+lua 的性能压测，想请教一下您，wrk 集群压测思路是什么，wrk 集群压测后的压测报告的合并的思路
