刚接触性能测试的人十有八九都会遇到同一个问题Web端压测脚本到底怎么来手写HTTP请求吧业务接口一多、参数一复杂还没写完人先崩溃了。后来我发现最实用的入门路径其实是先学会JMeter录制通过本地代理把你浏览器里的真实操作变成一条条可回放的压测脚本。今天这篇就围绕JMeter录制Web端压测脚本的完整操作步骤来讲从原理到实操再从HTTPS证书坑到脚本清洗基本把我这几年在性能测试上踩过的坑都翻出来说一遍。这篇文章特别适合刚入门JMeter、或者已经在用JMeter但平时主要靠手写脚本的人。录制不是万能的但它在快速构造业务流程、复现线上操作路径、做冒烟压测这些场景下效率确实非常高。看完你至少能独立走完一整套录制、清洗、增强、执行压测的流程遇到问题也知道去哪找原因。1. 先搞懂录制原理为什么JMeter能录下你的操作1.1 代理服务器模式录制就是当中间人JMeter录制Web端脚本靠的是一个内置的HTTP代理服务器组件。你在浏览器里设置好代理后所有HTTP请求都会先经过JMeter这条管道再转发到真实服务器。JMeter在这个过程中解析请求内容自动生成对应的HTTP请求采样器保存到指定的录制控制器里。这个过程可以理解成你站在一条高速公路边上每路过一辆车就拍一张照记录车牌、颜色、载重最后把所有照片整理成册。浏览器里发生的每一次点击、每一个表单提交本质都是一次HTTP请求JMeter把这些请求按顺序记录下来回放时就能模拟你的完整操作流程。这里有几个关键点需要留意代理服务器只在录制阶段启用压测阶段不依赖它JMeter直接向目标服务器发请求。录制的请求顺序就是你的操作顺序这对业务流程类压测很重要比如先登录再查询再下单顺序错乱会导致脚本直接失败。录制过程中浏览器和JMeter代理服务器必须在同一网络环境如果JMeter跑在远程服务器上浏览器所在机器要能访问到该服务器的代理端口。我之前遇到不少新人问为什么我录了半天里面什么都没有十有八九是代理没生效浏览器请求压根没走JMeter这条管道。后面我会专门讲浏览器代理配置的细节。1.2 逃避不掉的两个细节端口和证书JMeter的HTTP代理服务器组件默认监听8888端口这个端口既要配置在浏览器代理里也要保证没被其他程序占用。我建议在正式录制前先检查一下端口占用Windows下可以用netstat -ano | findstr 8888看是不是已经有进程在监听。另一个让很多人头疼的问题是HTTPS。Web端系统现在基本都是HTTPS协议JMeter要录制HTTPS请求就必须在浏览器端安装JMeter生成的根证书否则浏览器会拦截代理流量提示证书不受信任录制直接失败。关于证书的原理和导入方法我会在第4节详细展开。这里先记住一个结论HTTP协议可以直接录HTTPS必须先把JMeter根证书装进浏览器的受信任的根证书颁发机构存储区。1.3 录制和手写脚本怎么选录制不是万能的它最大的优势是快尤其是当你面对一个完全陌生的系统时手工分析接口参数可能要半天录制五分钟就能跑起来一条完整业务流程。但录制脚本也有明显的短板脚本里会混入大量静态资源请求、冗余Cookie、无关的AJAX轮询请求直接拿去压测请求数量虚高结果失真。另外录制下来的脚本参数都是硬编码的多用户并发时无法模拟不同账号、不同数据的场景。我的经验是业务接口数量多、前端加密参数复杂、需要快速复现真实操作路径时优先用录制来打底接口很简单、只有两三个核心交易接口时手写脚本反而更干净。但不管用哪种方式录制出来的脚本必须要经过清洗和增强就像原材料一定要加工后才能上桌一样。2. 环境准备装对JDK和JMeter比什么都重要2.1 版本怎么选JDK与JMeter版本关系JMeter是Java应用需要JDK环境。我个人推荐直接装JDK11或JDK17JMeter 5.x系列对这两个版本支持都很好尽量避免用太老的JDK7或JDK8因为新版JMeter的一些组件和插件在老JDK上会报不兼容问题。下载JMeter时认准Apache官方下载页面选择binaries压缩包Windows下就是zipLinux下是tgz。解压后先配置JAVA_HOME环境变量指向JDK安装目录然后在命令行执行java -version jmeter -v两个命令都能正常输出版本信息说明环境没问题。如果java -version能识别但jmeter -v不行一般就是PATH里没有包含JMeter的bin目录去环境变量里补上即可。JMeter的目录结构也值得看一眼。bin目录是启动入口和核心配置文件所在lib/ext是插件和扩展jar包的位置lib目录存放运行依赖。以后你装第三方插件基本就是往lib/ext里放jar包或者通过插件管理器自动安装。2.2 首次启动和界面语言Windows下进入bin目录双击jmeter.bat启动我建议第一次启动时用中文界面选择菜单栏的Options - Choose Language - ChineseJMeter会记住这个设置。某些老版本需要手动改配置文件打开bin/jmeter.properties找到language这个参数去掉注释并改成zh_CN。启动后默认带一个测试计划保存为.jmx文件这是JMeter脚本的标准格式压测时命令行执行的就是这个文件。我建议从一开始就给脚本文件建好规范的命名比如order_pressure_2025_v1.jmx否则后面脚本版本多了根本分不清哪个是哪个。另外强调一句JMeter的GUI模式是用来写脚本和调试脚本的不是用来压测的。真正的压测执行建议全部用命令行模式这一点在第6节会详细说明。2.3 需要的插件哪些对录制和压测有用录制本身不需要任何额外插件JMeter自带的HTTP代理服务器组件就够用。但我建议安装JMeter Plugins Manager插件管理器后面做性能监控、图形化指标扩展时会用到。安装方式很简单从官方插件管理器的Github仓库下载plugins-manager.jar放到lib/ext目录重启JMeter后菜单栏会出现Plugins Manager选项在里面搜索你需要的插件一键安装。注意安装完插件同样需要重启JMeter才能生效。需要提醒的是插件不是越多越好。压测时很多插件会额外消耗资源尤其是一些图形化插件在集群压测和高并发下反而拖累性能。录制阶段装个插件管理器就够了其他组件等真正需要时再装。3. 录制Web端压测脚本的完整操作步骤3.1 第一步搭好录制骨架打开JMeter后先按照下面这个顺序把录制骨架搭起来在测试计划下添加一个线程组线程数先填1用来录制和调试跑压测时再改成实际并发数。在线程组下添加逻辑控制器里的录制控制器。这个控制器专门用来存放录制生成的采样器建议把它重命名为录制脚本方便识别。在测试计划下添加非测试元件里的HTTP代理服务器。HTTP代理服务器的配置有几个关键项要设置端口默认8888保持不变即可。目标控制器下拉框选择测试计划线程组录制控制器这样录出来的脚本会自动挂到指定的录制控制器下而不是散落各处。分组我习惯选择每个分组放入一个新的控制器这样JMeter会尝试按页面或事务对请求分组录制后脚本结构更清晰。录制模式选择HTTP客户端4或HTTP客户端3都行一般按默认即可。勾选捕捉HTTP头信息这样能录到请求头里的重要内容比如Content-Type、Cookie。添加断言建议不要勾选断言我们后面根据需要手工加录制时自动加的断言往往不是我们想要的。配置完基本就是这个样子。这里还有个小技巧录制前把目标服务器地址在HTTPS Domains里填上比如被测系统是www.example.com填到HTTPS Domains那一栏可以避免把其它域名的请求也录进脚本。3.2 第二步配置浏览器代理这步是很多人卡住的地方。JMeter代理服务器启动后浏览器必须把流量指向它否则你就算在页面上点半天录制控制器里依然空空如也。以Chrome为例最简单的方式是使用系统代理打开Chrome设置搜索代理点击打开代理设置。在Windows的Internet属性里打开局域网设置。勾选为LAN使用代理服务器地址填127.0.0.1端口填8888。这里特别提醒需要取消本地地址不使用代理这个选项因为我们要录制的目标地址可能是内网IP一旦勾选了浏览器访问内网系统时就会绕过代理导致录不到数据。如果觉得每次改系统代理太麻烦可以安装Chrome的SwitchyOmega扩展在里面新建一个代理情景模式协议选HTTP服务器填127.0.0.1端口填8888需要录制时一键切换不用录制时切回直连模式比手动改系统代理高效很多。Firefox和Edge的配置逻辑完全一样都是设置代理服务器地址和端口。录制过程中我建议打开浏览器的无痕模式并且把浏览器上所有插件都停用特别是广告拦截类插件它们会产生额外的代理流量请求把脚本污染得乱七八糟。3.3 第三步设置过滤规则别把静态资源录进来这一步非常关键。一个现代Web页面打开时会加载几十个静态资源文件JS、CSS、图片、字体、图标哪个都不是你压测关心的业务接口。如果不做过滤这些请求会全部录进脚本压测时不仅造成请求量虚高还会干扰服务器性能数据的真实性。在HTTP代理服务器的排除配置里我通常加上这样一条正则表达式.*\.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot|map)(\?.*)?$这条正则的含义是任何以这些静态资源后缀结尾的URL不管后面带不带查询参数都直接排除掉不录进脚本。实际使用中根据被测系统的资源类型可以灵活增删后缀。除了静态资源还有很多前端埋点、监控上报的请求也应该排除这些请求往往带有collect、analytics、track、log之类的关键字。可以在排除规则里再加一条正则.*(collect|analytics|track|report|monitor).*过滤规则是录制脚本质量的第一道防线宁可规则稍微严格一点也别让垃圾请求混进来。当然也别过滤得太狠核心业务接口肯定不能过滤掉这个度需要你对自己的被测系统有基本了解。3.4 第四步启动代理、操作业务、停止录制配置全部就绪后点击HTTP代理服务器上的启动按钮。如果是第一次录制HTTPS网站JMeter会弹出一个根证书向导提示需要安装证书到浏览器这里按提示操作证书问题第4节会单独讲。启动成功后打开浏览器并切换到代理模式在地址栏输入被测系统网址然后按你的测试场景设计一步一步操作页面。比如要压测用户登录后查询订单这个流程就先登录、再进入订单页面、查询、退出每个步骤都停顿一两秒尽量模拟真实用户的操作节奏。操作完成后回JMeter点击HTTP代理服务器的停止按钮。这时你会看到录制控制器下面出现了一串HTTP请求采样器排列顺序基本对应你的操作时序。先别急着高兴到这里只完成了30%的工作接下来的脚本清洗和增强才是大头。4. HTTPS录制与证书最容易翻车的一环4.1 为什么会遇到证书报错中间人解密原理HTTP协议是明文传输代理直接转发就行。但HTTPS在传输前会做TLS加密浏览器和服务器之间要完成握手和证书校验。代理服务器想看到请求内容就必须让浏览器信任它这个中间人所以JMeter会生成一个根证书你需要把这个证书安装到浏览器的受信任区。装上证书后JMeter就能解密HTTPS流量把请求内容解析成采样器。如果证书没装对浏览器会报ERR_CERT_AUTHORITY_INVALID之类的错误严格的时候连页面都打开不了或者点几次就被拦下来。很多新手在这里反复踩坑第一个坑是把证书装到了个人证书区而不是受信任的根证书颁发机构第二个坑是证书装好后没有彻底关闭浏览器再重启浏览器进程还在内存中缓存旧状态导致证书校验还是失败。4.2 证书导入实操步骤JMeter的根证书文件在bin目录下文件名是ApacheJMeterTemporaryRootCA.crt注意这个文件名里带Temporary因为它是有有效期的临时根证书。导入步骤以Windows Chrome为例双击ApacheJMeterTemporaryRootCA.crt弹出证书信息窗口。点击安装证书存储位置选本地计算机。选择将所有证书都放入下列存储点击浏览。选择受信任的根证书颁发机构确认并完成导入。完全关闭浏览器重新打开再访问HTTPS站点。导入成功后不需要对证书有任何恐慌或误解这只是测试工具用于解密流量生成脚本的正常机制。如果录制完成想彻底移除证书可以在Windows运行里输入certmgr.msc打开证书管理器找到受信任的根证书颁发机构搜到JMeter对应的证书右键删除即可。4.3 录制HTTPS时常见报错与处理我整理了一下录制HTTPS时最常遇到的几个现象按照排查优先级大致是这样浏览器打开页面提示证书不受信任或您的连接不是私密连接说明JMeter根证书没有被浏览器正确信任重新导入一遍确认放在受信任的根证书颁发机构。录制一开始有数据中途突然断掉大概率是证书有效期问题或者浏览器缓存异常重新启动代理服务器试一次。代理启动后所有HTTPS站点都打不开先停掉代理恢复浏览器直连然后把浏览器缓存清一下再重试。如果确定是证书问题重新生成证书再导入。公司统一安装安全软件拦截了本地代理这种情况只能和网管或安全团队协商或者改用内网专用的压测环境去录制。这里补充一个很实用的小经验如果换了一个新的被测系统尤其是跨越时间比较久之后旧的JMeter证书可能已经失效重新启动代理服务器时会自动生成新的证书这时需要在浏览器里把旧证书删掉重新导入新证书不然会一直报错。5. 录制完不等于能用脚本清洗与增强5.1 第一步清洗删掉静态资源和无效请求打开录制控制器逐个检查采样器。即使过滤规则已经挡掉了大部分静态资源依然会有漏网之鱼比如接口返回的JSON里有Base64图片、动态生成的验证码图片、某些根据URL参数动态加载的资源。清洗的标准很简单只看业务相关的核心请求。比如登录接口、查询接口、下单接口、支付接口这些才是压测关注的对象。其它回答不了这个请求属于哪一步业务的都可以禁用或删除。删除请求时要注意有些请求虽然单独看不重要但它在业务流程中承担了关键作用。比如登录后获取用户信息、获取Token的请求把它们删掉会导致后续请求直接失败。我的做法是先在查看结果树里运行一遍录制好的脚本根据报错情况判断哪些请求是业务链路中的必需环节而不是盲目删除。5.2 第二步增强加断言和参数化干净的脚本要能验证请求是否成功。最直观的方式是加响应断言比如判断登录接口的响应中是否包含success或欢迎xxx这类关键字。但有些系统的返回结构很复杂响应断言的关键字可能没法精确匹配这时可以上BeanShell断言。在采样器下添加BeanShell断言写入类似下面的代码String resp prev.getResponseDataAsString(); if (resp.contains(success)) { Failure false; } else { Failure true; FailureMessage 响应中未找到success关键字请求可能失败; }这段脚本的逻辑是取上一个采样器的响应内容如果包含success就判定通过否则标记失败并给出失败原因。当然实际业务里判断的关键字要根据系统返回内容来定比如错误码是code: 0还是status: 200见过响应格式之后改一下关键字就行。参数化则是为多用户压测准备。最简单的做法是使用CSV Data Set Config组件准备一个包含用户名密码的CSV文件配置好变量名然后在请求参数里引用${username}、${password}这样每个虚拟用户都能取到不同的账号。5.3 第三步思考时间、循环和多用户模拟录制脚本里每个请求之间几乎是没有间隔的这不符合真实用户行为全速请求会让服务器压力失真。压测时通常有两个方向如果是模拟极限压力思考时间可以直接去掉或者设置极短的值如果是模拟真实业务场景需要加常数吞吐量定时器或高斯随机定时器让请求间隔更接近真实分布。线程组参数这里再说一下压测时把线程数改成你计划的并发数比如100个用户循环次数填-1并勾选调度器设置持续时间比如压5分钟。使用Ramp-Up Period控制用户启动的速度我一般建议线程总数除以每秒启动数控制在30到60秒内把所有用户都启动起来这样能避免瞬间冲击造成的假错误。多用户模拟还有个关键点就是必须做参数化否则所有用户都用同一个账号要么被系统踢下线要么被测系统账号体系直接报错。5.4 关联处理动态Token的入门写法很多Web系统在登录后会返回Token、SessionId等动态参数这些参数在后续请求中要作为请求头或请求体的一部分携带。录制脚本里这些值已经写死了一旦换个用户、换次登录就会失效。解决方式是加关联动态提取。最常用的是正则表达式提取器放在登录请求下面提取响应中的Token值然后在后续请求中用${token}引用。举一个简单例子如果登录响应里是一段JSON{ data: { token: abcdef123456 } }在正则表达式提取器里配置引用名称token正则表达式token\s*:\s*([^])模板$1$匹配数字1提取完之后给后续请求加上HTTP头管理器传入token: ${token}。这样脚本就具备跨会话的能力了用户A登录取的Token不会带到用户B的请求里因为每个线程组的每个线程都有自己独立的变量副本。6. 从录制脚本到压测报告跑起来看数据6.1 用GUI跑还是命令行跑命令行更稳脚本清洗增强完毕后就可以正式压测了。这里有个很多人容易忽略的重要事项不要在GUI界面上直接跑高并发压测。GUI模式本身会消耗大量内存和CPU来绘制图表、更新界面JMeter进程的负载会干扰压测结果。正确做法是保存脚本后用命令行执行jmeter -n -t web_pressure_test.jmx -l result.jtl -e -o /path/to/report参数含义如下-n非GUI模式运行。-t指定测试计划文件。-l保存采样结果的JTL文件路径。-e压测结束后生成HTML报告。-oHTML报告的输出目录注意这个目录必须不存在或为空否则会报错。跑完之后进入输出目录打开index.html就能看到完整的测试报告。带-e参数最大的好处是不需要人工整理监听器报告页面已经把所有核心指标可视化好了。6.2 常用监听器与报告指标解读录制和调试阶段我用得最多的是查看结果树和聚合报告。查看结果树用来逐条确认请求响应是否正确聚合报告用来快速确认错误率和响应时间。聚合报告里重点看这几个字段样本数总请求数可以用来判断吞吐量是否稳定。平均响应时间所有请求的平均耗时。90%百分位90%的请求都在这个时间内完成这个指标比平均值更皮实不容易被极端值带偏。错误率错误请求占总请求数的比例压测时错误率应该趋近于0。HTML报告里还可以看APDEX应用性能指数、TPS曲线和响应时间分布。判断系统能否支撑预期压力一般看两个硬指标TPS是否达到目标值错误率是否在可接受范围。响应时间是否超时要结合业务需求来定不是说越短越好。6.3 压测过程中的实时观察命令行压测过程中看不到实时效果这时候有两个办法。第一个是在脚本里添加后端监听器配合InfluxDB和Grafana搭建实时监控看板适合正式压测第二种是临时在负载机上直接看JTL文件的变化tail -f result.jtl每新增一行就代表一个采样结果可以看到响应时间、状态码等信息。虽然不是结构化展示但快速判断接口是否大面积失败还是够用的。如果你发现压测刚开始错误率就很高不要先看监控平台先去JTL文件里看具体的HTTP状态码和错误摘要。状态码503说明服务器过载500说明业务异常连接超时则需要检查网络和负载机压力。定位问题方向远比盯着某一个指标发呆有效。7. 常见问题与排查陷阱我踩过的坑7.1 高频问题速查表我把实际工作中遇到的高频问题整理成了表格方便你直接对照排查。现象可能原因排查和处理方法代理启动后浏览器打不开网页代理配置错误或端口8888被占用检查代理地址和端口用netstat检查端口占用换个端口重配录制控制器里没有任何请求浏览器流量没走代理过滤规则把所有请求都过滤掉了打开代理模式再试暂时清空排除规则确认能录到再逐条加回HTTPS站点提示证书无效JMeter根证书未正确导入重新导入到受信任的根证书颁发机构重启浏览器录制成功后脚本里响应中文乱码采样器编码不对先检查查看结果树里的响应编码将HTTP请求的Content Encoding设为UTF-8修改bin/jmeter.properties里的sampleresult.default.encodingUTF-8命令行压测时报目录已存在-o参数指定的目录已存在换一个空目录或者在执行前删掉旧目录压测初期大量失败接口提示未登录脚本中的Token、Cookie等动态参数未做关联补充正则表达式提取器提取登录后返回的动态凭证这些问题的共同根源大多数都是配置细节没到位。录制脚本出问题优先检查代理配置和过滤规则压测时出问题优先检查参数化和关联。7.2 压测时报连不上目标服务压测过程中如果看到org.apache.http.conn.HttpHostConnectException: Connect to ...这类错误说明JMeter在向目标服务器发送请求时连接建立失败。排查顺序是这样先用ping确认网络能不能通再用telnet 目标IP 端口确认目标端口是否开放最后确认压测脚本里的服务器名称或IP是否填写正确。如果服务器本身没问题大概率是防火墙规则挡掉了负载机的IP或者是压测环境本身的网络策略限制并发连接数。还有个容易忽略的地方脚本里HTTP请求的协议配置是HTTP还是HTTPS要和目标服务实际协议一致HTTPS的443端口配成HTTP请求发出去立刻就是一堆错误。7.3 一点关于录制压测脚本的个人建议最后分享几条我实际做项目时的体会。录制脚本最大的价值是帮你快速搭出符合真实业务流程的压力模型。但它的上限取决于脚本清洗和增强这两步做得够不够细致。很多团队拿录制脚本直接上压测结果出来的数据要么虚高要么错误率诡异最后怀疑这怀疑那唯独没怀疑脚本本身。我的建议是清洗阶段宁慢勿快每条请求都确认它是干什么的增强阶段宁多勿少断言、参数化、关联一个都不能省。脚本第一次保存后先用1个线程、1次循环跑通全链路确认无报错、断言通过后再逐步增加并发。这个顺序能帮你过滤掉至少80%的脚本问题。再补充一个小技巧录制的脚本最好保存多个版本原始录制版、清洗版、参数化版每个阶段单独存一份。这样压测结果出现异常时可以对比不同版本的脚本快速定位是哪个环节引入了问题排查效率会高很多。