性能、负载、压力三个非功能性测试的目标部分重叠、实施工具也有重叠，常被混淆对待。这里会明确界定三者的核心差异与适用场景。
三者对比
| | 性能测试 Performance Testing | 负载测试 Load Testing | 压力测试 Stress Testing |
| 定义 | 评估系统在特定负载下的响应性、速度、稳定性、可伸缩性和资源使用效率的测试活动 | 模拟系统在 预期或典型 生产负载下的运行情况，评估其行为是否符合性能要求 | 将系统置于 超出其设计极限 的极端负载下，观察其行为，特别是失败模式和恢复能力 |
| 目标 | * 验证系统是否满足既定的性能指标（如响应时间、吞吐量）。 * 识别性能瓶颈（CPU、内存、I/O、网络、数据库等）。 * 为系统调优和容量规划提供基线数据。 | * 验证系统在正常或高峰用户/事务负载下能否维持可接受的性能水平（响应时间、错误率）。 * 确定系统在目标负载下的最大处理能力（吞吐量）。 * 观察系统在持续负载下的稳定性（是否有内存泄漏、资源耗尽等）。 | * 确定系统的 崩溃点 或 性能断崖式下降点。 * 评估系统在超负荷情况下的 健壮性 和 错误处理能力（是否优雅降级？数据是否一致？）。 * 验证系统在压力消除后的 恢复能力（能否自动恢复？恢复时间多长？）。 * 为灾难恢复和高可用性设计提供依据 |
| 核心关注点 | 系统在 预期 或指定 负载下的整体表现 和 效率 | 系统在 设计容量 下的 行为表现 和 稳定性。 | 系统的 极限承受能力 、 失效模式 和 可恢复性 |
| 测试目标与重点 | 关注 整体性能指标 和 效率。 | 关注 设计负载下的稳定性 和 处理能力 | 关注 超越极限时的行为 和 容错/恢复能力。 |
| 负载水平 | 可以是 低、中、高 负载，目标是测量指标 | 通常是 预期或目标峰值 负载 | 持续增加 负载直至系统 失效 或 远超 预期峰值。 |
| 成功标准 | 达到或接近性能指标（响应时间 < X ms, 吞吐量 > Y tps） | 在目标负载下维持稳定性能，无资源耗尽或错误率飙升 | 理解系统如何失效（是否优雅？），并能成功恢复。找到失效点本身就是目标之一 |
| 主要输出 | 性能指标报告（响应时间分布图、资源利用率图、吞吐量曲线） | 系统在目标负载下的稳定性报告、最大处理能力值 | 系统失效点报告、失效模式分析、恢复过程报告 |
| 典型应用场景 | * 新系统上线前基准测试。 * 版本迭代后性能回归测试。 * 评估不同配置或环境对性能的影响。 | * 电商平台"双十一"大促前的容量验证。 * 在线票务系统开票时的峰值流量模拟。 * 验证新服务器集群能否承载预测的用户增长 | * 测试数据库连接池耗尽时的系统行为。 * 模拟突发性远超预期的流量洪峰（如"热搜"效应）。 * 验证系统在内存溢出或磁盘写满时的处理逻辑。 * 灾难恢复演练（如主节点宕机后切换时间）。 |
| 关键性能指标 | 通用指标： * 响应时间 * 吞吐量 / TPS * 并发用户数 * 错误率 资源指标： * CPU利用率 * 内存使用量 * 磁盘 I/O * 网络带宽 * 数据库连接数、锁等待 |||
| 侧重 | 全面关注上述指标 | 重点关注在目标负载下的响应时间、吞吐量、错误率、资源利用率是否稳定 | 关注资源耗尽指标、错误率飙升点、响应时间剧增点、以及恢复时间 |
| 实施流程 | * 明确测试目标。 * 定义关键性能指标和可接受标准。 * 设计测试场景和脚本。 * 配置测试环境（尽量模拟生产）。 * 准备测试数据。 * 执行测试。 * 监控与分析。 * 报告与优化建议。 |||
| 各自挑战 | 如何设计有代表性的测试用例？如何准确模拟用户行为？ | 如何准确预测和模拟"典型"或"高峰"负载？ | 如何安全可控地施加极端压力？如何精确捕捉失效瞬间？ |
|---|
工具选型
-
常用工具： Apache JMeter, LoadRunner, Gatling, k6, Locust, Tsung 等。
-
选型考虑： 协议支持、分布式能力、报告分析、学习曲线、社区支持、成本。
总结与最佳实践
-
三者关系：负载测试和压力测试是性能测试的 子集 或 特定类型。性能测试是总称。
-
协同作用：完整的性能评估往往需要结合这三种测试。
-
性能测试提供基线。
-
负载测试验证容量。
-
压力测试探索极限。
-
-
最佳实践：
-
尽早并持续进行：非功能性测试应贯穿开发周期。
-
环境一致性：测试环境尽可能接近生产环境。
-
真实模拟：用户行为、数据、网络条件模拟要逼真。
-
明确指标与标准：测试前定义清晰的可接受标准。
-
结果分析重于工具使用：深入分析结果找出根因。
-
结果驱动行动：测试结果应用于优化系统、调整架构或完善监控。
-