1. 项目概述为什么JMeter处理JSON是个技术活如果你做过接口测试或者性能压测大概率用过JMeter。这个工具在发送HTTP请求、模拟并发用户上确实是一把好手但一碰到复杂的JSON数据交互很多人就有点头疼了。我见过不少测试同学脚本里硬编码着长长的JSON字符串要改个参数就得在那一大坨文本里小心翼翼地找生怕多删一个括号。还有更麻烦的上一个接口返回的JSON里有个userId下一个接口的请求体里得用上它这时候怎么优雅地提取和传递这些问题就是“JMeter JSON数据处理”这个主题要解决的核心痛点。简单来说这个实战指南要做的就是让你手里的JMeter从一个只会“发请求、看结果”的简单工具升级成一个能灵活“读懂、拆解、组装、传递”JSON数据的智能测试引擎。无论是接口自动化测试中的参数关联还是性能测试里模拟真实业务数据比如每个虚拟用户使用不同的登录账号和查询条件都离不开对JSON数据的精细处理。掌握了这套方法你设计的测试场景将更贴近真实脚本的维护成本也会大大降低。2. 核心思路将JSON视为可编程的数据结构处理JSON不能停留在“字符串拼接”的层面。在JMeter中我们需要建立起一种思维将JSON视为一个结构化的数据对象。这意味着我们可以定位到其中的任意节点如data.user.list[0].id可以读取它的值也可以基于模板和变量动态地构建一个新的JSON对象。基于这个思路整个处理流程可以拆解为三个核心环节它们构成了一个完整的数据流闭环构建与发送如何动态生成或组装一个JSON请求体。提取与存储如何从返回的JSON响应中精准抓取我们需要的数据。传递与复用如何将提取到的数据安全、正确地应用到后续的请求或判断逻辑中。JMeter本身提供了一系列元件如JSON提取器、JSR223处理器和内置函数来支持这些操作。我们的实战就是围绕这些元件和函数结合具体场景讲清楚“什么时候用什么”以及“怎么用才不出错”。2.1 工具选型为什么是这些元件面对JSONJMeter里有好几个元件都能沾上边比如正则表达式提取器、JSON提取器、JSR223处理器。我的选择逻辑是这样的JSON提取器 vs. 正则表达式提取器对于JSON响应无脑首选JSON提取器。正则表达式虽然强大但用来解析JSON就像用螺丝刀砍树——不是不行但效率低、容易出错一个格式上的微小变动比如多了个空格或换行就可能导致提取失败。JSON提取器基于JSONPath表达式定位是专门为JSON设计的精准且抗干扰能力强。JSON提取器 vs. JSR223处理器对于简单的字段提取比如取个tokenJSON提取器配置简单性能开销极小。但当需要非常复杂的逻辑比如遍历一个数组、根据条件过滤、或者对提取的值进行二次计算时JSR223处理器特别是Groovy脚本才是王道。它提供了完整的编程能力。用于构建JSON的利器硬编码字符串是最差的选择。我们主要用两种方式__StringFromFile函数适合JSON模板很大且基本固定只有少数几个参数需要替换的场景。把模板写在文件里用函数读取再用变量替换占位符。JSR223处理器中的Groovy脚本使用JsonBuilder或JsonOutput可以以编程方式灵活构建任何结构的JSON特别适合数据需要动态生成的情况。注意在JSR223处理器中语言务必选择“Groovy”而不是Java。因为Groovy在JMeter中编译执行效率更高对脚本的缓存机制更好能显著提升压测时的性能。3. 核心细节解析与实操要点3.1 JSON提取器像查字典一样定位数据JSON提取器的核心在于JSONPath表达式。你可以把它理解为JSON的“查询语言”。配置时有几个关键字段Names of created variables你给提取到的值起的变量名。比如填userId。JSON Path expressionsJSONPath表达式告诉JMeter去哪里找。比如$.data.userId。Match No.如果JSONPath找到多个结果比如一个数组你想取第几个0表示随机1表示第一个-1表示所有会存为变量名_1, 变量名_2...。Default Values如果没找到变量的默认值是什么。这里强烈建议设置一个易于识别的默认值比如NOT_FOUND方便后续断言或调试。JSONPath表达式速成$表示JSON的根节点。.或[]访问子节点。$.store.book[0].title或$[store][book][0][title]。..递归下降搜索所有节点。$..price能找到整个JSON里所有叫price的字段。*通配符匹配所有。$.store.book[*].author获取所有书的作者。?()过滤表达式。$.store.book[?(.price 10)]找到价格低于10的书。实操心得 在写JSONPath之前我习惯先用在线工具比如jsonpath.com或者浏览器的开发者工具Network标签下对响应结果直接点“Preview”来验证我的表达式是否正确。这能节省大量在JMeter里反复调试的时间。3.2 动态构建JSON请求体这是让脚本“活”起来的关键。假设我们要测试一个创建订单的接口请求体JSON需要包含用户ID、商品列表和收货地址。方法一使用变量与__eval函数进行模板替换在“用户定义的变量”或前置处理器中定义好变量productId123,productName测试商品,addressId456。在HTTP请求的“Body Data”中写入一个带有占位符的JSON模板{ userId: ${userId}, orderItems: [ { productId: ${productId}, productName: ${productName}, quantity: 1 } ], shippingAddressId: ${addressId} }JMeter在发送请求前会自动将${变量名}替换为实际值。对于简单嵌套这很有效。方法二使用JSR223处理器与Groovy构建推荐用于复杂结构当JSON结构复杂或者需要根据逻辑动态生成数组元素时用代码构建更清晰。在HTTP请求前添加一个JSR223 PreProcessor语言选Groovyimport groovy.json.JsonBuilder // 假设我们从前面接口提取或生成了这些变量 def userId vars.get(userId) // vars是JMeter的变量操作对象 def productList [] // 模拟动态添加商品 for (int i 1; i 3; i) { productList.add([ productId: 1000 i, productName: 动态商品 i, quantity: i ]) } def json new JsonBuilder() json { userId userId orderItems productList shippingAddressId vars.get(addressId) ?: default_address // 提供默认值 } // 将生成的JSON字符串存入一个变量比如orderJson vars.put(orderJson, json.toString()) // 在HTTP请求的Body Data中直接引用${orderJson}这样请求体就完全由代码动态生成了灵活性极高。3.3 处理JSON数组遍历与参数化从响应中提取一个JSON数组比如一个订单列表$.data.orders并让后续请求能依次使用数组里的每个元素这是一个常见需求。场景第一个接口获取用户的所有订单ID列表第二个接口需要遍历这些ID去查询每个订单的详情。步骤提取所有ID使用JSON提取器表达式写$.data.orders[*].id变量名设为orderIdMatch No.填-1。执行后你会得到orderId_1101,orderId_2102,orderId_3103...以及orderId_matchNr3表示总数。遍历执行将你的“查询订单详情”的HTTP请求假设它使用${orderId}作为路径参数放在一个循环控制器中。关键配置在循环控制器中需要巧妙地使用__V变量函数和__counter函数来依次获取每个ID。在循环控制器中将“循环次数”设置为${orderId_matchNr}。在HTTP请求的路径中这样写/api/order/${__V(orderId_${__counter(,)})}。__counter(,)会从1开始每次循环加1。于是第一次循环路径是/api/order/${orderId_1}第二次是/api/order/${orderId_2}以此类推。__V函数用于执行嵌套变量引用。踩坑记录这里最容易出错的是变量作用域。确保JSON提取器是“查询订单详情”请求的父级比如都在同一个事务控制器下否则orderId_1这些变量可能无法被取到。如果循环控制器在另一个线程组可能需要使用${__property(orderId_1)}等方式跨线程组传递但更推荐将关联请求组织在同一个逻辑单元内。4. 实操过程与核心环节实现让我们通过一个完整的场景来串联上述知识点模拟用户登录后查看商品列表并将第一个商品加入购物车。4.1 第一步用户登录并提取Token线程组新建一个线程组设置好线程数、循环次数等。HTTP请求登录方法POST路径/api/loginBody Data:{username: testUser, password: 123456}JSON提取器添加在登录请求下变量名authTokenJSONPath表达式$.data.token假设返回格式为{code:0, data:{token:xxxx}}Match No.:1默认值LOGIN_FAILED调试取样器可选但推荐添加一个调试取样器在测试初期勾选“JMeter属性”和“JMeter变量”运行后可以在“查看结果树”里看到所有变量值确认authToken是否提取成功。4.2 第二步携带Token获取商品列表HTTP请求获取商品列表方法GET路径/api/productsHTTP信息头管理器关键需要添加一个Header。名称Authorization值Bearer ${authToken}这是常见的Token携带方式JSON提取器添加在商品列表请求下变量名firstProductIdJSONPath表达式$.data.products[0].id提取列表第一个商品的IDMatch No.:1默认值NO_PRODUCT4.3 第三步动态构建加入购物车请求JSR223预处理器添加在“加入购物车”请求前import groovy.json.JsonOutput def cartItem [ productId: vars.get(firstProductId).toInteger(), // 转换为整数根据接口定义决定 quantity: 1, selected: true ] def requestBody JsonOutput.toJson(cartItem) vars.put(cartRequestJson, requestBody) // 打印日志便于调试 log.info(构建的购物车JSON: requestBody)HTTP请求加入购物车方法POST路径/api/cart/addHTTP信息头管理器同样需要Authorization: Bearer ${authToken}以及Content-Type: application/json。Body Data:${cartRequestJson}4.4 第四步断言与结果验证每个关键请求后都应添加断言确保业务链路的正确性。登录请求后添加“响应断言”检查响应文本是否包含code:0或者使用“JSON断言”直接检查$.code等于0。加入购物车请求后添加“JSON断言”检查返回消息例如$.msg包含“成功”。参数化与数据驱动 为了让测试更真实我们需要模拟不同用户。可以创建一个CSV文件users.csvusername,password user1,pass1 user2,pass2 user3,pass3在线程组开头添加一个CSV数据文件设置元件指定文件名和变量名username,password。然后将登录请求的Body Data改为{username: ${username}, password: ${password}}这样每次循环或每个线程都会读取CSV文件中的下一行数据实现多用户登录。5. 常见问题与排查技巧实录在实际使用中你会遇到各种各样的问题。下面是我总结的一些高频问题及解决方法。5.1 提取器失效变量为空这是最常见的问题。排查步骤确认响应格式在“查看结果树”中选择该请求将响应数据格式切换为“JSON”看看JMeter是否能正确解析成树状结构。如果不能说明响应可能不是标准的JSON比如有BOM头、包含了额外的文本。验证JSONPath将响应数据复制到在线JSONPath验证工具测试你写的表达式是否能正确取到值。检查变量作用域确保JSON提取器是你要使用该变量的请求的父级即位于请求之前且在同一个逻辑控制器内。查看提取结果添加“调试取样器”运行后查看提取的变量名和值这是最直接的诊断方式。5.2 中文乱码问题JMeter默认使用操作系统的编码有时会导致JSON中的中文显示为乱码或断言失败。解决方案在jmeter.properties文件位于JMeter的bin目录中找到并取消注释这一行sampleresult.default.encodingUTF-8然后重启JMeter。对于HTTP请求也可以显式地在请求中加上信息头Content-Type: application/json;charsetUTF-8。5.3 JSON断言失败但响应看起来是对的这可能是因为响应中包含了一些不可见的字符或者JSON的格式如缩进、换行与断言中写的不完全一致。技巧使用“JSON断言”而不是“响应断言”来检查JSON数据。JSON断言是基于JSONPath的不关心格式只关心值。例如断言$.code等于200远比断言响应文本包含code: 200要健壮得多。5.4 性能压测时JSON处理成为瓶颈当虚拟用户数很大时在JSR223处理器中执行复杂的Groovy脚本或大量的JSON解析可能会消耗较多CPU。优化建议脚本编译确保JSR223处理器中的“Cache compiled script if available”选项被勾选默认是勾选的。减少不必要的处理将一些固定的JSON模板或数据初始化工作放在“仅一次控制器”中而不是每个迭代都执行。慎用log.info压测时将日志级别调整为WARN或ERROR避免大量的控制台输出拖慢速度。考虑使用Beanshell还是Groovy对于极简单的脚本Beanshell可能更轻量但对于大多数情况Groovy的性能和功能更好是首选。5.5 变量引用错误例如在HTTP请求的路径中写了/api/${userId}但报错找不到该变量。检查点变量名拼写是否正确区分大小写。变量是否已经成功赋值。通过调试取样器查看。如果变量值来自正则表达式或JSON提取器其值默认是字符串。如果接口需要数字类型可能需要去除引号但这通常在请求体中不是问题因为JSON序列化时会处理。在路径参数中直接引用字符串变量即可。5.6 如何优雅地处理复杂的嵌套JSON响应有时我们需要从一个深层嵌套、结构复杂的JSON中提取多个字段。方法可以使用一个JSON提取器但利用JSONPath的“多重路径”功能。在“JSON Path expressions”中可以写多个表达式用分号;隔开。变量名也对应地用分号隔开。例如变量名userId;userName;emailJSONPath表达式$.data.user.id;$.data.user.name;$.data.user.contact.email这样就能一次提取三个字段到三个不同的变量中比配置三个独立的提取器更简洁。我个人在实际项目中处理JSON最深的体会是前期设计比后期调试更重要。在动手写JMeter脚本前先花时间分析接口文档画出数据流图哪个接口产出什么数据哪个接口消费什么数据规划好变量的命名规范比如前缀_描述resp_login_token,req_order_id。一个清晰的数据流设计和命名规范能让复杂的测试脚本保持可维护性尤其是在团队协作中价值巨大。
1. 项目概述为什么JMeter处理JSON是个技术活如果你做过接口测试或者性能压测大概率用过JMeter。这个工具在发送HTTP请求、模拟并发用户上确实是一把好手但一碰到复杂的JSON数据交互很多人就有点头疼了。我见过不少测试同学脚本里硬编码着长长的JSON字符串要改个参数就得在那一大坨文本里小心翼翼地找生怕多删一个括号。还有更麻烦的上一个接口返回的JSON里有个userId下一个接口的请求体里得用上它这时候怎么优雅地提取和传递这些问题就是“JMeter JSON数据处理”这个主题要解决的核心痛点。简单来说这个实战指南要做的就是让你手里的JMeter从一个只会“发请求、看结果”的简单工具升级成一个能灵活“读懂、拆解、组装、传递”JSON数据的智能测试引擎。无论是接口自动化测试中的参数关联还是性能测试里模拟真实业务数据比如每个虚拟用户使用不同的登录账号和查询条件都离不开对JSON数据的精细处理。掌握了这套方法你设计的测试场景将更贴近真实脚本的维护成本也会大大降低。2. 核心思路将JSON视为可编程的数据结构处理JSON不能停留在“字符串拼接”的层面。在JMeter中我们需要建立起一种思维将JSON视为一个结构化的数据对象。这意味着我们可以定位到其中的任意节点如data.user.list[0].id可以读取它的值也可以基于模板和变量动态地构建一个新的JSON对象。基于这个思路整个处理流程可以拆解为三个核心环节它们构成了一个完整的数据流闭环构建与发送如何动态生成或组装一个JSON请求体。提取与存储如何从返回的JSON响应中精准抓取我们需要的数据。传递与复用如何将提取到的数据安全、正确地应用到后续的请求或判断逻辑中。JMeter本身提供了一系列元件如JSON提取器、JSR223处理器和内置函数来支持这些操作。我们的实战就是围绕这些元件和函数结合具体场景讲清楚“什么时候用什么”以及“怎么用才不出错”。2.1 工具选型为什么是这些元件面对JSONJMeter里有好几个元件都能沾上边比如正则表达式提取器、JSON提取器、JSR223处理器。我的选择逻辑是这样的JSON提取器 vs. 正则表达式提取器对于JSON响应无脑首选JSON提取器。正则表达式虽然强大但用来解析JSON就像用螺丝刀砍树——不是不行但效率低、容易出错一个格式上的微小变动比如多了个空格或换行就可能导致提取失败。JSON提取器基于JSONPath表达式定位是专门为JSON设计的精准且抗干扰能力强。JSON提取器 vs. JSR223处理器对于简单的字段提取比如取个tokenJSON提取器配置简单性能开销极小。但当需要非常复杂的逻辑比如遍历一个数组、根据条件过滤、或者对提取的值进行二次计算时JSR223处理器特别是Groovy脚本才是王道。它提供了完整的编程能力。用于构建JSON的利器硬编码字符串是最差的选择。我们主要用两种方式__StringFromFile函数适合JSON模板很大且基本固定只有少数几个参数需要替换的场景。把模板写在文件里用函数读取再用变量替换占位符。JSR223处理器中的Groovy脚本使用JsonBuilder或JsonOutput可以以编程方式灵活构建任何结构的JSON特别适合数据需要动态生成的情况。注意在JSR223处理器中语言务必选择“Groovy”而不是Java。因为Groovy在JMeter中编译执行效率更高对脚本的缓存机制更好能显著提升压测时的性能。3. 核心细节解析与实操要点3.1 JSON提取器像查字典一样定位数据JSON提取器的核心在于JSONPath表达式。你可以把它理解为JSON的“查询语言”。配置时有几个关键字段Names of created variables你给提取到的值起的变量名。比如填userId。JSON Path expressionsJSONPath表达式告诉JMeter去哪里找。比如$.data.userId。Match No.如果JSONPath找到多个结果比如一个数组你想取第几个0表示随机1表示第一个-1表示所有会存为变量名_1, 变量名_2...。Default Values如果没找到变量的默认值是什么。这里强烈建议设置一个易于识别的默认值比如NOT_FOUND方便后续断言或调试。JSONPath表达式速成$表示JSON的根节点。.或[]访问子节点。$.store.book[0].title或$[store][book][0][title]。..递归下降搜索所有节点。$..price能找到整个JSON里所有叫price的字段。*通配符匹配所有。$.store.book[*].author获取所有书的作者。?()过滤表达式。$.store.book[?(.price 10)]找到价格低于10的书。实操心得 在写JSONPath之前我习惯先用在线工具比如jsonpath.com或者浏览器的开发者工具Network标签下对响应结果直接点“Preview”来验证我的表达式是否正确。这能节省大量在JMeter里反复调试的时间。3.2 动态构建JSON请求体这是让脚本“活”起来的关键。假设我们要测试一个创建订单的接口请求体JSON需要包含用户ID、商品列表和收货地址。方法一使用变量与__eval函数进行模板替换在“用户定义的变量”或前置处理器中定义好变量productId123,productName测试商品,addressId456。在HTTP请求的“Body Data”中写入一个带有占位符的JSON模板{ userId: ${userId}, orderItems: [ { productId: ${productId}, productName: ${productName}, quantity: 1 } ], shippingAddressId: ${addressId} }JMeter在发送请求前会自动将${变量名}替换为实际值。对于简单嵌套这很有效。方法二使用JSR223处理器与Groovy构建推荐用于复杂结构当JSON结构复杂或者需要根据逻辑动态生成数组元素时用代码构建更清晰。在HTTP请求前添加一个JSR223 PreProcessor语言选Groovyimport groovy.json.JsonBuilder // 假设我们从前面接口提取或生成了这些变量 def userId vars.get(userId) // vars是JMeter的变量操作对象 def productList [] // 模拟动态添加商品 for (int i 1; i 3; i) { productList.add([ productId: 1000 i, productName: 动态商品 i, quantity: i ]) } def json new JsonBuilder() json { userId userId orderItems productList shippingAddressId vars.get(addressId) ?: default_address // 提供默认值 } // 将生成的JSON字符串存入一个变量比如orderJson vars.put(orderJson, json.toString()) // 在HTTP请求的Body Data中直接引用${orderJson}这样请求体就完全由代码动态生成了灵活性极高。3.3 处理JSON数组遍历与参数化从响应中提取一个JSON数组比如一个订单列表$.data.orders并让后续请求能依次使用数组里的每个元素这是一个常见需求。场景第一个接口获取用户的所有订单ID列表第二个接口需要遍历这些ID去查询每个订单的详情。步骤提取所有ID使用JSON提取器表达式写$.data.orders[*].id变量名设为orderIdMatch No.填-1。执行后你会得到orderId_1101,orderId_2102,orderId_3103...以及orderId_matchNr3表示总数。遍历执行将你的“查询订单详情”的HTTP请求假设它使用${orderId}作为路径参数放在一个循环控制器中。关键配置在循环控制器中需要巧妙地使用__V变量函数和__counter函数来依次获取每个ID。在循环控制器中将“循环次数”设置为${orderId_matchNr}。在HTTP请求的路径中这样写/api/order/${__V(orderId_${__counter(,)})}。__counter(,)会从1开始每次循环加1。于是第一次循环路径是/api/order/${orderId_1}第二次是/api/order/${orderId_2}以此类推。__V函数用于执行嵌套变量引用。踩坑记录这里最容易出错的是变量作用域。确保JSON提取器是“查询订单详情”请求的父级比如都在同一个事务控制器下否则orderId_1这些变量可能无法被取到。如果循环控制器在另一个线程组可能需要使用${__property(orderId_1)}等方式跨线程组传递但更推荐将关联请求组织在同一个逻辑单元内。4. 实操过程与核心环节实现让我们通过一个完整的场景来串联上述知识点模拟用户登录后查看商品列表并将第一个商品加入购物车。4.1 第一步用户登录并提取Token线程组新建一个线程组设置好线程数、循环次数等。HTTP请求登录方法POST路径/api/loginBody Data:{username: testUser, password: 123456}JSON提取器添加在登录请求下变量名authTokenJSONPath表达式$.data.token假设返回格式为{code:0, data:{token:xxxx}}Match No.:1默认值LOGIN_FAILED调试取样器可选但推荐添加一个调试取样器在测试初期勾选“JMeter属性”和“JMeter变量”运行后可以在“查看结果树”里看到所有变量值确认authToken是否提取成功。4.2 第二步携带Token获取商品列表HTTP请求获取商品列表方法GET路径/api/productsHTTP信息头管理器关键需要添加一个Header。名称Authorization值Bearer ${authToken}这是常见的Token携带方式JSON提取器添加在商品列表请求下变量名firstProductIdJSONPath表达式$.data.products[0].id提取列表第一个商品的IDMatch No.:1默认值NO_PRODUCT4.3 第三步动态构建加入购物车请求JSR223预处理器添加在“加入购物车”请求前import groovy.json.JsonOutput def cartItem [ productId: vars.get(firstProductId).toInteger(), // 转换为整数根据接口定义决定 quantity: 1, selected: true ] def requestBody JsonOutput.toJson(cartItem) vars.put(cartRequestJson, requestBody) // 打印日志便于调试 log.info(构建的购物车JSON: requestBody)HTTP请求加入购物车方法POST路径/api/cart/addHTTP信息头管理器同样需要Authorization: Bearer ${authToken}以及Content-Type: application/json。Body Data:${cartRequestJson}4.4 第四步断言与结果验证每个关键请求后都应添加断言确保业务链路的正确性。登录请求后添加“响应断言”检查响应文本是否包含code:0或者使用“JSON断言”直接检查$.code等于0。加入购物车请求后添加“JSON断言”检查返回消息例如$.msg包含“成功”。参数化与数据驱动 为了让测试更真实我们需要模拟不同用户。可以创建一个CSV文件users.csvusername,password user1,pass1 user2,pass2 user3,pass3在线程组开头添加一个CSV数据文件设置元件指定文件名和变量名username,password。然后将登录请求的Body Data改为{username: ${username}, password: ${password}}这样每次循环或每个线程都会读取CSV文件中的下一行数据实现多用户登录。5. 常见问题与排查技巧实录在实际使用中你会遇到各种各样的问题。下面是我总结的一些高频问题及解决方法。5.1 提取器失效变量为空这是最常见的问题。排查步骤确认响应格式在“查看结果树”中选择该请求将响应数据格式切换为“JSON”看看JMeter是否能正确解析成树状结构。如果不能说明响应可能不是标准的JSON比如有BOM头、包含了额外的文本。验证JSONPath将响应数据复制到在线JSONPath验证工具测试你写的表达式是否能正确取到值。检查变量作用域确保JSON提取器是你要使用该变量的请求的父级即位于请求之前且在同一个逻辑控制器内。查看提取结果添加“调试取样器”运行后查看提取的变量名和值这是最直接的诊断方式。5.2 中文乱码问题JMeter默认使用操作系统的编码有时会导致JSON中的中文显示为乱码或断言失败。解决方案在jmeter.properties文件位于JMeter的bin目录中找到并取消注释这一行sampleresult.default.encodingUTF-8然后重启JMeter。对于HTTP请求也可以显式地在请求中加上信息头Content-Type: application/json;charsetUTF-8。5.3 JSON断言失败但响应看起来是对的这可能是因为响应中包含了一些不可见的字符或者JSON的格式如缩进、换行与断言中写的不完全一致。技巧使用“JSON断言”而不是“响应断言”来检查JSON数据。JSON断言是基于JSONPath的不关心格式只关心值。例如断言$.code等于200远比断言响应文本包含code: 200要健壮得多。5.4 性能压测时JSON处理成为瓶颈当虚拟用户数很大时在JSR223处理器中执行复杂的Groovy脚本或大量的JSON解析可能会消耗较多CPU。优化建议脚本编译确保JSR223处理器中的“Cache compiled script if available”选项被勾选默认是勾选的。减少不必要的处理将一些固定的JSON模板或数据初始化工作放在“仅一次控制器”中而不是每个迭代都执行。慎用log.info压测时将日志级别调整为WARN或ERROR避免大量的控制台输出拖慢速度。考虑使用Beanshell还是Groovy对于极简单的脚本Beanshell可能更轻量但对于大多数情况Groovy的性能和功能更好是首选。5.5 变量引用错误例如在HTTP请求的路径中写了/api/${userId}但报错找不到该变量。检查点变量名拼写是否正确区分大小写。变量是否已经成功赋值。通过调试取样器查看。如果变量值来自正则表达式或JSON提取器其值默认是字符串。如果接口需要数字类型可能需要去除引号但这通常在请求体中不是问题因为JSON序列化时会处理。在路径参数中直接引用字符串变量即可。5.6 如何优雅地处理复杂的嵌套JSON响应有时我们需要从一个深层嵌套、结构复杂的JSON中提取多个字段。方法可以使用一个JSON提取器但利用JSONPath的“多重路径”功能。在“JSON Path expressions”中可以写多个表达式用分号;隔开。变量名也对应地用分号隔开。例如变量名userId;userName;emailJSONPath表达式$.data.user.id;$.data.user.name;$.data.user.contact.email这样就能一次提取三个字段到三个不同的变量中比配置三个独立的提取器更简洁。我个人在实际项目中处理JSON最深的体会是前期设计比后期调试更重要。在动手写JMeter脚本前先花时间分析接口文档画出数据流图哪个接口产出什么数据哪个接口消费什么数据规划好变量的命名规范比如前缀_描述resp_login_token,req_order_id。一个清晰的数据流设计和命名规范能让复杂的测试脚本保持可维护性尤其是在团队协作中价值巨大。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
