📚 课程目录第1章压力测试基础

1. 压力测试基础：定义、目的与核心指标

压力测试（Stress Testing）是性能工程中最具挑战性的环节之一。它通过向系统施加超出正常预期的负载，观察系统在极端条件下的行为表现。与负载测试不同，压力测试的核心目标是找到系统的崩溃点和恢复能力，而非仅仅验证是否满足日常性能要求。

1.1 压力测试的定义

压力测试是一种破坏性的性能测试方法，它持续增加并发用户数或请求量，直到系统出现性能拐点或完全失效。其本质是回答三个问题：

系统能承受的最大负载是多少？ —— 找到容量上限。
系统在过载时如何失效？ —— 是优雅降级还是直接崩溃。
系统在压力解除后能否自动恢复？ —— 验证自愈能力。

  关键区分： 负载测试关注“能否支撑预期流量”，压力测试关注“超出预期后会发生什么”。两者互为补充，但目标截然不同。

1.2 压力测试的目的

在真实生产环境中，流量突增（如秒杀、热点事件、DDoS攻击）时有发生。压力测试的主要目的包括：

目的维度	具体说明	业务价值
容量规划	确定系统在给定硬件资源下的最大吞吐量	指导服务器扩缩容决策，避免资源浪费或不足
瓶颈定位	发现CPU、内存、IO、网络、数据库连接池等资源瓶颈	精准优化代码、配置或架构，提升系统承载力
稳定性验证	检查系统在持续高压下是否出现内存泄漏、连接未释放等问题	保障7×24小时高负载场景下的服务连续性
恢复能力验证	测试系统在压力解除后能否自动恢复正常响应	降低故障恢复时间（MTTR），提升SLA
弹性伸缩验证	配合K8s等容器编排，验证自动扩缩容策略是否有效	实现成本与性能的动态平衡

1.3 核心指标详解

压力测试的量化分析依赖四个核心指标：TPS、QPS、RT 和 错误率。理解它们的定义、计算方式和相互关系，是解读测试报告的基础。

1.3.1 TPS（Transactions Per Second）

TPS 衡量系统每秒能成功处理的事务数。一个事务通常包含一组完整的业务操作（如：登录→查询→下单→支付）。TPS 是衡量系统业务处理能力的最直接指标。

1.3.2 QPS（Queries Per Second）

QPS 衡量系统每秒能响应的查询请求数。在大多数Web系统中，QPS 与 TPS 高度相关，但 QPS 更侧重于读请求或单一接口的吞吐能力。当业务逻辑简单（如纯查询接口）时，QPS 可近似等于 TPS。

实践建议： 在压测报告中，建议同时记录 TPS 和 QPS。对于写密集型业务（如订单、支付），优先关注 TPS；对于读密集型业务（如首页、搜索），优先关注 QPS。

1.3.3 RT（Response Time）

RT 即响应时间，指从客户端发出请求到收到完整响应所经过的时间。通常关注以下统计值：

平均RT： 所有请求响应时间的算术平均值，易受极端值影响。
P95/P99 RT： 95%/99%的请求响应时间低于该值，更能反映大多数用户的真实体验。
最大RT： 最慢请求的响应时间，通常用于排查异常。

1.3.4 错误率（Error Rate）

错误率指在压测过程中，返回HTTP 5xx、超时、连接失败等异常响应的请求数占总请求数的百分比。业界通常要求错误率低于 0.1%（千分之一），对于核心交易链路，要求更严格（低于 0.01%）。

避坑提示： 不要只看平均RT！当系统出现部分请求超时时，平均RT可能仍然“好看”，但P99 RT和错误率会急剧恶化。务必同时监控多个分位值。

1.4 核心指标关系图

下图展示了在典型压力测试过程中，TPS、RT 和错误率随并发用户数增加的变化趋势。理解这个“三阶段”模型是分析压测结果的关键。

1.5 指标计算与采样示例

在实际压测中，我们通常使用工具（如 JMeter、Locust、wrk）采集原始数据，然后按时间窗口计算指标。以下是一个典型的 60 秒压测采样片段：

# 原始采样数据（每秒采集一次）
time_sec, total_requests, success_count, fail_count, total_rt_ms
1, 1200, 1198, 2, 48000
2, 1250, 1249, 1, 50000
3, 1180, 1175, 5, 52000
...
60, 980, 960, 20, 68000

# 计算第1秒的指标
TPS = success_count / 1 = 1198
QPS = total_requests / 1 = 1200
平均RT = total_rt_ms / success_count = 48000 / 1198 ≈ 40.07 ms
错误率 = fail_count / total_requests = 2 / 1200 ≈ 0.17%

  重要原则： 压力测试的指标必须在稳定负载下持续观察至少 3-5 分钟，避免因瞬时波动得出错误结论。同时，务必记录每个时间窗口的 P95/P99 RT，而非仅依赖平均值。

1.6 压力测试流程概览

一个标准的压力测试流程通常包含以下步骤，这也是后续章节将深入展开的内容：

场景定义： 确定压测的业务接口、并发模型、数据量级。
脚本开发： 编写压测脚本，配置参数化、断言、关联。
预压验证： 小并发验证脚本正确性，确保无逻辑错误。
梯度加压： 从低并发开始，逐步增加负载，记录每个梯度的指标。
持续压测： 在目标并发下持续运行 15-30 分钟，观察稳定性。
数据采集与分析： 收集 TPS、RT、错误率、服务器资源等数据。
瓶颈定位与优化： 根据指标异常定位代码、配置或架构问题。
回归验证： 优化后重新压测，确认问题是否解决。

本章为后续所有章节奠定了指标基础。在接下来的课程中，我们将基于 TPS、RT 和错误率这三个核心指标，深入讲解如何设计压测场景、分析性能瓶颈，并将其与 A/B 测试的实验设计相结合，实现真正的数据驱动增长。