性能测试--初识Jmeter
初识Jmeter
Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试,它最初被设计用于Web应用测试,但后来扩展到其他测试领域。 它可以用于测试静态和动态资源,例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器, 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载,来自不同压力类别下测试它们的强度和分析整体性能。另外,JMeter能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性,JMeter允许使用正则表达式创建断言。
一、安装Jmeter、jmeter使用小技巧
1、下载jdk、配置环境变量
2、下载jmeter、配置环境变量
3、离线文档的使用:jmeter安装目录下的printable_docs 目录下index.html文件中的Using JMeter选项
4、对jmeter左侧的节点树中的某个节点有疑问:直接在选择该节点的情况下,点击帮助文档,便会跳转至该节点的详细说明页面
二、jmeter测试示例
1、需求场景
-
-
- 模拟5个用户同时访问百度首页
- 每秒钟增加1个用户去访问百度首页,这样5个用户一共需要5秒种的时间去加载完毕
- 循环2次,这个一共会产生
5 * 2 = 10
个请求的负载
-
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
""" 步骤一:选择Web Test Plan模版 1、点击templates按钮 2、选择Building a Web Test Plan 3、最后点击create,完成创建。 步骤二:修改参数 1、修改测试计划名称为hello jmeter 2、修改线程组名称为:5个虚拟用户访问百度首页,线程数:5,ramp-up period:5, 循环次数:2。 3、修改HTTP Request Defaults的名称为百度站点的默认配置,并将web服务器名称修改为www.baidu.com 4、将Home Page HTTP请求的名称修改为百度首页,注释掉百度首页下的断言 5、删除Page Returing 404节点 步骤三:运行 1、点击运行按钮(快捷键ctrl+r) """
注:
从上面脚本中可以看到下面几种类型的jmeter组件。
-
配置元件。图标是扳手和起子。配置元件是用来存放配置信息的,jmeter提供了丰富的配置元件来帮助我们构建我们的测试脚本。常用的配置元件有用户自定义变量元件,HTTP请求默认值元件等;
-
取样器。取样器的图标是滴管,跟图像处理软件中的取色器图标类似。取样器(Samplers)是jmeter真正产生请求的组件。常用的取样器是HTTP请求取样器;
-
逻辑控制器。逻辑控制器用来控制取样器的执行顺序,比如Ramdom Controller(暂且称为是随机控制器吧),能够产生让取样器随机执行的效果;比如事务控制器可以用来组织一些事务型的请求;
-
监听器。可以通俗的理解为测试报告。
三、对jmeter示例中的组件释疑
用jmeter开发性能测试脚本有点像是搭积木。jmeter给我们提供了很多组件,通过合理的组合这些组件,可以开发出符合自己测试场景jmeter脚本。
1、测试计划(Test Plan)
Test Plan是所有取样器和控制器的父组件,可以通过右键单击Test Plan组件的方式往里面其中添加其它组件。
2、线程组(Thread Group)
我们可以简单把线程组理解成虚拟用户配置的组件。线程组里比较重要的一些配置项是
- 线程数(Number Of Threads)。配置几个就代表有几个虚拟用户
- Ramp-Up Period(in seconds)。表示从第一个虚拟用户开始生成直到最后一个虚拟用户开始生成的时间。假如配置了5个虚拟用户,Ramp-Up配置成10s,那么jmeter会每隔2s生成1个虚拟用户。这个选项主要的作用是控制并发的强度,不让虚拟用户在同一时间产生从而对系统造成过大的复杂。Ramp-Up设置成0,那么所有的用户将会同时立即产生
- 循环数(Loop Count)。很好理解,要么是N次,要么是永远
- 调度器(Scheduler)。就是定时执行的设置方式。我们可以设置在未来的某个时间开始执行也可以设置多少秒后开始执行。注意只有在按下执行按钮后,调度器才生效
3、HTTP请求默认配置(HTTP Request Defaults)
这是jmeter中最常用的取样器。该组件的作用很容易理解,就是配置http请求,可以配置的项目很多
- 名称(Name)。给这个请求取个名字,好的名字可以让报告便于阅读;
- Web服务器(Server)。可以配置请求的目的服务器的域名或IP及端口号,比如服务器名称是
localhost
,端口号是8080
; - HTTP请求协议(Protocol)。支持3种协议:HTTP,HTTPS,FILE。 默认是: HTTP
-
HTTP请求Implementation。选择实现方式。有下面几个选项:
- 空。也就是不选。这时候jmeter就回去找jmeter全局属性的
jmeter.httpsampler
的值,如果没设置的话就用HttpClient4
。一般情况下,jmeter.httpsampler
的值是没有配置的,所以选空基本上就等于选HttpClient4
- HttpClient3.1。jmeter 3.0后就废弃了,千万不要选
- HttpClient4。基本上是系统默认值了,不知道怎么选的时候就选这个
- java。jvm的标准实现,不支持很多扩展的http方法,所以不清楚的适合就不要选这个
- 空。也就是不选。这时候jmeter就回去找jmeter全局属性的
-
HTTP请求方法。默认是GET。注意,如果你选java作为http请求的实现方式的话,那么java实现只支持GET , POST , HEAD , TRACE , OPTIONS , PUT , DELETE方法
- 路径(Path)。略
- 同请求一起发送的参数(Send Parameters With the Request)。参数是HTTP请求取样器的难点。一般来说我们都是通过录制的方式获取请求参数,然后再在脚本取样器里对参数进行一些修改——比如参数化等
4、HTTPCookie管理器(HTTP Cookie Manager)
- Cookie 管理器就像一个 web 浏览器那样存储并发送 cookie。
- 接收到的 cookie 数据可以作为 JMeter 线程的参数进行存储(JMeter 2.3.2 之后的版本默认不再打开这个功能)。
- 手工添加一个 cookie 到 Cookie 管理器。
5、HTTP信息头管理器(HTTP Header Manager)
这是一个配置元件。在录制脚本的时候,每一个HTTP请求取样器下面都挂着一个HTTP信息头管理器。这个组件的作用就是以key-value的格式设置http请求的header,一般来说我们通过录制的方式http请求的header。另外每一个请求下面挂一个header信息配置器不利于我们统一的控制线程组中的所有请求,我们可以只在线程组下面挂一个header管理器,这样线程组下的所有http请求都具有同样的header了。
6、录制控制器(Recoding Controller)
这个控制器就是个容器,录制脚本时自动生成的请求都在这个控制器下面
7、事务控制器(Transaction Controller)结果树
假如我们正在测试1个工单系统,提交工单共需要3个步骤,暂且认为是step1,step2,step3,每一步都需要发送一个请求到服务器。1个工单提交的总耗时应该等于step1的耗时+step2的耗时+step3的耗时,在jmeter报告中可以很容易的获取每个请求的响应时间,但是如何获取3个请求的总时间呢?答案是使用事务控制器将这3个请求聚合,把3个请求作为事务控制器的子组件就可以了。
所以事务控制器可以为我们聚合逻辑上应该合并在一起度量的N个请求的总响应时间。
8、工作台
该组建可以理解成为临时工作区,我们可以把一些临时性质或是调试性质的组件放在里面。当我们保存测试计划时,WorkBench组建默认是不保存的,另外下面3种组件只能存在于WorkBench中
- HTTP(S) Test Script Recorder
- HTTP Mirror Server
- Property Display
四、聚合报告中的指标
图形结果里出现了一些性能测试中经常用到的指标:
-
样本数量(samples)。在这里,我们可以把样本数量简单理解成是jmeter一共向服务器发起了多少次请求;
-
平均(average)。所有请求响应时间的平均值。单位是毫秒;
- 中值。就是响应时间的中间值,学术一点中值指的是有50%的值大于这个值,另外50%的值小于这个值。蒙圈了吧?实际上中值指的是如果有9个数,那么我们从小到大排列这些数,排在第5个的数就是这一组数的中值。那么如果有10个数呢?10个数的话第5个和第6个数的平均值就是这组数字的中值;
- 90%Line 。90%请求响应时间不会超过XXX毫秒
- 95%Line。与上同理
- 99%Line。与上同理
- Min。最小响应时间
- Max。最大响应时间
-
Error%.请求响应失败率
-
吞吐量(throughput)。被测系统每分钟能处理的请求个数,这是判断服务器性能好坏的重要指标(也可以说是最重要的指标)。在上面的图形结果报表里我们可以看到系统的吞吐量是138.985每分钟,这就代表着系统每分钟可以处理138.985个请求;
- Received KB/sec 平均每秒接受多少KB的数据
- Sent KB/sec 平均每秒发送多少KB的数据