JMeter基础入门之必备 学习

JMeter学习笔记

1. 安装JMeter

1.安装JDK 1.4以上版本。

2. 设置环境变量：

i. 在用户变量中,新建变量名“JAVA_HOME”,变量值为：安装JDK的目录,如我的为：

“C:\Program Files\Java\jdk1.5.0;”

ii. 再新建变量名为“CLASSPATH”,变量值为：

“%JAVA_HOME%\lib\dt.jar; %JAVA_HOME%\lib\tools.jar; %JAVA_HOME%\bin;” 。

iii. 在系统变量的“Path”变量值后加上：“%JAVA_HOME%\bin;”。

3. 安装Jmeter,解压“jakarta-jmeter-2.3.2.zip”到E盘根目录下：

“E:\jakarta-jmeter-2.3.2”。

4. 设置环境变量：

i. 在用户变量中,新建变量名“JMETER_HOME”,变量值为：

“E:\jakarta-jmeter-2.3.2;”。

ii. 修改“CLASSPATH”，添加：

“%JMETER_HOME%\lib\ext\ApacheJMeter_core.jar;%JMETER_HOME%\lib\jorphan

.jar;%JMETER_HOME%\lib\logkit-1.2.jar;”。

5. 运行jmeter: 直接打开 E:\jakarta-jmeter-2.3.2\bin\jmeter.bat 即可。

2. JMeter 的主要测试组件总结如下：

1. 测试计划是使用JMeter 进行测试的起点，它是其它JMeter 测试元件的容器。

2. 线程组代表一定数量的并发用户，它可以用来模拟并发用户发送请求。实际的请求内容在Sampler中定义，它被线程组包含。

3. 监听器负责收集测试结果，同时也被告知了结果显示的方式。

4. 逻辑控制器可以自定义JMeter发送请求的行为逻辑，它与Sampler结合使用可以模拟复杂的请求序列。

5. 断言可以用来判断请求响应的结果是否如用户所期望的。它可以用来隔离问题域，即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。

6. 配置元件维护Sampler需要的配置信息，并根据实际的需要会修改请求的内容。

7. 前置处理器和后置处理器负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置，后置处理器则常常用来处理响应的数据。

8. 定时器负责定义请求之间的延迟间隔。

3. 常用测试

本文以这三种节点为例，介绍如何使用JMeter 来完成针对于它们的压力测试。

3.1 Web 服务器

对于大多数的项目来说，并不会自行开发一个Web服务器，因此Web服务器压力测试的对象实际就是--发布到Web服务器中的软件。最简单的Web测试计划只需要三个JMeter 的测试元件，如下图：

其中：

?在线程组中定义线程数、产生线程发生的时间和测试循环次数。

?在http请求中定义服务器、端口、协议和方法、请求路径等。

?表格监听器负责收集和显示结果。

这种设置对于包含了安全机制的web 应用是不够的，典型的web 应用一般都会：

1. 有一个登录页，它是整个应用的入口。当用户登录之后，应用会将用户相关的安全信息放到session 中。

2. 有一个filter，它拦截请求，检查每个请求相关的session 中是否包含有用户安全信息。如果没有，那么请求被重定向到登录页，要求用户提供安全信息。

在这种配置下应用上面的测试计划，那么除了登录页之外的其它请求都将因为缺少用户安全信息，而使请求实际定位到登录页。如果不加断言，那么在监听器看来所有的请求都是成功。而实际上，这些请求最终都没有到达它们应该去的地方。显然，这种测试结果不是我们所期望的。

为了成功的测试，至少有2种方法：

?方法一，去掉程序的安全设置，如filter，使得不需要用户安全信息也能访问受限内容；

?方法二，不修改程序，使用JMeter提供的"Http URL重写修饰符"或"Http Cookie管理器"。

对于第一种方法，有其局限性：

?需要修改程序配置，如去掉web.x中关于安全filter的设置。需要维护多个版本的web.x，如压力测试和功能测试分别各自的web.x，增加了维护成本，而且有可能会在测试之后忘记将web.x修改回来。

?对于一些需要用户安全信息的页面无能为力，如某些业务审计操作需要用户安全信息来记录。因为缺少这样的信息，注定了测试的失败。如果解决为了这个问题进一

步的修改程序，那么因为存在多个版本的程序，那么其维护难度将大大增加。

虽然，第二种方法配置难度增加了，但是它不用修改程序。而且还可将测试计划保存成文件，以便重复使用。因此，选用第二种方法是较为理想的做法。下面以一个简化的例子说明使用方法二的配置步骤。

1. 例子由以下几个文件组成：

?AuthorizenFilter.java，过滤器负责检验session中是否存在用户信息。如果没有，那么就转向到login.jsp。它的主要方法doFilter 内容如下：

public void doFilter(ServletRequest request,

ServletResponse response,

FilterChain chain)

throws IOException, ServletException {

HttpServletRequest req = (HttpServletRequest)request;

HttpServletResponse res = (HttpServletResponse)response;

HttpSession session= req.getSession();

User user = (User)session.getAttribute("user");

if(null == user){

String uri= req.getRequestURI();

//如果请求页是登录页，不转向

if( uri.equalsIgnoreCase("/gWeb/login.jsp")){

chain.doFilter(request, response);

} else{

res.sendRedirect("/gWeb/login.jsp");

}

}else{

chain.doFilter(request, response);

}

}

?User.java，用户类负责记录用户的信息。为了简化，这里的登录操作只允许指定用户名和密码。主要内容如下：

?Login.jsp 和welcome.jsp。其中login.jsp 负责生成User 对象，并调用User 的login。

当login 返回为true 时转向到welcome.jsp。其验证部分的代码：

<%

if( request.getParameter("Submit") != null) {

User ur= new User( request.getParameter("user"), request.getParameter("pwd"));

if( ur.login()){

session.setAttribute("user", ur);

response.sendRedirect("/gWeb/welcome.jsp");

} else{

session.setAttribute( "LOGIN_ERROR_MSG",

"无效的用户，可能原因：用户不存在或被禁用。");

response.sendRedirect("/gWeb/index.jsp");

return;

}

}

%>

?

2. 创建如下结构的Web测试计划：

其中主要测试元件说明如下：

?http请求默认值负责记录请求的默认值，如服务器、协议、端口等。

?第一个http请求，请求login.jsp，并附加验证所需要的参数（user=foxgem，pwd=12345678，Submit=Submit）；其包含的响应断言验证url中包含"welcome.jsp"，这一点可以从程序中反应。

?第二个http请求，请求是welcome.jsp；其包含的响应断言验证响应文本中包含"foxgem"，它是welcome.jsp页面逻辑的一部分。

?http cookie管理器负责管理整个测试过程中使用的cookie，它不需要设置任何属性。

?循环控制器设置发送第二个请求的循环次数，表格监听器负责收集和显示第二个请求的测试结果。

启动测试计划之后，执行的顺序是：首先，第一个请求登录页进行登录；成功登录之后，使用循环控制器执行第二个请求。请求welcome.jsp时，响应断言用来验证是否确实是welocme.jsp来处理请求，而不是因为其它页。在这个测试计划中需要注意的是http cookie 管理器。正是由于它的作用，使得第二个请求能顺利的发送到welcome.jsp进行处理，而不是因为缺少用户安全信息转发到login.jsp。

在这个例子中，我们并没有在程序中使用cookie（使用的是session），那么http cookie管理器怎么会起作用呢？这是因为在servlet/jsp规范中对于session的状态跟踪有2种方式：

?使用cookie，保留和传递sessionid。它不要求程序对于url有什么特殊的处理，但是要求浏览器允许cookie。在这个例子中，就是这种情形。

?使用url重写，每次显式的在浏览器和服务器之间传递sessionid。它要求程序对url 进行编码，对浏览器没有要求。

对于第二种情形，可以使用JMeter前置管理器中的http url重写修饰符来完成。对于Tomcat，Session参数是jsessionid，路径扩展使用"；"。使用url编码时需要注意，必须将浏览器的cookie 功能关闭。因为url编码函数，如encodeURL，会判断是否需要将sessionid编码到url中。当浏览器允许cookie时，就不会进行编码。

如果cookie而不是session来保存用户安全信息，那么直接使用http cookie管理器就行了。此时，需要将使用的cookie参数和值直接写到管理器中，由它负责管理。对于其它的cookie 使用，也是如此操作。

登录问题解决之后，对于Web 服务器的测试就没什么难点了。剩下的就是根据实际需要，灵活运用相关的测试组件搭建编写的测试计划。（当然，对于安全问题还有其它的使用情景。在使用时需要明确：JMeter 是否支持，如果支持使用哪种测试组件解决。）

3.2 数据库服务器

数据库服务器在大多数企业项目中是不可缺少的，对于它进行压力测试是为了找出：数据库对象是否可以有效地承受来自多个用户的访问。这些对象主要是：索引、触发器、存储过程和锁。通过对于SQL语句和存储过程的测试，JMeter 可以间接的反应数据库对象是否需要优化。

JMeter 使用JDBC 发送请求，完成对于数据库的测试。一个数据库测试计划，建立如下结构即可：

其中：

?JDBC连接配置，负责配置数据库连接相关的信息。如：数据库url、数据库驱动类名、用户名和密码等等。在这些配置中，"绑定到池的变量名"（Variable Name Bound to

Pool）是一个非常重要的属性，这个属性会在JDBC请求中被引用。通过它，JDBC

请求和JDBC连接配置建立关联。（测试前，请将所需要的数据库驱动放到JMeter的classpath中）。

?JDBC请求，负责发送请求进行测试。

?图形结果，收集显示测试结果。

在实际的项目中，至少有2种类型的JDBC请求需要关注：select语句和存储过程。前者反应了select语句是否高效，以及表的索引等是否需要优化；后者则是反应存储过程的算法是否高效。它们如果效率低下，必然会带来响应上的不尽如人意。对于这两种请求，JDBC请求的配置略有区别：

?Select语句

?存储过程

如果对于Oracle，如果测试的是函数，那么也可以使用select语句来进行配置，此时可以使用：select 函数(入参) from dual形式的语句来测试，其中dual是oracle的关键字，表示哑表。对于其它厂商的数据库产品，请查找手册。

3.3 JMS服务器

MOM 作为消息数据交换的平台，也是影响应用执行效率的潜在环节。在Java 程序中，是通过JMS 与MOM 进行交互的。作为Java 实现的压力测试工具，JMeter 也能使用JMS 对应用的消息交换和相关的数据处理能力进行测试。这一点应该不难理解，因为在整个测试过程中，JMeter 测试的重点应该是消息的产生者和消费者的本身能力，而不是MOM本身。根据JMS 规范，消息交换有2种方式：发布/订阅和点对点。JMeter针对这两种情形，分别提供了不同的Sampler进行支持。以下MOM我们使用ActiveMQ 3.2.1，分别描述这两种消息交换方式是如何使用JMeter 进行测试。

1. 测试前的准备（两种情况都适用）

下面就是实际使用jmeter 进行jms 测试

首先需要启动activemq，直接运行ACTIVEMQ_HOME/bin/activemq.bat （ACTIVEMQ_HOME即activemq的安装目录）批处理脚本，当看到如下图所示内容，说明activemq 已经成功启动。

下面开始启动jmeter。在运行jmeter 之前需要完成几件事情。由于jmeter 是通过jndi 来获得jms 中相关对象的，如ConnectionFactory 和Destination，所以在jmeter 的classpath 中需要添加一个jndi.properties 属性文件，用于配置jndi。这个文件配置的是activemq 相关的jndi，有关activemq 与jndi

保存并把这个文件复制到JMETER_HOME/bin （JMETER_HOME为jmeter 的安装目录）目录中。由于bin 目录并不在jmeter 的classpath 中，所以需要执行一些额外的工作来把jndi.properties 添加到jmeter 的classpath 中，这儿使用一种最简单的办法：把jndi.properties 打包到jmeter 的启动jar 包中。jmeter 的启动jar 包为JMETER_HOME/bin/ApacheJMeter.jar，所以需要把jndi.properties 打包到这个jar 文件中。执行如下操作，打开命令行窗口，并定位到JMETER_HOME/bin 目录，运行如下命令jar uf ApacheJMeter.jar jndi.properties 就可以，如图所示

下图是运行jar uf ApacheJMeter.jar 命令之前，ApacheJMeter.jar 中所包含的目录或文件

下图是运行jar uf ApacheJMeter.jar 命令之后的情况

可以看到，ApacheJMeter.jar 文件中已经包含了jndi.properties 文件。

jmeter 在测试jms 的时候会使用到activemq 提供的jms 的实现类，这些类并没有随jmeter 一起分发，所以需要把这些类添加到jmeter 的classpath 中。只要把ACTIVE_HOME/activemq-all-5.2.0.jar 文件复制到JMETER_HOME/lib 目录中即可。

下面可以运行jmeter 了，直接运行JMETER_HOME/bin/jmeter.bat 批处理文件就可以启动jmeter 了。

（jmeter 启动的时候默认会在JMETER_HOME/bin 目录中生成一个日志文件jmeter.log，如果运行过程中有什么问题可以查看这个日志文件）jmeter 启动之后如下图所示

下面我们来一步一步建立测试计划。

首先是创建线程组

线程组的具体配置为

创建完线程组之后创建jms point to point sampler

jms 配置如下所示

最后创建一个监听器

下面就可以开始测试了

下面两张图片是通过activemq 基于web 的管理控制台查看到的example.MyQueue 队列上等待传递的消息的条数。

图1

图2

可以看到运行这一次测试发送了5条消息，这些消息的内容为

上面就是一个简单的使用jmeter 测试jms 应用的过程。

从上面准备测试的过程可以看出，在准备activemq 方面的jndi 的配置的时候有点麻烦，尤其是需要修改jndi 配置的时候尤其麻烦，还有就是直接把activemq 的jar 包放到lib 目录中会使jmeter 的jar 包与测试依赖的混在一起，下面就通过修改jmeter 启动类源代码的方法来解决这两个问题。

要通过修改jmeter 的启动类，在lib 目录下增加两个目录：user 和conf，user 目录用于存放测试依赖的jar 包，conf 用于存放类似jndi.properties 这样的配置文件，这两个目录都必须添加到jmeter 运行时的classpath 中。

查看jmeter.bat 可以知道，是通过运行bin 目录中ApacheJMeter.jar 文件来启动jmeter 的。查看ApacheJMeter.jar 文件的清单文件可知启动类为org.apache.jmeter.NewDriver。下载jmeter 的源代码，查看类org.apache.jmeter.NewDriver。查看NewDriver 的源代码可知，jmeter 的启动方式是，扫描lib 目录以及lib 目录下的子目录ext 和junit 下的jar 包，通过这些jar 包构建一个URLClassLoader，然后把这个类加载器设为当前线程的上下文类加载器，然后使用这个类加载器加载类

org.apache.jmeter.JMeterReport，并运行它的start 方法（activemq 也是以这样的方式来编写启动类的）。下面只要把user 添加到扫描目录中，并把conf 目录添加到classpath 中。修改后的源代码，以及编译打好的包都在附件中，需要的可以下载。只要下载ApacheJMeter.jar 并把它复制到bin 目录中，替换jmeter 原来的ApacheJMeter.jar 即可，然后在lib 目录下创建两个子目录user 和conf。user 用于存放测试依赖的jar 包，conf 用于存放配置。

2. 发布/订阅

在实际测试时，发布者和订阅者并不是需要同时出现的。例如，有时我们可能想测试单位时间内消息发布者的消息产生量，此时就不需要消息发布者，只需要订阅者就可以了。本例为了说明这两种Sampler的使用，因此建立如下的测试计划：

其中JMS Publisher和JMS Subscriber的属性：选择"使用jndi.properties"，连接工厂是connectionFactory，主题是MyTopic，其它使用默认配置。对于JMS Publisher，还需提供测试用的文本消息。

启动ActiveMQ，运行测试计划。如果配置正确，那么与ActiveMQ成功连接之后，在JMeter 的后台会打印出相关信息。在测试过程中，JMeter 后台打印可能会出现

https://www.sodocs.net/doc/2a16785921.html,ng.InterruptedException 信息，这个是正常现象，不会影响测试过程和结果。这一点可以从bin 下的jmeter.log 看出。

3. 点对点

对于点对点，JMeter只提供了一种Sampler：JMS Point-to-Point。在例子中，建立如下图的测试计划：

其中：Communication style是Request Only。对于另一种风格：Request Response，会验证收到消息的JMS Header中的JMSCorrelationID，以判断是否是对请求消息的响应。

4. jmeter结果分析

采用Jmeter测试工具对web系统作的负载测试，得出的响应报表，数据比较难懂，现作一具体说明以下是在一次具体负载测试中得出的具体数值，测试线程设置情况为：线程数：200，等待时间（ramp-up）：0秒，循环次数为永远，另线程组——这些元件用于指定运行的线程数和等候周期。每个线程模拟一个用户，而等候周期用于指定创建全部线程的时间。例如，线程数为5，等候时间为10秒，则创建每个线程之间的时间间隔为2秒。循环数定义了线程的运行时间。使用调度器，还可以设置运行的起始时间

取样器——对于服务器HTTP、FTP或LDAP请求，这些元件是可配置请求。该教程仅侧重于Web Services 请求监听器——这些元件用于请求数据的后期处理。例如，可以将数据保存到文件或用图表来说明结果。此时JMeter图表并没有提供许多配置选项；然而它是可扩展的，它始终可以添加额外的可视化效果或数据处理模块，得出的图形报表和聚合报告如下所示：

4.1 图形报表

图表底部参数的含义如下：

样本数目是总共发送到服务器的请求数。

最新样本是代表时间的数字,是服务器响应最后一个请求的时间。

吞吐量是服务器每分钟处理的请求数。

平均值是总运行时间除以发送到服务器的请求数。

中间值是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。

偏离表示服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。

4.2 聚合报告

图表含义说明如下：

Label：说明是请求类型，如Http，FTP等请求。

#Samples：也就是图形报表中的样本数目，总共发送到服务器的样本数目。

Average：也就是图形报表中的平均值，是总运行时间除以发送到服务器的请求数。

Median：也就是图形报表中的中间值，是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。

90%line：是指90%请求的响应时间比所得数值还要小。

Min：是代表时间的数字,是服务器响应的最短时间。

Max: 是代表时间的数字,是服务器响应的最长时间。

Error%:请求的错误百分比。

Throughput:也就是图形报表中的吞吐量，这里是服务器每单位时间处理的请求数，注意查看是秒或是分钟。KB/sec:是每秒钟请求的字节数。

4.3 使用分析

在测试过程中，平均响应时间是我们性能测试的一个重要衡量指标，但是在测试中，特别是在聚合报告中，得出的90%Line,我这里参考《《LoadRunner 没有告诉你的》之一——描述性统计与性能结果分析》，我认为90%Line等同于该文作者提出的90%响应时间,这个数值对我们性能测试分析也很有参考价值。90%响应时间是说在发送的请求中，90%的用户响应时间都比得到的数值上要短，同时说明，一个系统在应用时，90%的用户响应时间都能达到这个数值，那么就为系统性能分析提供了很好的参考价值。

4.4 view Results Tree 以树状列表查看结果

通过这个Listener，我们可以看到很详细的每个transaction它所返回的结果，其中红色是指出错的transaction，绿色则为通过的。

如果你测试的场景会有很多的transaction完成，建议在这个Listener中仅记录出错的transaction就可以了。要做到这样，你只需要将Log/Display:中的Errors勾中就可以了。

5.使用JMeter进行脚本的录制。

5.1 Jmeter中的脚本录制

方法一：