一、JMeter安装与环境配置
因为JMeter本身是一个纯Java开发的应用程序，它的运行依赖于Java虚拟机。因此，安装JMeter之前一定要确保系统中已经正确安装配置JDK（Java开发工具包）。这里本人不再赘述其详细步骤**。（版本要求------建议JDK17或者更高版本）如图是我的版本，Win+R,输入cmd，打开终端输入java -version即可查看自己电脑的JDK版本。**
对于小白来说，附两个详细的安装文章，自行学习。 JDK17 下载安装详细教程-CSDN博客
App测试环境搭建全过程，包含JAVA JDK配置、Android SDK、、Appium、Node.js、模拟器配置【究极保姆级】还不会我吃奥利给_app测试jdk-CSDN博客
接下来是JMeter的安装。
1.第一步，先访问JMeter的官网地址：Apache JMeter - Download Apache JMeter
2.第二步，下载最新的二进制安装包，如图所示。（下载.zip的，是windows系统的安装包）
3.第三步，将下载的安装包解压至任意的本地目录（建议路径中不要包含中文名和空格）
4.手动启动方式：
Windows:进入解压后的bin目录，双击运行jmeter.bat
Linux|macOS:进入解压后的bin目录，双击运行sh jmeter.sh
5.命令启动方式：
解压后的bin目录，加入系统变量path中（在旧的上面加入环境变量，不要把path变量原有的内容去掉）如果想要详细步骤，看这篇文章------ Jmeter安装教程【5.5】【Windows】jmeter详细安装配置教程，装不好你打我-CSDN博客
CLASSPATH的环境变量改为：
;%JAVA_HOME%\;lib\;dt.jar;%JAVA_HOME%\;lib\;%JMETER_HOME%\lib\ext\ApacheJMeter_core.jar;%JMETER_HOME%\lib\jorphan.jar;tools.jar;%CATALINA_HOME%\;lib\;servlet-api.jar
重新打开命令行终端，执行jmeter。如图所示：
表示Jmeter安装成功。
二、JMeter页面与组件
如果英语不好，可以改为中文；字体小的话也能找到选项进行放大。
接下来，看一下这个工具的页面布局和功能展示，这里我将该工具分为六个部分，如图所示。
对每一部分的功能做一个讲解：
1.从左往右，每一个图标依次是新建文件、通过模版方式创建文件（通过脚本入置）、打开之前关闭文件、保存文件。
2.第二组的按钮都是对组件来进行管理的，组件里面有东西，有内容，可以实现对组件内容的剪切、复制粘贴、折叠、展开、禁用和恢复的切换。（都是对组件进行服务的）
3.第三组从图标就可以看出来，分别是运行启动、不停顿开始、停止、关闭、清除（产生的结果、日志、数据）、清除全部 。
4.第四组主要提供的帮助，查找内容、重置搜索、函数助手对话框（函数名和函数参数拼在一起就能生成代码）以及帮助（查看官方学习文档，英文的） 。
5.第五部分内容就是用来展示所有的组件，是一个组件列表。（每一个组件的内容都不一样）
6.第六部分是组件的面板，用来展示组件的内容，需要对组件进行一些配置。
因此，JMeter的核心内容就是组件。
核心组件介绍
1.测试计划（Test Plan）----很重要
含义：是所有测试元素中的顶级容器，描述了一系列测试步骤的执行逻辑。
特点：任何测试计划都必须置于测试计划之下。
2.线程组（Thread Group）
含义：用于模拟一组虚拟用户的执行用例，决定了用户的总数，也就是线程数，启动的节奏，以及测试的执行次数或时长。
特点：所有取样器都必须置于线程组之下。
3.取样器（Sampler）
含义：用于模拟用户的具体操作，也就是测试步骤 ，一般来说是向服务器发送请求。它有多种类型，其中，最常用的就是HTTP取样器。
特点：是大部分非核心组件的服务对象。
这三部分构成了一个Jmeter测试当中的最小的测试实例。
辅助组件------对取样器起辅助工作
- 监听器 (Listener) ：展示取样器工作细节和结果
- 配置元件 (Config Element) ：配置修改取样器的设置
- 定时器 (Timer) ：延迟取样器的执行
- 断言 (Assertion) ：判断取样器的结果
- 前置处理器 (Pre-Processor) ：取样器之前，自动执行
- 后置处理器 (Post-Processor) ：取样器之后，自动执行
- 逻辑控制器 (Logic Controller) ：对取样器进行逻辑控制（条件、分支、循环、跳过）
这几个组件都不是必须的。
在求职面试时，会问到这几个组件的执行顺序------前置处理器 → 取样器 → 后置处理器 → 断言 → 监听器。（其中，定时器会在每个取样器执行之前触发）
上面的这些概念不要死记硬背，自行理解每一个部分的用途，在实战中会用即可。
三、JMeter实战练习（巩固）
发送一个接口请求
首先，右击测试计划，新建一个线程组，起名为"第一个接口练习"。
然后，右击"第一个接口练习"，新建一个HTTP取样器。
然后，根据接口的文档内容来进行接口的请求。
这是网上资源的参考接口，也可以使用自己所做的项目接口来做测试。
请求方式：POST 接口地址：http://api.fbi.com:9225/rest-v2/login/access_token
Request Body 请求类型：application/json
password string<password> required
= 8 characters <= 20 characters
email string<email> required
= 8 characters <= 30 characters
点击启动 之后，会发现没有任何效果，这里就需要用到辅助组件------监听器。
添加监听器，选择查看结果树。
这里就能看到HTTP请求的结果了。（以上这个HTTP的地址是模拟地址，本机上如果没有启动这个9225这个端口就会报错，如下图所示。因此，在练习时要选用自己电脑上已有的端口地址来做练习测试。）
正常情况下，Response code会弹出422、200、401这样的HTTP状态码。
在测试过程中，如果遇到取样器的格式错误，这里不能直接对取样器的格式做一个修改（取样器本身不提供一个Content的配置），需要使用一个辅助组件------配置元件。
在配置元件中选择HTTP信息头管理器 。这里就有一个基本的顺序，先配置，再请求，最后返回结果。
这是第一次请求的Content-type的结果，发现Content-type的格式出现了错误，这里添加完HTTP信息头管理器之后，这里面更改content-type的格式，就能得到正确的返回结果。
如果遇到如图所示的这种情况，响应数据提示这样的信息，就表明里面的数据格式出现了错误，不应该是上面表格的形式，传入的应该是消息体数据。
这里面应该注意 ：1.最后一行不要写逗号，要不然会报错
2.消息体数据的格式展示是什么样的，最后返回的响应数据就是什么样的，不要出现大量的空格。
最后，还需要注意password和email的格式，如果格式错误就会提示英文的密码或邮箱错误，改成正确的格式就能请求成功，返回200。
由于HTTP取样器自带的请求是有限的，因此需要详细了解里面的配置元件的功能，才能更好的契合项目实战的需要。
接下来就详细学习一下配置元件吧。
HTTP核心配置------配置元件
含义 ：在JMeter当中，配置元件是一类特殊的测试元件 ，它们不直接向服务器发送请求，而是用于修改或配置取样器发出的请求内容。（与取样器相互配合）
配置元件有优先级，在收集和加载时有非常高的优先级，但是主要还是以取样器为主，配置元件没有顺序要求，放在什么地方都可以。
注：一个配置元件会对其所在层级及以下所有层级的取样器生效。
下面介绍一下几个常用的配置元件。如果想要学习的更加深入，参考这个文章：Jmeter(八) - 从入门到精通 - JMeter配置元件（详解教程） - 北京-宏哥 - 博客园
这篇文章的配置元件都是英文，可自行参考学习。
1.HTTP请求头管理器
HTTP 信息头是构成 HTTP 请求和响应的必要组成部分，它以键值对的形式传递关于请求或响应的元数据。对于接口测试而言，我们最常关注请求头 (Request Header)。
- Content-Type ：指定请求体数据格式，传 JSON 就用**
application/json** ，表单传参用**x-www-form-urlencoded**； - Authorization：存放登录 token，做接口身份鉴权；
- User-Agent：标识客户端设备 / 浏览器，用来伪装请求来源。
2.HTTP Cookie管理器
HTTP 协议本身是无状态的（Stateless），即服务器不会记录连续请求之间的关系。为了解决这个问题，引入了Cookie 机制。
当用户首次登录成功后，服务器会生成一个唯一的身份标识（Session ID）并通过响应头（Set-Cookie）发送给客户端，客户端（如浏览器）会存储这个 Cookie。
在后续的请求中，客户端会自动携带此 Cookie，服务器据此便能识别出是哪位用户在进行操作，从而维持了用户的登录状态，这个过程称为会话(Session)。
Jmeter 想要保持登录态（登录后调用需要登录才能访问的接口），必须添加：HTTP Cookie 管理器 ，自动接收、存储、传递 Cookie，自动维持 Session 会话。
3.HTTP默认请求值
然后在刚才创建的请求当中就可以省略前面的协议、服务器名称以及端口号。
执行优先级规则（核心重点）
- 如果单个 HTTP 取样器里：服务器地址、端口这些输入框留空不填写 → 自动取用【HTTP 请求默认值】里配置好的内容；
- 如果单个 HTTP 取样器自己手动填写了服务器、端口 → 优先以取样器自身填写内容为准，会覆盖默认值配置。
这里挑选了三个配置元件来做一个详细的讲解，其他的配置元件可自行学习上面的文章！
四、用JMeter来进行性能测试
性能测试一般在最后一个环节来做，甚至在交互之前才做。
1.理解需求，理解指标，熟悉性能测试类型
例如：
需求1：下单之后，验证某一功能能否在100-200个并发的情况下，各项性能指标达到要求。
需求2：下单之后，验证某一功能是否能够在每秒完成20笔交易。
在面试时，可能会问到------TPS和并发数以及平均响应时间之间的关系？
理论上：TPS=并发数/平均响应时间
实际上：TPS=总样本数/总运行时间
需求3：（不明确指标）某一小程序，用户数100万，日活2万，测试小程序日活10万，评估这一小程序能否在这个条件下正常运行。
常见的性能指标主要有：
并发用户数：系统用户数、在线用户数、最大最优并发数
吞吐量：TPS（可能包含有多个请求的情况下，会不一样）、RPS、QPS
实事务成功率：0.1%以下
资源利用率：80%以下
响应时间：1.5s以下（可能需要考虑标准偏差）
在使用JMeter做完性能测试之后，可以在聚合报告、图表、Prometheus、日志中查看以上数据。
学过软件测试基础的就能知道，测试包含多种类型，所以一定要分清楚测试的类型：
性能测试：（指标测试）
基准测试
负载测试
压力测试
稳定性测试
2.性能测试全过程掌握以及性能文档编写
先进行需求分析(测试组评审)------>计划和方案（方案决定怎么做）------>准入检查（Grafana+Prometheus）------>执行性能测试------>分析报告以及调优
这里附一个Prometheus的官方学习文档：开始使用 | Prometheus - Prometheus 监控系统
3.精通JMeter性能压测工具场景应用
这里首先要学会JMeter的接口测试步骤（精通），然后学习如何使用JMeter来进行性能压测。
这张图片展示的就是一个项目中的各个功能模块的压测测试，其中同步定时器的核心目的就是模拟大量用户同一时刻并发请求，制造瞬间峰值压力。
默认情况下，100 个线程用户会陆陆续续发起请求，达不到同一秒并发冲击服务器的效果； 添加同步定时器后，线程会被拦住等待，凑够设定的用户数才会统一放行，一起发起请求 ，专门用于秒杀、抢购、并发提交这类瞬时高并发场景压测。
如何人为的去控制并发数：
- 自由并发 最接近真实的场景，但是，是不稳定的，是压力比较小的
- 人为并发 (人为的加同步定时器，确定具体并发多少，增加瞬时压力)
对于jp@gc 系列监听器（第三方插件监听器）这里做一个详细介绍。
jp@gc 开头的组件，都属于 JMeter 插件管理器（JMeter Plugins） 提供的拓展监听器，原生 JMeter 没有自带，需要提前安装插件才可使用； 作用：可视化监控压测全过程的动态性能曲线，直观查看服务器、接口各项指标实时变化，是性能测试最常用的图表监控工具。
1. jp@gc - Active Threads Over Time
名称：随时间变化的活跃线程数图
- 用途：绘制折线图，展示压测全程每一秒正在运行的并发用户（活跃线程）数量走势
- 使用场景：
（1）查看线程启动节奏：验证线程组是否按照你设置的增速逐步拉起用户
（2）查看运行期间线程有无异常掉线、提前结束
通俗理解：看图就能知道：什么时候拉起来多少并发用户。
2. jp@gc - Response Times Over Time
名称：随时间变化的响应时间曲线图
- 用途：记录压测每一秒接口的平均响应耗时变化
- 核心价值：
（1）并发量慢慢上涨后，查看接口响应时间会不会逐渐变长（服务器压力越大，返回数据越慢）
（2）定位卡顿拐点：找到响应时间突然飙升的时刻，代表服务器开始承压不足
通俗理解：全程盯着接口快慢变化。
3. jp@gc - Transactions per Second
名称：每秒事务数（TPS/QPS）走势图
- 核心指标：TPS（每秒能成功处理的请求事务数量），衡量服务器吞吐能力最核心指标
- 作用：查看压测全过程系统每秒处理请求量的变化
（1）正常趋势：并发升高 → TPS 先上涨，到达峰值后趋于平稳；
（2）服务器瓶颈：TPS 到达上限后不再上涨，甚至下降，代表系统已经顶不住压力。
4. jp@gc - PerfMon Metrics Collector
名称：服务器资源监控收集器（硬件资源监控）
- 作用：远程采集被测服务器硬件资源使用数据，并生成曲线图表
- 可监控内容： CPU 使用率、内存占用、磁盘 IO 读写、网络带宽、磁盘空间等服务器底层资源
- 测试意义： 定位性能瓶颈根源：
（1）CPU 跑满 100%：瓶颈在处理器；
（2）内存持续暴涨溢出：瓶颈在内存； 是性能调优必不可少的监控工具。
前置条件：服务器需要提前部署
ServerAgent配套程序，才能采集资源数据。
这里还有三个组件在企业项目的实际应用当中必不可少。
1.仅一次控制器（Once Only Controller）
被它包裹的所有接口，不管线程循环跑多少遍，整套内容全程只会执行 1 次。
- 模拟真实用户行为：只登录一次 用户打开网站一辈子只需要输入账号密码登录一回，后续反复逛页面、发帖、退出，不用每次都重新登录。 把【登录接口】放进仅一次控制器： 线程启动只登录 1 次，之后循环执行浏览帖子、发帖操作时，不会重复调用登录接口，完全贴合正常人上网逻辑。
- 节省服务器资源、压测数据更精准 反复登录会不停生成新会话、占用服务端内存，干扰发帖、浏览接口的性能统计，只登录一次能保证压测结果纯粹。
登录初始化、获取全局 token、加载首页基础配置这类只需要执行一遍的前置操作。
2.事务控制器（发帖事务）
把一连串连贯、属于同一个完整业务动作的多个接口打包捆在一起，算作 1 个事务（1 次业务操作）
- 统计业务整体耗时，而非单个接口耗时（性能测试最关键） 用户视角：我点发帖、写完内容提交，完整发出去一篇帖子，这才叫 1 次发帖行为。 后台拆成了 2 个接口：进入发帖编辑页、提交帖子。 不加事务控制器：聚合报告只会分别展示两个接口各自的响应时间； 加了之后：会额外统计整套发帖全过程总耗时，用来衡量用户操作体验快慢，给产品、运维看整体业务性能指标。
- 事务内要么全成功，要么整体算失败 两个接口任意一个报错（进编辑页失败 / 提交内容失败），整个发帖事务都会标记为失败，精准统计业务操作失败率，更贴合线上真实故障场景。
下单事务：查看购物车→结算→提交订单→支付，一整套打包成事务，统计下单全流程性能。
3.吞吐量控制器（Throughput Controller）
**控制接口执行次数比例，分配不同业务的访问权重。**简单说：用来规定「跑多少次浏览帖子，才允许跑多少次发帖」，模拟网站不同功能被用户点击的频次差异。
线上真实情况： 90% 用户都是逛帖子、看内容；只有 10% 用户会主动发帖写内容。浏览操作频次远远高于发帖。 用吞吐量控制器就能精准配比流量：
- 设置比例：每访问 9 次浏览页面，才允许执行 1 次发帖事务
- 压测出来的数据完全贴合线上用户流量分布，压测结果才有参考价值，而不是所有接口均等频次跑。
两种常用控制模式
- 按百分比控制：发帖事务只分配 10% 的执行流量；
- 按固定次数控制：总共运行 1000 次请求，发帖只执行 100 次；
性能摸底：想要测试次要功能（发帖）在大流量浏览请求冲击下，还能不能稳定运行。
小提醒：在做性能测试时不要用GUI界面（图形用户界面），会出现BUG。
要用命令行，生成jtl报告，然后放到JMeter当中生成图表。
五、性能瓶颈分析与性能调优
对于一个测试人员，一定要有分析能力（全方位），知道问题所在，然后和开发人员汇报问题。
这是市面上最主流的性能架构图，可以做一个参考分析。
企业的标准流程是：
- 基线测试：少量并发跑一遍，记录初始 TPS、响应时间；
- 加压测试：慢慢调高并发，直到系统性能开始下降、出现报错；
- 对照监控数据，定位具体瓶颈点；
- 修改代码 / 配置 / 数据库进行优化；
- 优化完重新压测，对比前后性能指标；
- 反复迭代，直到满足项目性能需求（比如要求 TPS 达到 500，响应时间低于 300ms）。
举个论坛发帖业务例子
压测发帖接口： 并发涨到 80 用户之后，TPS 不再上涨，响应时间从 100ms 涨到 800ms；
查看监控：MySQL CPU 100% 结论瓶颈：发帖写入数据库无索引 + 频繁插入拖慢速度 调优：给帖子表字段加索引 + 发帖内容存入 Redis 缓冲，优化后 TPS 直接翻倍。
以上就是今天的学习情况啦。
