简介这份PPT面向需要系统掌握JMeter性能测试流程的测试工程师与培训学员围绕数据制造、方案设计、脚本执行、监控调优与报告编写五个环节展开帮助读者建立从准备到复盘的完整方法论。内容结合云影像系统实例讲解用JMeter参数化脚本模拟HTTP请求造数据的具体步骤对比存储过程与Java代码插数的效率差异并给出测试环境软硬件清单、AWR与慢日志等监控指标参考以及聚合报告、ServerAgent、PerfMon Metrics Collector等工具的配置思路。资源包共1个pptx文件约12.48MB以图文并茂的幻灯片形式呈现便于课堂讲授与自学对照。目前已有1150人学习适合希望把性能测试流程落地到实际项目中的初中级测试人员参考。1. 从一份 PPT 说起性能测试培训为什么绕不开 JMeter很多团队做性能测试第一反应是“上工具”结果脚本跑起来了数据没铺够、环境没对齐、监控没开压出来的结果自己都不敢信。这份《性能测试-Jmeter.pptx》培训材料讲的正是这条链路上最容易断的几节造数据、写方案、执行脚本、监控调优、出报告。它不教你 JMeter 的按钮在哪而是把一次完整压测从准备到收尾的工序摊开适合已经会用 JMeter 发请求、但压出来的数说不清楚的从业者。下面按材料里的真实工序拆一遍能抄的步骤直接给坑也一并标出来。2. 造数据100 万条铺底数据怎么在一天内落地性能测试里最容易被低估的环节就是数据准备。材料把数据分成三类初始化数据系统启动必需的基础配置、铺底数据历史存量决定查询类接口的真实耗时、参数化数据每次请求变化的字段。以某影像登记系统为例登记保存模块要求 100 万条存量涉及 EXAM_REQUEST、EXAM_PATIENTVISIT 等多张关联表。数据不够索引选择性失真查询响应时间会假性偏快数据造错压测结论直接作废。2.1 两条造数据路线的取舍材料给了两条路我把它们的边界整理成表选型时对着看就行方式实现手段速度主要风险适用场景接口模拟JMeter 参数化脚本打 HTTP 请求约 2–5 万条/小时受接口校验、限流影响不熟悉表关系、要求数据真实直插数据库存储过程 / Java 代码约 10–20 万条/小时SQL 写错产生脏数据表关系清晰、时间紧材料作者选了第一条理由很实在不清楚业务表之间的外键与状态流转关系硬写 SQL 大概率造出“看起来有、业务上不成立”的脏数据返工成本比慢一点高得多。这个判断值得记住——造数据的第一原则是“数据要能被业务逻辑认”速度排第二。2.2 接口造数据的五步操作具体工序材料写得很细我按可复现的顺序重排并补上每步的检查点第一步抓接口。用抓包工具抓登记保存接口的完整请求重点记录请求头里的鉴权字段、请求体里的必填项和业务状态字段。检查点确认抓到的请求在浏览器里重放一次能成功否则后面全白搭。第二步参数化。把请求体里需要变化的字段抽成变量JMeter 里用 CSV Data Set Config 或函数助手生成。下面是一个参数化请求体的骨架示例# 请求体模板JSON变量用 ${} 占位 { patientId: ${patient_id}, examType: ${exam_type}, requestTime: ${__time(yyyy-MM-dd HH:mm:ss,)}, status: REGISTERED, orgCode: ${org_code} }逻辑说明patient_id从 CSV 读取保证唯一性exam_type用 Random 函数在枚举值里取requestTime用内置时间函数保证递增status固定为业务允许的初始态。参数说明唯一性字段必须走 CSV 而不是随机数随机数在百万级下碰撞率不可忽略一旦主键冲突接口返回失败但你未必看得到。第三步小批量调试。设 10 个线程各跑 1 次看聚合报告的错误率是否为 0。检查点不要只看 HTTP 200要核对响应体里的业务码很多系统失败也返回 200。第四步批量造数。100 万条按 20 线程 × 50000 次循环配置线程组里勾选“调度器”控制总时长避免跑飞。第五步挂到持续集成服务器上跑。材料特别提到放 Jenkins 上是因为要跑很久本地机器不能关机。这里补一句血泪经验造数脚本和压测脚本要分开放别让造数的线程组混进压测计划里否则压测时数据还在涨结果没法复现。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, BODY, CREATETIME) values(sys_guid(), 1.0, 4aa066b7-1660-4ae7-b84c-98eaea24a3ce111, {code:12345678,msgId:12345678:abort}, sysdate); end loop; commit; end;逻辑说明sys_guid()生成主键循环体控制单次提交量commit放在循环外减少事务开销。参数说明循环上限 300 是单次提交批次实际造百万级数据时外层再套一层调度或改大上限但单次提交别超过几千条否则回滚段压力大。注意这段样例里的 BIZID 是写死的真实场景要按业务规则生成写死会导致后续按业务 ID 查询的接口全部命中同一条记录压测结果完全失真。3. 方案与脚本把压测需求翻译成可执行的线程组方案设计不是写文档交差它决定了后面所有数字有没有解释力。材料把方案拆成四块性能需求规格、环境清单、测试方法与工具、业务场景案例。这四块缺一块报告就站不住。3.1 环境清单要细到端口和版本材料给的环境表值得照抄格式硬件和软件分开列客户端、应用服务器、数据库服务器三行起步角色IP硬件软件测试客户端10.1.1.18016 核 / 8G / 500GWin10 JMeter 5.1.1 及 agent应用服务器10.8.3.19916 核 / 64G / 500GWinServer2012 JDK1.8 Tomcat8 nginx1.10数据库服务器10.8.3.17316 核 / 64G / 500GWinServer2012 Oracle 19c注意客户端只有 8G 内存这是常见配置但并发线程数上去后 JMeter 自身会吃内存压测中途客户端先 OOM 的话你看到的事务失败全是假象。经验做法是客户端内存至少给到 16G或者用分布式压测把线程分散到多台机器。3.2 脚本结构控制器和集合点怎么摆材料强调两点请求之间有先后顺序用事务控制器同步进行的用简单控制器请求执行前加同步定时器当集合点。这两条直接决定压测模型对不对。事务控制器的意义是把“登录→查询→提交”打包成一个事务统计响应时间否则你看到的是单个接口耗时不是用户感知耗时。同步定时器的意义是让线程真正同时发压模拟集合点不加的话线程是陆续启动的峰值压力被摊平测出来的并发是虚的。聚合报告必须加材料把它列为脚本标配。报告里重点看三列90% 响应时间、错误率、吞吐量。错误率非 0 时先别急着调优先确认是脚本问题还是系统问题。3.3 服务端监控的两条接入路径材料给了两条监控路径。第一条是 ServerAgent服务端装 JMeter 的 ServerAgent 插件Windows 双击 startAgent.batLinux 跑 startAgent.sh确保客户端到服务端 4444 端口通然后在 JMeter 里加 PerfMon Metrics Collector 看 CPU 和内存。第二条是网络不通时的替代方案用 nmon 之类的系统工具采集事后取文件分析。4444 端口不通是高频翻车点现象是监控器一直显示无数据原因多半是服务端防火墙没放行或 agent 没启动。解决顺序先在服务端本地 telnet 127.0.0.1 4444 确认 agent 活着再从客户端 telnet 服务端 IP 4444 确认链路通两步都过再回 JMeter 配置。3.4 JVM 层监控jconsole 看什么材料用 jconsole 做 JVM 监控服务端先开远程 JMX 端口本地输入 IP:端口连接。重点看两个页签内存页签相当于可视化的 jstat看 Full GC 后占用是否回落线程页签相当于可视化的 jstack看有没有长时间停顿的线程。线程停顿的常见原因材料列了三类等外部资源数据库连接、网络、死循环、锁等待。压测中出现响应时间突然飙升而 CPU 不高优先去线程页签找阻塞点。4. 执行与监控压测跑起来之后盯什么脚本调通只是开始执行阶段的功夫在“边压边看”。材料把执行拆成配置检查、场景执行、结果记录三段中间穿插了 AWR 快照的手工触发这块是很多新手会漏的。4.1 执行前的六项配置核对按材料顺序用例命名规范、控制器选型、同步定时器、聚合报告、ServerAgent 连通、jconsole 远程连接。这六项我建议做成一张检查单每次压测前逐项打勾。尤其是同步定时器调试阶段可以先关掉正式压测前必须打开否则并发模型和方案对不上。4.2 AWR 快照的手工触发Oracle 默认每小时自动打一次 AWR 快照压测场景如果只跑十几分钟自动快照可能一个都没覆盖到。材料的做法是手工触发-- 压测前打一个基线快照 exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(); -- 压测结束后再打一个 exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(); -- 生成报告 ?/RDBMS/ADMIN/awrrpt.sql逻辑说明两个快照之间就是压测窗口生成报告时选这两个快照 IDAWR 只分析这段区间。参数说明?代表 Oracle Home 路径在 sqlplus 里直接这么写能解析。注意材料提到 11g 需要额外跑 addmrpt.sql 才有优化建议19c 两个脚本已合并版本不同别照搬。4.3 日志里的四类关键字材料把日志排查放在调优第一节给了四个关键字OutOfMemoryError / Cannot allocate memory 指向内存溢出SQLException 指向数据库语句异常Connection closed / connection refused 指向连接数打满。压测中错误率抬头时先 grep 这四个词比盲目看监控曲线快得多。我的习惯是压测脚本里挂一个后台 tail 日志的任务出错当场截一段事后复盘不用猜。5. 避坑压测结果不可信的五个常见原因这一节按“现象→原因→解决”写都是材料场景里真实会遇到的。现象一造数脚本跑了一夜数据量对不上。原因接口有幂等校验或唯一约束重复请求被静默丢弃JMeter 只看 HTTP 状态码看不出。解决造数脚本里加响应断言校验业务返回码失败计数单独统计跑完先对账再压测。现象二并发设了 200服务端 CPU 只有 30%。原因同步定时器没加或超时设置过短线程没真正集合就放行实际并发远低于设定值。解决同步定时器超时设为 0无限等待或大于单请求最大耗时压测时看聚合报告的活跃线程数确认。现象三响应时间曲线在某个点断崖式上升。原因数据库连接池打满后续请求排队。解决压测前确认连接池上限监控里加连接池活跃数指标断崖点对应的并发数就是连接池瓶颈值这个数比平均响应时间更有价值。现象四Full GC 后内存不回落怀疑内存泄漏。原因可能只是压测数据量太大导致老年代增长未必是泄漏。解决撤压后观察一段时间内存仍不恢复才判定泄漏材料里也是这么说的压力撤除后依旧不恢复十有八九是泄漏。现象五AWR 报告里 Top SQL 全是造数时的插入语句。原因造数和压测没隔离快照窗口混进了造数流量。解决造数完成、数据对账通过后再打基线快照造数和压测分两个时间段别图省事连着跑。6. 从报告反推瓶颈一个可复用的判读顺序报告不是把聚合报告截图贴进去就完事。材料把报告要素列为测试目的、环境、方法、结果、瓶颈分析、调优建议其中瓶颈分析才是读者真正要看的部分。我自己的判读顺序是固定的从外到内四层每层都有对应的证据来源。第一层看事务级指标。聚合报告里 90% 响应时间和错误率是入口错误率非 0 先归因到具体接口再看该接口对应的日志关键字。第二层看服务端资源。PerfMon 的 CPU 曲线要区分 User、Sys、Wait材料特别提醒 CPU 高不一定是问题长期 80% 以上才值得关注Wait 高要去查磁盘 I/O 或全表扫描。第三层看 JVM。jconsole 内存页签看 Full GC 后回落情况线程页签看阻塞线程的堆栈锁等待和连接等待在这里现形。第四层看数据库。AWR 的 Top SQL 按 elapsed time 排序慢 SQL 和行争用一目了然。四层证据对不上时以事务级指标为准因为那是用户感知。资源层指标好看但事务慢多半是链路中间有排队比如 nginx 或连接池资源层指标差但事务快可能是压测时长不够还没到资源瓶颈的并发点。一个具体技巧把每轮压测的并发数、90% 响应时间、错误率、CPU 峰值、Top SQL 耗时记成一行跑五六轮就是一张趋势表。趋势表比单次报告有说服力得多调优前后各跑一轮改善幅度直接可量化。材料里“记录测试结果包括截图和数据”说的就是这个意思截图是证据趋势表是结论。从那以后我每次压测前都强制走一遍“数据对账→环境核对→监控连通→基线快照”四步少一步后面就得返工。这份材料的价值不在于教你 JMeter 怎么点而在于把这四步的工序和判断标准写清楚了照着走能少踩不少坑。希望帮到你。本文还有配套的精品资源点击获取