简介这份实验报告面向软件测试专业学生围绕LoadRunner性能测试脚本的录制、分析、增强与回放调试以飞机订票系统为被测对象完整覆盖HTML与URL录制方式对比、事务插入、用户参数化、集合点并发、Controller运行及自动关联、输出函数与扩展日志等关键操作。内容来自实际课程实验步骤清晰、截图齐全适合软件功能测试与性能测试初学者参考也便于考生或学员对照完善自己的实验报告。资源为单个doc文档共1个文件压缩包大小6.2MB文档内含实验目的、环境配置、操作流程、脚本代码及结果分析可直接查阅或按需编辑。已有419人浏览学习。借助这份报告读者能理解性能测试脚本从录制到增强的完整链路掌握处理动态数据、设置并发用户和分析响应时间的方法并借鉴其中参数化与关联的排错思路提升性能测试实践能力。1. 性能测试项目里脚本录制与开发的分工性能测试项目动工之前第一道坎永远是脚本从哪来。很多工程师上来就问“能不能录”其实录制只是入口真正决定压测数据可不可信的是录制之后那段开发量。挂名“性能测试脚本录制和开发”的实验训练的就两件事先会录再会改最后能判断脚本到底算不算数。下面按 JMeter 最常用路线把代理录制原理、HTTPS 证书、参数化关联和回放验证串成一条可复现的路径每节都给可直接照抄的配置和命令。适合正在补性能测试基础或者刚接手压测任务但脚本还停留在“能跑就行”阶段的工程师。2. 脚本录制原理JMeter 代理与 HTTPS 证书2.1 录制为什么是代理转发而不是抓包最稳妥的脚本录制手段是本地代理转发不是抓包。抓包工具拿到的是二进制流和原始报文想还原成请求头、请求体、cookie再映射成压测脚本几乎等于手工重做一遍。JMeter 的 HTTP(S) Test Script Recorder 本质是个本地 HTTP 代理浏览器把流量指到 127.0.0.1:8888代理解析出请求行、请求头、表单参数和上传文件再按 Target Controller 设置把每个请求生成一个 HTTPSamplerProxy 节点顺序挂到线程组下面。因为做的是协议层还原只要浏览器代理配置正确页面是 Vue 前端还是服务端渲染录出来的请求结构都一致这也是它比浏览器开发者工具导出更通用的原因。代理录制只认识 HTTP/HTTPS。被测系统里如果还有 gRPC、WebSocket 长连接或自定义 TCP 协议录制器管不了。WebSocket 要另装插件gRPC 得按 protobuf 手工构造请求在这些场景里“录制”退化成“对照抓包结果手写脚本”。判断一个系统适不适合走录制路线第一看协议第二看认证逻辑里有没有大量动态 token。2.2 HTTPS 录制先过证书这一关让 JMeter 处理 HTTPS 请求关键一步是让浏览器信任 JMeter 自己的根证书。JMeter 会在工作目录或用户目录生成一个叫 ApacheJMeterTemporaryRootCA 的 CRT 文件代理首次启动时也会弹提示导入。Windows 上双击导入到“受信任的根证书颁发机构”macOS 导入钥匙串后把信任级别改成“始终信任”Firefox 则在隐私与安全设置里单独添加。证书只为本机调试服务实验环境无所谓但涉及公司内网或生产域名时先确认安全策略允许录完立刻从信任列表移除不留残余信任。URL 过滤也要提前配。Recorder 面板的 URL Patterns to Exclude 默认带了一条静态资源正则.*\.(bmp|css|js|gif|ico|jpe?g|png|swf|woff|woff2|svg|webp)(\?.*)?$这条保留即可。静态文件对性能测试没意义录进脚本会拉低 TPS、污染事务统计。只想录被测系统自身流量的话在 Include patterns 里加.*api\.example\.com.*这样的域名前缀Exclude 里保留静态资源正则双保险总比录完再清理省事。需要提醒的是 Include/Exclude 匹配的是完整 URL按正则语义逐字符匹配写错一个转义符就可能整场录空。2.3 录制计划的最小组件清单录制前先搭好测试计划骨架避免取样器散落在根上。最少需要五件套Test Plan、Thread Group先设 1 线程、Recording Controller、HTTP(S) Test Script Recorder以及配合观察的 View Results Tree。各组件在录制阶段的分工如下表。组件位置录制中的作用Thread GroupTest Plan 下提供线程上下文取样器最终挂在这里共享变量Recording ControllerThread Group 下收纳录制内容的容器把请求按树形归拢HTTP(S) Test Script RecorderWorkBench 下代理本体监听 8888 端口并生成取样器View Results TreeWorkBench 下录制过程实时显示请求和响应排错靠它录制生成的取样器在 jmx 文件里对应一个 HTTPSamplerProxy 节点大概长这样HTTPSamplerProxy guiclassHttpTestSampleGui testclassHTTPSamplerProxy testnamePOST /login stringProp nameHTTPSampler.domainapi.example.com/stringProp stringProp nameHTTPSampler.port443/stringProp stringProp nameHTTPSampler.protocolhttps/stringProp stringProp nameHTTPSampler.path/login/stringProp stringProp nameHTTPSampler.methodPOST/stringProp boolProp nameHTTPSampler.postBodyRawtrue/boolProp /HTTPSamplerProxy这段结构说明了两个关键点。domain、port、protocol、path、method 全被写死在取样器里环境切换时靠 HTTP Request Defaults 统一接管POST 请求默认按原始 body 录制postBodyRawtrue后续做参数化往往要先把它改成 Form Parameters 形态否则 CSV 变量没法直接替换。录制本身不产生断言和关联那部分属于“开发”是后面第 4 章的重点。3. 用 JMeter 录制性能测试脚本的步骤与参数设置3.1 代理录制的最小操作步骤操作顺序很关键先在 JMeter 里把代理启动起来再让浏览器走代理最后操作被测系统。顺序反了浏览器直接连不上排错时分不清是代理没起来还是证书没导入。最小操作步骤新建测试计划加线程组线程数设 1、循环次数设 1线程组下加 Recording Controller。在 WorkBench 下加 HTTP(S) Test Script Recorder端口默认 8888Target Controller 指向刚建的 Recording Controller。把系统代理指向 127.0.0.1:8888或者用浏览器代理插件按场景切换。点 Start按提示完成证书信任然后走一遍被测主流程登录、查询、下单、退出动作之间停 23 秒方便后面看树。点 Stop先把明显多余的静态请求清掉另存为 baseline.jmx。为什么强调 1 线程录制要的是请求序列不是并发多线程会把不同用户的动作交错混进同一棵树后续按事务整理时全是脏数据。提示录制时浏览器一直转圈九成是代理端口被占用或证书没导入成功先查端口再查证书不要反复重启 JMeter。3.2 代理组件参数表与三个必调项Recorder 面板参数不多但有一组必调项见下表。参数默认值录制建议说明Port88888888 或 8866端口冲突时改浏览器代理要同步改Target Controller根据路径匹配指定到 Recording Controller选错会把取样器挂到根节点树全乱Grouping按分组生成事务按业务动作选决定事务名粒度影响后续 TPS 统计Capture HTTP headers勾选保持勾选不勾会丢自定义头token 请求后续要补Exclude patterns静态资源正则保留并补充域名过滤埋点、广告、字体等无关请求Grouping 值得多说一句。“Put each group in a new transaction”会把一组连续请求包进一个事务控制器命名类似 group-1被测接口本身是单请求事务时选“Put each request in a new transaction”更干净。压力结果里的 TPS、平均响应时间都以事务为统计单元事务划错报告等于白做。3.3 录制完先做一次脚本清洗录完不等于能用。先看树做三件清洗删掉 Exclude 漏掉的资源请求合并重复的同路径请求比如登录失败重试留下的两条 POST /login只留成功那条把请求头和参数里肉眼可见的时间戳、随机数标出来留给后续开发环节处理。想快速找出重复请求用命令对 jmx 文件里的 testname 做去重统计grep -o testname[^]* baseline.jmx | sort | uniq -c | sort -rn | head -20输出里计数大于 1 的 testname 就是重复或相似请求逐条确认是业务必要还是录制噪声。注意这里统计的是请求名不是 URL如果录制时没统一命名先手动把取样器改成“方法路径”格式例如POST /login统计结果才有辨识度。4. 脚本开发参数化、断言与关联4.1 参数化CSV 数据集与 JMeter 内置函数录制出来的脚本是一份“单人单次”的固定数据直接上并发会出现两类事故会话 token 被所有线程共用导致鉴权失败同一份账号被并发重复提交触发业务层风控。参数化是脚本开发的第一个必要动作最常见的实现是 CSV Data Set Config。先在 jmx 同级目录建 users.csvusername,password,phone_token perf_001,pssw0rd,TK-1001 perf_002,pssw0rd,TK-1002 perf_003,pssw0rd,TK-1003然后在 Thread Group 下添加 CSV Data Set ConfigFilename 填users.csvVariable Names 填username,password,phone_tokenDelimiter 用逗号Sharing Mode 选 Current thread。这样线程组里任意取样器都能用${username}取值每个线程每次迭代按行推进数据不重样。参数文件不是越大越好。CSV 每次迭代读一行行数小于线程数时从头循环复用如果业务对账号状态有依赖比如登出后 token 失效就必须准备足够的独立账号。另一类常用工具是内置函数${__time(yyyyMMddHHmmss)}生成时间戳${__RandomString(6,abcdef123456)}生成随机串。函数在执行期求值适合替换请求里的临时值但不适合承载“登录后才返回”的服务端数据那是 4.3 节关联的事。4.2 断言响应断言与 JSR223 断言的选择录制阶段 JMeter 不判断业务成败只要 HTTP 200 就标绿。压测里最坑的假绿就是“HTTP 200 但业务失败”比如下单接口返回{code:50001,msg:库存不足}从协议层看一切正常。要区分这两类必须在取样器下加断言。响应断言配置很快Field to Test 选 Response TextPattern Matching Rules 选 ContainsPatterns to Test 填接口约定的成功标识。比如登录接口固定返回code:0断言就填code:0带引号是为了避免把code:0和code:0x混为一谈。断言不要铺满每个请求它本身有执行开销压测机 CPU 会先于被测系统变成瓶颈只放在登录、鉴权这类必须快速失败的接口上。遇到响应结构复杂的场景用 JSR223 Assertion 写脚本更可控def body prev.getResponseDataAsString() def resp new groovy.json.JsonSlurper().parseText(body) if (resp.code ! 0) { AssertionResult.setFailure(true) AssertionResult.setFailureMessage(business code resp.code) }这段脚本在取样器执行后立刻运行prev指向上一个取样器的结果对象AssertionResult是当前断言上下文。它比响应断言灵活可以同时校验 code 和 data 字段长度。Groovy 首次执行有编译开销压测前务必把 JSR223 的脚本缓存打开否则高并发下断言自身时延会被放大。4.3 关联JSON 提取器与正则提取器的选型边界登录返回的 token、下单返回的订单号这类“后一个请求依赖前一个响应”的数据参数文件解决不了必须做关联。JMeter 对 JSON 响应的标准做法是 JSON Extractor 后置处理器配置上要做四件事Name of created variable 写accessTokenJSON Path expressions 写$.data.tokenMatch No. 填 0 取全部匹配Default Values 填TOKEN_MISSING。后续取样器的 Header Manager 里直接引用${accessToken}。响应不是 JSON 时比如老系统返回 XML 或 HTML 片段JSONPath 取不到值改用正则提取器。正则写宽了会串到别的字段写窄了匹配不到建议带边界匹配token:([^])括号里就是要提取的部分。不要用.*兜底响应里多个 token 字段时提取结果不稳定排错成本反而更高。4.3.1 提取器作用域与执行顺序后置处理器挂在哪个节点就在哪个范围执行。挂在具体取样器下只在该请求响应后执行一次挂在 Thread Group 下线程组内每跑一个取样器就执行一次变量会被反复覆盖。常见踩坑把跨接口共享的 token 提取器挂在线程组下前置接口还没跑到后续请求已经拿到 TOKEN_MISSING 了。取样器的完整生命周期是 前置处理器 → 取样器 → 后置处理器 → 断言 → 监听器。关联必须在断言前完成所以提取器和断言放在同一个取样器下时提取器在上、断言在下。选型判断参考下表。场景推荐组件理由响应是 JSON字段层级固定JSON ExtractorJSONPath 语义清晰不依赖文本顺序响应是 HTML/XML/纯文本正则提取器只能基于文本做模式匹配需要拼接变量或条件分支JSR223 PostProcessor逻辑集中避免多个提取器互相覆盖需要从响应头取 Set-Cookie正则提取器配合 Header 域响应头不是 JSONJSONPath 无效5. 回放验证与常见失败处理5.1 单线程回放与聚合报告怎么看脚本开发完第一步不是上并发而是单线程单循环回放。线程组改成 1 线程 1 迭代加 View Results Tree 和聚合报告跑完看三处取样器有没有红色、断言有没有 failure、Error % 是不是 0。聚合报告指标要对照解读指标含义回放合格线Samples实际发出的事务数等于 迭代数 × 脚本内事务数Error %失败事务占比单线程回放必须为 0Average平均响应时间与手工操作量级一致90th pct90% 请求的响应时间和 Average 不应差出 10 倍以上如果 Samples 大于预期值大概率是引入了重试或重定向Error % 非零就看 View Results Tree 里是连接超时、断言失败还是响应体为空三种原因排查方向完全不同。5.2 三类典型录制回放失败与排查把常见回放失败收敛成三类排查效率最高。失败现象最可能原因处理方式401/403 且提示未认证登录 token 没关联或已过期检查提取器作用域重跑登录事务200 但断言失败业务参数写死或账号复用冲突确认 CSV 数据唯一性放宽断言模式Connection refused / timeout残留代理流量或目标端限流确认代理已停检查压测机端口与限流连接失败里有一种隐蔽情况录制时走代理回放时没走代理脚本目标写的内网域名在压测机上解析不了。这时要确认用 IP 还是域名并用 HTTP Request Defaults 统一协议、端口、超时避免每个取样器单独维护一份。排查断言失败jtl 和日志是最直接的证据。命令行回放时可以这样输出jmeter -n -t baseline.jmx -l replay.jtl -j replay.log grep -i assertion\|error replay.log | tail -30-j参数把运行日志单独写到 replay.log不和 jtl 混在一起。jtl 每行是一个取样器结果字段顺序固定前几列是时间戳、请求名、响应码、成功标记后续写校验脚本时直接按列解析。5.3 思考时间与事务边界的取舍录制过程天然带思考时间回放默认不保留。要不要恢复取决于测试目标摸底极限吞吐思考时间设 0压力拉满压出系统上限模拟真实用户占比用常数吞吐量定时器控制节奏或用${__P(thinktime,0)}做开关。不要用录制时的固定停顿真人操作间隔是随机分布固定间隔会产生节拍效应让压测曲线出现规律性毛刺容易被误判成系统振荡。事务边界同样影响数据解读。一个下单流程拆成 5 个取样器TPS 就按 5 个请求分别统计“下单 TPS”直接失真。常见做法是在流程外面包一层事务控制器勾选 Generate parent sample让聚合报告同时出现整体事务和子请求两套数据定位慢在哪个环节时不用重跑。6. 进阶技巧命令行压测与结果校验6.1 用 jmeter 无界面模式跑实验脚本录制、开发、回放都在 GUI 完成正式压测必须切命令行。GUI 要画界面、维护树结构并发一高压测机自己先撑不住。最小命令如下jmeter -n -t experiment5.jmx -l result.jtl -e -o html_report \ -Jthreads50 -Jrampup10 -Jduration120参数逐个说-n无界面-t指定测试计划-l写原始结果 jtl-e -o生成 HTML 报告目录-J系列给脚本里${__P(threads,10)}这类属性供值。脚本里把线程数、持续时间都写成__P占位一套脚本就能跑多组配置不用反复开 GUI。跑完先看 jtl 尾部时间戳是否覆盖了预期时长防的是压测提前结束时长缩水导致报告失真。6.2 用成功率和响应时间校验脚本有效性压测结束看两个数Error % 是否在可接受范围平均响应时间与单线程回放基准的比值是否合理。并发上去后响应时间线性上升、Error % 同步升高说明压力真实到达了系统瓶颈在服务端并发从 10 升到 50误差为 0 且响应时间纹丝不动反而要怀疑压测机和被测系统之间的网络带宽或是脚本被限流挡掉了大半请求。脚本有效性最终要落到 jtl 字段上验证head -3 result.jtl | cut -d, -f1,2,4,8这段命令取前 3 行按逗号切出时间戳、耗时、响应码和 success 标记。先确认时间戳单调递增、响应码齐全、success 全为 true再做聚合统计。任何一步异常都回到脚本本身排查而不是急着调被测系统参数。实验报告里把录制基线 jmx、开发后的脚本、回放 jtl 三段对应起来验收和复现时都能直接对上账。本文还有配套的精品资源点击获取