压测基础：压力测试的定义、类型与关键指标
压力测试（Performance Testing / Stress Testing）是容量规划与巡检脚本的基石。只有准确理解压测的定义、分类与核心指标，才能设计出有效的巡检脚本，并为后续的容量建模提供可靠数据。
一、压力测试的定义
压力测试是通过模拟真实用户或系统负载，观察系统在预期或超预期并发下的行为、响应时间与资源消耗，从而评估系统稳定性、可靠性与性能瓶颈的测试活动。其核心目标不是“测到系统崩溃”，而是找到系统在崩溃前的安全边界与退化模式。
容量规划视角： 压测数据是容量模型的输入。没有压测，容量规划就是“拍脑袋”。
二、压力测试的三大类型
不同类型的压测关注不同的系统行为。下表总结了三种最核心的压测类型及其在容量规划中的用途：
| 类型 | 英文名称 | 核心目的 | 负载模式 | 容量规划用途 |
|---|---|---|---|---|
| 负载测试 | Load Testing | 验证系统在预期正常负载下的表现 | 逐步增加并发至目标值，保持稳定 | 确认当前容量是否满足SLA |
| 压力测试 | Stress Testing | 找到系统的极限与崩溃点 | 持续增加并发直至系统出现错误或降级 | 确定系统最大容量与安全水位线 |
| 耐久性测试 | Endurance / Soak Testing | 验证系统在长时间运行下的稳定性 | 中等负载持续运行数小时至数天 | 发现内存泄漏、资源耗尽等长期问题 |
三、三种压测类型的流程对比
下图展示了三种压测类型在负载变化与时间轴上的典型模式：
四、关键性能指标
压测结果必须量化为可对比的指标。以下是容量规划中最核心的四个指标：
| 指标 | 全称 | 定义 | 容量规划意义 |
|---|---|---|---|
| TPS | Transactions Per Second | 系统每秒处理的事务数（通常指完整业务事务） | 直接反映系统处理业务的能力，是容量模型的核心输出 |
| QPS | Queries Per Second | 系统每秒处理的查询或请求数（通常指单次接口调用） | 用于评估接口级吞吐量，与TPS结合可分析事务复杂度 |
| RT | Response Time | 从发送请求到收到完整响应所经过的时间（通常取平均值或P99） | 影响用户体验，RT突增往往是容量不足的前兆信号 |
| 错误率 | Error Rate | 失败请求数占总请求数的百分比 | 超过阈值（如1%）即表示系统已进入不稳定区，需触发扩容 |
五、指标之间的关系
四个指标并非孤立存在。下图展示了它们在压测过程中的典型联动关系：
六、巡检脚本中的指标采集要点
在编写容量压测巡检脚本时，需要针对上述指标设计采集逻辑：
- TPS/QPS： 从压测工具（如 JMeter、wrk、Locust）的聚合报告中获取，或通过中间件埋点（如 Prometheus + Grafana）实时采集。
- RT： 记录平均值、P95、P99 三个分位值。P99 比平均值更能反映尾部延迟问题。
- 错误率： 区分业务错误（如 HTTP 500）与超时错误（如连接超时）。巡检脚本应分别统计。
- 资源指标： 同步采集 CPU、内存、磁盘 IO、网络带宽，用于关联分析。
实战经验： 在巡检脚本中设置“三级告警阈值”——RT 超过基线 1.5 倍时告警（黄色），超过 2 倍时触发自动扩容（橙色），错误率超过 1% 时立即熔断（红色）。
七、压测类型与指标的对应关系
不同的压测类型应重点关注不同的指标组合：
| 压测类型 | 重点关注指标 | 次要关注指标 | 典型阈值参考 |
|---|---|---|---|
| 负载测试 | TPS、RT（平均值） | 错误率、CPU使用率 | RT < 200ms，错误率 < 0.1% |
| 压力测试 | TPS（拐点）、RT（P99） | 错误率、内存使用率 | 找到TPS下降前的最大并发数 |
| 耐久性测试 | 错误率趋势、内存增长趋势 | TPS稳定性、GC频率 | 错误率无增长，内存无泄漏 |
注意： 不要只关注平均值。在容量规划中，P99 响应时间和最大错误率才是决定扩容策略的关键指标。平均值会掩盖尾部延迟问题。