Linux下运行Jmeter （含一个jmeter简单示例）

最新推荐文章于 2024-08-08 15:33:35 发布

zhemeteor

最新推荐文章于 2024-08-08 15:33:35 发布

阅读量3.5w

点赞数 4

分类专栏：测试开发 jmeter 文章标签：测试开发 jmeter

本文链接：https://blog.csdn.net/zhemeteor/article/details/51316176

版权

测试开发同时被 2 个专栏收录

3 篇文章 0 订阅

订阅专栏

jmeter

3 篇文章 0 订阅

订阅专栏

本文的方法是现在图形界面下添加好组件，生成jmx脚本文件，然后将jmx文件放到linux环境下用命令行运行脚本，进行性能测试。

1. 用Jmeter进行打压测试

如果可以打开图形界面，则可以参看图形界面的使用教程；

此外，在Linux下用命令行进行测试。

1.1 在图形界面编辑打压测试脚本

参考《Jmeter教程简单的压力测试》： http://www.cnblogs.com/TankXiao/p/4059378.html

其实所谓的脚本文件，就是用图形界面配置好信息后保存的jmx文件，jmx是一个xml格式的文本，可以用来在命令行作为参数执行。

以下流程是在《Jmeter教程简单的压力测试》的基础上根据 Y公司的测试习惯做得补充和修改：

什么是压力测试

顾名思义：压力测试，就是被测试的系统，在一定的访问压力下，看程序运行是否稳定/服务器运行是否稳定（资源占用情况）

比如： 2000个用户同时到一个购物网站购物，这些用户打开页面的速度是否会变慢，或者网站是否会奔溃

做压力测试的常用工具

做压力测试，一般要使用工具，人工是没办法做的。最常用的工具是LoadRunner, 但是LoadRunner毕竟是收费软件，而且使用上也比较复杂。现在越来越多的人开始使用Jmeter来做压力测试。免费，而且使用上非常简单。

做压力测试的步骤如下:

1. 写脚本或者录制脚本

2. 使用用户自定义参数

3. 场景设计

4. 使用控制器，来控制模拟多少用户。

5. 使用监听器，查看测试结果

本文做压力测试的例子

本文举的实例是：在一台电脑用Jmeter模拟200个用户，同时去使用bing搜索不同的关键字，查看页面返回的时间是否在正常范围内。

第一步：使用CSV Data Set Config 来参数化

首先我们把测试需要用到的2个参数放在txt文件中，

新建一个data.txt文件，输入些数据，一行有两个数据，用逗号分隔。

1. 启动Jmeter, 会出现如下界面，系统自动添加了一个Test Plan（测试计划），在名称位置可以更改测试计划名称，比如： Bing接口测试样本

2. 先添加一个Thread Group (右击 Test Plan(测试计划) -> Add(添加) -> Thread（Users）-> Thread Group（线程组） )；

线程组也可以重命名，比如：Bing 200并发

3. 然后在“线程组” 下添加一个CSV Data Set Config (右击线程组 -> Add（添加） -> Config Element（配置元件） -> CSV Data Set Config)；

在 CSV Data Set Config 中配置测试中要用到的文件内容信息，

第二步：添加HTTP Request.

我们添加http 请求，发送get 到 http://cn.bing.com/search?q=${param1}+${param2} （）

1. 选择Thread Group 右键 (Add（添加） ->Sampler -> HTTP Request（HTTP 请求）)，

2. 需要填的数据如下：

A. 在路径中使用变量

B. 在变量栏中添加变量

C. 在变量中添加变量，同时路径中也含有变量

本文后续采用第二种方式

第三步：使用Thread Group，控制模拟多少用户

选中Thread Group

Number of Threads(users 线程数): 一个用户占一个线程， 200个线程就是模拟200个用户

Ramp-Up Period(in seconds)（准备时长）: 设置线程需要多长时间全部启动。如果线程数为200 ，准备时长为10 ，那么需要1秒钟启动20个线程。也就是每秒钟启动20个线程。

Loop Count（循环次数）: 每个线程发送请求的次数。如果线程数为200 ，循环次数为100 ，那么每个线程发送100次请求。总请求数为200*100=20000 。如果勾选了“永远”，那么所有线程会一直发送请求，直到选择停止运行脚本。

注：如果想保证线程数里的线程能同时执行，所有线程的执行时间必须大于Ramp-up Period的时间。Jmeter打压的同时运行线程数最大不会超过我们设置的线程数。

关于 Number of Threads、Ramp-Up Period 以及 Loop Count 之间关系的解释，可参考：http://blog.csdn.net/hsd412237463/article/details/49929173

主要是对于 Ramp-Up Period 参数的理解(http://www.knowsky.com/367353.html)。

（每个线程均独立运行测试计划。因此，线程组常用来模拟并发用户访问。假如客户机没有足够的能力来模拟较重的负载，可以使用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 也是不恰当的，因为将会降低访问峰值的负载，换句话说，在一些线程还未启动时，初期启动的部分线程可能已经结束了。）

此外，对于Thread Group 的循环次数的设置，可以选用调度器来指定：

第四步：添加监听器查看测试结果

有两种比较常用的监听器，一个是察看结果树（View Result Tree），右击线程组 -> Add -> Listener（监听器）-> View Result Tree（察看结果树）

一个是聚合报告（Aggregate Report），右击线程组 -> Add -> Listener（监听器）-> Aggregate Report（聚合报告）

下面运行完成之后再简单解释这两个监听器的作用

第五步：运行一下

到目前为止，脚本就全写好了，我们来运行下，如何看下测试的结果

点击启动之后，脚本就会执行，在“察看结果数”界面会看到我们发送的请求的具体信息和响应数据。

在实际的应用中，建议勾选“仅日志错误”，因为运行的请求太多时，如果全都显示，系统容易崩溃，且我们比较关心的是错误的结果。

聚合报告会显示很多详细信息，请求数量，99响应时间，错误率以及吞吐等。详细的解释请参看《JMeter 聚合报告》（ http://www.cnblogs.com/jackei/archive/2007/01/17/623166.html）。