1. 为什么我建议性能测试脚本尽量用录制而不是纯手写先聊个很现实的问题。很多人刚接触Jmeter时第一反应是打开软件找到Test Plan然后对着HTTP Request一个个手工填写域名、路径、参数。对于接口只有三五个的小项目这么做没问题。但一旦遇到几十个接口的完整业务流程比如从登录到下单再到支付手写脚本能把人写到怀疑人生而且非常容易漏掉某个隐藏请求或者写错某个动态参数。录制测试脚本的价值就在这里。通过Jmeter内置的HTTP代理服务器把客户端发起的真实请求原样捕获下来自动生成对应的Sampler。你只需要做后期的整理和参数化而不是从零开始构造每一个请求。本质上这相当于给测试人员配了一个“自动抄写员”把你在浏览器或者App里的每一步操作都变成可执行的测试脚本。这篇文章适合谁看想给项目快速搭建压测脚本的测试工程师、刚入门性能测试的新人、以及需要把手工测试流程转化成自动化回归脚本的开发或测试同学。我会把从环境准备、代理配置、HTTPS证书处理到脚本二次整理的完整路径都讲一遍包括那些容易踩的坑。2. 录制方案选型自带代理和Badboy的区别在哪2.1 Jmeter自带HTTP代理服务器Jmeter本身原生支持录制功能。你打开Jmeter后在测试计划里添加一个“HTTP代理服务器”元件配置好端口把浏览器的代理指到这个端口所有经过浏览器的HTTP和HTTPS请求就会被Jmeter截获并转化为脚本里的Sampler、断言和控制器。这个方案最大的优势是零额外依赖装好Jmeter就能用。而且它能够直接生成JMX格式的脚本不需要中间转换。缺点是界面相对粗糙配置项多新手第一次看到那一堆“目标控制器”“分组”选项会有点懵。另外HTTPS抓包需要安装Jmeter自带的证书这一步如果处理不好录制直接失败。2.2 Badboy录制后导出JMXBadboy是老牌录制工具很多人第一次接触Jmeter录制就是从Badboy开始的。它的操作方式是独立的图形界面录制过程像录屏一样直观能看到每个请求都在左侧树形结构中冒出来。录制完成后通过File - Export to JMeter导出JMX文件然后在Jmeter中打开使用。Badboy的好处是录制体验好请求列表一目了然对新手非常友好。但它有几个转向问题一是Badboy已经停止维护很久了只支持Windows二是部分新版浏览器的行为它无法完整模拟三是导出的脚本经常会带上很多冗余的请求头需要花不少时间清理。2.3 我的选型建议按我个人的实践习惯如果只是简单场景直接使用Jmeter自带代理如果项目里HTTP请求头特别复杂或者需要快速抓取AJAX动态交互可以先用Badboy录一遍看清楚请求结构再用Jmeter自带代理做精细录制。两种方案不是互斥的实际工作中经常混合使用。有一点需要特别提醒录制只是一种获取请求快照的手段录出来的脚本永远不会是最终上线压测的脚本。真正的工作量在录制之后——参数化、关联、去冗余、加断言。换句话说录制是开胃菜整理才是正餐。3. 录制前的环境准备版本选择、目录规范、浏览器代理设置3.1 Jmeter版本选择与基础环境我遇到很多人问“Jmeter下载哪个版本”这里直接给出结论优先选官方最新稳定版。Jmeter是Apache基金会旗下的开源项目官方地址是jmeter.apache.org。下载页里会有两个选择Source源码包和Binaries二进制包。普通用户直接下Binaries格式是zip或tgzWindows下zip最方便Linux/macOS下tgz更顺手。运行Jmeter需要JDK环境这一点很多人容易忽略。不同版本的Jmeter对JDK版本的要求不同。比如Jmeter 5.4及以上官方要求JDK 8以上但实际如果跑5.6以上的版本建议直接用JDK 11或JDK 17否则有些插件和组件会报类版本错误。安装完JDK后命令行里输入java -version能正常输出版本号再解压Jmeter包双击bin目录下的jmeter.batWindows或者运行jmetermacOS/Linux即可。3.2 目录结构规范Jmeter解压后不要直接仍在桌面或者下载文件夹里就完事。我个人建议建一个专门的测试工作目录比如D:\jmeter_workspace下面是test_scripts放最终脚本、recording_tmp放录制中间文件、test_data放CSV参数化文件、logs放测试日志和结果文件。这个习惯看起来很小但等脚本多了之后能省很多找文件的时间。每次录制前把生成的脚本先存到recording_tmp然后整理完毕再移动到test_scripts这样能避免“脚本没保存就关了”以及“改乱了找不到原版”这种低级事故。3.3 HTTP代理服务器配置这一步是核心。打开Jmeter后右键测试计划 - 添加 - 非测试元件 - HTTP代理服务器在HTTP代理服务器面板里端口填8080或任意未被占用的端口比如8888。如果提示端口被占用就换一个目标控制器选择“测试计划 线程组”意思是录制的请求会落到哪个位置。建议先建一个空的线程组再指定到这里分组选择“每个组放入一个新的控制器”或者“在组间添加分隔”。这两个选项会让录制的请求按事务分组便于整理记录HTTP信息头勾选否则请求头里的Cookie、Authorization等关键信息录不进去添加断言可以勾选但我不建议录制时就加断言后续手动加会更准确配置完成后点击启动Jmeter会提示“代理服务器已启动”。此时把浏览器代理设置指向127.0.0.1:8080即可。注意如果本机之前已经设置过系统代理开启Jmeter代理前最好把系统代理关掉否则流量会走两层代理导致录制丢包甚至完全录不到请求。3.4 浏览器代理设置的两种方式与选择对于Chrome浏览器有两种设置代理的路径一种是修改系统代理。在Windows设置 - 网络和Internet - 代理 - 手动设置代理输入127.0.0.1和端口。这种方式对所有走系统代理的程序都生效但是容易被其他程序干扰。另一种是用浏览器插件比如SwitchyOmega。在插件的“新增情景模式-代理服务器”里填好地址和端口然后一键切换。这种方式的优势是只影响当前浏览器不影响系统里其他网络请求并且可以随时切换“直接连接”和“代理”模式。我更推荐用插件方式。原因很实在录制过程中经常需要在“代理-直连”之间切换系统代理改一次要进设置界面好几层而插件点一下就切换了。而且录制完别忘了切回直连否则你会发现浏览器上不了网因为流量还在往代理端口发送。4. 录制过程中最绕不开的坎HTTPS证书处理4.1 为什么HTTPS录制成空白很多人在第一次用Jmeter录制HTTPS请求时都会遇到一个诡异现象浏览器能正常打开网页但Jmeter这边一个请求都录不到或者录到了全是乱码和报错。这个问题的根源是HTTPS的加密机制。HTTPS通信里浏览器会对服务器证书做合法性校验。当浏览器被设置代理后Jmeter代理服务器会扮演一个“中间人”的角色它接收浏览器的请求然后用自己生成的一个根证书签名出一个服务器证书再跟目标服务器完成握手。浏览器发现这个证书不是你访问的那个域名签发的会视为不受信任直接中断连接。所以页面就打不开请求也录不到。要解决这个问题核心做法是把Jmeter代理服务器的根证书导入浏览器并标记为受信任的根证书颁发机构。4.2 Jmeter证书导入完整步骤在启动代理服务器后打开浏览器访问代理地址一般是http://localhost:8080页面会提供一个证书下载入口通常是一个叫“ApacheJMeterTemporaryRootCA”的CA证书文件。有些版本是访问 http://jmeter 或 http://localhost:端口 后自动下载下载完成后文件是CRT格式。双击打开点击“安装证书”存储位置选择“本地计算机”选择“将所有的证书都放入下列存储”点浏览选择“受信任的根证书颁发机构”一路下一步直至完成。弹窗提示“导入成功”即可导入完成后重启浏览器注意是彻底退出再打开不是刷新再访问HTTPS网站时就不会报警告了录制也能正常捕获HTTPS请求。4.3 一个容易被忽视的细节证书有效期与浏览器忽略Jmeter生成的根证书默认有效期大概是7天左右。也就是说你上周还能正常录制的环境这周突然录不到HTTPS请求了大概率不是操作配置错了而是证书过期了。遇到这种情况重新下载一次证书并覆盖安装即可。另外Chrome和Edge对证书的管理策略越来越严格有时候明明导入了证书浏览器还是不认。这种情况可以试试在浏览器地址栏直接输入chrome://flags看看有没有“Allow insecure local connections”之类的实验项或者换Firefox浏览器录制Firefox对本地导入证书的支持更宽松。我在实际项目中录制HTTPS脚本时首选Firefox稳定性比Chrome好很多。提示如果你用抓包工具Fiddler或Charles配合Jmeter一起工作注意它们的证书和Jmeter证书不要相互覆盖否则会出现“证书被替换”的冲突提示。每个工具独立的证书文件建议分开导入不要同时启用多个代理。5. 实战演示从零录制一个完整的登录-查询-退出脚本5.1 录制场景设定为了把整个流程走一遍我以一个常见的Web业务系统为例用户登录、进入订单列表查询订单、退出登录。这个场景基本覆盖了Session保持、Cookie传递、动态请求参数这几类录制中最常遇到的要素。录制前的准备工作确认测试计划里已经创建了一个空线程组HTTP代理服务器的目标控制器指向这个线程组浏览器我用Firefox代理设置为127.0.0.1:8080证书已安装且浏览器已重启5.2 开始录制在Jmeter中点击代理服务器面板的“启动”按钮控制台会打印出代理启动成功的日志。然后打开浏览器访问被测系统的登录页面。录制时建议按真实用户的完整流程走一遍输入用户名和密码点击登录等待页面跳转点击“订单查询”菜单在订单查询页面输入查询条件点“查询”按钮查看查询结果列表点击退出登录关闭浏览器整个过程中不要做多余操作。不要切出浏览器去查资料也不要中途去操作别的标签页因为代理会把你所有经过它的请求都记录下来——哪怕只是一个加载广告的请求。录制的请求越干净后期整理越省事。5.3 停止录制并检查脚本操作完成后回到Jmeter点击代理服务器的“停止”按钮。然后展开测试计划里的线程组你会看到刚才的一堆请求已经躺在里面了。这时先不要急着运行按照下面几个点检查请求顺序是否和实际操作顺序一致登录 - 查询 - 退出是否出现非业务流程的请求很多系统会加载统计脚本、埋点请求、静态资源请求这些对压测没有意义直接删掉。判断依据是和业务数据生成、提交无关的都可以去掉每个HTTP请求的路径是否正确双击请求查看“协议”“服务器名称”“路径”确认URL拼写正确请求参数是否齐全在“参数”标签页查看尤其注意POST请求的表单数据和JSON数据是否完整5.4 保存脚本并做最小验证把整理后的脚本保存为test_login_query_logout.jmx然后右键线程组 - 添加 - 监听器 - 查看结果树。点击绿色三角形“启动”按钮快捷键CtrlR先用1个线程、1次循环跑一遍。如果日志里全部是绿色成功说明脚本录制的基本形态是通的。如果出现失败重点看响应数据里的错误码和错误信息。这时候不要急着去改参数先定位是哪个请求失败了失败原因是什么。常见的失败原因有Cookie没有保持、某个字段被服务端校验了、请求头缺失。这是录制脚本后最正常的调试过程。6. 录制完成后的脚本手术四道必须做的整理工序6.1 第一刀去掉“身体脂肪”——冗余请求清理录制脚本最显著的问题就是噪音多。一个登录操作可能录下来了页面本身的HTML请求、CSS、JS、图片、图标、统计上报请求、前端埋点请求等。这些请求在压测中如果全量保留不仅会消耗测试机资源还会干扰真正的业务请求占比导致压测结果失真。怎么判断哪些该留哪些该删原则很简单只保留会产生业务数据、或对业务流程有依赖关系的数据请求。比如登录时提交用户名密码的POST请求必须留登录成功后返回首页的HTML请求可以留模拟用户看到页面页面里的logo.png、jquery.min.js这些静态资源可以全部删除前端埋点、SDK请求删除实际操作时我习惯先按“请求名称”排序找出所有静态资源请求直接选中删除。然后再看一遍剩下的把重复请求去重把可疑请求对照浏览器开发者工具里的Network面板二次确认。6.2 第二刀把写死的值变成变量——参数化录制下来的数据是死的。登录用户名是“admin”那脚本永远只能以admin身份压测。查询条件是“2024-01-01”那所有用户的查询条件就都是这一天。这在真实压测里是不允许的真实用户上千人用户名、密码、查询条件、商品编号各不相同。参数化的核心操作分两步第一步准备数据文件。用CSV文件存储数据第一行通常是参数名第二行开始是数据。比如username,password user001,yh123456 user002,yh789012 user003,pwd88888把文件存到测试数据目录编码建议用UTF-8。如果包含中文要确认文件保存时没有BOM头否则第一个参数名会被读成“\ufeffusername”导致断言失败。第二步在Jmeter中添加CSV数据文件设置。右键线程组 - 添加 - 配置元件 - CSV数据文件设置。填入文件名路径变量名称写“username,password”分隔符逗号是否允许带引号选“False”结束符选“EOF”或“True”按需选择。然后在请求参数中把写死的用户名和密码替换为${username}和${password}。运行脚本后每个线程会从CSV中取一行数据作为请求参数。提示如果压测场景要求所有用户使用同一个账号登录那就不需要参数化用户名。但这种情况在真实场景中很少见多用户并发时服务端做了会话限制同账号会互相顶掉登录态导致大量登录失败。所以只要条件允许账户尽量参数化。6.3 第三刀把动态值关联起来——处理token和session业务系统通常会在登录后返回一个token或者SessionID后续的查询、下单等操作必须携带这个值。录制脚本时Jmeter会把登录响应里的token值原样记录下来。但压测时每次登录生成的token都不一样如果继续用录制时的那个token一定报401或403。解决办法是“关联”。用正则表达式提取器或者JSON提取器从登录请求的响应中提取token然后作为变量传递到后续请求中。具体操作右键登录请求 - 添加 - 后置处理器 - 正则表达式提取器引用名称填token正则表达式根据接口返回格式填写。如果返回的是JSON用token:(.?)这种写法模板$1$匹配数字1代表取第一个匹配项默认值留空或填NOTFOUND然后再到后续查询请求中把请求头或参数里的旧token替换为${token}。这样每次压测都会自动使用当前登录返回的新token解决了动态参数失效的问题。如果系统返回的是JSON格式直接用JSON提取器更简单JSON Path表达式写$.data.token变量名填token。注意JsonPath的根路径是从$开始具体写法取决于响应结构。不确定时可以在Jmeter的“查看结果树”里查看响应数据确认层级关系。6.4 第四刀加断言和数据正确性校验很多人录完脚本就直接开压测跑完发现所有请求都返回200以为万事大吉。但实际上200只能代表请求到达了服务器并返回了响应不能代表业务成功了。比如一个登录接口账号密码错误时也返回200但响应体里写的是“登录失败用户名或密码错误”。如果只看状态码这就会被当成成功请求压测报告完全失真。所以关联断言的添加很有必要。在需要验证的关键请求上右键 - 添加 - 断言 - 响应断言。要检查的响应字段选择“响应文本”模式匹配规则包括字符串测试模式填业务成功时的特征字符串。比如登录成功返回“code:200”或者“登录成功”这样压测时如果一个请求没有包含这个字符串Jmeter会把它判定为失败并在结果统计中显示出来。这样你的通过率才真正反映业务成功率而不是HTTP状态码的通过率。6.5 整理阶段的顺序也很重要这里给一个清晰的处理顺序减少返工先做请求清理删除静态资源、埋点、无关请求再做参数化把账号、查询条件等固定值变成变量然后是关联识别出依赖登录态的请求把动态token关联到位最后加断言在关键业务请求上添加响应断言跑一遍小规模冒烟测试1个线程循环1次确认全绿后再逐步增加并发这个顺序遵循“先解决有无再解决正确性”的原则。如果刚开始就纠结正则表达式怎么写结果跑都跑不通调试效率会很低。7. 常见录制问题与排查方法实录7.1 录制时浏览器提示“代理服务器出现问题”或“无法连接”最常见的原因是端口没对上。Jmeter代理服务器设置的端口是8080浏览器代理也填8080这两个必须完全一致。如果填错了端口浏览器发的流量根本没被Jmeter拦住自然什么也录不到。另一个原因是端口被占用。可以命令行执行netstat -ano | findstr 8080查完之后如果发现PID对应的是别的程序说明8080被占用了。换一个端口重新启动代理即可。7.2 页面能打开但录不到请求这种情况多半是浏览器设置了“绕过本地地址的代理”或者“不使用代理”。在代理设置里要确保“对以下地址不使用代理”列表中没有填localhost和127.0.0.1。另外检查浏览器的扩展程序里有没有其他代理类插件在冲突比如某些下载工具内置了代理设置会拦截流量。7.3 HTTPS请求录到了但请求头缺少Cookie和Token这可能是因为录制时“记录HTTP信息头”没勾选。HTTP代理服务器面板里有一个“记录HTTP信息头”的选项不勾选的话Jmeter不会保存请求头内容导致Cookie等信息缺失。修改后重新录制。7.4 压测时脚本报400 Bad Request但浏览器访问正常经常出现在录制POST请求的场景。原因是Jmeter录制时可能把Content-Type头弄成了默认的application/x-www-form-urlencoded而实际接口要求的是application/json。检查请求的“HTTP信息头管理器”确认Content-Type是否正确若不正确直接修改或添加。7.5 中文乱码问题录制时请求参数含中文运行后查看结果树发现中文变成了乱码。这个问题的根子在编码设置上。Jmeter默认使用的编码是ISO-8859-1需要改成UTF-8。处理方式有两种一是修改jmeter.properties配置文件将sampleresult.default.encoding改为UTF-8后重启Jmeter二是在HTTP请求面板的“内容编码”一栏填UTF-8。第二种方式更灵活只对当前请求生效。7.6 排查问题时的实用技巧很多新手遇到问题第一反应是到处百度其实更高效的是先看Jmeter的日志和响应数据。查看结果树里每个请求都有“请求体”、“响应数据”、“响应头”大部分问题可以从这里面直接定位。比如响应数据里明确写了“token已过期”那就知道是关联没做对写了“参数不能为空”那就知道是参数没传到位。8. 录制脚本工作流的进一步延伸录制脚本虽然主要服务性能压测但实际上它的能力边界远不止于此。我平时也用它来快速搭建接口自动化冒烟测试集。录一遍登录、录一遍核心流程然后整理成不依赖并发配置的测试计划接入持续集成流水线每次发版后自动跑一遍能提前拦截很多回归问题。另外在使用Jmeter录制脚本时搭配一些插件能显著提升效率。比如通过JMeter Plugins Manager安装Custom Thread Groups插件可以更灵活地设置测试场景安装JSON插件后JSON提取器的选择范围更广。不过插件安装不宜过载够用就好插件过多会导致启动变慢还会带来版本兼容问题。最后再分享一个经验录制脚本虽然方便但不要过度依赖。对于新开发的功能录制前一定要先手工在浏览器里走通整个业务流程确认功能本身是完好的。如果业务逻辑本身有Bug录下来的脚本怎么修都跑不顺——因为问题根本不在脚本层。我在实际项目中发现录制过程中意外“帮助”业务排查出了几个隐藏BUG反而是额外收获。回到开头那句话录制是入口整理是核心精准参数化是魂。把录制的每个环节理解透了Jmeter的脚本就不再是写不出来的难题而是可以在几分钟内快速生成的顺手工具。下次遇到压测任务不妨先别急着手写让代理服务器帮你干那些繁重的抓包工作你会发现测试脚本的准备效率能提高不少。