做性能测试第一步往往不是写脚本而是拿到一份像样的脚本。提到“脚本录制”很多刚入行的朋友会下意识觉得这是最没技术含量的一环——不就是开着代理点几下鼠标把操作录下来吗但实际上我这些年看过太多项目脚本录制这一步没走好后面压测、分析全是在错误的数据上盖楼结果越忙越乱。录制这个环节表面上是把用户操作“变成”脚本本质上是在解决一个问题如何让测试脚本最大程度贴近真实用户行为同时又能被压测工具解析、扩展并驱动起来。这篇内容我会围绕Web端和App端Android、iOS两条主线把JMeter录制性能测试脚本的完整思路、实操步骤和踩坑经验都拆开讲一遍也会把现在热搜上经常提到的“AI生成性能测试脚本”这件事说清楚——哪些是能落地的哪些还是宣传话术希望你读完能有个自己的判断。1. 性能测试脚本录制的核心思路1.1 为什么非要从“录制”入手性能测试不是把接口通一次就完事它的核心目标是模拟出多个用户同时操作时的真实压力然后观察系统扛不扛得住。真实用户的操作链路是什么打开首页、登录、检索、下单、支付每一步都会产生多个HTTP请求。这些请求里往往还有加密参数、token、时间戳、签名等动态内容。如果纯靠手工逐个去写HTTP请求不是不能写而是成本极高而且容易写错——尤其对于业务复杂、链路很长的系统手工维护几百个请求的脚本效率低到没法接受。录制脚本的思路就是利用工具在客户端和服务器之间架一个“中间人”把客户端发出去的每一个请求都拦截下来、解析成结构化数据再自动转换成测试工具认识的脚本格式。这样做的最大好处是脚本能如实还原用户操作路径包括请求头、请求体、参数生成规则、访问顺序等比手工臆想的脚本可靠得多。1.2 录制的本质把“流量”变成“脚本资产”说得更本质一点录制的过程就是把一段时间的真实HTTP流量转化为可维护、可复用、可扩展的脚本资产。这个过程中工具帮你完成的是“翻译”和“还原”工作——翻译指的是把抓到的报文变成Sampler取样器还原指的是通过代理服务器把加密流量解密后还原出请求内容。理解这一点很重要因为它决定着你后续怎么处理录制后的脚本。录制完成的脚本本质上只是一个“骨架”真正的动态参数提取、业务逻辑组织、并发模型建模其实都要靠后面的手工调整。很多新人误以为录制完脚本就算万事大吉直接拿去做压测结果并发一上来全是报错这就是没有理解录制的“资产”属性——它只是基础不是成品。1.3 手工编写与脚本录制的取舍对比方式优势劣势适用场景手工编写HTTP脚本灵活可控脚本结构清晰工作量大易遗漏真实请求细节接口单一、业务链路短、纯API服务录制脚本Web端还原真实浏览器行为省时会录制大量静态资源请求需清洗页面操作复杂、需要还原UI级链路录制脚本App端能拿到App真实协议兼容复杂加密参数需要处理证书、部分App防抓包移动端压测、端到端链路Har包/日志转换来源丰富可批量生成需要额外工具链、转换后仍需清洗已有现成流量数据、回归验证2. 工具选型解析2.1 当前可用的几类录制工具一说录制脚本老一代测试工程师可能马上想到Badboy。这个工具在当年确实是Jmeter录制脚本的标配导出脚本到JMeter也方便。但Badboy已经停止维护很多年对现代浏览器的支持、对HTTPS流量的解密能力都很弱我不建议新项目再往这个方向投入。它的历史意义大于实用价值。目前主流的录制路径无非三类第一类是用JMeter自带的HTTP代理服务器录制这也是最通用、零成本的一条路后面我会详细展开。它不需要额外安装什么插件只需要在JMeter里添加一个代理服务器组件把浏览器或手机的代理指过去就行。第二类是用抓包工具Charles、Fiddler、Wireshark等抓到流量后再通过导出Har文件的方式转成JMeter脚本。这种方式的优势是抓包工具本身的界面友好、过滤规则灵活缺点是中间多了一道转换环节很多动态参数得在转换后重新提取。第三类是现在讨论度较高的“AI生成脚本”核心思路是基于业务描述或API文档利用大模型生成脚本框架或者借助开源工具将Har文件、Postman Collection等结构化数据自动转成JMeter脚本。这个方向还比较早期但已经有可用的东西我放到第4章专门讲。2.2 为什么多数场景下选JMeter自带代理我的习惯是除非团队里已经有一套成熟的抓包工具链否则优先用JMeter自带的HTTP代理服务器。原因有三个。第一少一层转换录制即所见录出来的东西就是Sampler不用再想办法从Har里面解析。第二JMeter代理服务器在录制时可以把域名、端口、路径、参数全部结构化地存进线程组配合“分组”功能还能按请求顺序自动分层后期整理成本低。第三它天然支持HTTPS解密虽然在App端装证书也有一些坑但基本可控。当然有些场景我不建议用JMeter自带代理比如需要精确抓取TCP层、TLS层细节的排障场景这时候用Wireshark更合适。但纯论“录制性能测试脚本”这个目标JMeter自带代理足够了。3. 实操过程与核心环节实现3.1 Web端录制5分钟跑通一套完整流程先演示一遍最常见的JMeter录制Web端操作流程。假设你本地已经装好了JMeter并且测试计划已经建好。第一步在测试计划下添加一个线程组线程数可以先设1方便录制时每条请求都能看清。第二步在工作台或测试计划下添加“HTTP代理服务器”位置是“添加 - 非测试元件 - HTTP代理服务器”。这里我把录制到的脚本归类到线程组下所以“目标控制器”选择刚才建好的线程组。第三步配置端口。端口号默认是8888这个一般不用改但如果被占用换成其他未占用端口即可。注意这个端口是指JMeter代理服务器的监听端口后面浏览器或手机的流量要指到这个端口上。第四步设置“分组”。我习惯选择“每个组放入一个新的控制器”这样录制完成后每个业务子流程会独立成一个简易控制器后期可以很方便地给每个控制器加事务、加思考时间。如果你不分组所有请求会平铺在线程组下几十上百个请求堆在一起后期整理会很痛苦。第五步配置“排除模式”。这一步非常关键排除模式是用来过滤静态资源请求的。图片、CSS、JavaScript这些静态文件大多不参与核心业务计算压测时如果不对它们单独建模通常不建议录制进来。我常用的排除正则如下.*\.js$ .*\.css$ .*\.png$ .*\.jpg$ .*\.jpeg$ .*\.gif$ .*\.ico$ .*\.svg$ .*\.woff.* .*\.ttf$你可以复制上面这些粘贴到排除模式里。如果有其他后缀按同样规则追加。第六步启动代理服务器。点击“启动”后JMeter会提示需要设置一个根CA证书这个过程是自动的你只需要在浏览器里信任它即可。启动成功后在浏览器里设置HTTP代理为127.0.0.1:8888然后正常访问被测系统执行一遍关键业务流程就可以在JMeter线程组下看到录到的HTTP请求。第七步停止录制恢复浏览器代理设置。录完之后记得立即关闭代理服务器并把浏览器代理恢复为“直连”或原来的配置否则后续正常上网都会卡在JMeter这一层。到这里一次最简单的Web端录制就完成了。3.2 HTTPS录制证书问题最容易被拦住的坎如果你只是走一遍上面的流程录HTTP网站基本没问题但现在的系统基本都是HTTPS录制时稍不注意就会遇到“录到了请求但请求体是乱码”“浏览器直接报证书不可信”等问题归根结底是证书没有处理好。JMeter作为代理服务器监听HTTPS流量时本质上是在中间做了一次“证书替换”——它用自己的根证书动态生成一张目标站点的证书客户端浏览器如果信任了JMeter的根证书就会信任这张动态证书从而让JMeter能解开HTTPS流量。这个过程其实就是MITM中间人代理的核心原理只不过用在了合法的测试场景里。所以核心操作就是把JMeter生成的根证书导入到浏览器的受信任根证书颁发机构列表中。具体路径是JMeter的bin目录下有一个ApacheJMeterTemporaryRootCA.crt文件双击它选择“安装证书”存储位置选“本地计算机”证书存储选择“受信任的根证书颁发机构”一步一步确认即可。注意导入证书后要彻底关闭浏览器再重新打开否则很多浏览器不会立即加载新证书。这里有一个我踩过多次的坑JMeter自带的这个临时根证书是有有效期限制的而且默认有效期不长。证书过期后录制时浏览器会直接提示“连接不是私密连接”但很多人根本想不到是JMeter证书过期了以为是代理设置或防火墙的问题。最简单的确认方法在浏览器里访问一个HTTPS站点如果报错信息里提到证书颁发者、证书日期相关信息基本就是JMeter根证书过期了。解决方式是删除旧证书重新在JMeter里生成新证书并安装。3.3 App端录制Android和iOS的操作差异App端录制和Web端录制在思路上一致都是把流量引到JMeter代理上但多了几个移动端的特有环节。前提条件手机和电脑必须在同一个局域网内这个很多人容易忽略。手机上的“WiFi代理”设置为电脑的局域网IP加JMeter监听端口。这里的IP不能用127.0.0.1因为那是手机自己。你可以在电脑上执行ipconfigWindows或ifconfigmacOS/Linux查看当前局域网IP。代理设置完成后App的HTTP流量理论上都会走JMeter代理。流量是HTTP的话直接就能录到但如果是HTTPS依然要装证书到手机上。Android和iOS的证书安装方式不同iOS端手机用Safari浏览器访问http://代理IP:端口页面会提示下载证书下载完成后到“设置 - 通用 - 关于本机 - 证书信任设置”里把对应的证书信任开关打开。这里最容易漏掉的就是最后一步“信任开关”如果你只下载没信任JMeter依然解不开HTTPS流量。Android端证书下载后是一个.crt或.pem文件不同版本的Andorid流程差异较大。大多数情况下需要到“设置 - 安全 - 加密与凭据 - 安装证书”里选择CA证书。Android 7.0以后App默认不信任用户安装的CA证书所以很多App即使你装好证书也抓不到包。这时候常规做法是让开发提供一份debug包在AndroidManifest里配置networkSecurityConfig允许用户证书或者把测试证书装进系统证书目录需要root。这个不属于脚本录制本身的范畴但可以说是App端录制绕不开的准备工作提前跟开发团队打招呼会省很多事。另外很多主流App会做防抓包检测到代理环境后直接拒绝网络请求或者返回空白数据。这种情况下单纯依靠JMeter代理的方式是录不到脚本的。实际项目里的替代方案是让开发提供测试专用的APK包关闭防抓包逻辑和SSL Pinning证书绑定如果实在拿不到只能用“云真机服务端日志”的方式从后端日志里提取请求模板来人工构造脚本。不过这一块背后的逻辑比较复杂不是简单配置能解决的。3.4 录制完成后的脚本清洗去掉“垃圾请求”录制结束后你大概率会看到线程组下堆着一大堆请求其中很多是静态资源。如果选了分组、配了排除模式情况会好很多但依然可能出现三类“垃圾请求”一是埋点请求很多Web页面有各种统计埋点这些请求对业务压测没有价值二是长连接/WebSocket请求JMeter默认的HTTP Sampler不一定能正确解析需要单独处理三是被重定向的请求录制时如果浏览器自动跟随了重定向JMeter会录到多个Hop后期要确认主请求是哪个。我的处理方案是录制完成后先整体浏览一遍请求列表把明显无关的请求先禁用掉快捷键CtrlE而不是直接删除。禁用的好处是一旦后续发现有些请求其实是业务链路的一部分可以快速恢复不用重新录制。这块操作没什么技术含量但直接影响后续压测的脚本清洁度。3.5 关联、参数化、断言录制后必做的三件事录制完脚本真正的工作才刚刚开始。从严格意义上讲录制只是拿到了“静态脚本”要让脚本能在性能测试中跑起来必须解决三件事关联、参数化和断言。关联解决的是“动态值传递”问题。典型场景是登录后返回的token后续请求需要带上这个token。录制时token是写死的具体值但你压测时100个用户不能都拿同一个token所以得从登录响应里动态提取。JMeter里常用的提取器是正则表达式提取器和JSON提取器前者适合从任意文本里抓取后者适合从JSON响应里定位字段。比如登录返回的响应体是{data:{token:abc123}}用JSON提取器设一个$.data.token就能动态取到。提取出来后后续请求的HTTP Header管理器里用${token}引用即可。参数化解决的是“数据多样性”问题。100个用户并发登录如果所有用户都用同一个账号一是服务器可能有单一账号并发限制二是测试结果完全失真。正确做法是把不同用户的用户名和密码放在CSV文件里用CSV数据集配置元件读取让每个线程使用不同账号。同样的道理也适用于搜索关键词、商品ID、订单号等业务数据。断言解决的是“请求是否成功”的问题。JMeter里最简单的做法是加响应断言判断响应是否包含特定字符串比如登录成功后的欢迎语或状态码200。这一步的核心价值是在压测过程中自动判断请求是否失败如果漏掉断言你可能压了一晚上最后看报告才发现大量请求是报错的等于白测。这三件事做完录制出来的脚本才算真正达到了“可压测”状态。4. AI生成性能测试脚本能落地还是噱头4.1 当前AI在这一领域能干什么“AI生成性能测试脚本”是最近搜索热度很高的词我专门去研究了一些开源项目和商业化方案。坦率讲目前的AI能力在生成测试脚本这个领域还没有到“描述一下业务就能自动生成完整JMeter脚本”的程度但在几个细分方向上已经有一些能提高效率的工具。第一个方向基于Har文件自动转JMX。Har是HTTP归档文件的缩写几乎所有抓包工具都能导出Har。现在有一些开源工具能够把Har直接转换成JMeter的JMX格式比如个人开发者维护的har2jmeter这类项目。实测下来对于请求参数简单、无动态依赖的接口转换准确率挺高但遇到路径参数带签名、请求头里带时间戳、短token这类动态内容时转换出来的脚本还需要人工补关联和参数化处理。第二个方向利用大模型生成JMeter脚本的代码片段。现在用ChatGPT、Claude这类工具你直接说“帮我写一个JMeter JSR223脚本实现从上一个响应提取token并设置到变量”它确实能生成可用的Groovy代码。对于不熟悉JMeter脚本语法的人来说这能省不少查文档的时间但距离“一键生成完整测试剧本”还很远。第三个方向基于OpenAPI规范生成脚本。如果你的系统有完整的Swagger/OpenAPI文档有些工具可以直接从API定义里生成JMeter脚本结构。这种方式生成的脚本好处是结构清晰、参数定义规范但缺点也明显——它只面向API无法还原UI层面真实的用户操作链路也无法覆盖除了API调用之外的前端交互行为。4.2 实际使用时的红线和判断我的建议是AI生成脚本可以当作辅助手段但别把它当成“免录制”的捷径。至少在当前阶段以下三个问题AI还解决不了动态参数识别。AI能根据接口文档猜测参数含义但它无法确定哪些参数是服务端返回的、哪些是本地算法生成的这些必须结合真实流量或代码来分析。而性能测试脚本最核心的就是动态参数的关联处理这一块目前还离不开人。业务场景还原。用户真实的操作未必是线性的API调用可能穿插着各种异常路径、超时重试、断网恢复。这些场景靠AI从文档里是“脑补”不出来的而是要从真实用户行为中采样和建模。脚本稳定性保障。生成的脚本在单机跑一遍能通不代表并发1000时还能通。性能测试里大量问题恰恰是高并发下才暴露的比如token竞争、连接池耗尽、断言误报等。这些必须靠实际压测和调优才能发现。所以我对“AI生成性能测试脚本”的判断是可以用它减少重复劳动但核心的脚本设计能力还是得靠自己踏踏实实练。5. 常见问题与排查技巧实录5.1 高频问题速查表现象可能原因解决思路浏览器访问网页时连接失败或超时代理端口未监听、JMeter代理未启动检查JMeter代理是否已启动确认代理端口与浏览器设置一致录不到HTTPS请求或请求体是乱码证书未安装或未信任重新导入JMeter根证书确认浏览器信任设置手机App无法联网手机代理设置错误、不在同一局域网检查IP、端口确认电脑防火墙放行录到大量静态资源请求未配置排除模式按本文第3.1节的排除正则配置“排除模式”录制到的中文请求数据显示乱码页面编码为UTF-8而录制时未按UTF-8解析在HTTP Sampler的Content encoding中设置utf-8或修改JMeter配置文件默认编码压测时请求报错但单次执行正常缺少关联、token重复使用导致冲突检查动态参数添加提取器做关联生成的脚本跑完后结果树的响应为空可能被服务端拦截或证书问题残留检查代理是否彻底关闭重新发起请求确认实际网络环境上面这张表覆盖了我这几年来录制脚本时遇到的大部分“现场事故”很多问题的根因就是代理和证书但排查时却往往绕了好大一圈。5.2 录制中的“时间刺客”思考时间要怎么加这里的思考时间指用户操作间隔。录制时工具会忠实记录每个请求的时间戳但默认情况下JMeter的Sampler之间不会自动插入思考时间这会导致压测时请求“无脑”地以最快速度发出压力远大于真实用户场景。正确做法是录制时打开HTTP代理服务器配置里的“记录HTTP消息头”同时在JMeter线程组里用“固定定时器”或“泊松随机定时器”模拟用户思考时长。固定定时器的延时是固定值适合粗粒度控制泊松随机定时器能产生更符合真实的随机间隔但配置稍复杂。如果你一开始不熟悉先加固定定时器延时设1000~3000毫秒跑一轮看看效果再调整。思考时间加得太多会稀释压力加得太少会失真。最靠谱的做法是从业务的埋点数据里取用户操作间隔的P50、P90值再把它作为定时器的参数依据。5.3 面试向被问到“脚本怎么录制”时怎么答最近“性能测试面试题”“性能测试岗位常见面试题”这些热词一直在线我顺带聊聊面试环节跟录制相关的考察点。面试官问“做性能测试时脚本是怎么来的”其实考察的不是你说“用JMeter录制”而是你有没有想清楚不同场景下脚本来源的差异性。回答时我会建议按“流量来源 工具链 处理策略”来组织业务是Web端优先用JMeter代理录制然后做三件事过滤静态资源、识别动态参数、做关联和参数化业务是App端优先用手机代理抓包过程中要注意证书配置和防抓包处理必要时配合后端日志提取请求模板业务是纯API服务直接通过Swagger文档或已有Har文件生成脚本效率更高如果被测系统已有线上日志平台从网关或SLS里抽样真实流量反而比录制更能代表真实用户场景。面试考的不只是工具更是对性能和业务的理解。录制本质上是想办法还原真实负载理解这一点面试时就能比“背步骤”的人高出一截。6. 个人经验总结在我自己带团队做过的性能测试项目里脚本录制环节花费的时间往往占整个项目周期的两到三成。很多刚入行的同事不理解总觉得录制就是“开代理、点开始、点结束”三连为什么这么慢实际上真正慢的不是录制本身而是录制后的“清洗与增强”——有多少请求需要过滤、多少参数需要提取、多少场景需要覆盖这些都直接决定了压测结果的置信度。我一直有个习惯录制前会先用三分之一的时间做“预演”把核心业务链路完整走一遍确认代理设置、证书、过滤规则都正常然后再开始正式录制。这样做的好处是正式录制的过程中不会被环境问题打断录制结果干净完整。否则等你录了十分钟才发现证书没生效所有请求全是乱码又得从头再来。最后分享一个使用细节JMeter录制完的JMX文件看起来就是个XML如果你对XML结构有一定了解完全可以直接在文本编辑器中搜索关键字快速修改一些批量参数。比如你想把某个请求的域名从test.example.com统一改成pre.example.com用JMeter的GUI一个个改太费劲直接用文本编辑器全局替换反而更快。这个技巧说起来有点土但在处理大脚本时确实能省不少时间算是我个人比较偏爱的一条“野路子”。脚本录制这件事说到底没有什么玄学就是把“用户操作”翻译成“机器能执行的语言”翻译得越准确后面的压测越有意义。希望这篇内容能帮你少走一些弯路。