这个问题其实困扰了我很久,不是很理解很多团队选择JMeter进行接口测试。在最近的面试过程中,发现不论是中级岗,还是高级测试,90%的团队用的都是JMeter。它明明是个性能测试工具呀。不是说JMeter不能用来做接口测试,但是它的局限性明显了。这就好比汤匙明明是用来喝汤的,但是你就是要用来吃面,还美其名曰:可以同时搞定面和汤,不好吗?反正笔者是没想明白。
01
作为一个当下普及性相当广的测试工具,JMeter有它自身的优势,总结下大约有以下几点:
02
JMeter工具应用在性能场景上,它是款优秀的工具,但是如果用于接口测试,它是存在很多无法解决的缺点。这些缺点也是笔者认为它不是一个优秀的接口测试工具。
已知的解决方案是:根据业务模块来划分,不同的人维护各自的脚本。但是JMeter又不支持一次运行多个JMX文件,需要额外的代码来处理(放到Shell脚本中是一个常见的方案)。
已知的解决方案是把所有的场景放到一个JMX文件中去维护。那脚本的原子性就无从谈起。笔者见过一个JMX文件中,超过100个Http Sampler的。
现在有很多基于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来做接口测试,还有什么其他的理由,欢迎留言讨论,期待你的答案。
END
标星、点赞、关注三连走起,感谢支持。
如果想阅读更多文章,请关注我的公众号。