1. 项目概述为什么选择JMeter代理录制移动APP接口测试如果你是一名测试工程师或者正在从功能测试转向自动化测试面对一个全新的移动APP第一反应是不是有点无从下手特别是当开发文档不全、或者接口数量庞大时手动编写每一个接口的测试脚本工作量巨大且容易出错。这时候“录制与回放”就成了一个快速切入的利器。而JMeter这个老牌的、功能强大的开源工具其内置的HTTP(S) Test Script Recorder代理录制器功能恰好能完美解决这个痛点。简单来说这个项目的核心就是利用JMeter作为“中间人”代理捕获你的手机APP在真实操作过程中发出的所有网络请求主要是HTTP/HTTPS并自动生成可重复执行的测试脚本JMX文件。这相当于给你的测试过程装了一个“行车记录仪”你只管正常使用APP它来负责记录所有“路线”接口请求。之后你可以随时“回放”这段记录来验证接口功能是否正常、性能是否达标或者作为自动化测试套件的基础。为什么是JMeter而不是Postman、Charles或者Fiddler首先JMeter是完全免费且开源的没有使用成本或功能限制。其次它生成的脚本本身就是性能测试脚本录制好的接口用例稍加配置如参数化、断言、逻辑控制器就能直接用于压力测试实现了功能与性能测试的“脚本复用”效率极高。最后JMeter的生态非常丰富支持各种插件扩展能满足复杂的测试场景需求。对于需要兼顾接口自动化与性能测试的团队来说JMeter代理录制是一条非常高效的入门和实战路径。2. 核心思路与工具选型解析2.1 代理录制的工作原理扮演“中间人”要理解这个过程首先得明白“代理”在这里扮演的角色。在标准的网络请求中你的手机APP客户端直接与服务器通信。当我们启用JMeter的代理录制功能时整个数据流就变成了这样配置代理你在手机上设置网络代理将所有的HTTP/HTTPS流量指向运行JMeter的电脑的IP地址和指定端口默认8888。请求拦截当你操作APP时它发出的请求不再直接去往服务器而是先发送到JMeter代理。请求转发与记录JMeter代理接收到请求后会原封不动地将其转发给真正的目标服务器。同时它会将这个请求的详细信息如URL、方法、请求头、请求体捕获下来并按照你预设的格式在JMeter中生成一个对应的HTTP请求采样器。响应返回服务器处理请求后将响应返回给JMeter代理代理再将其传回给你的手机APP。这样APP能正常收到响应你的操作可以继续。同时JMeter也可以选择记录服务器的响应内容。这个过程就像快递代收点快递请求先送到代收点JMeter代理代收点登记快递信息录制脚本后再通知你转发请求给服务器来取件返回响应给APP。整个通信是透明的APP无感知。注意对于HTTPS请求由于涉及加密需要JMeter提供根证书并让手机安装信任才能进行解密和录制。这是录制HTTPS流量时必须处理的一步否则你只能看到一堆加密的数据包。2.2 为什么是JMeter对比其他方案市面上能录制网络请求的工具很多我们简单对比一下Postman虽然也有代理功能但其主要定位是API调试与协作。录制生成的集合Collection更适合手工调试和简单的自动化要转化为性能测试脚本需要额外步骤且大规模并发测试能力不如JMeter。Charles / Fiddler专业的抓包工具录制和调试功能极其强大能提供非常详细的请求/响应分析。但它们生成的会话记录Session通常需要导出为HARHTTP Archive文件再通过转换工具或脚本才能导入到JMeter中流程稍显繁琐。而且它们本身不是性能测试工具。JMeter一站式解决方案。录制直接生成.jmx脚本该脚本既是功能自动化脚本可添加断言进行校验也是性能测试脚本可直接设置线程组进行压测。避免了工具链切换和数据转换的麻烦。对于测试团队而言学习一个工具解决两类问题性价比最高。因此我们的选型思路很明确以快速构建可复用的、兼具功能和性能测试能力的接口测试脚本为目标JMeter的代理录制是当前综合成本最低、效率最高的方案。2.3 环境准备清单在开始动手之前你需要准备好以下环境我将以Windows/MacOS Android手机为例进行说明JMeter运行环境Java JDK 8或11JMeter基于Java开发必须安装JDK。建议安装JDK 8或11LTS长期支持版本并配置好JAVA_HOME环境变量。Apache JMeter 5.x从官网下载最新版本。解压即用无需安装。测试设备一台Android手机或iOS手机用于安装待测APP。本文以Android为例iOS原理类似配置代理的位置在Wi-Fi设置中。确保手机和运行JMeter的电脑在同一个局域网连接同一个Wi-Fi。这是代理能够通信的前提。待测应用程序确保手机上已经安装了你要测试的APP的测试包或线上包。3. JMeter代理录制器详细配置与实操3.1 启动JMeter与创建测试计划首先进入JMeter的解压目录找到bin文件夹。Windows双击jmeter.bat启动。Mac/Linux在终端中执行./jmeter启动。启动后你会看到一个空的测试计划Test Plan。我建议你先进行保存CtrlS或CmdS并命名为一个有意义的名称例如Mobile_APP_Recording.jmx。3.2 添加并配置HTTP(S) Test Script Recorder这是录制的核心控制器。添加录制器在左侧测试计划Test Plan上右键选择Add-Non-Test Elements-HTTP(S) Test Script Recorder。这会在测试计划下创建一个名为“HTTP(S) Test Script Recorder”的元件。创建存放录制的线程组在测试计划上右键选择Add-Threads (Users)-Thread Group。这个线程组将作为录制请求的“容器”。你可以将其重命名为“录制容器”或“APP业务流程”。关联录制器与容器点击刚创建的HTTP(S) Test Script Recorder在右侧面板的Target Controller下拉框中选择我们刚创建的Thread Group。这意味着所有录制到的请求都会自动放入这个线程组中。关键配置详解Port代理端口默认8888。如果此端口被占用如被Charles等工具使用可以改为其他未被占用的端口如8899。记住这个端口号手机配置代理时会用到。HTTPS Domains这里填写你待测APP的主要域名。例如如果你的API都指向api.yourcompany.com就填这个。这有助于JMeter在录制HTTPS流量时正确生成证书。可以填写多个用逗号分隔。Start按钮点击它来启动代理服务器。3.3 设置请求过滤避免录制垃圾请求如果不加过滤你会录制到大量图片、CSS、JS等静态资源请求以及第三方SDK如友盟、广告的请求这些通常不是我们接口测试的重点会干扰脚本的清晰度。点击HTTP(S) Test Script Recorder配置面板中的Request Filtering标签页这里是过滤器的核心。包含模式IncludeURL Patterns to Include这是最常用的过滤方式。根据你的接口URL特征添加正则表达式。例如如果你的后端接口路径都包含/api/v1/那么可以添加一个包含模式.*/api/v1/.*。这表示只录制URL中包含/api/v1/的请求。Content-Type to Include如果你的接口都是RESTful API返回JSON可以在这里添加application/json。这可以过滤掉非JSON的响应如图片。排除模式ExcludeURL Patterns to Exclude用于排除已知的干扰项。例如你可以添加.*\.(js|css|png|jpg|gif|ico)来排除所有常见的静态资源文件请求。实操心得在第一次录制某个APP时我建议先不设置任何过滤完整录制一遍。然后观察录制到的请求列表分析出你真正需要测试的接口的URL模式特征再据此设置包含和排除规则。这样过滤出来的脚本最精准。3.4 处理HTTPS流量安装JMeter证书这是录制能否成功的关键一步。对于HTTP请求跳过此步。对于HTTPS必须操作。启动代理并生成证书在完成上述基本配置后点击Start按钮启动代理。第一次启动时JMeter会在其bin目录下生成一个名为ApacheJMeterTemporaryRootCA.crt的根证书文件。将证书发送到手机并安装你可以通过数据线、邮件、网盘等方式将这个.crt文件传到手机上。Android在手机的文件管理器中找到该证书点击安装。系统会要求你为证书命名如“JMeter Proxy CA”并选择用途选择“VPN和应用”或“WLAN”。安装完成后你需要在手机的“设置” - “安全” - “加密与凭据” - “用户凭据”或“信任的凭据” - “用户”中看到它。iOS过程类似通过邮件或网页打开证书文件进入“设置” - “已下载描述文件”安装并在“设置” - “通用” - “关于本机” - “证书信任设置”中完全信任此根证书。为什么必须安装证书HTTPS通信是加密的手机不信任JMeter这个“中间人”就会拒绝连接。安装JMeter的根证书就是告诉手机“我信任这个代理允许它解密和查看我的HTTPS流量。”这是一个标准的安全操作仅用于测试环境。重要安全提示此证书仅用于内部测试。测试结束后建议在手机上删除此证书不要用于浏览不可信的网站。4. 移动端代理配置与录制过程4.1 手机端代理配置步骤确保你的手机和电脑处于同一Wi-Fi网络下。进入手机的“设置” - “WLAN”。长按当前已连接的Wi-Fi网络选择“修改网络”或“高级选项”。找到“代理”设置项将其从“无”改为“手动”。代理服务器主机名填写你电脑在局域网内的IP地址。在电脑上打开命令行Windowsipconfig查找“无线局域网适配器 WLAN”下的IPv4 地址。Mac/Linuxifconfig或ip addr查找en0或wlan0下的inet地址。代理服务器端口填写你在JMeter中设置的端口默认8888。保存设置。验证代理是否生效此时手机上的所有HTTP(S)流量都会经过你的电脑。你可以在电脑浏览器访问http://ip.cn这类网站查看IP如果显示的是你电脑的IP说明代理成功。或者在JMeter的“查看结果树”监听器中如果开始出现请求也说明配置成功。4.2 开始录制与操作APP清空录制容器在开始前右键点击之前创建的Thread Group录制容器选择Clear或Remove All确保里面是空的。操作APP像正常用户一样打开手机上的待测APP进行你想要测试的业务操作。例如启动APP - 登录 - 浏览首页 - 点击某个商品 - 加入购物车 - 下单。观察JMeter在操作APP的同时观察JMeter。在对应的Thread Group下你会看到HTTP Request采样器一个接一个地自动生成并且按照操作顺序排列。每个采样器都包含了完整的请求信息。停止录制完成所有需要录制的操作后回到JMeter点击HTTP(S) Test Script Recorder上的Stop按钮停止代理录制。关闭手机代理非常重要录制完成后务必回到手机Wi-Fi设置中将代理改回“无”。否则手机无法正常上网。4.3 录制脚本的初步优化与整理录制生成的脚本是“原始”的直接回放可能会遇到问题需要做一些清理和优化删除无用请求手动检查线程组中的请求删除那些明显是静态资源图片、CSS、JS或第三方服务的请求如果之前过滤没生效。重命名采样器默认的采样器名称是请求的URL可读性差。建议根据业务逻辑重命名。例如将POST /api/login重命名为01_用户登录。添加事务控制器为了更清晰地组织业务流可以添加Transaction Controller。例如创建一个名为“用户登录流程”的事务控制器将登录相关的请求如获取验证码、提交登录拖进去。这有助于在生成报告时查看整个事务的耗时。保存脚本及时保存你的.jmx文件。5. 从录制到回放构建可用的自动化测试脚本录制只是拿到了“原材料”回放才是“烹饪”。直接回放原始脚本大概率会失败因为很多请求带有动态参数如Token、时间戳、会话ID。5.1 处理动态参数正则表达式提取器与JSON提取器这是接口自动化测试的核心技能。你需要从先前的请求响应中提取出动态值传递给后续的请求。识别动态参数回放脚本在“查看结果树”中检查失败的请求。通常失败原因是“Token无效”或“参数缺失”。找到是哪个参数需要动态获取。添加后置处理器正则表达式提取器适用于响应体是文本或HTML的情况。在需要提取数据的请求采样器下右键Add-Post Processors-Regular Expression Extractor。Apply to: 通常选Main sample only。Field to check: 选Body。Reference Name: 定义一个变量名如access_token。Regular Expression: 编写正则表达式来匹配和捕获值。例如如果响应是{token: abc123}表达式可以是token: (.?)。Template:$1$表示取第一个捕获组。Match No.:1表示取第一个匹配项。JSON提取器强烈推荐用于JSON响应更简单稳定。在需要提取数据的请求采样器下右键Add-Post Processors-JSON Extractor。Names of created variables: 变量名如access_token。JSON Path expressions: JSON路径表达式如$.data.token。Match No.:1。引用变量在后续需要该动态参数的请求中使用${变量名}的格式来引用。例如在请求头的Authorization字段中填入Bearer ${access_token}或在请求体参数中填入${access_token}。5.2 添加断言验证接口响应是否正确没有断言的测试脚本是没有灵魂的。断言用于自动判断请求是否成功而不仅仅是看服务器是否返回了200状态码。响应断言最常用的断言。在需要断言的请求下右键Add-Assertions-Response Assertion。测试字段可以检查Response Code如等于200、Response Message、Response Headers或者Response Body。模式匹配规则对于响应体常用“包含”或“匹配”规则。例如登录成功后响应体里会有success: true你就可以添加一个模式success: true进行“包含”断言。JSON断言如果响应是JSON用JSON断言更精确。需要安装插件或者使用JSR223断言配合Groovy脚本解析JSON。持续时间断言用于性能测试断言响应时间不应超过某个阈值如2000毫秒。实操心得断言不是越多越好要关注核心业务逻辑。通常对关键的成功/失败状态码、核心业务字段如订单ID、用户ID进行断言即可。过于严格的断言如检查整个响应JSON会导致脚本脆弱一旦接口返回字段顺序或无关字段有变测试就会失败。5.3 参数化让测试数据更灵活如果你需要测试多组数据如用不同用户登录就需要参数化。CSV数据文件设置最常用的参数化方式。添加一个CSV Data Set Config元件在Config Element下。Filename: 指向一个CSV文件如user_data.csv内容可以是username,password作为表头下面多行数据。Variable Names: 填写变量名用逗号分隔如username,password。Delimiter: 分隔符CSV通常是逗号,。Recycle on EOF?: 文件读完是否循环通常性能测试设为True功能测试设为False。Stop thread on EOF?: 文件读完是否停止线程与上一项配合使用。在请求中使用变量在登录请求的用户名和密码参数中使用${username}和${password}。用户定义的变量对于一些全局的、不变的值如服务器域名可以在Test Plan或User Defined Variables配置元件中定义。5.4 组织测试逻辑控制器与定时器逻辑控制器仅一次控制器将只需要执行一次的请求如登录放进去。循环控制器控制一组请求循环执行多次。如果If控制器根据条件决定是否执行其子元件。例如根据上一个请求的响应结果决定是执行成功流程还是失败流程。定时器固定定时器在每个请求后等待固定的时间模拟用户思考时间。高斯随机定时器等待时间随机更贴近真实用户行为。添加了参数化、断言和必要的控制器后你的脚本就从简单的“录制回放”升级为一个具备基本校验能力和数据驱动能力的自动化测试脚本。6. 回放调试与常见问题排查实录即使配置得当第一次回放也常会遇到各种问题。下面是我在实践中总结的常见问题及排查思路。6.1 问题一回放时请求全部失败无响应数据可能原因1手机代理未关闭。这是最常见的原因。录制完成后手机代理仍指向你的电脑但JMeter代理已停止导致手机无法上网。解决立即检查并关闭手机Wi-Fi设置中的手动代理。可能原因2JMeter代理未启动或端口冲突。回放时不需要启动代理。但如果脚本中包含了需要代理的配置错误添加了或者8888端口被其他程序占用会导致JMeter自身运行异常。解决确保回放时HTTP(S) Test Script Recorder是停止状态。用netstat -ano | findstr :8888(Windows) 或lsof -i :8888(Mac/Linux) 检查端口占用。可能原因3IP/域名不可达。检查脚本中请求的服务器地址是否正确。录制时用的是手机的实时网络如果服务器是内网地址如192.168.1.100而你的电脑不在同一内网回放自然会失败。解决使用User Defined Variables定义一个主机变量方便切换测试环境如${host}在测试环境指向内网IP在本地指向localhost。6.2 问题二登录后接口返回“Token无效”或“未授权”可能原因Token未成功提取或传递。检查提取器在登录请求下确认JSON Extractor或Regular Expression Extractor配置正确。在“查看结果树”中查看登录请求的响应体确认你要提取的字段存在且路径正确。调试变量值添加一个Debug Sampler和View Results Tree放在提取器后面回放后查看Debug Sampler的响应里面会列出所有JMeter变量的当前值检查你的Token变量如${access_token}是否有值。检查传递过程确认在需要Token的请求中正确引用了变量。例如在请求头的Authorization字段应该是Bearer ${access_token}注意拼写和空格。检查请求采样器的Parameters或Body Data中引用变量的语法是否正确。作用域问题默认提取的变量作用域限于当前线程组。如果Token需要在多个线程组间共享需要将其设置为全局属性。可以使用BeanShell PostProcessor或JSR223 PostProcessor执行props.put(global_token, vars.get(access_token))来存入全局属性在其他线程组用${__P(global_token)}来引用。6.3 问题三回放时出现大量“503 Service Unavailable”或连接超时可能原因1服务器压力过大。如果你用JMeter进行高并发回放压测而服务器处理能力不足就会返回503。解决降低并发线程数或检查服务器状态。可能原因2JMeter自身端口耗尽。这是JMeter做压测时的一个经典问题。在高并发下JMeter作为客户端会占用大量本地端口来与服务端建立连接如果端口快速耗尽就会报错。解决增加JMeter运行机器的本地端口范围需修改系统设置如Windows注册表。在JMeter的bin/jmeter.properties配置文件中设置httpclient4.time_to_live为一个较低的值如30000单位毫秒让连接更快关闭和释放。使用TCPMon或Connection Close等控制器或者在HTTP请求高级设置中勾选Use KeepAlive的相反选项根据实际情况。可能原因3缺少必要的请求头。有些服务器会检查User-Agent,Referer,Content-Type等头信息。录制时这些头被完整记录但如果你在脚本中误删了或者使用HTTP Request Defaults覆盖了可能导致服务器拒绝。解决对比录制和回放的请求头在“查看结果树”的请求标签页确保关键头信息一致。6.4 问题四响应断言失败但业务看起来是成功的可能原因断言模式匹配过于严格或响应数据动态变化。例如断言响应体包含orderId: 12345但每次生成的订单ID都是不同的。解决将断言改为检查模式是否存在而不是值完全相等。例如使用正则表达式orderId: \d来断言存在一个数字订单ID或者断言包含status: SUCCESS这个状态字段。响应中可能包含时间戳等每次都会变的信息。解决在断言前使用后置处理器如JSR223 PostProcessor配合Groovy脚本将响应中的动态部分如时间戳替换为固定值或通配符然后再进行断言。或者使用更灵活的JSON断言插件通过JSON Path判断某个字段是否存在而非其具体值。6.5 问题排查通用流程当脚本回放出问题时建议按照以下步骤排查可以解决90%以上的问题看日志首先查看JMeter GUI界面下方的日志区域或者运行命令行时控制台的输出看是否有明显的错误信息。用“查看结果树”这是最强大的调试工具。添加一个View Results Tree监听器回放脚本。绿色对勾通常表示网络请求成功状态码为2xx/3xx但不意味着业务成功。红色叉叉表示请求失败网络错误、超时、4xx/5xx状态码。检查请求点击失败的请求查看“请求”标签页确认发送的URL、头信息、参数/体是否正确特别是动态变量是否被正确替换显示为实际值而不是${var}。检查响应点击请求查看“响应数据”标签页这里包含了服务器返回的真实内容。这是判断业务逻辑是否成功的唯一依据。根据响应内容去调整你的提取器或断言。简化与隔离如果整个脚本复杂难以定位。可以新建一个测试计划只放入出问题的单个请求并手动填写参数看是否能成功。如果能再逐步将变量、提取器等加回去定位是哪个环节引入的问题。使用Debug Sampler在怀疑的环节前后添加Debug Sampler查看变量的状态变化。7. 脚本增强与持续集成初探一个健壮的自动化测试脚本不仅要能跑通还要易于维护和集成。7.1 添加监听器生成报告“查看结果树”在调试时很好用但会消耗大量内存不适合在正式运行或无头模式命令行下使用。我们需要更轻量或更聚合的报告。聚合报告Summary Report或Aggregate Report。提供基本的统计信息请求数、平均响应时间、错误率、吞吐量等。适合性能测试结果分析。断言结果Assertion Results。专门显示哪些断言通过了哪些失败了失败的原因是什么。生成HTML报告这是更专业的方式。JMeter支持生成美观的HTML报告。首先在运行测试时使用-l参数指定一个JTL结果文件jmeter -n -t your_test.jmx -l result.jtl然后使用-g参数根据JTL文件生成HTML报告jmeter -g result.jtl -o ./report_folder生成的report_folder里就是一个完整的HTML测试报告包含图表和详细信息非常适合归档和分享。7.2 将脚本集成到CI/CD流水线自动化测试的最终价值在于持续反馈。你可以将JMeter脚本集成到Jenkins、GitLab CI等工具中。命令行执行CI流水线的核心是使用命令行非GUI模式执行JMeter。jmeter -n -t /path/to/your_test.jmx -l /path/to/results.jtl -e -o /path/to/html/report-n: 非GUI模式。-t: 指定测试脚本。-l: 指定结果文件。-e -o: 生成HTML报告。判断测试结果通过分析JTL文件或HTML报告中的错误率在CI脚本中设置阈值。如果错误率超过一定比例如1%则让CI任务失败。可以使用Shell/Python脚本解析JTL文件或者使用JMeter插件提供的性能指标。参数化环境配置使用-J参数在命令行中传递变量给JMeter脚本。例如jmeter -n -t test.jmx -Jhosttest.env.com -Jusers50 -Jduration300在JMeter脚本中通过${__P(host, default_host)}来引用这些属性。这样同一套脚本就可以通过传入不同参数轻松地在开发、测试、预生产环境中运行。从零开始通过代理录制获取原始脚本经过参数化、断言、逻辑控制等步骤进行增强和调试最终形成一个稳定可靠的自动化测试资产并能集成到CI流程中提供持续的质量反馈——这就是用JMeter完成移动APP接口自动化测试的完整闭环。这个过程开始可能有些繁琐但一旦跑通对于后续的回归测试和新功能测试效率提升是巨大的。最重要的是你拥有了一个既能做功能验证又能做性能评估的统一脚本库这是很多其他测试工具难以比拟的优势。
JMeter代理录制移动APP接口测试：从原理到实战完整指南
发布时间：2026/6/18 3:03:00
1. 项目概述为什么选择JMeter代理录制移动APP接口测试如果你是一名测试工程师或者正在从功能测试转向自动化测试面对一个全新的移动APP第一反应是不是有点无从下手特别是当开发文档不全、或者接口数量庞大时手动编写每一个接口的测试脚本工作量巨大且容易出错。这时候“录制与回放”就成了一个快速切入的利器。而JMeter这个老牌的、功能强大的开源工具其内置的HTTP(S) Test Script Recorder代理录制器功能恰好能完美解决这个痛点。简单来说这个项目的核心就是利用JMeter作为“中间人”代理捕获你的手机APP在真实操作过程中发出的所有网络请求主要是HTTP/HTTPS并自动生成可重复执行的测试脚本JMX文件。这相当于给你的测试过程装了一个“行车记录仪”你只管正常使用APP它来负责记录所有“路线”接口请求。之后你可以随时“回放”这段记录来验证接口功能是否正常、性能是否达标或者作为自动化测试套件的基础。为什么是JMeter而不是Postman、Charles或者Fiddler首先JMeter是完全免费且开源的没有使用成本或功能限制。其次它生成的脚本本身就是性能测试脚本录制好的接口用例稍加配置如参数化、断言、逻辑控制器就能直接用于压力测试实现了功能与性能测试的“脚本复用”效率极高。最后JMeter的生态非常丰富支持各种插件扩展能满足复杂的测试场景需求。对于需要兼顾接口自动化与性能测试的团队来说JMeter代理录制是一条非常高效的入门和实战路径。2. 核心思路与工具选型解析2.1 代理录制的工作原理扮演“中间人”要理解这个过程首先得明白“代理”在这里扮演的角色。在标准的网络请求中你的手机APP客户端直接与服务器通信。当我们启用JMeter的代理录制功能时整个数据流就变成了这样配置代理你在手机上设置网络代理将所有的HTTP/HTTPS流量指向运行JMeter的电脑的IP地址和指定端口默认8888。请求拦截当你操作APP时它发出的请求不再直接去往服务器而是先发送到JMeter代理。请求转发与记录JMeter代理接收到请求后会原封不动地将其转发给真正的目标服务器。同时它会将这个请求的详细信息如URL、方法、请求头、请求体捕获下来并按照你预设的格式在JMeter中生成一个对应的HTTP请求采样器。响应返回服务器处理请求后将响应返回给JMeter代理代理再将其传回给你的手机APP。这样APP能正常收到响应你的操作可以继续。同时JMeter也可以选择记录服务器的响应内容。这个过程就像快递代收点快递请求先送到代收点JMeter代理代收点登记快递信息录制脚本后再通知你转发请求给服务器来取件返回响应给APP。整个通信是透明的APP无感知。注意对于HTTPS请求由于涉及加密需要JMeter提供根证书并让手机安装信任才能进行解密和录制。这是录制HTTPS流量时必须处理的一步否则你只能看到一堆加密的数据包。2.2 为什么是JMeter对比其他方案市面上能录制网络请求的工具很多我们简单对比一下Postman虽然也有代理功能但其主要定位是API调试与协作。录制生成的集合Collection更适合手工调试和简单的自动化要转化为性能测试脚本需要额外步骤且大规模并发测试能力不如JMeter。Charles / Fiddler专业的抓包工具录制和调试功能极其强大能提供非常详细的请求/响应分析。但它们生成的会话记录Session通常需要导出为HARHTTP Archive文件再通过转换工具或脚本才能导入到JMeter中流程稍显繁琐。而且它们本身不是性能测试工具。JMeter一站式解决方案。录制直接生成.jmx脚本该脚本既是功能自动化脚本可添加断言进行校验也是性能测试脚本可直接设置线程组进行压测。避免了工具链切换和数据转换的麻烦。对于测试团队而言学习一个工具解决两类问题性价比最高。因此我们的选型思路很明确以快速构建可复用的、兼具功能和性能测试能力的接口测试脚本为目标JMeter的代理录制是当前综合成本最低、效率最高的方案。2.3 环境准备清单在开始动手之前你需要准备好以下环境我将以Windows/MacOS Android手机为例进行说明JMeter运行环境Java JDK 8或11JMeter基于Java开发必须安装JDK。建议安装JDK 8或11LTS长期支持版本并配置好JAVA_HOME环境变量。Apache JMeter 5.x从官网下载最新版本。解压即用无需安装。测试设备一台Android手机或iOS手机用于安装待测APP。本文以Android为例iOS原理类似配置代理的位置在Wi-Fi设置中。确保手机和运行JMeter的电脑在同一个局域网连接同一个Wi-Fi。这是代理能够通信的前提。待测应用程序确保手机上已经安装了你要测试的APP的测试包或线上包。3. JMeter代理录制器详细配置与实操3.1 启动JMeter与创建测试计划首先进入JMeter的解压目录找到bin文件夹。Windows双击jmeter.bat启动。Mac/Linux在终端中执行./jmeter启动。启动后你会看到一个空的测试计划Test Plan。我建议你先进行保存CtrlS或CmdS并命名为一个有意义的名称例如Mobile_APP_Recording.jmx。3.2 添加并配置HTTP(S) Test Script Recorder这是录制的核心控制器。添加录制器在左侧测试计划Test Plan上右键选择Add-Non-Test Elements-HTTP(S) Test Script Recorder。这会在测试计划下创建一个名为“HTTP(S) Test Script Recorder”的元件。创建存放录制的线程组在测试计划上右键选择Add-Threads (Users)-Thread Group。这个线程组将作为录制请求的“容器”。你可以将其重命名为“录制容器”或“APP业务流程”。关联录制器与容器点击刚创建的HTTP(S) Test Script Recorder在右侧面板的Target Controller下拉框中选择我们刚创建的Thread Group。这意味着所有录制到的请求都会自动放入这个线程组中。关键配置详解Port代理端口默认8888。如果此端口被占用如被Charles等工具使用可以改为其他未被占用的端口如8899。记住这个端口号手机配置代理时会用到。HTTPS Domains这里填写你待测APP的主要域名。例如如果你的API都指向api.yourcompany.com就填这个。这有助于JMeter在录制HTTPS流量时正确生成证书。可以填写多个用逗号分隔。Start按钮点击它来启动代理服务器。3.3 设置请求过滤避免录制垃圾请求如果不加过滤你会录制到大量图片、CSS、JS等静态资源请求以及第三方SDK如友盟、广告的请求这些通常不是我们接口测试的重点会干扰脚本的清晰度。点击HTTP(S) Test Script Recorder配置面板中的Request Filtering标签页这里是过滤器的核心。包含模式IncludeURL Patterns to Include这是最常用的过滤方式。根据你的接口URL特征添加正则表达式。例如如果你的后端接口路径都包含/api/v1/那么可以添加一个包含模式.*/api/v1/.*。这表示只录制URL中包含/api/v1/的请求。Content-Type to Include如果你的接口都是RESTful API返回JSON可以在这里添加application/json。这可以过滤掉非JSON的响应如图片。排除模式ExcludeURL Patterns to Exclude用于排除已知的干扰项。例如你可以添加.*\.(js|css|png|jpg|gif|ico)来排除所有常见的静态资源文件请求。实操心得在第一次录制某个APP时我建议先不设置任何过滤完整录制一遍。然后观察录制到的请求列表分析出你真正需要测试的接口的URL模式特征再据此设置包含和排除规则。这样过滤出来的脚本最精准。3.4 处理HTTPS流量安装JMeter证书这是录制能否成功的关键一步。对于HTTP请求跳过此步。对于HTTPS必须操作。启动代理并生成证书在完成上述基本配置后点击Start按钮启动代理。第一次启动时JMeter会在其bin目录下生成一个名为ApacheJMeterTemporaryRootCA.crt的根证书文件。将证书发送到手机并安装你可以通过数据线、邮件、网盘等方式将这个.crt文件传到手机上。Android在手机的文件管理器中找到该证书点击安装。系统会要求你为证书命名如“JMeter Proxy CA”并选择用途选择“VPN和应用”或“WLAN”。安装完成后你需要在手机的“设置” - “安全” - “加密与凭据” - “用户凭据”或“信任的凭据” - “用户”中看到它。iOS过程类似通过邮件或网页打开证书文件进入“设置” - “已下载描述文件”安装并在“设置” - “通用” - “关于本机” - “证书信任设置”中完全信任此根证书。为什么必须安装证书HTTPS通信是加密的手机不信任JMeter这个“中间人”就会拒绝连接。安装JMeter的根证书就是告诉手机“我信任这个代理允许它解密和查看我的HTTPS流量。”这是一个标准的安全操作仅用于测试环境。重要安全提示此证书仅用于内部测试。测试结束后建议在手机上删除此证书不要用于浏览不可信的网站。4. 移动端代理配置与录制过程4.1 手机端代理配置步骤确保你的手机和电脑处于同一Wi-Fi网络下。进入手机的“设置” - “WLAN”。长按当前已连接的Wi-Fi网络选择“修改网络”或“高级选项”。找到“代理”设置项将其从“无”改为“手动”。代理服务器主机名填写你电脑在局域网内的IP地址。在电脑上打开命令行Windowsipconfig查找“无线局域网适配器 WLAN”下的IPv4 地址。Mac/Linuxifconfig或ip addr查找en0或wlan0下的inet地址。代理服务器端口填写你在JMeter中设置的端口默认8888。保存设置。验证代理是否生效此时手机上的所有HTTP(S)流量都会经过你的电脑。你可以在电脑浏览器访问http://ip.cn这类网站查看IP如果显示的是你电脑的IP说明代理成功。或者在JMeter的“查看结果树”监听器中如果开始出现请求也说明配置成功。4.2 开始录制与操作APP清空录制容器在开始前右键点击之前创建的Thread Group录制容器选择Clear或Remove All确保里面是空的。操作APP像正常用户一样打开手机上的待测APP进行你想要测试的业务操作。例如启动APP - 登录 - 浏览首页 - 点击某个商品 - 加入购物车 - 下单。观察JMeter在操作APP的同时观察JMeter。在对应的Thread Group下你会看到HTTP Request采样器一个接一个地自动生成并且按照操作顺序排列。每个采样器都包含了完整的请求信息。停止录制完成所有需要录制的操作后回到JMeter点击HTTP(S) Test Script Recorder上的Stop按钮停止代理录制。关闭手机代理非常重要录制完成后务必回到手机Wi-Fi设置中将代理改回“无”。否则手机无法正常上网。4.3 录制脚本的初步优化与整理录制生成的脚本是“原始”的直接回放可能会遇到问题需要做一些清理和优化删除无用请求手动检查线程组中的请求删除那些明显是静态资源图片、CSS、JS或第三方服务的请求如果之前过滤没生效。重命名采样器默认的采样器名称是请求的URL可读性差。建议根据业务逻辑重命名。例如将POST /api/login重命名为01_用户登录。添加事务控制器为了更清晰地组织业务流可以添加Transaction Controller。例如创建一个名为“用户登录流程”的事务控制器将登录相关的请求如获取验证码、提交登录拖进去。这有助于在生成报告时查看整个事务的耗时。保存脚本及时保存你的.jmx文件。5. 从录制到回放构建可用的自动化测试脚本录制只是拿到了“原材料”回放才是“烹饪”。直接回放原始脚本大概率会失败因为很多请求带有动态参数如Token、时间戳、会话ID。5.1 处理动态参数正则表达式提取器与JSON提取器这是接口自动化测试的核心技能。你需要从先前的请求响应中提取出动态值传递给后续的请求。识别动态参数回放脚本在“查看结果树”中检查失败的请求。通常失败原因是“Token无效”或“参数缺失”。找到是哪个参数需要动态获取。添加后置处理器正则表达式提取器适用于响应体是文本或HTML的情况。在需要提取数据的请求采样器下右键Add-Post Processors-Regular Expression Extractor。Apply to: 通常选Main sample only。Field to check: 选Body。Reference Name: 定义一个变量名如access_token。Regular Expression: 编写正则表达式来匹配和捕获值。例如如果响应是{token: abc123}表达式可以是token: (.?)。Template:$1$表示取第一个捕获组。Match No.:1表示取第一个匹配项。JSON提取器强烈推荐用于JSON响应更简单稳定。在需要提取数据的请求采样器下右键Add-Post Processors-JSON Extractor。Names of created variables: 变量名如access_token。JSON Path expressions: JSON路径表达式如$.data.token。Match No.:1。引用变量在后续需要该动态参数的请求中使用${变量名}的格式来引用。例如在请求头的Authorization字段中填入Bearer ${access_token}或在请求体参数中填入${access_token}。5.2 添加断言验证接口响应是否正确没有断言的测试脚本是没有灵魂的。断言用于自动判断请求是否成功而不仅仅是看服务器是否返回了200状态码。响应断言最常用的断言。在需要断言的请求下右键Add-Assertions-Response Assertion。测试字段可以检查Response Code如等于200、Response Message、Response Headers或者Response Body。模式匹配规则对于响应体常用“包含”或“匹配”规则。例如登录成功后响应体里会有success: true你就可以添加一个模式success: true进行“包含”断言。JSON断言如果响应是JSON用JSON断言更精确。需要安装插件或者使用JSR223断言配合Groovy脚本解析JSON。持续时间断言用于性能测试断言响应时间不应超过某个阈值如2000毫秒。实操心得断言不是越多越好要关注核心业务逻辑。通常对关键的成功/失败状态码、核心业务字段如订单ID、用户ID进行断言即可。过于严格的断言如检查整个响应JSON会导致脚本脆弱一旦接口返回字段顺序或无关字段有变测试就会失败。5.3 参数化让测试数据更灵活如果你需要测试多组数据如用不同用户登录就需要参数化。CSV数据文件设置最常用的参数化方式。添加一个CSV Data Set Config元件在Config Element下。Filename: 指向一个CSV文件如user_data.csv内容可以是username,password作为表头下面多行数据。Variable Names: 填写变量名用逗号分隔如username,password。Delimiter: 分隔符CSV通常是逗号,。Recycle on EOF?: 文件读完是否循环通常性能测试设为True功能测试设为False。Stop thread on EOF?: 文件读完是否停止线程与上一项配合使用。在请求中使用变量在登录请求的用户名和密码参数中使用${username}和${password}。用户定义的变量对于一些全局的、不变的值如服务器域名可以在Test Plan或User Defined Variables配置元件中定义。5.4 组织测试逻辑控制器与定时器逻辑控制器仅一次控制器将只需要执行一次的请求如登录放进去。循环控制器控制一组请求循环执行多次。如果If控制器根据条件决定是否执行其子元件。例如根据上一个请求的响应结果决定是执行成功流程还是失败流程。定时器固定定时器在每个请求后等待固定的时间模拟用户思考时间。高斯随机定时器等待时间随机更贴近真实用户行为。添加了参数化、断言和必要的控制器后你的脚本就从简单的“录制回放”升级为一个具备基本校验能力和数据驱动能力的自动化测试脚本。6. 回放调试与常见问题排查实录即使配置得当第一次回放也常会遇到各种问题。下面是我在实践中总结的常见问题及排查思路。6.1 问题一回放时请求全部失败无响应数据可能原因1手机代理未关闭。这是最常见的原因。录制完成后手机代理仍指向你的电脑但JMeter代理已停止导致手机无法上网。解决立即检查并关闭手机Wi-Fi设置中的手动代理。可能原因2JMeter代理未启动或端口冲突。回放时不需要启动代理。但如果脚本中包含了需要代理的配置错误添加了或者8888端口被其他程序占用会导致JMeter自身运行异常。解决确保回放时HTTP(S) Test Script Recorder是停止状态。用netstat -ano | findstr :8888(Windows) 或lsof -i :8888(Mac/Linux) 检查端口占用。可能原因3IP/域名不可达。检查脚本中请求的服务器地址是否正确。录制时用的是手机的实时网络如果服务器是内网地址如192.168.1.100而你的电脑不在同一内网回放自然会失败。解决使用User Defined Variables定义一个主机变量方便切换测试环境如${host}在测试环境指向内网IP在本地指向localhost。6.2 问题二登录后接口返回“Token无效”或“未授权”可能原因Token未成功提取或传递。检查提取器在登录请求下确认JSON Extractor或Regular Expression Extractor配置正确。在“查看结果树”中查看登录请求的响应体确认你要提取的字段存在且路径正确。调试变量值添加一个Debug Sampler和View Results Tree放在提取器后面回放后查看Debug Sampler的响应里面会列出所有JMeter变量的当前值检查你的Token变量如${access_token}是否有值。检查传递过程确认在需要Token的请求中正确引用了变量。例如在请求头的Authorization字段应该是Bearer ${access_token}注意拼写和空格。检查请求采样器的Parameters或Body Data中引用变量的语法是否正确。作用域问题默认提取的变量作用域限于当前线程组。如果Token需要在多个线程组间共享需要将其设置为全局属性。可以使用BeanShell PostProcessor或JSR223 PostProcessor执行props.put(global_token, vars.get(access_token))来存入全局属性在其他线程组用${__P(global_token)}来引用。6.3 问题三回放时出现大量“503 Service Unavailable”或连接超时可能原因1服务器压力过大。如果你用JMeter进行高并发回放压测而服务器处理能力不足就会返回503。解决降低并发线程数或检查服务器状态。可能原因2JMeter自身端口耗尽。这是JMeter做压测时的一个经典问题。在高并发下JMeter作为客户端会占用大量本地端口来与服务端建立连接如果端口快速耗尽就会报错。解决增加JMeter运行机器的本地端口范围需修改系统设置如Windows注册表。在JMeter的bin/jmeter.properties配置文件中设置httpclient4.time_to_live为一个较低的值如30000单位毫秒让连接更快关闭和释放。使用TCPMon或Connection Close等控制器或者在HTTP请求高级设置中勾选Use KeepAlive的相反选项根据实际情况。可能原因3缺少必要的请求头。有些服务器会检查User-Agent,Referer,Content-Type等头信息。录制时这些头被完整记录但如果你在脚本中误删了或者使用HTTP Request Defaults覆盖了可能导致服务器拒绝。解决对比录制和回放的请求头在“查看结果树”的请求标签页确保关键头信息一致。6.4 问题四响应断言失败但业务看起来是成功的可能原因断言模式匹配过于严格或响应数据动态变化。例如断言响应体包含orderId: 12345但每次生成的订单ID都是不同的。解决将断言改为检查模式是否存在而不是值完全相等。例如使用正则表达式orderId: \d来断言存在一个数字订单ID或者断言包含status: SUCCESS这个状态字段。响应中可能包含时间戳等每次都会变的信息。解决在断言前使用后置处理器如JSR223 PostProcessor配合Groovy脚本将响应中的动态部分如时间戳替换为固定值或通配符然后再进行断言。或者使用更灵活的JSON断言插件通过JSON Path判断某个字段是否存在而非其具体值。6.5 问题排查通用流程当脚本回放出问题时建议按照以下步骤排查可以解决90%以上的问题看日志首先查看JMeter GUI界面下方的日志区域或者运行命令行时控制台的输出看是否有明显的错误信息。用“查看结果树”这是最强大的调试工具。添加一个View Results Tree监听器回放脚本。绿色对勾通常表示网络请求成功状态码为2xx/3xx但不意味着业务成功。红色叉叉表示请求失败网络错误、超时、4xx/5xx状态码。检查请求点击失败的请求查看“请求”标签页确认发送的URL、头信息、参数/体是否正确特别是动态变量是否被正确替换显示为实际值而不是${var}。检查响应点击请求查看“响应数据”标签页这里包含了服务器返回的真实内容。这是判断业务逻辑是否成功的唯一依据。根据响应内容去调整你的提取器或断言。简化与隔离如果整个脚本复杂难以定位。可以新建一个测试计划只放入出问题的单个请求并手动填写参数看是否能成功。如果能再逐步将变量、提取器等加回去定位是哪个环节引入的问题。使用Debug Sampler在怀疑的环节前后添加Debug Sampler查看变量的状态变化。7. 脚本增强与持续集成初探一个健壮的自动化测试脚本不仅要能跑通还要易于维护和集成。7.1 添加监听器生成报告“查看结果树”在调试时很好用但会消耗大量内存不适合在正式运行或无头模式命令行下使用。我们需要更轻量或更聚合的报告。聚合报告Summary Report或Aggregate Report。提供基本的统计信息请求数、平均响应时间、错误率、吞吐量等。适合性能测试结果分析。断言结果Assertion Results。专门显示哪些断言通过了哪些失败了失败的原因是什么。生成HTML报告这是更专业的方式。JMeter支持生成美观的HTML报告。首先在运行测试时使用-l参数指定一个JTL结果文件jmeter -n -t your_test.jmx -l result.jtl然后使用-g参数根据JTL文件生成HTML报告jmeter -g result.jtl -o ./report_folder生成的report_folder里就是一个完整的HTML测试报告包含图表和详细信息非常适合归档和分享。7.2 将脚本集成到CI/CD流水线自动化测试的最终价值在于持续反馈。你可以将JMeter脚本集成到Jenkins、GitLab CI等工具中。命令行执行CI流水线的核心是使用命令行非GUI模式执行JMeter。jmeter -n -t /path/to/your_test.jmx -l /path/to/results.jtl -e -o /path/to/html/report-n: 非GUI模式。-t: 指定测试脚本。-l: 指定结果文件。-e -o: 生成HTML报告。判断测试结果通过分析JTL文件或HTML报告中的错误率在CI脚本中设置阈值。如果错误率超过一定比例如1%则让CI任务失败。可以使用Shell/Python脚本解析JTL文件或者使用JMeter插件提供的性能指标。参数化环境配置使用-J参数在命令行中传递变量给JMeter脚本。例如jmeter -n -t test.jmx -Jhosttest.env.com -Jusers50 -Jduration300在JMeter脚本中通过${__P(host, default_host)}来引用这些属性。这样同一套脚本就可以通过传入不同参数轻松地在开发、测试、预生产环境中运行。从零开始通过代理录制获取原始脚本经过参数化、断言、逻辑控制等步骤进行增强和调试最终形成一个稳定可靠的自动化测试资产并能集成到CI流程中提供持续的质量反馈——这就是用JMeter完成移动APP接口自动化测试的完整闭环。这个过程开始可能有些繁琐但一旦跑通对于后续的回归测试和新功能测试效率提升是巨大的。最重要的是你拥有了一个既能做功能验证又能做性能评估的统一脚本库这是很多其他测试工具难以比拟的优势。
)
![[实战] 2026年图纸特性提取AI技术深度解析：从CAD/PDF到数字化检验计划](http://pic.xiahunao.cn/yaotu/[实战] 2026年图纸特性提取AI技术深度解析：从CAD/PDF到数字化检验计划)
