普通场景介绍
1.线程数：并发用户数
2.Ramp-Up时间：启动时间（线程数的准备时间），在这个时间点结束时，所有用户都已运行起来
3.循环次数：每个线程数都要运行的次数。✔永远 和 调度器一起使用，在调度器时间内，所有线程数都一直运行
****************************************************************************************************
安装插件
把从官网下载jmeter-plugins-manager-1.6.jar （1.6是版本号）插件放在binext文件夹下，重启jmeter，可以在菜单栏的选项 -> plugins manager，点击，进入如下页面。
Installed Plugins是已安装了的插件，Available Plugins是可安装的，Upgrades是已安装但可升级的插件，选择插件，点击右下角的按钮进行安装或更新。
在Available Plugins搜索 " jpgc - Standard Set"并安装，安装成功后，可以在右键->添加->线程（用户） 如下图，多了几个选项
负载测试的两种场景
一、jp@gc - Stepping Thread Group (deprecated) 线程组模拟线程数逐步递增场景
1. This group will start 100 threads：共100个线程
2. First, wait for 0 seconds; Then start 0 threads: 0秒启动0个线程
3.Next， add 10 threads every 30 second, using ramp-up 5 second : 每30秒增加一次线程，即5秒内启动10个线程，并运行30秒
4.Then hold load for 60 seconds：100个线程都启动后运行60秒
5.Finally， stop 5 threads every 1 seconds：每秒停5个线程，100个需要20秒
在这个负载线程组里，除了添加HTTP请求，还有搭配的监听器有
jp@gc - Active Threads Over Time 线程启动状态
jp@gc - Response Time Over Time 响应时间
jp@pc - Transaction per Second 每秒处理事务数
模拟访问某网站的用户递增场景，线程设置保留默认，即前面介绍的，运行后结果如下：
1.如下图，活跃线程趋势，10个线程5秒内启动，然后运行30秒，循环9次，第10次的10个线程启动后，当前即有100个线程，同时运行60秒，然后每秒下线5个线程。
2.如下图，横坐标为运行时间线，纵坐标为响应时间。下图的响应时间不太好看，区间间隔太大，贴近0秒，但突然跳到6秒，对比Active thread （上图）的线程数，在10个用户都启动完并运行30秒的时间内，响应时间突然达到6秒，虽然很快又降下来了，从图的趋势看，该网站在10个用户就有点不稳定了。其实根本原因应该是我网络不稳定的原因导致的，做性能测试不能用WiFi，要连无线，还要跟系统保持在同一网络上，否则数据是很不准的。
行业标准响应时间：0.5秒为最优，1.5秒为可接受，超过2秒性能就很差了。
3.每秒处理事务数，如下图，可以看出有请求是失败的（绿线）。结合响应时间趋势，可以看出响应时间高的时候，处理事务数低，时间低的时候，处理事务数高。能力有限，暂时还看不出其他什么信息
总结：从响应时间趋势图中找到响应时间是1.5秒的运行时间大概在什么时候，找到这个运行时间，对比Active Thread趋势中这个运行时间的线程数是多少，从而得出多少个用户同时使用的性能最佳
行业标准响应时间：0.5秒为最优，1.5秒为可接受，超过2秒性能就很差了。
二、jp@gc - Ultimate Thread Group 模拟阶段性线程递增场景
如下图,，Thread schedule里，一行代表一个阶段，Start Threads Count为启动线程数，Initial Delay为启动时间，Startup time是这个时间内这个阶段的线程数要启动完，Hold load for为线程启动完后持续运行时间，shutdown time是把该阶段所有线程下线。第二阶段的启动时间要晚于等于第一阶段全部结束，以此类推。
运行趋势分析同上面的逐步递增一样分析。
