1. 压力测试概述
1.1 压力测试的定义
压力测试（Stress Testing）是一种通过向系统施加超出正常预期负载的极端条件，观察系统在资源紧张、高并发、数据洪峰等极限场景下的行为表现与稳定性的测试方法。其核心目标是找出系统的崩溃点、恢复能力以及降级表现，而非验证功能正确性。
关键定义：压力测试 = 在超载条件下，验证系统能否优雅地失败并恢复，而不是直接崩溃或数据损坏。
1.2 压力测试的目的
- 发现系统瓶颈：定位 CPU、内存、磁盘 I/O、网络带宽、数据库连接池等资源的极限阈值。
- 验证降级与熔断机制：确认系统在超载时是否按预期触发限流、降级、熔断等自我保护策略。
- 评估恢复能力：测试系统在压力释放后能否自动恢复正常服务，以及恢复所需时间。
- 防止雪崩效应：识别单点故障是否会扩散至整个服务集群，导致级联崩溃。
- 满足 SLA 与合规要求：验证系统在极端流量下仍能保证核心交易不丢失、数据不损坏。
1.3 压力测试的核心价值
| 价值维度 | 具体说明 | 业务收益 |
|---|---|---|
| 风险前置 | 在上线前暴露极端场景下的崩溃隐患 | 避免生产事故，降低故障修复成本 |
| 容量规划依据 | 提供系统最大承载能力的量化数据 | 指导硬件采购与弹性伸缩策略 |
| 架构韧性验证 | 检验分布式架构的容错与自愈能力 | 提升系统整体可用性与用户信任度 |
| 性能基线建立 | 形成极限场景下的性能基准数据 | 为后续版本迭代提供对比参考 |
实践提示：压力测试不是一次性活动，应纳入 CI/CD 流水线，每次重大架构变更或流量预估增长时重新执行。
1.4 压力测试与负载测试、容量测试的区别
这三类测试常被混淆，但关注点、测试方法和目标有本质差异。下表从多个维度进行对比：
| 对比维度 | 压力测试 | 负载测试 | 容量测试 |
|---|---|---|---|
| 核心目标 | 找到系统崩溃点与恢复能力 | 验证系统在预期负载下的性能表现 | 确定系统最大可承载容量 |
| 负载特征 | 持续增加负载直至系统失效 | 模拟正常峰值负载（如 80% 上限） | 阶梯式增加负载，寻找拐点 |
| 关注指标 | 错误率、恢复时间、降级行为 | 响应时间、吞吐量、资源利用率 | 最大并发用户数、TPS 上限 |
| 测试场景 | 突发流量、资源耗尽、依赖故障 | 日常高峰、促销活动、定时任务 | 扩容评估、资源规划、预算审批 |
| 通过标准 | 系统不崩溃、数据不丢失、可自动恢复 | 响应时间 < SLA 阈值，错误率 < 1% | 找到最大容量点，并留有余量 |
| 典型工具 | Chaos Monkey、Locust（高并发模式） | JMeter、Gatling、k6 | LoadRunner、wrk、ab |
常见误区：不要将压力测试与负载测试混为一谈。负载测试回答“系统能跑多快”，压力测试回答“系统能扛多狠”。容量测试则回答“系统最多能接多少”。
1.5 三类测试的关系示意图
下图展示了压力测试、负载测试、容量测试在负载递增曲线上的不同关注区域：
1.6 压力测试的典型应用场景
- 电商大促：模拟双十一、秒杀等瞬间流量洪峰，验证订单系统与支付链路的稳定性。
- 流媒体直播：测试直播间百万级并发观看、弹幕发送、礼物赠送等极端场景。
- 金融交易系统：验证开盘、收盘等时间点的集中交易压力，确保不丢单、不错账。
- 物联网平台：模拟百万设备同时上报数据，测试消息队列与数据存储的吞吐极限。
- 云原生基础设施：验证 Kubernetes 集群在节点故障、Pod 驱逐、网络分区等场景下的自愈能力。
实战建议：构建压力测试特征清单时，优先从业务历史流量峰值、运营活动计划、架构评审风险点三个来源提取压力场景。