JMeter技巧集锦[组图]



  JMeter 是一个流行的用于负载测试的开源工具, 具有许多有用的功能元件,如线程组(thread group), 定时器(timer), 和HTTP 取样 (sampler) 元件。 本文是对JMeter 用户手册的补充,而且提供了关于使用Jmeter的一些模拟元件开发质量测试脚本的指导。
  
  本文同时也讨论了一项重要的内容:在指定了精确的响应时间要求后,如何来校验测试结果,非凡是在采用了置信区间分析这种严格的统计方式的情况下应如何操作。请注重,我假定本文的读者们了解关于Jmeter的基础知识,本文的例子基于Jmeter2。0。3版。 
  
    确定一个线程组的ramp-up period (Determine)
  

  Jmeter脚本的第一个要素是线程组(Thread Group),因此首先让我们往返顾一下。 正如图一所示,线程组需要设置以下参数: 
  ·线程数量。 
  ·ramp-up period。 
  ·运行测试的次数。 
  ·启动时间:立即或者预定的时间,假如是后者,线程组所包含的元素也要指定这个起止时间。
  
  

  
  图 1。 JMeter 线程组(JMeter Thread Group)
  
  每个线程均独立运行测试计划。因此, 线程组常用来模拟并发用户访问。假如客户机没有足够的能力来模拟较重的负载,可以使用Jmeter的分布式测试功能来通过一个Jmeter控制台来远程控制多个Jmeter引擎完成测试。 
  
  参数 ramp-up period 用于告知JMeter 要在多长时间内建立全部的线程。默认值是0。假如未指定ramp-up period ,也就是说ramp-up period 为零, JMeter 将立即建立所有线程,假设ramp-up period 设置成T 秒, 全部线程数设置成N个, JMeter 将每隔T/N秒建立一个线程。 
  
  线程组的大部分参数是不言自明的,只有ramp-up period有些难以理解, 因为如何设置适当的值并不轻易。 首先,假如要使用大量线程的话,ramp-up period 一般不要设置成零。 因为假如设置成零,Jmeter将会在测试的开始就建立全部线程并立即发送访问请求, 这样一来就很轻易使服务器饱和,更重要的是会隐性地增加了负载,这就意味着服务器将可能过载,不是因为平均访问率高而是因为所有线程的第一次并发访问而引起的不正常的初始访问峰值,可以通过Jmeter的聚合报告监听器看到这种现象。 
  这种异常不是我们需要的,因此,确定一个合理的ramp-up period 的规则就是让初始点击率接近平均点击率。当然,也许需要运行一些测试来确定合理访问量。 
  
  基于同样的原因,过大的ramp-up period 也是不恰当的,因为将会降低访问峰值的负载,换句话说,在一些线程还未启动时,初期启动的部分线程可能已经结束了。 
  
  那么,如何检验ramp-up period I太小了或者太大了呢?首先,推测一下平均点击率并用总线程除点击率来计算初始的ramp-up period。 例如,假设线程数为100, 估计的点击率为每秒10次, 那么估计的理想ramp-up period 就是 100/10 = 10 秒。 那么,应怎样来提出一个合理的估算点击率呢?没有什么好办法,必须通过运行一次测试脚本来获得。
  
  其次, 在测试计划(test plan)中增加一个聚合报告监听器,如图2所示,其中包含了所有独立的访问请求(一个samplers)的平均点击率。 第一次取样的点击率(如http请求)与ramp-up period 和线程数量密切相关。通过调整ramp-up period 可以使首次取样的奠基率接近平均取样的点击率。 
  
  

点击查看大图


  图2 JMeter 聚合报告 
  
  第三, 查验一下Jmeter日志(文件位置:JMeter_Home_Directory/bin) 的最后一个线程开始时第一个线程是否真正结束了,二者的时间差是否正常。
  
  总之,是否能确定一个适当的ramp-up time 取决于以下两条规则: 
  ·第一个取样器的点击率(hit rate)是否接近其他取样器的平均值,从而能否避免ramp-up period 过小。
  ·在最后一个线程启动时,第一个线程是否在真正结束了,最好二者的时间要尽可能的长,以避免ramp-up period过大。
  
  有时,这两条规则的结论会互相冲突。 这就意味着无法找到同时满足两条规则的合适的ramp-up period。 糟糕的测试计划通常会导致这些问题,这是因为在这样的测试计划里,取样器将不能充分地采集数据,可能因为测试计划执行时间太短并且线程会很快的运行结束。 
  
  
  
    用户思考时间(User think time),定时器,和代理服务器(proxy server)
  

  在负载测试中需要考虑的的一个重要要素是思考时间(think time), 也就是在两次成功的访问请求之间的暂停时间。 有多种情形挥发导致延迟的发生: 用户需要时间阅读文字内容,或者填表, 或者查找正确的链接等。未认真考虑思考时间经常会导致测试结果的失真。例如,估计数值不恰当,也就是被测系统可以支持的最多用户量(并发用户)看起来似乎要少一些等。 
  
  Jmeter提供了一整套的计时器(timer)来模拟思考时间(think time), 但是仍然存在一个问题:: 如何确定适当的思考时间呢?幸运的是, JMeter 提供了一个不错的答案:使用 JMeter HTTP 代理服务器(Proxy Server)元件。 
  
  代理服务器会记录在使用一个普通的浏览器(如Firefox 或 Internet EXPlorer)浏览一个web应用时的操作。 另外, JMeter 在记录操作的同时会建立一个测试计划(test plan)。 这个功能能提供以下便利: 
  
  ·不必手工建立HTTP 访问请求, 尤其是当要设置一些令人乏味的参数时(然而,非英文的参数也许不能正常工作) 。JMeter 将会录制包括隐含字段(hidden fields)在内的所有内容。 
  
  ·在生成的测试计划中,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)元件上单击右键,然后选择”add the HTTP Proxy Server “。 注重是在WorkBench 上单击右键而不是在Test Plan上, 因为现在是要为记录操作进行配置而不是要运行测试计划。  HTTP Proxy Server 的实现原理就是通过配置浏览器的代理服务器而使所有的访问请求通过JMeter发送(,因而被Jmeter把访问过程录制下来)。 
  
  如图3所示, HTTP代理服务器(HTTP Proxy Server)元件的一些参数必须被配置: 
  
  ·端口(port): 代理服务器的监听端口 
  
  ·目标控制器(Target Controller): 是代理用于存储生成的数据的控制器,默认情况下,, JMeter 将会在当前的测试计划中找一个记录用的控制器用于存储,此外也可以在下拉菜单中选择任意控制起来存储,通常默认值就可以了。 
  
  ·分组(Grouping): 确定在测试计划中如何来为生成的元件分组。 有多个选项, 一般可以选择“只存储每个组的第一个样本”,否则,将会原样录制URLs,包括包含图像和javascripts脚本的页面。当然 也可以尝试一下默认值“不对样本分组”("Do not group samples"),来看一下JMeter 建立的原版的测试计划。 
  
  ·包含模式(Patterns to Include) 和 排除模式(Patterns to Exclude) :帮助过滤一些不需要的访问请求。
  
  




  JMeter 是一个流行的用于负载测试的开源工具, 具有许多有用的功能元件,如线程组(thread group), 定时器(timer), 和HTTP 取样 (sampler) 元件。 本文是对JMeter 用户手册的补充,而且提供了关于使用Jmeter的一些模拟元件开发质量测试脚本的指导。
  
  本文同时也讨论了一项重要的内容:在指定了精确的响应时间要求后,如何来校验测试结果,非凡是在采用了置信区间分析这种严格的统计方式的情况下应如何操作。请注重,我假定本文的读者们了解关于Jmeter的基础知识,本文的例子基于Jmeter2。0。3版。 
  
    确定一个线程组的ramp-up period (Determine)
  

  Jmeter脚本的第一个要素是线程组(Thread Group),因此首先让我们往返顾一下。 正如图一所示,线程组需要设置以下参数: 
  ·线程数量。 
  ·ramp-up period。 
  ·运行测试的次数。 
  ·启动时间:立即或者预定的时间,假如是后者,线程组所包含的元素也要指定这个起止时间。
  
  

  
  图 1。 JMeter 线程组(JMeter Thread Group)
  
  每个线程均独立运行测试计划。因此, 线程组常用来模拟并发用户访问。假如客户机没有足够的能力来模拟较重的负载,可以使用Jmeter的分布式测试功能来通过一个Jmeter控制台来远程控制多个Jmeter引擎完成测试。 
  
  参数 ramp-up period 用于告知JMeter 要在多长时间内建立全部的线程。默认值是0。假如未指定ramp-up period ,也就是说ramp-up period 为零, JMeter 将立即建立所有线程,假设ramp-up period 设置成T 秒, 全部线程数设置成N个, JMeter 将每隔T/N秒建立一个线程。 
  
  线程组的大部分参数是不言自明的,只有ramp-up period有些难以理解, 因为如何设置适当的值并不轻易。 首先,假如要使用大量线程的话,ramp-up period 一般不要设置成零。 因为假如设置成零,Jmeter将会在测试的开始就建立全部线程并立即发送访问请求, 这样一来就很轻易使服务器饱和,更重要的是会隐性地增加了负载,这就意味着服务器将可能过载,不是因为平均访问率高而是因为所有线程的第一次并发访问而引起的不正常的初始访问峰值,可以通过Jmeter的聚合报告监听器看到这种现象。 
  这种异常不是我们需要的,因此,确定一个合理的ramp-up period 的规则就是让初始点击率接近平均点击率。当然,也许需要运行一些测试来确定合理访问量。 
  
  基于同样的原因,过大的ramp-up period 也是不恰当的,因为将会降低访问峰值的负载,换句话说,在一些线程还未启动时,初期启动的部分线程可能已经结束了。 
  
  那么,如何检验ramp-up period I太小了或者太大了呢?首先,推测一下平均点击率并用总线程除点击率来计算初始的ramp-up period。 例如,假设线程数为100, 估计的点击率为每秒10次, 那么估计的理想ramp-up period 就是 100/10 = 10 秒。 那么,应怎样来提出一个合理的估算点击率呢?没有什么好办法,必须通过运行一次测试脚本来获得。
  
  其次, 在测试计划(test plan)中增加一个聚合报告监听器,如图2所示,其中包含了所有独立的访问请求(一个samplers)的平均点击率。 第一次取样的点击率(如http请求)与ramp-up period 和线程数量密切相关。通过调整ramp-up period 可以使首次取样的奠基率接近平均取样的点击率。 
  
  

点击查看大图


  图2 JMeter 聚合报告 
  
  第三, 查验一下Jmeter日志(文件位置:JMeter_Home_Directory/bin) 的最后一个线程开始时第一个线程是否真正结束了,二者的时间差是否正常。
  
  总之,是否能确定一个适当的ramp-up time 取决于以下两条规则: 
  ·第一个取样器的点击率(hit rate)是否接近其他取样器的平均值,从而能否避免ramp-up period 过小。
  ·在最后一个线程启动时,第一个线程是否在真正结束了,最好二者的时间要尽可能的长,以避免ramp-up period过大。
  
  有时,这两条规则的结论会互相冲突。 这就意味着无法找到同时满足两条规则的合适的ramp-up period。 糟糕的测试计划通常会导致这些问题,这是因为在这样的测试计划里,取样器将不能充分地采集数据,可能因为测试计划执行时间太短并且线程会很快的运行结束。 
  
  
  
    用户思考时间(User think time),定时器,和代理服务器(proxy server)
  

  在负载测试中需要考虑的的一个重要要素是思考时间(think time), 也就是在两次成功的访问请求之间的暂停时间。 有多种情形挥发导致延迟的发生: 用户需要时间阅读文字内容,或者填表, 或者查找正确的链接等。未认真考虑思考时间经常会导致测试结果的失真。例如,估计数值不恰当,也就是被测系统可以支持的最多用户量(并发用户)看起来似乎要少一些等。 
  
  Jmeter提供了一整套的计时器(timer)来模拟思考时间(think time), 但是仍然存在一个问题:: 如何确定适当的思考时间呢?幸运的是, JMeter 提供了一个不错的答案:使用 JMeter HTTP 代理服务器(Proxy Server)元件。 
  
  代理服务器会记录在使用一个普通的浏览器(如Firefox 或 Internet EXPlorer)浏览一个web应用时的操作。 另外, JMeter 在记录操作的同时会建立一个测试计划(test plan)。 这个功能能提供以下便利: 
  
  ·不必手工建立HTTP 访问请求, 尤其是当要设置一些令人乏味的参数时(然而,非英文的参数也许不能正常工作) 。JMeter 将会录制包括隐含字段(hidden fields)在内的所有内容。 
  
  ·在生成的测试计划中,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)元件上单击右键,然后选择”add the HTTP Proxy Server “。 注重是在WorkBench 上单击右键而不是在Test Plan上, 因为现在是要为记录操作进行配置而不是要运行测试计划。  HTTP Proxy Server 的实现原理就是通过配置浏览器的代理服务器而使所有的访问请求通过JMeter发送(,因而被Jmeter把访问过程录制下来)。 
  
  如图3所示, HTTP代理服务器(HTTP Proxy Server)元件的一些参数必须被配置: 
  
  ·端口(port): 代理服务器的监听端口 
  
  ·目标控制器(Target Controller): 是代理用于存储生成的数据的控制器,默认情况下,, JMeter 将会在当前的测试计划中找一个记录用的控制器用于存储,此外也可以在下拉菜单中选择任意控制起来存储,通常默认值就可以了。 
  
  ·分组(Grouping): 确定在测试计划中如何来为生成的元件分组。 有多个选项, 一般可以选择“只存储每个组的第一个样本”,否则,将会原样录制URLs,包括包含图像和javascripts脚本的页面。当然 也可以尝试一下默认值“不对样本分组”("Do not group samples"),来看一下JMeter 建立的原版的测试计划。 
  
  ·包含模式(Patterns to Include) 和 排除模式(Patterns to Exclude) :帮助过滤一些不需要的访问请求。
  
  


从35个方面对Jmeter从原理到实际演示,一册在手,天下我有 1.性能测试基本概念 1.1.RT -Response time 请求响应时间 从客户端发出请求到得到响应的整个时间 一般包括网络响应时间+server的响应时间。 用户接受准则: 例如2-5-10原则,即按照正常用户体验,如果用户能够在2秒内得到响应,会感觉速度很快,如果2-5秒得到响应,用户感觉系统的响应速度还不多,在5-10秒之内得到响应时,用户会感觉系统的响应速度慢,但是可以接受,超过10秒后还没有响应,用户就会感觉不能够接受。 不同行业不同业务可接受的响应时间是不同的,一般情况,对于在线实时交易: 互联网企业:500毫秒以下,例如淘宝业务10毫秒左右。 金融企业:1秒以下为佳,部分复杂业务3秒以下。 保险企业:3秒以下为佳。 制造业:5秒以下为佳。 1.2.系统处理能力 系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。系统处理能力通过系统每秒钟能够处理的交易数量来评价,交易有两种理解: 一是业务人员角度的一笔业务过程; 二是系统角度的一次交易申请和响应过程。 前者称为业务交易过程,后者称为事务。两种交易指标都可以评价应用系统的处理能力。一般的建议与系统交易日志保持一致,以便于统计业务量或者交易量。系统处理能力指标是技术测试活动中重要指标。 1.1.1.简称 一般情况下,用以下几个指标来度量: HPS(Hits Per Second) :每秒点击次数,单位是次/秒。 TPS(Transaction per Second):系统每秒处理事务数,单位是笔/秒。吞吐量。 不可分割的。要么完全成功,要么完全失败。 QPS(Query per Second):系统每秒处理查询次数,单位是次/秒。 对于互联网业务中,如果某些业务有且仅有一个请求连接,那么TPS=QPS=HPS, 一般情况下用TPS来衡量整个业务流程,用QPS来衡量接口查询次数,用HPS来表示对服务器点击请求。 每秒钟处理完的事务次数,一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理,一个事务在分布式处理中,可能会对应多个请求,对于衡量单个接口服务的处理能力,用QPS比较多。 1.1.2.标准 无论TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标,越大越好,根据经验,一般情况下: 金融行业:1000TPS~9000TPS,不包括互联网化的活动 保险行业:100TPS~1000TPS,不包括互联网化的活动 制造行业:10TPS~50TPS 互联网电子商务:10000TPS~100000TPS,例如天猫5万TPS 互联网中型网站:100TPS~500TPS 互联网小型网站: 50TPS~100TPS 1.3.并发用户数量 常见的错误理解: 使用系统的全部用户数量(注册用户) 使用系统的全部在线用户数量 正确理解 并发用户数指在同一时刻内,打开系统并进行业务操作的用户数量,并发用户数对于长连接(数据库连接时长连接,web请求时短连接)系统来说最大并发用户数即是系统的并发接入能力。对于短连接系统而言最大并发用户数并不等于系统的并发接入能力,而是与系统架构、系统处理能力等各种情况相关 http:请求只能由客户端发出,服务端被动响应。 1.1.3. 简称 Virtual User: VU 1.1.4.标准 一般情况下,性能测试是将系统处理能力容量测出来,而不是测试并发用户数,除了服务器长连接可能影响并发用户数外,系统处理能力不完全受并发用户数影响,可以用最小的用户数将系统处理能力容量测试出来,也可以用更多的用户将系统处理能力容量测试出来。 并发用户数量: 并发用户多少为好? 中小企业:5000用户 1.4.错误率 1.1.5. 定义及解释 错误率指系统在负载情况下,失败交易的概率。错误率=(失败交易数/交易总数)*100%。稳定性较好的系统,其错误率应该由超时引起,即为超时率。 1.1.6.标准 不同系统对错误率的要求不同,但一般不超出千分之六,即成功率不低于99.4% 1.5.CPU 定义及解释 中央处理器是一块超大规模的集成电路,是一台计算机的运算核心(Core)和控制核心( Control Unit)。它的功能主要是解释计算机指令以及处理计算机软件中的数据。CPU Load: 系统正在干活的多少的度量,队列长度。系统平均负载。 CPU指标主要指的CPU利用率,包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。CPU 利用率要低于业界警戒值范围之内,即小于或者等于75%;CPU sys%小于或者等于30%, CPU wait%小于或者等于5%。单核CPU也需遵循上述指标要求。 7*24不允许宕机 1.6. Memory 内存是计算机中重要的部件之一,它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的,因此内存的性能对计算机的影响非常大。 现代的操作系统为了最大利用内存,在内存中存放了缓存,因此内存利用率100%并不代表内存有瓶颈,衡量系统内有有瓶颈主要靠SWAP(与虚拟内存交换)交换空间利用率,一般情况下,SWAP交换空间利用率要低于70%,太多的交换将会引起系统性能低下。 Swap解释: 当物理内存接近崩溃时,将物理内存中最近一段时间最少频率使用到的页框移出物理内存,放进该存储空间,这段存储空间我们称之为交换空间(Swap) 1.7.磁盘吞吐量 Disk Throughput. 磁盘吞吐量是指在无磁盘故障的情况下单位时间内通过磁盘的数据量。 磁盘指标主要有每秒读写多少兆,磁盘繁忙率,磁盘队列数,平均服务时间,平均等待时间,空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据,一般情况下,磁盘繁忙率要低于70%。 1.8.网络吞吐量 Network Throughput 10Mbit带宽,每秒传输的字节数1.25MBytes 网络吞吐量是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/s。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时,则需要考虑升级网络设备。 网络吞吐量指标主要有每秒有多少兆流量进出,一般情况下不能超过设备或链路最大传输能力的70%。 2.性能测试基本流程 性能测试需求: 1)最终用户体验,例如2-5-10原则,即按照正常用户体验,如果用户能够在2秒内得到响应,会感觉速度很快,如果2-5秒得到响应,用户感觉系统的响应速度还不多,在5-10秒之内得到响应时,用户会感觉系统的响应速度慢,但是可以接受,超过10秒后还没有响应,用户就会感觉不能够接受。 2)技术需求, cpu,内存,网络吞吐量,磁盘吞吐量 3)标准要求: 竞品分析- 响应时间 互联网企业:500毫秒以下,例如淘宝业务10毫秒左右。 金融企业:1秒以下为佳,部分复杂业务3秒以下。 保险企业:3秒以下为佳。 制造业:5秒以下为佳。 TPS 金融行业:1000TPS~9000TPS,不包括互联网化的活动 保险行业:100TPS~1000TPS,不包括互联网化的活动 制造行业:10TPS~50TPS 互联网电子商务:10000TPS~100000TPS,例如天猫5万TPS 互联网中型网站:100TPS~500TPS 互联网小型网站: 50TPS~100TPS 性能测试计划 测试环境,测试需求,测试方法,测试时间表,测试组织架构,测试风险,输入输出文档 性能测试步骤: 性能测试执行 3.性能测试工具 4.Jmeter简介 4.1.Jmeter的基本概念 Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试,它最初被设计用于Web应用测试,但后来扩展到其他测试领域。 它可以用于测试静态和动态资源,例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器, 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载,来自不同压力类别下测试它们的强度和分析整体性能。另外,JMeter能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性,JMeter允许使用正则表达式创建断言 4.2.我们为什么使用Jmeter 开源免费还很好用,基于Java编写,可集成到其他系统可拓展各个功能插件 支持接口测试,压力(负载和压力)测试等多种功能,支持录制回放,入门简单 相较于自己编写框架活其他开源工具,有较为完善的UI界面,便于接口调试 多平台支持,可在Linux,Windows,Mac上运行 5.Jmeter安装配置及目录结构 5.1.Windows下Jmeter下载安装 登录 http://jmeter.apache.org/download_jmeter.cgi ,根据自己平台,下载对应文件 安装JDK,配置环境变量(具体步骤不做介绍) 将下载Jmeter文件解压,打开/bin/jmeter.bat 5.2.Jmeter的目录结构 /bin 目录(常用文件介绍) examples:目录下包含Jmeter使用实例 ApacheJMeter.jar:JMeter源码包 jmeter.bat:windows下启动文件 jmeter.sh:Linux下启动文件 jmeter.log:Jmeter运行日志文件 jmeter.properties:Jmeter配置文件 jmeter-server.bat:windows下启动负载生成器服务文件 jmeter-server:Linux下启动负载生成器文件 /docs目录——Jmeter帮助文档 /extras目录——提供了对Ant的支持文件,可也用于持续集成 /lib目录——存放Jmeter依赖的jar包,同时安装插件也放于此目录 /licenses目录——软件许可文件,不用管 /printable_docs目录——Jmeter用户手册 6.Jmeter简单入门 6.1.修改语言 6.2.创建测试计划 6.3.添加线程组 6.4.添加sampler设置http请求 6.5.添加结果树 6.6.查看结果 7.测试计划 独立运行每个线程组: 再每一组运行结束后启动下一个 Run tearDown Thread Groups after shutdown of main threads:   主线程关闭运行后拆除线程组, 8.线程组 Delay Thread creation until needed                延迟创建线程,直到该线程开始采样,即之后的任何线程组延迟和加速时间为线程本身。这样可以支持更多的线程,但不会有太多是同时处于活动状态。  持续时间(秒):测试计划持续多长时间,会覆盖结束时间。  启动延迟(秒):测试计划延迟多长时间启动,会覆盖启动时间。 9.Sampler --HTTP请求 请求方式 请求路径 请求ip 请求协议 请求编码 重定向之前的和之后的请求都会在结果树中显示出来 自动重定向,只会显示重定向之后的地址。 10.结果收集 10.1.查看结果树 10.2.表格查看结果 偏离表示服务器响应时间变化、离散程度测量值的大小,或者,换句话说,就是数据的分布。 10.3.聚合报告 10.4.Summary Report 11.Jmeter参数化 11.1.用户定义的变量 使用配置原件中用户定义的变量可以进行参数化 11.2.用户参数 使用前置管理器设置用户参数 11.3.使用csv配置原件 配置元件(Config E
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值