jmeter简要操作

一、Jmeter安装

下列说明以5.4.3版本为举例版本，对于jdk最低要求为8+

①前置条件（jdk)

若为全局安装则无需配置jdk地址：

具体jdk软件包可以参详：软件版本记录

纠结open/oracle jdk参详：Open/Oracle JDK8 选择困难？

②安装源

参照上图进行搭配下载

二、jmeter编写测试脚本

再次提醒，需要安装jdk。若为安装包安装无需配置，否则需要配置全局JAVA_HOME

1、编写脚本（建议window下编辑）

举例使用window系统举例，以基础性http请求为样例

①基础层级结构

通常脚本进程需要几个点，通常层级代表生效位置，往下辐射

线程组

​ |

采样器

​ |--------------------------|-----------------------------|——————|

​ 配置元素 ------ 前/后置处理器 ----------- 定时器 -------- 监视器

②新建测试脚本

线程组说明

① Threads Group

默认执行的线程组

②setUp Threads Group

默认执行组之前执行的线程组（提前铺路）

③tearDown Threads Group

默认执行组之后执行的线程组（收尾）

1、配置进程数（用户数）

Number of Threads : 模拟进程数/用户数

Ramp-up period： 特定秒启动完所有线程

Loop Count： 循环次数

2、配置请求讯息

这里主要是建议注意配置Content encoding

③数据源配置（可选）

图二中，以$(paramter)格式标记的值数据源可以从额外配置的 config Element内csv去获取

（1）定义cvs格式

实际上就是配置一个excel表格，以csv形式保存

（2）配置cvs配置文件

谨记，cvs编码要检查是否与配置的一致，可以通过记事本查看

Filename： 选择刚刚修改的数据源文件

Variable Names： 这里针对CSV表格内的每一行，对应你变量的值

Ignore first line： 若第一行作了说明，则可以为true来跳开第一行

例如第一行設置Variable Name為 question，則可以在参数处配置${question}来读取CSV内容

④监视器配置（可以安装其他拓展）

用来更好的分析数据，除了默认的几个，其实还可以去获取更多的插件

下载地址： https://jmeter-plugins.org/downloads/old/

下载该插件后解压，包放在jmeter安装目录的\lib\ext路径下，重新启动jemter即可。

以上为当前版本默认自带监视器（基本够用）

（1）View Results Tree （结果树）

仅作调试，实际压测建议关闭，日志多少影响io，导致最终结果受影响（不过还是看日志量而定）

可以用来查看请求过程中的请求头/载体/结果等基本讯息

若需要输出日志

可以勾选单选项选则筛选结果，且选择输出文件位置即可，其中参数可以在configure配置

默认为jtl文件，若需要保存为xml，也需要先configure中设置

（2）Summary Report (汇总报告)

#Samples： 取样器运行次数

Average ：请求（事务）的平均响应时间

Min： 请求的最小响应时间

Max ：请求的最大响应时间

Std. Dev： 响应时间的标准方差

Error % ：事务错误率

Throughput： 吞吐量 也就是TPS

Received KB/sec： 每秒收到的千字节

Sent KB/sec： 每秒发送的千字节

Avg. Bytes： 响应平均流量

（3）Aggregate Report（聚合报告）

聚合报告，记录总请求数、错误率、用户响应时间、吞吐量等

#Samples ： 表示测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里就显示对应的 HTTP Request的执行次数是100

Average ： 平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间

Median ： 50%用户的响应时间

90%Line ： 90%用户的响应时间

Min ： 最少响应时间

Max ： 最大响应时间

Error% ： 出现错误的请求的数量/请求的总数

Throughput ： 吞吐量，默认情况下表示每秒完成的请求数

sent KB/sec ： 每秒接收到的数据量

（4）Backend Listener(后端监听器)

我反正现在没用到，懒了

2、执行测试脚本

-n ：非 GUI 模式

-t ：测试脚本

-l ：记录结果的日志 通常 jtl后缀

-r ：远程执行

-H ：远程执行代理主机

-P ：远程执行的端口号

（1）window

最直接的是直接点击上方执行

命令行：

安装基础目录下

设测试脚本为：test.jmx

 .\bin\jmeter -n -t .\test.jmx -l ./test.jtl

（2）Linux

安装基础目录下

设测试脚本为：test.jmx

Tips: 对应若设置了数据源或输出监视器路径，记得更改相对地址

 .\bin\jmeter -n -t .\test.jmx -l ./test.jtl

三、调试可能遇到的问题

①乱码问题

我们可以通过增加后置处理器来处理

在Script处增加
prev.setDataEncoding("UTF-8")

四、内容补充

0、执行流程描述

整体上，执行过程除了特殊的前后置触发外，基本都是以从上至下执行请求，同时断言、数据源等也按照层级确认生效位置。

我们可以利用执行流程来完美填充一些流程，比如
①B基于A获取的数据，则A执行完后设置数据为全局参数提供给B使用
②A后续的运行基于A得到的会话权限之类

1、断言（Assertions)

通常对值校验的时候用到的一个功能，通常只需要下列几个断言即可

①响应断言

用于针对响应结果作出的断言，决定响应是否为成功响应

整体可以分为三个部分

（1）断言应用层面

断言的作用域，也就是apply to .

其中这里的父子节点通常指代上下关系

1、Main sample and sub-samples ：作用于父节点及对应子节点

2、Main sample only ：仅作用于父节点

3、Sub-samples only ：仅作用于子节点

4、JMeter Variable ：作用于jmeter变量(输入框内可输入jmeter的变量名称【通常就是这个格式：${}】)

（2）判断的元素

作为断言的数据来源选择，也就是 field to test

下属描述的匹配值，也就是Patterns to test

1、Text Response ： 指代响应报文内的数据全文

针对Response body中的内容进行匹配

{"code":0,"msg":"success"}

2、ResPonse Code ：http请求对应的响应码 （此时 Ignore status不生效）

Response headers 中,如下状态码为200，此时就根据这个值去匹配

HTTP/1.1 200 OK
Date: Fri, 11 Mar 2022 02:03:53 GMT
Content-Type: application/json
Transfer-Encoding: chunked

3、Response Message：

Response headers 中,请求状态值,如下状态值为ok，此时就根据这个值去匹配

HTTP/1.1 200 OK
Date: Fri, 11 Mar 2022 02:03:53 GMT
Content-Type: application/json
Transfer-Encoding: chunked

4、Response Headers ：

顾名思义，就是针对响应头（Response headers）进行匹配，如下值都在匹配范围内

HTTP/1.1 200 OK
Date: Fri, 11 Mar 2022 02:09:55 GMT
Content-Type: application/json
Transfer-Encoding: chunked

5、Request Headers （不常用）

针对请求头进行处理匹配

6、Document（text）（不常用）

针对响应数据进行抽取匹配，例如文档等解析为text然后匹配

7、 Ignore status （忽略状态码)

特定情况下不生效，如上述2情况下，主要为了避免状态码影响匹配

（3）匹配规则

1、Contains（支持正则达式）

①符合特定内容

②正则表达式（模糊）

# 统一结果返回值
{"code":0,"msg":"success"}

# 匹配值
success

#响应结果： 成功

2、Matches （支持正则，但全匹配）

只能全匹配结果才可以判断为成功

# 统一结果返回值
{"code":0,"msg":"success"}

#一、 匹配值
success

#响应结果： 失败

#二、 匹配值
{"code":0,.+}

#响应结果：成功

3、Equals（不支持正则，且区分大小写）

需要完全匹配文本才可以断言成功，差一点都不可以

# 统一结果返回值
{"code":0,"msg":"success"}

#一、 匹配值
{"code":0,"msg":"success"

#响应结果： 失败

#二、 匹配值
{"code":0,"msg":"success"}

#响应结果：成功

4、Substring（不支持正则，且区分大小写）

与contains一致，仅仅不支持正则表达式

5、Not（取反匹配规则）

针对上述四点的匹配规则结果取反值

6、Or（或条件匹配）

此时匹配值可以填多个，当且仅当其中一个符合的时候，返回成功结果

②超时断言

（1）断言应用层面

1、Main sample and sub-samples ：作用于父节点及对应子节点

2、Main sample only ：仅作用于父节点

3、Sub-samples only ：仅作用于子节点

（2）超时时长（毫秒级）

Duration in milliseconds ：填写毫秒数，若在时间内则成功，否则失败

③返回实体大小断言

（1）断言应用层面

1、Main sample and sub-samples ：作用于父节点及对应子节点

2、Main sample only ：仅作用于父节点

3、Sub-samples only ：仅作用于子节点

4、JMeter Variable ：作用于jmeter变量(输入框内可输入jmeter的变量名称【就是这个格式：${}】)

（2）筛选字段

1、Full Response ： 整个响应包

2、Response Headers ： 响应头

3、Response Body ： 响应体

4、Reponse Code ：响应状态吗

5、Reponse Message ： 响应信息

④JSON断言

若返回的数据非json格式，直接解析失败

参照响应头 ： Content-Type: application/json

（1）判断样本方式

1、Assert JSON Path exists ： 断言的Json表达式

说白了就是解析后整个json的对应value值

2、Additionally assert value - 如果需要对值进行断言，需要勾选

3、Match as regular expression - 如果使用正则表达式，请勾选

4、Expected Value - 匹配断言或则正则表达式

5、Expect null - 期望为空，勾选

6、Invert assertion (will fail if above conditions met) - 对断言结果进行反转

#例如 响应值如下
{"code":0,"msg":"success"}

Assert JSON Path exists： $.code

Expected Value： 0

则最终匹配结果为成功

2、关于jmeter变量

整体上就是围绕${}这个符号的值，里面的值我们可以有多个获取方式，例如csv，前后置处理器设置等