首先要明白一个误区，并发用户数和 jmeter 的线程数，它们是不对等的。并发用户数应该和 tps 是一个概念，假如需求是想获取 1000 个用户同时操作时，系统能否承受得住或者系统各项指标反应如何，我们应该拿 tps 来给出答案。jmeter 的线程数大小仅仅是一个压力的大小概念。
所以说我们在接口压测时，肯定是要采用递增并发时的策略来获取系统最大的 tps。至于递增间隔需要参考基准测试时，接口的响应时间。如果响应时间很小，那你增加步数就小一点，如果响应时间大，步数就需要大一点。

除了楼上的办法，当数据量很大时可以把数据写入 redis，通过插件获取参数化数据

是呀，也不知道天天干嘛呢？

Sampler 里填的截图出来看看。只让看现象，无法看到原因

我认为第一次实验结论第三点完全没有必要。并发线程数只是压力工具用来施压的一个策略，不能用来衡量系统支持的并发能力。tps 才是可以真正可以反应系统支持的并发能力。还有就是群主不要把 rps 以及 tps 做为两个概念，其实他们按理说是一致的没有区别，都是反应服务器在一段时间可以处理的多少事物。并且你分析的拐点我也不太认可，你第一次 10 秒内 rps 增加到 100，tps 也是在 10s 增加到了 100，但第二次是在 20 秒内直接增加到了 400，但是你看 20 秒的 tps 确实在连 300 都不到。这个时候性能已经开始衰减了吧。

数据库连接会不会没有断开呢？导致一直 20 20 的递增

高大上，通篇读下来，就觉得牛逼。然后就没有然后了

哦哦，明白了。谢谢解惑了

为什么 3600×20% 之后还要×8 呢？

你这直接写个脚本，调用你们的业务接口造数据不可以吗？要不要自动化框架无所谓吧。

可以更改默认的 python 的版本吧

东西很好

python 有 testng 模块？

好的，谢谢🙏

报一堆错

好的

支持 mindjet mindmanager 吗？

我感觉看公司吧，一般都是整理一些主要或核心功能的用例，主要是因为项目时间紧，不是每个开发都是很负责的，而且你给开发搞一个故事场景的测试，他肯定得疯了。当然了冒烟测试写的越详细，覆盖面越广，交到测试手上的项目质量也就越高，测试就不用被一些重复的低级问题搞得想骂娘，从而有更多时间去发现一些隐藏较深的缺陷和保证产品质量。个人见解，希望可以帮到你。

好的，

谢谢啦。

谢谢了，按照你的思路实现了。

嗯，谢谢啦。我感觉思路还是挺好的，等中午有时间了试试。最近业务有点忙。

不过，还是谢谢你了。

额，我用 xpath 可以对某一个特定的产品定位，但是我想实现的是我从入口随意输入一个产品，检查这个页面，没有就报错，有的话，定位到，并去点击立即加入按钮。

@Sorin 大神帮帮忙