jmeter——下

最新推荐文章于 2024-06-20 19:32:12 发布

daimabanyun

最新推荐文章于 2024-06-20 19:32:12 发布

阅读量762

点赞数 9

文章标签： jmeter dubbo

本文链接：https://blog.csdn.net/daimabanyun/article/details/138409960

版权

逻辑控制器

如果（if）控制器

条件判断满足才执行

作用:If控制器用来控制它下面的测试元素是否运行

位置:测试计划-->线程组-->(右键添加)逻辑控制器-->如果(If）控制器

可以与函数助手对话框搭配使用

如果（if）控制器案例

使用‘用户定义的变量’定义一个变量name，name的值可以是baidu,根据name的变量值实现对应网站的访问

1．添加线程组

2．用户定义的变量

3．添加If控制器，判断name是否等于baidu

不勾选Interpret condition,'$ {name } ' =='baidu'

勾选，${__jexl3 ( ' $ {name } ' == 'baidu' ,) }

4．添加HTTP请求，用来访问百度

5．添加if控制器，判断name是否等于itcast

6．添加HTTP请求，用来访问传智播客

7．添加查看结果树

事务控制器

将多个步骤绑定为一个事务有一个步骤失败事务就失败了比如ATM机取钱

吞吐量控制器

控制执行百分比，例线程组设置线程数为10再建两个吞吐量控制器设置吞吐量为30,10再执行，一个执行三次，一个执行一次

循环控制器

位置:测试计划-->线程组-->(右键添加)逻辑控制器-->循环控制器

参数介绍:

案例:

使用"循环控制器"的操作循环访问百度10次步骤?

1．添加线程组

2．添加循环控制器—设置循环次数

3．添加HTTP请求

4．添加查看结果树

ForEach控制器

作用:一般和用户自定义变量或者正则表达式提取器一起使用，读取返回结果中一系列相关的变量值。该控制器下的取样器都会被执行一次或多次，每次读取不同的变量值。

位置:测试计划-->线程组-->(右键添加）逻辑控制器-->ForEach控制器

WebService文件上传接口

用户场景：有一个新建用户凭证页面，填写字段信息，上传图片文件，点击提交，即新建成功。

WebSocket

WebSocket是一种网络通信协议，客户端和服务端只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

例

Server Name or IP：发送请求的目标服务器的IP地址或者域名。

Port Number：服务器地址后的端口号，有则填写，没有不用填写。

Protocol [ws/wss]：ws是明文数据传输，wss是密文数据传输，相当于http和https的差别，默认ws。

Path：接口路径。

Request data：发送的请求数据。

jmeter连接数据库

jmeter命令行界面执行

例：

#jmeter压力测试,并使用命令生成详细的html报告 jmeter -n -t C:\Users\Administrator\Desktop\HTTP请求.jmx -l D:\迅雷下载\res\res.jtl -e -o D:\迅雷下载\res\report #在非 GUI 模式下运行指定的 JMX 测试计划文件，将测试结果保存为 res.jtl 文件，并生成一个 HTML 报告，最后将报告输出到 D:\迅雷下载\res\report 目录下。 --? #打印命令行选项并退出 -h, --help #打印使用信息并退出 -v, --version #打印版本信息并退出 -p, --propfile <参数> #要使用的 jmeter 属性文件 -q, --addprop <参数> #额外的 JMeter 属性文件 -t, --testfile <参数> #要运行的 jmeter 测试（.jmx）文件 -l, --logfile <参数> #将样本记录到的文件 -i, --jmeterlogconf <参数> #jmeter 日志配置文件（log4j2.xml） -j, --jmeterlogfile <参数> #jmeter 运行日志文件 (jmeter.log) -n, --nongui #在 nongui 模式下运行 JMeter -s, --server #运行 JMeter 服务器 -H, --proxyHost <参数> #为 JMeter 设置代理服务器以使用 -P, --proxyPort <参数> #设置 JMeter 使用的代理服务器端口 -N, --nonProxyHosts <参数> #设置非代理主机列表（例如 *. apache.org | localhost ） -u, --username <参数> #为 JMeter 使用的代理服务器设置用户名 -a, --password <参数> #为 JMeter 使用的代理服务器设置密码 -J, --jmeterproperty <参数>=<值> #定义额外的 JMeter 属性 -G, --globalproperty <参数>=<值> #定义全局属性（发送到服务器）例如 -Gport = 123或 -Gglobal.properties -D, --systemproperty <参数>=<值> #定义附加系统属性 -S, --systemPropertyFile <参数> #附加系统属性文件 -f, --forceDeleteResultFile #在开始测试之前强制删除现有的结果文件和网络报告文件夹（如果存在） -L, --loglevel <参数>=<值> #[category=]level 例如 jorphan=INFO、jmeter.util=DEBUG 或 com.example.foo=WARN -r, --runremote #启动远程服务器（在 remote_hosts 中定义） -R, --remotestart <参数> #启动这些远程服务器（覆盖 remote_hosts） -d, --homedir <参数> #要使用的 jmeter 主目录 -X, --remoteexit #在测试结束时退出远程服务器（CLI 模式） -g, --reportonly <参数> #仅从测试结果文件生成报告仪表板 -e, --reportatendofloadtests #负载测试后生成报告仪表板 -o, --reportoutputfolder <参数> #报表仪表板的输出文件夹

性能理论

满足用户需求

最小成本

评估系统性能

功能测试后,项目上线前

并发:并发用户数，并发请求数(QPS)

TPS:每秒事务数(吞吐量)数值越大越好

RT:响应时间2-5-8优先以公司标准、各行业标准、行业通用失败率

CPU使用率越小越好，80%

指标（括展）

系统性能指标

系统响应时间

响应时间（Response Time: RT）指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。在性能检测中一般以压力发起端至被压测服务器返回处理结果的时间为计量，单位一般为秒（s）或毫秒（ms）。

平均响应时间指系统稳定运行时间段内，同一交易的平均响应时间。一般而言，交易响应时间都是指平均响应时间。平均响应时间指标值应根据不同的交易分别设定，一般情况下，分为复杂交易响应时间、简单交易响应时间、特殊交易响应时间。其中，特殊交易响应时间的设定必须明确该交易在响应时间方面的特殊性。

不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易：

互联网企业：500 毫秒以下，例如淘宝业务 10 毫秒左右。
金融企业：1 秒以下为佳，部分复杂业务 3 秒以下。
保险企业：3 秒以下为佳。
制造业：5 秒以下为佳。

对于批量交易：

时间窗口：即整个压测过程的时间，不同数据量则时间不一样，例如双 11 和 99 大促，数据量级不一样则时间窗口不同。大数据量的情况下，2 小时内可完成压测。

系统处理能力

系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：

一是业务人员角度的一笔业务过程；
二是系统角度的一次交易申请和响应过程。

前者称为业务交易过程，后者称为事务。两种交易指标都可以评价应用系统的处理能力。一般建议与系统交易日志保持一致，以便于统计业务量或者交易量。系统处理能力指标是技术测试活动中重要指标。

一般情况下，用以下指标来度量：

HPS（Hits per Second）：每秒点击次数，单位是次 / 秒。
TPS（Transaction per Second）：系统每秒处理交易数，单位是笔 / 秒。
QPS（Query per Second）：系统每秒处理查询次数，单位是次 / 秒。

对于互联网业务中，如果某些业务有且仅有一个请求连接，那么 T P S = Q P S = H P S TPS=QPS=HPSTPS=QPS=HPS，一般情况下用 TPS 来衡量整个业务流程，用 QPS 来衡量接口查询次数，用 HPS 来表示对服务器单击请求。

无论 TPS、QPS、HPS，此指标是衡量系统处理能力非常重要的指标，越大越好，根据经验，一般情况下：

金融行业：1000 TPS ~ 50000 TPS，不包括互联网化的活动。
保险行业：100 TPS ~ 100000 TPS，不包括互联网化的活动。
制造行业：10 TPS ~ 5000 TPS。
互联网电子商务：10000 TPS ~ 1000000 TPS。
互联网中型网站：1000 TPS ~ 50000 TPS。
互联网小型网站：500 TPS ~ 10000 TPS。

并发用户

并发用户数（Virtual User：VU）指在同一时刻内，登录系统并进行业务操作的用户数量。

并发用户数对于长连接系统来说最大并发用户数即是系统的并发接入能力。对于短连接系统而言最大并发用户数并不等于系统的并发接入能力，而是与系统架构、系统处理能力等各种情况相关。例如系统吞吐能力很强，加上短连接一般都有连接复用，往往并发用户数大于系统的并发接入连接数。所以对于大部分短连接类型的系统，吞吐量模式（RPS 模式，Request Per Second）比较适合，也是阿里的最佳实践，PTS 支持 RPS 模式的压测，吞吐量的压测构建和衡量一步到位。在测试中，采用虚拟用户来模拟现实中用户进行业务操作。

一般情况下，性能测试是将系统处理能力容量测出来，而不是测试并发用户数，除了服务器长连接可能影响并发用户数外，系统处理能力不受并发用户数影响，可以用最小的用户数将系统处理能力容量测试出来，也可以用更多的用户将系统处理能力容量测试出来。

错误率

错误率（Virtual Failure Ratio：FR）指系统在负载情况下，失败交易的概率。错误率＝（失败交易数 / 交易总数）×100%。稳定性较好的系统，其错误率应该由超时引起，即为超时率。

不同系统对错误率的要求不同，但一般不超出千分之六，即成功率不低于99.4%。

资源指标

CPU

CPU 指标主要指的：CPU使用率、利用率，包括用户态（user）、系统态（sys）、等待态（wait）、空闲态（idle）。

CPU 使用率、利用率要低于业界警戒值范围之内，即小于或者等于 75%、CPU sys% 小于或者等于30%，CPU wait% 小于或者等于5%。单核 CPU 也需遵循上述指标要求。CPU Load 要小于 CPU 核数。

内存

现代的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率 100% 并不代表内存有瓶颈，衡量系统内有瓶颈主要靠 SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP 交换空间利用率要低于 70%，太多的交换将会引起系统性能低下。

磁盘吞吐量

磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的重要依据，一般情况下，磁盘繁忙率要低于70%。

网络吞吐量

网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的 70%。

内核参数

操作系统内核参数主要包括信号量、进程、文件句柄，一般不要超过设置的参数值即可

数据库指标

常用的数据库例如ＭySQL，指标主要包括 SQL、吞吐量、缓存命中率、连接数等

SQL耗时越小越好，一般情况下微秒级别。

命中率越高越好，一般情况下不能低于 95%。

锁等待次数越低越好，等待时间越短越好。

前端指标

前端指标主要包括页面展示和网络所花的时间

页面要尽可能小及压缩。

页面展示和花费时间越短越好。

稳定性指标

最短稳定时间：系统按照最大容量的 80% 或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。

一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行 8 小时以上。对于 7×24 运行的系统，至少应该能够保证系统稳定运行 24 小时以上。如果系统不能稳定的运行，上线后，随着业务量的增长和长时间运行，将会出现性能下降甚至崩溃的风险。

TPS 曲线稳定，没有大幅度的波动。

各项资源指标没有泄露或异常情况。

流程

需求分析

分析系统非功能需求（关注业务量、业务分布、用户规模、性能指标等信息），确定性能测试范围，了解性能指标。一、系统非功能需求采集

（1）系统架构：物理架构（硬件及部署策略）和逻辑架构（系统的功能与服务），包括中间件产品与配置、数据库配置等，供我们搭建测试环境时进行参考。

（2）业务流程：业务量和业务分布。采集业务（分析出哪些业务纳入性能测试范围）并量化业务、业务扩展趋势（年增长率或者未来的业务量）、业务发生时段（业务高峰的发生时间和高峰业务量）、业务分布（各项业务之间的比例）。

（3）用户信息：在线用户数、活动用户数、业务分布。有些系统用户量特别大，会对系统造成性能瓶颈，可以通过分析活动用户数和业务分布来分析负载情况。

（4）系统是否与第三方系统有关，是否需要做挡板（Mock程序）。

（5）系统是否有归档机制：如果数据库有归档机制，可以把一些无用或者过时的信息移到归档库，这样就减少当前数据库的数据，有利于提高系统性能。

（6）性能指标：吞吐率、响应时间、事务成功率，CPU、内存、磁盘、带宽使用阀值。

二、系统非功能需求分析

确定性能测试范围

是否核心业务，是否要求严格的质量
是否高频次的业务
是否占用系统较多资源、或性能影响大的业务
使用人数多还是少
在线人数多还是少
确定此功能的可测性、可验证性：功能是否可验证（是否牵连到第三方程序，是否需要做挡板Mock程序）。

明确性能指标 业务性能指标吞吐量（PV）、吞吐率（TPS等）响应时间（RT）/ 应用响应时间（ART）：3秒以内事务成功率：99%以上稳定波动正常范围

测试策略

负载测试压力测试并发测试

在文档中明确列出测试范围、人力投入、持续时间、工作内容、风险评估、风险应对策略等。

系统概述：简述系统使命、系统功能，用于给非专业人士了解系统是做什么的。
测试环境：生产环境、测试环境（服务器+负载机）的硬件架构和详细配置信息。
需求分析：需要测试的业务模型及其信息采集，性能指标的采集和确定。
测试策略：测试目的、测试执行的可行性分析、具体的测试手段及测试监控策略。
测试场景：如何组合业务场景进行性能测试。
测试准备：包括：测试工具的准备（负载工具、监控工具、文档管理工具）；测试脚本及测试程序准备；测试数据准备；测试环境准备。
时间计划：进行需求分析、测试策略后，就可以相对合理的估算测试资源及耗时。
测试组织架构：测试相关干系人，明确不同干系人的工作职责。
交付物清单：性能测试计划、性能测试脚本、性能缺陷报告、性能测试阶段性报告、性能测试报告（包括且不仅限于事务成功率、TPS、硬件性能指标等）。
系统风险：风险预测及风险评估（包括且不仅限于人员风险、软件风险、进度风险、变更风险、系统风险、数据风险、环境风险），并提出应对策略。

编写脚本

录制脚本或手动开发，添加固定计时器模拟ThinkTime，增加同步定时器模拟集合点，增加IF条件控制器判断逻辑，添加后置处理器获取参数。脚本注意做断言！！！，验证事务是否成功。开发挡板程序，开发测试工具等。

事务定义 合理的定义事务，能够方便分析耗时（特别是混合业务功能场景测试），进而方便分析瓶颈。比如，购买商品，我们可以把下订单定义为一个事务，把支付也定义为一个事务。

执行测试

测试执行是性能测试的关键，同样的脚本不同执行人员得出的结果可能差异较大。这些差异主要体现在场景设计与测试执行上。

场景设计前面已经确定了测试模型。场景设计是根据测试模型与目标，组织虚拟用户、组合业务种类到一个测试单元。组织测试场景时尽量要与实际业务情况一致。

基准测试采用单业务场景、单用户的方式执行脚本。用于验证测试环境、测试脚本，以及为后续的测试执行提供性能基准。比如一个登录系统，如果系统登录时间为8秒，那么这个系统也就没必要再进行性能测试，因为它连一般性能都达不到要求。

配置测试配置测试场景一般为混合场景（多个业务同时执行），用于帮助分析系统软、硬件配置是否满足性能需求指标，优化配置使各项资源达到最优分配原则。测试过程是一个实验过程，先是找出不合理配置，然后进行修改，最后进行验证；周而复始到配置满足需求。

负载测试负载测试的目的是分析性能变化趋势，找出性能拐点分析性能问题与风险，对系统进行定容定量；为系统优化、性能调整提供数据支撑。负载测试分为单场景与混合场景；单场景有利于分析性能问题，因为排除了其他业务干扰；混合场景更贴近用户实际使用习惯，是一个综合的性能评估。建议先做单场景测试再做混合场景测试。

负载测试的性能变化曲线图见前面的 “RT&TPS和Thread的趋势图”，①可以理解为单业务、单用户时的系统性能，②通常是我们估算的满足性能需求的点，③是性能拐点，之后性能变差，在这个点系统吞吐量达到最大，④这个点已经过载，吞吐量开始减小。负载测试一般需要找到②③④这三个点，通常会因为一些配置、程序问题而受到干扰，所以执行测试也是一个耗时的工作。

稳定性测试稳定性测试在正常性能阀值下尽量加大负载，长时间运行，确定系统的软、硬件环境是否运行稳定。什么是阀值呢？比如响应时间要求3s以内，3秒就是阀值；比如CPU利用率70%以下，70%就是阀值。假设满足性能要求的负载是B，那么稳定性测试时负载一般是1.5B~2B。执行时采用混合场景，按惯例执行时间不低于8小时。时间上越长越好，有些隐藏较深的诸如内存溢出的问题是需要长时间运行才能反映出来的。