2.jmeter使用

最新推荐文章于 2024-06-03 09:00:00 发布

qq_36227329

最新推荐文章于 2024-06-03 09:00:00 发布

阅读量973

点赞数 1

分类专栏： python测试开发笔记文章标签： python

本文链接：https://blog.csdn.net/qq_36227329/article/details/128101652

版权

python测试开发笔记专栏收录该内容

40 篇文章 1 订阅

订阅专栏

3. JMeter基础

3.1 简介

Apache JMeter 是 Apache 组织开发的基于 Java 的压力测试工具。用于对软件做压力测试，它最初被设计用于 Web 应用测试，但后来扩展到其他测试领域。它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器，等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter 能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter 允许使用正则表达式创建断言。
Apache jmeter 可以用于对静态的和动态的资源（文件，Servlet，Perl 脚本，java 对象，数据库和查询，FTP 服务器等等）的性能进行测试。它可以用于对服务器、网络或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。你可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。

3.2 为什么选择 JMeter

开源许可: Jmeter 是完全免费的，并提供了源码可供自定义开发
图形界面模式：提供了方便的图形界面来编辑和开发测试脚本
平台无关：可以轻易在 windows、linux、mac 上运行
多线程框架：通过线程组，能够轻易的设置不同测试的并发用户。
图形测试结果：提供了图表、表格、树、文件等格式的结果显示。
易于安装：jmeter 不需要安装，下载解压即可用。
高扩展性：jmeter 支持用户自定义测试脚本，同样还提供了各种插件。
多测试类型支持：支持性能测试、分布式测试、功能测试
仿真模拟：支持多用户并发测试
多协议支持：支持 http、jdbc、ldap、soap、jms、ftp 等等协议
录制&回放：支持用 badboy 或 jmeter 录制，不过笔者从来不用该模式，纯手工最佳。
脚本测试：jmeter 支持 beanshell 和 selenium

缺点

使用JMeter无法验证JS程序，也无法验证页面UI，所以要须要和Selenium配合来完成Web2.0应用的测试

3.3 JMeter启动和目录结构

1.启动

使用jmeter必须jdk大于等于1.8版本验证在终端中输入 Java —version 及 java看是否成功

JDK — JAVA开发工具包

JRE — JAVA运行时环境

JVM — JAVA虚拟机

JDK JRE JVM三者关系：https://www.cnblogs.com/java-lzx/p/11641610.html

然后直接解压jmeter压缩包进入bin目录点击 jmeter.bat

jmeter官网地址 http://jmeter.apache.org/download_jmeter.cgi

3.4 基本页面布局

1.主页面布局

JMeter的主界面布局分为标题栏、菜单栏、工具栏、树形标签栏和内容栏
标题栏：主要显示JMeter版本。
菜单栏：全部的功能的都包含在菜单栏中。
工具栏：工具栏中的按钮在菜单栏都可以找到，工具栏就相当于菜单栏常用功能的快捷按钮
树形标签栏：树形标签栏通常用来显示测试用例（计划）相关的标签。
内容栏：配合树形标签栏显示，树形标签中点击哪个标签，内容栏中就显示相应的内容和操作。

3.Test Plan(测试计划)

作用：

测试所需要的【组件】都是基于测试计划(测试计划名称可以自定义)添加；
测试所有组件的设置与执行都基于测试计划(只作用于该测试计划)；
测试计划就类似一个容器
组件：完成指定功能代码段的封装；

配置：

独立运行每个线程组：

进程：是每个正在运行的应用程序。
线程：按照进程的指令去执行指定的代码。
线程组（多线程）：多个线程的组合。
线程组（多线程）的执行顺序是并行的。 
勾选：让本次测试计划中所有线程组保持从上到下顺序执行

Add directory or jar to classpath：

加载第三方jar包；比如：测试数据库时使用，加载数据库驱动jar包。

一般我们不需要改变，直接用默认的

4.thread group(线程组)

   1) thread group(线程组)
   2) setup thread group【特殊线程组】  
   3) teardown thread group【特殊线程组】

作用:

就是用来设置性能测试的运行场景的(执行脚本的线程数，循环次数)
所有的常见请求相关组件必须是在线程组下面才能创建，不能直接在测试计划下面创建

线程属性

  - 线程数：虚拟用户数
  - Ramp-Up Period(in serconds)：启动虚拟全部用户数所需要的时间
  - 循环次数 ：指定次数或勾线永远
  - 调度器：勾选后，调度器配置才能使用；

调度器配置

 调度器:有时候我们并不希望我们的脚本立即开始运行，而是在特定时段运行，这就需要用到调度器。调度器有持续时间&启动延迟和启动时间&结束时间两种组合。调度器要先勾选后才会生效，而且需要将循环次数设置为永远，否则当运行次数达到循环次数后，脚本会立即停止，持续时间和结束时间不再生效。
 - 持续时间（秒）：设置脚本压测持续时间
  - 启动延迟（秒）：启动延迟时间

3.5 线程组下常用的元件

1. 元件的概念和分类

概念：相同类似功能组件的集合称之为元件

线程组下的元件有：
   1. 逻辑控制器  
        if控制器【If Controller】---业务场景设计
        吞吐量控制器【Throughput Controller】--业务场景设计
        循环控制器【Loop Controller】
        仅一次控制器【Once Only Controller】
   2. 配置元件  
        csv数据文件设置【CSV Data Set Config】
        HTTPcookie管理器【HTTP Cookie Manager】---自动管理cookie
        HTTP请求默认值【HTTP Request Defaults】
        计数器【Counter】
        jdbc连接配置【JDBC Connection Configuration】
        用户定义的变量【User Defined Variables】
   3. 定时器  
           固定定时器【Constant Timer】--思考时间
        高斯随机定时器【Gaussian Random Timer】--思考时间
        同步定时器【Synchronizing Timer】--集合点
   4. 前置处理器  
           用户参数【User Parameters】--参数化
   5. Sampler  (取样器)
        HTTP(S)采样器【HTTP Request】
        调试采样器【Debug Sampler】--用于调试
        jdbc采样器【JDBC Request】
   6. 后置处理器  
          json提取器【JSON Extractor】---关联
        正则表达式提取器【Regular Expression Extractor】--关联
   7. 断言  
       响应断言【Response Assertion】
       json断言【JSON Assertion】
   8. 监听器
        查看结果树【View Results Tree】
        汇总报告【Summary Report】
        聚合报告【Aggregate Report】
        断言结果【Assertion Results】
        活跃用户数【jp@gc - Active Threads Over Time】
        吞吐量【jp@gc - Bytes Throughput Over Time】
        HPS每秒钟点击率【jp@gc - Hits per Second】
        资源收集器【jp@gc - PerfMon Metrics Collector】
        RT响应时间【jp@gc - Response Times Over Time】
        TPS事务处理能力【jp@gc - Transactions per Second】
   9. 测试片段
   我们这里只学重要的、常用的

正常来说，应该开始按照顺序一个组件一个组件的进行讲解。
但是每个组件都不能独立执行。都需要多个组件进行配合，才能够解决实际问题。
所以我们会按照JMeter主要解决的问题点来讲解组件。Jmeter的脚本本质上就是由不同的组件构成

2.各大元件中常用的重点组件

2.1 取样器（sample)

就是发送请求的配置组件选项,里面包含了常见的请求类型

1. HTTP请求常见的HTTP协议的请求组件

1. 名称：本属性用于标识一个取样器，建议使用一个有意义的名称。
2. 服务器名称或IP ：HTTP请求发送的目标服务器名称或IP地址。
3. 端口号：目标服务器的端口号，默认值为80 。
4. 协议：向目标服务器发送HTTP请求时的协议,可以是http或者是https ,默认值为http 。
5. 方法：发送HTTP请求的方法，可用方法包括GET、POST、PUT、DELETE。
6. Content encoding ：内容的编码方式，默认值为iso8859；一般设置【UTF-8】
7. 路径：目标URL路径（不包括服务器地址和端口）
8. 同请求一起发送参数

1. 名称：本属性用于标识一个取样器，建议使用一个有意义的名称。
2. 服务器名称或IP ：HTTP请求发送的目标服务器名称或IP地址。
3. 端口号：目标服务器的端口号，默认值为80 。
4. 协议：向目标服务器发送HTTP请求时的协议,可以是http或者是https ,默认值为http 。
5. 方法：发送HTTP请求的方法，可用方法包括GET、POST、PUT、DELETE。
6. Content encoding ：内容的编码方式，默认值为iso8859；一般设置【UTF-8】
7. 路径：目标URL路径（不包括服务器地址和端口）
8. 同请求一起发送参数

java与httpclient4的区别：
Java：选择压测时，链接是复用的（代码中的http调用都加了连接池）
httpclient4：压测时，每请求一次都创建一个新的链接，（jmeter5.0以前默认关闭了连接复用，5.0上是打开的：即每请求一次都会创建一个新的链接）
从JMeter 5.0开始，当使用默认的HC4实现时，JMeter将在每个线程组迭代时重置HTTP状态（SSL状态+连接）。如果您不想要此行为，请设置httpclient.reset_state_on_thread_group_iteration = false
所以httpclient4 在连接复用设置打开的情况下，压测结果与java的是不一样的，因为java复用链接，httpclient4每次连接都会重新建立tcp连接，如果httpclient4吞吐量过低，需要考虑网络带宽的限制
java实现适合压榨性测试，httpclient4适合真实场景的模拟

2.2 监听器（Listener）

(用来查看请求结果的一些组件)

1 察看结果树

    1. 文件名：存放服务器响应后的状态信息； 
    2. 取样器结果：服务器响应的信息头信息；比如：响应代码，响应数据大小
    3. 请求：查看向服务器请求时的信息；比如：请求地址、方法、数据等
    4. 响应数据：查看服务器响应的数据；比如：获取资源时，返回的JSON数据

2.3 断言（Assertions)

(就是对脚本执行结果进行断言)

1.响应断言

Apply to 应用范围

关于应用范围，我们大多数勾选“main sample only” 就足够了，因为我们一个请求，实质上只有一个请求。但是当我们发一个请求时，可以触发多个服务器请求，类似于ajax那种，那么就有main sample 和 sub-sample之分了。此外，对于有重定向的请求，并且勾选了“跟随重定向”，那么这两个请求都是 sub-sample，重定向后的请求（第二个请求）就是main-sample
测试字段
- 响应文本: 服务器响应文本，一般普通http响应，都勾选这个。
- 响应代码：http响应代码，如101,200,302,404,501等。但当我们要验证404,501等http响应代码时，需要勾选“ ignore status”。因为当http 响应代码为400,500时，jmeter默认这个请求时失败的。
- url样本：是对sample的url进行断言。如果请求没有重定向（302），那么就是这个就是请求url。如果有重定向（且跟随重定向，那么url就包含请求url 和重定向url
- 响应信息：http响应代码对应的响应信息，例如：OK, Found
  
  HTTP/1.1 200 OK
  HTTP/1.1 302 Found
- Document(Text)：一切Apache Tika 支持服务器响应，包括文本响应，还支持 PDF, Office, Audio, Video formats。jmeter会用Apache Tika 去解析服务器响应内容，会很耗内存，而且也很容易解析失败。所以一般普通http请求，不要选择这个。
模式匹配规则
- 包括：返回结果包括你指定的内容，支持正则匹配
- 匹配： 相当于 equals 。当返回值固定时，可以返回值做断言，效果和equals相同。支持正则匹配。用正则表达式匹配返回结果，但必须全部匹配。即正则表达式必须能匹配整个返回值，而不是返回值的一部分
- Equals : 返回结果与你指定断言完全一致
- SubString：与 “包括”差不多，都是指返回结果包括你指定的内容，但是subString不支持正则字符串

2.Json断言

Assert JSON Path exists：

需要断言的 JSON 表达式
- $ 表示返回结果 []表示下标 [*]表示匹配任意一个 .键名表示获取那个键
**Additionally assert value：**如果要根据值去断言，请勾选
**Match as regular expression：**如果要根据正则表达式去断言，请勾选
**Expected Value：**期望值
**Expect null：**如果期望是 null 则勾选
**Invert assertion：**取反

2.4 逻辑控制器（logic controller）

(就是用来控制脚本运行逻辑的)

1.简单控制器(Simple Controller)

是最基本的控制器，对jmeter测试运行没有任何影响，可以将某些请求归集在一个简单控制器中，视为一个模块，使得脚本结构更清晰。

2.循环控制器 (Loop Controller)

在输入框中输入需要循环的次数，控制器下的子项会循环相应的次数。如果勾选了【forever】，那么控制器下的子项会一直运行。

3.事务控制器

4.吞吐量控制器

Total Executions：
    按总执行数控制，即当选中该项时，吞吐量中填写的值就是控制器期望的被执行的最大次数。
    当吞吐量小于等于0时，控制器及其子节点不会被执行。
    当吞吐量为空、字符串时，控制器及其子节点会被执行一次。
    当吞吐量为小数时，控制器会以向下取整的方式被触发执行。<1.9—1、2.322—2>
    当吞吐量的值大于总执行数时，控制器每次都会被触发，直至程序停止运行。
percent executions：
    按百分比执行，即当选中改项时，吞吐量中填写的值为触发执行的百分比<1–100>。
    当吞吐量小于等于0时，控制器及其子节点不会被执行。
    当吞吐量为空、字符串时，控制器及其子节点会被以百分比100%来执行。
    当吞吐量大于100时，控制器及其子节点会被以百分比100%来执行。
    请严格输入1-100之间的数控制百分比  
    吞吐量控制器严格按照请求次数发送请求 如果计算的结果有小数 向下取整

5.仅一次控制器

6.if 控制器

不勾选interpret condition as variable expression
直接输入我们需要判断的表达式即可，判断表达式为真时，执行if控制器下的请求，例如1!=2，则一定会执行下面的http请求。如果是字符串比较不管是否引用变量都需要加引号

勾选“interpret condition as variable expression” 默认勾选
这时expression中不能直接填写条件表达式，需要借助函数将条件表达式计算为true/false，可以借助的函数有_jexl3和_groovy

JMeter元件详解之逻辑控制器：

https://blog.csdn.net/weixin_40365361/article/details/106122251

2.5 前置处理器（Per Processors）

(就是在请求发送之前对请求进行处理)

2.6 后置处理器（Post Processors）

(就是在请求发送之后对响应进行处理)

2.7 定时器（Timer）

(设置思考时间的一些元件)

Jmeter性能测试工具Timer定时器详解 https://blog.csdn.net/qq_36502272/article/details/86748560

2.8 配置元件（config Element）

(就是对请求做一些配置处理的元件，如cookie 请求默认值等)

请求默认值
- 就是将线程组下的请求的重复参数放到请求默认值中，后续的所有请求就不需要重复实现该参数设置，会默认从该元件中获取所需参数值
HTTP Cookie管理器
- jmetetr不会自动关联cookie，需要添加cookie管理期来关联cookie
HTTP信息头管理器
用户定义的变量
jmeter配置元件 https://blog.csdn.net/mu_wind/article/details/92796646?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EOPENSEARCH%7Edefault-13.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EOPENSEARCH%7Edefault-13.control

3. JMeter脚本的组件结构

测试计划自带组件 Jmeter所有的其他类型组件都是必须位于该组件下
- 线程组必选组件通过该组件设置性能测试的运行场景(执行脚本的线程数，循环次数)
  - 取样器 Sample 必选组件即请求，我们要去访问接口需要使用该组件
  - 逻辑控制器可选组件用来控制字脚本的一些执行逻辑
- 其他组件 (配置元件，定时器，前置处理器，后置处理器，断言，监听器)都是辅助组件，服务取样器的
  - 配置元件用来完成一些基础配置工作
    - http信息头管理器用来添加http的信息头
    - http cookie管理器用来实现cookie管理
  - 定时器和时间控制有关的组件
  - 前置处理器运行在请求之前的一些组件
  - 后置处理器运行在请求之后的组件
  - 断言用来实现检查点、断言的组件
  - 监听器日志组件用来管理日志 ——-> 查看请求结果

4. 作用域

作用域是jmeter中，六大辅助组件对于取样器组件的生效规则

定义：辅助组件对于其父级组件，所有同级组件，同级组件的子组件有效

其中：

定时器、前置处理器是运行在作用域内的每一个请求之前。和组件的先后无关，运行次数等于请求的次数
后置处理器、断言是运行在作用域内的每一个请求之后。和组件的先后无关，运行次数等于请求的次数

4.jmeter工具核心知识点

4.1基本结构

线程组
- 取样器(HTTP请求)
  - 响应断言
- 循环控制器
  - 取样器(HTTP请求)
- 查看结果树
- HTTP信息头管理器(管理头部信息)
- HTTP请求默认值(设置端口服务器IP默认)
- HTTPcookie管理器(方便多个请求中cookie共用)

4.2 jmeter 参数化

1.为什么要参数化？

键所对应的值都是写死的，只能手动更改，无法解决大数量测试数据的问题

2.什么是参数化？

概念：根据需求动态获取数据并进行赋值的过程

3.在Jmeter中参数化常用方式

用户参数
- 位置：前置处理器—>用户参数
- 参数化引用格式：${参数名}
用户定义的变量
- 用户可根据需求自定义相应的变量，一般做全局变量使用。不适合参数需求量大时的选择
- 位置：配置元件->用户定义的变量

csv

位置：配置元件->CSV Data Set Config

配置项

1. Filename:文件路径+文件名+后缀名    如：d:/a.txt;
    绝对路径：文件的完整路径
    相对路径：把文件放到jmeter的bin目录下面 然后直接引用即可
2. File Encoding:文件编译字符编码，一般设置utf-8;
3. Vaiable Names:读取参数后保存的变量名称;也可以不定义直接用文件中的变量名称
4. Delimiter:如文件中使用的是逗号分隔，则填写逗号；如使用的是TAB，则填写\t;
5. 变量名称：有几个字段就建几个变量名 后期脚本文件 ${变量名} 进行引用
6. 是否允许带引号 ： 如果文件中字段值带引号 只能是双引号
7. 线程共享模式：
    所有现场：csv配置文件数据被所有线程组共享
    当前线程组：csv配置文件数据只被当前线程组的所有线程共享
    当前线程：csv配置文件相对于复制同数量线程数的文件  每个线程使用自己的csv数据

参数化引用格式：${参数名}

函数
- 位置：Ctrl+Shift+F1 或工具栏倒数第二个记事本图标

作业：

模拟十个用户操作  用户先登录一次    然后随机访问 员工信息 页面 或者 学员信息页面 或者系统版本页面  每个操作间隔 1-2秒  持续时间30s模拟20个用户（用户名读取csv文件） 登陆

4.3 Jmeter 集合点

1.为什么要设置集合点？

需求对woniuboss登录这个接口进行20个用户【同时】请求登陆操作。
如果我们以前学的
1. 设置线程组循环次数为：20，解决不了需求问题
2. 设置线程组线程数量为：20，同样解决不了问题

2.什么是集合点

集合点用以同步虚拟用户，以便恰好在同一时刻执行任务。

3. jmeter中集合点的使用方式

位置：定时器->同步定时器 Synchronizing Timer

参数含义

1. Number of Simulated Users to Group by:
    集合多少用户后再执行请求（也就是执行的线程数）
2. Timeout in milliseconds：超时时间(毫秒)
    1) 设置为0，无限等待，直到达到集合点设置的线程数。
    2) 设置指定时长，如果到达指定时长，集合点数量未到达，集合多少用户释放多少用户数量。
两个都设置的话则哪一个先满足就执行

4. 使用场景

电商高并发的接口任务
一般我们不会特地给每个接口去设置

4.4 jmeter 事务

1. jmeter中事务的使用方式

位置：逻辑处理器->事务控制器
参数含义

Generate parent sample：将事务控制器作为一个父样本执行include duration of timer and pre-post processors in generated sample：是否包含时间的计时器和前后处理器耗用的时间。

作业：

模拟 两个用户操作，第一步 都是用户登陆， 然后  第一个用户 实现 新增员工事务： 访问首页，点击人事管理下员工信息，点击新增 一个用户   第二个用户 实现  新增学员事务：访问首页，点击资源管理下的培训资源 然后新增一个学院   整个 流程循环10次

4.5 Jmeter 关联

1. 为什么要设置关联？

需求:第一次获取cookie值，第二次把获取的值作为参数名的参数值附加请求中。

2.什么是关联？

概念：从上一条请求中获取数据，使用在下一条请求中的过程。

3.Jmeter关联中常用方式

正则表达式提取器

位置：后置处理器->正则表示式提取器

1. 引用名称：下一个请求要引用的参数名称，如填写title，则可用${title}引用它。
2. 正则表达式：制定规则的公式
   公式模板：前缀识别()后缀识别()：括起来的部分就是要提取的数据。
       1) .：匹配任何字符串。
       2) +：一次或多次。
       3) ?：在找到第一个匹配项后停止。
       4) *：匹配规则内所有字符串
3. 模板：$数字$ 格式；$1$表示解析到的第1个值；如果匹配有2个值，第二个值$2$，以此例推
4. 匹配数字：(匹配出来可能有多个结果)1代表全部取值，0代表随机取值，通常情况下填1 
5. 缺省值: 匹配不到的默认值

json提取器

Variable names：保存的变量名，后面使用${Variable names}引用JSON Path  expressions：调试通过的json path表达式Match Numbers：匹配数字（0代表随机，1代表第一个，-1代表所有）Default Values：找不到时默认值，一般设置为NOT FOUNDCompute concatenation var(suffix_ALL)：是否统计所有，即将匹配到的所有值保存，名为“变量名_ALL”

作业：

模拟 管理员用户 登陆，然后在人事管理员工信息中添加员工（员工名使用csv参数化），其他字段使用函数随机生成。
添加完成之后 去系统管理用户管理界面 查询该用户，然后给用户授权(讲师权限，班主任权限)   循环十次
提示：参数化文件格式：
WNCD600,
WNCD601,
WNCD602,

4.6 Jmeter 函数

__counter 统计函数

第一个参数：
   1) TRUE:  每个用户有自己的计数器，可以用于统计每个线程各执行了多少次
   2) FALSE: 使用全局计数器，可以统计出这次测试共运行了多少次用

__Random随机函数随机生成一个指定范围内的数值
__Randomdate 随机生成一个指定格式日期
__Randomstring 从给定的字符随机生成指定长度的字符串
__jex13 返回布尔值常配合 if或者while 控制器
__threadNum 获取当前线程编号
__setProperty 把指定数据设定成Jmeter全局属性
__property 获取Jmeter中属性值如果函数找不到属性值，而又没有提供默认值，则它会返回属性的名称
__P 是一个简化版的__property。不同于函数__property，本函数没有提供选项用于设置保存属性值的变量

__V 执行变量名表达式，并返回执行结果用于嵌套变量的场景

举个栗子，当前有两个变量 A1、A2，还有一个 N = 1
 ${A1} ：可以正常引用
 ${A${N}} ：不可以这样使用，因为不支持函数嵌套
 ${__V(A${N})} ：可以这样使用， A${N}  会变成 A1 ，__V 函数会返回 A1

5. jmeter拓展知识点

5.1 jmeter 图形监视器扩展插件下载及使用

1.安装步骤

去官网 https://jmeter-plugins.org/install/Install/ 下载最新的jar包文件
然后放到Jmeter的Lib目录下面的ext目录
重启Jmeter，在选项中应该就能看到plugins manager
性能监控插件下载地址：https://jmeter-plugins.org/wiki/PerfMonAgent/
解压到要监控的服务器任意目录
然后 Windows启动startAgent.bat Linux启动startAgent.sh 默认启用4444端口进行监听

2. 客户端监控系统资源

在监听器中使用 jp@gc - PerfMon Metrics Collector
Host/IP：填写服务器IP地址
Port：默认4444(4444为启动服务器监听服务程序时的端口号)
Metric to collect：选择要收集的指标（CPU、内存、网络、磁盘即 CPU memory network disk）

5.2 非GUI运行常用命令参数

-n ：以非GUI形式运行Jmeter
-h ：显示帮助文档
-t ：指定要运行的脚本路径
-j ：保存运行产生的日志文件
-l ：运行结果保存路径（.jtl）,此文件必须不存在
```
  1) .jtl
  2) .txt
  3) .csv
  4) .无后缀
```
-e ：在脚本运行结束后生成html报告
-o ：保存html报告的地址, 此文件必须不存在

无日志文件生成测试报告
jmeter -n -t <test JMX file> -l <test log file> -e -o <Path to output folder>
jmeter -n -t E:\test.jmx -l testLog -e -o ./output/report
使用已有的jtl日志文件或csv日志文件生成
jmeter -g <log file> -o <Path to output folder>
jmeter -g E:\resultt.jtl -o ./outputreport

-r ：在Jmeter.properties文件内定义的所有远程主机上运行测试。
-R ：使用指定的远程主机名和端口号进行测试，这样会覆盖并忽略掉Jmeter.properties文件中的设置。
-X ：在非GUI模式运行时，运行完测试自动退出远程主机，即断开连接。

5.4 JMeter测试WebSocket协议

在“Plugin Manager”中安装“WebSocket Samplers by Peter Doornbosch”。
在线程组中添加一个单次通信的“WebSocket request-response Sampler”抽样器，并输入相应的WebSocket服务器地址以及要发送的数据，如图。
运行上述脚本，可以在察看结果树中看到对应的请求和响应
但是这种单次通信仅适用于测试其联通性，并不能真正用于现实中，因为这本身违背了WebSocket长连接的作用和价值。所以在真实情况下，我们需要单独分别添加：WebSocket Open Connection用于建立连接，WebSocket Single Write Sampler用于发送请求，WebSocket Single Read Sampler用于接收响应，最后执行完成后使用WebSocket Close关闭连接。而对于Write/Read这对组合抽样器，通常建议将其放在循环控制器中，以便于模拟多次通信的过程。如图：

5.5 Jmeter连接数据库

下载MySQL的JDBC驱动程序，文件名为：MySQL-connector-java-5.1.16.jar，并保存于JMeter/lib/ext文件中，重启JMeter使该库生效。

在线程组中添加一个“JDBC Connection Configuration”组件，并输入相应的数据库连接信息，并在“Variable Name for created pool”中输入“MyJDBC”(自定义一个变量名)作为后续请求使用该连接的纽带：

Variable Name： 变量名称，需要变量名绑定到池。需要唯一标识。与JDBC取样器中的相对应，决定JDBC取样的配置。简单理解就是在JDBC request的时候确定去哪个绑定的配置。
MaxNumber of Connection： 数据库最大链接数
PoolTimeout： 数据库链接超时，单位ms
Idle Cleanup Interval （ms）： 数据库空闲清理的间隔时间，单位ms
Auto Commit：自动提交。有三个选项，true、false、编辑（自己通过jmeter提供的函数设置）
Transaction Isolation：   事务间隔级别设置，主要有如下几个选项：（对JMX加解密）

添加“JDBC Request”请求，并输入一条正确的SQL语句，如图：

   Variable Name：数据库连接池的名字，需要与JDBC Connection Configuration的Variable Name Bound Pool名字保持一致
   Query：填写的sql语句
   Parameter valus： 引用用户定义的其他变量 填充sql语句中的参数值
   Parameter types：参数类型，可参考：Javadoc for java.sql.Types
   Variable names：保存sql语句返回结果的变量名
   Result variable name：创建一个对象变量，保存所有返回的结果
   Query timeout：查询超时时间
   Handle resultset：定义如何处理由callable statements语句返回的结果
   拓展:
   https://www.cnblogs.com/istart/p/11226270.html
   如果要更新数据  Query Type应选择“Update Statement”
   如果要执行 多条SQL语句，Quer Type一定要选择 Callable statement,使用Callablestatement时，一次可以包含多个SQL

6.1 基于Web前端的性能测试分析

1.概述

WEB系统主要分为客户端和服务器端。客户端的主要载体就是浏览器，相对比较简单，而服务器端则架构要复杂得多，使用到的技术也更加复杂。但是，最终用户在使用的时候是一直在与浏览器打交道，用户不关心我们的服务器端到底使用了怎么样的技术和架构。那么，做为一个软件测试人员，我们也应该站在一个用户的角度来从WEB前端来进行系统测试与分析，辅助找出一些系统的问题，提升用户使用体验。WEB前端测试分析的意义也就在此，可以以相对更小的代价，更快的速度来对系统可能存在的问题进行分析，如果真正能做好前端的分析，对用户体验和性能提升方面会有很大的正面影响。当然，最好是前端分析与后端分析相结合进行，这样才能对系统有一个全面的了解。

2.案例分析

1. 对百度首页进行前端分析

从上述监控结果中，我们可以得到如下的初步结论：

当输入http://www.baidu.com访问百度搜索引擎时，发送了一共15个请求，0个错误，总共传输了75.49KB的数据。
整个页面共消耗时间1.6秒，页面渲染的时间为877毫秒。此处要注意的是，这里的1.6秒只是每一个请求的响应时间的简单总和，1.82秒的加载时间才是页面的整体响应时间。由于浏览器都是多线程处理的，同时可以处理多个请求，有可能请求A消耗0.5秒，请求B消耗0.8秒，总消耗时间为1.3秒，但是真实的用户能感知到的响应时间有可能是0.9秒。
消耗时间最大的请求为下载一个JS的脚本，所花时间为1.18秒，当然，经过对时间的排序，我们也可以看到消耗时间最少的等各种情况（注：具体时间视网络状况将有所差异）。一个10KB的JS脚本，怎么会花费1.18秒这么长时间呢？这就需要进行更为具体的分析了，到底这1.18秒都花在了什么地方。后面我们再来介绍详细的分析。
所有的响应均是2xx和3xx，没有出现异常响应。

2. 对新浪首页进行前端分析

我们能够看到，新浪这个首页监控到的数据很夸张。总共捕获到了693个请求，共传输了5.02MB数据，页面整体加载时间为52.34秒，页面渲染时间为23.2秒。排名前五的请求，都消耗了很长的时间，而其文件大小都是10KB以内。毫无疑问，我们可以初步估计，这些时间要么消耗在了网络传输上，要么消耗在了服务器端处理上。如果消耗在了网络上，那么网络肯定因为产生了堵塞才会导致需要10秒钟来传输一个10KB的文件。后面我们可以继续做深入的分析

3.关于页面响应时间

有一个问题我们必须要理解，比如上面的新浪首页的响应时间达到了52.34秒，但是实际上我们访问新浪首页的时候并不会一直等待52秒才会看到页面，而是5秒钟内就可以看到首页了（专业术语叫做First Impression，第一印象），用户体验还不错。这是为什么呢？其实很多门户网站的首页内容是非常多的，我们从滚动条的长短就能看出来，但是页面的加载使用的是局部加载的方式（这得归结于XHTML和渲染引擎的功劳），这样可以保证用户先看到一部分内容，然后再继续加载剩余内容。

所以，在进行性能测试的过程中，我们不能武断地将响应时间当成用户体验的关键指标，很多时间用户只关心第一屏内容，只要能快速看到这一部分内容，即使整体响应时间会很长，但是用户体验并不会变差。这一点是我们在进行性能测试时，对响应时间的评估容易出现误判的情况。

3.优化方案

3.1 Web前端分析之时间分析

一个典型的网站访问过程由如下几个时间段组成：

(1) 浏览器预处理时间：主要指浏览器查找本地缓存资源和等待网络连接可用的时间。通常由于浏览器访问网站时线程数量是有限的，比如IE浏览器的并发线程数量默认为4，所以如果请求数量过多时一定会出现某些请求要等待线程资源的情况，通常这是预处理花时间的最主要原因。

(2) DNS解析：DNS Lookup，将域名解析成IP地址所花的时间。通常在浏览器打开的整个过程中针对同一个域名的DNS解析只处理一次，后续将直接读取其缓存数据。所以这一部分时间不会对整体响应时间有太大的影响。

(3) 建立TCP连接：客户端与服务器端进行三次握手建立连接这一过程所花的时间。这也是我们为什么需要使用长连接的原因，这样可以减少建立连接的次数，提升效率。

(4) 等待服务器响应：TTFB的意思是Time to First Byte，即从请求发送给服务器开始，到接收到服务器响应的第一条内容所经历的时间。通常情况下，这个时间是由两部分构成：请求和第一个响应的传输，以及服务器端的处理时间。但是基本上来说，请求和响应的第一个字节传输所花的时间都会很少，所以我们可以近似地认为TTFB就是服务器端的处理时间。

(5) 响应内容的下载时间：从接收到服务器响应的第一个字节开始计时，到整个响应的内容完成下载所经历的时间。这一部分时间受网络带宽的影响最大。也同时可以从客户端地视角来评估服务器端的网络带宽传输情况（当然，前提是客户端的带宽是够用的）。

，即使整体响应时间会很长，但是用户体验并不会变差。这一点是我们在进行性能测试时，对响应时间的评估容易出现误判的情况。

3.优化方案

3.1 Web前端分析之时间分析

一个典型的网站访问过程由如下几个时间段组成：

前端性能优化方案 https://www.jianshu.com/p/b0fd5d87e295

qq_36227329

关注

1
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
2.jmeter使用

概念：根据需求动态获取数据并进行赋值的过程集合点用以同步虚拟用户，以便恰好在同一时刻执行任务。概念：从上一条请求中获取数据，使用在下一条请求中的过程。WEB系统主要分为客户端和服务器端。客户端的主要载体就是浏览器，相对比较简单，而服务器端则架构要复杂得多，使用到的技术也更加复杂。但是，最终用户在使用的时候是一直在与浏览器打交道，用户不关心我们的服务器端到底使用了怎么样的技术和架构。
复制链接

扫一扫