JMeter配置元件

JMeter配置元件
一：管理请求服务器信息和Headers参数
如果使用Jmeter同时执行多个http请求任务，就需要创建多个HTTP取样器，每一个取样器都来手动填写服务器信息和端口号，会非常消耗时间。
解决方法：Jmeter之HTTP请求默认值
1、添加方式
“线程”右键->添加->配置元件->选中HTTP请求默认值

2、配置好服务器IP和端口以后，新建一个HTTP取样器，不填写服务器信息。

3、运行，检查结果。

可以看出该配置元件是作用于整个线程内的，对该线程内的所有HTTP请求都生效。

我的被测系统中Headers需要填写参数，该参数作为用户唯一标识符，请求传入了它服务器才会对请求作出响应。
Jmeter之HTTP信息头管理器
1、添加方式
“线程”右键->添加->配置元件->选中HTTP信息头管理器

2、运行一个请求，查看请求数据

Jmeter：发送JDBC请求
　　下午花了两个小时研究了一下Jmeter发送JDBC请求，现在把基本操作流程分享一下。
　　做JDBC请求，首先需要两个jar包：mysql驱动-mysql-connector-java-5.1.13-bin.jar 和 sqlServer驱动-sqljdbc4.jar，将这两个jar包放到Jmeter目录中的lib文件下,然后重启Jmeter。（需要jar包的直接联系本人哦）
　　1：添加线程组　　
　　2：添加 JDBC Connection Configuration
　　
　　3：配置 JDBC Connection Configuration 基本参数（注意Variable Name命名必须和之后JDBC Request中的Variable Name 命名一致）
　　　Driver Class 可写成org.gjt.mm.mysql.Driver，也可写成com.mysql.jdbc.Driver，　
　 4：添加 JDBC request
　　
　　4： JDBC request 中，键入sql查询语句　　
　　5：执行线程，查看结果如下

二：正则表达式提取器
（正则表达式提取器是Jmeter关联中的一种）使用场景：
有两个HTTP请求，请求A的返回数据中有一个字段“ABCD”，该字段要作为请求B的入参。
1、添加方式
请求A上右键–>后置处理器->正则表达式提取器

2、提取A请求中的taskCode对应的值

为了获取到上图中圈起来的这个值，要配置正则表达式提取器：

说明：
（1）引用名称：下一个请求要引用的参数名称，如填写Atask，则可用Atask引用它。（2）正则表达式：()：括起来的部分就是要提取的。.：匹配任何字符串。+：一次或多次。?：不要太贪婪，在找到第一个匹配项后停止。（3）模板：用{Atask}引用它。（2）正则表达式：　　　　()：括起来的部分就是要提取的。　　　　.：匹配任何字符串。　　　　+：一次或多次。　　　　?：不要太贪婪，在找到第一个匹配项后停止。（3）模板：用Atask引用它。（2）正则表达式：　　　　()：括起来的部分就是要提取的。　　　　.：匹配任何字符串。　　　　+：一次或多次。　　　　?：不要太贪婪，在找到第一个匹配项后停止。（3）模板：用$引用起来，如果在正则表达式中有多个正则表达式，则可以是222333等等，表示解析到的第几个值给title。如：111表示解析到的第1个值
（4）匹配数字：0代表随机取值，1代表全部取值，通常情况下填0
（5）缺省值：如果参数没有取得到值，那默认给一个值让它取，我填的Error。
3、获取到的值传入B请求

看一下请求B是否如预期的一样传入Atask这个值

引用成功~~

记录一个好用的测试正则表达式的工具：
工具名称：RegexTester
使用方法：

三：从文本读取参数
使用场景：测试一个接口并发处理数据的能力，并且每次请求传入的参数都要不同。
解决方法— CSV Data Set Config

列举一个实例，步骤中会侧重读取参数操作的说明，其他有疑问的步骤请查阅博主之前Jmeter相关的文章。
1、创建HTTP请求默认值—为了指定请求的服务器信息
2、创建HTTP信息头管理器—为了在Headers中传值
3、创建HTTP采样器—我们的请求任务
填好Http请求方式和请求路径，请求参数用变量方式引用进来，变量来源于CSV Data Set Config配置：
（1）添加CSV Data Set Config

（2）配置CSV Data Set Config

Filename：需要传入的参数所位于的文件名称，一定要填写完整路径，博主填写的绝对路径。
File encoding：参数文件的编码格式。可以不填。
Variable Names：对应参数文件中每列的变量名，也是你要引用到请求中的参数变量名。例如博主填写的值为ecsCode，在http请求中引用该参数时${ecsCode}
Delimiter：文件中的分隔符，一般用英文的逗号分隔开即可。
Allow quoted data？：是否允许引用数据。博主没有用到，默认设置为 false。
Recycle on EOF?：是否循环读取参数文件内容。设置为 true 时，意味着已经读取完参数文件内的测试用例数据时，线程循环次数仍然没有结束，那就循环读取参数文件数据；设置为 false 时，若已至文件末尾，则不再继续读取测试数据。
Sotp thread on EOF?：当读取到参数文件末尾时，是否停止读取线程。默认为 false。当 Recycle on EOF? 设置为 true 时，此项不起任何作用。当且仅当 Recycle on EOF? 为 false 时，此项配置才生效。
Sharing mode：共享模式，即参数文件变量作用域，博主没用到就不关注他。
（3）在文本中填写参数

该文件所在的路径即为CSV Data Set Config配置元件中的Filename值；
博主只传入一个参数，所以只有一列，如果有两个参数，会有两列数据，并用英文逗号隔开；引用参数时，CSV Data Set Config配置元件中Variable Names填写两个变量，也用英文逗号隔开即可
有10行数据，意味着10条测试用例，我会设置线程循环10次。这也是为什么我会在CSV Data Set Config配置元件中Recycle on EOF填写False

循环次数设置为10，意味着该条请求只执行10次。
Ramp-Up Period设置为0，意味着10条请求同时发出。如果设置为5，意味着5秒内发起10条请求，平均1秒发出2条。
（4）在请求中引用参数

4、增加一个响应断言，意味着返回数据包含“执行成功”字样，任务成功

5、添加监听器-察看结果树

四：用户定义的变量
使用场景：一组API根据业务流程制作成测试脚本，想要移植到其他测试环境时，由于数据库发生了变更，有些初始化数据也相应发生了变化，例如环境地址、请求路径等等。博主甚至把服务器地址和接口的部分共同请求路径都做成了自定义变量。

1、添加方式
线程组右键->添加->配置元件->用户定义的变量

2、作用范围
当前的线程组内所有取样器（即博主的HTTP请求）都可以引用变量
3、变量引用方式

需要说明的是，服务器IP地址和端口号以及接口共同的请求路径部分，作为变量引用时，需要在路径填充表格的最前面添加两个斜杠“//”，不加的话会引用失败。

循环控制器
指定其子节点运行的次数，可以使用具体的数值，也可以设置为变量
勾选永远：表示一直循环下去
如果同时设置了线程组的循环次数和循环控制器的循环次数，那循环控制器的子节点运行的次数为两个数值相乘。（线程数*循环控制器数值）

简单控制器：
这是Jmeter里最简单的一个控制器，它可以让我们组织我们的采样器和其它的逻辑控制器（分组功能），提供一个块的结构和控制，并不具有任何的逻辑控制或运行时的功能。

Foreach控制器
ForEach控制器一般和用户自定义变量一起使用，用于可以遍历读取相关的返回值。该控制器下的采样器或控制器都会被执行一次或多次，每次读取不同的变量值。
· Input Variable Prefix：输入变量前缀
· Output variable name：输出变量名称
· Start index for loop(exclusive)：循环开始的索引（默认从1开始，如果没有1开始的变量，执行时会报错）
· End index for loop(inclusive)：循环结束的索引
· Add””before number：输入变量名称中是否使用“”进行间隔。
注：foreach控制器通常和表达式提取器一起使用。表达式提取值应为-1，表示取全部值，然后sampler在foreach控制器下执行遍历

仅一次控制器（Once Only Controller）
在测试计划执行期间，该控制器下的元件对每个线程只执行一次，登录场景经常会使用到这个控制器

事务控制器（Transaction Controller）
Generate parent sample：勾选后，所有的结果将在父结点中展示(选中这个参数结果展示如下图红框)
Include duration of timer and pre-post processors in generated sample：选中这一项会统计定时器(timer)的时间，否则只统计采样器(sample)的时间

If 控制器（If Controller）
　　作用：根据给定表达式的值决定是否执行该节点下的子节点，默认使用javascript的语法进行判断
判断if控制器里面的语句是否为真，如果为真继续执行

这里我把id值写死了，跑一次观察结果，发现执行了服务人员的接口

Switch控制器（Switch Controller）
作用：Switch控制器通过给该控制器中的Value赋值，来指定运行哪个采样器。有两种赋值方式：
· 第一种是数值，Switch控制器下的子节点从0开始计数，通过指定子节点所在的数值来确定执行哪个元素。
· 第二种是直接指定子元素的名称，比如采样器的Name来进行匹配。当指定的名称不存在时，不执行任何元素。
当Value为空时，默认执行第1个子节点元素。
示例：
1、Switch Controller选择的值为客服登录

2、执行结果：

吞吐量控制器(Throughput Controller):
　　作用：控制其下的子节点的执行次数与负载比例，别被名字迷惑了，跟TPS RPS等等没关系。也有两种方式：

Total Executions：设置运行次数，整个测试计划中总计执行次数
Percent Executions：设置运行比例(1~100之间)，整个测试计划中总计执行百分比
Throughtput: 设计的数值
Per User: 依据网上的说明在选择Total Executions时，勾选时会在每个线程中执行的次数。但在3.0版本中尝试使用无效
示例：
1、设置线程组循环5次：

2、Throughput Controller1的子结点执行3次：、

结果发现一共运行了3次

3、Throughput Controller2的子结点执行（40% * 线程组循环次数5）= 2次：注意percent选项下，填写的是百分比！

观察运行结果，发现运行了2次

随机控制器(Random Controller):
作用：随机执行其下的某个子结点，随机选择控制器中的请求进行执行
应用场景: 页面的随机访问

执行结果，随机选择了三个登录中的一个

随机顺序控制器(Random Order Controller):
作用：随机执行其下的所有子结点
· 与Random Controller不同的是，这个控制器会先将需要随机的内容均执行一遍，但次序不定
· 应用场景: 页面的随机访问,但均需要访问，且次序不限

多运行一次，观察结果，发现两次运行的顺序不同，但是每个接口都运行了一遍

Critical Section Controller 关键部分控制器
作用：用于核心部分的控制，确保其子节点下的取样器或控制器在一个线程中仅会执行一次
Lock name: 锁名称，这里可以填入其子节点下执行的线程的名称，这个线程作为一个全局锁存在

Interleave Controller 交替控制器
交替控制器使得该控制器包含的取样器步骤交错执行在每个循环中，每个线程用户仅执行一次控制器内的请求，线程用户依据循环的次数请求控制器中的请求数

Module Controller 模块控制器
· 模块控制器，用于跳转到选定的控制器位置并执行对应的控制器
· 应用场景: 业务逻辑的跳转
· 配制说明
· Module to Run: 选择需要跳转到的目标控制器

While Controller
While 控制器，与开发语言中的While功能一致。直到条件为false时，停止运行
循环执行一个请求，仅判断一种状态下退出循环
Condition条件如下：
1：为空(不输入任何值) – 直到某次请求执行失败才退出循环
2：LAST – 直到最后一个请求请求失败才退出循环
3：其它 – 条件值等于"false"时，退出循环
4：Contion可以输入计算结果等于“false”的变量、函数。
例：${num} !=5判断变量num的值是否为5，等于5则退出循环

KaTeX parse error: Expected group after '_' at position 2: {_̲_javaScript("{num}"!=8 && "KaTeX parse error: Expected 'EOF', got '}' at position 13: {num}"<"5",)}̲，表示在{num}不等于8的情况下执行循环体，但是只能循环5次
我们通过计数器让它有十次循环的机会

查看结果，循环体执行到${num}==5的时候就停止了

Jmeter(四十九)_常用的性能测试监听器
概述
jmeter中提供了很多性能数据的监听器，我们通过监听器可以来分析性能瓶颈
本文以500线程的阶梯加压测试结果来描述图表。

常用监听器
1：Transactions per Second
监听动态TPS，用来分析吞吐量。其中横坐标是运行时间，纵坐标是TPS值。红色表示通过的TPS，绿色表示失败的。
最大TPS大约在140左右，从1分26秒左右，开始有未通过的事物

2：Hits per Second
动态监听单位时间的点击率，也就是触发的请求数。其中横坐标是运行时间，纵坐标是HPS值。
点击率波动较大，且不能持续上升。说明性能很不稳定

3：Response Times Over Time
监听整个事物运行期间的响应时间。其中横坐标是运行时间，纵坐标是响应时间（单位是毫秒）
响应时间在4950ms左右开始稳定下来，后续又经历一次大的波动

4：Response Times vs Threads
线程活动期间的响应时间监听。其中横坐标是活动的线程数（也就是并发数），纵坐标是响应时间（单位是毫秒）

5： Active Threads Over Time
监听单位时间内活动的线程数。其中横坐标是单位时间（单位是毫秒），纵坐标是活动线程数（也就是并发数）

6：Response Times Percentiles
监听响应时间分布的百分比。其中横坐标是请求数的百分比，纵坐标是响应时间。此图表示有99.7%的请求响应时间在5s以内。

7：Response Times Distribution
响应时间分布的柱状图。其中横坐标是柱状分布图，纵坐标是响应时间。此图表示大约有111个请求响应时间在5076ms。

8：Composite Graph
组合式的监听器。其中横坐标是运行时间，纵坐标是各性能数据的汇总值（其中有一些数据需要除以10）。

总结
不同的监听器可以监听不同的性能数据，但是想要在图表中直观的分析出性能的瓶颈，就需要组合式的监听器。例如通过响应时间和吞吐量的分布得出吞吐量的拐点。
通过以上图表能看出来，在持续加压的事物场景中，99.7%的请求响应时间都控制在了5s以内。
逻辑控制器
逻辑控制器允许您在线程中定义处理请求的顺序。它允许您控制“何时”将用户请求发送到Web服务器。例如，您可以使用随机控制器随机向服务器发送HTTP请求
逻辑控制器确定执行用户请求的顺序。

image.png
JMeter性能测试工具快速入门教程-目录 https://www.jianshu.com/p/7b1a3346dc0f
录制控制
JMeter可以记录您的测试步骤;记录控制器是占位符，用于存储这些记录步骤。
简单控制器：
简单控制器只是用户请求的容器。

循环控制器：
循环控制器使用户请求运行指定的次数或永久运行，如图所示：

随机控制器：
随机控制器使所有用户请求在每个循环周期中以随机顺序运行。
模块控制器
Module Controller的目标是为JMeter添加模块化。
一般的想法是Web应用程序由小的功能单元组成（即登录，创建帐户，注销…）。此功能可以作为“模块”存储在Simple Controller中。模块控制器将选择需要运行的模块。

其他重要控制器：
Interleave 控制器：在线程的每个循环中运行一个用户请求。
运行时控制器：控制子项运行的时间。例如，如果您指定运行时控制器10秒，JMeter将运行您的测试10秒。
事务控制器：测量完成测试执行所需的总时间
包含控制器：旨在使用外部测试计划。该控制器允许您在JMeter中使用多个测试计划。
循环控制器示例
除了为线程组指定的循环值之外，循环控制器使采样器运行一定次数。例如，如果你
将一个HTTP请求添加到循环控制器，循环计数为50
将线程组循环计数配置为2
然后，JMeter将发送总共50 * 2 = 100个HTTP请求。
断言
断言帮助验证您的服务器是否返回预期结果。
响应断言

响应断言允许您添加模式字符串以与服务器响应的各个字段进行比较。
例如，您向网站http://www.google.com发送用户请求并获取服务器响应。您可以使用Response Assertion来验证服务器响应是否包含预期的模式字符串（例如“OK”）。
持续时间断言

持续时间断言测试在给定的时间内收到每个服务器响应。任何花费超过给定毫秒数（由用户指定）的响应都会标记为失败的响应。
例如，JMeter将用户请求发送到www.google.com ，并在预期时间内获得响应，然后测试用例通过5秒，否则测试用例失败。
大小断言
测试每个服务器响应包含其中的预期字节数。您可以指定大小等于，大于，小于或不等于给定的字节数。
JMeter向www.google.com发送用户请求，并在测试用例通过时获取大小小于预期字节5000字节的响应数据包。如果是，测试用例失败。
XML断言

测试响应数据由XML文档组成。
HTML断言

HTML Assertion允许用户检查响应数据的HTML语法。这意味着必须满足HTML语法的响应数据。

添加模式进行测试
当您向Google服务器发送请求时，它可能会返回一些响应代码，如下所示：
404 ：服务器错误
200 ：服务器正常
302 ：Web服务器重定向到其他页面。

假设您要验证Web服务器google.com响应代码是否包含模式302，
在响应字段要测试，选择响应代码，
在Response Assertion Panel上，单击- Add -> a new blank entry display -> enter 302 。
添加断言结果
右键单击Add -> a new blank entry display -> enter 302
运行测试
关于线上指标的估算
性能测试过程中，我们调研时需要确认指标要求，以下是我总结的几种估算场景
A、监控观察法–准确度高：
针对线上现有接口，存在监控数据（请求量和RT），可以直接查看该接口的某一段时间的调用峰值，将统计粒度换算为每秒请求量（qps）。Rt响应时间
例：某服务1天36万笔（粗粒度统计），平均RT在100ms，指标计算如下
指标=(日量36万/10小时高峰期/3600秒)x5倍保险系数=50qps、rt100ms
例：某服务近期监控请求峰值为1小时36万笔（粗粒度统计），平均RT在100ms，，指标计算如下
指标=(时量36万/3600秒)x5倍保险系数=500qps、rt100ms
(监控粒度粗细和线上监控工具有关，分钟级的类似，除以60s即可)

B、类比法–准确度中：
针对新接口或者线上无监控的接口，但存在类似接口的监控，可以类比计算。
例：A接口线上指标为50qps、rt100ms，新接口B的使用场景和A相似度很高，那可以将B接口的性能也指标定位50qps、rt100ms

C、估算法–准确度低：
针对新接口或者线上无监控的接口，也没有类似的接口可以参考，仅从产品或者市场调研估算出某一天的量或者某一段时间的量，接下来估算方法和A方法类似。关于RT，如没特别说明，将会采用默认性能要求值（单服务单表类rt<100ms；较复杂接口rt<300ms；大list类或调用链较长接口rt<1s）
例：通过运营数据得知接口A在1天内要完成36万笔交易，指标计算如下
指标=(日量36万/10小时高峰期/3600秒)x8倍保险系数=80qps、rt100ms

D、其他情况：
除以上场景外，针对新接口无任何数据，无法给出指标值情况，性能压测不再关注指标压测，仅执行阶梯性的负载测试，压测出该接口的最优处理能力。（此情况存在较大风险，上线后需要时刻关注，请避免此情形。）

性能测试过程
线程组参数详解：

线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里也就是设置多少个线程数。
Ramp-Up Period(in seconds)准备时长：设置的虚拟用户数需要多长时间全部启动。如果线程数为10，准备时长为2，那么需要2秒钟启动10个线程，也就是每秒钟启动5个线程。
循环次数：每个线程发送请求的次数。如果线程数为10，循环次数为100，那么每个线程发送100次请求。总请求数为10*100=1000 。如果勾选了“永远”，那么所有线程会一直发送请求，一到选择停止运行脚本。
Delay Thread creation until needed：直到需要时延迟线程的创建。
调度器：设置线程组启动的开始时间和结束时间(配置调度器时，需要勾选循环次数为永远)
持续时间（秒）：测试持续时间，会覆盖结束时间
启动延迟（秒）：测试延迟启动时间，会覆盖启动时间
启动时间：测试启动时间，启动延迟会覆盖它。当启动时间已过，手动只需测试时当前时间也会覆盖它。
结束时间：测试结束时间，持续时间会覆盖它。
50线程组
1.线程数：50
Ramp-Up Period(in seconds)准备时长：20
循环次数：2

100线程组

1.线程数：100
2. Ramp-Up Period(in seconds)准备时长：30
3. 循环次数：2

500线程组

1.线程数：500
2. Ramp-Up Period(in seconds)准备时长：60
3. 循环次数：5

1.线程数：1000
2. Ramp-Up Period(in seconds)准备时长：60
3. 循环次数：10

拐点分析
在进行性能测试的时候，我们需要对图的曲线进行分析。分开来看的时候，响应时间（RT）、吞吐量（TPS）和资源利用率的变化情况分别是：
　　响应时间：随着并发用户数的增加，在前两个区，响应时间基本平稳，小幅递增。在第三个区域：急剧递增。在第三个区的点为拐点。
　　吞吐量：随着并发用户数的增加，在前两个区，对于一个良好的系统来说，并发用户数的增加，请求增加，吞吐量增加，中间的区域，处理达到顶点。
　　在第三个区：资源利用率：呈直线，表示饱和。

7.条曲线合起分析：吞吐量下降，排队现象，服务器宕机，响应时间越来越大。
　　8.整体的分析思路：
　　当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续工作，但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有些用户无法忍受而放弃；而当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长的响应时间而放弃。

JMeter配置元件相关推荐

性能测试之JMeter配置元件【HTTP信息头管理器】
JMeter提供了丰富的配置元件,常用的包括参数化配置元件.HTTP请求默认值.HTTP信息头管理器.计数器等,这些配置元件用于设置默认值和变量,提供给后面的sampler(取样器)使用. 提示:本文 ...
性能测试之JMeter配置元件【计数器】
1.计数器介绍如果需要引用的数据量较大,且要求不能重复或者需要自增,那么可以使用计数器组件来实现. 计数器组件中的数据,允许在一个线程组之内都可以被引用. 2.计数器界面详解添加计数器组件的操作: ...
性能测试之JMeter配置元件【随机变量】
1.随机变量介绍随机变量应用场景:在一些数据要求不重复,或者对数据取值需要正态分布的时候,我们可以采用随机变量组件来满足需求. 随机变量与用户自定义变量的区别: 随机变量(random variab ...
JMeter配置元件【HTTP请求默认值】
1.HTTP请求默认值介绍我们在JMeter中编辑测试计划时,如果有多个Sampler(取样器)请求中,参数和设置都是相同的,例如请求服务的IP地址.协议.端口号等,这些信息重复的配置在每个Samp ...
jmeter配置元件之计数器
如果需要引用的数据量较大,且要求不能重复或者需要自增,那么可以使用计数器来实现. 计数器(counter):允许用户创建一个在线程组之内都可以被引用的计数器. 计数器允许用户配置一个起点,一个最大值, ...
JMeter 配置元件-CSV Data Set Config 参数化配置
众所周知,在进行接口测试的过程中,需要创建不同的场景(不同条件的输入,来验证不同的入参的返回结果).因而,在日常的自动化接口监控或商品监控等线上监控过程中,需要配置大量的入参来监控接口的返回是否正确. ...
【Jmeter篇】如何利用Jmeter配置元件计数器、随机变量制造批量数据和变量参数化？
一.计数器 1.线程组-配置元件-计数器 2.功能介绍 starting value:给定计数器的起始值.初始值,第一次迭代时,会把该值赋给计数器递增(Increment): 每次迭代后,给计数器增 ...
Jmeter配置元件之CSV数据文件设置-18
CSV数据文件设置用于读取文件中的行,并将行中的数据根据拆分符拆分为可引用的变量,通常用于处理大量变量.就CPU和内存而言,如果在运行时生成大量变量,将会消耗大量资源,而在测试前创建好这些数据,执行测 ...
JMeter初探五-配置元件与参数化
目录 1.HTTP Header Manager(信息头管理器) 2.HTTP Cookie Manager(cookie管理器) 3.CSV Data Set Config 所谓配置元件可以理解为J ...

JMeter配置元件

JMeter配置元件相关推荐

最新文章

热门文章