1.1 压力测试概述
1.1.1 压力测试的定义
压力测试（Stress Testing）是一种通过向系统施加超出其正常处理能力的负载，来观察系统在极限或异常条件下的行为、稳定性和恢复能力的软件测试方法。其核心目标是找出系统的“崩溃点”或“性能拐点”，并验证系统在极端压力下是否能够优雅地降级或恢复，而非直接崩溃导致数据丢失或服务中断。
核心定义公式： 压力测试 = 极限负载 + 异常条件 + 稳定性观察 + 恢复能力验证
1.1.2 压力测试的目的与价值
压力测试并非为了证明系统“能跑多快”，而是为了回答以下关键问题：
- 系统何时会崩溃？ —— 确定系统的最大容量上限。
- 崩溃前有何征兆？ —— 识别性能退化曲线（如响应时间陡增、错误率飙升）。
- 崩溃后能否恢复？ —— 验证自动伸缩、熔断、降级、重启等容错机制是否生效。
- 数据是否完整？ —— 确保在极端压力下不会发生数据错乱或丢失。
| 价值维度 | 具体说明 |
|---|---|
| 业务保障 | 避免大促、秒杀、突发流量时系统崩溃导致直接经济损失和品牌声誉受损。 |
| 架构验证 | 检验分布式架构的弹性伸缩、服务熔断、限流降级等设计是否有效。 |
| 容量规划 | 为硬件采购、云资源扩容、集群规模提供数据依据，避免过度投资或资源不足。 |
| 稳定性提升 | 提前暴露内存泄漏、线程死锁、连接池耗尽、数据库慢查询等隐蔽问题。 |
| 合规与SLA | 满足金融、医疗等行业的监管要求，确保系统在极端条件下仍能提供基本服务。 |
1.1.3 压力测试与负载测试的区别
压力测试与负载测试常被混淆，但二者在目标、方法和关注点上存在本质差异：
| 对比维度 | 压力测试 | 负载测试 |
|---|---|---|
| 核心目标 | 找到系统的崩溃点与恢复能力 | 验证系统在预期负载下的性能指标 |
| 负载特征 | 持续增加负载直至超过极限 | 模拟典型或峰值预期负载 |
| 关注指标 | 崩溃点、错误率、恢复时间、数据完整性 | 响应时间、吞吐量、资源利用率 |
| 测试场景 | 突增流量、资源耗尽、依赖服务故障 | 日常高峰、促销活动、平稳增长 |
| 结果导向 | 系统是否安全失效？能否自动恢复？ | 系统是否满足性能基线？ |
| 典型问题 | OOM、死锁、雪崩、数据丢失 | 响应慢、CPU高、数据库连接池满 |
一句话区分： 负载测试回答“系统能处理多少？”，压力测试回答“系统最多能承受多少以及崩溃后怎么办？”
1.1.4 压力测试在软件生命周期中的位置
压力测试并非仅在系统上线前执行一次，而是贯穿软件生命周期的多个关键阶段：
常见误区： 很多团队只在上线前做一次压力测试，发现并修复问题后就认为万事大吉。实际上，随着代码迭代、数据增长、用户行为变化，系统的压力承受能力会动态变化。压力测试应成为持续交付流水线中的一环，实现“持续压力测试”。
1.1.5 压力测试的典型应用场景
在实际项目中，压力测试通常聚焦于以下高风险的业务场景：
- 电商大促/秒杀： 瞬间涌入数十倍于平时的流量，考验订单系统、库存系统、支付系统的极限承载能力。
- 金融交易系统： 开盘、收盘、重大行情波动时的高频交易请求，要求系统在极端负载下仍能保证数据一致性和事务完整性。
- 社交媒体热点事件： 突发新闻、明星事件导致用户并发访问量暴增，考验内容分发、评论、推送等服务的稳定性。
- 物联网设备接入： 百万级设备同时上报数据，考验网关、消息队列、数据存储的写入和吞吐能力。
- 游戏开服/新版本发布： 大量玩家同时登录、创建角色、进入游戏，考验登录服务、游戏逻辑服务器的并发处理能力。
实战建议： 在开始压力测试之前，务必先明确“压力测试通过标准”。例如：在持续5分钟的极限压力下，系统响应时间不超过5秒，错误率不超过2%，且停止压力后5分钟内系统自动恢复至正常状态。没有明确标准的压力测试，结果往往难以落地。