1. 项目概述为什么“用户定义的变量”是JMeter脚本的灵魂如果你刚开始接触JMeter可能会觉得它就是个“点按钮”的工具添加线程组、加个HTTP请求、填上URL然后开跑。但当你试图模拟一个真实的用户登录、浏览商品、下单支付这样的流程时很快就会撞上第一堵墙每个用户的用户名、密码、商品ID总不能都一样吧这时候“用户定义的变量”就不再是一个可选项而是构建任何有实际意义性能测试脚本的基石。简单来说用户定义的变量就是你在JMeter里设置的“全局参数池”。它允许你将那些在脚本中反复出现、或者需要动态变化的值比如服务器地址、端口、用户凭证、查询参数集中管理起来。想象一下你要测试开发、测试、生产三套环境难道要复制三份脚本然后手动一个个去改里面的IP地址吗那太原始了。正确的做法是在一个地方定义变量${host}然后在所有HTTP请求的“服务器名称或IP”字段里都引用这个${host}。切换环境时你只需要改这一个变量的值整个脚本就自动适配了。这不仅仅是方便更是维护性和可靠性的保障。没有它你的脚本会充斥着“硬编码”脆弱且难以协作。几乎所有搜索“jmeter使用教程”、“jmeter压力测试步骤”的新手在迈过第一个简单示例后紧接着要攻克的核心技能就是它。接下来我会带你从零开始彻底搞懂这个功能并分享一些官方教程里很少提及的实战技巧和深坑。2. 核心概念与配置界面全解析2.1 变量、引用与作用域你必须理清的三个关键在深入配置之前我们必须先建立正确的认知模型。JMeter中的“用户定义的变量”涉及三个核心概念理解错了后面会处处碰壁。1. 变量Variable 这就是你定义的一个“名字-值”对。例如你可以定义一个变量名为api_host值为api.yourdomain.com。变量名最好做到见名知义使用小写字母和下划线是常见的约定。2. 引用Reference 定义变量不是目的使用它才是。在JMeter中你通过${变量名}的语法来引用一个变量的值。比如在HTTP请求的“路径”字段里填写/v1/user/${user_id}/profileJMeter在执行时就会用变量user_id的实际值替换掉${user_id}。3. 作用域Scope 这是最容易混淆的地方。JMeter的配置元件包括“用户定义的变量”有其作用范围。线程组级别如果你把“用户定义的变量”放在某个线程组下面那么这个变量只对这个线程组内的所有Sampler如HTTP请求可见。其他线程组无法使用它。测试计划级别如果你把它放在测试计划的根节点下和线程组平级那么它就是全局变量对所有线程组都可见。执行顺序JMeter元素是按顺序执行的。同一个作用域内“用户定义的变量”会在启动时或循环开始时被初始化一次。这意味着在测试运行过程中你无法通过“用户定义的变量”元件来更新一个已定义变量的值。如果你想实现动态变化比如每次循环用一个新用户需要用到“CSV数据文件设置”或“函数助手”。注意很多新手会误以为在运行时修改“用户定义的变量”元件的值能生效实际上不行。它是一个“初始化”元件不是“运行时更新”元件。2.2 配置元件添加与参数设置详解现在我们动手添加一个“用户定义的变量”。添加配置元件在JMeter GUI中右键点击你的测试计划或者某个线程组 - 选择“添加” - “配置元件” - “用户定义的变量”。理解界面添加后你会看到一个简单的表格界面。主要包含两列“名称”和“值”。你可以点击“添加”按钮来新增一行定义一对变量。填写示例让我们定义一个最常用的基础变量。名称server_protocol值https名称server_host值api.example.com名称server_port值443名称api_version值v2引用变量现在在一个HTTP请求采样器中你可以这样配置协议${server_protocol}服务器名称或IP${server_host}端口号${server_port}路径/${api_version}/login当JMeter执行时这个请求就会指向https://api.example.com:443/v2/login。实操心得我强烈建议即使你暂时只测一个环境也把协议、主机、端口这些基础信息变量化。这能培养良好的脚本习惯。未来某天需要切换环境时你会感谢现在的自己。2.3 与“用户参数”的区别静态初始化 vs 动态每线程这是另一个高频困惑点。在配置元件里还有一个叫“用户参数”的元件。它们界面相似但行为天差地别。特性用户定义的变量用户参数初始化时机测试/线程组启动时仅一次。每次线程迭代开始时都可以重新取值。是否支持多用户数据不支持。一套变量值所有线程共享。支持。可以为每个“用户”线程设置不同的变量值。主要用途定义静态的、全局的配置参数如主机名、环境标志。模拟不同用户的不同数据如用户名、用户ID尤其在与“线程数”配合模拟多用户时。动态更新不支持在运行中更新。支持在每次迭代时更新如果勾选了“每次迭代更新一次”。如何选择如果你的值在整个测试运行期间不变比如服务器地址、应用版本号用用户定义的变量。如果你的值需要每个虚拟用户不同或者同一个用户每次循环都要变化比如模拟100个用户分别用100个账号登录用用户参数或更专业的CSV数据文件设置。3. 高级用法与实战场景拆解掌握了基础我们来看看如何把它用出花来解决实际测试中的复杂问题。3.1 构建模块化与可移植的测试架构这是“用户定义的变量”最重要的价值。假设你为公司的一个微服务做性能测试这个服务在开发、集成、预发、生产环境都有部署。糟糕的做法写四个脚本或者在一个脚本里写四套HTTP请求用“如果If控制器”来切换。脚本臃肿维护噩梦。优雅的做法在测试计划根节点下添加一个“用户定义的变量”。定义一组环境变量env(值可以是dev,sit,uat,prod)file.encoding(值UTF-8)然后添加一个“如果If控制器”作为所有线程组的父级。在If控制器的条件中输入${__jexl3(${env} dev)}。在If控制器下添加一个“用户定义的变量”用于开发环境app_host:dev-api.service.comdb_host:dev-db.internal复制这个If控制器修改条件和内部的变量值用于其他环境。这样你只需要修改最顶层的那个env变量就能一键切换整个脚本的运行环境。所有请求中的${app_host}都会自动指向正确的目标。这种架构对于持续集成CI尤其友好可以通过命令行参数-Jenvuat来动态指定环境。3.2 与JMeter函数的强强联合变量可以引用函数的结果这让它的能力大大增强。你不需要手动计算一些值可以让JMeter在初始化时帮你算好。例如你想生成一个全局唯一的测试流水号可以用时间戳函数名称test_run_id值${__time(,)}// 这会生成一个13位的时间戳或者你想定义一个动态的日期用于查询接口名称query_date值${__time(yyyy-MM-dd,)}// 格式化为2023-10-27更复杂的你可以用__RandomString函数来定义初始的随机数据名称initial_username值testuser_${__RandomString(5,abcdefghijklmnopqrstuvwxyz,)}注意事项函数在“用户定义的变量”中执行也是在初始化阶段。所以${__time}获取的是脚本启动时的时间不是每个请求发生的时间。如果需要每个请求都获取实时时间应该把函数直接写在请求参数里。3.3 在断言和监听器中引用变量变量的用途不限于请求配置在验证结果和收集数据时同样强大。在响应断言中你可以断言返回的JSON中包含某个特定的用户ID而这个ID正是你之前定义的变量。响应断言 - 要测试的模式userId: ${defined_user_id}在监听器中比如“查看结果树”如果请求失败你希望看到失败时用的是哪个用户的数据。你可以在“Sample Result Save Configuration”中勾选“Variable Names”这样失败日志里就会记录当时变量的值对排查“为什么这个用户的请求失败了”至关重要。在生成动态文件名时使用“聚合报告”监听器你可以将结果保存到文件。文件名可以包含变量以便区分不同环境或不同测试轮次的结果。文件名./results/aggregate_report_${env}_${test_run_id}.csv4. 常见问题排查与深度避坑指南即使理解了原理在实际操作中还是会遇到各种奇怪的问题。下面是我从无数次踩坑中总结出来的经验。4.1 变量未解析或解析为空白这是最常见的问题。你在请求里写了${host}但跑起来发现请求发到了字面意义上的“${host}”这个域名或者该字段变成了空白。排查步骤检查拼写首先百分之五十的错误是变量名拼写错误或大小写不一致。确认定义的是host引用的也是${host}不是${Host}或${HOST}。检查作用域确认定义变量的“用户定义的变量”元件其作用域是否覆盖了引用的地方。如果变量定义在线程组A在线程组B引用肯定是找不到的。一个检查方法是使用${__V(variable_name)}函数来引用它更严格如果变量不存在会报错而${variable_name}在变量不存在时会直接替换成空字符串。检查执行顺序记住“用户定义的变量”只在启动时初始化。如果你试图在一个“后置处理器”如JSON提取器中提取一个值然后立刻在同一个请求的“用户定义的变量”中更新它这是行不通的。后置处理器在请求之后执行而“用户定义的变量”在请求之前甚至线程启动之前就初始化完了。查看调试工具添加一个“调试取样器”和“查看结果树”监听器。运行脚本后查看调试取样器的响应数据里面会列出JMeter当前作用域下的所有变量及其值。这是最直观的调试手段。4.2 多级变量引用与嵌套问题JMeter支持变量嵌套引用但需要小心。例如定义base_url: api.com定义full_url: https://${base_url}/v1这在“用户定义的变量”内部是可以工作的。JMeter会从左到右解析。但是如果你在另一个地方引用${full_url}它已经是解析后的值https://api.com/v1了。一个经典的坑你想用函数生成一个动态值作为变量的一部分。错误尝试dynamic_path: /data/${__time(yyyyMMdd,)}.json在“用户定义的变量”中__time函数会被执行dynamic_path的值被固定为/data/20231027.json假设当天是2023-10-27。这不是动态的。正确做法不要在变量值里嵌套需要实时计算的函数。应该把函数直接写到最终使用的请求路径里/data/${__time(yyyyMMdd,)}.json。或者使用“用户参数”并在每次迭代时更新。4.3 性能测试中的变量使用陷阱在并发压力测试时变量使用不当会影响测试结果甚至导致错误。线程安全“用户定义的变量”是线程不安全的吗对于读取操作它是安全的因为初始化后值就固定了。问题在于如果你错误地试图用它来共享一个需要在线程间更新的状态比如一个递增的计数器那肯定会出问题。对于需要线程安全的状态共享应该使用__threadNum函数或者__javaScript函数配合属性Properties来实现。内存开销虽然定义几十个变量对内存影响微乎其微但如果你错误地在“用户定义的变量”里存储了巨大的字符串比如一个完整的HTML模板或大JSON并且有上千个线程那么内存消耗就会增加。对于大型数据应该使用“文件读取”的方式比如CSV文件。命令行覆盖的优先级JMeter允许通过-J参数在命令行覆盖变量值例如jmeter -Jhostprod-server -n -t test.jmx。这个优先级是最高的会覆盖JMX脚本中“用户定义的变量”里设置的值。这在自动化测试中非常有用。但要注意命令行传入的变量在GUI界面中是不会显示的只有在运行时才生效。4.4 与其它配置元件的协作与冲突“用户定义的变量”常与“HTTP请求默认值”、“CSV数据文件设置”等一起使用需要理清优先级。与“HTTP请求默认值”“HTTP请求默认值”也是一个配置元件它可以设置协议、主机、端口等默认值。如果在这里也用了变量引用如${server_host}那么它和直接在HTTP请求中引用效果一样。优先级规则是越靠近采样器的配置优先级越高。HTTP请求自身的设置 线程组级别的“HTTP请求默认值” 测试计划级别的“HTTP请求默认值”。与“CSV数据文件设置”这是用于参数化的黄金搭档。通常“用户定义的变量”定义静态环境配置“CSV数据文件设置”定义动态测试数据如用户名、密码。两者没有冲突可以同时使用。一个请求中可以同时引用${server_host}来自变量和${username}来自CSV文件。最后分享一个我调试变量问题的私藏技巧在测试计划的最顶层添加一个“JSR223采样器”语言选Groovy写入脚本log.info(“所有变量” vars.getIterator().asIterator().collect{it}.join(“, “))。运行一下你会在JMeter的日志窗口不是结果树看到当前作用域下所有变量名的列表一目了然。这个技巧在排查复杂作用域问题时尤其管用。变量是JMeter脚本灵活性的来源花时间掌握它你的脚本能力会立刻上一个台阶。
1. 项目概述为什么“用户定义的变量”是JMeter脚本的灵魂如果你刚开始接触JMeter可能会觉得它就是个“点按钮”的工具添加线程组、加个HTTP请求、填上URL然后开跑。但当你试图模拟一个真实的用户登录、浏览商品、下单支付这样的流程时很快就会撞上第一堵墙每个用户的用户名、密码、商品ID总不能都一样吧这时候“用户定义的变量”就不再是一个可选项而是构建任何有实际意义性能测试脚本的基石。简单来说用户定义的变量就是你在JMeter里设置的“全局参数池”。它允许你将那些在脚本中反复出现、或者需要动态变化的值比如服务器地址、端口、用户凭证、查询参数集中管理起来。想象一下你要测试开发、测试、生产三套环境难道要复制三份脚本然后手动一个个去改里面的IP地址吗那太原始了。正确的做法是在一个地方定义变量${host}然后在所有HTTP请求的“服务器名称或IP”字段里都引用这个${host}。切换环境时你只需要改这一个变量的值整个脚本就自动适配了。这不仅仅是方便更是维护性和可靠性的保障。没有它你的脚本会充斥着“硬编码”脆弱且难以协作。几乎所有搜索“jmeter使用教程”、“jmeter压力测试步骤”的新手在迈过第一个简单示例后紧接着要攻克的核心技能就是它。接下来我会带你从零开始彻底搞懂这个功能并分享一些官方教程里很少提及的实战技巧和深坑。2. 核心概念与配置界面全解析2.1 变量、引用与作用域你必须理清的三个关键在深入配置之前我们必须先建立正确的认知模型。JMeter中的“用户定义的变量”涉及三个核心概念理解错了后面会处处碰壁。1. 变量Variable 这就是你定义的一个“名字-值”对。例如你可以定义一个变量名为api_host值为api.yourdomain.com。变量名最好做到见名知义使用小写字母和下划线是常见的约定。2. 引用Reference 定义变量不是目的使用它才是。在JMeter中你通过${变量名}的语法来引用一个变量的值。比如在HTTP请求的“路径”字段里填写/v1/user/${user_id}/profileJMeter在执行时就会用变量user_id的实际值替换掉${user_id}。3. 作用域Scope 这是最容易混淆的地方。JMeter的配置元件包括“用户定义的变量”有其作用范围。线程组级别如果你把“用户定义的变量”放在某个线程组下面那么这个变量只对这个线程组内的所有Sampler如HTTP请求可见。其他线程组无法使用它。测试计划级别如果你把它放在测试计划的根节点下和线程组平级那么它就是全局变量对所有线程组都可见。执行顺序JMeter元素是按顺序执行的。同一个作用域内“用户定义的变量”会在启动时或循环开始时被初始化一次。这意味着在测试运行过程中你无法通过“用户定义的变量”元件来更新一个已定义变量的值。如果你想实现动态变化比如每次循环用一个新用户需要用到“CSV数据文件设置”或“函数助手”。注意很多新手会误以为在运行时修改“用户定义的变量”元件的值能生效实际上不行。它是一个“初始化”元件不是“运行时更新”元件。2.2 配置元件添加与参数设置详解现在我们动手添加一个“用户定义的变量”。添加配置元件在JMeter GUI中右键点击你的测试计划或者某个线程组 - 选择“添加” - “配置元件” - “用户定义的变量”。理解界面添加后你会看到一个简单的表格界面。主要包含两列“名称”和“值”。你可以点击“添加”按钮来新增一行定义一对变量。填写示例让我们定义一个最常用的基础变量。名称server_protocol值https名称server_host值api.example.com名称server_port值443名称api_version值v2引用变量现在在一个HTTP请求采样器中你可以这样配置协议${server_protocol}服务器名称或IP${server_host}端口号${server_port}路径/${api_version}/login当JMeter执行时这个请求就会指向https://api.example.com:443/v2/login。实操心得我强烈建议即使你暂时只测一个环境也把协议、主机、端口这些基础信息变量化。这能培养良好的脚本习惯。未来某天需要切换环境时你会感谢现在的自己。2.3 与“用户参数”的区别静态初始化 vs 动态每线程这是另一个高频困惑点。在配置元件里还有一个叫“用户参数”的元件。它们界面相似但行为天差地别。特性用户定义的变量用户参数初始化时机测试/线程组启动时仅一次。每次线程迭代开始时都可以重新取值。是否支持多用户数据不支持。一套变量值所有线程共享。支持。可以为每个“用户”线程设置不同的变量值。主要用途定义静态的、全局的配置参数如主机名、环境标志。模拟不同用户的不同数据如用户名、用户ID尤其在与“线程数”配合模拟多用户时。动态更新不支持在运行中更新。支持在每次迭代时更新如果勾选了“每次迭代更新一次”。如何选择如果你的值在整个测试运行期间不变比如服务器地址、应用版本号用用户定义的变量。如果你的值需要每个虚拟用户不同或者同一个用户每次循环都要变化比如模拟100个用户分别用100个账号登录用用户参数或更专业的CSV数据文件设置。3. 高级用法与实战场景拆解掌握了基础我们来看看如何把它用出花来解决实际测试中的复杂问题。3.1 构建模块化与可移植的测试架构这是“用户定义的变量”最重要的价值。假设你为公司的一个微服务做性能测试这个服务在开发、集成、预发、生产环境都有部署。糟糕的做法写四个脚本或者在一个脚本里写四套HTTP请求用“如果If控制器”来切换。脚本臃肿维护噩梦。优雅的做法在测试计划根节点下添加一个“用户定义的变量”。定义一组环境变量env(值可以是dev,sit,uat,prod)file.encoding(值UTF-8)然后添加一个“如果If控制器”作为所有线程组的父级。在If控制器的条件中输入${__jexl3(${env} dev)}。在If控制器下添加一个“用户定义的变量”用于开发环境app_host:dev-api.service.comdb_host:dev-db.internal复制这个If控制器修改条件和内部的变量值用于其他环境。这样你只需要修改最顶层的那个env变量就能一键切换整个脚本的运行环境。所有请求中的${app_host}都会自动指向正确的目标。这种架构对于持续集成CI尤其友好可以通过命令行参数-Jenvuat来动态指定环境。3.2 与JMeter函数的强强联合变量可以引用函数的结果这让它的能力大大增强。你不需要手动计算一些值可以让JMeter在初始化时帮你算好。例如你想生成一个全局唯一的测试流水号可以用时间戳函数名称test_run_id值${__time(,)}// 这会生成一个13位的时间戳或者你想定义一个动态的日期用于查询接口名称query_date值${__time(yyyy-MM-dd,)}// 格式化为2023-10-27更复杂的你可以用__RandomString函数来定义初始的随机数据名称initial_username值testuser_${__RandomString(5,abcdefghijklmnopqrstuvwxyz,)}注意事项函数在“用户定义的变量”中执行也是在初始化阶段。所以${__time}获取的是脚本启动时的时间不是每个请求发生的时间。如果需要每个请求都获取实时时间应该把函数直接写在请求参数里。3.3 在断言和监听器中引用变量变量的用途不限于请求配置在验证结果和收集数据时同样强大。在响应断言中你可以断言返回的JSON中包含某个特定的用户ID而这个ID正是你之前定义的变量。响应断言 - 要测试的模式userId: ${defined_user_id}在监听器中比如“查看结果树”如果请求失败你希望看到失败时用的是哪个用户的数据。你可以在“Sample Result Save Configuration”中勾选“Variable Names”这样失败日志里就会记录当时变量的值对排查“为什么这个用户的请求失败了”至关重要。在生成动态文件名时使用“聚合报告”监听器你可以将结果保存到文件。文件名可以包含变量以便区分不同环境或不同测试轮次的结果。文件名./results/aggregate_report_${env}_${test_run_id}.csv4. 常见问题排查与深度避坑指南即使理解了原理在实际操作中还是会遇到各种奇怪的问题。下面是我从无数次踩坑中总结出来的经验。4.1 变量未解析或解析为空白这是最常见的问题。你在请求里写了${host}但跑起来发现请求发到了字面意义上的“${host}”这个域名或者该字段变成了空白。排查步骤检查拼写首先百分之五十的错误是变量名拼写错误或大小写不一致。确认定义的是host引用的也是${host}不是${Host}或${HOST}。检查作用域确认定义变量的“用户定义的变量”元件其作用域是否覆盖了引用的地方。如果变量定义在线程组A在线程组B引用肯定是找不到的。一个检查方法是使用${__V(variable_name)}函数来引用它更严格如果变量不存在会报错而${variable_name}在变量不存在时会直接替换成空字符串。检查执行顺序记住“用户定义的变量”只在启动时初始化。如果你试图在一个“后置处理器”如JSON提取器中提取一个值然后立刻在同一个请求的“用户定义的变量”中更新它这是行不通的。后置处理器在请求之后执行而“用户定义的变量”在请求之前甚至线程启动之前就初始化完了。查看调试工具添加一个“调试取样器”和“查看结果树”监听器。运行脚本后查看调试取样器的响应数据里面会列出JMeter当前作用域下的所有变量及其值。这是最直观的调试手段。4.2 多级变量引用与嵌套问题JMeter支持变量嵌套引用但需要小心。例如定义base_url: api.com定义full_url: https://${base_url}/v1这在“用户定义的变量”内部是可以工作的。JMeter会从左到右解析。但是如果你在另一个地方引用${full_url}它已经是解析后的值https://api.com/v1了。一个经典的坑你想用函数生成一个动态值作为变量的一部分。错误尝试dynamic_path: /data/${__time(yyyyMMdd,)}.json在“用户定义的变量”中__time函数会被执行dynamic_path的值被固定为/data/20231027.json假设当天是2023-10-27。这不是动态的。正确做法不要在变量值里嵌套需要实时计算的函数。应该把函数直接写到最终使用的请求路径里/data/${__time(yyyyMMdd,)}.json。或者使用“用户参数”并在每次迭代时更新。4.3 性能测试中的变量使用陷阱在并发压力测试时变量使用不当会影响测试结果甚至导致错误。线程安全“用户定义的变量”是线程不安全的吗对于读取操作它是安全的因为初始化后值就固定了。问题在于如果你错误地试图用它来共享一个需要在线程间更新的状态比如一个递增的计数器那肯定会出问题。对于需要线程安全的状态共享应该使用__threadNum函数或者__javaScript函数配合属性Properties来实现。内存开销虽然定义几十个变量对内存影响微乎其微但如果你错误地在“用户定义的变量”里存储了巨大的字符串比如一个完整的HTML模板或大JSON并且有上千个线程那么内存消耗就会增加。对于大型数据应该使用“文件读取”的方式比如CSV文件。命令行覆盖的优先级JMeter允许通过-J参数在命令行覆盖变量值例如jmeter -Jhostprod-server -n -t test.jmx。这个优先级是最高的会覆盖JMX脚本中“用户定义的变量”里设置的值。这在自动化测试中非常有用。但要注意命令行传入的变量在GUI界面中是不会显示的只有在运行时才生效。4.4 与其它配置元件的协作与冲突“用户定义的变量”常与“HTTP请求默认值”、“CSV数据文件设置”等一起使用需要理清优先级。与“HTTP请求默认值”“HTTP请求默认值”也是一个配置元件它可以设置协议、主机、端口等默认值。如果在这里也用了变量引用如${server_host}那么它和直接在HTTP请求中引用效果一样。优先级规则是越靠近采样器的配置优先级越高。HTTP请求自身的设置 线程组级别的“HTTP请求默认值” 测试计划级别的“HTTP请求默认值”。与“CSV数据文件设置”这是用于参数化的黄金搭档。通常“用户定义的变量”定义静态环境配置“CSV数据文件设置”定义动态测试数据如用户名、密码。两者没有冲突可以同时使用。一个请求中可以同时引用${server_host}来自变量和${username}来自CSV文件。最后分享一个我调试变量问题的私藏技巧在测试计划的最顶层添加一个“JSR223采样器”语言选Groovy写入脚本log.info(“所有变量” vars.getIterator().asIterator().collect{it}.join(“, “))。运行一下你会在JMeter的日志窗口不是结果树看到当前作用域下所有变量名的列表一目了然。这个技巧在排查复杂作用域问题时尤其管用。变量是JMeter脚本灵活性的来源花时间掌握它你的脚本能力会立刻上一个台阶。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
