这个问题其实困扰了我很久，不是很理解很多团队选择 JMeter 进行接口测试。在最近的面试过程中，发现不论是中级岗，还是高级测试，90% 的团队用的都是 JMeter。它明明是个性能测试工具呀。不是说 JMeter 不能用来做接口测试，但是它的局限性明显了。这就好比汤匙明明是用来喝汤的，但是你就是要用来吃面，还美其名曰：可以同时搞定面和汤，不好吗？反正笔者是没想明白。
01
作为一个当下普及性相当广的测试工具，JMeter 有它自身的优势，总结下大约有以下几点：
易用性：JMeter 上手简单，大部分操作都有对应的元件帮你完成，并且是开源的，社区接受度高。有多少用 JMeter 的人逛过 JMeter 社区？
灵活性：JMeter 提供了 BeanShell 脚本能力，可以让使用者更好地编写个性化的脚本，满足不同场景需求；同时提供了比较高级的扩展能力，允许自己定义和扩展新的协议支持，比如扩展支持阿里提供的 Dubbo 协议的 JMeter 插件等
支持多种协议：除了支持常见的 HTTP 协议之外，还可以直接通过 JDBC Sampler 连接数据库，把期望的测试结果存入数据库中，直接对测试结果进行验证。在编写测试脚本过程中，可以将不同的协议调用使用同一个脚本进行组合调用，写出比较复杂的测试用例。
接口性能复用：这个是笔者最无法接受，但是被使用最广的理由。“写好接口测试后，加下并发数，就能测试性能了”，很多人如是说。如果性能脚本是这么容易搞定的，那我们分析业务模型、数据模型又是为了什么？撑的？
02
JMeter 工具应用在性能场景上，它是款优秀的工具，但是如果用于接口测试，它是存在很多无法解决的缺点。这些缺点也是笔者认为它不是一个优秀的接口测试工具。
团队协作：在性能的场景下，脚本开发可以按场景划分成不同的 JMX 文件，并由多人分别负责。写完基本上是不会变的。而接口测试不同，由于接口测试涉及的范围更广，变更更加频繁，如果团队有 2 个以上的人员进行接口脚本开发，如何分工协作是第一个问题。
已知的解决方案是：根据业务模块来划分，不同的人维护各自的脚本。但是 JMeter 又不支持一次运行多个 JMX 文件，需要额外的代码来处理（放到 Shell 脚本中是一个常见的方案）。
脚本复用：由于 JMX 文件是相互独立，相互之间无法引用的。那个公用模块就无法解耦，比如登录，所有的脚本都需要写一次（至少是复制一次），如果有变动，所有的脚本都需要手动变更，维护成本巨高。
已知的解决方案是把所有的场景放到一个 JMX 文件中去维护。那脚本的原子性就无从谈起。笔者见过一个 JMX 文件中，超过 100 个 Http Sampler 的。
问题定位：在日常 JMeter 运行中，都会以非 UI 的方式进行，这种情况下是没有 Results Tree 给你查看返信息的。如何知道失败的原因是什么？只能以 UI 的形式再跑一次，但由于接口的幂等性或环境原因，往往无法复现，比较尴尬。虽然 JMeter 也提供了 HTML 的报告，但毕竟人家本来就是个性能工具，报告的内容多偏向与性能相关。
现在有很多基于 JMeter 的接口自动化框架是结合了 Jenkins+Git+JMeter+Ant 或者 Allure 来完成的，本质上还是没有解决上面的几个问题。
03
理清楚优缺点后，再回头看看为什么要选 JMeter 来作为接口测试。随着接口测试价值被越来越多的人接受，其对应的测试工具也越来越多，包含但不仅限于 apipost、doclever、itest、MeterSphere 等商用的，还有 Pytest、Junit、HttpRunner 等开源框架，完全可以取代 JMeter 的缺点，同时包含 JMeter 的优点。
进一步想想，也许是 JMeter 声名在外，很多测试的同学能接触或者了解到的工具只有 Jmeter，也不想花额外的成本去学习。就直接用了。从个人的角度上看，没有问题，也能快速解决团队的需求，低成本开展接口自动化测试，完成团队 KPI。但是从团队的角度上看，以 JMeter 为基础开展接口测试，存在很大的局限性。需要进行大量的二次封装，才能解决它自身的缺点（这也是为什么很接口测试工具底层也是选择 JMeter 的原因，利用它的优势，通过 WEB 封装来屏蔽它的缺点）。
所以，如果你想把接口测试真正在团队中落地，慎用 JMeter。
至于选择其他工具或者架构的学习成本问题，从个人的角度上来，其实是有益的。代码能力是现在测试工程师必备的技能了，通过学习接口测试框架，可以有效地有效地锻炼自己的代码能力，比起其他的学习方式，它更能落地，也能更好地补充代码知识、解决实际问题。远比你写一套不实用的 WEB 工程来的有用。
这里还隐藏了一个问题没有展开的，就是关于接口测试用例的要求（在确定的前两点中有提到），这个问题在另一篇文章中有详细的讨论，可移步阅读：你写的接口脚本合理么。
关于你为什么选 JMeter 来做接口测试，还有什么其他的理由，欢迎留言讨论，期待你的答案。
分析得很详细了 我之所以不选 jmeter 是因为脚本量大了 维护起来简直要命 并且业务流程复杂了脚本不方便调试 如果是小项目倒是还好 短平快 对人员要求低
03 节 第二段第二行中'从个人的脚本上看' 这个'脚本'应该是个错别字
Jmeter 用的人多，个人觉得主要还是因为它可以做接口 + 性能测试，对于新人来说，学一个工具可以做 2 个事情，肯定会比要学 2 个工具有吸引力。况且国内 Jmeter 有大量文档可以参考，这对于新手自学也可以起到很大帮助。
Jmeter 我觉得核心的硬伤主要是团队协作，以及脚本封装复用。大部分公司做接口测试规模并不大，团队协作需求相对不那么强，脚本也不算很复杂，没有太多需要相互复用的地方，所以也可以大概理解。甚至其实还有不少团队在用 postman 做接口测试呢。团队协作需求强的，一般都会上平台，光靠工具很难解决。
至于 "问题定位" 这块，其实实际使用并没有这样的问题。jmeter 配合 ant 插件，可以输出包含类似 result tree 内容在内的报告，方便查看请求参数和失败的返回值内容的。
jmeter 是个好工具，至于为什么选他做接口测试，得看使用场景。如果是产品级的接口测试，要协同工作，可能 jmeter 的确不太合适，毕竟它非平台，产出物是 jmx 文件。但如果是交付型项目级的接口测试，要求短平快，拿来改下并发数做性能测试，确实效率很高。所以很多工具本身都没问题，主要是使用场景。
apipost、doclever、itest、MeterSphere 类似这些工具不是你想用就能用的，除非公司买了类似服务，很多个人版、社区版、免费版商用容易收到律师函，公司 IT 懒得去研究法律问题，直接就禁用了，而且，如果只是个别人想用类似工具，在线版肯定不行，那就只能直接部署，还要找服务器等，这样比起来 postman 和 jmeter 的优势就来了。很多人用 jmeter 做接口测试，其实就是和用 pestman 一样，当成是一个私人的接口请求信息存放工具，拿来存放请求脚本，和楼主理解的不一样，不存在团队合作等等场景，而且用 jmeter，后续性能测试也方便，把请求 jmx 改改就能做简单的单接口性能测试了，其实现在大部分公司对功能测试的要求并不是很高，“分析业务模型、数据模型” 并不是手工测试要考虑的事情，那是类似楼主的专业人士考虑的事情。所以考虑为什么用 jmeter，不如思考下为什么不用 apipost、doclever、itest、MeterSphere ，这样对测开人员落地相关工具还是很有参考意义的
从各个渠道的反馈来看，我大概能理解为什么了。现实情况是大多数测试团队对于接口测试的落地还只是存在于个人或者少数人的阶段。测试的发展还是任重道远。就像其它楼主所说，个人用 JMeter 还是比较方便，还容易上手。
kuroky
回复
itest 是免费的，他的接口测试看这里
还有调用链等
具体看这个贴子，有不少创新思路
https://testerhome.com/topics/30495
陈恒捷
回复
postman 怎么了，听你的意思很瞧不起 postman， 我觉得小量的接口测试用 postman 反而比 jmeter 更方便
爆冲弧圈
回复
不是瞧不起，无意引战。
postman 本身是很好的接口测试工具，日常的接口调试或者简单测试，我也喜欢用 postman 。上手比 jmeter 还要简单（不用管什么线程组、sample 这堆术语），当然对应的灵活性扩展性等也会比 jmeter 稍微差一些。
我这里举这个例子，只是想说明有很多团队对于接口测试工具的需求其实并不那么复杂，类似 postman 这样的灵活性弱一些但简单好用的工具，也可以很好满足。
陈恒捷
回复
确认如此，对于个人而言工具不是越复杂越好，也不是功能越多越好，反而是越简单，越便捷越好，很多平台为了完成各种各样的功能，适配各种各样的场景，会存在为了满足极少一部分场景，把系统做的很复杂，用起来成本很高，反而类似 jmeter postman 这种简单粗暴的工具类应用更得人心，就比如我管的团队，虽然有接口测试平台，但是大家平常还是喜欢用 postman 和 jmeter，只有为了做自动化和 mock 的时候才会在平台上去做。
自己写代码最灵活
工具何其多， 用什么根据自己的实际需要选择即可， 没有必须要选择哪种， 选 Jmeter 只需要一个理由， 就是当下产生的价值比其他工具高，更适合我而已
选择工具，没有更好，只有合适。不同阶段，选择适合的工具，才能更高效。
这个是笔者最无法接受，但是被使用最广的理由。“写好接口测试后，加下并发数，就能测试性能了”，很多人如是说。如果性能脚本是这么容易搞定的，那我们分析业务模型、数据模型又是为了什么？撑的？
真诚请教，分析业务模型、数据模型指的是确定指标的过程吗？毕竟我也是很多人中的一个 
PS : 今年我们也写过一段时间的 jmeter，主要是团队中的代码水平较差，而 jmeter + ant 比较容易上手，感觉遇到问题还是蛮多的，比如说 不能直观反映结果（用的是公司的 CI 平台），效果就是每次集成发邮件给你，还需要点进去才可以看到正确与否。再比如说 不能执行多个（文章里面也说到了），还有模板不好看，自己也不会改 
Jmeter 相对做测试来说好入手且上限很好，可以做基础的各类型接口调用，也支持重量级的性能测试或复杂的接口自动化搭建，当然也存在一些公用软件都有的问题：功能全而不深，但是这点相对其强大的功能组件库来说就是瑕不掩瑜啦。但是现实使用中却很少有用它来做接口自动化测试的，因为相对自写的框架来说，维护成本确实相对较大，而且 standalone
leixs
回复
性能测试并不是简单的上压力就完事的。你需要分析业务模型是什么样的，哪些节点需要做性能，业务比例是多少。
还需要考虑数据模型，比如哪些是基础数据，哪些需要参数化，哪些可以直接关联，对系统的影响有哪些，等等。
具体可参考：https://mp.weixin.qq.com/s/dJ8sIoQ5I3M1SgbrE-npPQ
CKL的思考
回复
感谢回复，感觉说的挺全面的，先关注后期需要实践的时候再系统的看看~
就我所在的工作场景下，判断指标，确定压测场景，数据铺底，参数化这些肯定是需要做的，不过可能都比较粗糙，比如，
- 数据铺底直接用压测脚本先跑几个小时，数据就达标了，最多的也就是十万 百万级
- 参数化可能就是需要关联的用户，中间参数 (常见就是交易编号，审批编号啥的)
- 业务场景基本就是基于客户历史的业务分布来确定了
对于瓶颈定位原因分析啥的，还停留在比较初级的阶段，只能找到现象，比如说 CPU 太高了，内存占用太高，垃圾回收太频繁，或者系统报错了，基本还是找开发解决，感觉路还很长..
CKL的思考
回复
赞同，很多时候开发人员都觉得没必要进行接口测试，或者对测试出来的问题有反感，例如数据敏感性，接口传参类型定义不规范，他们更多考虑的是业务上不会出现问题即可，不会从性能、安全等方面去考虑~
总结得不错，但工具是工具，怎么使用还是靠人
单兵神器
我选择 jmeter 是因为上手快，简单。
我代码能力弱，所以首先考虑这种工具，，，