1. 压力测试概述
1.1 压力测试定义
压力测试（Stress Testing）是一种通过向系统施加超出正常预期负载的极端条件，观察系统在资源紧张、高并发、数据洪峰等极限场景下的行为表现与容错能力的测试方法。其核心目标是验证系统的稳定性边界与故障恢复能力，而非仅仅验证功能正确性。
关键定义：压力测试 = 在超载条件下，评估系统是否仍能维持可接受的响应水平，并在压力解除后能否自动恢复至正常状态。
1.2 压力测试的目的与价值
压力测试在软件开发生命周期中承担着质量守门员的角色，其核心目的与业务价值可归纳为以下五个维度：
| 维度 | 目的 | 业务价值 |
|---|---|---|
| 稳定性验证 | 确认系统在极限负载下不崩溃、不丢失数据 | 保障大促、秒杀等峰值场景的可用性 |
| 瓶颈定位 | 发现 CPU、内存、IO、网络等资源短板 | 指导容量规划与硬件采购决策 |
| 弹性评估 | 验证自动伸缩、降级、熔断等容错机制 | 降低运维故障响应成本 |
| 恢复验证 | 确认压力解除后系统能自动恢复正常 | 缩短故障恢复时间（MTTR） |
| SLA 达标 | 检验系统是否满足约定的性能服务等级 | 避免合同违约与客户流失 |
实践提示：压力测试的最佳时机是在系统上线前完成至少一轮完整压力测试，并在每次重大架构变更后回归执行。不要等到线上出现故障才想起做压力测试。
1.3 压力测试与负载测试的区别
压力测试与负载测试常被混淆，但二者在测试目标、负载模型和成功标准上存在本质差异。下表从六个关键维度进行对比：
| 对比维度 | 压力测试 | 负载测试 |
|---|---|---|
| 核心目标 | 找到系统崩溃点与恢复能力 | 验证系统在预期负载下的性能指标 |
| 负载模型 | 持续递增至超载，甚至超过峰值 200%~500% | 模拟真实用户行为，负载在预期范围内波动 |
| 关注指标 | 错误率、崩溃时间、恢复时间、资源耗尽点 | 响应时间、吞吐量、资源利用率、并发数 |
| 成功标准 | 系统不丢失数据、能自动恢复、不产生雪崩 | 所有指标满足 SLA 阈值（如 TP99 < 500ms） |
| 执行阶段 | 通常在负载测试之后，作为极限验证 | 作为常规性能验证，贯穿开发与预发布 |
| 典型场景 | 双11零点流量洪峰、数据库连接池耗尽 | 日常高峰时段 10000 用户并发访问 |
1.4 常见应用场景
压力测试在互联网、金融、物联网、游戏等众多行业中均有广泛应用。以下是六类典型场景：
- 电商大促（秒杀/抢购）：模拟数万用户同时下单，验证订单系统、库存系统、支付链路的抗压能力与数据一致性。
- 金融交易系统：在开市、闭市等集中交易时段，验证交易引擎在高并发委托下的撮合延迟与资金清算正确性。
- 流媒体直播：模拟百万级观众同时进入直播间，测试推流、转码、分发链路的带宽瓶颈与连接稳定性。
- 物联网设备接入：模拟海量设备同时上报数据，验证网关、消息队列、存储层的吞吐能力与去重机制。
- 游戏开服/合服：模拟大量玩家同时登录、创建角色、进入场景，测试登录服、场景服、数据库的承载上限。
- 云原生基础设施：验证 Kubernetes 集群在节点故障、Pod 驱逐、网络分区等异常场景下的自动伸缩与自愈能力。
常见误区：不要将压力测试等同于“把系统搞崩”。压力测试的核心价值在于可控地发现极限边界，而非破坏系统。每次压力测试前必须制定明确的回滚预案与监控告警策略。
1.5 压力测试的基本流程
一个标准的压力测试通常遵循以下六个步骤，形成闭环迭代：
- 场景定义：明确测试目标（如“数据库连接池耗尽后能否自动恢复”），确定负载模型与关键指标。
- 环境准备：搭建与生产环境尽可能一致的测试环境，部署监控工具（如 Prometheus + Grafana）。
- 脚本开发：使用 JMeter、Locust、Gatling 等工具编写压力脚本，模拟真实用户行为。
- 执行测试：从小负载开始逐步递增，持续观察系统状态，记录崩溃点与恢复时间。
- 结果分析：分析资源瓶颈、错误日志、慢查询、线程堆栈等数据，定位根因。
- 优化与回归：针对瓶颈进行代码、配置或架构优化，然后回归验证直至达标。