性能测试数据构造实战：从Jmeter基础到海量数据生成策略

1. 项目概述：为什么测试数据构造是性能测试的“命门”？

做性能测试的朋友都知道，脚本录制、参数化、断言、监听器这些环节一个都不能少。但很多人，尤其是刚入行的朋友，最容易轻视或者搞砸的环节，恰恰是“测试数据构造”。你可能花了大半天调通了脚本，一上压力，要么是数据库主键冲突脚本报错，要么是缓存命中率奇高结果毫无参考价值，要么就是数据量太小根本模拟不出真实场景的负载。这些问题，十有八九都出在数据上。

我干了十多年性能测试，踩过最多的坑，不是Jmeter本身有多难用，而是“数据”没准备好。性能测试的本质是模拟真实用户行为对系统施加压力，而用户行为的核心载体就是数据。没有贴近生产环境的数据模型、数据量和数据分布，你的压测结果就是空中楼阁，甚至可能误导研发团队做出错误的优化决策。比如，你用一个只有10条记录的订单表去压测一个分页查询接口，数据库索引可能根本用不上，响应时间自然好看，但上线后数据量上来，性能立刻雪崩。

所以，这个系列我们就深挖一下，在2024年的技术环境下，如何用Jmeter以及其他辅助手段，构造出“以假乱真”的高质量测试数据。这不仅仅是学会几个Jmeter配置项那么简单，它涉及到对业务的理解、对技术的选型，以及对“真实”二字的执着追求。无论你是刚接触Jmeter的新手，还是想优化现有流程的老鸟，相信这个系列都能给你带来一些实实在在的启发和可落地的方案。

2. 测试数据构造的核心思路与设计原则

在动手之前，我们必须先想清楚：我们要构造什么样的数据？为什么这么构造？一套好的测试数据方案，背后一定有一套清晰的设计逻辑。

2.1 明确数据构造的四大核心目标

构造数据不是盲目地生成一堆随机字符串，它必须有明确的目标导向。我总结为以下四点：

1. 真实性：这是最高原则。数据必须尽可能模拟生产环境的特征。包括数据格式（如手机号、身份证号、邮箱的规则）、数据长度、数据间的关联关系（如用户ID与订单的归属关系）、以及数据的业务状态分布（如订单中待支付、已发货、已完成等状态的比例）。不真实的数据会导致测试场景失真，例如，用连续的ID去测试缓存，可能全部命中，而生产环境是离散的，缓存命中率会低得多。
2. 可重复性：性能测试往往需要多次执行以对比优化前后的效果。这就要求每次测试使用的数据集合必须是确定的、可复现的。你不能这次用A数据集跑出结果A，下次用随机生成的B数据集跑出结果B，然后说系统性能变了。可控和可重复是进行科学对比实验的基础。
3. 独立性：测试数据应该与生产数据、以及其他测试任务的数据隔离。绝对不能直接使用或污染生产数据库。同时，并行执行的多个性能测试任务之间，其使用的数据也应互不干扰，避免因数据争用导致测试结果异常。
4. 可扩展性：当我们需要模拟百万、千万级用户时，数据构造方案必须能高效、低成本地生成海量数据。同时，方案应该易于维护和调整，比如当业务字段增加时，能快速更新数据生成逻辑。

2.2 常见数据构造方案对比与选型

明确了目标，我们来看看有哪些“兵器”可以选择。每种方案都有其适用场景和优缺点。

实操心得：在实际项目中，我几乎不会只采用单一方案，而是“组合拳”。比如，核心业务流（如下单、支付）采用“数据库预置+Jmeter查询”保证数据关联真实性；而对于一些用户画像信息（如姓名、地址），则用JSR223+Faker库在脚本运行时动态生成，以减轻数据准备的压力并增加随机性。理解每种工具的边界，进行混合搭配，才是高效之道。

2.3 数据量级与分布模型设计

确定了用什么工具，接下来要确定生成多少数据，以及数据如何分布。这里有两个关键概念：

1. 数据量级：这需要根据业务规模和测试目标来定。一个基本的估算方法是：测试数据量 ≥ （虚拟用户数 × 每个用户迭代中涉及的核心数据操作数）。例如，1000个并发用户，每个用户执行10次登录操作，那么你至少需要1万个独立的、可用的测试账号。为了保险起见，通常会准备2-3倍的量，以防止数据争用。
2. 数据分布模型：真实世界的数据很少是均匀分布的。你需要考虑：
   • 业务分布：例如，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文件中管理是更优雅的方式。

1. 创建CSV文件：用Excel或文本编辑器创建，例如user_data.csv，内容如下：

   username,password,email test_user_1,pass123,user1@example.com test_user_2,pass456,user2@example.com ...（成千上万行）

2. 配置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是所有线程共享同一个文件指针，按顺序取数据，确保数据不重复。这是最常用的模式。

3. 在请求中引用：在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.count=100），非常适合用于动态调整测试规模。在脚本中，你可以用${__P(thread.count, 50)}来引用，第二个参数是默认值。

将环境配置与测试数据、业务逻辑分离，是编写可维护、可移植性能测试脚本的好习惯。

4. 高级数据构造：JSR223与外部库集成

当内置功能无法满足复杂需求时，JSR223元件是我们的“瑞士军刀”。它允许我们在Jmeter中直接运行Java、Groovy、JavaScript等代码。强烈推荐使用Groovy语言，因为它在Jmeter中性能最好，兼容性最佳。

4.1 使用Groovy和Faker库生成逼真数据

虽然Jmeter内置函数能生成随机数据，但不够“真实”。Faker是一个强大的库，可以生成看起来非常真实的姓名、地址、公司、文本等。

1. 添加JSR223依赖：为了在Jmeter中使用外部Jar包，你需要将下载的faker.jar（可以从Maven仓库下载）放入Jmeter安装目录的lib/ext文件夹下，然后重启Jmeter。
2. 编写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))

3. 在请求中引用变量：在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 数据库预生成与批量操作

这是最主流、最高效的海量数据构造方法。

1. 设计数据表结构：完全克隆或简化生产环境的表结构。
2. 编写数据生成脚本：使用你熟悉的语言（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 {i+batch_size} records’) cursor.close() conn.close()

3. 建立数据索引：数据插入完成后，一定要根据测试查询场景建立合适的索引。一个没有索引的千万级表，性能测试结果会惨不忍睹，但这并不是被测系统的真实表现。
4. 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 必须避开的五个“坑”

1. 数据未脱敏/包含敏感信息：这是红线！绝对禁止将任何包含真实个人信息、手机号、身份证号的数据用于测试，即使是在内网环境。必须使用Faker等工具生成模拟数据，或对获取的生产数据进行严格的、不可逆的脱敏处理。
2. 数据量级不足：用几百条数据去压测一个设计容量为百万级的系统，结果毫无意义。数据量必须足够大，使得数据库索引能够正常工作，缓存命中率趋于稳定，才能反映出系统的真实性能。
3. 数据分布过于均匀：用完全随机的均匀分布数据，往往测不出系统的瓶颈。真实业务数据通常是倾斜的（幂律分布）。你需要构造热点数据（如少数热门商品被频繁访问），这样才能测试出缓存的有效性、数据库热点行的锁竞争等问题。
4. 忽略数据关联性：只参数化一个字段，而其他关联字段使用固定值。例如，用随机用户ID下单，但收货地址却是固定的。这会导致业务逻辑错误（如地址不属于该用户），使得大量请求失败，压测无法继续。
5. 数据准备耗时过长，影响测试效率：如果每次跑测试前都要花1小时生成数据，那CI/CD就无从谈起。要将数据准备过程脚本化、自动化，并考虑使用Docker容器快速构建带数据的测试数据库镜像，实现环境的秒级拉起。

6.2 提升效率的三个最佳实践

1. 分层构造，按需加载：不要试图一次性准备好所有数据。将数据分为“基础数据”（如用户、商品类目，变化少，可长期存在）和“业务数据”（如订单、交易流水，随测试生成和清理）。基础数据预置，业务数据可以由脚本在测试过程中按需生成（如通过调用业务接口），这样更灵活，也更贴近真实场景。
2. 监控数据状态：在压测过程中，不仅要监控系统的CPU、内存，还要监控数据库的连接数、慢查询、锁等待，以及缓存命中率、消息队列堆积等。这些指标能直接告诉你，你的测试数据是否“打”到了系统的正确位置。例如，如果你发现数据库锁等待激增，可能是你的数据构造导致了过多的热点行更新。
3. 将数据构造纳入CI/CD流水线：在自动化测试平台中，将数据准备作为压测任务的一个前置步骤。可以使用Ansible、Terraform等工具，自动化地创建数据库实例、执行初始化SQL脚本、导入基础数据。确保每一次性能测试都在一个干净、一致的数据环境中开始。

数据构造是性能测试中技术含量最高、最需要耐心和业务理解的工作之一。它没有一成不变的银弹，最好的方案永远是贴合你当前业务场景和技术栈的那一个。多思考、多实践、多总结，当你构造的数据能让压测场景无限逼近真实时，你得到的性能报告，才会是那个能真正指导优化、支撑决策的可靠依据。