资讯专栏INFORMATION COLUMN

云智慧压测实战分享之JMeter工具使用初探

venmos / 3410人阅读

摘要:有了测试脚本,通过线程组来模拟真实用户对服务器的访问压力。不同的是,这些类型的线程执行测试结束后执行定期的线程组。线程组中包含的线程数量在测试执行过程中是不会发生改变的。逻辑控制器元件只对其子节点中的取样器和逻辑控制器作用。

工欲善其事必先利其器,要保证移动应用产品在上线之后能稳定运行于各种复杂环境,仅仅进行功能测试是远远不够的,压力测试越来越被应用开发商所重视。而压力测试从传统的内部压力到基于云计算的压力测试,再到用户视角的外部压测,也在不断发展变化。JMeter作为一款广为流传的开源压测产品,最初被设计用于Web应用测试,并不断扩展到其他测试领域。
如今,JMeter可以用于测试静态和动态资源,例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器等等,还能对服务器、网络或对象模拟巨大的负载,通过不同压力类别测试它们的强度和分析整体性能。另外,JMeter能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性,JMeter允许使用正则表达式创建断言。
JMeter的特点包括对HTTP、FTP服务器、数据库进行压力/性能测试;完全的可移植性;完全 Swing和轻量组件支持包;完全多线程;缓存和离线分析/回放测试结果;可链接的取样器;具有提供动态输入到测试的功能;支持脚本编程的取样器等。不仅如此,在设计阶段JMeter能够充当HTTP PROXY(代理)来记录浏览器的HTTP请求,也可以记录Apache等WebServer的log文件来重现HTTP流量,并在测试运行时以此为依据设置重复次数和并发度(线程数)来进行压测。

JMeter的压力发生原理

JMeter可以作为Web服务器与浏览器之间的代理网关,捕获浏览器请求和Web服务器响应,这样就能快速生成性能测试脚本。有了测试脚本,JMeter通过线程组来模拟真实用户对Web服务器的访问压力。
原理图如下:


JMeter的结构如下图所示,通过各种元件的组织配合,满足不同的测试需要:

JMeter的常见元件

1、Test Plan (测试计划):用来描述一个性能测试,包含与本次性能测试所有相关的功能,也就说性能测试的所有内容都是于基于一个计划的,右键单击“测试计划”弹出菜单:


注意:“函数测试模式”复选框如果被选择,会记录来自服务器返回的每个取样的数据,在测试监听器中选择一个文件,这些数据将被写入文件。如果尝试一个较小的测试来保证JMeter配置正确并且服务器正在返回期望的结果,这是很有用的,但后果是这个文件会快速增大并对JMeter效率产生影响。

2、Threads(Users)线程(用户)


1) setup thread group 
一种特殊类型的ThreadGroup的,可用于执行预测试操作。这些线程的行为完全像一个正常的线程组元件。不同的是这些类型的线程执行测试前进行定期线程组的执行。setUp Thread Group类似于lr的init.可用于执行预测试操作。
2) teardown thread group
一种特殊类型的ThreadGroup的,可用于执行测试后动作。这些线程的行为完全像一个正常的线程组元件。不同的是,这些类型的线程执行测试结束后执行定期的线程组。tearDown Thread Group类似于lr的end.可用于执行测试后动作。
3) thread group(线程组)
这个就是我们通常添加运行的线程,可以看做一个虚拟用户组,线程组中的每个线程都可以理解为一个虚拟用户。线程组中包含的线程数量在测试执行过程中是不会发生改变的。


在设置线程组参数的时候注意:
  Ramp-Up Period:指定了启动所有线程所花费的时间,单位是秒,默认时间是1秒。比如,当前的设定表示“在5秒内启动5个线程,每个线程的间隔时间为1秒”。如果需要JMeter立即启动所有线程,将此设定为0即可.
  循环次数:表示每个线程执行多少次请求。

3、测试片段(Test Fragment)
测试片段元素是控制器上的一个种特殊线程组,在测试树上与线程组处于一个层级。它与线程组的差异在于,只有被一个模块控制器或者是被控制器所引用时才会执行。

4、取样器(Sampler)
取样器(Sampler)是性能测试中向服务器发送请求,记录响应信息和响应时间的最小单元,JMeter 原生支持多种不同的Sampler,如HTTP Request Sampler、FTP  Request Sampler、TCP Request Sampler、JDBC Request Sampler 等,每一种不同类型的Sampler可以根据设置的参数向服务器发出不同类型的请求。在JMeter的所有Sampler中,Java Request Sampler与BeanShell Requst Sampler是两种特殊的可定制的Sampler。

5、逻辑控制器(Logic Controller)
逻辑控制器包括两类元件,一类是用于控制test plan 中 Sampler节点发送请求的逻辑顺序的控制器,常用的有 如果(If)控制器 、 switch Controller 、Runtime Controller、循环控制器等。另一类是用来组织和控制 Sampler节点的,如事务控制器、吞吐量控制器。

6、配置元件(Config Element)
配置元件(config element)用于提供对静态数据配置的支持。CSV Data Set config 可以将本地数据文件形成数据池 (Data Pool),而对应于HTTP Request Sampler和 TCP Request Sampler等类型的配置元件则可以修改 Sampler的默认数据。例如,HTTP Cookie Manager 可以用于对 HTTP Request Sampler 的 cookie 进行管理。HTTP 请求默认值不会触发JMeter发送http请求,而只是定义HTTP请求的默认属性。

7、定时器(Timer)
定时器(Timer)用于操作之间等待时间的设置,等待时间是性能测试中常用的控制客户端QPS的手段,类似于LoadRunner里面的“思考时间”。JMeter 定义了Bean Shell Timer、Constant Throughput Timer、固定定时器等不同类型的Timer。

8、前置处理器(Per Processors)
前置处理器用于在实际的请求发出之前对即将发出的请求进行特殊处理。例如,HTTP URL重写修复符则可以实现URL重写,当URL中有sessionID 一类的session信息时,可以通过该处理器填充发出请求的实际的sessionID 。

9、后置处理器(Post Processors)
后置处理器是用于对Sampler 发出请求后得到的服务器响应进行处理,一般用来提取响应中的特定数据(类似LoadRunner测试工具中的关联概念)。例如,XPath  Extractor 可以提取响应数据中通过给定XPath 值获得的数据,正则表达式提取器则可以提取响应数据中通过正则表达式获得的数据。

 10、断言(Assertions)
断言用于检查测试中得到的相应数据等是否符合预期,断言一般用来设置检查点,用以保证性能测试过程中的数据交互是否与预期一致。


 
11、监听器(Listener)
监听器不是用来监听系统资源的元件,而是对测试结果数据进行处理和可视化展示的一系列元件,包括图形结果、查看结果树、聚合报告、用表格察看结果都是我们经常用到的元件。

12、工作台

在测试中我们可能需要暂时更改一些组件,可以把一些需要更改的组件保存在工作台中,测试完成后再恢复。但是切记不能退出jmeter,一旦退出jmeter工作台中的内容就会消失。

13、Property Display
此元件相当于是jmeter.properties的GUI。

JMeter元件的作用域和执行顺序

在JMeter中,元件的作用域是靠测试计划的树型结构中元件的父子关系来确定的,作用域的原则是:
1.取样器(sampler)元件不和其它元件相互作用,因此不存在作用域的问题。
2.逻辑控制器(Logic Controller)元件只对其子节点中的取样器和逻辑控制器作用。
3.除取样器和逻辑控制器元件外,其他6类元件,如果是某个sampler的子节点,则该元件公对其父子节点起作用。
4.除取样器和逻辑控制器元件外的其他6类元件,如果其父节点不是sampler,则其作用域是该元件父节点下的其他所有后代节点(包括子节点,子节点的子节点等)。
了解了元件有作用域之后,再来看看元件的执行顺序规则,在同一作用域名范围内,测试计划中的元件按照如下顺序执行:
1)配置元件(config elements )
2)前置处理程序(Per-processors)
3)定时器(timers )
4)取样器(Sampler)
5)后置处理程序(Post-processors) (除非Sampler 得到的返回结果为空)。
6)断言(Assertions)(除非Sampler 得到的返回结果为空)。
7)监听器(Listeners)(除非Sampler 得到的返回结果为空)。
关于执行顺序,有三点需要注意:

前置处理器、后置处理器和断言等元件只能对 取样器作用,因此,如果在它们的作用域内没有任何取样器,则不会被执行。

如果在同一作用域范围内有多个同一类型的元件,则这些元件按照它们在测试计划中的上下顺序一次执行。

一个断言在测试树中是分等级的。如果它的父元件是请求,它就被应用于那个请求。如果它的父元件是控制器,它就影响所有那个控制器下的所有请求。
以上是JMeter使用之前必须了解的一些基本信息,接下来我们将为您带来JMeter脚本录制实例,敬请期待。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/8764.html

相关文章

  • 智慧微课堂:移动创业公司的IT性能优化实例讲解

    摘要:大家好,我叫汤金城,今天和大家分享一下我在公司业务方面故障排查遇到的一些坑,以及进行性能调优的解决方法。性能的优化在我看来,性能优化和监控是分不开的,现在关于优化的配置非常多,适合自己的才是最好的。 本期主讲:汤金城,多年从事移动互联网相关运维工作,带领团队维护数百台服务器,拥有丰富的故障排查和性能优化实战经验,擅长业务拆分,高可用架构设计。 大家好,我叫汤金城,今天和大家分享一下我在...

    xzavier 评论0 收藏0
  • 企业互联网+转型实战:如何进行PB级别数据的架构变迁

    摘要:常用的根据主键或非主键的分片规则枚举法比如数据是按照地区省份来保存的,用户通过多级别划分的,本规则适用于这些特定的场景。 随着DT时代的来临,数据对于企业经营决策的价值日益凸显,而企业在进行互联网+转型的过程中,如何让数据架构平滑迁移到大数据平台,对于传统业务的转型升级至关重要。企业IT部门该如何进行PB级别大数据平台的迁移规划呢,请看云智慧运维总监张克琛带来的经验分享。提到PB级别的...

    xeblog 评论0 收藏0
  • 企业互联网+转型实战:如何进行PB级别数据的架构变迁

    摘要:常用的根据主键或非主键的分片规则枚举法比如数据是按照地区省份来保存的,用户通过多级别划分的,本规则适用于这些特定的场景。 随着DT时代的来临,数据对于企业经营决策的价值日益凸显,而企业在进行互联网+转型的过程中,如何让数据架构平滑迁移到大数据平台,对于传统业务的转型升级至关重要。企业IT部门该如何进行PB级别大数据平台的迁移规划呢,请看云智慧运维总监张克琛带来的经验分享。提到PB级别的...

    feng409 评论0 收藏0
  • 企业互联网+转型实战:如何进行PB级别数据的架构变迁

    摘要:常用的根据主键或非主键的分片规则枚举法比如数据是按照地区省份来保存的,用户通过多级别划分的,本规则适用于这些特定的场景。 随着DT时代的来临,数据对于企业经营决策的价值日益凸显,而企业在进行互联网+转型的过程中,如何让数据架构平滑迁移到大数据平台,对于传统业务的转型升级至关重要。企业IT部门该如何进行PB级别大数据平台的迁移规划呢,请看云智慧运维总监张克琛带来的经验分享。提到PB级别的...

    JaysonWang 评论0 收藏0
  • jmeter web性能测试实例

    jmeter web性能测试实例 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; ma...

    IT那活儿 评论0 收藏1191

发表评论

0条评论

venmos

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<