在性能测试中经常提到并发，但是实际上很少会有同时很多请求的，如果一下子就来很多的请求，服务器很快就会被压垮。都是在逐渐增加，然后达到一个预期值，再持续运行一段时间，其实阿里云的PTS配置压测策略也有这种的。
在jmeter中有插件可以帮助我们实现这种场景。（推荐使用新版的bzm - Concurrency Thread Group）
1.Stepping Thread Group
通过插件管理器下载插件Custom Thread Groups即可，点击了Apply后就等待安装，安装后jmeter会自动重启的。
This group will start N threads：设置线程组启动的线程总数为N个；First,wait for N seconds：启动第一个线程之前，需要等待N秒；Then start N threads：设置最开始时启动N个线程；ZNext,add X threads every Y seconds,using ramXp-up Z seconds：每隔Y秒，启动X个线程，在Z秒内启动X个线程；Then hold load for N seconds：启动的线程总数达到最大值之后，再持续运行N秒；Finally,stop X threads every Y seconds：每Y秒停止X个线程；
2.Concurrency Thread Group
测试计划右键添加线程组->bzm - Concurrency Thread Group
Target Concurrency: 预期客户端最大并发线程数为100Ramp Up Time(min): 在1min内启动100个线程Ramp-up Steps Count: 在上述时间内，分5次启动Hold Target Rate Time (min): 达到目标并发线程数100后，再并发运行30秒Thread Iterations Limit：线程迭代次数限制，即循环次数（空，即为一次）（无特殊情况，建议不设置该选项的值）Log Threads Status into File：将线程状态记录到文件中
3.Ultimate Thread Group
测试计划右键添加->线程组->jp@gc - Ultimate Thread Group
Start Threads Count：当前行启动的线程总数Initial Delay/sec：延时启动当前行的线程，单位:秒Startup Time/sec：启动当前行所有线程达峰值所需时间，单位:秒Hold Load For/sec：当前行线程达到峰值后的稳定加载时间，单位:秒Shutdown Time：停止当前行所有线程所需时间，单位:秒
上图含义：
第一个线程：没有延时，在30秒内启动100个线程数，到达100个后稳定运行60秒后，在再10秒内结束100个线程数。第二、第三行同理。
[mark]需要注意的是如果设置多行其实运行时是一起运行的，并不是第一行设置的结束了再进行第二行，点击开始后，立马启动第一行设置的线程，启动2秒后，第二行和第三行的线程开始启动（此时第一行设置的线程数也是在启动中，同步进行的）[/mark]
三.查看结果
以上阶梯式压测可以添加 jp@gc - Active Threads Over Time 察看具体请求结果图（需要安装插件3 Basic graphs）
总体来讲：普通的压测，线程产生的方式是固定的，通过计算得出每秒产生X个线程（在线程中配置的，线程数10,5秒，循环2次；这样计算出来就是每0.5s产生一个线程，共计循环2次），每个线程从请求发出，到服务端处理再返回接收，这样一个线程的完整生命周期就结束了，后面就没他啥事了。而阶梯式压测能保证活跃的线程数在一个数值，当一个线程结束时为了保持活跃度，jmeter会立马再产生一个新的线程来运行，维护活跃的线程数，具体的线程产生间隔时间是根据实际运行状态来决定的，旧的线程结束的快，新的产生就产生得快，因此间隔时间没有固定值（而普通的压测间隔时间就是固定的值）。阶梯式压测可以控制的是在一段时间内的线程数，所以可能相同配置每次阶梯式压测，总的线程数都是不一样的，测出来的结果也是不同的。
