这个问题其实困扰了我很久,不是很理解很多团队选择 jmeter 进行接口测试。在最近的面试过程中,发现不论是中级岗,还是高级测试,90% 的团队用的都是 jmeter。它明明是个性能测试工具呀。不是说 jmeter 不能用来做接口测试,但是它的局限性明显了。这就好比汤匙明明是用来喝汤的,但是你就是要用来吃面,还美其名曰:可以同时搞定面和汤,不好吗?反正笔者是没想明白。文章源自玩技e族-https://www.playezu.com/442231.html
01作为一个当下普及性相当广的测试工具,jmeter 有它自身的优势,总结下大约有以下几点:
易用性:jmeter 上手简单,大部分操作都有对应的元件帮你完成,并且是开源的,社区接受度高。有多少用 jmeter 的人逛过 jmeter 社区?文章源自玩技e族-https://www.playezu.com/442231.html
灵活性:jmeter 提供了 beanshell 能力,可以让使用者更好地编写个性化的,满足不同场景需求;同时提供了比较高级的扩展能力,允许自己定义和扩展新的协议支持,比如扩展支持阿里提供的 dubbo 协议的 jmeter 插件等文章源自玩技e族-https://www.playezu.com/442231.html
支持多种协议:除了支持常见的 http 协议之外,还可以直接通过 jdbc sampler 连接数据库,把期望的测试结果存入数据库中,直接对测试结果进行验证。在编写测试过程中,可以将不同的协议调用使用同一个进行组合调用,写出比较复杂的测试用例。文章源自玩技e族-https://www.playezu.com/442231.html
接口性能复用:这个是笔者最无法接受,但是被使用最广的理由。“写好接口测试后,加下并发数,就能测试性能了”,很多人如是说。如果性能是这么容易搞定的,那我们分析业务模型、数据模型又是为了什么?撑的?文章源自玩技e族-https://www.playezu.com/442231.html
02jmeter 工具应用在性能场景上,它是款优秀的工具,但是如果用于接口测试,它是存在很多无法解决的缺点。这些缺点也是笔者认为它不是一个优秀的接口测试工具。
团队协作:在性能的场景下,开发可以按场景划分成不同的 jmx 文件,并由多人分别负责。写完基本上是不会变的。而接口测试不同,由于接口测试涉及的范围更广,变更更加频繁,如果团队有 2 个以上的人员进行接口开发,如何分工协作是第一个问题。文章源自玩技e族-https://www.playezu.com/442231.html
已知的皇冠盘网址的解决方案是:根据业务模块来划分,不同的人维护各自的。但是 jmeter 又不支持一次运行多个 jmx 文件,需要额外的代码来处理(放到 shell 脚本中是一个常见的方案)。文章源自玩技e族-https://www.playezu.com/442231.html
脚本复用:由于 jmx 文件是相互独立,相互之间无法引用的。那个公用模块就无法解耦,比如登录,所有的脚本都需要写一次(至少是复制一次),如果有变动,所有的脚本都需要手动变更,维护成本巨高。文章源自玩技e族-https://www.playezu.com/442231.html
已知的皇冠盘网址的解决方案是把所有的场景放到一个 jmx 文件中去维护。那脚本的原子性就无从谈起。笔者见过一个 jmx 文件中,超过 100 个 http sampler 的。文章源自玩技e族-https://www.playezu.com/442231.html
问题定位:在日常 jmeter 运行中,都会以非 ui 的方式进行,这种情况下是没有 results tree 给你查看返信息的。如何知道失败的原因是什么?只能以 ui 的形式再跑一次,但由于接口的幂等性或环境原因,往往无法复现,比较尴尬。虽然 jmeter 也提供了 html 的报告,但毕竟人家本来就是个性能工具,报告的内容多偏向与性能相关。文章源自玩技e族-https://www.playezu.com/442231.html
现在有很多基于 jmeter 的接口自动化框架是结合了 jenkins git jmeter ant 或者 allure 来完成的,本质上还是没有解决上面的几个问题。文章源自玩技e族-https://www.playezu.com/442231.html
03理清楚优缺点后,再回头看看为什么要选 jmeter 来作为接口测试。随着接口测试价值被越来越多的人接受,其对应的测试工具也越来越多,包含但不仅限于 apipost、doclever、itest、metersphere 等商用的,还有 pytest、junit、httprunner 等开源框架,完全可以取代 jmeter 的缺点,同时包含 jmeter 的优点。
进一步想想,也许是 jmeter 声名在外,很多测试的同学能接触或者了解到的工具只有 jmeter,也不想花额外的成本去学习。就直接用了。从个人的角度上看,没有问题,也能快速解决团队的需求,低成本开展接口自动化测试,完成团队 kpi。但是从团队的角度上看,以 jmeter 为基础开展接口测试,存在很大的局限性。需要进行大量的二次封装,才能解决它自身的缺点(这也是为什么很接口测试工具底层也是选择 jmeter 的原因,利用它的优势,通过 web 封装来屏蔽它的缺点)。文章源自玩技e族-https://www.playezu.com/442231.html
所以,如果你想把接口测试真正在团队中落地,慎用 jmeter。文章源自玩技e族-https://www.playezu.com/442231.html
至于选择其他工具或者架构的学习成本问题,从个人的角度上来,其实是有益的。代码能力是现在测试工程师必备的技能了,通过学习接口测试框架,可以有效地有效地锻炼自己的代码能力,比起其他的学习方式,它更能落地,也能更好地补充代码知识、解决实际问题。远比你写一套不实用的 web 工程来的有用。文章源自玩技e族-https://www.playezu.com/442231.html
这里还隐藏了一个问题没有展开的,就是关于接口测试用例的要求(在确定的前两点中有提到),这个问题在另一篇文章中有详细的讨论,可移步阅读:你写的接口脚本合理么。文章源自玩技e族-https://www.playezu.com/442231.html
关于你为什么选 jmeter 来做接口测试,还有什么其他的理由,欢迎留言讨论,期待你的答案。文章源自玩技e族-https://www.playezu.com/442231.html
原文链接:https://mp.weixin.qq.com/s/xzz2kggh2tghx12lvy-tyq文章源自玩技e族-https://www.playezu.com/442231.html
免责声明:本文内容来自用户上传并发布或网络新闻客户端自媒体,玩技博客仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,请联系删除。
22f
单兵神器
我选择 jmeter 是因为上手快,简单。
我代码能力弱,所以首先考虑这种工具,,,
21f
总结得不错,但工具是工具,怎么使用还是靠人