4. 压测用例设计原则：业务场景建模、用户行为模拟、数据驱动与参数化

压测用例不是简单的“发请求、看TPS”。在真实后端部署场景中，压测用例必须反映生产流量的真实面貌。本章围绕四个核心原则展开：业务场景建模、用户行为模拟、数据驱动与参数化。这四个原则共同决定了压测结果的可信度与可复现性。

4.1 业务场景建模：从接口列表到业务流

业务场景建模是压测用例设计的起点。它要求测试人员从“单个接口”的思维中跳出来，转向“用户完整业务路径”的视角。一个典型的电商下单场景，至少包含：商品浏览 → 加入购物车 → 结算 → 支付 → 订单确认。每个环节的流量比例、依赖关系、数据状态都不同。

4.2 用户行为模拟：思考时间、并发模型与状态保持

用户行为模拟是压测用例的“灵魂”。仅仅把请求发出去是不够的，必须模拟真实用户的操作节奏、并发到达模式以及会话状态保持。常见的模拟维度包括：

• 思考时间（Think Time）： 用户两次操作之间的间隔。生产环境中，思考时间通常服从对数正态分布，而非固定值。
• 并发到达模型： 用户到达率可以是泊松分布、固定速率或基于生产日志的复现模式。恒定并发（如 100 线程同时发请求）是最不真实的模型。
• 会话状态保持： 用户登录后的 Token、Session、Cookie 需要在压测过程中正确传递。状态丢失会导致大量 401/403 错误，污染压测数据。

4.3 数据驱动：从固定数据到数据池

数据驱动是压测用例可复用的关键。固定数据会导致缓存命中率失真、数据库热点锁竞争、以及测试结果不可复现。数据驱动要求压测用例从外部数据源（CSV、数据库、API 响应）动态读取测试数据。

数据驱动的主要模式包括：

• 唯一数据池： 每个虚拟用户使用不同的数据（如不同用户 ID、不同商品 ID），避免数据竞争。
• 数据轮询： 多个虚拟用户循环使用数据池中的数据，适用于数据量有限但需要模拟多用户场景。
• 数据关联： 从上一个请求的响应中提取数据，作为下一个请求的输入（如从登录响应中提取 Token）。

// 数据驱动示例：从 CSV 读取用户数据
// 使用 testing 框架的 DataSource 注解
@Test
@DataSource(file = "users.csv", format = DataFormat.CSV)
public void testUserLogin(TestContext ctx) {
    String username = ctx.getData("username");
    String password = ctx.getData("password");
    
    // 每个迭代使用不同的用户数据
    Response resp = httpPost("/api/login")
        .body("{\"username\":\"" + username + "\",\"password\":\"" + password + "\"}")
        .execute();
    
    // 数据关联：提取 Token 供后续请求使用
    String token = resp.jsonPath().getString("data.token");
    ctx.setSessionData("token", token);
}

4.4 参数化：让压测用例具备弹性

参数化是数据驱动的进阶形式。它不仅包括测试数据的动态化，还包括压测配置的动态化。参数化让同一个压测用例可以在不同环境、不同负载模式下运行，而无需修改代码。

参数化的典型应用场景：

4.5 四个原则的协同关系

业务场景建模、用户行为模拟、数据驱动与参数化不是孤立的四个步骤，而是一个有机整体。它们之间的协同关系如下：

• 业务场景建模 定义了“测什么”——业务路径、流量比例、数据状态。
• 用户行为模拟 定义了“怎么测”——思考时间、并发模型、状态保持。
• 数据驱动 提供了“用什么测”——动态数据池、数据关联、数据轮询。
• 参数化 提供了“怎么复用”——环境参数、负载参数、业务参数的动态注入。

在实际项目中，建议按照以下顺序逐步完善压测用例：

1. 从生产日志中提取 Top 3 业务路径，完成初步的场景建模。
2. 为每个路径配置合理的思考时间分布和并发到达模型。
3. 建立数据池，确保每个虚拟用户使用独立数据。
4. 将环境参数、负载参数提取到配置文件中，实现参数化。
5. 运行基线压测，验证用例的真实性（对比生产环境的响应时间分布、错误率模式）。
6. 根据基线结果调整权重、思考时间、数据池大小，迭代优化。