这个问题其实困扰了我很久，不是很理解很多团队选择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来做接口测试，还有什么其他的理由，欢迎留言讨论，期待你的答案。
