1. 压力测试概述

压力测试（Stress Testing）是性能工程中用于评估系统在极端或超预期负载下行为的关键手段。它通过向系统施加超过正常峰值的并发请求、数据吞吐或资源消耗，观察系统何时失效、如何失效以及失效后能否恢复。与常规负载测试不同，压力测试的核心目标不是验证系统在预期负载下的响应时间，而是探索系统的极限边界与失效模式。

1.1 压力测试的定义

压力测试是一种破坏性的性能测试方法，它持续增加系统负载直至系统达到瓶颈或崩溃，从而识别系统的最大承载能力、资源耗尽点以及降级行为。压力测试通常关注以下维度：

• 并发极限：系统能同时处理的最大用户会话数或连接数。
• 吞吐量天花板：单位时间内系统能处理的最大事务数（TPS/QPS）。
• 资源耗尽点：CPU、内存、磁盘I/O、网络带宽等资源达到100%利用率时的负载水平。
• 失效恢复能力：系统在过载崩溃后能否自动恢复，以及恢复时间（RTO）。

1.2 压力测试的目的

压力测试在软件工程中承担以下核心目的：

1.3 压力测试与负载测试的区别

两者常被混淆，但在测试目标、负载模型、通过标准和执行策略上存在本质差异。下表从多个维度进行对比：

1.4 压力测试在软件生命周期中的位置

压力测试并非孤立的活动，它嵌入在软件开发的多个阶段中。下图展示了压力测试在典型软件生命周期中的触发节点与数据流向：

从图中可以看出，压力测试在功能测试完成且负载测试基线建立之后执行，其输出直接驱动性能调优、容量规划和运维策略的制定。同时，压力测试结果会形成反馈回路，在调优后需要重新执行以验证改进效果。

1.5 压力测试的典型触发场景

在实际项目中，以下场景通常会触发压力测试的执行：

• 大促/秒杀活动前：验证系统能否承受数倍于日常的流量洪峰。
• 架构重大变更后：微服务拆分、数据库分库分表、缓存引入等变更后需要重新评估极限。
• 第三方依赖变更：上游服务或中间件版本升级后，需要确认新组件的容量上限。
• 混沌工程演练：结合故障注入，验证系统在压力+故障双重打击下的表现。
• 容量规划周期：每季度或每半年对系统进行压力测试，更新容量模型。

1.6 压力测试的输入与输出

一次完整的压力测试需要明确的输入工件和产出物，以保证测试的可重复性和可追溯性：