1. 项目概述为什么录制脚本是性能测试的基石如果你刚开始接触性能测试或者从Postman、Apifox这类接口调试工具转向Jmeter第一个让你感到困惑的环节很可能就是“录制脚本”。为什么不能像写单元测试一样直接手写请求为什么需要这个看似多此一举的步骤这恰恰是性能测试与功能测试的核心区别所在。性能测试的核心目标是模拟真实用户的操作行为对系统施加压力。而“真实用户的操作行为”是一个复杂的、连续的、有状态的交互序列。想象一下一个电商用户的操作打开首页 - 搜索商品 - 浏览商品详情 - 加入购物车 - 登录 - 结算 - 支付。这每一个步骤背后都对应着浏览器向服务器发送的多个HTTP/HTTPS请求其中包含了大量的动态参数会话IDJSESSIONID、防重提交令牌CSRF Token、商品ID、用户身份信息等。这些参数环环相扣后一个请求往往依赖于前一个请求的响应结果。手动编写这样的脚本不仅工作量巨大而且极易出错任何一个动态参数获取错误都会导致后续所有请求失败测试也就失去了意义。因此录制脚本的本质是借助工具自动捕获用户在真实浏览器操作过程中产生的所有网络请求并将其转化为Jmeter可以识别和回放的测试脚本。这是一个“从真实到模拟”的桥梁确保了我们的压测脚本能最大程度地还原真实业务场景。对于新手掌握录制是入门Jmeter最快的方式对于老手高效的录制和脚本优化是提升测试效率的关键。接下来我将拆解两种最主流、最稳定的Jmeter脚本录制方案并分享从录制到生成可压测脚本的完整心路历程和避坑指南。2. 核心方案选型HTTP(S)测试脚本录制器 vs. 浏览器代理模式Jmeter提供了多种录制方式但经过多年实战我将其收敛为两大主力方案它们各有最佳适用场景选对了能事半功倍。2.1 方案一使用内置的“HTTP(S)测试脚本录制器”HTTP(S) Test Script Recorder这是Jmeter自带的录制功能其原理是让Jmeter本身作为一个**代理服务器Proxy Server**运行。你需要将浏览器或手机系统的网络代理设置为Jmeter代理的地址和端口。此后所有流经该代理的网络请求都会被Jmeter捕获并记录。它的核心优势在于“一站式”和“高可控性”环境集成无需额外安装插件或第三方工具开箱即用。过滤精准可以在录制控制器中设置“包含模式”和“排除模式”例如通过正则表达式.*\.(js|css|png|jpg|gif).*排除所有静态资源请求只录制关键的API接口让生成的脚本非常干净。便于调试录制时可以直接看到请求和响应的原始数据对于排查问题很有帮助。但它也有明显的短板配置稍繁琐需要手动配置浏览器代理且对于HTTPS网站必须在浏览器中安装Jmeter生成的根证书否则无法解密HTTPS流量会报证书错误。这个过程对新手可能是个挑战。对现代Web应用支持有局限对于大量使用WebSocket、gRPC等非HTTP协议或前端框架如React, Vue生成的复杂异步请求捕获可能不完整。2.2 方案二使用浏览器开发者工具导出为Jmeter脚本推荐给新手和现代Web应用这是目前我个人更推荐尤其是给团队新人的首选方案。其原理是利用现代浏览器Chrome/Firefox/Edge内置的“开发者工具DevTools”的网络抓包功能手动操作一遍业务流程后将捕获到的所有请求导出为通用的HARHTTP Archive文件再通过Jmeter的一个第三方插件将其转换为.jmx脚本。这个方案的优势是“直观”和“避坑”零代理配置你不需要改动任何系统或浏览器的网络设置直接用浏览器正常访问即可。HTTPS无忧浏览器本身已经处理了HTTPS的加解密你看到的就是明文请求完全绕开了证书安装的麻烦。所见即所得你能清晰地看到每个请求的发起顺序、请求头、请求体、响应状态对于理解业务流非常有帮助。你可以手动筛选只保留必要的请求再导出。兼容性更好能更好地捕获到Fetch/XHR请求以及一些非标头信息。它的不足在于需要额外步骤依赖插件需要安装HAR Converter插件。手动筛选导出的是所有网络活动包含大量图片、CSS、JS等需要你在导出前或转换后进行清理。如何选择如果你是初学者或者测试目标是基于浏览器的现代Web应用尤其是HTTPS站点毫不犹豫地选择方案二浏览器导出HAR。它能让你快速上手把精力集中在业务逻辑而非工具配置上。如果你需要录制手机App的流量或者希望录制过程更自动化如配合Selenium做自动化录制那么方案一HTTP代理录制器是唯一的选择因为你可以将手机Wi-Fi的代理设置为电脑的Jmeter代理。如果你需要频繁录制同一个站点的不同场景在第一次配置好方案一的证书后后续录制会非常流畅。在接下来的详解中我将以方案二浏览器导出HAR作为主要路径因为这是当前最高效、最少踩坑的入门方式同时也会穿插讲解方案一的关键配置点作为补充。3. 实操全流程从浏览器操作到可运行的Jmeter脚本让我们以一个经典的“用户登录后搜索商品”场景为例完成一次完整的脚本录制与生成。3.1 第一步环境准备与插件安装工欲善其事必先利其器。除了Jmeter本体我们还需要一个关键插件。安装Jmeter从Apache官网jmeter.apache.org下载最新稳定版如5.6.3。解压后运行bin目录下的jmeter.batWindows或jmeterMac/Linux即可启动。确保你的系统已安装对应版本的JDKJmeter 5.4需要JDK 8。安装“HAR Converter”插件启动Jmeter在菜单栏选择Options-Plugins Manager。在“Available Plugins”标签页中找到并勾选HAR Converter。点击右下角的“Apply Changes and Restart JMeter”等待Jmeter重启。这个插件是由JMeter-Plugins.org社区维护的它能将HAR文件完美地转换成包含HTTP请求、头信息、Cookie管理器的完整测试计划。3.2 第二步使用浏览器捕获网络请求HAR文件生成这是整个流程中最关键的业务操作环节你的操作路径决定了脚本的逻辑。打开浏览器开发者工具以Chrome为例访问你的目标网站例如一个演示电商站。按F12或CtrlShiftI打开开发者工具切换到“Network”网络标签页。开始录制确保网络面板顶部的**录制按钮是红色正在录制**状态。一个重要的习惯是点击一下“Clear”清除按钮清空之前无关的请求记录。执行业务流程像真实用户一样操作。例如在首页的搜索框输入“手机”点击搜索。在搜索结果页点击一个具体的商品。在商品详情页点击“加入购物车”。弹出登录框输入用户名/密码登录。查看购物车。关键技巧操作速度可以稍慢确保每个请求都能被完整捕获。同时观察网络面板中请求的列表你会看到很多?search手机、/api/login、/api/cart/add这样的请求这些就是你的目标API。停止并导出HAR操作完成后在网络面板的任意位置右键选择“Save all as HAR with content”。将其保存到本地例如user_search_login.har。务必选择“with content”这样才会包含请求和响应的具体内容如JSON数据转换时才不会丢失。3.3 第三步在Jmeter中导入并转换HAR文件现在我们将捕获到的“原材料”加工成Jmeter能理解的“菜谱”。新建测试计划在Jmeter中默认会新建一个“Test Plan”。建议首先将其重命名为一个有意义的名称如“电商用户购物流程”。导入HAR文件在测试计划上右键选择Add-Non-Test Elements-HAR Converter。注意它不在常规的线程组或采样器下面而是在“非测试元件”里。在右侧的“HAR Converter”控制面板中点击“HAR file”的浏览按钮选择你刚才保存的.har文件。关键配置与转换Target Controller选择Test PlanThread Group。这会在测试计划下自动创建一个线程组并将所有转换出的请求放在里面。你也可以先手动创建一个线程组然后这里选择它。Filter这是净化脚本的神器。在“Filter”输入框你可以使用正则表达式来排除无用的请求。例如输入.*\.(js|css|png|jpg|gif|ico|woff2?|svg).*可以过滤掉绝大多数静态资源。勾选上“Filter”选项。Create a Transaction Controller for each page建议勾选。它会根据HAR文件中的页面Page信息将同一个页面的多个请求归集到一个“事务控制器”下让脚本结构更清晰。例如“搜索结果页”的所有请求会被包在一个叫“Page:搜索结果页”的事务控制器里。点击“Convert”按钮。稍等片刻一个结构清晰的测试脚本就生成了。3.4 第四步脚本解析与关键元件审查转换完成后不要急着运行。花10分钟审查和了解自动生成的脚本结构这是从“会用工具”到“理解测试”的进阶一步。线程组Thread Group这是性能测试的负载单元定义了虚拟用户数线程数、循环次数、启动时间等。转换插件通常会创建一个默认的线程组1个用户循环1次。事务控制器Transaction Controller如果你勾选了相关选项现在应该能看到以“Page:”开头的控制器。它会把其下的所有请求采样器作为一个整体来统计响应时间这对衡量页面性能非常有用。HTTP请求采样器HTTP Request脚本的核心。展开一个请求你需要重点关注协议、服务器名称、端口、路径这些通常已正确填充。请求方法GET/POST/PUT/DELETE是否正确。参数Parameters或消息体数据Body Data对于POST请求检查参数是否完整。特别是登录请求的用户名密码搜索请求的关键词。这里经常是第一个坑如果网站登录使用了JSON格式你需要检查“Body Data”标签页而不是“Parameters”。HTTP信息头管理器HTTP Header Manager插件会自动创建一个里面包含了录制时浏览器发送的常见头信息如User-Agent,Accept,Content-Type等。这是第二个关键点对于现代APIContent-Type: application/json这个头至关重要如果缺失服务器可能无法解析你的JSON请求体。Cookie管理器HTTP Cookie Manager这是保证脚本连续运行的核心插件会自动添加一个Cookie管理器。正是这个元件帮我们自动处理了登录后的会话Cookie如JSESSIONID。在回放时Jmeter会像浏览器一样存储服务器返回的Set-Cookie信息并在后续请求中自动携带。没有它登录后的所有请求都会因未认证而失败。3.5 第五步参数化与关联——让脚本“活”起来直接回放录制的脚本可能只能成功运行一次。因为很多数据是“写死”的。我们需要引入参数化和关联模拟不同用户的不同行为。参数化搜索关键词我们录制的搜索请求中关键词是固定的“手机”。现在要模拟不同用户搜索不同商品。在测试计划中添加一个“CSV 数据文件设置”元件。配置一个search_keywords.csv文件里面每行写一个关键词手机,笔记本电脑,耳机,智能手表。在CSV元件中指定文件名和变量名如KEYWORD。回到那个搜索的HTTP请求将路径或参数中的“手机”替换为${KEYWORD}。这样每次循环或不同线程就会读取不同的关键词。关联动态令牌以CSRF Token为例很多系统在登录或提交表单时需要携带一个服务器下发的、一次性的CSRF Token用于防攻击。这个Token每次访问页面时都不同。第一步提取。在登录前的那个GET请求可能是获取登录页面的响应中通常包含这个Token。我们需要添加一个“后置处理器”比如“正则表达式提取器”或更强大的“JSON提取器”如果Token在JSON里。配置它从响应数据中提取Token值并存入一个变量如csrf_token。第二步使用。在登录的POST请求中将这个${csrf_token}变量作为参数之一提交给服务器。这是第三个大坑也是性能测试脚本调试中最常遇到的问题。务必使用Jmeter的“查看结果树”监听器仔细对比录制时和回放时请求与响应的差异找到这些动态值。4. 脚本调试与增强确保回放成功脚本制作完成后必须经过严格的调试才能用于正式压测。4.1 使用监听器进行调试在线程组下添加两个关键的监听器查看结果树View Results Tree这是你最强大的调试工具。在调试阶段务必启用它。运行脚本后你可以查看每一个请求的详细情况请求发送了什么数据头信息是否正确。响应数据服务器返回了什么。成功通常是预期的JSON或HTML失败则可能是登录失效、参数错误等提示信息。通过对比录制和回放的请求差异能快速定位问题。注意“查看结果树”会消耗大量内存在正式进行高并发压测时务必禁用或删除它否则会导致Jmeter内存溢出OOM或严重性能下降。聚合报告Aggregate Report在调试阶段也可以添加它提供所有请求的响应时间、吞吐量等统计信息的概览帮你快速发现哪个请求最慢。4.2 添加断言Assertion——验证业务是否成功压测不仅要看请求是否成功HTTP 200更要看业务是否成功。例如登录后服务器返回200但内容可能是“密码错误”。这就需要断言。在登录请求下添加一个“响应断言”。可以断言“响应文本”包含“登录成功”或你的用户昵称。也可以断言“响应代码”等于200并且“响应消息”包含“OK”。断言失败Jmeter会将该次采样记为失败在最终的测试报告里你就能知道业务成功率是多少这比单纯的HTTP状态码更有意义。4.3 设置思考时间与定时器Timer真实用户操作时有间隔。录制脚本时我们的操作间隔也被记录了下来体现在请求之间的时间差上。但在回放时Jmeter会以最快速度发送请求这会给服务器带来不真实的瞬时压力。你可以在事务控制器或请求之间添加“固定定时器Constant Timer”。设置一个合理的等待时间比如3000毫秒3秒模拟用户浏览页面的时间。更真实的模拟可以使用“高斯随机定时器Gaussian Random Timer”它会在一个基准时间上下随机波动。5. 常见问题排查与性能优化实录即使按照步骤操作你也一定会遇到问题。这里记录了几个最高频的“坑”和我的解决方案。5.1 问题回放脚本时登录后的请求全部失败返回401/302跳转登录页排查思路这几乎100%是会话Session丢失问题。检查步骤确认脚本中包含了“HTTP Cookie 管理器”。没有就加上。检查登录请求是否成功。在“查看结果树”里看登录请求的响应是否包含了Set-Cookie头可能需要切换到“响应头”标签查看。检查服务器返回的Cookie路径Path和域名Domain。如果Cookie管理器配置了“Cookie策略”可以尝试改为standard或ignoreCookies再试。终极技巧有时候网站可能使用了额外的身份验证方式如JWT Token放在Authorization头里。这时你需要用“正则表达式提取器”从登录响应体通常是JSON中提取出token然后手动添加一个“HTTP信息头管理器”在里面添加一行Authorization: Bearer ${your_token_variable}。5.2 问题POST请求提交后服务器返回“参数无效”或“格式错误”排查思路请求体Body格式或内容头Header不正确。检查步骤在“查看结果树”中对比录制和回放时该请求的“请求体”是否完全一致。特别注意JSON格式的缩进、引号。检查“HTTP信息头管理器”中的Content-Type。如果是提交JSON必须是application/json如果是表单通常是application/x-www-form-urlencoded。这个头信息错误服务器就无法正确解析你的数据。对于文件上传请求需要检查“文件上传”标签页是否正确选择了文件路径、设置了参数名和MIME类型。5.3 问题脚本在少量用户时运行正常但并发量一高就出现大量错误排查思路这可能是脚本本身存在性能瓶颈或者参数化数据不足导致冲突。优化方向检查参数化数据如果所有用户都使用同一个用户名登录必然会在服务器端产生冲突。确保CSV文件中的数据量远大于并发线程数并使用不同的数据读取模式如Random。禁用或清理监听器正式压测时只保留“聚合报告”、“汇总报告”等轻量级监听器。“查看结果树”、“用表格查看结果”等务必禁用。调整Jmeter自身配置编辑bin/jmeter.properties文件增加JVM堆内存如-Xms2g -Xmx4g修改maxHeapSize等参数以适应更高的并发和更长的测试时间。使用命令行非GUI模式运行压测GUI模式本身会消耗资源。正式压测应使用命令jmeter -n -t your_test.jmx -l result.jtl来执行并将结果保存到.jtl文件事后用GUI打开分析。5.4 问题录制时一切正常但回放时页面显示不全或功能异常排查思路可能遗漏了某些关键但“不起眼”的请求。检查步骤回顾录制过程是否有一些异步加载的请求比如滚动加载更多、鼠标悬停提示等。这些请求在HAR文件中可能因为过滤而被误删。尝试在转换HAR时先不添加任何Filter生成一个完整的脚本然后手动删除明显无关的静态资源请求。虽然麻烦但能确保完整性。检查是否有请求依赖特定的“Referer”头或自定义头。有些API会校验请求来源页面。录制脚本只是性能测试万里长征的第一步但它决定了后续所有工作的基础是否牢固。一个录制精良、参数化完整、关联正确的脚本就像一份精准的地图能指引你的压测引擎直击系统瓶颈。而一个粗糙、满是硬编码的脚本只会带你走进歧途得出毫无价值的测试结论。多花时间在脚本准备和调试上是性能测试工程师最值得的投资。当你能够熟练地让脚本模拟出成百上千个真实用户在系统里“逛街”、“抢购”、“吐槽”时你就真正掌握了通过技术洞察业务负载本质的能力。