最近在 AI 的指导下根据实际项目使用 Jmeter，以前网上跟学总是难以实践要么示例太简单、要么给的接口无法调用，在构造请求时，也踩了不少坑；不过在构造接口阶段顺利做了接口测试，后期可以直接性能压测还是挺方便的。
想问问大家的工作中现在还用这个工具吗？主要场景包含哪些呢，负载测试的量有多大呢？
jmeter 也是我毕业前两年接触到的第二个压测工具，当时跑在 windows 上，有 UI 界面，只要理解几个关键的参数就能直接开始用，后面单机压力不够看了，还能换成命令行使用搞成多机。整体很适合作为性能测试接触的第一个 GUI 工作。
但是随着业务场景越来越复杂，jmeter 这些老派工具就跟不上了，一方面是 java 本身的性能极限不够高（线程模型、堆大小上限等编程语言方面的约束引入的天花板）；另一方面从命令行工具角度评价，市面上其他工具用起来感觉都很像，无非就是参数设置稍有差异；
进阶的接口性能测试，就不再是拿二进制工具单接口发压这么简单，开始关注多接口关联的场景性压测，此时可能演变为写代码调用库来更灵活地发压；
接口性能测试在大公司的终极形态，必然是平台化，此时你就脱离性能测试工具本身，不会再关注你用的是 jmeter 还是 gatling 还是 wrk 还是啥，平台会帮你解决压测机器调度、多机发压等问题，你只要告诉压测平台你要压多少 qps，压多长时间，qps 变化策略和一些动态构造的数据就行，还会额外出现压测环境、压测集群等跟公司研发体系配套的问题，人就会聚焦在 “性能测试方案” 上，返璞归真。
用啊，根据实际需求来的。压测量大，就上服务器。中小公司，jmeter 搭配点脚本啥的够用了。主要是怎么模拟真实性能场景，数据也很重要
王稀饭
回复
谢谢大佬分享，其实在近期使用过程中就发现 Jmeter 的局限性，例如 json 提取器在多并发时存储的数值有误，最终只能使用 JSR 脚本进行存值。想请教下大佬过往的经验中，遇到的问题如何判断是工具本身局限性还是自己操作错误呢？因为我们测试人员只有我一个，只能一个人摸索，自己也会有很多操作错误，但真遇到工具本身局限性时因为自己难以判断，需要花费很久的时间来定位
Sss
回复
【如何判断是工具本身局限性还是自己操作错误】这个经验为主吧，但一般工具清楚说明了它支持 xx 功能，然后你怎么用都无效基本就是自己的使用不当问题。
如果工具没说明，你使用有问题，以前是上外网搜搜看看其他人或者老外有没有解法，现在就直接问 AI 好了。AI 在信息搜索上是无敌的。
jmeter 使用其实就是一个熟练度问题，本质上就是接口请求 + 各种逻辑。熟练了之后其实还是很好用的，并发量少的情况下，直接本地电脑上调试完就能跑，再结合一些参数化，工作中很多问题的都能解决。比如：造数据、单接口压测，业务场景压测，中间件压测。目前工作十年，性能测试这块没有它解决不了的，当然我是 toB 行业，用户并发量没有互联网行业那么大，90% 的性能场景都能解决。
工具我觉着在压测体系里面反而是最不值得关注的