业务场景决定你的脚本加载策略。先确定需求再来决定怎么设计脚本，抛开业务空谈是没有任何意义的

jmeter 插件里有很多针对线程组的插件，都可以了解下，根据情况选择即可，基本可以满足各种用户加载策略.

我在我自己公司，是一直使用的（jp@gc - Stepping Thread Group (deprecated) 插件）设置一些，用户数，每秒新增多少，持续运行多久，达到目标线程数，就每多少秒，结束多少线程，通过这个插件来查看性能的各项指标，我性能方面也不是很会

1、并不是，主要看需求。压测并发量决定于服务器是否能达到 CPU70% 或者更高的使用率。
2、持续时间这个没要求，你可以一直压，也可以压个 10 分钟或者更久。
3、递增并发请求数这个，个人经验来说没法准确的判断每次递增后并发数是不是一样。大概一样就好了。

不管你在发请求上玩什么花，目的无非就是一个，找到性能的临界点,并尝试在不同的场景上找临界点
所以还是回到本质，你要清楚你发请求的场景，模拟多种场景去设计发压用户数，发压的策略.
你怎么做其实都不影响，只是的符合你的场景设定而不是与实际业务不符，那测试就没有意义

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

我想追问一下，【所以说我们在接口压测时，肯定是要采用递增并发时的策略来获取系统最大的 tps】这里说的递增并发指的是 jmeter 中的【Number of Threads(users)】还是【Number of Threads(users)】乘循环次数或持续长时间的请求 (samples)