1. 压力测试基础：定义、目的与重要性
1.1 压力测试的定义
压力测试（Stress Testing）是一种通过向系统施加超出正常预期负载的极端条件，观察系统在资源紧张、高并发或数据量激增等场景下的行为表现的非功能性测试方法。其核心目标是发现系统在极限状态下的崩溃点、恢复能力以及性能瓶颈。
关键特征：压力测试关注的是“系统何时会失效”以及“失效后如何表现”，而非“系统在正常负载下响应有多快”。
1.2 压力测试的目的
- 发现系统瓶颈：识别CPU、内存、磁盘I/O、网络带宽或数据库连接池等资源的极限阈值。
- 验证稳定性与恢复性：测试系统在过载后能否自动恢复，或需要人工干预的程度。
- 评估容错能力：检查系统在部分组件失效（如节点宕机、服务超时）时的降级表现。
- 确定安全冗余：为生产环境的容量规划提供数据支撑，明确系统还能承受多少突发流量。
- 满足合规要求：金融、医疗等行业的监管机构常要求系统必须通过特定压力测试。
1.3 压力测试的重要性
| 维度 | 重要性说明 |
|---|---|
| 用户体验 | 避免大促、秒杀等场景下系统雪崩，导致用户流失。 |
| 业务连续性 | 确保核心交易链路在极端流量下仍能保持基本可用。 |
| 成本控制 | 提前发现资源浪费或不足，避免盲目扩容或过度投资。 |
| 风险规避 | 降低因系统崩溃导致的数据丢失、订单错乱等重大事故概率。 |
实战提示：压力测试不是一次性活动，应伴随版本迭代持续进行，尤其在架构变更或流量预估增长时。
1.4 与负载测试、容量测试的区别
这三者常被混淆，但关注点、测试方法和目标有本质差异。下表从多个维度进行对比：
| 对比维度 | 压力测试 | 负载测试 | 容量测试 |
|---|---|---|---|
| 核心目标 | 找到系统崩溃点与恢复能力 | 验证系统在预期负载下的性能指标 | 确定系统能处理的最大并发用户数或数据量 |
| 负载特征 | 持续增加负载直至超过极限 | 模拟典型生产负载（如平均负载、峰值负载） | 逐步增加负载，找到拐点 |
| 关注指标 | 错误率、恢复时间、资源耗尽点 | 响应时间、吞吐量、资源利用率 | 最大并发数、最大TPS、最大数据存储量 |
| 测试场景 | 突增流量、资源降级、长时间过载 | 日常高峰、促销活动、正常业务波动 | 容量规划、扩容决策、资源预算 |
| 结果用途 | 稳定性评估、容错设计、应急预案 | 性能验收、SLA验证、调优依据 | 容量基线、扩容阈值、成本估算 |
常见误区：很多人认为压力测试就是“把系统搞挂”，实际上压力测试更关注“挂掉的过程”和“挂掉后的行为”，而非单纯制造故障。
1.5 三种测试的关系示意图
下图展示了压力测试、负载测试和容量测试在负载递增过程中的定位关系：
1.6 实战案例：电商秒杀场景
以电商平台的秒杀活动为例，三种测试的典型应用如下：
- 负载测试：模拟1万用户同时抢购，验证系统响应时间是否在2秒以内。
- 容量测试：逐步增加并发用户数，发现系统在1.5万用户时TPS达到峰值，之后开始下降。
- 压力测试：将并发用户数提升至3万，观察系统是否出现连接池耗尽、数据库死锁、服务雪崩，并记录恢复时间。