企业官网建设流程全解析

录制脚本这件事，说大不大，说小不小。我刚接触压测那会儿，总觉得“录制脚本”是把浏览器操作变成JMeter脚本的捷径，但真正动手才发现，坑全藏在细节里：证书没导入、代理没配对、脚本录出来一堆静态资源请求、录完跑压测直接报连接重置。这几年带着团队做过不少压测项目，也帮别人排过很多录制相关的坑，整理一篇完整的实操记录，从原理到步骤再到避坑，一次讲透。

这篇内容适合刚接触JMeter、想通过录制快速生成测试脚本的人，也适合已经会用JMeter但录制HTTPS总失败、脚本录完不会整理的测试工程师。看完你应该能独立完成一次“录制—整理—验证—可压测”的完整闭环。

1. 先说清楚：录制脚本到底是怎么回事

很多新手有个误解，以为录制脚本是JMeter“自动分析”了你的操作，然后生成智能脚本。实际完全不是这么回事，录制的本质是代理拦截。

JMeter在录制时会在你电脑上启动一个HTTP代理服务器，你在浏览器里的每一次请求，都会先经过这个代理，JMeter把请求内容（URL、请求头、请求体、参数、Cookie等）原样抓下来，再翻译成对应的Sampler采样器。所以录制脚本这个动作，本质上是“拦截并翻译HTTP通信”。至于你的业务逻辑、参数关联、动态令牌，都靠后续整理。

这意味着两件事：

• 第一，不是所有请求都能录到。走系统级代理的流量能抓到，但有些应用不走系统代理（比如某些客户端、命令行工具），就录不进去。
• 第二，录出来的脚本只是“草稿”，不是“成品”。你点了10次页面，可能录出200多个请求，其中大半是图片、CSS、JS、字体等静态资源，这些对压测业务接口来说往往要剔除。

所以在动手录制之前，先想清楚：你的目标是什么？是录一条完整的业务链路（比如登录→查询→下单），还是录单个接口？业务链路建议用录制快速搭骨架，再手动改；单个接口不如直接用Badboy抓包或者直接手写HTTP请求，录制反而效率低。

我在实际项目里一般这么定：复杂的多步骤业务流程（5步以上、依赖动态参数），先录制再整理；简单接口（1到3步），直接手写或从抓包工具复制。记住这个原则，你后面会省很多事。

2. 环境准备：别小看这一步，录不录得成HTTPS全看它

录制前的环境准备，可以分为四个部分：JDK和JMeter版本匹配、JMeter本身安装、必要插件（如录制HTTPS所需证书）、浏览器代理设置。很多人跳过其中某一步，结果录制时各种怪问题。

2.1 JDK与JMeter版本匹配

JMeter是纯Java应用，JDK版本和JMeter版本不匹配，最典型的报错是“UnsupportedClassVersionError”或者启动后界面某些功能异常。建议用下表对照：

我本人的习惯是长期使用JDK 8配合JMeter 5.x系列，大量项目验证过，兼容性最稳。如果追求JSON提取器里更完善的语法支持或脚本中用到较新的Java特性，可以上JDK 11，但注意Beanshell等旧组件在JDK 11下偶有问题，能用JSR223就不要用Beanshell。

2.2 JMeter安装与启动

下载地址上官网认准Apache JMeter的发行版，不要从第三方站点下载来路不明的压缩包。拿到包后解压，进入bin目录，Windows双击jmeter.bat（或者用管理员权限打开），macOS/Linux执行./jmeter。

这里有几个启动时的细节：

• 如果启动报错“java.lang.IllegalArgumentException: Unsupported class file major version”，基本可以断定是JDK版本低于JMeter要求，不用查别的。
• 如果双击无法启动、窗口一闪而过，先用命令行启动：jmeter.bat或者jmeter -v，通常能看到真实的报错信息。
• JMeter GUI模式本身比较吃内存，录制阶段的资源开销不算大，但正式压测不建议开GUI。录制阶段用默认堆内存即可，压测前再调整jmeter.bat里的HEAP参数。

2.3 插件安装

录制HTTPS脚本或使用更好的录制体验，需要关注两个东西：安装证书（bin目录下已有ApacheJMeterTemporaryRootCA.crt，录制脚本启动代理时会自动生成）和必要的插件管理器。插件管理器Windows直接下载plugins-manager.jar放进lib/ext目录，重启JMeter后在“选项→Plugins Manager”中按需安装插件。

录制本身不需要额外插件，但如果你需要WebSocket、MQTT这类协议的录制能力，就需要相应插件。热搜词里提到“jmeter下载mqtt插件”，说明很多人需要在JMeter里压测MQTT服务，这类场景就靠插件管理器解决。

2.4 关键点：让录制更干净的常用配置

在正式开始录制之前，我强烈建议你先在JMeter里做两个配置：

• 在bin/jmeter.properties中找到proxyhandler.httpsampling，确认是否开启HTTPS采样（默认情况下JMeter代理可以解析HTTPS，但证书信任链必须装好）。
• 建议增加mode=Standard或mode=BODY，这样录制的采样器在“察看结果树”中可以看到完整的请求体和响应体，方便录制后确认内容。

配置完成后，启动JMeter，正式进入录制流程。

3. HTTP录制完整步骤：从创建脚本录制器到跑通首条脚本

这里以最常用的HTTP协议为主，HTTPS的证书问题在下一节专门讲。

3.1 创建测试计划与线程组

打开JMeter后，选中“测试计划”，右键添加“线程组”。线程组里的线程数在录制阶段设1个就够了，录制只是为了抓请求，不是为了压测。但线程组的命名建议直接体现业务场景，比如“录制-登录查询下单”，这样后面整理时一眼能认出归属。

3.2 添加HTTP代理服务器

关键一步来了。在“测试计划”上右键，选择“添加”→“非测试元件”→“HTTP代理服务器”。这个元件就是录制的中枢。

代理服务器的核心配置项如下：

分组策略我在这里多说一句。默认“每个组放入一个新的控制器”会在每个事务（浏览器标签页）下建一个“简单控制器”，把请求分门别类放进去。这个策略最贴近业务流程，整理脚本时可以直接按控制器为单位保留或删除，比“全部请求放一个平铺列表”好找得多。

3.3 启动代理并配置浏览器

点击“HTTP代理服务器”面板右下角的“启动”按钮，JMeter会在本地启动代理服务并在bin目录下生成临时CA证书（仅用于录制）。这时需要在浏览器里设置代理指向127.0.0.1:8888。

不同浏览器设置代理的路径差异不大，这里以Chrome为例（注意新版Chrome对系统代理依赖度高）：

• 打开浏览器设置，搜索“代理”
• 进入“打开您计算机的代理设置”
• 手动设置代理，地址填127.0.0.1，端口填8888
• 点击保存

设置好后，浏览器访问任意HTTP站点，JMeter代理面板下方的“记录”列表中会实时刷出请求，这一步看到请求在跳，就说明代理链路通了。

3.4 执行操作，停止代理

配置好代理后，在浏览器里按你的业务用例操作：登录、填写表单、点击按钮、查询数据，一步步走完。操作越接近真实用户，录制出来的脚本越完整。操作完成后回到JMeter，点击代理服务器面板上的“停止”按钮，再关闭浏览器代理（这一步很多人会忘，导致之后浏览器上不了网）。

此时去线程组下面查看，会发现已经生成了大量采样器。别被数量吓到，这是正常的，一个页面可能产生几十个请求。

3.5 首次回放：确认录制脚本能跑通

右键线程组，“添加”→“监听器”→“察看结果树”，点击运行按钮，看录制的请求是否有绿色回调。假如全是绿色，恭喜你，录制链路基本没问题；假如有红色请求，先不要急着怀疑录制，去“察看结果树”看响应体里的具体报错，大部分情况是登录态的Cookie或Token问题，这在后面的脚本整理阶段会专门解决。

我第一次录制时犯过一个低级错误：录制完直接在JMeter里点运行，结果返回“401 Unauthorized”。后来检查才发现，录制时的登录态已经过期了（操作和回放间隔太久），重新走一遍录制流程就好了。所以如果你回放失败，先确认浏览器录制时的登录态是否还在有效期内，再做其他排查。

4. HTTPS录制：证书问题一次讲透

HTTPS录制是很多新手卡壳的地方。热搜词“jmeter录制https脚本”和“jmeter安全证书”热度很高，说明这是普遍痛点。HTTPS和HTTP录制的本质区别在于：HTTPS涉及到CA证书的信任，JMeter作为中间人需要生成自己的CA根证书，并且让浏览器信任它，才能解密HTTPS流量。

4.1 获取JMeter的CA证书

启动代理之后，JMeter在bin目录下会生成一个叫ApacheJMeterTemporaryRootCA.crt的证书文件，也有可能是ApacheJMeterTemporaryRootCA（无扩展名，需要手动加.crt）。这个文件的位置可以在jmeter.properties里通过proxy.cert.directory修改，默认是bin目录。

4.2 将CA证书导入浏览器/系统信任库

Windows系统操作比较简单：双击这个.crt文件，选择“安装证书”，存储位置选“本地计算机”，然后选择“将所有证书放入下列存储”，点击“浏览”选择“受信任的根证书颁发机构”，按提示完成导入。

macOS系统操作也很方便：双击证书文件，钥匙串访问会弹窗，把证书加入“系统”钥匙串，然后在证书列表中双击刚刚导入的证书，展开“信任”，把“使用此证书时”改为“始终信任”，关闭并输入系统密码确认。

Android手机如需录制App的HTTPS流量，把证书文件传到手机里，在设置中搜索“证书”或“加密与凭据”，选择“安装证书”，类型选“CA证书”，确认安装即可。iOS系统不展开说，因为仅限HTTPS录制采用的是针对iPhone的代理配置方式，需要额外在App中信任。

4.3 浏览器代理里的HTTPS处理

证书导入后，关键一步是在浏览器代理设置里勾选“对https地址也使用代理服务器”（部分浏览器这个选项在系统代理中默认开启，有些需要手动）。如果你用的浏览器不支持直接控制HTTPS代理，可以考虑为浏览器配置PAC脚本或使用支持全局代理的插件。

4.4 HTTPS录制的几个经典报错

4.5 实测经验：证书问题排查链路

如果你遇到HTTPS录制失败，按下面这个顺序排查，可以少走很多弯路：

1. 先去浏览器的“不安全连接”页面看具体报错，是“证书不受信任”还是“证书过期”。
2. 查看JMeter的代理面板“记录”区域有没有出现请求，如果完全没有请求，先排查代理配置，别急着看证书。
3. 如果请求出现了但是全红，看窗口输出里的SSL相关报错，再检查证书是否被信任。
4. 确认证书文件名是否正确。我同事遇到过证书生成在bin目录里但文件名少了扩展名，直接把整个文件拖入浏览器安装，结果提示“无法识别”，加个.crt后缀就好了。
5. 清理浏览器缓存和SSL状态缓存，重试。有些场景下浏览器缓存了旧证书状态，会导致新的JMeter证书不生效。

另外一个容易被忽略的点：JMeter代理启动时生成证书是有时效的。如果你多次启动代理，JMeter会尝试复用同一个证书，但如果证书过期或损坏，可以删掉bin目录下的ApacheJMeterTemporaryRootCA.crt和对应的私钥文件（一般是同目录下的.key文件），重新启动代理会生成新的证书。

5. 录完的脚本不能直接用：整理、参数化、关联的完整处理

录制大概率会产生大量冗余请求。如果你拿刚录完的脚本直接压测，通常会出现几个问题：一是静态资源请求大量堆积，压测请求数虚高；二是动态参数（Token、Session、时间戳）没有处理，并发一上来就报错；三是脚本结构混乱，后期维护困难。所以录制后一定要做脚本整理。

5.1 脚本瘦身：剔除静态资源与辅助请求

识别哪些请求该删，有个简单原则：不是业务核心链路的请求，且不携带业务状态，都是静态资源或辅助请求。典型包括.jpg、.png、.css、.js、.woff、.ico、.gif、.svg等文件资源请求。另外，页面埋点、统计上报、第三方广告等请求通常也与被测业务无关，可以一并删除。

具体操作时，在“察看结果树”里看到URL后缀是图片或静态资源，右键“禁用”而不是“删除”。禁用后如果后续压测发现某个禁用请求其实是业务依赖，恢复勾选即可。用“禁用”代替“删除”，是我在整理脚本时最推荐的做法，因为禁用后脚本还能在“察看结果树”里看到请求信息，需要恢复时点一下勾选就行。

录制完的脚本如果请求数量还是很大，可以在“HTTP代理服务器”的“请求过滤”中使用正则表达式排除.*\.(js|css|png|jpg|gif|svg|ico|woff|ttf).*，下次录制时这些静态资源就不会被录进来。

5.2 参数化：从CSV文件读取用户数据

压测100个并发用户，如果全部用同一个账号，后端大概率会触发限流或风控，也测不出真实场景。参数化的本质是把脚本里的写死的数据提取成变量，让每个虚拟用户用不同数据。

具体步骤：

1. 准备CSV文件，格式类似：username,password，首行为列名或按序排列。
2. 在测试计划或线程组下添加“配置元件”→“CSV数据文件设置”。
3. 配置项里填上CSV文件路径、变量名（如username）、分隔符（默认逗号）、碰到文件结束符是否循环（建议勾选“循环”）、是否共享模式（一般用“所有线程”）。
4. 在HTTP请求的“参数”中用${username}引用变量。

需要特别注意编码问题。CSV文件如果含有中文，建议另存为UTF-8编码（不带BOM），并在“CSV数据文件设置”中文件编码填UTF-8，否则会出现乱码，登录直接失败。

5.3 关联：动态参数的提取与传递

录制脚本最大的坑是动态参数。录制时Token、SessionId、时间戳都是登录时从服务器返回的，直接回放往往因为令牌过期或不存在而失败。关联就是让脚本能从某个请求的响应中提取动态值，并作为后续请求的参数。

JMeter常用的提取工具是“后置处理器”→“JSON提取器”（适用于JSON响应）和“正则表达式提取器”（适用于任意文本）。举一个最典型的场景：登录接口返回一个token字段，后续接口需要在请求参数携带token，步骤如下：

1. 在登录请求上右键，添加“后置处理器”→“JSON提取器”。
2. 变量名称填token，JSON Path表达式填$.data.token（根据实际响应结构调整），匹配数字填1。
3. 在后续请求的参数中用${token}引用。

正则提取器的写法大同小异，正则表达式填"token":"(.*?)"之类，模板填$1$，匹配数字填1。这里要提醒一句：能用JSON提取器就不要用正则，正则对响应格式变化更敏感，一旦服务端字段顺序调整或加个空格，脚本就可能失效。

我整理过一个下单链路脚本，登录接口返回的token在3分钟后过期，而压测设了5分钟的持续运行时间，导致后面的下单接口大量失败。解决方法是在脚本中用循环控制器或Random定时器维持登录态刷新，或者将业务链路的思考时间缩短，让压测在token有效期内完成。这类坑在真实项目里很常见，整理脚本时务必关注动态值的有效期。

5.4 事务控制器与取名规范

脚本整理完之后，给每个业务步骤添加“逻辑控制器”→“事务控制器”，把登录、查询、下单等请求分别包进去。事务控制器可以帮助你在聚合报告里按“事务”维度查看响应时间，压测报告更立体。

命名规范方面，我的建议是：控制器用业务名称，采样器用“序号+接口名+简要作用”，比如“01-登录接口-获取token”。这样几百个请求的脚本别人一眼能看懂，后面维护成本大幅降低。

6. 用察看结果树和断言验证录制脚本的正确性

脚本整理完，下一步是验证：跑一次，确认所有请求都是绿的，并且绿得不只是状态码，响应内容也正确。这里“响应内容正确”往往是新手最容易忽略的点——接口返回200不代表业务成功，可能响应体里是个错误码。

6.1 察看结果树的正确用法

“察看结果树”监听器在录制阶段和验证阶段的作用不同。录制阶段用它看请求是否捕获成功，验证阶段主要看三样东西：

• HTTP状态码：2xx和3xx一般算正常，4xx和5xx需要排查。
• 响应内容：是否包含关键业务字段，比如登录后是否返回了token、userId。
• 请求参数：是不是正确替换了变量，${token}是否被真实值替换，一旦看到请求参数里还有未替换的${xxx}，说明变量引用有误。

查看请求参数是否成功替换的办法：在察看结果树里选中请求，切到“请求体”标签页，看POST请求体里的具体内容。如果还有${}形式的变量，说明提取器没生效或变量名拼错了。

6.2 断言：让脚本自己判断正确性

验证阶段可以加断言，也可以在压测阶段保留断言，让JMeter在压测过程中自动标记“业务失败”的请求。不过断言不是越多越好，断言越多压测性能开销越大。建议只在关键业务节点上加断言。

最常用的是“响应断言”，可以配置“包括”模式，检查响应内容是否包含某个特定文本。比如登录接口断言包含"code":0，下单接口断言包含“下单成功”。具体步骤：选中请求，右键添加“断言”→“响应断言”，在“要测试的模式”里添加需要匹配的内容，模式匹配规则选“包括”，同时可以勾选“自定义失败消息”，这样压测报告里能直接看到失败原因。

特别注意：响应断言的正则匹配是“匹配整个模式串”，默认.*不会自动补全首尾。所以如果你想只匹配“成功”这两个字，模式填成功即可，不需要写.*成功.*，但如果你用了正则语法做复杂匹配，要注意.不会匹配换行符。

6.3 验证清单：什么算“脚本可以压测了”

整理完脚本，跑一遍单线程验证，符合以下条件再进压测：

• 所有核心业务请求返回绿码，且响应内容断言通过。
• 没有未替换的${}变量。
• 脚本中的登录态、Cookie、Token能维持整个业务流程走通。
• 参数化文件中的数据量能够覆盖计划并发数，不会出现数据用尽或循环冲突。

满足这四条，脚本基础质量就有了保障。

7. 录制压测中的高频问题与排查方法

最后把我在实际项目和帮人看问题过程中积累的常见问题集中写一下。这些问题很多不是录制本身的问题，而是录制前、录制后没注意细节导致的，但搜索引擎热词里都在搜，说明踩坑的人非常多。

7.1 浏览器代理设置后无法上网或页面白屏

优先检查JMeter代理服务器是否处于启动状态。代理启动后浏览器所有流量都走本地代理，一旦JMeter关闭或代理没开，浏览器就会断网。操作顺序很重要：先启动JMeter代理，再配置浏览器代理；停止录制时先关代理，再恢复浏览器代理。另外，有的浏览器（如Firefox）自带代理设置覆盖了系统代理，需要单独在浏览器里配置。

7.2 录制下来的请求在“察看结果树”中全是HTTP 404

这个常见于前端是单页应用（SPA）的场景。SPA页面的路由跳转往往通过JavaScript完成，请求可能是相对URL，在JMeter录制结果里会变成路径缺失或拼接错误。解决方案是录制完成后检查请求URL，手动修正为完整地址；或者干脆不用录制，直接在开发者工具Network面板里找到真正的XHR请求，复制信息到JMeter中手动建请求。

7.3 “java.io.IOException: Error writing to server”怎么破

这个报错在压测过程中很常见，原因是JMeter向目标服务器发送数据时I/O异常，通常跟网络不稳定、服务器连接数打满或请求体过大有关。排查链路：

• 看压测机与目标服务器之间的网络是否丢包。
• 看后端连接数是否达到上限，如果超了并发连接，会有大量这类错误。
• 看是否踩了服务器防火墙或负载均衡的流量限制。
• 适当调大JMeter的socket.keepalive相关参数，但治标不治本，根因一般不在JMeter。

7.4 录制登录接口出现“__RequestVerificationToken 未提供必要的防伪标记”

很多基于ASP.NET MVC或Web框架的应用有CSRF/XSRF防护机制，页面里会埋一个隐藏的__RequestVerificationToken字段，提交表单时必须带回。录制脚本如果只录了POST请求但没带上这个token字段，回放就会报这个错。

解决方式是用正则或JSON提取器从登录页面的响应里提取隐藏字段的值，拼到POST请求体里。具体提取正则可以参考name="__RequestVerificationToken" type="hidden" value="(.*?)"。这类防伪令牌是典型的“录制脚本必须做关联”的场景，也是检查脚本是否真正整理好的试金石。

7.5 压测时请求乱序或并发数上不去

录制脚本回放是单线程顺序执行，压测时如果没加“同步定时器”（即集合点），线程组里的每个线程是会按自身节奏跑的，可能出现请求顺序和录制时不一致。如果想要所有并发用户同时发起某个请求，可以在该请求前添加“同步定时器”，设置同步用户数等于线程数，超时时间按需设置。

并发数上不去，优先看JMeter本身的运行机器负载（CPU、内存、网络）、被测服务器的承受能力，以及本机是否开启了GUI监听器。压测阶段强烈建议以命令行模式运行：jmeter -n -t 脚本.jmx -l 结果.jtl -e -o 报告目录，GUI里加的察看结果树聚合报告等监听器会严重拖慢Jmeter吞吐。

7.6 CSV参数化文件每个线程分块取值的问题

热搜词里有一条“jmeter在同一个csv参数化文件中每个线程分块取值”，这个需求一般是想让不同线程组或不同线程取CSV的不同区块，避免数据冲突。

实现方式：在“CSV数据文件设置”中，共享模式选择“当前线程组”或“所有线程”，再配合“线程数”和循环次数来控制每个线程读取的行数。如果追求更精细的分块，比如线程1读1-100行，线程2读101-200行，可以在脚本中用__CSVRead()函数或配合BeanShell/JSR223读取CSV，并在变量名中带上线程编号${__threadNum}做拼接定位。

7.7 JMeter界面字体调整

顺带说一下界面字体的调整。JMeter默认字体在部分高分屏下偏小，修改bin/jmeter.properties里的jmeter.hidpi.mode=true和jmeter.hidpi.scale.factor=2.0可以解决高DPI下模糊的问题，具体缩放系数按需调整。字体大小则可以在“选项→外观”里换主题，或在jmeter.properties里修改jmeter.user.properties相关的swing字体设置。

7.8 JDBC 参数化与数据库关联

脚本里如果涉及数据库参数化（热搜词里也有“jmeter jdbc request参数化”），常见两个场景：

• 把数据库查到的数据作为后续接口参数：添加“JDBC Connection Configuration”和“JDBC Request”，在JDBC Request里写查询SQL，结果变量名填dbResults，后续接口用${dbResults_1}引用第一行第一列的值。
• 接口返回的数据反查数据库验证：可以添加“JDBC Request”后加断言，查询结果为空则失败。

JDBC参数化最大的坑是数据库连接数。并发大时，JDBC连接池太小会报Cannot create PoolableConnectionFactory，建议根据并发规模调大连接池最大连接数。

写在最后：关于录制脚本的几点个人经验

录制脚本只是JMeter性能测试链路里“造车”的开端，真正决定压测结果有效性的，是脚本整理环节对动态参数、业务链路的处理。我个人碰过太多“录完就跑”导致压测数据完全失真、被开发质疑的案例，所以特别强调一遍：录制的产物是草稿，整理后的脚本才叫脚本。

另外提一个小技巧：录制前先在浏览器打开开发者工具的Network面板，把请求分类方式切到“Fetch/XHR”，操作业务时专门记录这些接口的调用顺序和参数格式。录制出的脚本如果哪里不对劲，用Network面板里的原始请求做对照，一眼就能发现录制器丢参数或漏请求的问题。

录制脚本是入门JMeter的一个重要里程碑，也是理解HTTP请求细节的天然教材。把录制、整理、验证这套流程走顺，往后无论手写脚本、调试接口、排查压测报告，你都会比没走过这条路的人快不少。