接口测试 Jmeter 接口自动化和 Python 接口自动化，到底选哪个？
背景
很多刚接触接口自动化的朋友都会疑惑，市面上 Jmeter 接口自动化，Python 接口自动化，到底选哪个开始学习呢？导致这个学学，那个学学，遇到困难就放弃，没有哪一个学到最后了。
作为一个多年项目实战经验者，那么今天我们来谈一谈，接口自动化到底怎么学合适。
Jmeter 接口自动化
Jmeter 是个开源软件，很多朋友认识 Jmeter 都是因为它可以做性能测试。但是 Jmeter 不仅仅止步于此，后期做接口自动化也是和 Python 不相上下。
特点
- 学习者不需要会代码，就可以完成项目所有接口的自动化脚本；
- Jmeter 自带 20 种控制器、40+ 种函数、20+ 种配置元件，可以满足 99% 的项目接口自动化需求；
- 可以集成不同的应用，数据库，redis，mock，dubbo、jar 包二次开发等都不在话下；
- 测友可以根据喜好（项目特性）自由组合（适合项目的）测试框架；
- 实在满足不了的，可以用 beanshell 来写；
- 因为 Jmeter 自带组件、函数，所以编写接口自动化脚本特别高效、快捷。
总结：适合对代码不敏感的测友，不会代码也可以完成接口自动化，设计框架。适合紧急迭代的项目。
Python 接口自动化
由于 Python 的语言特性，如果对代码不敏感的，就不建议了。如果想学好 Python，先学接口自动化是个不错的选择。
特点
- Python 做接口自动化有自带的框架，如 Pytest、Unittest 等；
- 学会了 Python 接口自动化，再学 UI 自动化就很容易上手，原理相同；
- Python 接口自动化难点在于测试框架，需要自己封装，否则没有创新点；
- Python 的框架可以自由设计，函数可以自己封装，相对灵活，可扩展性较强；
- Python 写接口自动化脚本需要时间，不适合紧急迭代的项目。
总结：想学 Python，从接口自动化开始，而不是测开。学会 Python 接口自动化的里程碑是要会设计框架。不适合紧急迭代的项目。
谈项目
为什么要考虑项目呢？我们都知道，做接口自动化，就是为了完成项目的接口，提高测试的效率，提高项目的质量，那么到底什么才是最适合你们公司项目的技术？我们先看看下面几种类型。
- 时间相对宽松的大项目
（公司有安排选哪个技术，就听公司安排，业余时间学另一种）
周期长的大项目，测试时间比较充裕，用 Python 还是 Jmeter 都可以来做，如果想早点做完划划水，首选 Jmeter。
看中自我提升的，在测试时间比较充裕的情况下，用 Python 写测试框架，实现接口自动化，项目上线后，在测试团队内部推广，提高自我品牌价值。
- 紧急迭代项目
首选 Jmeter，Python 连上场的机会都没**一首凉凉送给Python**
写在最后
随着测试行业的内卷趋势越来越严重，多学习不是坏事，最怕的就是这一句：我们公司用不到，我不用学。
时刻注意：在 IT 行业，你不可能在一家公司干到养老。
小七老师真棒👍🏻
都要会，但是首选 python
首选肯定是 python，除非不会 coding，但是连 coding 都不会的 jmeter 能用到什么程度呢？？对吧
小孩子才做选择
没必要选，两个到要会。
接口自动化 5 年内基本被淘汰，未来一定是 流量回放（jvm_sandbox_repeater）+ 全链路监控（sskwalking）的天下，接口自动化的成本高，收益太小；就连 UI 自动化存在的意义也比接口自动化存在的意义要大。在 k8s 的支持下，流量回放 + 全链路监控，做接口回归，压力测试都是一件很简单的事情。
nore
回复
这位同学做过多久的接口自动化？
1、“5 年内会被淘汰？” 口气未免狂妄了些，接口自动化已经存在不止 5 年了，而且会越来越普及。
2、UI 自动化的意义大于接口自动化，这个观点我也不是很认可。自动化的意义多大，取决于对项目的效益，而非自动化本身。
在 k8s 的支持下，流量回放 + 全链路监控，做接口回归，压力测试都是一件很简单的事情。
并不是简单的事情，至少目前业内还没成功案例。
nore
回复
这个有点绝对了吧。
流量回放无法解决未上线新功能测试的需要（没有流量可录制），对于接口调用频率不高、数据安全性要求高的 ToB 类业务也不见得适用（流量不足以覆盖大部分场景），还是有自身的局限性的。只是他相比手工写自动化脚本，自动化成本降低很明显，所以比较受欢迎，应用领域也更多是有大量流量的 ToC 类业务。
至于说 k8s 支持后这两个都很简单，没太理解这个点。k8s 貌似本身并没有自带接口回归、压力测试的能力。你想说的和 k8s 组合的 istio 这种服务网格机制，可以更方便控制服务间流量吧？
Jmeter 是一个工具，Python 是一门语言。
Jmeter 学会了，还是不懂代码，Python 学会了，有一门语言立足了。
nore
回复
sandbox 录制要是能够解决所有问题，要接口自动化做什么？
1、新接口上线要不要接口测试？
2、录制回放的流量没有包括线上全部场景，线上能保证不出问题么？
乾行
回复
问题 1：接口自动化做的也不是新接口的测试，也是原有接口的回归，而流量回放也可以做到，新接口的接口测试大部分还是通过手工调用 postman 解决；问题 2：流量回放完全可以做到包含线上全部场景，只要你手工做线上回归，就会存在线上的流量，就可以用来做线上回归。
nore
回复
1、抱歉，新接口也是可以自动化的。
2、接口也不只有 http 协议的接口。
3、线上测试时可能还没有你的流量回放系统了
4、当系统复杂度升高时，系统配置与开关引发流量发生变化时，你这流量回放如何处理？
凡事没有绝对，多开阔一下自己的视野！
nore
回复
哈哈，不错。
保持自己习惯就好，个人喜欢辩证地看东西多一点，所以不大喜欢太绝对的东西。不过观点无对错，期待你后面对楼上说的基于 k8s 支持做流量回放的成功案例分享。
团队现在还大部分用 jmeter 跑接口自动化，早些年的历史原因，jmeter 对于小团队做接口测试和自动化还算不错，对于新手了解协议也不错，但是在现在这个时间节点来说，jmeter 的限制是真的太大了。流程灵活性不高，要实现一些业务性的测试，要一些骚操作和传参，跟 python 脚本的灵活性不可同日而语。beanshell 的调试也是一个诟病的地方，出错查原因就那个堆栈信息很不好看，不熟 java 简直一脸懵逼。
而且在稍微大点的团队，还要考虑到协作和复用的问题，我经常问管理接口自动化的同学要 jmeter 文件，动辄打开一分多钟，更不要说协作了，根本很难协作。你见过一个 jmeter 写上百个 beanshell，一旦要改某个地方，要改上百次么。
团队今年接口测试已经整体转平台了。剩那些老的 jmeter 的自动化每天都在跑着
那啥，希望楼主不要介意，并不是杠你，就是文章里一些定论性的观点，其实有时候真的跟我们实际项目的情况不是那么符合和准确，也稍微显得有点浅显，容易被杠。建议楼主可以改一下风格试试，可以从一些具体功能教程来，也可以举一些比较精彩的例子
nore
回复
首先，k8s 是做自动化部署的，是一个框架，执行调度你的自动化任务
其次，流量回放，全链路是方便定位分析性能问题的
有这两样东西，你就会接口自动化，性能测试了吗？你会个锤子哦
搭个框架，弄几个专业词汇就敢说性能测试，接口测试简单，不喷你都不行
如果涉及复杂测试场景，jemter 的优势，相较于 python，就不那么明显了。
看完大家的讨论，讨论蛮激烈的。就单本篇文章来说，个人觉得写的过于绝对了。个人经历过得项目。jmeter 就很难满足需求（加密解密之类需要搞个 java 包之类得场景），索性直接改 python 了。
迷龙
回复
jmeter 本身就是 java 语言开发的，支持 jar 包是它的一大特色，而不是缺点。
python 是另一种语言，实现加解密不是什么难事，但是需要自己写。
两者都是可以解决问题的，只不过效率不一致。
nore
回复
很想问，用户能覆盖多少场景？你打算回放对少天的数据来支撑。如果产生的代码问题对于新用户没有问题，突然注册一个用户产生事故，你确定流量回放当中覆盖了？这还是一个假设性的问题。
性能测试的难度不在设计脚本吧？是个人学习一个星期都可以用 jmeter 来写脚本吧。难点是在怎么分析问题定位问题好吧，什么流量回放，K8S，自己都没做出来就拿出来说，你觉得有什么说服力呢？
