简介面向性能测试初学者与需要系统梳理JMeter实战流程的测试工程师这份PPT培训课件围绕真实项目场景把性能测试从准备到收尾的关键环节串成一条完整链路。内容覆盖数据制造、性能测试方案设计、脚本执行、性能监控与调优、测试报告编写五大模块既有JMeter参数化脚本造数据与存储过程造数据的效率对比也有测试环境软硬件清单、AWR与PerfMon等监控指标参考还涉及同步定时器、事务控制器及Jenkins持续运行等实操细节。资源包共1个pptx文件约12.48MB以图文并茂的幻灯片形式呈现便于课堂讲解与自学翻阅。目前已有1150人学习适合希望借助具体案例理解性能测试组织方式、补齐方案设计与调优思路的读者参考。1. 从一份 JMeter 培训 PPT 说起性能测试到底卡在哪很多人第一次做性能测试卡住的地方往往不是 JMeter 怎么用而是数据从哪来、方案怎么写、脚本跑起来之后服务器到底发生了什么。这份《性能测试-Jmeter.pptx》培训材料把整条链路拆成五段造数据、写方案、执行脚本、监控调优、出报告。它面向的是已经会用 JMeter 发请求、但还没独立扛过一次完整压测的从业者也适合需要把性能测试流程规范化的小团队拿来当内部培训底稿。材料里给的是 JMeter 5.1.1 配合 Oracle 19c、Tomcat 8、Jenkins 的一套实操路径不是泛泛而谈的方法论下面按能复现的顺序拆开讲。2. 造数据的两条路JMeter 参数化脚本与存储过程怎么选压测前先把数据准备好这一步决定了后面脚本能不能跑出有意义的曲线。材料里把数据分成三类初始化数据、铺底数据历史数据和参数化数据。初始化数据是系统能跑起来的基础配置铺底数据是为了让查询、分页、关联查询有足够的历史量参数化数据则是每次请求要变化的字段。以某登记业务为例新建登记模块和登记保存模块各需要 100 万条数据涉及 EXAM_REQUEST、EXAM_PATIENTVISIT 等表。数据量不够压测时数据库走的是空表或小表索引命中、缓存命中都和真实场景差很远出来的响应时间没有参考价值。2.1 两种造数据方式的取舍材料里明确对比了两条路。第一条是用 JMeter 写参数化脚本模拟 HTTP 请求往系统里灌数据。优点是走的是真实业务接口不用去理数据库表之间的外键和关联关系造出来的数据天然一致缺点是速度慢一小时大概 2 到 5 万条。第二条是写存储过程或 Java 代码直接往表里插。优点是快一小时 10 到 20 万条缺点是要先弄清楚表之间的关联关系SQL 写错就是脏数据得推倒重来。材料作者选的是第一条理由很实在对云影像系统的表关系不熟时间也够。这个判断值得借鉴——如果压测目标系统是别人开发的、表结构没有文档硬写存储过程的风险远大于多跑几个小时脚本。反过来如果表关系清晰、数据量要求上千万直接插库才是合理选择。2.2 用 JMeter 灌数据的五步操作具体步骤材料给得很细我按可复现的顺序整理如下。第一步用抓包工具抓出登记保存接口的完整参数。Fiddler 挂上之后在页面上正常操作一次把请求头、请求体、Cookie 都留下来重点看哪些字段是每次变化的、哪些是固定值。第二步对变化的字段做参数化。JMeter 里常用 CSV Data Set Config 或者函数助手下面是一个 CSV 配置的典型写法# data.csv 示例第一行是变量名后面每行一条数据 patientName,idCard,visitNo,deptCode 张三,110101199001010011,V20240001,D001 李四,110101199001010012,V20240002,D002!-- JMeter 线程组下 CSV Data Set Config 的关键配置 -- CSVDataSet guiclassTestBeanGUI testclassCSVDataSet stringProp namefilenamedata.csv/stringProp stringProp namevariableNamespatientName,idCard,visitNo,deptCode/stringProp boolProp namerecycletrue/boolProp boolProp namestopThreadfalse/boolProp stringProp nameshareModeshareMode.all/stringProp /CSVDataSetrecycletrue表示文件读完后从头循环造数据场景必须开stopThreadfalse保证某一行数据异常时线程继续跑而不是整体停掉shareMode.all让所有线程共享同一个文件指针避免每个线程各读一份导致数据重复。如果字段需要唯一值可以在 CSV 基础上拼时间戳或使用 UUID 函数比如${__UUID()}但要注意接口是否对格式有校验。第三步先小规模调试。线程组设 10 个线程、循环 1 次跑一遍看响应断言是否全绿。这一步别省参数化字段类型不对、必填项漏传、Token 过期都会在这一步暴露。第四步确认调试通过后开始批量灌。材料给的经验值是 100 万条数据用 20 个线程循环 50000 次20 × 50000 正好 100 万。线程数不要盲目加大接口背后是应用服务器和数据库线程太多反而把目标系统压出异常造出来的数据可能一半是失败的。第五步执行位置的选择。本地 PC 跑意味着连续几小时不能关机材料建议放到 Jenkins 服务器上持续运行。Jenkins 上部署的 JMeter 版本要和本地一致材料里两边都是 5.1.1版本不一致时函数行为、插件兼容性都可能出问题。2.3 存储过程造数据的样例与边界材料也给了一段 Oracle 存储过程样例核心是用循环批量插入create or replace procedure T_ESB2_AUDIT_sp as begin for i in 1 .. 300 loop insert into t_esb2_audit_new( FID,VERSION,BIZID,BIZDESC1,BIZDESC3,REQID,RESID, SOURCESYS,TARGETSYS,ESBSVCCODE,BACKSVCCODE, EXGPTN,RESULTCODE,BODY,CREATETIME ) values( sys_guid(),1.0,4aa066b7-1660-4ae7-b84c-98eaea24a3ce111, http://192.168.67.12:50806/ESB_FOSS2ESB_PUSH_FORM_TRAJECTORY2DOP, 192.168.20.14,63528dad-2222-4489-af6f-4ab05be641b4, 3f7be047-52c7-4574-8523-3ea716531219,FOSS,UIP, ESB_FOSS2ESB_PUSH_FORM_TRAJECTORY2DOP, DOP_ESB2DOP_PUSH_FORM_TRAJECTORY2DOP,1,0, {code:12345678,company:KUAIDI100,msgId:12345678:abort,watchStatus:abort}, sysdate ); end loop; commit; end;sys_guid()生成主键sysdate填当前时间循环 300 次后统一 commit。这段样例的价值在于演示结构实际用的时候有几个参数要改循环次数按目标数据量除以单次插入条数算commit放在循环外可以减少提交次数、提升速度但事务太大时回滚段压力也大常见做法是每 1000 到 5000 条提交一次BODY 字段里的 JSON 如果业务会解析字段名和取值要符合接口约定否则造出来的数据在查询时可能被过滤掉。另外直接插库绕过了应用层校验如果表上有触发器或约束插入顺序不对会直接报错这也是材料说“SQL 写错导致脏数据”的具体来源。3. 性能测试方案怎么写环境清单、监控指标与场景设计方案不是写给自己的备忘录是给项目组、运维、开发对齐用的文档。材料里把方案拆成四块性能需求、环境清单、测试方法与工具、业务场景案例。3.1 性能需求与环境清单性能需求一般由项目组提供也就是性能测试需求规格说明书里面写清楚并发用户数、响应时间上限、事务成功率要求。没有这份东西压测跑出来的数字没法判定合格与否。环境清单要分硬件和软件两张表材料给的格式可以直接抄服务器类型IPCPU内存硬盘系统测试客户端10.1.1.18016 核8G500Gwin10应用服务器10.8.3.19916 核64G500Gwin2012数据库服务器10.8.3.17316 核64G500Gwin2012服务器类型IP软件配置测试客户端10.1.1.180Windows 10 旗舰版 SP1 64 位JMeter 5.1.1 及 agent应用服务器10.8.3.199Windows Server 2012 R2 Standard 64 位JDK 1.8Tomcat 8.0nginx 1.10数据库服务器10.8.3.173Windows Server 2012 R2 Standard 64 位Oracle 19c环境清单的意义在于复现和归因。压测结果异常时第一件事就是核对客户端、应用、数据库三层的配置是否和方案一致客户端内存只有 8G 却开 500 个线程瓶颈可能先在压测机自己身上。3.2 监控指标与采集方式材料列了一张指标表我按采集方式重新组织指标参考值采集方式数据库 Top SQL查看耗时或消耗资源高的 SQLAWR、ADDM用户数线程组中的线程数JMeter事务响应时间每笔事务平均响应时间变化JMeter事务成功率Err 为 0 即 100%JMeterCPU 使用率压测中服务端 CPU 情况JMeter ServerAgent内存使用率压测中服务端内存情况JMeter ServerAgentOracle 侧用 AWR 报告看整体负载和 Top SQLMySQL 侧对应的是慢查询日志。这里有个容易忽略的点AWR 默认每小时自动打一次快照如果单个场景只跑十几分钟快照可能覆盖不到材料给的做法是场景跑完手工执行一次快照-- 手工创建一次 AWR 快照 exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(); -- 生成 AWR 报告? 代表 ORACLE_HOME ?\RDBMS\ADMIN\awrrpt.sql;Oracle 11g 如果要看 SQL 优化建议还需要额外跑ADDMrpt.sql19c 里两个脚本已经合并不用再单独执行。这个版本差异材料特意标了出来跨版本迁移脚本时容易踩。3.3 业务场景怎么设计场景设计要贴着真实业务走。材料以云影像系统为例把接口按调用关系分成同步和异步两类多个请求同时发、互不依赖的用简单控制器并列有先后顺序的用事务控制器包起来事务控制器会把内部请求的耗时合并成一个事务统计。每个请求前加同步定时器Synchronizing Timer作用类似集合点让线程攒够一批再同时发出模拟真实并发瞬间。场景设计还要写清楚每个场景的并发数、持续时间、数据量、通过标准这些数字后面写报告时直接引用。4. 脚本执行与监控落地从 ServerAgent 到 jconsole脚本能跑通和脚本能用于压测是两回事。材料在这一章给了 7 个配置点我按执行顺序合并成可操作的步骤。4.1 脚本结构与命名规范脚本按用例组织一个用例对应一个业务场景用例名写清楚模块和操作比如“登记保存-单接口-50并发”。请求之间同步的用简单控制器有先后依赖的用事务控制器。执行前在请求前挂同步定时器线程数设为目标并发数超时时间按业务容忍度设超时后不再等待直接放行。聚合报告必须加它是后面出报告的数据源。4.2 ServerAgent 与 PerfMon 的配置服务端监控靠 JMeter 的 ServerAgent。Windows 服务器双击startAgent.batLinux 执行startAgent.sh默认监听 4444 端口。测试客户端要能通到服务端的 4444 端口网络不通时材料建议换 nmon 等工具不要在这一个点上耗太久。# Linux 服务端启动 ServerAgent cd /opt/ServerAgent chmod x startAgent.sh ./startAgent.sh # 客户端验证 4444 端口连通性 telnet 10.8.3.199 4444客户端在 JMeter 里加 PerfMon Metrics Collector 监听器填服务端 IP 和 4444 端口勾选 CPU、Memory、Disk I/O 等指标。PerfMon 是可选插件需要先在插件管理器里装上版本和 JMeter 5.1.1 要匹配。指标采集间隔默认 1 秒左右压测时间短的话可以调小但间隔太小会增加服务端负担。4.3 jconsole 看 JVM 内存与线程应用服务器是 Java 的话jconsole 是最直接的 JVM 观察窗口。前提是服务端开启 JMX 远程端口Tomcat 的catalina.bat或启动参数里加# Tomcat 开启 JMX 远程监控的典型参数 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port9999 -Dcom.sun.management.jmxremote.authenticatefalse -Dcom.sun.management.jmxremote.sslfalse -Djava.rmi.server.hostname10.8.3.199本地 jconsole 输入10.8.3.199:9999连接。材料说主要看内存和线程两个页签内存页签相当于可视化的 jstat重点看 Full GC 后占用是否回落压力撤除后内存不恢复基本就是泄漏线程页签相当于可视化的 jstack线程长时间停顿常见原因是等外部资源数据库连接、网络、设备、死循环、锁等待。authenticatefalse和sslfalse只适合内网压测环境生产环境不要这么配。4.4 执行与结果记录按场景设线程数跑完记录聚合报告的截图和数据。复杂场景建议每个场景跑完手工打一次 AWR 快照简单场景可以全部跑完再统一生成报告。结果记录要包含时间、并发数、TPS、平均响应时间、错误率、服务端 CPU 和内存峰值这些是写报告和调优的原始素材。5. 避坑与排查压测现场最容易翻车的五件事5.1 造数据跑了一半发现大量失败现象灌数据脚本跑了几个小时聚合报告错误率突然升高。原因参数化数据重复触发唯一约束或者 Token 过期、会话失效。解决造数据前先确认接口是否有幂等或唯一性校验CSV 里加唯一字段长时间运行前把登录态做成 setUp 线程组定期刷新别指望一个 Token 跑到底。5.2 压测曲线很好看但服务器没压力现象TPS 很高、响应时间很短但服务端 CPU 和内存几乎没动。原因请求打到了 nginx 静态页或缓存根本没进应用或者同步定时器没生效线程是陆续发的不是并发的。解决核对请求 URL 和参数是否命中真实业务接口抓包对比检查同步定时器的“模拟用户组数量”是否等于线程数。5.3 ServerAgent 连不上导致监控空白现象PerfMon 监听器一直无数据压测结果只有 JMeter 侧指标。原因4444 端口被防火墙拦、ServerAgent 没启动、或者客户端和服务端网段不通。解决先在服务端netstat -an | grep 4444确认监听再从客户端 telnet 验证不通就换 nmon 或系统自带监控别让监控缺失拖住整个压测。5.4 AWR 报告里找不到压测时段现象生成 AWR 报告后压测时间段的快照缺失或间隔太大。原因AWR 默认一小时一次快照短场景落在两次快照之间。解决场景跑完手工执行CREATE_SNAPSHOT()再生成报告复杂场景每个场景一次别攒到最后。5.5 内存泄漏误判现象压测中内存持续上涨判定为泄漏。原因没看 Full GC 后的回落情况或者压力还没撤除就下结论。解决观察 Full GC 后占用是否回到基线压力撤除后等一段时间再看结合 jconsole 线程页签排除线程阻塞导致的堆积单看一条上涨曲线不够。6. 从监控数据到调优结论一个可复用的判断顺序压测跑完数据一堆先看哪里我自己的习惯是按“日志 → CPU → 内存 → 数据库”的顺序过一遍这个顺序和材料里列的瓶颈点一致但落地时有些细节值得展开。先检索日志里的异常关键字。OutOfMemoryError或Cannot allocate memory指向 JVM 内存溢出SQLException后面通常跟着数据库返回的具体错误能直接定位到哪条 SQLConnection closed或connection refused一般是连接数不够应用侧连接池或数据库最大连接数到了上限。日志是成本最低的线索先看它。再看 CPU。CPU 高不一定是问题性能优化本来就要把硬件用满但长期高于 80% 就值得警惕。关键要区分消耗在 User、Sys 还是 WaitUser 高说明计算密集看是否有低效算法或大量序列化Sys 高看系统调用和上下文切换Wait 高往往是等 I/O材料举的例子是大表全表扫描没走索引CPU 大量时间处于 wait。这时候去 AWR 里找 Top SQL比盯着 CPU 曲线猜有用得多。内存看的是恢复能力。jconsole 内存页签里每次 Full GC 后占用如果逐次抬高、压力撤除后也不回落基本可以判定泄漏如果只是高位波动但能回落那是正常的高负载表现。线程页签配合看线程数持续上涨不下降结合 jstack 抓两次对比能看出是锁等待还是外部资源超时。数据库侧用 AWR 的 Top SQL 和 ADDM 建议交叉验证。Top SQL 按 elapsed time 排序排在前面的未必是执行次数最多的可能是单次最慢的行争用、行阻塞看 segment statistics 和 enqueue 相关段落。调优动作落到具体参数上SQL 加索引、连接池调大、Tomcat 线程数调整、JVM 堆参数调整每改一项单独复测一个场景别一次改五个参数否则不知道哪个起了作用。最后写报告时把测试目的、环境、方法、结果、瓶颈分析、调优建议按顺序摆清楚结果部分用聚合报告和 AWR 的原始数据说话别只写“性能良好”。从那以后我每次压测收尾都会强制自己按日志、CPU、内存、数据库这个顺序过一遍再下结论跳过任何一步都可能在报告里留下说不圆的地方。希望帮到你。本文还有配套的精品资源点击获取