先说明一个判断JMeter 这类工具网上教程非常多但大部分要么只讲界面怎么点要么上来就扔一堆压测报告术语对刚接触接口测试的人很不友好。这篇主要面向两类读者一是刚入门测试或开发、想快速把接口测试跑起来的新手二是已经在用 Postman 等工具但想更进一步做批量回归和简单性能验证的工程师。内容主线是 AI 辅助下的 JMeter 接口测试从工具安装、环境准备、第一个接口脚本到登录鉴权、上传文件、批量任务再到常见报错排查和压测结果的初步判断尽量把每一步为什么这么做讲清楚。个人的建议是不要一开始就盯着“能不能压测”“并发数多少”不放先学会用 JMeter 把一条接口请求完整跑通再谈性能和批量的复杂度。否则后面报错时你根本分不清是脚本问题、参数问题还是环境问题。1. 先理解 JMeter 解决什么问题再决定要不要学1.1 接口测试在做什么接口测试的核心不是点页面按钮而是直接请求后端服务验证返回结果是否符合预期。比如登录接口、查询列表接口、提交订单接口都是前端和后端之间的数据通道。接口测试要确认的是请求参数正确、返回结构完整、状态码合理、数据落库准确、异常情况能兜住。这类测试比单纯的功能点击更容易自动化。只要你有一份接口文档或抓包数据就能构造请求、检查结果不需要等待页面加载、不需要处理复杂的前端交互。1.2 JMeter 和 Postman、Apifox 的差异很多初学者会问已经有 Postman 了为什么还要学 JMeter它们定位不一样。Postman、Apifox 这类工具更偏接口调试和日常联调。你手工点几下看响应非常方便。但它们做批量数据驱动、多用户并发、复杂断言和长时间稳定性验证时要么功能弱要么是收费功能。JMeter 是开源工具定位是性能测试和接口测试一体。它既可以发单条请求也可以模拟多用户并发访问还能通过 CSV 文件批量读取测试数据。对于服务端接口测试这是很常见的刚需场景验证接口在多个账号、多条数据下是否稳定验证接口在指定并发下响应时间和错误率如何。如果只是临时调试一个接口不需要学 JMeter用 Postman 更快。但如果你要跑回归、批量验证、做压力测试JMeter 性价比较高。1.3 AI 在 JMeter 接口测试里能干什么稍微提一下 AI 的辅助价值这也是标题里“AI”的实际落点。AI 不会替你把 JMeter 完全配置好但可以在这些环节明显提速根据接口文档生成初始测试数据。根据响应结果快速判断异常点。辅助编写正则表达式和 JSON 提取器中的表达式。分析 JMeter 日志或压测报告中的潜在瓶颈。把大批量参数整理成 JMeter 识别的 CSV 格式。这些能力我们在后文会穿插说明。记住一个原则AI 是辅助不是替你决策。最终判断请求格式是否正确、断言是否符合业务逻辑、性能指标能否接受都要靠人来确认。2. 环境准备JDK、JMeter 版本和系统要求2.1 JMeter 运行依赖 JDK先装 JDKJMeter 是基于 Java 的工具所以第一步不是下载 JMeter而是确认你有没有可用的 Java 环境。这里最常见的坑就是电脑上装了很多 Java 版本但 JMeter 使用的是系统 PATH 里那个版本不匹配就直接启动失败。建议使用 JDK 8 或 JDK 11。JMeter 5.4 以后版本对 JDK 8 仍然支持较好JDK 11 更稳。如果你下载的是最新 JMeter 5.6 左右建议直接 JDK 11 或 17。JDK 版本过低会提示类似 UnsupportedClassVersionError那就是 JMeter 版本和 Java 版本不匹配。我一般建议新手直接装 JDK 11避免版本太新带来兼容问题也避免太老导致 JMeter 启动受限。装完之后在命令行检查java -version javac -version如果命令行输出里能看到版本号说明 Java 环境没问题。如果提示“不是内部或外部命令”那就要先配置环境变量 JAVA_HOME 和 PATH。这里不要偷懒因为后面 JMeter 启动脚本会依赖 JAVA_HOME。2.2 JMeter 下载与目录结构JMeter 是 Apache 开源项目官网下载页会提供两个压缩包一个是源码包一个是二进制包。我们只需要二进制包。下载时注意文件名里带有 bin 字样的是可运行版本source 是源码不要下错。下载完成后解压到一个固定目录。这里不建议放在 C 盘带空格的路径下比如 C:\Program Files\apache-jmeter因为某些脚本和插件可能对空格路径处理不友好。更建议放在类似 D:\tools\apache-jmeter-5.6.3 这种纯英文路径。解压后目录结构里最关键的是 bin 文件夹。里面有启动脚本 jmeter.batWindows 用和 jmeter.shmacOS/Linux 用。bin 之外还有 lib 目录用来放插件 jar 包。如果你想装第三方插件比如 JSON 断言插件、性能监控插件一般就是下载 jar 包放到 lib/ext 目录然后重启 JMeter。2.3 启动方式和界面模式Windows 下双击 jmeter.bat 就能启动图形界面。macOS/Linux 下在终端切到 bin 目录执行sh jmeter.sh启动后你会看到一个带菜单栏的图形界面。如果不小心打开了后台黑窗口不要关那是 JMeter 的运行进程关闭它界面也会退出。JMeter 有两种常用模式GUI 模式和命令行模式。GUI 模式适合编辑脚本、调试单个请求。真正跑压测、跑批量任务时更推荐命令行模式因为 GUI 会占用额外资源影响测试结果准确性。后面实战部分会细说。3. 第一个接口测试脚本从零开始跑通登录请求3.1 创建测试计划核心逻辑打开 JMeter 后默认会有一个测试计划。你需要往里添加的关键组件是线程组定义模拟多少用户、循环多少次。HTTP 请求取样器定义接口地址、方法、参数。查看结果树查看每条请求的响应结果。HTTP 信息头管理器如果需要传 token、Content-Type 等请求头。很多新手会一次性把组件全加满然后直接运行结果一报错就不知道问题出在哪。我更建议先只加一个线程组和一个 HTTP 请求跑通第一条请求后再逐步增加断言、关联和批量数据。3.2 拿一个真实接口做示例这里用登录接口举例。假设接口信息如下请求地址https://api.example.com/api/login请求方法POST请求头Content-Type: application/json请求体{username:admin,password:123456}在线程组里添加 HTTP 请求取样器填写协议、服务器名称或 IP、端口、方法、路径。然后在“消息体数据”区域粘贴 JSON 请求体。添加信息头管理器在该组件中增加一组键值对Content-Type 为 application/json。如果不加这个请求头后端可能无法正确解析 JSON 格式的请求体。添加查看结果树后点击运行按钮。如果配置正确查看结果树里应该出现绿色成功条目响应内容就是后端返回的数据。这里注意成功不代表接口业务成功。如果后端返回 200但响应内容里 code 字段是 500说明接口仍可能报错只是 HTTP 层没断。3.3 断言怎么写才有效接口测试不能只看状态码是 200。更常见做法是用响应断言检查响应正文中是否包含某个关键字段。比如登录成功后后端会返回 token 或 userId。你就可以添加一个响应断言模式匹配填“success”或自定义业务码。这样当接口返回异常但状态码仍然是 200 时断言会标记为失败。实操建议先跑一次请求把响应内容复制出来观察里面哪些字段是稳定的。拿一个稳定的业务字段做断言不要拿时间戳、随机数这类变化值做断言否则测试会时好时坏。4. 接口关联与登录态处理用一个接口的返回值作为下一个接口的输入4.1 为什么要做关联很多接口不是在登录那一步就结束。比如你登录后拿到 token然后查询用户信息列表查询接口需要带上这个 token。如果你在 JMeter 里两次请求都写死 token每次登录 token 变了脚本就必须手动改根本没法批量跑。解决办法是让 JMeter 自动从登录接口的响应里提取 token然后传给下一个请求。这个过程叫关联。4.2 JSON 提取器的使用方式如果登录接口返回 JSON 格式比如{code:0,data:{token:eyJhbGciOiJIUzI1NiJ9,userId:12345}}你可以在登录请求上右键添加后置处理器 - JSON 提取器。配置变量名称tokenJSON 表达式$.data.token默认值NOT_FOUND然后在后续 HTTP 请求的信息头管理器里把 token 的值写成 ${token}。运行时 JMeter 会自动替换成提取到的真实值。这里经常出现的坑直接在 HTTP 请求里引用变量但变量作用域不对。JMeter 的变量是跟随线程组的如果你的后续请求在不同线程组里默认会取不到需要额外配置跨线程组传参。新手阶段建议先放在同一个线程组里避免作用域问题干扰排查。4.3 AI 辅助生成 JSON 提取表达式如果接口返回结构很复杂嵌套很多层手工写 JSON 表达式容易出错。这时候可以借助 AI 工具做两件事把接口响应 JSON 粘贴给 AI请它找出某个具体字段的 JSONPath 表达式。让 AI 解释响应结构里层级关系方便你确认提取的是不是目标字段。但要注意AI 生成的表达式不一定能直接匹配真实返回字段。如果字段名拼写错误或响应结构有嵌套数组AI 可能提取不到。实际使用时先在查看结果树里确认响应结构再让 AI 生成表达式最后用 JMeter 调试采样器验证提取结果。5. 接口测试项目实战用户管理接口回归测试5.1 项目场景设计假设现在有一个用户管理系统需要做接口回归测试。核心接口包括登录接口获取 token。用户列表接口分页查询用户需要携带 token。创建用户接口新增用户需要携带 token。上传头像接口文件上传需要携带 token。导出用户数据接口下载文件需要处理响应结果。这样一组接口可以组成一个完整的回归用例集。相比单个接口更贴近实际项目。5.2 在 JMeter 中组织脚本结构建议按模块建线程组而不是把所有接口塞进一个线程组。比如登录放“登录线程组”用户管理放“用户管理线程组”。登录线程组的用户数和循环次数设为 1保证只登录一次提取 token 后给后续接口使用。用户管理线程组里可以添加多个 HTTP 请求分别对应查询列表、创建用户、上传头像、导出数据。每个请求都从信息头里带 ${token}。如果要在创建用户接口里批量新增多个用户可以通过 CSV 数据文件配置来驱动。准备一个 user_data.csv 文件里面几列数据分别是用户名、手机号、邮箱。CSV 数据文件设置中定义变量名称HTTP 请求的参数值写 ${username} 这类引用即可。5.3 文件上传接口怎么测JMeter 测文件上传接口也不复杂。在 HTTP 请求取样器里方法选择 POST勾选“使用 multipart/form-data”然后在下方文件上传区域添加文件名、参数名、MIME 类型。这里最容易踩坑的是参数名与后端约定不一致后端接口文档里写的是 file而你填成 uploadFile就会收到文件字段缺失的报错。另一个坑是文件路径。JMeter 不会自动读取相对路径下的文件所以最好填写绝对路径比如 D:\testdata\avatar.jpg。如果使用相对路径要以 JMeter 的启动目录为基准很容易定位错路径。5.4 导出接口的响应处理导出接口返回的通常不是 JSON而是二进制文件流。此时响应断言就不能按包含文本来写。你可以通过“保存响应到文件”监听器把响应内容直接存成一个文件然后去检查文件大小和内容完整性。实际项目里导出接口的测试重点不是返回 JSON而是状态码是否为 200。响应头中的 Content-Type 是否为文件流类型。保存下来的文件能否正常打开。文件内容是否包含预期数据。如果文件下载不完整多半是响应超时时间设置太短或者服务端生成本身慢。这时候可以调整 HTTP 请求里的超时时间一般建议连接超时 5000ms响应超时 30000ms 起步具体看接口真实耗时。6. AI 在接口测试中的实用辅助方法6.1 用 AI 生成测试数据接口测试往往需要大量测试数据。比如创建用户接口需要用户名、手机号、邮箱、年龄等字段手工造 100 条数据很枯燥。这时候可以借助 AI 生成 CSV 样例。可以把字段格式要求告诉 AI比如“帮我生成 100 条测试数据包含字段 username、phone、email用户名不能重复手机号要符合 1 开头 11 位”。AI 能快速给出一份 CSV 内容你再导入 JMeter 使用。需要确认的是AI 生成的数据不一定符合你的接口字段约束。比如接口要求 user_type 只能是 1 或 2AI 可能生成 3。所以使用前要按接口文档核对字段类型、长度、枚举值、边界值。6.2 用 AI 辅助分析响应结果当接口返回结构复杂或者报错信息不直观时把响应内容交给 AI 做初步解读是可行的。比如返回一个很长的堆栈异常AI 能快速指出可能的空指针位置或参数类型不匹配。这对新手尤其友好。但这一类辅助只能作为线索。最终判断还是看源码和日志。因为 AI 看到的是片段看不到完整上下文容易给出泛化结论。6.3 用 AI 帮助生成 JMeter 脚本配置说明如果你刚接触某些 JMeter 组件比如正则表达式提取器、BeanShell 断言不知道配置项是什么意思可以把界面截图或配置项名称让 AI 解释一下。AI 在解释通用概念方面比较擅长能节省不少搜索时间。更推荐的做法是先把官方文档里的参数说明阅读一遍再用 AI 补充案例。不要完全依赖 AI 做脚本生成因为 JMeter 的组件关联、变量作用域和线程组逻辑AI 目前还容易给出表面正确但实际不完整的设计。6.4 用 AI 优化测试用例设计对一个接口做接口测试时除了正例请求还要考虑异常场景。AI 可以帮助列出一份常见的接口测试用例清单必填参数缺失。参数类型错误。参数超过边界长度。未携带 token 访问需鉴权接口。携带过期 token 访问。文件上传大小超限。分页参数为负数。非法 JSON 请求体。这份清单可以当作 JMeter 脚本里多个测试用例的来源。但具体哪些跑、哪些不跑要结合项目时间、接口重要性和风险等级来判断不是越多越好。7. 从单任务到批量CSV 数据驱动与并发场景7.1 CSV 数据文件的基本用法批量接口测试最常见的方式是数据驱动。新建一份 CSV 文件形如username,mobile zhangsan,13800000001 lisi,13800000002 wangwu,13800000003在 JMeter 线程组中添加配置元件 - CSV 数据文件设置。配置项里填写 CSV 文件路径、变量名称、分隔符。之后 HTTP 请求参数值可以直接引用 ${username}、${mobile}。这里有几个需要留意的细节文件编码建议使用 UTF-8否则中文参数可能乱码。CSV 中不要有额外的空行或格式错误否则 JMeter 可能读成错误数据。如果文件读取到末尾默认是停止线程还是重新循环取决于“共享模式”和“遇到文件结束符”的配置。初学者建议把“遇到文件结束符”设为停止线程避免重复使用同一行数据影响测试预期。7.2 循环次数和线程数怎么设线程数表示同时有几个用户在执行脚本。循环次数表示每个线程执行多少遍。只做接口回归时可以设置线程数为 1循环次数等于 CSV 数据条数。这样按顺序批量跑数据适合检查功能正确性。如果要做简单的压力测试可以把线程数设成 50 或 100循环次数设成 10。这时候 JMeter 会模拟多用户并发重复请求。但要注意的是本地脚本运行时会占用本地资源线程数越大你机器的 CPU 和内存消耗越高测试结果不一定能代表服务端真实性能。7.3 定时器的作用真实用户不会像机器人一样不停发请求。在压测场景里通常会添加“常数吞吐量定时器”或“固定定时器”控制请求发送频率让测试更接近真实用户行为。做接口功能测试时可以不加定时器。但做性能测试时如果不加定时器瞬间高并发可能直接打爆服务端导致结果看起来全部超时但你分不清是工具压力过大还是服务端本身性能不足。我建议先在低并发、低频次下观察接口正常响应时间再逐步增加压力。7.4 命令行模式批量运行图形界面跑批量任务不是不行但长时间运行时 GUI 会增加内存和 CPU 开销。更稳妥的方式是命令行模式jmeter -n -t test_plan.jmx -l result.jtl -e -o report_dir参数说明-n 表示非图形化模式。-t 指定测试计划文件。-l 指定结果文件路径。-e 表示生成 HTML 报告。-o 指定报告输出目录。运行前建议先确认 output 目录不存在或者为空否则 JMeter 可能提示目录已存在。运行过程中打开命令行窗口不要关闭结束后再查看 result.jtl 和 HTML 报告。如果测试脚本里使用了 CSV 数据文件建议把 CSV 路径写为绝对路径避免命令行模式下相对路径定位失败。8. 结果怎么看响应时间、错误率、吞吐量的判断标准8.1 聚合报告里的核心指标运行完脚本后添加一个聚合报告监听器会看到这些常用指标指标含义初步判断标准Samples请求总次数等于线程数乘以循环次数乘以请求数Average平均响应时间越小越好按接口复杂度差异很大Min最小响应时间表示最快一次请求耗时Max最大响应时间和平均差太多说明存在慢请求Error%错误率功能回归应为 0压测按业务要求判断Throughput吞吐量每分钟处理请求数越高越好新手最容易盯着 Average 看其实更应该在 Max 和 Error% 上多留意。如果 Max 是 Average 的好几倍说明某些用户请求很慢存在尾部延迟问题。这种情况在压测中比平均响应时间更有排查价值。8.2 查看结果树和断言结果功能测试阶段主要靠查看结果树和断言结果。查看结果树里可以看到每个请求的请求头、请求体、响应头、响应体。断言结果里会明确显示哪条断言失败失败原因是什么。断言失败不一定是接口报错也可能是你的断言模式写得不准确。比如后端返回英文 success你断言成成功就会失败。所以在断言之前建议先看一眼真实响应内容再确定匹配模式。8.3 报告里的响应时间分布最新版本的 JMeter 能生成 HTML 报告里面有 APDEX 指标和响应时间分布图。APDEX 可以理解为一个满意度指数一般超过 0.9 算不错。如果你不想分析太多数据就看两个点错误率是否在可接受范围。90% 和 99% 响应时间是否符合预期。如果一个接口 90% 请求在 200ms 内返回但 99% 请求要 3 秒说明仍然有一部分用户会明显感受到卡顿。此时不要只看平均值要把超长耗时请求的日志拉出来分析。9. 常见错误与排查链路9.1 请求成功但响应不是预期数据这是非常常见的问题接口返回 200但响应里的 code 是错误码或者返回了空列表。这种问题先不要怀疑 JMeter 配置而是先确认请求参数是不是和接口文档一致。请求头有没有缺少 Content-Type、Authorization。是否没有传递登录态 token。是否用错了请求方法。建议在查看结果树中查看请求体确认 JMeter 实际发送的内容是不是你预期发送的内容。很多时候是参数名写错或者多余了一个空格。9.2 响应超时或无响应如果单个请求都能正常返回但批量或压测时大量超时优先检查服务端配置的连接池大小和超时时间。本地线程数是否设置过大。网络带宽是否成为瓶颈。是否有防火墙或网关拦截了高频请求。压测时出现超时不能直接下结论说服务端不行。要结合服务端 CPU、内存、连接数逐层排查必要时在服务端抓包或查看访问日志。9.3 变量提取和使用失败JSON 提取器配置正确但后续请求中变量一直是 NOT_FOUND常见原因有JSONPath 表达式写错。响应内容不是标准 JSON。变量作用域不对。后续请求执行顺序不对。解决方法是先用调试取样器查看变量值。右键添加取样器 - JSR223 取样器或调试取样器运行后在查看结果树里找到 Debug Sampler 的响应内容确认变量是否成功提取。这样能快速定位是提取环节还是使用环节的问题。9.4 中文乱码接口返回中文乱码一般不是接口问题而是 JMeter 的默认编码和解码方式不对。处理办法如果请求返回的是 UTF-8在 HTTP 请求取样器里设置内容编码为 UTF-8。如果响应内容乱码可以在查看结果树中调整编码或在 bin/jmeter.properties 里找到 sampleresult.default.encoding 修改默认编码。CSV 文件里的中文乱码则确认文件本身是 UTF-8 编码而不是 ANSI。9.5 端口或证书问题HTTPS 接口有时会提示证书校验失败。JMeter 有自带的证书设置也可以在 HTTP 请求取样器里禁用证书校验或者在 JMeter 选项中导入证书。实际项目里测试环境大多是自签名证书所以禁用校验是很常见的做法。如果在另一台机器上有“端口已被占用”的提示先关掉占用端口的进程或修改 JMeter 的远程通信端口设置。注意这个一般不是 JMeter 启动失败的主因更多是代理端口冲突。10. 如何把 JMeter 脚本放上持续集成10.1 使用 Maven 或 Jenkins 的可行思路接口测试脚本不仅要能手动跑更理想的是在每次代码提交后自动执行。JMeter 本身是命令行工具所以集成到 Jenkins 很自然。一个常用思路是用 Jenkins 服务器上的 JMeter 路径通过命令行参数运行 .jmx 测试计划然后收集 JTL 报告和 HTML 报告。Jenkins 主机上安装 JMeter配置 job 时构建步骤选择“执行 shell”或“执行 Windows 批处理命令”填入命令即可。如果你用的是 Maven也可以通过 jmeter-maven-plugin 插件来管理 JMeter 脚本和测试结果。这个插件适合已经有 Maven 工程经验的人新手可以先不碰等手工脚本稳定后再考虑。10.2 脚本参数化在集成测试中接口地址、用户名、密码这些配置不应该写死在 JMeter 脚本里否则每个环境都要改脚本。更推荐两种方式使用 JMeter 的“用户定义的变量”组件在脚本顶部定义环境相关参数。命令行运行时通过 -J 参数传入属性。比如运行时执行jmeter -n -t api_test.jmx -Japi_hosttest.api.example.com -Japi_port8080脚本里用 ${__P(api_host)} 读取。这样同一份脚本可以跑测试环境、预发布环境只需切换启动参数。10.3 建议的测试频率如果接口回归集比较长比如几百个用例不是每次提交都适合全量跑。前期可以分成冒烟集和全量回归集。冒烟集只覆盖核心链路登录、获取列表、创建资源。全量回归可以安排在每晚定时任务。压测任务更不建议每次都跑。压测会占用服务端资源可能影响正常业务。一般是在上线前、大促前、代码改动涉及性能瓶颈模块时再跑。平时只需要保持功能回归脚本稳定通过即可。11. 提升脚本复用性和可维护性的一些习惯11.1 合理拆分 JMX 文件一个大测试计划里塞了所有接口后期维护会非常痛苦。建议把公共组件抽出来比如共用 HTTP 请求头、登录逻辑、公共变量。JMeter 支持类似模块化的设计吗不完全支持但可以通过“测试片段”或者多个测试计划引用的方式实现。对于团队协作项目更简单的方法是约定好命名规范。比如所有需要登录的接口请求统一通过变量引用 token不在请求里直接写死。CSV 文件名、JMX 文件名都按业务模块命名不要叫 test1、test2。11.2 记录脚本变更接口测试脚本会被接口改动频繁影响。接口字段变了测试脚本也要同步。建议在测试计划注释中记录脚本基于哪个接口文档版本、修改时间、修改人、修改内容。这不是 JMeter 的功能但能极大减少后续排查脚本的时间。11.3 不要过度依赖录制脚本JMeter 支持 HTTP 代理服务器录制就是你用浏览器操作一遍JMeter 自动生成请求。这个方法适合快速抓取接口但生成的脚本通常包含大量静态资源的请求需要过滤。我更推荐手动构造接口请求或者借助浏览器开发者工具抓取请求信息然后在 JMeter 里手动配置。这样你对每个请求的意图很清楚后续维护起来也更可控。11.4 前后端联调场景下的 JMeter 用法接口测试不仅可以在后端完成后做。前后端并行开发时后端接口文档先产出你可以直接根据文档在 JMeter 里构造请求提前验证参数格式和校验规则。等后端代码部署后再执行一遍脚本验证实际实现是否和文档一致。这种情况下JMeter 更像一个接口规范验证器。它能帮你发现请求参数写的和文档一样但接口返回参数缺失或者文档说字段是字符串实际返回成数字等兼容性问题。12. 一点务实建议循序渐进别被工具绑架接口测试最容易走入的误区是把工具能力当成了测试能力。学会 JMeter 的界面和组件只占一小部分真正难的是设计接口用例、判断结果是否符合业务语义、分析性能指标的合理性。如果你刚开始可以按这个顺序推进先用 JMeter 跑通一个 GET 请求和一个 POST 请求。学会使用查看结果树和响应断言。做一个登录接口和后续查询接口的关联。用一个 CSV 文件驱动批量数据。最后再研究线程组并发和命令行压测。关于 AI 的使用也不必过度神话。AI 能帮你生成数据、解释报错、组织想法但无法替代你对接口业务逻辑的理解。保持必要的怀疑把 AI 给的方案在真实环境里验证一遍再放进正式脚本。这个问题踩过几次之后你会发现接口测试脚本报错大多数不是 JMeter 本身有问题也不是 AI 写错了配置而是你手里没有足够清楚的输入接口字段、返回结构、环境地址、鉴权方式。这几项确认清楚了JMeter 的使用会顺畅很多。