LoadRunner的参数化是指将脚本中的常量值（如用户名、密码、商品ID、查询条件等）替换为变量（参数），并让这些变量在脚本运行时从数据源（如文件、数据库、内部列表）中获取不同的值。

为什么要做参数化？

性能测试的目的是模拟真实用户行为。如果不做参数化所有虚拟用户都会使用完全相同的数据去访问服务器，这会导致测试结果失真，甚至无法发现系统的短板。原因：

1. 真实业务场景

在实际生产环境中，每个用户的身份、操作对象都是不同的。如：

1000个用户同时登录，不可能都用同一个账号。

100个用户同时查询订单，不可能都查同一个订单号。

如果所有虚拟用户都使用相同的数据，服务器处理的是重复请求，这无法反映真实负载下的资源消耗（如数据库连接池、缓存命中率、锁竞争等）。参数化后，每个用户的数据都是唯一的，更贴近真实场景。

2. 服务器缓存效应

现代系统大量使用缓存（如Redis、CDN、数据库查询缓存）来提升性能。如果所有虚拟用户都请求同一个资源（如首页、商品详情页），服务器的缓存命中率会异常高，导致测试结果过于乐观。

如：1000个用户同时访问同一个商品详情页，第一用户触发数据库查询后，后续999个用户可能直接从缓存返回，响应时间极短。但这不代表真实场景-真实场景中，1000个用户访问的是1000个不同的商品，缓存无法全部命中。通过参数化，让每个用户请求不同的资源，才能准确考虑系统在缓存压力下的真实表现。

3. 处理服务器端的唯一性约束

很多业务场景要求输入数据在系统中是唯一的，如：

注册接口：用户名、手机号、邮箱必须唯一

下单接口：订单号不能重复

支付接口：同一笔订单不能被重复支付

如果不做参数化，使用固定数据执行多次，必然触发服务器端的唯一性检查，导致大量事务失败（返回用户名已存在订单已支付等错误），测试无法不断运行。

4. 关联数据依赖

业务流程后续操作往往依赖前一步返回的动态数据。虽然关联技术用于捕获这些动态值，但有些数据是动态且多值的-如，用户登录后，系统返回该用户的购物车中所有商品ID，后续操作需要从中随机选择一个商品进行结算。这时就需要将捕获到的商品ID列表参数化，让不同用户或不同迭代使用不同的商品ID。

5. 数据驱动测试

参数化将测试数据和脚本思路分离。当需要调整测试数据时（如更换一批测试账号、扩大商品ID范围），只需修改数据源（如Excel文件、数据库表），无需改动脚本代码。这种设计提高了脚本的可维护性。