【性能测试实战】

阶梯加压

负载测试概念：不断增加并发用户数，向服务器发起请求。得到系统最大的负载量
（持续不断加压，看服务器什么时候不能达到我的预期，或者崩溃）

插件下载 Stepping Thread Group

1、下载jmeter-plugins-manager-1.8.jar包放在lib\ext\目录下

2、启动jmeter->在JMeter Plugins Manager窗口->搜索 jpgc -Standard Set插件->勾选并下载

installed plugins：已经下载的插件
available plugins:可下载的插件
upgrades:可以更新的插件

3、下载成功会，重新启动jmeter

插件下载后，jmeter就引入了：

引入了多个线程组—用于设计场景设计的
引入了多个监听器：用于性能测试结果，从不同的维度展示
引入了多个函数

阶梯加压线程组

1、jp@gc - Stepping Thread Group

this group will start：表示总共要启动的线程数；若设置为 100，表示总共会加载到 100 个线程
first，wait for：从运行之后多长时间开始启动线程；若设置为 0 秒，表示运行之后立即启动线程
then start：初次启动多少个线程；若设置为 0 个，表示初次不启动线程
next add：之后每次启动多少个线程；若设置为 10个，表示每个梯次启动 10 个线程
threads every：当前运行多长时间后再次启动线程，即每一次线程启动完成之后的持续时间；若设置为 30 秒，每梯次启动完线程之后再运行 30 秒
using ramp-up：启动线程的时间；若设置为 5 秒，表示每次启动线程都持续 5 秒（和基础线程组的ramp-up一样意思）
then hold load for：线程全部启动完之后持续运行多长时间，如图：设置为 60 秒，表示 100 个线程全部启动完之后再持续运行 60 秒
finally，stop/threads every：多长时间释放多少个线程；若设置为 5 个和 1 秒，表示持续负载结束之后每 1 秒钟释放 5 个线程
只要线程启动了，就会不停的取执行取样器的请求。

2、结合Active Threads Over Time 随着时间变化的并发用户数

运行Stepping Thread Group需要和Active Threads Over Time结合起来使用，这样能看到动态的阶梯加压效果
可以看到和Stepping Thread Group负载预览图基本一致，证明加压效果是正常的。

3、结合jp@gc - Response Times Over Time 随着时间变化的响应时间

性能测试场景，遵守一个准则：缓起步，快结束

快结束，不是瞬间结束，结束的速度太快会导致，不能中断的请求，被强制中断，这个是会出现错误，是人为场景设计问题，不是服务器的问题
缓 不能太慢。

需要注意

在做完一次性能测试后，需要停顿一段时间，再开始进行下次测试。

停顿多长时间：需要看服务器资源的恢复情况而定，恢复的基本不变。

为什么要停顿：因为每次做性能测试，都可能会对服务器造成性能压力，有可能导致服务器资源使用率高，就需要一些时间使服务器恢复正常。如果还没有恢复正常，就开始下一次测试，后面的性能测试指标会受影响。

负载测试如何找到最大并发用户数

在性能测试中，当我们接到项目任务时，很多时候我们是不知道待测接口能支持多少并发用户数的。此时，需要我们先做负载测试，通过逐步加压，来找到最大并发用户数。那么当我们找到一个区间，怎么找到具体的值呢？

在区间中逐步增加步长，出现以下任意现象时，即是最大并发用户数：

出现连续报错

平均响应时间超过1.5秒（1.5秒是行业标准）

tps出现下降趋势

负载测试概念
逐步增加并发用户数，找出被测系统的最大可接受的并发用户数，并考察系统性能的变化。

脚本总体设计：

场景介绍：

1、首先用插件管理器下载插件jpgc-StandardSet，然后重启jmeter

2、添加线程组jp@gc-SteppingThreadGroup

3、在线程组下添加请求取样器和其他配置元件，并填写接口参数，本文的被测接口为注册接口

4、添加监听器：

<span style="background-color:#f8f8f8"><span style="color:#333333">jp@gc-ActiveThreadsOverTime（活跃线程数随时间变化图）
jp@gc-ResponseTimesOverTime（响应时间随时间变化图）
jp@gc-TransactionsperSecond（tps随时间变化图）</span></span>

5、jp@gc-SteppingThreadGroup填写数据，场景为在5秒内增加10个并发用户数，并运行30秒，再继续在5秒内增加10个并发用户数，重复循环，直至并发用户数达到50个后运行脚本60秒。然后在每1秒内减少5个并发用户数，直到减为0，结束脚本的运行。

6、第一次运行脚本，结束后观察数据：

由图形得知：

当并发用户数为20时，平均响应时间超过1.5秒

tps全程没有出现明显的下降趋势，也没有出现连续的报错

第一次运行脚本分析：因此得出结论，系统的最大并发用户数为10~20区间

我们已经得出系统的最大并发用户数为10~20区间，那么具体是多少呢？接下来要减少步长,并进行第二次的测试