一、脚本录制
第一种：创建http代理服务器进行脚本录制（可选，这种方式录制很多无用接口）
端口要设置和本机的代理端口一致为8888,录制的时候需要关闭fiddler
第二种：fiddler自动生成jmeter测试脚本
1.安装fiddler4.6及以上版本
2.下载jmeter插件JmeterExport.dll，保存至fiddler安装路径ImportExport文件夹下
3.重启fiddler，通过过滤器去抓包
正则条件过滤图片、js等文件，输入以下内容：
REGEX:(?insx)/[^\?/]*\.(css|js|ico|jpg|png|gif|bmp|wav)(\?.*)?$4.导出jmx文件
jmeter导入jmx文件报错解决：
1.下载安装jmeter插件http://jmeter-plugins.org/
2.下载插件jmeter-plugins-manager.jar，将该jar包复制到Jmeter的lib/ext目录下
3.重新启动Jmeter
4.打开Jmeter，单击菜单 选项—>Plugins Manager
5.进入Plugins Manager，下载json/yaml插件后重新导入jmx文件
二、脚本调试
必须流程
1. 添加http的cookie管理器
线程组--配置原件--http cookie管理器
2. 添加HTTP信息头管理器
3. 关联
在需要获取数据的接口中添加，后置处理器，正则表达式提取器
"data":"(.+?)"4. 添加参数化数据
线程组--配置原件--csv数据文件设置
5. 检查点
在需要检查的接口中添加--断言--响应断言
用的是响应文本断言，匹配字符串
可选流程
1. 测试场景
测试计划--线程组--jp@gc-uitmate Thread Group
一共300用户，分别三次加载完，每次加载100用户，每个用户持续运行100秒
2.一共300用户，一共运行三个阶段，每个阶段运行100人，每60秒增加100人，每5秒退出50人
2. 集合点
在需要添加集合的接口中添加
线程组---定时器--同步定时器
3. 循环控制器，仅一次控制器
如果场景仅循环一次或者仅一个接口循环多次，就可添加此类方法
线程组--取样器--循环控制器
线程组--取样器--仅一次控制器
4. 聚合报告
线程组--监听器--聚合报告
聚合报告的数据都是由毫秒显示
样本：请求数
吞吐率：Transactions per second
事务响应时间：response time over time
5. 分布式压测
首先需要负载机打开jmeter.server.bat
总结
jmeter压测首先就是录制脚本确定脚本的两种生成方式，第一种就是手写接口，但是这个需要提供接口文档，以及接口参数，如果是界面已经集成，则可以使用代理来录制脚本，这一点和loadrunner是很相似的
脚本录制好之后，首先是回放脚本，确保脚本能够调通，先添加测试原件中的HTTP cookie管理器，确保能够自动获取到cookie，在一个就是在某些登录接口，或者登录之后的接口需要做关联，因为一些session 或者token在登录后失效过期，这里可以使用后置处理器中的正则表达式提取器，来关联获取有返回token的接口的数据，再将其参数化给需要用到的地方
下来就是参数化，可以用到配置原件，中csv数据文件管理器中来添加csv的测试数据
下一个就是检查点，这里我习惯使用断言中的响应断言，来获取接口的返回值中的数据，来根据预期值判断是否成功
接下去就是集合点，集合点可以使用定时器--中的同步定时器，可根据并发的人数需求来设置并发的人数
准备分布式压测，因为如果压测数据过多，一台负载机无法产生过多的虚拟用户，则需要多台负载机一起生成虚拟用户，这里可根据其他机器，打开jmeter.server.bat文件即可启动负载机，然后再主控机这边配置文件，配置对应的负载机ip地址
测试场景的设置，可以使用插件来设置多样化的测试运行场景，人数加载，以及持续运行时间，
数据监控，可安装插件来多界面的观察，负载，响应时间以及吞吐率
性能分析
tps说明
通过红线的大致比对可以知道，当每线程每秒的请求数降到 55 左右的时候，TPS 就达到上限了，大概在 5000 左右，再接着往上增加线程已经没有用了，响应时间开始往上增加了。
CPU指标参数
1. us（User Time） • 用户态程序占用的CPU时间百分比。即用户进程在用户态下运行所使用的CPU时间，这些进程包括执行非系统内核代码的应用程序。高 us 值通常表示系统正在运行许多用户级应用程序。
2. sy（System Time） • 系统态程序占用的CPU时间百分比。即内核进程在内核态下运行所使用的CPU时间，包括系统调用和内核中的各种服务。高 sy 值可能表示有大量的系统调用或内核操作在执行。
3. ni（Nice Time） • 改变过优先级的用户态进程占用的CPU时间百分比。通过 nice 命令调整优先级的进程在用户态下运行所使用的CPU时间。高 ni 值表示有许多调整了优先级的进程在运行。
4. id（Idle Time） • CPU 空闲时间百分比。即CPU没有处理任何任务的时间百分比。高 id 值表示系统的CPU大部分时间处于空闲状态。
5. wa（I/O Wait Time） • CPU 等待I/O操作完成所占用的时间百分比。即CPU等待硬盘、网络等I/O设备完成操作的时间。高 wa 值通常表示系统I/O瓶颈，CPU花费了大量时间等待I/O操作完成。
6. hi（Hardware Interrupt Time） • 硬件中断占用的CPU时间百分比。即处理硬件中断（由外部设备如硬盘、网络卡等生成的中断）所使用的CPU时间。高 hi 值表示有大量的硬件中断在处理，可能是某个硬件设备工作异常或过于繁忙。
7. si（Software Interrupt Time） • 软件中断占用的CPU时间百分比。即处理软件中断（由软件生成的异常）所使用的CPU时间。高 si 值可能表示有大量的软中断需要处理，例如网络包的处理。
8. st（Steal Time） • 虚拟机偷取时间百分比。即虚拟机因物理机处理其他虚拟机任务而被偷取的CPU时间。高 st 值通常出现在虚拟化环境中，表示宿主机上的其他虚拟机占用了本虚拟机的CPU资源。
