JMeter是一个流行的用于负载测试的开源工具，具有许多有用的功能元件，如线程组（threadgroup），定时器（timer），和HTTP取样(sampler)元件。本文是对JMeter用户手册的补充，而且提供了关于使用Jmeter的一些模拟元件开发质量测试脚本的指导。
本文同时也讨论了一项重要的内容：在指定了精确的响应时间要求后，如何来校验测试结果，笔者是在采用了置信区间分析这种严格的统计方式的情况下应如何操作。请注重，我假定本文的读者们了解关于Jmeter的基础知识。
确定一个线程组的ramp-upperiod（Determine）
Jmeter脚本的第一个要素是线程组（ThreadGroup），因此首先让我们往返顾一下。正如图一所示，线程组需要设置以下参数：
a·线程数量。
b·ramp-upperiod。
c·运行测试的次数。
d·启动时间:立即或者预定的时间，假如是后者，线程组所包含的元素也要指定这个起止时间。
球球裙：1017539290
图1：JMeter线程组（JMeterThreadGroup）
每个线程均独立运行测试计划。因此，线程组常用来模拟并发用户访问。假如客户机没有足够的能力来模拟较重的负载，可以使用Jmeter的分布式测试功能来通过一个Jmeter控制台来远程控制多个Jmeter引擎完成测试。
参数ramp-upperiod用于告知JMeter要在多长时间内建立全部的线程。默认值是0。假如未指定ramp-upperiod，也是说ramp-upperiod为零，JMeter将立即建立所有线程，假设ramp-upperiod设置成T秒，全部线程数设置成N个，JMeter将每隔T/N秒建立一个线程。
线程组的大部分参数是不言自明的，只有ramp-upperiod有些难以理解，因为如何设置适当的值并不轻易。首先，假如要使用大量线程的话，ramp-upperiod一般不要设置成零。因为假如设置成零，Jmeter将会在测试的开始建立全部线程并立即发送访问请求，这样一来很轻易使服务器饱和，更重要的是会隐性地增加了负载，这意味着服务器将可能过载，不是因为平均访问率高而是因为所有线程的第一次并发访问而引起的不正常的初始访问峰值，可以通过Jmeter的聚合报告监听器看到这种现象。
这种异常不是我们需要的，因此，确定一个合理的ramp-upperiod的规则是让初始点击率接近平均点击率。当然，也许需要运行一些测试来确定合理访问量。
基于同样的原因，过大的ramp-upperiod也是不恰当的，因为将会降低访问峰值的负载，换句话说，在一些线程还未启动时，初期启动的部分线程可能已经结束了。
那么，如何检验ramp-upperiodI太小了或者太大了呢？首先，推测一下平均点击率并用总线程除点击率来计算初始的ramp-upperiod。例如，假设线程数为100，估计的点击率为每秒10次，那么估计的理想ramp-upperiod是100/10=10秒。那么，应怎样来提出一个合理的估算点击率呢？没有什么好办法，必须通过运行一次测试脚本来获得。
其次，在测试计划（testplan）中增加一个聚合报告监听器，如图2所示，其中包含了所有独立的访问请求（一个samplers）的平均点击率。第一次取样的点击率（如http请求）与ramp-upperiod和线程数量密切相关。通过调整ramp-upperiod可以使首次取样的奠基率接近平均取样的点击率。
球球裙：6428306858
图2：JMeter聚合报告
第三，查验一下Jmeter日志(文件位置：JMeter_Home_Directory/bin)的后一个线程开始时第一个线程是否真正结束了，二者的时间差是否正常。
总之，是否能确定一个适当的ramp-uptime取决于以下两条规则:
·第一个取样器的点击率（hitrate）是否接近其他取样器的平均值，从而能否避免ramp-upperiod过小。
·在后一个线程启动时，第一个线程是否在真正结束了，好二者的时间要尽可能的长，以避免ramp-upperiod过大。
有时，这两条规则的结论会互相冲突。这意味着无法找到同时满足两条规则的合适的ramp-upperiod。糟糕的测试计划通常会导致这些问题，这是因为在这样的测试计划里，取样器将不能充分地采集数据，可能因为测试计划执行时间太短并且线程会很快的运行结束。
用户思考时间（Userthinktime），定时器，和代理服务器（PRoxyserver）
在负载测试中需要考虑的的一个重要要素是思考时间（thinktime），也是在两次成功的访问请求之间的暂停时间。有多种情形挥发导致延迟的发生：用户需要时间阅读文字内容，或者填表，或者查找正确的链接等。未认真考虑思考时间经常会导致测试结果的失真。例如，估计数值不恰当，也是被测系统可以支持的多用户量（并发用户）看起来似乎要少一些等。
当我们进入正在的负载测试后，如果发现事务控制器的时间比所有子组件的时间之和差距过大，那么说明Jmeter本身的性能出问题了。可以考虑通过如下三种方式进行处理：
一、修改Jmeter.bat文件，调整JVM参数，将heap和permsize值适当的设置大一点。
二、联机负载，减少单台机器上的负载线程数。
三、采用命令模式运行测试。
Jmeter提供了一整套的计时器（timer）来模拟思考时间（thinktime），但是仍然存在一个问题：:如何确定适当的思考时间呢？幸运的是，JMeter提供了一个不错的答案：使用JMeterHTTP代理服务器（ProxyServer）元件。
代理服务器会记录在使用一个普通的浏览器（如Firefox或InternetEXPlorer）浏览一个web应用时的操作。另外，JMeter在记录操作的同时会建立一个测试计划（testplan）。这个功能能提供以下便利：
不必手工建立HTTP访问请求，尤其是当要设置一些令人乏味的参数时（然而，非英文的参数也许不能正常工作)。JMeter将会录制包括隐含字段（hiddenfields）在内的所有内容。
在生成的测试计划中，Jmeter会包含浏览器生成的所有的HTTP报头，如User-Agent(e。g。，Mozilla/4。0)，或AcceptLanguage(e。g。，zh-tw，en-us;q=0。7，zh-cn;q=0。3)等。
JMeter会根据设置在录制操作的同时建立一些定时器，其延迟时间是完全根据真实的操作来设置的
现在让我们来看一下如何配置Jmeter的录制功能。在JMeter的控制台上，在工作台（WorkBench）元件上单击右键，然后选择”addtheHTTPProxyServer“。注重是在WorkBench上单击右键而不是在TestPlan上，因为现在是要为记录操作进行配置而不是要运行测试计划。HTTPProxyServer的实现原理是通过配置浏览器的代理服务器而使所有的访问请求通过JMeter发送（，因而被Jmeter把访问过程录制下来）。
HTTP代理服务器（HTTPProxyServer）元件的一些参数必须被配置:
端口(port):代理服务器的监听端口
目标控制器（TargetController）:是代理用于存储生成的数据的控制器，默认情况下，JMeter将会在当前的测试计划中找一个记录用的控制器用于存储，此外也可以在下拉菜单中选择任意控制起来存储，通常默认值可以了。
分组(Grouping):确定在测试计划中如何来为生成的元件分组。有多个选项，一般可以选择“只存储每个组的第一个样本”，否则，将会原样录制URLs，包括包含图像和javascripts脚本的页面。当然也可以尝试一下默认值“不对样本分组”（“Donotgroupsamples”），来看一下JMeter建立的原版的测试计划。
包含模式(PatternstoInclude)和排除模式(PatternstoExclude):帮助过滤一些不需要的访问请求。
写在最后：
没有一个寒冬不会过去，没有一个春天不会到来，过去的2020年对于全世界人民来说是不平凡的一年，每个人都在坚强勇敢的和疫情抗战，在这里我们一起为自己鼓个掌吧，2021年已经如约而至，制定好目标继续向上生长吧。
在这里推荐一个我自己创建的软件测试交流群，qq:642830685,群中群中会不定期的分享软件测试资源，测试面试题以及行业资讯，大家可以在群中积极交流技术。
愿你我相遇，皆有所获！ 欢迎关注微信公众号：程序媛一菲，下面这些硬核资源就是你的了。
