**一、建立一个测试计划(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
- 第一章-测试理论
- 1.1软件测试的概念
- 1.2测试的分类
- 1.3软件测试的流程
- 1.4黑盒测试的方法
- 1.5AxureRP的使用
- 1.6xmind,截图工具的使用
- 1.7测试计划
- 1.8测试用例
- 1.9测试报告
- 2.0 正交表附录
- 第二章-缺陷管理工具
- 2.1缺陷的内容
- 2.2书写规范
- 2.3缺陷的优先级
- 2.4缺陷的生命周期
- 2.5缺陷管理工具简介
- 2.6缺陷管理工具部署及使用
- 2.7软件测试基础面试
- 第三章-数据库
- 3.1 SQL Server简介及安装
- 3.2 SQL Server示例数据库
- 3.3 SQL Server 加载示例
- 3.3 SQL Server 中的数据类型
- 3.4 SQL Server 数据定义语言DDL
- 3.5 SQL Server 修改数据
- 3.6 SQL Server 查询数据
- 3.7 SQL Server 连表
- 3.8 SQL Server 数据分组
- 3.9 SQL Server 子查询
- 3.10.1 SQL Server 集合操作符
- 3.10.2 SQL Server聚合函数
- 3.10.3 SQL Server 日期函数
- 3.10.4 SQL Server 字符串函数
- 第四章-linux
- 第五章-接口测试
- 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常见的问题
- 第六章-性能测试
- 6.1 性能测试理论
- 6.2 性能测试及LoadRunner简介
- 第七章-UI自动化
- 第八章-Maven
- 第九章-测试框架
- 第十章-移动测试
- 10.1 移动测试点及测试流程
- 10.2 移动测试分类及特点
- 10.3 ADB命令及Monkey使用
- 10.4 MonkeyRunner使用
- 10.5 appium工作原理及使用
- 10.6 Appium环境搭建(Java版)
- 10.7 Appium常用函数(Java版)
- 10.8 Appium常用函数(Python版)
- 10.9 兼容性测试