做 JMeter 脚本录制真正让人头疼的往往不是找不到按钮而是录完以后脚本跑不起来登录态丢了、Token 对不上、静态资源一大堆、HTTPS 还弹证书警告。尤其是接手一个已有系统接口文档不全前端参数藏得深手工拼请求就像盲人摸象。这时 JMeter 的脚本录制就很有价值让浏览器正常走一遍业务流程JMeter 把请求、参数、Cookie、文件上传等原始信息抓下来再在此基础上做参数化、关联、断言和压测编排。这篇适合已经装好 JMeter、能发简单请求但对录制流程、HTTPS 处理、录制后清理不熟的同学也适合做接口测试、性能测试、自动化回归的从业者。核心会围绕 JMeter、脚本录制、HTTPS 录制、参数化、关联、常见报错排查展开尽量把踩过的坑讲透。1. 脚本录制到底解决什么问题1.1 手写脚本和录制的边界手工写 JMeter 脚本不是不行而是成本取决于你对接口的熟悉程度。如果接口文档齐全请求方法、路径、参数、Header、鉴权方式都写清楚了直接手写反而更干净因为你不会把页面里的图片、样式、字体、统计脚本一起带进来。问题是很多项目并不具备这个条件老系统文档缺失前端代码压缩过参数名靠猜登录还带着验证码、加密串、防伪标记。这个时候先录一遍相当于让浏览器帮你把真实请求“抄”下来再去做减法。但录制不是终点。录制出来的东西只能叫“原始素材”它记录了浏览器在某个时刻发出的请求包括一堆你根本不关心的资源。直接拿录制脚本去压测通常会遇到两个结果一是请求数爆炸压测机先扛不住二是业务跑不通因为动态参数没有关联。我的习惯是未知接口先录已知接口手写复杂登录先录简单查询手写。录制解决的是“我不知道请求长什么样”不是“我不用理解业务”。1.2 录制前先画业务链路录制之前别急着点 Start。先拿一张纸或者笔记软件把核心链路写出来。比如一个订单系统链路可能是打开首页、登录、进入商品列表、搜索商品、查看详情、加入购物车、提交订单、支付模拟、退出。每一步要观察什么登录后 Cookie 有没有变化Token 放在响应体还是 Header商品 ID 是不是从列表接口返回订单号是不是提交后生成。把这些动态点标出来录制时才有意识地去看。我见过很多人录完脚本才发现自己把“退出登录”也录进去了结果压测时每个线程跑完就退出会话被清掉后续请求全部 401。还有人把“删除商品”录进主链路压测时把测试数据删得干干净净。所以录制前要明确哪些步骤是压测需要的哪些只是手工操作顺手点的。录制范围越聚焦后面清理越省事。1.3 录制方式的取舍记录器、开发者工具、旧工具JMeter 自带的 HTTP(S) Test Script Recorder 是最常用的方式适合录制完整浏览器会话能自动带上 Cookie、Header、文件上传等细节。浏览器开发者工具也能看请求还能复制为 cURL再导入 JMeter但它是单请求视角跨请求关联、Cookie 管理、重定向链路需要自己拼。旧工具如 Badboy 曾经流行现在用得少了兼容性和维护性都不如直接使用 JMeter 记录器。方式适合场景优点注意点HTTP(S) Test Script Recorder完整业务链路、登录态复杂自动记录请求、Cookie、Header需要处理 HTTPS 证书容易录入静态资源浏览器开发者工具复制 cURL单个接口补录快、准、不污染脚本需要手动处理变量和 Cookie抓包工具导出移动端、非浏览器客户端能看底层报文格式转换麻烦HTTPS 需额外处理手工编写接口文档齐全脚本干净、可维护对业务理解要求高我一般用记录器录主链路用开发者工具补漏。比如登录接口里有验证码录制器录到的验证码是过期值这时就从开发者工具里确认验证码接口再决定是屏蔽验证码、固定验证码还是从响应中提取。2. 环境准备与录制原理2.1 JMeter 安装和 Java 环境的最低检查JMeter 官方包解压即用但 Java 环境必须先确认。命令行执行java -version能看到版本号再继续。JMeter 5.x 通常要求 Java 8 及以上较新的版本对 Java 11、17 支持更好。如果你在 Windows 上双击jmeter.bat一闪而过大概率是 Java 没配好或者JAVA_HOME指向了错误的 JDK。此时不要反复重装 JMeter先在命令行里跑jmeter.bat -v看报错信息。安装目录建议不要带中文和空格比如D:\tools\apache-jmeter-5.6.3。带空格有时会让某些插件、脚本路径处理变得别扭。内存方面默认配置对普通录制足够但如果后面要压测需要调整bin/jmeter.bat或bin/jmeter里的HEAP参数。录制阶段不用改太大否则 GUI 启动慢。字体太小可以在jmeter.properties里调整缩放或者用界面里的 Zoom 功能录制时看清请求名很重要。2.2 HTTPS 录制为什么绕不开证书HTTP 录制很简单浏览器把请求发到本机监听端口JMeter 直接看到明文。HTTPS 不一样浏览器和服务器之间是加密的JMeter 要看到内容就必须在中间完成一次证书替换。首次启动 HTTP(S) Test Script Recorder 时JMeter 会在bin目录生成ApacheJMeterTemporaryRootCA.crt。这个证书需要被浏览器或操作系统信任否则浏览器会提示连接不安全JMeter 只能看到 CONNECT 请求看不到真正的请求体和响应。导入证书时要注意这是测试用途的临时根证书不要在生产机器上长期保留。Windows 可以导入“受信任的根证书颁发机构”macOS 导入钥匙串并设为始终信任Firefox 有独立的证书管理器。导入后重启浏览器再访问目标站点。如果仍然报证书错误检查是否导入了错误的证书文件或者浏览器使用了独立的证书库。测试结束后建议删除该证书避免后续排查问题时混淆。2.3 浏览器网络设置与监听端口怎么配合记录器默认监听8888端口。启动记录器后浏览器需要把 HTTP 和 HTTPS 的网络访问入口指向本机127.0.0.1:8888。Firefox 可以在设置里的网络设置中手动配置HTTP 主机填127.0.0.1端口填8888HTTPS 也填同样的主机和端口并勾选“为所有协议使用相同主机和端口”。Chrome 通常跟随系统网络设置改完后整个系统的流量都会走这个入口测完一定要还原否则浏览器上不了网。如果 8888 被占用记录器启动会报错。可以换成 8899、9000 等端口同时浏览器也要同步修改。录制时建议只开一个目标浏览器窗口关掉无关标签页、即时通讯、自动更新否则会录到大量无关请求。浏览器插件、广告拦截、翻译功能也可能发出额外请求。录制环境越干净后期清理成本越低。2.4 录制过滤规则别把静态资源全带回来记录器里的 Requests Filtering 是录制质量的关键。URL Patterns to Include 用来只保留目标域名例如.*\.example\.com.*URL Patterns to Exclude 用来排除静态资源和第三方服务。常见排除规则可以这样写.*\.(js|css|png|jpe?g|gif|ico|svg|woff2?|ttf|eot|map).* .*\.(doubleclick|google-analytics|googletagmanager|facebook|hotjar)\.com.* .*\.(mp4|webm|ogg|mp3|wav).*注意 Include 和 Exclude 同时存在时一般先判断 Include再判断 Exclude。如果你把目标域名也排除了就会什么都录不到。更稳妥的做法是先不设 Include只设 Exclude 排静态资源录制一轮后看哪些域名是业务域名再补 Include。过滤规则写得太狠可能漏掉关键接口比如某些系统把业务请求放在api.example.com静态资源放在static.example.com这时 Include 要覆盖.*\.example\.com.*再单独排除静态路径。3. 一步步录出登录、查询、下单脚本3.1 测试计划与记录器配置打开 JMeter先新建测试计划添加一个线程组命名为“录制线程组”。线程组里暂时不用改线程数录制阶段一个线程就够。然后在测试计划上右键添加 Non-Test Elements 里的 HTTP(S) Test Script Recorder。记录器配置里重点看几个参数Port 填8888Target Controller 选择“Test Plan 录制线程组”Grouping 建议选“Put each group in a new transaction controller”这样录制出来的请求会按页面操作分组后面好整理。Requests Filtering 里把静态资源排除规则填上。如果目标站点是 HTTPS先点击 Start让 JMeter 生成证书文件。此时记录器会弹窗提示证书位置。不要急着关后面导入浏览器要用。记录器启动后界面下方会显示运行状态。如果启动失败看日志里的端口占用、证书生成失败、权限不足等信息。Windows 上如果 JMeter 装在 C 盘 Program Files可能因为权限无法写证书换到用户目录即可。3.2 证书导入与浏览器设置证书文件通常在bin目录下叫ApacheJMeterTemporaryRootCA.crt。以 Firefox 为例进入设置搜索“证书”打开证书管理器选择“证书颁发机构”导入该文件勾选信任该证书用于识别网站。Chrome 和 Edge 使用系统证书库Windows 上双击证书选择“安装证书”存储位置选“本地计算机”手动放入“受信任的根证书颁发机构”。导入后关闭所有浏览器窗口重新打开。浏览器网络设置指向127.0.0.1:8888后先访问一个 HTTP 页面测试。如果记录器里出现请求说明链路通了。再访问 HTTPS 目标站点如果浏览器地址栏没有证书警告说明证书信任成功。如果提示“您的连接不是私密连接”检查证书是否导入到正确的证书库Firefox 有独立证书库系统证书不一定生效。测试完成后记得把浏览器的网络设置恢复为“不使用网络访问入口”或自动模式。3.3 录制现场从打开首页到提交订单正式开始录制时浏览器先清空缓存和 Cookie保证会话干净。在 JMeter 里点击记录器的 Start然后在浏览器输入目标地址。操作节奏可以比正常使用稍慢每点一个按钮停一两秒让请求完整发出。遇到页面跳转、弹窗、文件上传按真实流程走。提交订单这类写操作如果压测环境允许可以录如果不允许录到提交前一步即可。录制过程中观察 JMeter 的请求树。如果发现某个请求一直转圈可能是 HTTPS 证书没信任或者目标站点有 WebSocket、Server-Sent Events 等长连接。记录器对普通 HTTP 请求支持很好对 WebSocket 支持有限需要后续用插件或手写。录制完成后先点击 Stop再关闭浏览器。不要在记录器还在运行时直接改浏览器设置容易造成请求丢失或重复。3.4 录制后第一轮清理录完第一眼通常是“怎么这么多请求”。先删静态资源CSS、JS、图片、字体、favicon、地图瓦片、统计脚本。再看有没有 OPTIONS 预检请求如果后端不校验可以保留也可以删除但要注意删除后可能影响跨域模拟。接着合并重定向登录成功后可能跳转好几次保留最终业务请求删除中间 302 跳转除非你需要验证跳转逻辑。然后把请求按业务步骤重命名。GET /api/product/list改成“查询商品列表”POST /api/order改成“提交订单”。名字清晰后面加断言、看结果都方便。最后把无关的第三方请求删掉比如客服插件、广告、埋点。注意有些埋点请求虽然不影响业务但会占用线程和带宽压测时最好排除。3.5 回放验证与察看结果树清理后先跑一遍。线程组设为 1 个线程、1 次循环添加“察看结果树”点击运行。重点看三个东西响应码是否 200响应体里有没有业务错误码动态参数是否被正确传递。如果登录接口返回 401检查 Cookie 管理器和 Header 管理器。如果查询接口返回空检查请求参数是否写死成录制时的旧值。如果提交订单提示“请先登录”说明会话没保持住。察看结果树适合调试不适合压测。压测时一定要禁用或删除否则内存很快被结果数据撑爆。调试完成后把结果树的作用域设为“仅当前线程组”或临时启用。导出结果可以用右键导出 CSV但同样只适合小规模调试。真正压测用命令行生成 HTML 报告下面会讲。4. 录制后的参数化、关联与断言4.1 CSV 参数化与每个线程分块取值录制脚本里的账号、密码、商品 ID 往往是写死的。要模拟多用户必须参数化。最简单的是用户定义变量但并发场景更常用 CSV Data Set Config。准备一个users.csvusername,password,expected_code user001,pass001,0 user002,pass002,0 user003,pass003,0在 CSV Data Set Config 中填写文件名、编码 UTF-8、变量名username,password,expected_code忽略首行选 True分隔符逗号。Recycle on EOF 选 FalseStop thread on EOF 选 True这样数据读完后线程停止不会反复使用同一批账号。Sharing mode 选 All threads多个线程共享文件读取位置。热词里提到“在同一个 CSV 参数化文件中每个线程分块取值”这个需求很常见。比如 100 个线程CSV 有 100 行希望每个线程固定拿一行不要交叉。最简单的方法是按线程拆文件data/users_${__threadNum}.csv。在 CSV 文件名里写data/users_${__threadNum}.csvSharing mode 选 Current thread。__threadNum从 1 开始每个线程读自己的文件互不干扰。前提是提前把总文件拆成users_1.csv到users_100.csv。另一种是用__CSVRead函数文件指针通常按线程独立维护适合简单分块场景但可读性不如拆文件。4.2 Token、ID 的动态关联登录后返回的 Token、用户 ID、订单 ID 都是动态值。JMeter 里用后置处理器提取。JSON 响应最适合 JSON Extractor比如响应{ code: 0, data: { token: eyJhbGciOi..., userId: 12345 } }添加 JSON ExtractorNames of created variables 填tokenJSON Path expressions 填$.data.tokenMatch No. 填1Default Value 填NOT_FOUND。下一个请求里用${token}引用。如果响应是 HTML比如老系统的隐藏域使用正则表达式提取器name__RequestVerificationToken typehidden value(.?)模板填$1$匹配数字1默认值NOT_FOUND。如果接口返回的是 XML用 XPath Extractor。提取后一定要在“察看结果树”里确认变量值不要猜。很多时候提取失败是因为 JSON Path 写错层级或者响应被压缩、编码不对。4.3 BeanShell/JSR223 断言怎么写录制脚本默认只看 HTTP 状态码但业务系统经常返回 200 却带错误码。比如{code:500,msg:库存不足}。这时需要断言。BeanShell 断言可以用但性能不如 JSR223 Groovy。简单示例String code vars.get(code); if (!0.equals(code)) { Failure true; FailureMessage 业务码异常 code; }在 BeanShell 断言里Failure和FailureMessage是内置变量。更推荐 JSR223 断言语言选 Groovydef code vars.get(code) if (code ! 0) { AssertionResult.setFailure(true) AssertionResult.setFailureMessage(业务码异常 code) }前提是先用 JSON Extractor 把code提取出来。断言不要写得太复杂能判断业务成功失败即可。响应时间断言、大小断言可以用 JMeter 自带组件。注意断言作用域放在采样器下面只影响该请求放在线程组下面影响所有请求。不清楚作用域时先用一个请求试验。4.4 Cookie、Header 与文件上传HTTP Cookie Manager 通常会自动处理 Cookie。录制时如果已经带了 Cookie回放时可能因为 Cookie 过期而失败。可以在测试计划里添加 HTTP Cookie Manager并设置“Clear cookies each iteration”为 False保证同一线程内会话保持。如果跨线程组共享 Cookie需要额外处理。Header 管理器用来补Content-Type、Authorization、Referer等。录制时 Header 可能带浏览器版本、User-Agent压测时不一定需要全部保留但Content-Type和鉴权头不能少。文件上传录制比较特殊。浏览器发送的是multipart/form-dataJMeter 里在 HTTP 请求中勾选“Use multipart/form-data”添加文件参数填写文件路径、参数名、MIME 类型。参数名必须和浏览器一致比如file、avatar。文件路径建议用相对路径或变量避免换机器后找不到。大文件上传要关注超时和内存JMeter 默认可能把文件读入内存文件特别大时要调整http.postBody相关设置或改用其他方式。5. 常见报错与排查技巧实录5.1 HTTPS 只录到 CONNECT 或提示证书错误这是 HTTPS 录制最常见的坑。现象是记录器里只有一条CONNECT请求没有后续正文。原因通常是证书没有被信任JMeter 无法解密。解决步骤确认ApacheJMeterTemporaryRootCA.crt已生成确认导入的是“证书颁发机构”而不是“个人”Firefox 要单独导入导入后彻底关闭浏览器再打开访问目标站点看地址栏是否仍报不安全。如果公司电脑有额外证书策略可能需要联系环境管理员但测试环境一般可以自行导入。另一个现象是证书导入后依然报错可能是浏览器使用了 HTTP/3 或 QUIC记录器对这类协议支持不好。可以在浏览器设置里关闭 HTTP/3或者换 Firefox 测试。还有可能是目标站点用了证书固定这种情况记录器很难直接解密需要改用其他方式获取接口。5.2 录不到请求、请求重复、请求缺失录不到请求先检查四件事记录器是否 Start浏览器网络设置是否指向127.0.0.1:8888过滤规则是否把目标域名排除了端口是否被占用。如果浏览器能上网但 JMeter 没请求多半是网络设置没生效。请求重复常见于重定向、自动重试、预检请求、页面轮询。可以在记录器里启用分组录制后删除重复请求。请求缺失可能是浏览器缓存清空缓存再录也可能是某些请求走 WebSocket记录器抓不到。还有一种情况是录制时操作太快页面还没加载完就点了下一步导致依赖请求没发出。录制时慢一点每步等页面加载完成。如果目标系统有验证码录制到的验证码是旧值回放必然失败。解决办法是让开发提供万能验证码、关闭验证码或者用 OCR、打码接口但压测环境更推荐前两种。5.3 回放报错error writing to server、防伪标记未提供java.io.IOException: error writing to server通常不是脚本逻辑错而是连接层问题。常见原因有请求体太大、Header 太大、服务端提前关闭连接、超时设置太短、压测机网络抖动、并发太高把服务端打挂。排查时先单线程跑如果单线程正常多线程才报说明是压力问题降低线程数或加超时。如果单线程也报检查请求体是否包含特殊字符、Content-Length 是否正确、是否启用了 Keep-Alive。__RequestVerificationToken 未提供必要的防伪标记是典型的老系统防伪问题。解决方式是先从登录页或表单页提取隐藏域再放到提交请求里。正则提取器示例name__RequestVerificationToken typehidden value(.?)模板$1$变量名requestToken。提交请求参数里加__RequestVerificationToken${requestToken}。如果该值同时存在于 Cookie 中也可以从 Cookie 管理器读取。注意提取时机必须在提交之前完成。5.4 扩展场景JDBC、MQTT、RESTful、结果导出如果压测需要从数据库取参数比如从用户表里查一批账号可以用 JDBC Connection Configuration 和 JDBC Request。配置数据库 URL、驱动类、用户名、密码查询语句写SELECT username, password FROM users LIMIT 100。在 JDBC Request 的 Variable Names 填username,password结果会变成username_1、password_1等。用 ForEach 控制器遍历或者用${username_1}直接取第一条。JDBC 驱动要放到lib目录MySQL 密码不要明文提交到代码仓库可以用变量或环境变量。MQTT 场景录制器录不到需要安装 MQTT 插件手动添加连接、发布、订阅采样器。RESTful 接口录制后要检查路径参数和查询参数比如/api/order/{id}里的id要参数化。察看结果树导出适合小规模调试右键导出 CSV 或 XML但压测时不要开监听器。命令行生成报告更可靠jmeter -n -t order.jmx -l result.jtl -e -o html-report如果报“文件已经存在”先删除result.jtl和html-report目录。这个报错很常见不是脚本问题。5.5 常见问题速查表现象常见原因解决方向只录到 CONNECTHTTPS 证书未信任导入 JMeter 临时根证书到受信任机构完全录不到请求浏览器网络设置未指向监听端口检查 127.0.0.1:8888 和记录器状态录制请求特别多静态资源、埋点未过滤配置 Exclude删无关请求回放 401/403Cookie、Token 缺失加 Cookie 管理器提取 Token 并传递业务码错误但 HTTP 200缺少业务断言用 JSON Extractor JSR223 断言error writing to server超时、请求体大、服务端关闭单线程验证调超时降并发防伪标记未提供隐藏域未提取正则提取__RequestVerificationToken文件已存在结果文件或报告目录冲突删除旧结果换文件名6. 从录制脚本到压测脚本的优化经验6.1 删、并、参、关、断五步整理法我整理录制脚本一般按五步走删、并、参、关、断。删是删静态资源、第三方请求、无关页面并是把同一业务的多个请求放进事务控制器比如“登录事务”“下单事务”参是把账号、商品 ID、搜索词换成变量关是把动态 Token、订单号、防伪标记做关联断是加业务断言和响应时间断言。五步做完脚本才算能用于压测。事务控制器要注意勾选“Generate parent sample”这样聚合报告里能看到事务整体响应时间。如果只想看事务时间不勾选也可以但子请求仍会统计。事务里不要放无关请求否则事务时间被拉长。思考时间用定时器模拟常数吞吐量定时器、高斯随机定时器都可以但不要在调试阶段加否则单次回放很慢。6.2 并发设置与结果分析压测线程组设置线程数、Ramp-up、循环次数或持续时间。模拟 100 用户并发可以设 100 线程Ramp-up 10 秒持续时间 300 秒。Ramp-up 太短会让瞬间压力过大太长则达不到并发效果。真正压测前先跑 1 线程、10 线程、50 线程观察 TPS、响应时间、错误率变化。如果 TPS 上不去但响应时间线性上升说明服务端有瓶颈如果错误率突然升高先看是超时还是业务失败。结果分析看聚合报告、Summary Report、HTML 报告。重点指标样本数、平均值、中位数、90% 线、95% 线、99% 线、最小、最大、错误率、吞吐量。不要只看平均值平均值会被少数快请求拉低。90% 和 99% 线更能反映用户体验。压测机本身也可能成为瓶颈CPU、内存、网络带宽都要看。如果压测机 CPU 跑满先换机器或分布式压测不要急着下结论。6.3 脚本维护与团队协作的坑录制脚本如果不做版本管理过两周就没人敢改。建议把.jmx文件、CSV 数据、证书说明、环境地址分开管理。环境地址用用户定义变量或属性文件不要写死在请求里。CSV 文件不要提交真实用户密码测试环境用专用账号。证书文件不要提交到仓库只提交导入说明。团队协作时统一命名规范线程组按业务命名事务控制器按步骤命名采样器用“动词名词”。比如“登录”“查询商品”“提交订单”。变量名用英文小写加下划线不要用中文变量名避免编码问题。脚本里加注释说明动态参数从哪来、断言逻辑是什么。这样一来别人接手时不用重新录一遍。最后分享一个我自己的习惯录制脚本永远只当草稿不直接交付。每次录完先跑一遍单线程把动态参数全部找出来再跑 10 线程验证会话隔离最后才做参数化和压测编排。踩过几次坑之后我宁可多花半小时清理也不愿意在压测现场对着满屏红色错误猜原因。