1. 项目概述为什么测试数据构造是性能测试的“命门”做性能测试的朋友都知道脚本录制、参数化、断言、监听器这些环节一个都不能少。但很多人尤其是刚入行的朋友最容易轻视或者搞砸的环节恰恰是“测试数据构造”。你可能花了大半天调通了脚本一上压力要么是数据库主键冲突脚本报错要么是缓存命中率奇高结果毫无参考价值要么就是数据量太小根本模拟不出真实场景的负载。这些问题十有八九都出在数据上。我干了十多年性能测试踩过最多的坑不是Jmeter本身有多难用而是“数据”没准备好。性能测试的本质是模拟真实用户行为对系统施加压力而用户行为的核心载体就是数据。没有贴近生产环境的数据模型、数据量和数据分布你的压测结果就是空中楼阁甚至可能误导研发团队做出错误的优化决策。比如你用一个只有10条记录的订单表去压测一个分页查询接口数据库索引可能根本用不上响应时间自然好看但上线后数据量上来性能立刻雪崩。所以这个系列我们就深挖一下在2024年的技术环境下如何用Jmeter以及其他辅助手段构造出“以假乱真”的高质量测试数据。这不仅仅是学会几个Jmeter配置项那么简单它涉及到对业务的理解、对技术的选型以及对“真实”二字的执着追求。无论你是刚接触Jmeter的新手还是想优化现有流程的老鸟相信这个系列都能给你带来一些实实在在的启发和可落地的方案。2. 测试数据构造的核心思路与设计原则在动手之前我们必须先想清楚我们要构造什么样的数据为什么这么构造一套好的测试数据方案背后一定有一套清晰的设计逻辑。2.1 明确数据构造的四大核心目标构造数据不是盲目地生成一堆随机字符串它必须有明确的目标导向。我总结为以下四点真实性这是最高原则。数据必须尽可能模拟生产环境的特征。包括数据格式如手机号、身份证号、邮箱的规则、数据长度、数据间的关联关系如用户ID与订单的归属关系、以及数据的业务状态分布如订单中待支付、已发货、已完成等状态的比例。不真实的数据会导致测试场景失真例如用连续的ID去测试缓存可能全部命中而生产环境是离散的缓存命中率会低得多。可重复性性能测试往往需要多次执行以对比优化前后的效果。这就要求每次测试使用的数据集合必须是确定的、可复现的。你不能这次用A数据集跑出结果A下次用随机生成的B数据集跑出结果B然后说系统性能变了。可控和可重复是进行科学对比实验的基础。独立性测试数据应该与生产数据、以及其他测试任务的数据隔离。绝对不能直接使用或污染生产数据库。同时并行执行的多个性能测试任务之间其使用的数据也应互不干扰避免因数据争用导致测试结果异常。可扩展性当我们需要模拟百万、千万级用户时数据构造方案必须能高效、低成本地生成海量数据。同时方案应该易于维护和调整比如当业务字段增加时能快速更新数据生成逻辑。2.2 常见数据构造方案对比与选型明确了目标我们来看看有哪些“兵器”可以选择。每种方案都有其适用场景和优缺点。方案核心原理优点缺点适用场景Jmeter 内置函数/配置元件使用Jmeter自带的__Random,__CSVRead,__time等函数或CSV Data Set Config元件。简单快捷与脚本集成度高无需额外环境。生成逻辑简单难以构造复杂关联数据海量数据准备麻烦。参数化需求简单数据量小如千级以下快速验证脚本。数据库预置与查询提前用SQL脚本或工具生成数据存入测试库Jmeter脚本中通过JDBC Request取样器查询使用。数据真实性强可利用数据库能力生成复杂关联数据。依赖数据库数据准备阶段耗时数据清理和重置较麻烦。需要高度真实、关联性强的业务数据且有一定数据准备时间。自定义Java代码JSR223在Jmeter的JSR223 Sampler或前置处理器中编写Groovy/Java代码调用第三方库生成数据。灵活性极高能实现任何复杂逻辑可利用丰富的开源库。需要一定的编程能力脚本调试相对复杂。需要生成符合特定业务规则如身份证号校验、或调用外部服务的复杂数据。专用数据生成工具使用像Mockaroo,Faker(Python库)DataFactory等专门的数据模拟工具。专业性强能生成非常逼真的模拟数据种类繁多。需要额外学习和集成有些工具可能涉及版权或在线服务依赖。对数据真实性要求极高且需要快速生成大量结构化测试数据模板。流量录制与回放通过代理如Jmeter HTTP代理服务器录制生产或预发环境的真实流量过滤后直接用于压测。数据100%真实最能反映真实用户行为。涉及数据安全与脱敏问题数据量受录制流量限制可能包含测试不需要的噪音。有安全的、脱敏后的流量来源且追求极致真实的测试场景。实操心得在实际项目中我几乎不会只采用单一方案而是“组合拳”。比如核心业务流如下单、支付采用“数据库预置Jmeter查询”保证数据关联真实性而对于一些用户画像信息如姓名、地址则用JSR223Faker库在脚本运行时动态生成以减轻数据准备的压力并增加随机性。理解每种工具的边界进行混合搭配才是高效之道。2.3 数据量级与分布模型设计确定了用什么工具接下来要确定生成多少数据以及数据如何分布。这里有两个关键概念数据量级这需要根据业务规模和测试目标来定。一个基本的估算方法是测试数据量 ≥ 虚拟用户数 × 每个用户迭代中涉及的核心数据操作数。例如1000个并发用户每个用户执行10次登录操作那么你至少需要1万个独立的、可用的测试账号。为了保险起见通常会准备2-3倍的量以防止数据争用。数据分布模型真实世界的数据很少是均匀分布的。你需要考虑业务分布例如90%的订单可能集中在10%的热门商品上大部分用户是沉默用户只有小部分是高频用户。在构造商品ID、用户ID时应该模拟这种二八分布或长尾分布。Jmeter的__Random函数是均匀分布此时就需要用到__javaScript或 JSR223 来编写非均匀分布的随机逻辑。时间分布如果测试场景与时间相关如查询最近一周的订单那么你的数据时间戳就不能是随机的而应该集中在一个时间区间内并模拟自然的时间流逝密度如白天多夜晚少。设计数据模型时一定要拉着产品经理或业务分析师一起讨论理解真实的业务画像这比任何技术都重要。3. 基于Jmeter的核心数据构造技术详解理论说完了我们进入实战环节。Jmeter本身提供了丰富的数据处理能力我们先把它自带的“武器库”摸透。3.1 利用内置函数实现基础参数化Jmeter的函数是快速实现参数化的利器。它们以__双下划线开头可以在任何输入字段中调用。__Random: 生成随机数。${__Random(1000,9999,orderId)}会生成一个1000到9999之间的随机数并存入变量orderId。这是最常用的函数之一。__RandomString: 生成随机字符串。${__RandomString(10,abcdefghijklmnopqrstuvwxyz,username)}生成一个10位长的、由小写字母组成的用户名。__time: 获取当前时间戳。${__time(,)}获取13位毫秒时间戳${__time(yyyy-MM-dd HH:mm:ss,)}获取格式化的时间字符串。常用于构造时间相关的参数。__threadNum: 获取当前线程虚拟用户的编号。这在需要让每个用户使用不同数据时非常有用例如user_${__threadNum}。__counter: 计数器。${__counter(FALSE,)}全局递增${__counter(TRUE,)}每个用户独立递增。常用于生成唯一的序列ID。注意事项__Random等函数在每次调用时都会重新计算。如果你在一个请求中多次引用${__Random(...)}每次的值都可能不同。如果需要一个值在同一个请求的多个地方复用应该先将其赋值给一个变量如{__Random(…, myVar)}然后其他地方引用${myVar}。3.2 CSV Data Set Config经典外部数据驱动当数据量较大或数据关系复杂时将数据放在外部CSV文件中管理是更优雅的方式。创建CSV文件用Excel或文本编辑器创建例如user_data.csv内容如下username,password,email test_user_1,pass123,user1example.com test_user_2,pass456,user2example.com ...成千上万行配置CSV Data Set Config在Jmeter线程组中添加该配置元件。Filename: CSV文件的完整路径。建议使用相对路径如./data/user_data.csv方便脚本迁移。File encoding: 文件编码通常为UTF-8。Variable Names: 定义变量名用逗号分隔与CSV文件列头对应。如上例填写username,password,email。Delimiter: 分隔符默认为逗号,。Recycle on EOF?: 读到文件末尾后是否循环。性能测试中通常设置为True除非你明确要求每个虚拟用户只使用一次数据。Stop thread on EOF?: 读到文件末尾后是否停止线程。如果Recycle on EOF为True此项无效。Sharing mode: 共享模式。All threads是所有线程共享同一个文件指针按顺序取数据确保数据不重复。这是最常用的模式。在请求中引用在HTTP请求的参数中使用${username},${password}来引用变量。常见问题与排查问题脚本报错提示变量未定义。排查首先检查CSV文件路径是否正确。其次检查Variable Names是否与引用名完全一致大小写敏感。最后在View Results Tree监听器中查看请求的Request页签确认变量是否被正确替换。一个更稳妥的做法是在请求前添加一个Debug Sampler查看所有变量的值。问题压测时出现大量数据重复或主键冲突。排查这通常是Sharing mode设置不当。如果希望每个线程使用独立的数据集应该为每个线程准备独立的CSV文件或者使用__threadNum作为文件名的一部分并在Sharing mode中选择Current thread。更常见的做法是在数据库中预置海量数据然后让所有线程通过JDBC随机查询这能更好地模拟真实并发。3.3 用户自定义变量与属性管理全局配置对于一些全局的、固定的测试数据如服务器地址、端口、基础URL等使用用户自定义变量或属性来管理更为清晰。用户自定义变量在Test Plan或Thread Group级别添加配置元件。这里定义的变量会在其作用域内初始化一次。适用于固定不变的配置值。属性Jmeter属性是全局的可以通过__P()函数或${__property(property.name)}来引用。它们可以在命令行启动Jmeter时通过-J参数传入如-Jthread.count100非常适合用于动态调整测试规模。在脚本中你可以用${__P(thread.count, 50)}来引用第二个参数是默认值。将环境配置与测试数据、业务逻辑分离是编写可维护、可移植性能测试脚本的好习惯。4. 高级数据构造JSR223与外部库集成当内置功能无法满足复杂需求时JSR223元件是我们的“瑞士军刀”。它允许我们在Jmeter中直接运行Java、Groovy、JavaScript等代码。强烈推荐使用Groovy语言因为它在Jmeter中性能最好兼容性最佳。4.1 使用Groovy和Faker库生成逼真数据虽然Jmeter内置函数能生成随机数据但不够“真实”。Faker是一个强大的库可以生成看起来非常真实的姓名、地址、公司、文本等。添加JSR223依赖为了在Jmeter中使用外部Jar包你需要将下载的faker.jar可以从Maven仓库下载放入Jmeter安装目录的lib/ext文件夹下然后重启Jmeter。编写JSR223脚本添加一个JSR223 PreProcessor到你的HTTP请求下或放在线程组级别取决于变量作用域需求。// 引入Faker类 import com.github.javafaker.Faker // 创建Faker实例可以指定Locale如Locale.CHINA Faker faker new Faker() // 生成模拟数据 String fullName faker.name().fullName() // 例如张三 String cellPhone faker.phoneNumber().cellPhone() // 符合中国规则的手机号 String idNumber faker.idNumber().valid() // 生成一个有效的身份证号格式符合规则但非真实 String city faker.address().city() // 城市名 String streetAddress faker.address().streetAddress() // 街道地址 // 将数据存入Jmeter变量供后续请求使用 vars.put(fakeName, fullName) vars.put(fakePhone, cellPhone) vars.put(fakeIdNum, idNumber) vars.put(fakeCity, city) // 如果你需要生成JSON格式的请求体 def requestBody [ name: fullName, phone: cellPhone, idCard: idNumber, address: [ city: city, detail: streetAddress ] ] // 将对象转换为JSON字符串 import groovy.json.JsonOutput vars.put(requestBodyJson, JsonOutput.toJson(requestBody))在请求中引用变量在HTTP请求体中可以直接使用${fakeName}或者将Body Data设置为${requestBodyJson}。实操心得使用Faker等库时要注意其生成数据的“真实性”边界。它生成的是格式正确、看起来真实的数据但并非真实存在的个体信息如身份证号。这完全满足测试数据脱敏和安全要求。另外在JSR223元件中务必把“Language”选为“groovy”并把耗时的初始化代码如创建Faker对象放在if (vars.get(‘FAKER_INSTANCE’) null)这样的判断里然后存入变量中避免每次请求都重复初始化提升脚本性能。4.2 处理复杂关联与业务逻辑性能测试脚本经常需要处理数据关联比如先注册一个用户获取其userID然后用这个userID去登录、下单。Jmeter的正则表达式提取器或JSON提取器是处理这类关联的标准做法。但有时提取后的数据还需要进一步处理。例如注册后返回的userId是纯数字但下单接口要求一个带前缀的字符串如ORD_userId“_”时间戳。我们可以在JSON提取器后跟一个JSR223 PostProcessor来处理// 假设前一个提取器已将userId存入变量 ‘userId’ String rawUserId vars.get(“userId”) // 生成时间戳 String timestamp String.valueOf(System.currentTimeMillis()) // 构造订单号 String orderNo “ORD_” rawUserId “_” timestamp // 存入新变量 vars.put(“orderNumber”, orderNo) // 也许你还需要一个在未来时间生效的过期时间 import java.time.* def expiryTime LocalDateTime.now().plusDays(7).format(java.time.format.DateTimeFormatter.ISO_LOCAL_DATE_TIME) vars.put(“expiryTime”, expiryTime)这样你就实现了灵活的数据转换和业务逻辑封装让主请求脚本保持简洁。5. 海量测试数据的准备与管理策略面对百万、千万级的数据需求在Jmeter脚本运行时逐条生成是不现实的会极大增加脚本的启动时间和内存消耗。正确的做法是“预置数据运行时消费”。5.1 数据库预生成与批量操作这是最主流、最高效的海量数据构造方法。设计数据表结构完全克隆或简化生产环境的表结构。编写数据生成脚本使用你熟悉的语言Python、Java、Shell等连接测试数据库利用Faker库或其它数据生成工具批量插入数据。Python示例使用pymysql和faker:import pymysql from faker import Faker import random fake Faker(‘zh_CN’) conn pymysql.connect(host‘test-db’, user‘root’, password‘123456’, database‘perf_test’) cursor conn.cursor() # 批量插入用户数据 batch_size 10000 total_records 1000000 for i in range(0, total_records, batch_size): data [] for _ in range(batch_size): username fake.user_name() str(i) # 加后缀确保唯一 email fake.email() phone fake.phone_number() data.append((username, email, phone)) sql “INSERT INTO user (username, email, phone) VALUES (%s, %s, %s)” cursor.executemany(sql, data) conn.commit() print(f’Inserted {ibatch_size} records’) cursor.close() conn.close()建立数据索引数据插入完成后一定要根据测试查询场景建立合适的索引。一个没有索引的千万级表性能测试结果会惨不忍睹但这并不是被测系统的真实表现。Jmeter脚本调用在Jmeter中使用JDBC Connection Configuration配置数据库连接池然后在JDBC Request中编写SQL来获取数据。例如SELECT id FROM user ORDER BY RAND() LIMIT 1可以随机获取一个用户ID。对于更高并发的场景可以预先为每个线程或线程组分段分配好ID范围避免ORDER BY RAND()带来的性能开销。5.2 数据池化与高效使用策略有了海量数据如何在压测中高效、无冲突地使用是关键。分段取用根据虚拟用户数线程数将数据表的主键范围进行分段。例如有100万用户数据1000个线程。可以创建1000个数据段每个段约1000个用户。在线程启动时通过__threadNum计算出该线程应使用的数据段然后在SQL中使用WHERE id BETWEEN ? AND ?来查询。这完全避免了数据争用和锁竞争。缓存预热如果被测系统有缓存如Redis在正式压测前可以先运行一个“预热”线程组用小并发量将热点数据如热门商品信息、用户基础信息查询一遍使其加载到缓存中。这样正式压测时的性能表现才更贴近系统稳定运行后的状态。数据清理与重置自动化测试流程中必须有数据清理环节。可以在测试计划的tearDown Thread Group中执行清理SQL或者更佳实践是每次测试使用一个独立的数据库schema或容器测试完成后整体销毁重建保证环境纯净。5.3 利用中间件和缓存构造数据对于一些特殊场景数据可能不在数据库而是在消息队列、缓存或者搜索引擎里。Kafka/RocketMQ如果需要测试消息消费的性能可以预先用生产端工具向指定Topic灌入海量消息。Jmeter也有对应的插件如Apache Kafka插件可以用于生产和消费消息。Redis使用redis-cli或编写脚本通过MSET、Pipeline等方式批量初始化缓存数据。Jmeter可以通过JSR223 Sampler调用Jedis或Lettuce客户端来操作Redis用于测试缓存击穿、雪崩等场景。Elasticsearch使用ES的_bulkAPI批量导入测试文档。这对于测试搜索、聚合查询的性能至关重要。6. 性能测试数据构造的常见陷阱与最佳实践最后分享一些我踩过坑后总结的经验希望能帮你绕开这些“暗礁”。6.1 必须避开的五个“坑”数据未脱敏/包含敏感信息这是红线绝对禁止将任何包含真实个人信息、手机号、身份证号的数据用于测试即使是在内网环境。必须使用Faker等工具生成模拟数据或对获取的生产数据进行严格的、不可逆的脱敏处理。数据量级不足用几百条数据去压测一个设计容量为百万级的系统结果毫无意义。数据量必须足够大使得数据库索引能够正常工作缓存命中率趋于稳定才能反映出系统的真实性能。数据分布过于均匀用完全随机的均匀分布数据往往测不出系统的瓶颈。真实业务数据通常是倾斜的幂律分布。你需要构造热点数据如少数热门商品被频繁访问这样才能测试出缓存的有效性、数据库热点行的锁竞争等问题。忽略数据关联性只参数化一个字段而其他关联字段使用固定值。例如用随机用户ID下单但收货地址却是固定的。这会导致业务逻辑错误如地址不属于该用户使得大量请求失败压测无法继续。数据准备耗时过长影响测试效率如果每次跑测试前都要花1小时生成数据那CI/CD就无从谈起。要将数据准备过程脚本化、自动化并考虑使用Docker容器快速构建带数据的测试数据库镜像实现环境的秒级拉起。6.2 提升效率的三个最佳实践分层构造按需加载不要试图一次性准备好所有数据。将数据分为“基础数据”如用户、商品类目变化少可长期存在和“业务数据”如订单、交易流水随测试生成和清理。基础数据预置业务数据可以由脚本在测试过程中按需生成如通过调用业务接口这样更灵活也更贴近真实场景。监控数据状态在压测过程中不仅要监控系统的CPU、内存还要监控数据库的连接数、慢查询、锁等待以及缓存命中率、消息队列堆积等。这些指标能直接告诉你你的测试数据是否“打”到了系统的正确位置。例如如果你发现数据库锁等待激增可能是你的数据构造导致了过多的热点行更新。将数据构造纳入CI/CD流水线在自动化测试平台中将数据准备作为压测任务的一个前置步骤。可以使用Ansible、Terraform等工具自动化地创建数据库实例、执行初始化SQL脚本、导入基础数据。确保每一次性能测试都在一个干净、一致的数据环境中开始。数据构造是性能测试中技术含量最高、最需要耐心和业务理解的工作之一。它没有一成不变的银弹最好的方案永远是贴合你当前业务场景和技术栈的那一个。多思考、多实践、多总结当你构造的数据能让压测场景无限逼近真实时你得到的性能报告才会是那个能真正指导优化、支撑决策的可靠依据。