3. 参数化基础：为什么需要参数化？

在容量压测脚本开发中，参数化是区分“玩具脚本”与“生产级脚本”的第一道分水岭。没有参数化的脚本，本质上只是一台“数据复读机”，无法模拟真实用户的行为多样性，更无法触发系统在不同数据分布下的性能瓶颈。

3.1 硬编码数据的三大局限性

所谓硬编码数据，是指在脚本中直接写入固定的字符串、数字或 JSON 结构，例如：

// 硬编码示例：所有虚拟用户都使用相同的用户名和商品ID
let username = "test_user_001";
let productId = "P10086";
let payload = JSON.stringify({
  userId: username,
  sku: productId,
  quantity: 1
});

这种写法在调试阶段可以快速验证接口连通性，但一旦进入容量压测阶段，会立刻暴露出以下三个致命问题：

3.2 参数化的核心价值

参数化是将脚本中的固定数据替换为可动态变化的变量，这些变量可以从外部数据源（CSV 文件、JSON 数组、数据库查询结果、API 响应等）按规则读取。在容量压测中，参数化承担着四个不可替代的角色：

1. 数据多样性：每个 VU 每次迭代都使用不同的数据组合，模拟真实用户行为。
2. 负载均衡验证：通过不同的 key 分布，检验分库分表、一致性哈希、缓存分片的实际效果。
3. 业务场景覆盖：通过参数组合（如不同商品类目、不同用户等级、不同支付方式）触发完整的业务逻辑链路。
4. 水位口径对齐：在容量规划中，不同水位（如 30%、60%、80%、100% 峰值）需要对应不同的数据量级和分布特征，参数化是实现这一映射的基础设施。

3.3 参数化在容量压测中的具体意义

从容量压测的“水位口径”视角来看，参数化不仅仅是“换数据”，更是对压测模型精度的直接保障。以下从三个维度展开：

3.3.1 数据分布与水位口径的映射

容量压测通常按“水位”划分场景：30% 水位（日常均值）、60% 水位（日常峰值）、80% 水位（大促峰值）、100% 水位（极限容量）。不同水位不仅需要调整并发数，更需要调整数据特征：

3.3.2 避免“数据缓存效应”对结果的污染

当所有 VU 使用相同数据时，系统会逐渐将这部分数据“缓存热化”——数据库缓存、CDN 缓存、本地缓存全部命中，压测结果会呈现虚假的高性能。一旦上线真实流量，数据分布完全不同，缓存命中率骤降，系统瞬间被打垮。参数化通过以下方式消除这种污染：

• 缓存键分散：不同 VU 使用不同的 userId、sessionId，避免所有请求命中同一个缓存分片。
• 冷热数据混合：参数化数据集中包含一定比例的“冷数据”（从未被访问过的 key），模拟真实场景中的缓存未命中。
• 数据生命周期管理：在长时间压测中，参数化数据可以按时间窗口轮换，模拟数据过期、淘汰、重建的过程。

3.3.3 支撑“多场景组合”的压测设计

容量压测不是单一接口的压测，而是多个业务场景的并发组合。参数化使得不同场景可以共享同一套数据池，同时保持数据隔离：

// 多场景参数化示例：登录场景与下单场景共享用户池
const users = new SharedArray('users', function () {
  return JSON.parse(open('./data/users.json'));
});

export default function () {
  // 场景A：登录（使用用户A的数据）
  let userA = users[__VU % users.length];
  login(userA.username, userA.password);

  // 场景B：下单（使用用户B的数据，与登录用户不同）
  let userB = users[(__VU + 1) % users.length];
  let product = products[__ITER % products.length];
  placeOrder(userB., product.sku, 1);
}

这种设计确保了：

• 每个 VU 在登录和下单时使用不同的用户身份，避免单用户并发操作导致的业务异常。
• 用户池和商品池独立管理，可以分别控制不同维度的数据分布。
• 通过 __VU 和 __ITER 的组合索引，实现伪随机但可复现的数据分配。