企业官网建设流程全解析

简介：面向性能测试初学者与需要系统梳理JMeter实践的测试人员，这份培训课件围绕性能测试全流程展开，帮助读者建立从数据准备到报告输出的完整方法框架。压缩包内为1个pptx文件，大小约12.48MB，以幻灯片形式组织讲解，适合培训授课、个人自学及团队内部分享使用。内容覆盖数据制造、性能测试方案设计、脚本执行、性能监控与调优、测试报告编写五个环节，具体涉及JMeter参数化造数与存储过程造数的取舍、测试环境软硬件清单、同步定时器与聚合报告、ServerAgent与PerfMon监控、AWR及慢日志分析等知识点。已有1150人学习，可作为性能测试培训的参考材料，也便于读者对照检查自身项目中的测试设计与监控调优思路。

1. 一份把性能测试拆成五段流水线的 PPT：从造数据到 AWR 报告

性能测试培训里最容易被跳过的一页，往往是“造数据”。很多 JMeter 教程从线程组讲到聚合报告就结束了，脚本跑在一张只有几十行的空表上，TPS 数字漂亮得很，上线当天被打回原形。这份 JMeter 篇的 PPT 走的是另一条路：先把 100 万条铺底数据灌进去，再谈方案、脚本、监控和报告，五个环节首尾咬合，每个环节都给到了具体的量级和参数——20 线程 × 50000 循环、4444 端口、AWR 手工快照、jconsole 的内存与线程页签。

它不适合当 JMeter 元件入门看，拖控件这种事看官方文档更快；它适合已经能跑通一个登录接口、但卡在“压测前该准备什么、压完该看哪张表”这个阶段的人。下面按这份材料的实际章节顺序拆，把每一步落到能抄的参数、能复现的命令，以及我踩过的那些坑上。

2. 造 100 万条铺底数据：参数化脚本与存储过程的两条路

造数据这一章是整份材料里含金量最高的部分，因为它回答了一个很实际的问题：需求文档写着“登记模块 100 万条”，这 100 万条从哪来。空库压测等于没压，CBO 在空表和有百万行数据的表上会给出完全不同的执行计划，索引能不能用上、全表扫描还是索引扫描，结论天差地别。所以第一步不是打开 JMeter，是先想清楚造哪些数据、用哪条路造。

2.1 三类数据与两条路线的选型

材料把待造数据分成三类：初始化数据（字典、机构、用户这类基础表）、铺底数据（也叫历史数据，业务主表的存量）、参数化数据（每次请求要变的字段，比如患者姓名、证件号、申请单号）。三类的造法不一样，初始化数据量小可以直接写 SQL，铺底数据量大要走批量，参数化数据则必须在脚本里做。

真正要选型的是铺底数据。材料给了两条路：

材料里选的是第一条路，理由写得很实在：不清楚影像系统各张表之间的关联关系，而且时间比较充裕。这个判断标准可以直接抄——表关系摸不清、工期有余量，走接口；表关系清楚、测试窗口只有一两天，走存储过程。两条路的工期差距是 5 倍以上，选错了后面全乱。

提示：100 万条按每小时 2 万到 5 万条算，实际要跑 20 到 50 小时。这个账必须在排期时先算出来，否则压测窗口根本排不开，最后只能砍数据量，砍完铺底数据不够，索引该走全表扫描还是走，压测结论直接失效。

2.2 抓包到批量跑：五步把接口造数脚本跑起来

材料给的五步很干脆：抓包拿参数、参数化、10 线程调试、批量跑、放 Jenkins 长时间运行。我把中间的具体操作补全，落到能直接执行的脚本上。

第一步抓包，用抓包工具抓一次“登记保存”的完整请求，重点是三样：URL 与请求方法、请求头里的鉴权字段、请求体里哪些字段是每次必须变的。请求体是 JSON 的话，直接在 JMeter 的 HTTP 请求里贴原文，把要变的字段替换成函数。

第二步参数化。字段分两类处理：纯随机不用关联的（姓名、证件号、电话）用 JMeter 内置函数；需要符合业务规则或有长度限制的（申请单号、就诊流水号）用 CSV 喂。CSV 我一般用脚本先生成，比在 JMeter 里拼函数可控得多：

# 生成登记接口用的参数化 CSV，一次生成 100 万行，JMeter 按行读取 import csv import random import uuid from datetime import datetime, timedelta SURNAME = "赵钱孙李周吴郑王冯陈褚卫蒋沈韩杨" GIVEN = "伟芳娜秀英敏静丽强磊洋艳勇军杰娟涛明超秀霞平刚桂英" start = datetime(2020, 1, 1) with open("reg_params.csv", "w", newline="", encoding="utf-8") as f: writer = csv.writer(f) writer.writerow(["patientName", "idCard", "phone", "reqNo", "regTime"]) for i in range(1_000_000): name = random.choice(SURNAME) + random.choice(GIVEN) # 证件号只保证长度与字符集合法，真实校验逻辑由被测系统负责 id_card = "110101" + f"{random.randint(1950, 2005):04d}" \ + f"{random.randint(1, 12):02d}" + f"{random.randint(1, 28):02d}" \ + f"{random.randint(1000, 9999):04d}" phone = "13" + f"{random.randint(0, 999999999):09d}" req_no = "REG" + uuid.uuid4().hex[:16].upper() reg_time = (start + timedelta(minutes=i)).strftime("%Y-%m-%d %H:%M:%S") writer.writerow([name, id_card, phone, req_no, reg_time])

这段脚本的关键点有三个。reqNo用 UUID 前缀拼，保证全局唯一，重复单号会被接口的幂等校验挡回来，批量跑的时候几十万条失败大半是这个原因。regTime按分钟递增而不是全部取当前时间，是为了让后续按时间范围查询的接口有数据可查，全挤在同一天会让时间条件形同虚设。姓名和证件号只保证格式合法，不追求真实校验通过——真实校验由被测系统自己跑，脚本这边造的是“看起来合理”的量。

CSV 生成完，在 JMeter 里挂 CSV Data Set Config，参数这么配：

第三步调试，线程组设 10 线程、循环 1 次，跑一遍看聚合报告的错误率。这一步不要省，接口的参数校验规则、必填字段、鉴权 token 过期时间，都会在这一轮暴露。第四步批量跑，线程数和循环次数的组合材料给的是 20 × 50000，正好 100 万。第五步交给 Jenkins，因为本地 PC 要连续跑几十个小时不能关机，实测中途休眠一次、网络断一次，前面跑的就白费了。

命令行跑比 GUI 稳，长时间运行尤其如此：

# 非 GUI 模式跑造数脚本，-n 关闭界面，-t 指定脚本，-l 指定结果文件 jmeter -n -t reg_data.jmx \ -Jthreads=20 \ -Jloops=50000 \ -Jramp=60 \ -l reg_result.jtl \ -e -o ./report_html

-J开头的参数会覆盖 jmx 里的${__P(threads,10)}占位符，这样同一份脚本改线程数不用打开 GUI。-Jramp=60是 60 秒内把 20 个线程拉满，造数场景不需要瞬时并发，给个爬坡期反而能让数据库写入更平滑。-l指定 jtl 结果文件，-e -o直接生成 HTML 报告。跑之前记得把 jmx 里的“察看结果树”和“聚合报告”都禁用，监听器在非 GUI 模式下照样占内存，跑 50000 次循环的时候这个开销不小。

2.3 存储过程直插：什么时候该切到 SQL 路线

接口造数跑到一半发现太慢，或者铺底数据的字段根本不需要走业务校验，就该切到存储过程。材料的 Oracle 样例是循环 300 次插一张审计表，结构对但有两个地方要改：一是循环次数写死，二是整批只 commit 一次。

-- 分批提交的造数存储过程，避免一次性 UNDO 撑爆表空间 create or replace procedure sp_gen_exam_request( p_total in number, -- 总条数，例如 1000000 p_batch in number default 5000 -- 每多少条提交一次 ) as v_id varchar2(64); begin for i in 1 .. p_total loop v_id := sys_guid(); insert into exam_request( fid, version, bizid, reqid, sourcesys, targetsys, resultcode, body, createtime ) values( v_id, '1.0', v_id, rawtohex(sys_guid()), 'HIS', 'PACS', 0, '{"code":"0000","msgId":"' || v_id || '","status":"done"}', sysdate - dbms_random.value(0, 365) ); -- 每 p_batch 条提交一次，兼顾速度与回滚粒度 if mod(i, p_batch) = 0 then commit; end if; end loop; commit; end; /

改动点逐个说。p_total参数化之后，同一份存储过程既能造 10 万也能造 100 万，不用改代码重编译。分批 commit 是必须的，100 万条一次性提交，UNDO 表空间不够会直接报 ORA-30036，而且失败之后回滚要等很久；每 5000 条提交一次，单批失败最多丢 5000 条，重跑代价可控。sysdate - dbms_random.value(0, 365)把创建时间打散到一年内，比全部sysdate更接近真实历史数据的分布，按时间范围查询的 SQL 才能压出真实执行计划。

执行的时候分段来，别一口气跑完：

-- 先跑 1 万条验证数据分布和约束，没问题再放大 begin sp_gen_exam_request(10000, 2000); end; / -- 验证通过后补到 100 万条 begin sp_gen_exam_request(990000, 5000); end; /

存储过程路线的风险材料里写得很清楚：SQL 写错会导致数据不准、产生脏数据，需要重新编写。我的做法是造完先跑三条校验 SQL——总数对不对、关键外键有没有孤儿记录、业务状态分布是否合理——三条都过了再往下走。孤儿记录这一项最容易漏，直插绕过了应用层的外键检查，主表插进去了从表没插，压测时一查关联就报错。

3. 性能测试方案怎么写：需求规格、环境清单与场景设计

方案这一章看着像文档工作，实际上是整个压测的地基。需求规格没落到具体数字，后面压出来的结果就没法判断合格与否；环境清单没写清楚，出了瓶颈根本分不清是代码问题还是机器问题。材料给的模板不复杂，但每一项都有它的用途。

3.1 需求规格要落到哪几个数

性能测试需求规格说明书一般由项目组提供，里面至少有四组数：业务量（日均多少笔、峰值集中在几点）、并发用户数、响应时间要求、系统可用性要求。这四组数里，只有响应时间是可以直接拿来做验收标准的，其余三组要换算。

换算用利特尔法则：并发数 = TPS × 平均响应时间。举个具体例子，需求写“登记保存接口峰值 TPS 50，响应时间 2 秒以内”，那对应的并发用户数就是 100。反过来，如果需求只给了“500 用户同时在线”，那得先估活跃比例（常见做法是取 10% 到 20%），再乘上每个活跃用户的操作频率，才能折成 TPS。这一步不换算清楚，脚本里的线程数就是拍脑袋定的，压出来的数字没法解释。

注意：并发用户数和线程数不是一回事。JMeter 线程数配上同步定时器之后才是并发，不加定时器的线程组是“持续施压”，两者压出来的 TPS 曲线形状不一样。方案里写“500 并发”的时候，最好注明是不是带集合点的并发。

3.2 环境清单：三台机器的软硬件配置怎么写才不背锅

材料给了一张三机环境的表，我把字段整理成可以直接复用的版本：

这张表的价值不在记录，在对比。压测客户端只有 8G 内存，跑 20 线程 × 50000 循环的时候，JMeter 自己的堆内存就会成为瓶颈，这时候报出来的响应时间里有一截是压测机自己卡住的。我的习惯是把测试客户端的堆调大，jmeter.bat里改HEAP=-Xms2g -Xmx4g -XX:MaxMetaspaceSize=512m，并且在报告里注明压测机的配置，避免被追问“为什么生产 64G 压出来还不如测试环境”。

还有一处必须写进方案：测试环境和生产环境的配置比例。三台机器都是 16 核 64G，如果生产是 8 台应用服务器，那测试环境压出来的 TPS 只能做横向对比和趋势判断，不能直接外推成生产容量。方案里不写这一句，报告出去之后一定有人拿去当生产容量结论用。

3.3 场景设计与监控指标表

场景设计分三类：基准场景（单接口、单用户，拿基线响应时间）、负载场景（按需求 TPS 逐步加压，找拐点）、混合场景（多接口按业务比例混合，最接近真实）、稳定性场景（70% 峰值压力跑 8 小时以上，看内存和连接池有没有缓慢泄漏）。材料的案例是混合场景，几个接口按业务占比配线程数，用事务控制器包成一组。

监控指标表对应着后面要采集的数据，材料里列的这几项基本够用：

“持续低于 80%”这个阈值材料里给了，但后面还有一句更重要的补充：CPU 高不一定有问题，充分发挥硬件能力本来就是性能优化的目标之一；要看的是 CPU 消耗在 User、Sys 还是 Wait。落在 Wait 上，说明 CPU 在等 I/O，这时候去看磁盘和全表扫描，比继续加机器有用。

4. 脚本执行链：ServerAgent、PerfMon 与 jconsole 的三层监控

脚本执行这一章，材料的顺序是“先配脚本结构，再挂三层监控，最后跑场景出数据”。这个顺序不能反，监控没挂好就跑，跑完发现 CPU 曲线是空的，只能重跑。三层监控分别是：JMeter 自带的结果收集（应用层）、PerfMon + ServerAgent（操作系统层）、jconsole 与 AWR（JVM 与数据库层）。

4.1 脚本骨架：简单控制器、事务控制器、同步定时器的取舍

材料的规则很明确：多个请求之间是同步关系（可以并行发）用简单控制器，有先后依赖关系（后一个要用前一个的返回）用事务控制器。事务控制器还有个附带作用，它会把内部所有请求的耗时合并成一个事务统计，报告里看到的“一笔业务耗时”就是它。

同步定时器（Synchronizing Timer）相当于集合点，加在需要瞬时并发的请求前面。两个参数：模拟用户数（ Number of Simultaneous Users to Group by ）和超时时间（Timeout in milliseconds）。模拟用户数配成和线程数一致，超时时间给 5000 到 10000 毫秒。超时设成 0 是很多人的默认操作，含义是无限等待，线程数配错或者有请求卡住的时候，整个线程组会挂在那里不动，看起来像压测机崩了，实际是在等一个永远凑不齐的集合点。

脚本命名建议按用例来，比如TC_REG_001_登记保存_单接口.jmx，用例名里带上接口和场景类型。压测跑十几个脚本之后，靠文件名找脚本比靠记忆靠谱。

4.2 ServerAgent 与 PerfMon：4444 端口这条命脉

服务端装 ServerAgent，Windows 双击startAgent.bat，Linux 执行startAgent.sh，默认监听 4444 端口。装完第一件事不是打开 JMeter，是先验证端口通不通：

# 在压测客户端上探测服务端 4444 端口 # Linux / macOS nc -zv 10.0.0.12 4444 # Windows 用 PowerShell Test-NetConnection -ComputerName 10.0.0.12 -Port 4444

返回成功再往下走。不通的话，按顺序查三样：服务端防火墙有没有放行 4444、ServerAgent 进程是不是真的起来了（ps -ef | grep -i serveragent）、云主机的话安全组有没有开这个端口。这三样排查完还有问题，那就是网络策略层面的限制了，换 nmon 之类的工具从服务端本地采集，把文件拉回来解析，一样能出图。

JMeter 端加 PerfMon Metrics Collector 监听器，Host/Port 填服务端 IP 和 4444，Metric 勾 CPU、Memory、Disks I/O。这个监听器是可选插件，5.1.1 默认没装，得去插件管理器里下载。勾的指标越多，采集频率越高，对压测机和服务端的额外开销越大，一般 CPU、Memory 两项加一个磁盘就够定位大部分问题。

4.3 jconsole 远程连接：内存与线程两个页签怎么读

服务端要开 JMX 远程端口，Tomcat 的catalina.bat里加启动参数：

# Windows 下 Tomcat 开启 JMX 远程，端口 9999，不启用认证（内网测试环境） set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote ^ -Dcom.sun.management.jmxremote.port=9999 ^ -Dcom.sun.management.jmxremote.authenticate=false ^ -Dcom.sun.management.jmxremote.ssl=false ^ -Djava.rmi.server.hostname=10.0.0.12

-Djava.rmi.server.hostname这一行最容易漏，漏了之后 jconsole 连得上但拿不到数据，报连接超时。原因是 RMI 在握手之后会返回服务端自己解析出来的主机名，如果那是个容器内部名或者 localhost，客户端就回连不上。

连上之后只看两个页签。内存页签相当于可视化的 jstat，判断标准是每次 Full GC 之后占用能不能回落到基线，压力撤除后能不能恢复到压测前水平——回不去，十有八九是内存泄漏。线程页签相当于可视化的 jstack，遇到线程数只涨不跌，点“检测死锁”，再逐个看线程栈，常见原因是等数据库连接、等网络资源、死循环、锁等待。

4.4 AWR 快照与报告生成

Oracle 的 AWR 默认一小时打一次快照，短场景压完根本凑不出两个快照，报告是空的。材料的做法是每个场景跑完手工打一次快照：

-- 场景开始前打一个基线快照 exec dbms_workload_repository.create_snapshot(); -- 场景跑完再打一个 exec dbms_workload_repository.create_snapshot(); -- 生成 AWR 报告，按提示输入起止快照 ID @?/rdbms/admin/awrrpt.sql

?代表 ORACLE_HOME，在 sqlplus 里直接这么写就能找到脚本。快照 ID 在执行create_snapshot()的时候会返回，记下来，生成报告时按提示输入区间。材料里还有一处版本差异要留意：11g 需要额外跑addmrpt.sql才能拿到 SQL 优化建议，19c 两个脚本已经合并，只跑 awrrpt 就够。版本搞错的话，报告里少一块建议，排查时容易误判成“数据库没问题”。

场景复杂的时候，建议临时把自动快照间隔调短，跑完再调回来：

-- 查询当前快照间隔（单位分钟） select snap_interval, retention from dba_hist_wr_control; -- 临时改成 15 分钟一次，保留 8 天 exec dbms_workload_repository.modify_snapshot_settings( interval => 15, retention => 8*24*60);

改完记得改回去，自动快照频率调高会持续占用 SYSAUX 表空间，长期不还原会慢慢把库撑大。

5. 排查清单：性能测试里最容易翻车的五个点

这一节按“现象 → 原因 → 解决”记五条，都是我在实际压测里反复遇到的，跟材料里的操作步骤一一对应。

5.1 造数据与脚本执行阶段的三个坑

现象一：造数脚本跑了两小时，JMeter 界面卡死，jtl 文件停在某个时间点不再增长。原因是开着 GUI 跑长任务。GUI 模式下每个请求的结果都要渲染到察看结果树，内存占用随请求数线性上涨，8G 的压测机跑几十万条就撑不住了。解决方式是全程用jmeter -n -t ... -l ...非 GUI 模式，监听器只留一个聚合报告并且禁用，结果靠 jtl 文件后处理。已经跑了一半的，别删 jtl，用jmeter -g result.jtl -o report可以离线生成 HTML 报告。

现象二：批量跑造数据，错误率 30% 以上，报错集中在“单号重复”和“会话超时”。单号重复是 CSV 的 Sharing mode 配成了Current thread，每个线程各读各的，指针错位导致同一行被多个线程读到；会话超时是 token 有效期 30 分钟，而脚本跑了几个小时。解决方式是 CSV 改成All threads共享模式，Recycle on EOF设 False，把重复率降下来；token 用 setUp 线程组定时刷新，或者在后置处理器里判断过期后重新登录。造数脚本里加一个 JSON 断言，把返回码非成功的请求单独打标签，比事后翻 jtl 快得多。

现象三：存储过程造数跑到 60 万条报 ORA-30036，回滚之后重跑又从头开始。原因是一次性 commit 或者批次太大，UNDO 表空间扛不住。解决方式是把 commit 频率降到 2000 到 5000 条一次，同时把过程改成支持断点续跑——加一个p_start参数，重跑时从断点开始，而不是从 1 开始。另外造数前先select tablespace_name, bytes/1024/1024 from user_segments where segment_name='EXAM_REQUEST'看一眼表空间余量，心里有个数。

5.2 监控与结果分析阶段的三个坑

现象四：压测跑完，PerfMon 图表是空的，一条线都没有。按概率排：4444 端口不通（防火墙、安全组）、ServerAgent 没启动、PerfMon 监听器没装插件。前两个用上一节的nc命令就能排除，第三个去插件管理器确认。还有一种情况是 Host 填了主机名而不是 IP，DNS 解析到别的机器上去了，改成 IP 直连。

现象五：AWR 报告生成了，但里面只有一两个快照，Top SQL 一栏基本是空的。短场景（十分钟以内）跑完，自动快照还没轮到，手工快照又忘了打。解决方式是每个场景执行前后各手工create_snapshot()一次，把快照 ID 记在场景记录表里。已经跑完的，只能靠 v$active_session_history 里保留的近期活动会话数据凑，采样精度会差一些。

现象六：响应时间曲线在某一刻突然抬升，但应用服务器和后端数据库的 CPU 内存都很平稳。这种“两头都不忙、中间变慢”的情况，八成卡在连接池或者线程池。去 jconsole 的线程页签看线程数和阻塞数，去 Tomcat 日志里搜ConnectionPool相关的等待。还有一个容易被忽略的点是压测机自身——压测机 CPU 打满之后，录到的响应时间包含了压测机调度延迟，看起来像是被测系统变慢。压测期间在压测机上开个 top，这个低成本动作能省掉大量扯皮。

提示：每一轮压测都记一份“场景-时间-快照 ID-关键指标”的小表，四列就够。等到要出报告回头翻记录的时候，这份表能救命。

6. 从 AWR 报告反推瓶颈：一份结果的读法与一次教训

AWR 报告几十页，全看等于没看。我一般按三段切：先看 DB Time 和 Elapsed 的比值，判断数据库是不是真的忙；再看 Top 10 Foreground Events，看时间花在 CPU 还是等待上；最后看 SQL ordered by Elapsed Time，落到具体语句。三段看完，瓶颈在数据库还是不在数据库，基本就有结论了。

具体到数字上，几个关键项的判读方式：

读报告有两个容易翻车的地方。一是只看 Elapsed Time 不看 Executions，一条执行了 10 万次的语句总耗时自然高，单次耗时可能只有几毫秒，这种情况要优化的是调用频次，不是 SQL 本身。二是把db file scattered read一律当成坏消息，批量任务和报表查询本来就会全表扫描，得结合当时的场景判断。我吃过一次亏：稳定性场景压了 8 小时，AWR 里log file sync排第一，我第一反应是磁盘 I/O 不行，换了 SSD 之后曲线纹丝不动，最后回头看是应用侧每个事务都单独提交，把 commit 次数压下来，等待直接掉了一个数量级。那次之后我每次读 AWR 都强制走一遍“先看提交频次和事务粒度，再看 I/O”的顺序，不再凭第一眼的等待事件下结论。

最后一件事是出报告的骨架。报告里必须有测试目的、环境清单、场景设计、结果数据（吞吐量、响应时间、并发数、成功率）、瓶颈定位和调优建议六块，其中环境清单和场景设计直接从方案里搬，结果数据从聚合报告和 jtl 里出，瓶颈定位靠 AWR 和 jconsole 的截图。凡是没复现过的结论，宁可不写，也别把“可能是索引问题”四个字写进报告——下次评审被追着问执行计划和索引名，答不上来比不写还难看。希望帮到你。

本文还有配套的精品资源，点击获取