在性能测试圈里混过一阵子的人基本都清楚JMeter脚本录制是入门最快、也最容易踩坑的一条路。很多人一开始只写接口脚本遇上那种前端交互复杂、数据全靠JS动态拼出来的老系统直接手写脚本能把人写到怀疑人生。录制功能就是帮你把浏览器里的实际请求“原封不动”抓下来生成JMeter脚本再在这个基础上做精简、关联、参数化效率能翻好几倍。这篇内容就是围绕脚本录制这条主线从环境准备、操作步骤、HTTPS证书处理到脚本整理和问题排查一次性说清楚适合刚接触JMeter、正在为“录不到脚本”或者“录了一堆废请求”发愁的测试同学参考。1. 为什么优先选择录制方式生成脚本1.1 手工编写脚本和录制脚本的差别我在刚学JMeter那会儿也是习惯性打开“测试计划”就开始手动添加HTTP请求。简单接口确实没问题参数固定、逻辑清晰几分钟就能跑起来。但一旦遇到真实业务流——比如用户登录后查询列表、选择商品、加购物车、下单、支付这个过程涉及几十个请求每个请求里可能还有Token、订单号、时间戳之类的动态参数手工写脚本的第一反应是“我连这些参数哪儿来的都不知道”。这时候录制脚本的价值就体现出来了你只需要正常操作浏览器JMeter在后台把所有请求都记录下来包括请求地址、请求头、请求体、Cookie甚至连JS动态生成的参数都会被一并抓到后续再慢慢整理就行。这里有个常见的认知误区就是把“录制”当成最终交付物。实际上录制只是打底它帮你画好了地图但地图上的每条路线都需要你亲自走一遍、修剪一遍才能真正用于压测。手工脚本的优势是干净、可控、没有冗余请求劣势是效率低、对业务理解的依赖度高录制脚本的优势是完整、真实、上手快劣势是会产生大量静态资源请求和无关请求需要二次加工。两者不是二选一的关系在正式项目中我通常是“录制为主、手修为辅”先用录制快速生成主干再手动调整细节。1.2 录制脚本真正解决的业务痛点什么样的场景下录制是王道我根据自己的实际经验总结了三类。第一类是业务流程复杂且依赖前端JS动态拼参数的场景。很多企业级系统的登录接口除了用户名密码还会带上一个加密的signature这个signature由前端JS计算生成手工分析耗时很长通过录制直接拿到已生成好的完整请求省去了解密逆算的步骤。第二类是系统没有现成接口文档的情况这也是我遇到最多的状况——刚接手一个老项目接口文档早就不知道丢到哪儿去了录制脚本就是最快的接口信息收集方式录完还能顺手反推出接口结构一举两得。第三类是移动端H5页面浏览器就能访问但请求链路里嵌入了很多第三方统计、埋点、广告SDK的请求这些靠猜根本猜不全只有录制才能完整暴露出来。录制方案的核心思路就是让JMeter成为一个“中间人代理”浏览器发出去的每个请求都先经过JMeter再由JMeter转发给服务器。这样JMeter就拿到了请求和响应的全量数据再按需转成测试脚本。理解了这个原理后面所有的操作——设置代理、处理证书、过滤请求——就都能顺理成章地理解了。2. 录制前的环境准备与规划2.1 安装JMeter及版本选择“工欲善其事必先利其器”录制前第一步当然是把JMeter跑起来。JMeter是纯Java应用所以第一前提是安装JDK。如果你用的是JMeter 5.x系列JDK 8到JDK 17都能适配我用的是JDK 8或者JDK 11稳定性最佳。注意不要只装JRE因为后续写Beanshell脚本、扩展插件的时候需要javac编译器JRE会缺东西。JDK装好后配置环境变量JAVA_HOME指向JDK安装目录再把%JAVA_HOME%\bin加进Path。然后在终端执行java -version看到版本号输出就说明环境OK了。接下来下载JMeter二进制包直接解压到你想要的目录即可不用安装。解压后进入bin目录Windows环境双击jmeter.batLinux/Mac环境执行./jmeter就能看到JMeter的图形界面。启动后界面字体如果太小可以在bin/jmeter.properties里调整jmeter.hidpi.mode和jmeter.hidpi.scale.factor这个细节放在后面问题排查里细说。版本选择上我的建议是别追太新的版本。JMeter 5.4之后对JDK版本要求变高太老的插件和证书逻辑可能会有兼容性问题。生产环境里我看到很多团队还在稳定跑5.1甚至4.0其实完全够用。关键是跟你本地的JDK匹配官方文档里有明确的兼容矩阵选错了版本启动时就会报UnsupportedClassVersionError。2.2 录制环境规划的几个关键细节安装只是开始录制环境的规划才是决定成败的关键。我踩过最疼的坑就是在装有各种代理插件的浏览器上直接录制结果录出来的脚本里混了一堆插件请求排查起来极其浪费时间。所以强烈建议准备一个干净的浏览器实例或者单独开一个浏览器profile专门用来录制。如果你用的是Chrome最简单的做法是以独立用户目录启动在命令行执行chrome --user-data-dir/tmp/jmeter-profile这样启动的Chrome就是一个全新的干净环境既不会带上原有Cookie也不会加载影响流量的扩展插件。Firefox也类似可以在“管理配置”里单独新建一个profile。另外要把系统层面的代理设置检查一遍Windows的“Internet选项→连接→局域网设置”里如果配了其他代理要先关掉否则会影响JMeter代理的抓包。录制前还需要准备好业务测试账号、测试数据、清理过的浏览器缓存保证录制过程中不会因为历史Cookie干扰产生异常请求。我见过很多人录制时忘了登出旧账号录出来的脚本里带上了上一次登录的Cookie压测的时候一大堆鉴权失败排查了半小时才定位到是环境不干净的问题。还有个小技巧值得分享录制前先在JMeter中新建一个“察看结果树”监听器录制过程中可以实时看到请求进来确认代理是否生效。判断标准很简单——你操作浏览器的每一步结果树里都在不停增加请求条目说明链路是通的。如果操作了半天一条请求都没有后面会专门讲排错但提前看一眼结果树能帮你省很多时间。3. 端到端走通一次脚本录制3.1 创建测试计划与线程组打开JMeter后默认会生成一个空的测试计划。我习惯先改个有意义的名字比如“XX系统登录下单业务流程”避免录完了一堆脚本分不清谁是谁。在测试计划上右键添加“线程组”这时会弹出一组参数线程数模拟的并发用户数。录制阶段我建议填1因为录制只需一个虚拟用户走完业务流程就行等到压测阶段再根据需求调整为50、100、500等。Ramp-Up时间线程启动的持续时间。压测阶段通常让所有线程在较短时间内完成启动模拟高峰并发录制阶段保持默认1秒即可。循环次数录制阶段填1压测阶段决定跑几轮。顺便说一句录制阶段创建的线程组更像一个“容器”它并不真正执行压测只是为了承接录制进来的HTTP请求。所以录制前线程组参数不必太过纠结能跑通流程是第一优先级。3.2 配置HTTP代理服务器在线程组上继续右键添加“配置元件→HTTP代理服务器”。关键配置项有四个端口默认8080如果被占用可以改成8888或其他空闲端口。我习惯用8888因为8080经常被本地开发服务占用。目标控制器这里必须选择你刚才创建的线程组否则录制的请求不会进到你指定的位置会跑到默认的测试计划节点下。分组我一般选择“每个组放入一个新的控制器”这样录制时同一个业务流程的不同阶段会自动分组比如登录一组、查询一组、下单一组结构清晰整理起来方便。记录HTTP信息头勾选把浏览器发送的请求头也记录下来。这部分包含了Content-Type、Referer、User-Agent等关键信息后期跑压测时经常用得上。启动代理服务器的方式是点击HTTP代理服务器界面左下角的“启动”按钮。启动后JMeter会提示生成根证书这在后面HTTPS录制里非常关键。如果只录HTTP请求倒无所谓但要录HTTPS证书这关必须过。3.3 配置浏览器代理指向JMeter启动JMeter代理后还需要让浏览器的流量走这个代理。浏览器代理设置的本质就是告诉浏览器“你所有的HTTP/HTTPS请求都先发到127.0.0.1:8888”。这里有两种实现方式手动设置和用插件管理。手动设置Chrome代理的路径是“设置→高级→系统→打开您计算机的代理设置”然后把“使用代理服务器”打开地址填127.0.0.1端口填8888。这种方式简单直接但缺点是改系统代理会影响到所有浏览器和其他程序一会儿改一会儿改回来很麻烦。所以我更推荐用SwitchyOmega这类浏览器代理管理插件新建一个场景HTTP和HTTPS都指向127.0.0.1:8888需要录制时切换到这个场景录制完一键切回“直接连接”就行。Firefox的代理设置在“设置→网络设置→手动代理配置”里写法类似。注意HTTP代理和SSL代理都要填同一个地址端口否则HTTPS请求不会走JMeter代理。3.4 执行录制与停止录制配置完成后先在JMeter点“启动”代理再在浏览器里访问被测系统地址。这里有个非常容易犯的错很多人先打开浏览器后再启动JMeter代理导致浏览器一开始的请求压根没经过代理只有后续的请求才被录制到。正确的顺序一定是先启动JMeter代理再操作浏览器。接下来就按真实的用户路径操作输入用户名密码、登录、点开菜单、浏览列表、填写表单、提交、退出。操作过程中可以随时切回JMeter看“察看结果树”确认请求在实时产生。整个业务流程走完后回到JMeter点击HTTP代理服务器的“停止”按钮录制即告一段落。这时候你会看到线程组下面多了一堆HTTP请求这就是你刚才操作时产生的全部请求记录。对于刚上手的同学我强烈建议录制操作时动作慢一点、步骤少一点每一步之间停两三秒再点下一步。因为有些系统前端会同时发出多个异步请求操作太快容易漏掉关键请求或者造成请求顺序混乱后面整理脚本时要花更多时间去核对。这一步慢就是快。4. HTTPS脚本录制与证书处理4.1 为什么HTTPS录制时经常会“翻车”现在大部分线上系统都是HTTPS协议如果你按刚才的流程直接录大概率会在结果树里看到一堆红色报错最典型的就是SSLHandshakeException或者“证书不受信任”。很多新手在这里就卡住了以为JMeter代理有问题。其实原理说破了很简单HTTPS为了保证数据安全服务器会给浏览器发一张由CA机构签发的数字证书浏览器验证证书合法才会建立加密通道。而JMeter代理要抓取HTTPS明文请求就必须在中间做一次“SSL劫持”——JMeter会生成一张自己的根证书然后偷偷用这张证书跟浏览器建立信任关系。浏览器默认不认识JMeter这张“自制证书”所以会拒绝连接。解决方法就是把JMeter生成的根证书导入浏览器的受信任根证书列表里。这个过程在浏览器看来就是“你信任了一个新的发证机关”以后JMeter代理发出来的证书就会被浏览器放行。4.2 生成并导入JMeter根证书JMeter的根证书是在启动HTTP代理时自动生成的。步骤是在HTTP代理服务器界面点“启动”JMeter会在其安装目录的bin文件夹下生成一个名为ApacheJMeterTemporaryRootCA.crt的证书文件。如果你已经启动过代理但找不到这个文件有可能被系统安全软件拦截了检查一下bin目录的修改时间必要时手动切换到其他工作目录再启动一次。拿到证书后导入方式分平台略有差异。Windows平台最简单的做法是双击证书文件选择“安装证书”→选择“本地计算机”→选择“将所有的证书都放入下列存储”→浏览选择“受信任的根证书颁发机构”一路下一步即可。Chrome浏览器会自动读取Windows证书库所以导入系统证书后Chrome就认得它了。Firefox需要用独立的证书管理在浏览器“设置→隐私与安全→证书→查看证书→导入”中选择该证书勾选“信任由此证书颁发机构来标识网站”即可。这里特别提醒证书导入完成后要把JMeter代理启动一次让证书在系统中注册好然后再启动浏览器进行录制。如果顺序搞反了浏览器启动时还没拿到JMeter的证书信息第一次握手就会失败。导入证书前关掉浏览器导入成功后重新打开确保浏览器重新加载了信任列表。4.3 HTTP与HTTPS配双代理时的注意事项实际项目中经常遇到一个系统里既有HTTP接口也有HTTPS接口。录制时为了让两类请求都能被抓到在HTTP代理服务器配置界面要把“HTTPS Domains”留空“端口”依然用同一个。JMeter会自动监听并处理HTTP和HTTPS两种协议的代理请求不需要为每个协议各起一个代理。这一点好多教程都没讲清楚导致有些同学录HTTP用一个代理、录HTTPS又用一个代理来回切换很麻烦。还有一个常见问题是“页面访问正常但结果树里某几个请求报443”。443是HTTPS默认端口出现这种报错通常有几种可能一是这一步请求走的域名没在JMeter的HTTPS证书覆盖范围内——不过一般来说根证书导入成功就能覆盖所有域名极少遇到这种情况二是浏览器的证书缓存有问题清理一下浏览器缓存即可三是代理配置中SSL代理端口没填把SSL代理也填成8888基本能解决。在Firefox里有时还需要额外打开“安全例外”来临时绕过证书校验但我个人不太推荐这种“绕过去”的做法因为测试环境的TLS策略可能和真实用户不一样最后还是以合法导入证书为准。5. 录制后脚本整理与优化5.1 用过滤规则甩掉静态资源和无用请求录制完成后面对动辄几十甚至上百条的请求列表第一反应肯定是头大。但仔细看就会发现里面很大一部分是CSS、JS、图片、字体这类静态资源请求。比如style.css、jquery.min.js、logo.png、iconfont.woff2这些资源在压测时通常不是关注重点还会拖慢脚本执行速度、污染性能数据。所以整理脚本的第一步就是过滤。JMeter的HTTP代理服务器支持配置URL过滤规则在代理配置界面的“包含”和“排除”输入框里写正则表达式。排除模式支持正则比如想排除常见的静态资源可以这样写.*\.(css|js|png|jpg|jpeg|gif|ico|woff|woff2|svg|ttf)(\?.*)?$。这个表达式匹配以这些后缀结尾的URL不管后面带不带版本号参数都能命中。如果有些业务请求不需要也可以按域名或关键词追加排除比如.*\.sockjs.*之类。过滤规则的配置时机有两个录制前配好那么录制过程就不会产生这些静态资源请求录制后补配可以结合“HTTP代理服务器”重新录制一遍或者手动在结果树里挑选需要的请求复制到新线程组。第一种方式最干净但我更推荐录制时先不急着过滤完整录一遍然后在察看结果树里用过滤器查看——勾选“仅显示错误”或“按名称搜索”——先摸清请求全貌再决定哪些留下哪些剔除。这样你能对系统请求链路有个整体认知而不是盲目过滤。5.2 关联处理让动态参数自动“活”起来过滤完静态请求后脚本还没法直接跑。原因在于很多请求的参数是从上一个响应中动态获取的。最经典的场景是登录后的Token、SessionID、CSRF Token每次登录都会变化如果直接写死参数值第二次跑脚本必然失败。这时候就要做关联——从上一个请求的响应中提取动态值作为下一个请求的入参。JMeter实现关联的常用组件是“正则表达式提取器”和“JSON提取器”。加一个后置处理器到产生动态值的HTTP请求上配置提取规则。以正则表达式提取器为例假设登录响应返回{token:abc123xyz}你希望在下一个请求的Header里带上这个token可以这样配置引用名称token正则表达式token:([^])模板$1$匹配数字1配置完成后下一个请求的HTTP Header Manager里就可以写Authorization: ${token}JMeter会自动替换为真实提取到的值。这里有个关键点提取器的作用域必须正确。你把它加在登录请求下面它才能处理登录响应的内容如果加在线程组外层它不知道从哪个响应里取值。JSON提取器更直观响应是JSON格式时JSONPath表达式比正则可读性强得多。比如提取token字段就写$.token提取嵌套字段写$.data.user.id。我的习惯是优先用JSON提取器接口返回格式不稳定或者含HTML片段时再退回正则表达式。有个实用调试技巧在脚本里临时添加一个“调试取样器”Debug Sampler运行时它会把所有变量值和JMeter属性打印到察看结果树里你能直观看到提取出来的token到底是不是预期值。排查关联问题时这个部件特别好用调试完记得删掉。5.3 参数化数据准备关联解决的是动态值的来源问题参数化解决的是数据多样性的问题。性能测试为了模拟真实用户不能用同一组账号密码反复登录需要多个测试账号分布到不同线程。JMeter里最常用的参数化方式是CSV数据文件设置。在线程组下添加“配置元件→CSV数据文件设置”配置CSV文件路径、变量名称、分隔符。比如CSV里有一列用户名和一列密码配置变量名为username,password后面在请求参数里写${username}和${password}即可。这里要特别注意CSV文件的编码Windows下用记事本保存的CSV可能是GBK编码JMeter默认按UTF-8读取容易中文乱码建议用Notepad或VSCode另存为UTF-8无BOM格式踩过这个坑的人应该懂我在说什么。除了CSV用户自定义变量也是一种轻量参数化方式适用于常量配置比如服务器IP、端口、公共请求头等修改一处全局生效。实际项目里我通常联合使用全局配置用用户自定义变量多值测试数据用CSV。5.4 给关键请求加上断言脚本能跑了还不够还得能自己判断“跑得对不对”。没有断言的话即使服务器返回500错误JMeter也当作正常请求处理压测结果里错误率永远为零这显然是自欺欺人。所以整理脚本时要给关键请求加上断言。最常用的是“响应断言”它可以判断响应文本是否包含特定内容。比如登录成功响应里包含success: true那就对登录请求添加响应断言模式匹配写success: true条件是“包括”。如果响应中出现了这个字符串断言通过否则失败。JSON断言可以更精细地校验字段值适用于接口返回JSON结构的场景。添加断言后记得通过“查看结果树”的“断言结果”标签确认断言确实被触发而不是因为没匹配到内容所以“通过”。6. 常见问题与排查技巧实录6.1 录制时一条请求都录不到这个问题排第一因为它太常遇见了。排查思路按顺序来先看JMeter代理是否真的启动了——界面上会显示“代理已启动”再看浏览器代理是否指向了正确的地址和端口——在浏览器访问http://127.0.0.1:8888如果页面显示代理服务相关提示说明链路通了一半然后检查目标控制器是否选错了线程组最后考虑是不是受害者本机访问被测系统的IP没有走代理。常见情况是浏览器访问localhost或127.0.0.1时默认不经过代理服务器遇到这种情况要把被测地址的域名或IP加入“不使用代理”的排除列表的相反面——换句话说确保代理设置里没有把被测域名排除掉如果用了SwitchyOmega要注意它的“绕过代理”列表里是否有127.0.0.1。6.2 录制到的请求在结果树里大量报错先分辨报错类型。如果是SSL握手相关错误优先排查证书——重新导入证书、检查证书过期时间JMeter根证书有有效期限制过期后在bin目录重新生成并导入即可。如果是403或404这类业务状态码多半是请求本身被服务器拒绝要么是缺少Cookie、缺少Referer要么是动态参数没关联到位。先把察看结果树的“请求体”和“响应体”对比浏览器开发者工具里的网络请求一条条核对差异很快能定位到缺了什么。6.3 录制脚本里出现大量重定向请求很多系统登录后会302跳转到首页或者统一身份认证中心录制时会出现多个重定向链路。JMeter录制默认会记录重定向请求这在压测时可能导致请求次数翻倍。处理方式是在HTTP请求的“跟随重定向”选项上做选择如果接口本身需要跟随重定向保留如果不需要可以禁用或者改为“自动重定向”。这里需要结合业务语义判断不能一刀切。6.4 关联参数提取不到值关联提取不到值先想一个问题提取器加对位置了吗比如Token在登录响应里提取器必须在登录请求下面而不是随便挂在线程组里。然后确认响应内容是不是真的包含你写的正则或JSONPath——建议先查看结果树里的“响应数据”标签看清楚实际返回的JSON结构再调整提取表达式。正则表达式最容易因为转义符号写错而失败比如JSON里的双引号需要写成$符号要用\$转义。调试时别忘了启用“调试取样器”直接看变量值是否为空。6.5 压力测试跑不起来或吞吐量异常低如果脚本单线程能跑通但压测时吞吐量异常低甚至不响应先查线程组配置和资源占用。注意JMeter本身运行需要一定内存大并发时建议修改bin/jmeter.bat或jmeter启动脚本里的HEAP参数Windows下默认是-Xms1g -Xmx1g我一般改成-Xms4g -Xmx4g不然压测机器会成为瓶颈测出来的数据自然不准。另外注意压测机和被测机器要尽量分开部署不要让JMeter跟被压服务抢同一台服务器的CPU和内存。6.6 常见问题速查表问题现象可能原因解决方案一条请求都录不到代理未启动或浏览器代理未配置检查代理端口、目标控制器、浏览器代理设置HTTPS录制报SSL错误根证书未导入生成并导入ApacheJMeterTemporaryRootCA.crt录制到大量JS/CSS请求未配置过滤规则HTTP代理服务器配置排除正则第二个请求参数取不到值提取器作用域错误或表达式写错用调试取样器定位提取值中文乱码CSV编码不是UTF-8另存为UTF-8无BOM断言一直失败响应内容与断言模式不匹配查看响应数据确认断言内容压测吞吐量上不去JMeter堆内存不足修改HEAP参数并重启代理端口被占用8080被其他程序占用更换端口或杀掉占用进程写在最后的一点经验录了这么久的脚本我最大的体会是录制只是把“可能性”抓到手真正的功夫在整理环节。第一次录制成功时看着几十上百条请求记录会很兴奋但离一个能稳定压测的脚本还差着十万八千里。脚本录制的正确打开方式是把它当成“逆向工程”的起点——通过录制了解系统的请求链路、参数依赖和会话机制然后用过滤、关联、参数化、断言这套组合拳把脚本锤炼到能真实模拟用户压测的水平。这也是为什么我建议新手一定要找一个真实业务系统练一遍完整流程而不是只跟着教程空跑一个Demo。另外一个小建议录制时随时用察看结果树对照浏览器开发者工具里的网络面板两边请求一一对应你很快就会对“前端发什么、服务器回什么”这件事产生手感这个能力在后面的接口测试和性能分析里会反复用到。
在性能测试圈里混过一阵子的人基本都清楚JMeter脚本录制是入门最快、也最容易踩坑的一条路。很多人一开始只写接口脚本遇上那种前端交互复杂、数据全靠JS动态拼出来的老系统直接手写脚本能把人写到怀疑人生。录制功能就是帮你把浏览器里的实际请求“原封不动”抓下来生成JMeter脚本再在这个基础上做精简、关联、参数化效率能翻好几倍。这篇内容就是围绕脚本录制这条主线从环境准备、操作步骤、HTTPS证书处理到脚本整理和问题排查一次性说清楚适合刚接触JMeter、正在为“录不到脚本”或者“录了一堆废请求”发愁的测试同学参考。1. 为什么优先选择录制方式生成脚本1.1 手工编写脚本和录制脚本的差别我在刚学JMeter那会儿也是习惯性打开“测试计划”就开始手动添加HTTP请求。简单接口确实没问题参数固定、逻辑清晰几分钟就能跑起来。但一旦遇到真实业务流——比如用户登录后查询列表、选择商品、加购物车、下单、支付这个过程涉及几十个请求每个请求里可能还有Token、订单号、时间戳之类的动态参数手工写脚本的第一反应是“我连这些参数哪儿来的都不知道”。这时候录制脚本的价值就体现出来了你只需要正常操作浏览器JMeter在后台把所有请求都记录下来包括请求地址、请求头、请求体、Cookie甚至连JS动态生成的参数都会被一并抓到后续再慢慢整理就行。这里有个常见的认知误区就是把“录制”当成最终交付物。实际上录制只是打底它帮你画好了地图但地图上的每条路线都需要你亲自走一遍、修剪一遍才能真正用于压测。手工脚本的优势是干净、可控、没有冗余请求劣势是效率低、对业务理解的依赖度高录制脚本的优势是完整、真实、上手快劣势是会产生大量静态资源请求和无关请求需要二次加工。两者不是二选一的关系在正式项目中我通常是“录制为主、手修为辅”先用录制快速生成主干再手动调整细节。1.2 录制脚本真正解决的业务痛点什么样的场景下录制是王道我根据自己的实际经验总结了三类。第一类是业务流程复杂且依赖前端JS动态拼参数的场景。很多企业级系统的登录接口除了用户名密码还会带上一个加密的signature这个signature由前端JS计算生成手工分析耗时很长通过录制直接拿到已生成好的完整请求省去了解密逆算的步骤。第二类是系统没有现成接口文档的情况这也是我遇到最多的状况——刚接手一个老项目接口文档早就不知道丢到哪儿去了录制脚本就是最快的接口信息收集方式录完还能顺手反推出接口结构一举两得。第三类是移动端H5页面浏览器就能访问但请求链路里嵌入了很多第三方统计、埋点、广告SDK的请求这些靠猜根本猜不全只有录制才能完整暴露出来。录制方案的核心思路就是让JMeter成为一个“中间人代理”浏览器发出去的每个请求都先经过JMeter再由JMeter转发给服务器。这样JMeter就拿到了请求和响应的全量数据再按需转成测试脚本。理解了这个原理后面所有的操作——设置代理、处理证书、过滤请求——就都能顺理成章地理解了。2. 录制前的环境准备与规划2.1 安装JMeter及版本选择“工欲善其事必先利其器”录制前第一步当然是把JMeter跑起来。JMeter是纯Java应用所以第一前提是安装JDK。如果你用的是JMeter 5.x系列JDK 8到JDK 17都能适配我用的是JDK 8或者JDK 11稳定性最佳。注意不要只装JRE因为后续写Beanshell脚本、扩展插件的时候需要javac编译器JRE会缺东西。JDK装好后配置环境变量JAVA_HOME指向JDK安装目录再把%JAVA_HOME%\bin加进Path。然后在终端执行java -version看到版本号输出就说明环境OK了。接下来下载JMeter二进制包直接解压到你想要的目录即可不用安装。解压后进入bin目录Windows环境双击jmeter.batLinux/Mac环境执行./jmeter就能看到JMeter的图形界面。启动后界面字体如果太小可以在bin/jmeter.properties里调整jmeter.hidpi.mode和jmeter.hidpi.scale.factor这个细节放在后面问题排查里细说。版本选择上我的建议是别追太新的版本。JMeter 5.4之后对JDK版本要求变高太老的插件和证书逻辑可能会有兼容性问题。生产环境里我看到很多团队还在稳定跑5.1甚至4.0其实完全够用。关键是跟你本地的JDK匹配官方文档里有明确的兼容矩阵选错了版本启动时就会报UnsupportedClassVersionError。2.2 录制环境规划的几个关键细节安装只是开始录制环境的规划才是决定成败的关键。我踩过最疼的坑就是在装有各种代理插件的浏览器上直接录制结果录出来的脚本里混了一堆插件请求排查起来极其浪费时间。所以强烈建议准备一个干净的浏览器实例或者单独开一个浏览器profile专门用来录制。如果你用的是Chrome最简单的做法是以独立用户目录启动在命令行执行chrome --user-data-dir/tmp/jmeter-profile这样启动的Chrome就是一个全新的干净环境既不会带上原有Cookie也不会加载影响流量的扩展插件。Firefox也类似可以在“管理配置”里单独新建一个profile。另外要把系统层面的代理设置检查一遍Windows的“Internet选项→连接→局域网设置”里如果配了其他代理要先关掉否则会影响JMeter代理的抓包。录制前还需要准备好业务测试账号、测试数据、清理过的浏览器缓存保证录制过程中不会因为历史Cookie干扰产生异常请求。我见过很多人录制时忘了登出旧账号录出来的脚本里带上了上一次登录的Cookie压测的时候一大堆鉴权失败排查了半小时才定位到是环境不干净的问题。还有个小技巧值得分享录制前先在JMeter中新建一个“察看结果树”监听器录制过程中可以实时看到请求进来确认代理是否生效。判断标准很简单——你操作浏览器的每一步结果树里都在不停增加请求条目说明链路是通的。如果操作了半天一条请求都没有后面会专门讲排错但提前看一眼结果树能帮你省很多时间。3. 端到端走通一次脚本录制3.1 创建测试计划与线程组打开JMeter后默认会生成一个空的测试计划。我习惯先改个有意义的名字比如“XX系统登录下单业务流程”避免录完了一堆脚本分不清谁是谁。在测试计划上右键添加“线程组”这时会弹出一组参数线程数模拟的并发用户数。录制阶段我建议填1因为录制只需一个虚拟用户走完业务流程就行等到压测阶段再根据需求调整为50、100、500等。Ramp-Up时间线程启动的持续时间。压测阶段通常让所有线程在较短时间内完成启动模拟高峰并发录制阶段保持默认1秒即可。循环次数录制阶段填1压测阶段决定跑几轮。顺便说一句录制阶段创建的线程组更像一个“容器”它并不真正执行压测只是为了承接录制进来的HTTP请求。所以录制前线程组参数不必太过纠结能跑通流程是第一优先级。3.2 配置HTTP代理服务器在线程组上继续右键添加“配置元件→HTTP代理服务器”。关键配置项有四个端口默认8080如果被占用可以改成8888或其他空闲端口。我习惯用8888因为8080经常被本地开发服务占用。目标控制器这里必须选择你刚才创建的线程组否则录制的请求不会进到你指定的位置会跑到默认的测试计划节点下。分组我一般选择“每个组放入一个新的控制器”这样录制时同一个业务流程的不同阶段会自动分组比如登录一组、查询一组、下单一组结构清晰整理起来方便。记录HTTP信息头勾选把浏览器发送的请求头也记录下来。这部分包含了Content-Type、Referer、User-Agent等关键信息后期跑压测时经常用得上。启动代理服务器的方式是点击HTTP代理服务器界面左下角的“启动”按钮。启动后JMeter会提示生成根证书这在后面HTTPS录制里非常关键。如果只录HTTP请求倒无所谓但要录HTTPS证书这关必须过。3.3 配置浏览器代理指向JMeter启动JMeter代理后还需要让浏览器的流量走这个代理。浏览器代理设置的本质就是告诉浏览器“你所有的HTTP/HTTPS请求都先发到127.0.0.1:8888”。这里有两种实现方式手动设置和用插件管理。手动设置Chrome代理的路径是“设置→高级→系统→打开您计算机的代理设置”然后把“使用代理服务器”打开地址填127.0.0.1端口填8888。这种方式简单直接但缺点是改系统代理会影响到所有浏览器和其他程序一会儿改一会儿改回来很麻烦。所以我更推荐用SwitchyOmega这类浏览器代理管理插件新建一个场景HTTP和HTTPS都指向127.0.0.1:8888需要录制时切换到这个场景录制完一键切回“直接连接”就行。Firefox的代理设置在“设置→网络设置→手动代理配置”里写法类似。注意HTTP代理和SSL代理都要填同一个地址端口否则HTTPS请求不会走JMeter代理。3.4 执行录制与停止录制配置完成后先在JMeter点“启动”代理再在浏览器里访问被测系统地址。这里有个非常容易犯的错很多人先打开浏览器后再启动JMeter代理导致浏览器一开始的请求压根没经过代理只有后续的请求才被录制到。正确的顺序一定是先启动JMeter代理再操作浏览器。接下来就按真实的用户路径操作输入用户名密码、登录、点开菜单、浏览列表、填写表单、提交、退出。操作过程中可以随时切回JMeter看“察看结果树”确认请求在实时产生。整个业务流程走完后回到JMeter点击HTTP代理服务器的“停止”按钮录制即告一段落。这时候你会看到线程组下面多了一堆HTTP请求这就是你刚才操作时产生的全部请求记录。对于刚上手的同学我强烈建议录制操作时动作慢一点、步骤少一点每一步之间停两三秒再点下一步。因为有些系统前端会同时发出多个异步请求操作太快容易漏掉关键请求或者造成请求顺序混乱后面整理脚本时要花更多时间去核对。这一步慢就是快。4. HTTPS脚本录制与证书处理4.1 为什么HTTPS录制时经常会“翻车”现在大部分线上系统都是HTTPS协议如果你按刚才的流程直接录大概率会在结果树里看到一堆红色报错最典型的就是SSLHandshakeException或者“证书不受信任”。很多新手在这里就卡住了以为JMeter代理有问题。其实原理说破了很简单HTTPS为了保证数据安全服务器会给浏览器发一张由CA机构签发的数字证书浏览器验证证书合法才会建立加密通道。而JMeter代理要抓取HTTPS明文请求就必须在中间做一次“SSL劫持”——JMeter会生成一张自己的根证书然后偷偷用这张证书跟浏览器建立信任关系。浏览器默认不认识JMeter这张“自制证书”所以会拒绝连接。解决方法就是把JMeter生成的根证书导入浏览器的受信任根证书列表里。这个过程在浏览器看来就是“你信任了一个新的发证机关”以后JMeter代理发出来的证书就会被浏览器放行。4.2 生成并导入JMeter根证书JMeter的根证书是在启动HTTP代理时自动生成的。步骤是在HTTP代理服务器界面点“启动”JMeter会在其安装目录的bin文件夹下生成一个名为ApacheJMeterTemporaryRootCA.crt的证书文件。如果你已经启动过代理但找不到这个文件有可能被系统安全软件拦截了检查一下bin目录的修改时间必要时手动切换到其他工作目录再启动一次。拿到证书后导入方式分平台略有差异。Windows平台最简单的做法是双击证书文件选择“安装证书”→选择“本地计算机”→选择“将所有的证书都放入下列存储”→浏览选择“受信任的根证书颁发机构”一路下一步即可。Chrome浏览器会自动读取Windows证书库所以导入系统证书后Chrome就认得它了。Firefox需要用独立的证书管理在浏览器“设置→隐私与安全→证书→查看证书→导入”中选择该证书勾选“信任由此证书颁发机构来标识网站”即可。这里特别提醒证书导入完成后要把JMeter代理启动一次让证书在系统中注册好然后再启动浏览器进行录制。如果顺序搞反了浏览器启动时还没拿到JMeter的证书信息第一次握手就会失败。导入证书前关掉浏览器导入成功后重新打开确保浏览器重新加载了信任列表。4.3 HTTP与HTTPS配双代理时的注意事项实际项目中经常遇到一个系统里既有HTTP接口也有HTTPS接口。录制时为了让两类请求都能被抓到在HTTP代理服务器配置界面要把“HTTPS Domains”留空“端口”依然用同一个。JMeter会自动监听并处理HTTP和HTTPS两种协议的代理请求不需要为每个协议各起一个代理。这一点好多教程都没讲清楚导致有些同学录HTTP用一个代理、录HTTPS又用一个代理来回切换很麻烦。还有一个常见问题是“页面访问正常但结果树里某几个请求报443”。443是HTTPS默认端口出现这种报错通常有几种可能一是这一步请求走的域名没在JMeter的HTTPS证书覆盖范围内——不过一般来说根证书导入成功就能覆盖所有域名极少遇到这种情况二是浏览器的证书缓存有问题清理一下浏览器缓存即可三是代理配置中SSL代理端口没填把SSL代理也填成8888基本能解决。在Firefox里有时还需要额外打开“安全例外”来临时绕过证书校验但我个人不太推荐这种“绕过去”的做法因为测试环境的TLS策略可能和真实用户不一样最后还是以合法导入证书为准。5. 录制后脚本整理与优化5.1 用过滤规则甩掉静态资源和无用请求录制完成后面对动辄几十甚至上百条的请求列表第一反应肯定是头大。但仔细看就会发现里面很大一部分是CSS、JS、图片、字体这类静态资源请求。比如style.css、jquery.min.js、logo.png、iconfont.woff2这些资源在压测时通常不是关注重点还会拖慢脚本执行速度、污染性能数据。所以整理脚本的第一步就是过滤。JMeter的HTTP代理服务器支持配置URL过滤规则在代理配置界面的“包含”和“排除”输入框里写正则表达式。排除模式支持正则比如想排除常见的静态资源可以这样写.*\.(css|js|png|jpg|jpeg|gif|ico|woff|woff2|svg|ttf)(\?.*)?$。这个表达式匹配以这些后缀结尾的URL不管后面带不带版本号参数都能命中。如果有些业务请求不需要也可以按域名或关键词追加排除比如.*\.sockjs.*之类。过滤规则的配置时机有两个录制前配好那么录制过程就不会产生这些静态资源请求录制后补配可以结合“HTTP代理服务器”重新录制一遍或者手动在结果树里挑选需要的请求复制到新线程组。第一种方式最干净但我更推荐录制时先不急着过滤完整录一遍然后在察看结果树里用过滤器查看——勾选“仅显示错误”或“按名称搜索”——先摸清请求全貌再决定哪些留下哪些剔除。这样你能对系统请求链路有个整体认知而不是盲目过滤。5.2 关联处理让动态参数自动“活”起来过滤完静态请求后脚本还没法直接跑。原因在于很多请求的参数是从上一个响应中动态获取的。最经典的场景是登录后的Token、SessionID、CSRF Token每次登录都会变化如果直接写死参数值第二次跑脚本必然失败。这时候就要做关联——从上一个请求的响应中提取动态值作为下一个请求的入参。JMeter实现关联的常用组件是“正则表达式提取器”和“JSON提取器”。加一个后置处理器到产生动态值的HTTP请求上配置提取规则。以正则表达式提取器为例假设登录响应返回{token:abc123xyz}你希望在下一个请求的Header里带上这个token可以这样配置引用名称token正则表达式token:([^])模板$1$匹配数字1配置完成后下一个请求的HTTP Header Manager里就可以写Authorization: ${token}JMeter会自动替换为真实提取到的值。这里有个关键点提取器的作用域必须正确。你把它加在登录请求下面它才能处理登录响应的内容如果加在线程组外层它不知道从哪个响应里取值。JSON提取器更直观响应是JSON格式时JSONPath表达式比正则可读性强得多。比如提取token字段就写$.token提取嵌套字段写$.data.user.id。我的习惯是优先用JSON提取器接口返回格式不稳定或者含HTML片段时再退回正则表达式。有个实用调试技巧在脚本里临时添加一个“调试取样器”Debug Sampler运行时它会把所有变量值和JMeter属性打印到察看结果树里你能直观看到提取出来的token到底是不是预期值。排查关联问题时这个部件特别好用调试完记得删掉。5.3 参数化数据准备关联解决的是动态值的来源问题参数化解决的是数据多样性的问题。性能测试为了模拟真实用户不能用同一组账号密码反复登录需要多个测试账号分布到不同线程。JMeter里最常用的参数化方式是CSV数据文件设置。在线程组下添加“配置元件→CSV数据文件设置”配置CSV文件路径、变量名称、分隔符。比如CSV里有一列用户名和一列密码配置变量名为username,password后面在请求参数里写${username}和${password}即可。这里要特别注意CSV文件的编码Windows下用记事本保存的CSV可能是GBK编码JMeter默认按UTF-8读取容易中文乱码建议用Notepad或VSCode另存为UTF-8无BOM格式踩过这个坑的人应该懂我在说什么。除了CSV用户自定义变量也是一种轻量参数化方式适用于常量配置比如服务器IP、端口、公共请求头等修改一处全局生效。实际项目里我通常联合使用全局配置用用户自定义变量多值测试数据用CSV。5.4 给关键请求加上断言脚本能跑了还不够还得能自己判断“跑得对不对”。没有断言的话即使服务器返回500错误JMeter也当作正常请求处理压测结果里错误率永远为零这显然是自欺欺人。所以整理脚本时要给关键请求加上断言。最常用的是“响应断言”它可以判断响应文本是否包含特定内容。比如登录成功响应里包含success: true那就对登录请求添加响应断言模式匹配写success: true条件是“包括”。如果响应中出现了这个字符串断言通过否则失败。JSON断言可以更精细地校验字段值适用于接口返回JSON结构的场景。添加断言后记得通过“查看结果树”的“断言结果”标签确认断言确实被触发而不是因为没匹配到内容所以“通过”。6. 常见问题与排查技巧实录6.1 录制时一条请求都录不到这个问题排第一因为它太常遇见了。排查思路按顺序来先看JMeter代理是否真的启动了——界面上会显示“代理已启动”再看浏览器代理是否指向了正确的地址和端口——在浏览器访问http://127.0.0.1:8888如果页面显示代理服务相关提示说明链路通了一半然后检查目标控制器是否选错了线程组最后考虑是不是受害者本机访问被测系统的IP没有走代理。常见情况是浏览器访问localhost或127.0.0.1时默认不经过代理服务器遇到这种情况要把被测地址的域名或IP加入“不使用代理”的排除列表的相反面——换句话说确保代理设置里没有把被测域名排除掉如果用了SwitchyOmega要注意它的“绕过代理”列表里是否有127.0.0.1。6.2 录制到的请求在结果树里大量报错先分辨报错类型。如果是SSL握手相关错误优先排查证书——重新导入证书、检查证书过期时间JMeter根证书有有效期限制过期后在bin目录重新生成并导入即可。如果是403或404这类业务状态码多半是请求本身被服务器拒绝要么是缺少Cookie、缺少Referer要么是动态参数没关联到位。先把察看结果树的“请求体”和“响应体”对比浏览器开发者工具里的网络请求一条条核对差异很快能定位到缺了什么。6.3 录制脚本里出现大量重定向请求很多系统登录后会302跳转到首页或者统一身份认证中心录制时会出现多个重定向链路。JMeter录制默认会记录重定向请求这在压测时可能导致请求次数翻倍。处理方式是在HTTP请求的“跟随重定向”选项上做选择如果接口本身需要跟随重定向保留如果不需要可以禁用或者改为“自动重定向”。这里需要结合业务语义判断不能一刀切。6.4 关联参数提取不到值关联提取不到值先想一个问题提取器加对位置了吗比如Token在登录响应里提取器必须在登录请求下面而不是随便挂在线程组里。然后确认响应内容是不是真的包含你写的正则或JSONPath——建议先查看结果树里的“响应数据”标签看清楚实际返回的JSON结构再调整提取表达式。正则表达式最容易因为转义符号写错而失败比如JSON里的双引号需要写成$符号要用\$转义。调试时别忘了启用“调试取样器”直接看变量值是否为空。6.5 压力测试跑不起来或吞吐量异常低如果脚本单线程能跑通但压测时吞吐量异常低甚至不响应先查线程组配置和资源占用。注意JMeter本身运行需要一定内存大并发时建议修改bin/jmeter.bat或jmeter启动脚本里的HEAP参数Windows下默认是-Xms1g -Xmx1g我一般改成-Xms4g -Xmx4g不然压测机器会成为瓶颈测出来的数据自然不准。另外注意压测机和被测机器要尽量分开部署不要让JMeter跟被压服务抢同一台服务器的CPU和内存。6.6 常见问题速查表问题现象可能原因解决方案一条请求都录不到代理未启动或浏览器代理未配置检查代理端口、目标控制器、浏览器代理设置HTTPS录制报SSL错误根证书未导入生成并导入ApacheJMeterTemporaryRootCA.crt录制到大量JS/CSS请求未配置过滤规则HTTP代理服务器配置排除正则第二个请求参数取不到值提取器作用域错误或表达式写错用调试取样器定位提取值中文乱码CSV编码不是UTF-8另存为UTF-8无BOM断言一直失败响应内容与断言模式不匹配查看响应数据确认断言内容压测吞吐量上不去JMeter堆内存不足修改HEAP参数并重启代理端口被占用8080被其他程序占用更换端口或杀掉占用进程写在最后的一点经验录了这么久的脚本我最大的体会是录制只是把“可能性”抓到手真正的功夫在整理环节。第一次录制成功时看着几十上百条请求记录会很兴奋但离一个能稳定压测的脚本还差着十万八千里。脚本录制的正确打开方式是把它当成“逆向工程”的起点——通过录制了解系统的请求链路、参数依赖和会话机制然后用过滤、关联、参数化、断言这套组合拳把脚本锤炼到能真实模拟用户压测的水平。这也是为什么我建议新手一定要找一个真实业务系统练一遍完整流程而不是只跟着教程空跑一个Demo。另外一个小建议录制时随时用察看结果树对照浏览器开发者工具里的网络面板两边请求一一对应你很快就会对“前端发什么、服务器回什么”这件事产生手感这个能力在后面的接口测试和性能分析里会反复用到。
