性能测试中，单场景、混合场景、多场景是逐层递进、覆盖不同测试目标的核心场景类型，技术要求在场景定义、负载模型、数据设计、监控指标、执行策略、验收标准上差异显著，以下从核心维度展开详细说明。

一、单场景压测（单接口 / 单链路）

1. 核心定义与目标

• 单场景：聚焦单个独立接口或单一完整业务链路（如登录、商品查询、下单），无其他业务干扰。

• 核心目标：

• 验证单接口 / 单链路的基准性能、负载能力、极限阈值。

• 定位单体性能瓶颈（代码、数据库、连接池、缓存）。

• 为混合 / 多场景提供性能基线数据。

2. 技术要求

（1）场景设计

• 接口范围：仅包含 1 个接口或 1 条连续业务链（如 “提交订单” 全流程）。

• 参数设计：

• 固定参数 + 动态参数化（用户 ID、商品 ID、订单号），避免单一数据缓存失真。

• 业务逻辑完整（含前置依赖、Token/Cookie 会话保持）。

• 加压策略：

• 基准压测：1~10 并发，小流量验证可用性，记录基线 RT、TPS。

• 负载递增：阶梯加压（如 10→50→100→200→500 并发），每阶稳定 5~10 分钟。

• 极限压测：加压至 CPU≥70%、RT 陡增、错误率上升，找到性能拐点。

• 稳定性验证：拐点前 80% 负载，持续运行 1~2 小时。

（2）数据要求

• 测试数据量≥生产 30%，热点数据分布与线上一致。

• 无脏数据、无重复请求，避免锁冲突与数据错乱。

（3）核心监控指标

• 应用层：TPS、平均 / 95%/99% 响应时间 (RT)、错误率（≤0.1%）、成功率。

• 服务器：CPU（≤70%）、内存（≤80%）、磁盘 I/O、网络带宽。

• 数据库：连接池使用率、慢 SQL、锁等待、事务日志、缓存命中率。

• JVM / 容器：GC 频率、堆内存、线程池队列、超时异常。

（4）验收标准

• 基准：RT 达标（如核心接口≤500ms）、成功率 100%。

• 负载：目标并发下 RT 线性增长、无明显抖动、错误率≈0。

• 极限：明确最大承载并发 / TPS，无宕机、无内存泄漏、无死锁。

二、混合场景压测（多业务按比例并发）

1. 核心定义与目标

• 混合场景：多个核心业务 / 接口按真实业务比例同时并发（如电商：浏览 40%+ 搜索 20%+ 加购 15%+ 下单 20%+ 支付 5%）。

• 核心目标：

• 模拟线上真实用户行为，验证多业务并发下的整体性能、资源争抢、依赖瓶颈。

• 评估系统最优 TPS（CPU≈70% 时的最大有效吞吐量）。

• 发现单场景未暴露的问题（跨接口锁、连接池耗尽、服务级联超时）。

2. 技术要求

（1）场景设计

• 业务比例：基于日志 / 埋点分析线上流量占比，严格按权重配比。

• 并发模型：

• 总并发按比例拆分到各子场景（公式：并发用户数 = 目标 TPS × 平均       RT）。

• 独立思考时间（Think Time）：浏览 1~2s、加购 2~3s、下单 3~5s、支付 5~8s。

• 集合点策略：关键事务（下单 / 支付）启用集合点，模拟集中并发。

• 加压策略：

• 基线：总并发 10%~20%，验证脚本与比例正确性。

• 递增：每阶增加 20% 总并发，稳定 5~10 分钟，观察整体指标。

• 峰值：压至日常峰值 1.2~2 倍，验证高峰期承载能力。

• 稳定性：最优负载下持续 4~8 小时。

（2）数据与依赖要求

• 数据一致性：跨接口参数关联（如支付用下单生成的订单 ID）。

• 依赖隔离：第三方服务（支付、短信）用 Mock 或影子环境，避免污染线上。

• 资源配比：测试环境硬件 / 配置与生产 1:1 或等比例缩放。

（3）核心监控指标

• 整体指标：总 TPS、加权平均 RT、整体错误率（≤0.3%）。

• 分场景指标：各子场景 TPS、RT、成功率、资源占比。

• 资源争抢：CPU / 内存 / 连接池      / 磁盘 I/O 的争抢与瓶颈（如数据库被下单占满）。

• 服务依赖：调用链耗时、服务超时、熔断降级、限流生效情况。

（4）验收标准

• 整体：加权 RT 达标、成功率≥99.7%、无雪崩、无级联失败。

• 资源：CPU≤75%、内存≤85%、数据库连接池≤80%、无死锁。

• 比例：各子场景 TPS 与设计比例偏差≤±10%。

三、多场景压测（多业务独立 / 组合批量验证）

1. 核心定义与目标

• 多场景：多个独立业务场景批量执行（串行 / 并行），覆盖核心 + 非核心 + 异常场景，或多版本 / 多集群对比。

• 核心目标：

• 全面覆盖：验证所有核心业务的性能基线、稳定性、兼容性。

• 对比评估：多场景 / 多环境 / 多版本性能差异、容量规划。

• 批量回归：版本迭代后快速验证所有业务性能无退化。

2. 技术要求

（1）场景设计

• 场景清单：全量核心场景 + 关键边缘场景（大查询、批量操作、异常请求）。

• 执行模式：

• 串行：单场景依次执行，互不干扰，适合基线、回归、对比。

• 并行：高优先级场景并行，模拟多业务同时高峰，验证极限资源承载。

• 负载策略：

• 基线：各场景单基准并发，批量采集基线数据。

• 负载：各场景按目标负载并行 / 串行加压。

• 峰值：关键场景叠加峰值，验证系统最大承受力。

• 稳定性：重点场景长时间（8~24 小时）稳定压测。

（2）数据与环境要求

• 数据隔离：多场景数据独立，避免相互污染（影子库 / 独立表空间）。

• 环境一致性：所有场景在相同配置环境执行，保证对比有效性。

• 批量参数化：统一数据池、动态参数、会话管理，支持多场景复用。

（3）核心监控指标

• 全场景汇总：各场景基线 / 负载 / 峰值指标矩阵、性能排名。

• 资源全局视图：多场景并发下系统整体资源水位、瓶颈分布。

• 性能对比：版本 / 环境 / 场景间 RT、TPS、资源占用的差异率。

• 异常统计：各场景错误类型、频率、失败链路、重试 / 降级效果。

（4）验收标准

• 全覆盖：所有场景执行完成，无遗漏、无阻塞。

• 基线达标：各场景基准性能符合 SLA，无性能退化。

• 并行稳定：多场景并行无资源死锁、无服务崩溃、无大面积失败。

• 对比合格：新版本 / 新环境性能差异≤±5%，无显著劣化。

四、三类场景核心差异对比

表格

五、通用技术底线（三类场景均需满足）

1. 环境一致性：硬件、配置、数据量、依赖与生产等比对齐。

2. 数据真实性：参数化、动态关联、无固定值、热点分布仿真。

3. 加压规范：梯度递增、稳定观察、不突增突降、避免结果失真。

4. 监控全面：应用、服务器、数据库、JVM、调用链全维度覆盖。

5. 结果可复现：脚本、数据、配置可归档，问题可复现、可复测。

6. 风险控制：压测前预案、压测中监控、压测后数据清理、服务恢复。