JMeter参数化建模：CSV与Beanshell断言打造真实压测数据

做性能测试这些年JMeter 是我用得最多也最敢推荐的一把尺子。它本身不复杂复杂的是脚本里的数据怎么给、给得真不真实。项目标题说得很直白——参数化获取各种参数这一步恰恰是新手最容易卡住的地方。我见过太多人把登录账号写死在 HTTP 请求里一百个虚拟用户跑得跟复读机一样后端一看到重复数据就开始防重、限流、命中缓存压测结果自然没法用。参数化要解决的就是这件事让每个虚拟用户拿到的数据像真实用户那样独立且多样该随机就随机该从上一个接口的返回值里取就取回来接着用。做好这一步你再去谈线程数、吞吐量才有意义。这篇我按实战习惯来写覆盖 CSV 数据驱动、内置函数组合、正则提取器、JSON 提取器、JSR223 脚本与 BeanShell 断言最后把压测过程中常见的报错和排查路径捋了一遍。适合正在学 JMeter 接口测试的测试新人也适合想把脚本从“能跑”优化到“可信”的开发同学。1. 参数化的底层逻辑与测试计划设计1.1 不参数化的脚本只是一堆假请求JMeter 的测试计划说白了就是一组线程组每个线程模拟一个虚拟用户线程组里挂 HTTP 请求、断言、监听器。很多人在这一层就停住了觉得只要把接口调通、加上线程数压测就开始了。结果跑到一半发现响应全是失败或者服务端日志里全是同一个订单号在反复提交问题往往不是线程数不够而是请求里的数据“太假了”。真实用户的行为永远是有差异的。有人用手机号 A 注册有人用手机号 B 登录有人领了券 C 去下单有人拿着订单号 D 查物流。如果这些业务标识全部写死服务器端会怎么处理第一道拦路虎就是幂等性校验。很多下单接口对相同订单号做了防重重复请求直接返回“订单已存在”第二道是缓存相同参数的查询在 Redis 里命中一次就不再走数据库压力模型彻底失真第三道是业务规则比如一个优惠券只能被领取一次一百个线程抢同一张券很可能只有第一个成功剩下九十九个全部失败这根本不是你要测的并发能力。另外一类更隐蔽的参数是上一个接口动态产生的。登录接口返回一个 token创建订单接口返回一个订单号支付接口要拿订单号和签名去请求。这种值你在测试计划里没法预先写死因为每次登录拿到的 token 都不一样。JMeter 里把这叫做“关联”本质是从前面的响应里提取变量再传递给后面的请求。关联和参数化其实是同一件事的两面一个是主动准备数据一个是从响应里回捞数据目的都是让脚本跑起来更像真实业务流。1.2 先分清你要参数化的四类“参数”动手写脚本之前先别急着往 CSV 里塞数据。我在项目里习惯把参数分成四类分类不一样使用的 JMeter 组件就完全不一样。分清楚了后面就不会出现“明明用了参数化但每次循环拿到的还是同一个值”这种问题。参数类型来源推荐的 JMeter 方式典型场景固定枚举值业务中可穷举的选项CSV 数据集配置器、用户定义的变量地域编码、渠道来源、支付方式随机生成值每次请求都不同JMeter 函数__Random、__time、__UUID手机号、时间戳、流水号、随机金额上下游关联值前置接口响应正则提取器、JSON 提取器、XPath 提取器token、订单号、签名、会话ID环境配置值测试环境动态变化JMeter 属性、命令行参数域名、端口、超时时间、账号密码固定枚举值比较好理解业务上就那么几种情况用 CSV 拉一个列表出来一个虚拟用户跑一类数据能覆盖到不同分支。随机生成值适用于没有业务约束或者允许重复率很低的字段比如一个商品评价接口你可以让每个请求随机生成 1 到 5 星再用__Random拼上当前时间的毫秒值做评论编号。上下游关联值需要放在后置处理器里做千万别靠猜。环境配置值适合放到属性文件里用__P函数读取这样换环境压测时不用改脚本只要启动命令里加一个参数就行。这四类参数的共同点是它们最终都会变成一个可以被请求引用的变量。JMeter 里变量的引用格式是${变量名}你在请求体、URL、请求头、断言里都可以直接用。理解了这一层参数化的本质其实就是一句话把硬编码的常量剥离出来用变量替换再让变量按一定规则取值。2. 数据驱动参数化从 CSV 到 JMeter 函数的完整搭建2.1 参数化建模先设计测试数据搜索热词里有“参数化建模”这个词放到 JMeter 场景下我的理解是在动手配置组件之前先把测试数据当做一个数据模型来设计。这不是写代码而是在 Excel 里画一张表这张表的表头就是变量名每一行就是一条完整的业务数据。举个例子某个下单接口需要三个字段手机号、金额、优惠券类型。我先建一个order_data.csv文件第一行写变量名后面每行写数据mobile,amount,couponType 13800001111,99.00,1 13800002222,150.00,2 13800003333,88.00,1这个文件就是你的参数化模型。设计时有几个原则要守住。第一行数最好是你压测并发数的 1.5 倍以上。五十个线程并发准备一百行数据既能保证数据不重样又能避免 CSV 读完一遍后被迫循环。第二不要在字段里塞中文逗号、换行符这些特殊字符除非你后面配置了“允许带引号字段”否则 CSV 解析很容易把一行数据拆散。第三表头命名别用中文也最好别带空格否则在请求体里引用变量名时容易出各种小问题。CSV 文件准备好以后它和 JMeter 线程组之间的配合逻辑是这样的线程组每发起一个循环CSV 数据集配置器就自动读取下一行把这一行的数据赋值给对应变量。并发多、循环多的情况下每个虚拟用户拿到的是不同行这样请求就真正“错开”了。这也是 JMeter 里最主流、最好维护的数据驱动压测方式。2.2 CSV 数据集配置器的参数逐个说明在测试计划里添加“CSV 数据集配置器”后你会看到一堆配置项。我每次给团队讲解时都会说这几个字段别看都是英文组合起来其实决定了一轮压测的数据走向是否正确。文件名和文件编码这两项文件名建议优先用相对路径脚本和 CSV 文件放在同一个目录下迁移起来方便如果非要用绝对路径也要确认命令行运行时的工作目录。文件编码直接填utf-8千万不要留空留空时 JMeter 会按操作系统默认编码去读在 Windows 上很容易读出一堆乱码。变量名这一项如果你用 Excel 做了表头并且勾选了“忽略第一行”那么只需要在这里填上对应的列名用英文逗号分隔就行比如mobile,amount,couponType。如果文件没有表头也没有设置变量名JMeter 会把第一行数据当作变量名来读取这一点是很多新人踩坑的地方。分隔符默认是英文逗号如果文件里用的是制表符 Tab这里要改成\t。最需要注意的是“遇到文件结束符再次循环”和“停止线程”这两个选项。默认情况下CSV 读完最后一行后会重新回到第一行这样可以保证长跑压测时数据源不完但如果你的业务要求数据绝对不能重复那就要把“停止线程”设为 true让数据耗尽后对应线程停下来。实际项目中我更推荐保留默认的“再次循环”同时在数据量上做好准备否则一个线程组跑到一半忽然少了几个活跃线程吞吐量的曲线会非常难看。还有一项“线程共享模式”不同版本的 JMeter 里显示可能略有差异但核心是三种。所有线程共享同一份指针每个循环读取下一行数据分发最均匀当前线程组共享是让同一个线程组里的线程共享一份指针适合多线程组场景当前线程则让每个虚拟用户各自从头读文件适合每个用户需要固定使用同一组数据的场景。我的习惯是压测单个接口时选“所有线程”涉及到多组账号分别压测时就把 CSV 拆成多个文件各自挂在不同线程组下面。2.3 函数组合随机数、时间戳、线程号、UUIDCSV 适合管理业务数据但很多场景下我们不想准备那么多数据文件比如生成一个唯一流水号、生成一个随机星级评价用 JMeter 内置函数反而更快。打开 JMeter 菜单里的“函数助手对话框”能看到几十个内置函数我日常压测用得最频繁的就这五个__Random、__time、__threadNum、__UUID、__counter。__Random的写法是${__Random(1,100,score)}意思是生成 1 到 100 之间的随机整数存到变量score里。这个函数有个容易被忽略的特点随机范围是闭区间两个端点都可能取到。如果你想要一个可预期的随机手机号可以写${__Random(13500000000,13999999999,phone)}但要注意它并不能保证结果唯一并发场景下多个线程可能生成同一个手机号。想保证唯一性更靠谱的方案是用 CSV或者用__counter拼数。__time在造数据时很常用${__time(yyyy-MM-dd HH:mm:ss,time)}会生成当前时间的格式化字符串${__time(/1000,)}会生成十位秒级时间戳。和__threadNum、__counter组合起来就是一个不错的流水号生成器ORDER-${__time(yyyyMMddHHmmss,)}-${__threadNum}-${__counter(,)}这里__threadNum是当前线程的编号__counter是每个线程组里独立递增的计数器。组合出来的订单号既有时间维度也有并发维度在压测结果里一眼就能看出是哪个线程产生的请求。__UUID则适合用在需要全局唯一 ID 的接口比如消息推送的 messageId、文件上传的 taskId直接${__UUID()}就能拿到一个标准的 UUID 字符串不需要任何额外配置。函数还有一个好处是可以直接嵌套在请求体里比如 JSON 格式的请求体写成{ mobile: ${__Random(13500000000,13999999999,mobile)}, amount: ${__Random(1,100,amount)}, timestamp: ${__time(/1000,timestamp)} }JMeter 会在发送请求之前完成函数求值然后把值替换进请求体。这种用法比 CSV 更轻量适合那些对数据准确性要求不高的压测场景。2.4 用户定义的变量与用户参数静态与动态的分工JMeter 里有两处很容易混淆的组件一个是“用户定义的变量”另一个是“用户参数”。名字很像作用域和求值时机却完全不同选错了会让你排查半天都找不到变量为什么不变。“用户定义的变量”是一个配置元件放在线程组下面。它最大的特点是测试计划启动时求值一次之后整个压测过程中基本不再变化。你可以在里面定义域名、端口、公共请求头这些环境信息也可以定义固定的用户名集合。即使你在值里写了${__time(,)}它也只是在启动那一刻取一次时间后续所有请求拿到的都是同一个值。“用户参数”是一个前置处理器放在某个采样器下面。它会在每个采样器执行前重新求值。默认情况下它还带一个选项叫“每次迭代更新一次”如果你设置的是每次循环更新一次那同一线程在同一个循环内多次经过这个采样器时变量值不会变化只有进入下一轮循环才会刷新如果你需要每次请求都拿到新值就把这个选项关掉。这个组件非常适合在一个线程组里对不同接口使用不同随机参数的场景。举个实际例子你要压测一个“获取短信验证码”的接口每个虚拟用户每次循环都应该换一个手机号。这种情况下用“用户参数”放在请求节点下表达式写成${__Random(13500000000,13999999999,)}就能保证每轮循环拿到不同的手机号。相反如果你在“用户定义的变量”里放这个随机表达式那一百个线程从头到尾就只有一个手机号压测就变成了对一个号码的反复骚扰没有任何参考价值。3. 动态参数获取从响应里“拿值”的四种手段3.1 正则表达式提取器几乎万能的老办法压测中最常见的动态参数是登录 token它由服务端生成写在登录接口的响应里。后面的业务请求要在请求头里带上这个 token否则接口直接返回 401。这种场景靠 CSV 没法解决必须用后置处理器把响应里的值抓出来。正则表达式提取器是历史最久、兼容性最好的方案什么格式的响应都能处理。添加方式是在某个取样器上右键选择“添加 - 后置处理器 - 正则表达式提取器”。核心配置有四个字段正则表达式、模板、匹配数字、默认值。先看一个典型响应{ code: 0, data: { token: a1b2c3d4e5, expire: 7200 } }正则表达式可以写成token:(.*?)这里用了非贪婪匹配.*?表示从token:之后开始抓一直抓到下一个双引号为止。括号括起来的部分就是我们要提取的值。模板填$1$表示取第一个括号里的内容。匹配数字的意思是取第几个匹配结果填1表示取第一个如果你填0JMeter 会随机取一个匹配结果这在大部分场景下不是你想要的所以一般我都建议填1。默认值填一个容易识别的标记比如NOT_FOUND后面如果变量引用出来是这个值就说明提取失败一眼就能看出来。提取变量名填token后面在请求头里写成${token}就能直接使用。有些接口返回的是数组或者多个同名参数比如一次返回多条记录每条记录里都有id你想把这些 id 全部取出来循环使用可以把匹配数字填-1这样 JMeter 会把所有匹配结果存成带下标的变量id_1、id_2、id_3同时还会有一个id_matchNr记录总数。后面的请求可以用${__V(id_${i})}配合计数器来逐个引用。正则表达式提取器有一个风险点如果返回内容里有多个相同结构表达式写得不严谨容易抓错。所以我在实际项目里有个习惯抓 token 这类唯一值时会尽量带着前后上下文比如用token:([a-f0-9]{32})既能抓取到 32 位 hex 字符串又能避免匹配到其他字段。这个写法比.*?更保险只是需要你对业务格式有一点了解。3.2 JSON 提取器接口返回 JSON 时的首选现在大部分 RESTful 接口返回的都是 JSON 结构与其写正则表达式去字符串里抠不如直接用 JSON 提取器它按 JSONPath 表达式来定位节点可读性和稳定性都更好。添加方式和正则提取器一样在“后置处理器”里选择“JSON 提取器”。继续用上面那个登录接口的例子JSONPath 表达式填$.data.token变量名填token匹配数字同样填1默认值填NOT_FOUND。它不需要转义双引号也不需要关心 token 之后的字符JSON 结构只要不变提取就非常稳定。JSONPath 的匹配能力比想象中强。遇到数组结构比如{ data: { list: [ {id: 1001, name: A}, {id: 1002, name: B} ] } }想提取第一个 id表达式写$.data.list[0].id想提取所有 id写$.data.list[*].id。如果返回的 JSON 层级很深用递归写法$..id也可以把所有层的 id 全抓出来。匹配数字填-1时提取结果也会存成带下标的变量规则和正则提取器一致。用 JSON 提取器最大的优势是省心。过去用正则提取器处理嵌套结构时我要反复测试表达式换成 JSON 提取器以后只要响应格式是合法的 JSON表达式正确基本一次就能抓对。这里有个小提醒如果接口返回的不是标准 JSON比如在 HTML 里嵌了一段 JSON或者 JSON 前面有多余的空格和注释JSON 提取器会直接失败这时正则表达式提取器反而更可靠。两种工具不是替代关系而是互补关系我通常先看 Content-Type再决定用哪个。3.3 XPath 提取器处理 XML 响应的老伙计现在的后端服务里 XML 响应比较少但老系统、支付回调、SOAP 协议接口里仍然大量存在。XPath 提取器的思路和 JSON 提取器类似但针对的是 XML 文档结构。比如一个查询接口返回?xml version1.0 encodingUTF-8? response header resultCode0/resultCode /header body orderId2025001/orderId /body /response在 XPath 提取器里查询表达式写//body/orderId变量名填orderId就能提取到2025001。如果文档带有命名空间你要么用带命名空间的完整路径要么在设置里勾选“忽略命名空间”两种方式各有利弊。实际项目里我更喜欢勾选忽略命名空间因为大多数测试脚本并不关心 XML 的命名空间是否严格匹配只要定位到节点、拿到值就够了。还有一点要注意XPath 提取器在处理 HTML 响应时经常因为 HTML 不满足 XML 严格格式而失败。如果接口返回的是 HTML 页面里面藏着验证码、sessionId 或 hidden input 字段用正则表达式提取器往往比 XPath 提取器更靠谱因为 HTML 标签不规范的情况实在太多了。3.4 JSR223 与 BeanShell 断言在脚本里做参数判断与加工如果提取器和函数完成不了的动作就轮到脚本上场。搜索热词里的“jmeter beanshell断言”说的就是这类用法。简单理解后置处理器能从响应里拿参数断言能判断拿到的参数对不对而 JSR223 脚本可以把这两个动作揉在一起甚至还能对参数做二次加工。举个例子登录接口返回的 JSON 里有一个字段rgCode它不是一个纯字符串而是像{7356,p2p,pay}这样的结构需要我把里面的第二段取出来拼到后面的请求 URL 里。用 JSON 提取器也能做但要在多个后置处理器之间反复流转。用 JSR223 后置处理器就简单了def json new groovy.json.JsonSlurper().parseText(prev.getResponseDataAsString()) def code json.data.rgCode.tokenize(,) vars.put(channel, code[1].trim())这里prev是 JMeter 在当前采样器执行完后自动注入的变量指向采样器结果vars是变量管理对象put进去的变量后面请求就能用${channel}引用了。如果你想在一个脚本里同时完成断言可以用 JSR223 断言。比如判断业务码而不仅仅是 HTTP 状态码def json new groovy.json.JsonSlurper().parseText(prev.getResponseDataAsString()) if (json.code ! 0) { AssertionResult.setFailure(true) AssertionResult.setFailureMessage(业务返回码异常 json.code) }脚本逻辑看上很简单但我要提醒一点除非你在用 Java 8 之前的非常老的环境否则请尽量用 JSR223 配合 Groovy而不是 BeanShell。BeanShell 的性能很差在高压并发下会占用大量 CPU而且解释执行容易出线程问题。JSR223 里首选 Groovy脚本只编译一次后续执行走字节码性能比 BeanShell 高出一个数量级。我的习惯是能写 Groovy 就不碰 BeanShell。脚本里的vars对象只能操作 JMeter 变量它的作用域是当前线程。如果脚本里需要往其他位置传递值可以用props.put(key, value)存到 JMeter 属性里再用${__P(key,)}读取。属性是全局的适合跨线程组共享但要注意它的生命周期是整个测试计划用完记得清理。4. 实战排查变量作用域、乱码与命令行报错4.1 变量作用域与线程组之间如何传参新手做参数化时最容易碰到的坑不是不会配置而是变量拿到了却发现在另一个请求里取不到。JMeter 的变量作用域规则有一定隐蔽性我总结成三句话变量属于当前线程后置处理器提取的变量对该线程后续的采样器可见不同线程组之间不能直接访问对方的局部变量。提取器挂在哪个采样器节点下变量就从这个采样器之后开始生效。如果你把提取器挂在“登录请求”上面然后想在“订单请求”里引用顺序就反了变量值肯定是空。另外变量在同一个线程组内传递没问题但如果两个线程组各自有独立的登录请求和业务请求并且想复用同一个 token跨线程组直接引用${token}是拿不到的。跨线程组传递参数有一种通用方案用 JMeter 属性。先把 token 存到属性里props.put(token, vars.get(token))另一个线程组里通过${__P(token,)}来引用。这种写法适合不同线程组需要同一份基础信息的场景但要特别小心并发冲突——多个线程同时写同一个属性最终谁的值生效取决于执行顺序数据一致性不好控制。所以我的实际建议是如果不同线程组的业务数据本身是独立的就让它们各自登录、各自取 token不要强行共享。共享属性只在少数场景下用比如所有线程组都要带上同一个全局环境 token而这个 token 是通过专用登录接口获取的。4.2 CSV 中文乱码、BOM 与文件路径问题CSV 参数化最常见的三个问题几乎每个团队都遇到过中文乱码、Excel 保存造成的 BOM 头、文件路径找不到。中文乱码的根源几乎都在编码设置上。CSV 文件如果是 UTF-8 编码那 JMeter 里也要填utf-8如果文件是 GBK 编码配置器里就填gbk。最忌讳的是文件编码和配置器编码不一致请求发出去了服务端收到一堆乱码字符接口直接报参数错误。排查时先确认文件用什么编码保存再回头检查 CSV 数据集配置器里的文件编码这里填错后面的接口断言再怎么写都没用。BOM 头是个更隐蔽的坑。用 Windows 的记事本或某些 Excel 版本保存 UTF-8 CSV文件开头会自动加上一个不可见的标记字符JMeter 读取第一列表头时会把 BOM 一并读进去。结果就是你的变量名明明叫mobile引用${mobile}却总拿不到值会变成空或异常字符。解决办法有两个一是保存 CSV 时选择无 BOM 的 UTF-8 编码用 Notepad 或 VS Code 另存为时注意选项二是在“变量名”配置里手动填写带 BOM 字符的变量名。第二个办法太别扭了我一般直接用在线工具或者脚本把 CSV 批量转成无 BOM UTF-8。文件路径问题在命令行压测时尤其常见。在 GUI 里测试时相对路径可能没问题但用jmeter -n -t跑命令行时工作目录可能和 GUI 不一样相对路径就失效了。我的做法是把 CSV 文件路径放到 JMeter 属性里用__P读取。启动命令时加上参数jmeter -n -t test.jmx -l result.jtl -e -o report -JdataFile/data/csv/order_data.csv脚本里 CSV 数据集配置器的文件名填写${__P(dataFile,)}这样不管启动目录在哪都能正确读取文件。这个方案在分布式压测里同样适用每台压测机上指定不同的文件路径即可。4.3 压测时几种典型报错与排查路子新手压测时最常遇到的报错是org.apache.http.conn.HttpHostConnectException: Connect to ... failed。这个报错一出现很多人的第一反应是服务端挂了但排查顺序应该是反过来的先看请求的协议、域名、端口对不对再看目标机器能否连通最后才是服务端负载。我在项目里的排查步骤是这样的先用单个线程、单次循环跑一遍该请求排除脚本本身的问题然后在压测机上执行telnet 目标IP 端口确认网络连通性再检查 HTTP 请求里的连接超时和响应超时设置两个都别设得太长否则失败请求会在客户端堆积。如果这些都没问题再考虑是不是线程数设得过高压测机自己的连接数被占满了。很多连接报错根本不是服务器拒绝而是压测机本地的 socket 耗尽这时候加大压力毫无意义反而要把JMeter自带的连接数设置调一调。另一类是参数化的“空值”问题。请求发出去以后服务端返回参数错误看结果树发现变量是空的。这种情况九个来自三种原因第一CSV 里的变量名和脚本里引用的${变量名}不一致或者表头带了 BOM 导致变量名不匹配第二提取器没有执行成功默认值设为NOT_FOUND后一眼能看出来第三变量虽然提取到了但作用域不对上一个请求提取的值在下一个请求里没控制好先后顺序。排查时先在请求里加一个“调试采样器”把变量列表打出来所有变量名和当前值一目了然问题出在哪一层马上就能定位。还有一类和接口业务逻辑强相关的失败HTTP 状态码是 200但业务返回码是失败。这种场景只靠响应断言是抓不到的要靠 JSR223 断言判断业务码或者用 JSON 提取器把返回码提出来再和期望值做对比。搜索热词里专门提到“jmeter beanshell断言”就是因为很多人在这一步才明白默认断言只能检查协议层进不了业务层。4.4 GUI 布局错乱与命令行生成报告JMeter 在 Windows 高分屏下偶尔会出现界面布局错乱、控件重叠甚至撕裂的问题。这不是脚本写错了而是 Swing 组件和操作系统 DPI 缩放不兼容导致的。我遇到这个问题的处理顺序是先在菜单栏打开“选项 - 外观”切换到另一套主题很多场景下 Metal 主题能恢复正常如果不行再检查系统显示缩放是否设为了 125% 或 150%尝试把 JMeter 的启动脚本里加上 JVM 参数强制禁用高分屏缩放。Linux 上出现布局错乱则要优先检查字体环境很多精简版系统缺少中文字体装上字体包就解决了。这些小问题不影响测试结果但处理不好会非常影响排查效率。压测执行阶段我不建议一直开着 GUI 跑。JMeter 的官方建议也是压测用命令行模式因为 GUI 中各类监听器会把数据实时往界面上写CPU 消耗很大压测结果本来就该用命令行跑出来的数据说话。常用命令是jmeter -n -t test.jmx -l result.jtl -e -o report-n表示非 GUI 模式-t指定测试计划-l输出原始结果文件-e -o生成 HTML 格式的 Dashboard 报告。搜索结果里提到的“JMeter 5.6.3 生成测试报告”指的就是这个过程这个版本的 Dashboard 报告会自动生成吞吐量、响应时间分布、错误率等几十个核心图表已经能满足大部分压测汇报需求。至于“压测过程中如何查看压测接口的响应内容”我的经验是排查阶段在 GUI 里加“查看结果树”只勾选“错误”节点专门看失败请求的响应正式压测阶段则用“简单数据写入器”把响应数据落到文件里压测过程中直接tail -f文件看实时请求结果。查看结果树这种监听器在正式压测里千万不要全程开着它的内存开销极大压到最后经常是监听器先把 JMeter 自己压挂了。还有一个压测中很实用的排查方式在 JSR223 脚本里主动打印关键变量的值。比如每次发请求之前把请求体里的业务参数写到日志里配合jmeter -l的结果文件就能精确追溯到每一条请求用的什么参数、拿到了什么响应比盯着界面找根因快得多。最后再分享一个小技巧。不管用 CSV 还是函数做参数化数据量一定要留出余量。我见过不少项目在压测开始时数据刚好够用结果跑着跑着 CSV 循环到第一行业务上立刻出现重复数据后端开始返回“已存在”或直接限流整轮结果全废。我现在做压测前都会检查三件事CSV 的行数是否覆盖了并发数和循环次数的乘积、函数生成的数据是否可能重复、提取器的默认值会不会被错误引用。这三件小事检查完压测脚本的稳定性基本就上来了。参数化看着是个小功能但它是一轮压测能不能真实反映系统性能的地基地基不稳后面所有数据都不可信。