负载模型决定了测试结果的可靠性——用错误的负载模型测试，再精准的数据也是"准确但无用"的结果。银行系统的负载模型设计需要基于生产监控数据精确还原业务特征，而非凭经验拍脑袋。
一个完整的负载模型包含三个核心要素：
系统承受负载的方式，决定了压力的施加特征：
| 模型 | 特点 | 适用场景 | 银行实例 |
|---|---|---|---|
| 阶梯递增 | 逐步增加并发数，每阶梯稳态运行5-15分钟 | 寻找性能拐点、容量摸底 | 核心系统上线前阶梯加压 |
| 恒定并发 | 固定并发数持续运行2-24小时 | 稳定性测试、内存泄漏检测 | 年终决算前7×24小时稳定性验证 |
| 突发脉冲 | 短时间（30秒-5分钟）极高并发冲击 | 秒杀、抢购、峰值保护验证 | 理财发售、纪念币预约峰值模拟 |
| 波浪式 | 周期性增减并发，模拟日间业务波动 | 24小时业务曲线模拟 | 模拟工作日08:00-22:00业务起伏 |
| 业务混合 | 多交易类型按生产占比混合执行 | 真实业务场景还原 | 转账30%+查询50%+缴费10%+其他10% |
基于生产环境监控数据统计各交易类型的实际调用占比。关键步骤：从生产日志提取交易量分布→按TPS计算各交易占比→设计混合场景的线程组权重。
模拟真实用户操作间隔，避免"机器人式"的密集请求。银行柜面交易思考时间通常5-30秒，网银交易1-5秒。忽略思考时间会导致测试TPS虚高、偏离真实场景。
操作：采集过去30天的生产交易日志，按小时统计TPS、各交易占比、平均响应时间，生成24小时业务基线曲线。选取P95日作为"常规峰值"、历史最高日作为"极端峰值"设计测试场景。
操作：先用低并发验证负载模型的业务比例准确性，检查各交易的TPS分布是否与生产数据一致，调整线程组权重后再正式加压。