**一、建立一个测试计划(test plan)**
之前有说过,jmeter打开后会自动生成一个空的test plan,用户可以基于该test plan建立自己的test plan
一个性能测试的负载必须有一个线程组完成,而一个测试计划必须有至少一个线程组。添加线程组操作如下:
在测试计划处右键单击:添加→Threads(Users)→线程组
![](https://img.kancloud.cn/f6/e9/f6e93223671b50f2e353d68592a586d1_551x79.png)
每个测试计划都必须包含至少一个线程组,当然,也可以包含多个,多个线程组的运行在jmeter中采用的是并行的方式,即:同时被初始化且同时执行其下的sampler
![](https://img.kancloud.cn/4a/75/4a75cef3bcdfa91287e6f9c205817b3c_722x318.png)
线程组主要包含三个参数:
**线程数:**虚拟用户的数量,一个线程指一个线程或者进程
**Ramp—Up Period(in seconds):**准备时长。设置的线程数需要多久全部启动,比如上图,线程数为6000,启动时间为60,那么需要60S内启动6000个线程;
**循环次数:**每个线程发送请求的次数。如上图,6000个线程,每个线程发送1次,如果勾选了永远,那么它将永远发送下去,直到停止脚本;
设置合理的线程数对能否达到测试目标有决定性影响。比如在本例中,如果线程数太少,则无法达到设定的要求;
另外,设置合理的循环次数也很重要,除了给定的设置循环次数和永远,还可以通过勾选**调度器**,设置开始和结束时间来控制。
**二、添加sampler**
添加完线程组后,在线程组上右键单击:添加→Sampler→SOAP/XML-RPC Request(SOAP/XML-RPC:都是报文中不同的数据格式)
![](https://img.kancloud.cn/e1/ef/e1ef10905379aef95133b8cf193af7ea_547x579.png)
前面说过,取样器(Sampler)是与服务器进行交互的单元。一个取样器通常进行三部分的工作:向服务器发送请求,记录服务器的响应数据和记录相应时间信息
![](https://img.kancloud.cn/da/95/da951ba6456d599401116982495e9147_1211x756.png)
这里解释一下,因为微信H5界面的会员注册,向微信端发送的是xml文件,所以这里我选择的取样器是SOAP/XML-RPC Request
上面的图中,选择SOAP/XML-RPC Request取样器,然后URL一栏输入我们需要进行加压的URL
然后默认选项,Use KeepAlive的意思是:保持连接,这个是http协议报文中的一个首部字段,之前的关于HTTP协议的随笔写过
下面的SOAP/XML-RPC Data输入需要发送的xml格式的文件就行(也可以导入xml文件的文件夹进行读取),下面是xml和json的区别:
![](https://img.kancloud.cn/f2/7c/f27cee263cfeb4199e7c124d35051362_691x146.png)
添加完取样器和具体的地址参数之后,接下来就是添加监听器,对测试结果进行获取
**三、添加监听器**
在线程组上右键单击,添加你需要的监听器,一般常用的就是结果树和聚合报告
![](https://img.kancloud.cn/97/39/973934049bc19e63269f349f25843273_616x618.png)
添加后启动线程组进行测试,等线程执行完成后,根据结果树中的请求和响应结果(成功或者失败)就可以分析我们的测试是否成功,以及根据聚合报告结果来确认我们这次确认是否达成了预期结果。
**四、聚合报告简析**
![](https://img.kancloud.cn/47/e4/47e425276224b07dc4b634199a9d0aa3_866x192.png)
**ggregate Report:** ****JMeter**** 常用的一个 Listener,中文被翻译为“聚合报告”
**Label:**每个 JMeter 的 element(例如 HTTP Request)都有一个 Name 属性,这里显示的就是 Name 属性的值
**#Samples:**表示你这次测试中一共发出了多少个请求,如果模拟10个用户,每个用户迭代10次,那么这里显示100
**Average:**平均响应时间——默认情况下是单个 Request 的平均响应时间,当使用了 Transaction Controller 时,也可以以Transaction 为单位显示平均响应时间
**Median:**中位数,也就是 50% 用户的响应时间
**90% Line:**90% 用户的响应时间
Note:关于 50% 和 90% 并发用户数的含义
**Min:**最小响应时间
**Max:**最大响应时间
**Error%:**本次测试中出现错误的请求的数量/请求的总数
**Throughput:**吞吐量——默认情况下表示每秒完成的请求数(Request per Second),当使用了 Transaction Controller 时,也可以表示类似 ****LoadRunner**** 的 Transaction per Second 数
**KB/Sec:**每秒从服务器端接收到的数据量,相当于LoadRunner中的Throughput/Sec
- 接口测试
- 5.1 postman 接口测试简介
- 5.2 postman 安装
- 5.3 postman 创建请求及发送请求
- 5.4 postman 菜单及设置
- 5.5 postman New菜单功能介绍
- 5.6 postman 常用的断言
- 5.7 请求前脚本
- 5.8 fiddler网络基础及fiddler简介
- 5.9 fiddler原理及使用
- 5.10 fiddler 实例
- 5.11 Ant 介绍
- 5.12 Ant 环境搭建
- 5.13 Jmeter 简介
- 5.14 Jmeter 环境搭建
- 5.15 jmeter 初识
- 5.16 jmeter SOAP/XML-RPC Request
- 5.17 jmeter HTTP请求
- 5.18 jmeter JDBC Request
- 5.19 jmeter元件的作用域与执行顺序
- 5.20 jmeter 定时器
- 5.21 jmeter 断言
- 5.22 jmeter 逻辑控制器
- 5.23 jmeter 常用函数
- 5.24 soapUI概述
- 5.25 SoapUI 断言
- 5.26 soapUI数据源及参数化
- 5.27 SoapUI模拟REST MockService
- 5.28 Jenkins的部署与配置
- 5.29 Jmeter+Ant+Jenkins 搭建
- 5.30 jmeter脚本录制
- 5.31 badboy常见的问题