简介这份《性能测试-Jmeter》培训课件面向测试工程师、开发人员及需要承担性能测试任务的技术团队围绕JMeter实战梳理从数据准备到报告复盘的完整链路。内容覆盖数据制造、性能测试方案设计、脚本执行、性能监控与调优、测试报告编写五个环节并结合云影像等业务场景说明初始化数据、铺底数据与参数化数据的准备思路以及需求规格、环境清单、同步定时器、聚合报告、PerfMon监控和持续集成执行等要点。资源包共1个pptx文件大小约12.48MB以图文课件形式组织目录按五个模块展开便于直接用于内部培训或自学翻阅可帮助读者建立可落地的性能测试流程框架并理解常见瓶颈定位与调优方向。目前已有1150人学习适合希望系统入门或查漏补缺的初中级性能测试从业者。1. 性能测试项目从造数据到调优一份 JMeter 全链路培训方案的落地拆解性能测试最容易出问题的环节是准备阶段脚本写好了环境也备齐了真正跑起来才发现数据库里只有几百条数据查询快得没有参照价值或者并发刚开始增加服务端就已经资源异常而你连瓶颈在数据库还是在应用层都判断不了。这份 JMeter 培训方案解决的正是这类问题它把性能测试拆成造数据、方案设计、脚本执行、监控调优、报告输出五段每一段都给出可执行的操作和判断依据。方案面向两类读者需要交课程设计或毕业设计的学生以及要把性能测试真正做进项目交付流程的测试工程师。JMeter 5.1.1 是全流程的主力工具配套 Oracle 19c、Tomcat、jconsole 和 Jenkins 一起使用。2. 造数据两种路径的取舍与百万级数据落地造数据是性能测试的第一步也最容易被跳过。很多方案在需求里写着“支持 100 万条影像登记数据”测试时库里只有几万条索引命中率、分页查询、统计报表的表现完全不同压出来的结论自然不可信。方案里把造数据分成两类路径并且明确给出了各自的适用边界。2.1 先分清三类数据初始化、铺底与参数化方案把测试数据分成三类这个划分决定了后面的工作量分配。初始化数据是系统运行必需的基础配置比如字典表、科室表、权限表量不大但不能缺铺底数据是历史累积数据也就是让表“有厚度”的那部分云影像场景里就是 100 万条登记记录、100 万条患者就诊记录涉及 EXAM_REQUEST、EXAM_PATIENTVISIT 这类主表参数化数据是脚本每次请求要变化的字段比如患者姓名、证件号、登记时间。三类数据的制造方式不一样。初始化数据一般直接由开发提供 SQL 脚本铺底数据是工作量的大头决定了用哪种造数方式参数化数据则依赖 JMeter 的 CSV Data Set Config 或者函数助手。我一般会先让项目组确认每张目标表需要的量级然后把它拉成一张清单避免做到一半发现漏了关联表。2.2 接口造数与存储过程造数的对比方案里给了两种造数路径对比维度很实在对比项JMeter 接口造数存储过程或 Java 代码造数实现方式抓包拿到保存接口参数化后模拟 HTTP 请求直接按表关系往数据库插数据速度约 2–5 万条/小时约 10–20 万条/小时数据真实性高走完整业务逻辑取决于 SQL 是否写对主要风险执行慢占用时间长表关联搞错会产出脏数据前置条件需要一个可用的保存接口需要完全掌握表关系选择依据不是哪个更快而是你对系统熟不熟。方案里的实际选择是接口造数理由写得很坦白不熟悉云影像系统的表间关系而且时间相对充裕。这个判断我认为是对的百万级数据用存储过程一两个小时就能铺完但如果 SQL 写错了关联字段脏数据排查的时间远超省下来的那几个小时而且脏数据会污染后续所有压测结论相当于没有补救机会。存储过程那条路也不是不能用方案里给了一段 Oracle 样例思路可以照着改-- 循环插入 300 条审计流水记录核心是 sys_guid() 生成主键、sysdate 生成时间 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(), -- 主键32 位唯一串 1.0, -- 版本号按业务实际填 4aa066b7-..., -- 业务主键需要与关联表对应 http://.../PUSH_FORM_TRAJECTORY2D, 192.168.20.14, 63528dad-..., -- 请求 ID 3f7be047-..., -- 响应 ID FOSS, UIP, ESB_FOSS2ESB_PUSH_FORM_TRAJECTORY2D, DOP_ESB2DOP_PUSH_FORM_TRAJECTORY2D, 1, 0, {code:12345678,company:KUAIDI100,msgId:...,watchStatus:abort}, sysdate ); end loop; commit; -- 循环结束统一提交减少事务开销 end;这段样例的关键点不在语法而在两个地方一是BIZID这类业务字段必须和主表真实对应否则后续按业务 ID 关联查询时数据对不上二是commit放在循环外面每 300 条提交一次量级再大就要改成按 5000 或 10000 条分批提交否则 undo 表空间会被撑满。改循环次数、改批次大小、改时间字段是这段脚本最常调的三处。2.3 接口造数的五步流水线选定接口造数后执行流程是固定的五步方案里写得可以直接照抄第一步用抓包工具抓出登记保存接口的完整参数包括请求头里的 token、Content-Type以及请求体里每个字段。第二步对会变化的字段做参数化姓名、证件号、时间戳这类用 CSV 或随机函数生成固定字段保留原值。第三步先设 10 个线程跑一次做调试确认响应全部成功、库里数据条数对得上。第四步调试通过后再放开批量。第五步100 万条的量级用 20 个线程循环 50000 次本地机器跑或者放到 Jenkins 上持续跑。第五步的两个细节值得单独说。20 线程 × 50000 次 100 万这个组合不是随便定的线程数太少跑不完太多会把被测系统压出非预期错误反而制造失败数据。方案里选 20 线程是在“跑得完”和“不压垮系统”之间取的折中。至于放到 Jenkins 上原因是本地 PC 连续跑十几个小时不能关机中途休眠、断网、系统更新都会打断脚本跑了一半的数据还得重新核对。这里有个容易踩的点造数脚本和压测脚本必须分开。造数脚本的线程组配置、目标接口、数据源都不一样混在一个 jmx 文件里后面调整压测并发数时很容易把造数逻辑一起改掉。提示造数前先确认目标表的当前数据量跑完后再 count 一次两个数字对得上才算造数成功。仅看 JMeter 聚合报告的请求成功率不能证明数据真的落库了。3. 性能测试方案设计需求规格、环境清单与场景编排脚本能跑只是手段方案要回答的是“测什么、在什么环境下测、怎么判定通过”。这一章把方案文档里必须固定的三块内容拆开需求规格、环境清单、场景设计。3.1 需求规格说明书先明确指标性能需求一般由项目组提供形态是一张指标表。典型内容包括核心交易的平均响应时间上限、95 线响应时间、目标并发用户数、事务成功率要求、系统需要支撑的数据量级。方案里的做法是把这些指标逐条落成可测量的口径比如“登记保存接口在 200 并发下平均响应时间不超过 2 秒成功率 100%”。指标最容易出现的偏差是定义不一致。响应时间是只算服务端处理还是包含网络传输和前端渲染并发用户数是线程数还是活跃用户数这些不写清楚测完给出的数字和项目组的预期对不上报告就白写了。我一般在方案开头就把这几个定义固定下来后面所有表格都用同一口径。3.2 环境清单要细到版本号环境清单是方案里最不起眼但最不能省的部分。方案给的是双表结构硬件一张、软件一张服务器类型IPCPU内存硬盘操作系统测试客户端10.1.1.18016 核8G500GWin10应用服务器10.8.3.19916 核64G500GWin2012数据库服务器10.8.3.17316 核64G500GWin2012服务器类型软件配置测试客户端Win10 SP1 64 位JMeter 5.1.1 及 agent应用服务器Win Server 2012 R2JDK 1.8Tomcat 8.0Nginx 1.10数据库服务器Win Server 2012 R2Oracle 19c为什么版本号要写进去因为压测结论只在特定环境下成立。同样的脚本JDK 1.8 和更高版本的 GC 表现不一样Tomcat 的连接池默认值不一样Oracle 19c 和 11g 的 AWR 报告生成方式也不一样19c 已经把 ADDM 建议合并进 AWR 脚本11g 还要单独跑一次。报告里不写环境别人拿到数据也没法复现这份报告就只能自己看。3.3 监控指标与场景设计方案把监控指标列成一张表分四类数据库 top SQL用 AWR 或慢日志看耗时最高的语句、系统整体处理情况AWR、ADDM、用户数线程组线程数、事务响应时间与成功率JMeter 聚合报告、服务端 CPU 与内存JMeter 加 ServerAgent 插件。场景设计遵循由轻到重的顺序先单接口基准再混合场景最后稳定性。基准场景只压一个接口目的是拿到单笔事务的响应时间基线混合场景按业务比例编排多个接口看相互影响稳定性场景用中等并发长时间运行主要看内存是否持续增长、连接是否泄漏。方案给了一个业务性能测试案例的结构把同步执行的请求放进简单控制器有先后依赖的放进事务控制器请求前加同步定时器模拟集合点。这个结构的意义在于事务控制器会把内部所有请求的耗时合并成一个事务时间正好对应业务上“提交一次登记”这个动作简单控制器则只做分组不改变耗时统计。选错控制器统计出来的响应时间就是错的。4. 脚本执行从控制器编排到服务端监控接入脚本执行不只是点一下运行。方案里把执行前后的准备工作拆成七步覆盖脚本组织、结果收集、服务端监控三块我按实际操作的顺序重排了一遍。4.1 线程组与控制器编排脚本按用例命名一个用例对应一个业务动作。用例内部如果几个请求同步发起用简单控制器包起来如果请求之间有先后顺序用事务控制器。请求执行前加同步定时器作用是所有线程到齐后再一起发出模拟真实用户在同一时刻提交避免线程陆续启动造成的压力分散。同步定时器的参数有两个Number of Simulated Users to Group by 填目标并发数Timeout 填超时毫秒数。超时设置太小线程等不齐会提前发出集合点就失效了设置太大某个线程卡住会让所有线程一起等。我一般按并发数的 1.5 倍到 2 倍给超时比如 200 并发给 300 毫秒到 400 毫秒。脚本里必须挂聚合报告这是看结果的基本盘样本数、平均响应时间、90%/95% 线、错误率、吞吐量。方案还提到可以在数据服务端调整 AWR 的快照频率默认一小时一次如果场景跑得密就手工执行一次快照-- 手工触发一次 AWR 快照跑完一个场景就执行一次 exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(); -- 生成 AWR 报告? 代表 ORACLE_HOME ?\RDBMS\ADMIN\awrrpt.sql;手工快照的好处是场景和报告一一对应。默认一小时一次快照一个 20 分钟的场景跑完快照可能还没生成你拿到的报告里混着上一个场景的残余数据瓶颈定位就会被带偏。11g 环境还要补跑addmrpt.sql拿优化建议19c 不用这两个脚本已经合并了。4.2 服务端监控三件套ServerAgent、PerfMon、jconsole服务端资源监控分两层。第一层是操作系统层在应用服务器和数据库服务器上启动 JMeter 的 ServerAgentWindows 双击startAgent.batLinux 执行startAgent.sh然后确认测试客户端到服务端的 4444 端口是通的。通不了就换工具比如 nmon别在这里耗时间。# Linux 服务端启动 ServerAgent默认监听 4444 端口 ./startAgent.sh # 从测试客户端验证端口连通性能通才会在 JMeter 里看到数据 telnet 10.8.3.199 4444端口通了之后在 JMeter 里加 PerfMon Metrics Collector 监听器勾选 CPU、内存、磁盘 I/O 指标。这个监听器是可选插件要先在插件管理器里装上。采集间隔建议 5 秒一次太密会额外增加服务端负担太疏会漏掉瞬时峰值。第二层是 JVM 层。服务端先开远程 JMX 端口本地用 jconsole 连IP:端口。jconsole 主要看两个页签内存页签相当于可视化的 jstat重点看每次 Full GC 之后内存能不能回落线程页签相当于可视化的 jstack遇到线程停顿时看它在等什么。线程长时间停顿的原因无非三类等外部资源数据库连接、网络、设备、死循环、锁等待活锁或者死锁。方案里这两句判断非常实用基本上把 JVM 层排查的入口说清楚了。4.3 执行时的记录规范正式跑之前先确认并发数。场景要多少并发线程组就设多少不要为了“多压一点”随意加。跑的过程中每个场景结束记录三样东西聚合报告截图、服务端监控曲线截图、数据库侧的 AWR 报告文件名。三样东西按场景编号命名存到同一个目录写报告时直接引用。方案里有一句提醒复杂的场景建议调快 AWR 快照频率简单的场景可以全部跑完再统一生成报告。这条对时间安排很有用复杂场景一个接一个跑中间不留快照后面的分析就会变成多场景数据混在一起很难判断是哪个场景造成的压力。5. 避坑与排查性能测试中最容易出错的五个环节这一章按“现象 → 原因 → 解决”整理都是做这套方案时会真实遇到的问题提前知道能少走很多弯路。5.1 压测结果异常好看其实是数据量不够现象并发 200响应时间 200 毫秒吞吐量很高看着很漂亮。原因库里只有几千条数据索引全命中缓存也全命中和真实生产环境的数据量差两个数量级。解决压测前确认每张核心表的数据量达到需求规格里写的量级100 万就是 100 万。数据量不够压出来的所有数字都只能当功能验证不能写进报告当性能结论。5.2 造数成功但数据是脏的现象造数跑完了count 也对得上后面按业务 ID 关联查询却查不到数据。原因参数化字段没有保持业务一致比如请求体里的患者 ID 是随机生成的但库里根本没有这个患者接口却返回成功。解决造数后用业务 SQL 抽样验证随机取几十条记录按主外键关联查一遍确认关联关系成立。参数化不是把所有字段都随机化主键类字段要来自真实数据源。5.3 服务端监控拿不到数据现象PerfMon 监听器一片空白聚合报告正常。原因4444 端口不通或者服务端 ServerAgent 没启动或者防火墙拦截。解决先在客户端 telnet 一下 4444不通就查防火墙和进程通但还是没数据检查 ServerAgent 是否用对系统的启动脚本bat 和 sh 不能混用再检查 JMeter 版本和插件版本是否匹配。实在不通就换 nmon别在工具连通性上无限投入。5.4 CPU 高不等于有问题Wait 高才是信号现象监控看到 CPU 跑到 80% 以上第一反应是系统扛不住了。原因性能测试的目的本来就是压出硬件能力CPU 高是正常现象。真正要区分的是 CPU 消耗在 User、Sys 还是 Wait。解决看 CPU 构成。如果是 Wait 占大头说明 CPU 在等 I/O多半是大表全表扫描没走索引去 AWR 里找 top SQL看执行计划里是不是走了 TABLE ACCESS FULL。如果是 User 高说明是计算密集去看业务逻辑有没有低效循环。5.5 内存不回落是泄漏最直接的证据现象压测中途内存持续上涨压力撤掉后也不回落。原因可能是内存泄漏也可能只是对象还没被回收。解决看 Full GC 之后的内存曲线。如果每次 Full GC 后占用都没有回到原来水平且压力撤除一段时间后依旧不恢复基本可以判定泄漏。判断依据要写成“Full GC 后基线持续抬升”而不是只看绝对占用值否则容易误判。6. 报告与答辩让压测数据站得住脚的呈现方法性能测试报告最怕的不是数据不好看而是数据不可信。一份能过评审、能用于答辩的报告结构上要能回答四个问题测了什么、在什么环境测的、结果是什么、瓶颈在哪。方案里报告的口径是测试目的、测试环境、测试方法、测试结果吞吐量、响应时间、并发用户数、瓶颈分析与调优建议五块内容缺一不可。呈现上有几个具体做法。结果部分用表格而不是截图堆砌一个场景一行列是并发数、平均响应时间、95 线、TPS、错误率纵向能看出趋势横向能对比场景。截图放在附录正文只引用关键的一张比如内存泄漏的证据曲线或者 CPU Wait 占比异常的那段监控图。瓶颈分析部分一定要挂上证据链哪个指标异常 → 对应哪个监控数据 → 定位到哪条 SQL 或哪段代码 → 建议怎么改。只说“数据库存在性能瓶颈”不算分析说到“EXAM_REQUEST 表的分页查询未走索引AWR 中该 SQL 占 DB Time 的 42%建议在登记时间字段加复合索引”才算。答辩时最常被问的三个问题是数据量够不够、环境是不是生产同构、结论能不能复现。前两个用环境清单和数据量核对表就能答第三个要求你把脚本、数据源、监控配置一起交付别人拿到能重跑出接近的数字。我一般会在报告最后附一份复现说明写清楚脚本版本、JMeter 版本、造数方式和快照生成步骤。从那以后我每次做压测都强制先走一遍“数据量核对 → 端口连通性验证 → 单场景试跑”这三步哪怕时间再紧也不跳。跳过这三步省下的半小时后面往往要用一整天来找原因。希望这套流程能帮到你需要这份完整培训方案的话可以直接拿去对照着搭自己的性能测试链路。本文还有配套的精品资源点击获取