本文的方法是如今图形界面下添加好组件，生成jmx脚本文件，而后将jmx文件放到linux环境下用命令行运行脚本，进行性能测试。html
- 用Jmeter进行打压测试
若是能够打开图形界面，则能够参看图形界面的使用教程；
此外，在Linux下用命令行进行测试。
1.1 在图形界面编辑打压测试脚本
参考《Jmeter教程 简单的压力测试》：http://www.cnblogs.com/TankXiao/p/4059378.htmllinux
其实所谓的脚本文件，就是用图形界面配置好信息后保存的jmx文件，jmx是一个xml格式的文本，能够用来在命令行做为参数执行。apache
如下流程是在《Jmeter教程 简单的压力测试》的基础上根据 Y公司 的测试习惯作得补充和修改：服务器
什么是压力测试
顾名思义：压力测试，就是 被测试的系统，在必定的访问压力下，看程序运行是否稳定/服务器运行是否稳定（资源占用状况）
好比： 2000个用户同时到一个购物网站购物，这些用户打开页面的速度是否会变慢，或者网站是否会奔溃并发
作压力测试的经常使用工具分布式
作压力测试，通常要使用工具， 人工是没办法作的。 最经常使用的工具是LoadRunner, 可是LoadRunner毕竟是收费软件，并且使用上也比较复杂。 如今愈来愈多的人开始使用Jmeter来作压力测试。 免费， 并且使用上很是简单。ide
作压力测试的步骤以下:工具
-
写脚本 或者录制脚本oop
-
使用用户自定义参数性能
-
场景设计
-
使用控制器，来控制 模拟多少用户。
-
使用监听器， 查看测试结果
本文作压力测试的例子
本文举的实例是： 在一台电脑用Jmeter模拟200个用户，同时去使用bing搜索不一样的关键字， 查看页面返回的时间是否在正常范围内。
第一步： 使用CSV Data Set Config 来参数化
首先咱们把测试须要用到的2个参数放在txt文件中，
新建一个data.txt文件，输入些数据， 一行有两个数据，用逗号分隔。
-
启动Jmeter, 会出现以下界面，系统自动添加了一个Test Plan（测试计划），在名称位置能够更改测试计划名称，好比： Bing接口测试样本
- 先添加一个Thread Group (右击 Test Plan(测试计划) -> Add(添加) -> Thread（Users）-> Thread Group（线程组） )；
线程组也能够重命名，好比：Bing 200并发
- 而后在“线程组” 下 添加一个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} （）
-
选择Thread Group 右键 (Add（添加） ->Sampler -> HTTP Request（HTTP 请求）)，
- 须要填的数据以下：
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有些难以理解， 由于如何设置适当的值并不轻易。 首先，假如要使用大量线程的话，ramp-up period 通常不要设置成零。 由于假如设置成零，Jmeter将会在测试的开始就创建所有线程并当即发送访问请求， 这样一来就很轻易使服务器饱和，更重要的是会隐性地增长了负载，这就意味着服务器将可能过载，不是由于平均访问率高而是由于全部线程的第一次并发访问而引发的不正常的初始访问峰值，能够经过Jmeter的聚合报告监听器看到这种现象。
基于一样的缘由，过大的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）。
1.2 在命令行下运行脚本
将1.1中的脚本保存，在编辑是随时能够保存，保存后是一个jmx格式的文件（如图），这个就是要在命令行下运行的脚本（做为参数运行）。
这个脚本文件能够不包含1.1中第四和第五步，便可以不须要添加监听器，运行是在命令行下执行。
进到解压apache-jmeter-2.13的路径下，
执行Jmeter 脚本的命令是：
./bin/jmeter -n -t .jmx文件（脚本） -l .jtl文件（测试运行结果文件）
例：
./bin/jmeter -n -t /home/test/Bing接口测试样本.jmx -l /home/test/Bing接口测试样本.jtl
参数说明：
-n表示以nogui方式运行测试计划
-t表示测试计划，后面跟测试计划名称
-l表示测试结果，后面跟测试结果文件名称
运行后显示以下界面，即成功运行了脚本：
运行结束后，会显示：
显示 ... end of run 即脚本运行结束，在输入的测试运行结果文件的路径下就会出现命令中输入的jtl文件了。
- 查看测试结果
将上一步运行结束后生成的jtl文件传输到可视化图形界面可打开的路径下， 打开可视化图形界面的jmeter
随便新建一个项目，也能够用先用的项目，添加监听器，在监听器界面，点击浏览，选择测试运行的结果文件 .jtl文件，就能够查看结果了。
打开文件后，就会显示文件中的结果，可是如上述给出的命令在linux下获得的jtl文件里只有取样器结果，请求和相应数据为空
一样，在聚合报告中也能够打开jtl文件，查看结果：
备注： 另外，在Linux下咱们有时候但愿线程能够在后台运行，这样咱们关闭当前链接后，线程依然能够运行，这里提供一个将 jmeter命令设置为后台线程的方法。使用setsid命令： setsid bin/jmeter -n -t .jmx文件 -l .jtl文件setsid ./bin/jmeter -n -t .jmx文件 -l .jtl文件有没有 ./ 当前目录的表示符均可以