主题
界面
基线测试、负载测试与压力测试
1. 本节定位
《JMeter 断言与指标解读》讲怎么读指标；本节讲**"用这些指标回答哪四个问题"**：
| 问题 | 对应的测试 |
|---|---|
| "单用户有多快？" | 基线测试（Baseline）✓ |
| "预期流量下达标吗？" | 负载测试（Load）✓ |
| "极限在哪？" | 压力测试（Stress）★ |
| "跑一天会怎样？" | 稳定性测试（Soak）★★ |
★ 这是一节"名词辨析课"——因为这四个词在团队里经常被混用 ✗ ——混用会导致"测了但没回答任何问题" ✗✗
2. 学习目标
- 说出四种测试的目的、施压方式与停止条件 ★★★；
- 说出每种测试的"产出"是什么（结论形态）★★；
- 说出"稳定性测试"为什么不能省（内存泄漏只能长跑暴露）★★★；
- 会用拐点数据做容量规划 ★★；
- 知道"通过标准"该怎么定（不能只看 QPS）★★。
3. 前置知识检查
4. 为什么需要这个知识
先看四种测试被混用的典型后果：
text
"我们做过性能测试了"
问：结论是什么？
"QPS 有 800。" ← 回答了哪个问题？一个也没答 ✓
问：那大促 5 倍流量撑得住吗？
"……不知道。" ← ✗✗问题在于："做过压测"不等于"回答了业务问题" ✓
四种测试各自回答一个业务问题：
| 测试 | 回答的问题 | 谁关心 |
|---|---|---|
| 基线 | 单用户多快？"用户会不会嫌慢" | 产品 |
| 负载 | 预期流量下SLA 达标吗 | 业务 |
| 压力 | 什么情况下会崩 | 运维、架构 |
| 稳定性 | 长期跑会不会恶化 | 运维 |
5. 核心概念
5.1 四种测试对照表 ★★★
| 基线 | 负载 | 压力 | 稳定性（Soak） | |
|---|---|---|---|---|
| 目的 | 建立单用户基准 | 验证预期负载下达标 | 找极限与崩溃点 | 长时间运行是否退化 |
| 并发 | 1（串行） | 预期峰值（如 5 倍日常） | 阶梯递增 | 预期的 60~80% |
| 时长 | 几分钟 | 10~30 分钟 | 每档 3~5 分钟 | 数小时~数天 ★★ |
| 停止条件 | 数据稳定 | 达标即停（或失败即停） | QPS 不涨 / 错误率飙升 | 跑满预设时长 |
| 产出 | P50/P95 基线值 | "达标 / 不达标"结论 | 容量上限 + 拐点 | 是否泄漏 / 性能是否劣化 |
| 失败的含义 | 测错了 | 业务不达标 ✗ | 找到极限（这是目的） ✓ | 存在泄漏或退化 ✗✗ |
★ 最容易被漏的是"稳定性测试" ✗ ——而它捕捉的是最难发现的一类问题 ✓
5.2 稳定性测试：为什么必须长跑 ★★★
它要抓的是"时间维度"上的问题——这些问题在 10 分钟的压测里完全看不出来 ✗
| 问题 | 为什么短测发现不了 |
|---|---|
| 内存泄漏 ★★ | 堆增长很慢（每分钟几 MB）→ 10 分钟测不出来 ✗ ——跑 8 小时就 OOM ✗✗ |
| 连接池泄漏 ★ | 连接慢慢被占满 → 几小时后开始超时 ✗✗ |
| 文件句柄泄漏 | 同上 ✓ |
| 日志把磁盘写满 ⚠️ | 需要时间累积 ✓ |
| 缓存无限增长 | 无淘汰策略的 Map 会吃掉所有内存 ✗ |
| 定时任务与请求相互干扰 | 需要"跨越定时任务触发点"才能发现 ✓ |
| 性能缓慢劣化 | JIT 退化、碎片化 ⚠️ |
★ 稳定性测试的判据（三种典型形态）：
text
① 吞吐随时间下降 → 有泄漏或资源被耗尽 ✗
② 内存占用持续上升不回落 → 内存泄漏 ✗✗
③ 响应时间随运行时长缓慢变长 → GC 压力增大 / 碎片 ✗⚠️ 一个实践提醒：稳定性测试要压到 60~80% 的容量 ✓ ——压满会让系统一直处于边缘状态，测出来的问题"不典型" ⚠️
5.3 用本轮数据读出"三种测试" ★★★
本轮的实测数据（T2-003 第 7 节）：
text
并发 总请求 QPS P50(ms) P95(ms) P99(ms)
1 40 55.1 14 39 55
4 160 61.1 57 119 187
16 640 68.7 213 393 517
64 2560 68.8 845 1594 2011同一份数据，三种读法：
| 测试 | 取哪一档 | 读出什么 |
|---|---|---|
| 基线 ✓ | 串行 30 次 | P50 = 14 ms，P95 = 21 ms ——"单用户看到的速度" |
| 负载 ✓ | 并发 1 那档（假设它是预期负载） | QPS 55、P95 39ms ——"达标吗？"（取决于 SLA） |
| 压力 ★ | 全部四档 | 吞吐上限 ≈ 69 QPS；超出后 P99 涨 36 倍 ✗ |
★ 一句可以直接写进报告的结论：
"该接口在当前环境下的吞吐上限约 69 QPS；超出后吞吐不再增长，而 P99 从 55ms 升至 2011ms（36 倍）。建议将 69 QPS 视为扩容阈值。" ✓✓
这就是"压力测试的产出" ✓ ——它不是"跑了多少"，而是"一条可决策的结论" ✓
5.4 容量规划：从拐点推算 ★★
拿到拐点之后，容量规划就是一道算术题 ✓
text
已知：单实例吞吐上限 ≈ 69 QPS（当前环境）
需求：大促预计 300 QPS
需要实例数 = 需求 / (单实例上限 × 安全系数)
= 300 / (69 × 0.7) ← ★ 只用到 70%（留余量）
≈ 6.2 → 至少 7 个实例★ "安全系数"不是拍脑袋：
| 余量的用途 | 说明 |
|---|---|
| 突发流量 | 真实流量有尖峰 ✓ |
| 单实例故障 | 少一台时仍能扛住 ✓ |
| 性能衰减 | 数据量增长、GC 变化 ⚠️ |
| 拐点附近的延迟 | 压到 100% 时延迟已经爆了 ✗✗ |
最后一条最关键：
容量不能按"拐点"配，要按"拐点之下"配 ✓ ——因为在拐点上，延迟已经不可接受了 ✓✓
一般取拐点的 60~70% ✓
5.5 通过标准怎么定 ★★
"通过标准"必须：可量化、与业务相关、含多个维度 ✓
| 维度 | 典型标准 | 为什么 |
|---|---|---|
| 响应时间 ★★ | P95 < 200ms（而非平均） | 用分位（T2-014）✓ |
| 错误率 ★★ | < 0.1% | 再低也要有个红线 ✓ |
| 吞吐 | ≥ 预期峰值的 1.3 倍 | 留余量 ✓ |
| 资源水位 ★ | CPU < 70%、内存 < 80% | 有余量才叫"健康" ✓ |
| 稳定性 ★ | 长跑 8 小时无劣化 | 5.2 ✓ |
★ 一个常见的错误标准：
text
"CPU 使用率 95% 说明压得很充分" ← ✗ 这是"没有余量"，不是"充分"压测的目标不是"把 CPU 打满"，而是"确认在目标负载下有足够余量" ✓✓
5.6 测试顺序：一个可执行的流程 ★
推荐的执行顺序（每一步都依赖上一步的产出）：
text
① 基线测试
→ 得到"单用户速度"，作为后续对比的参照 ✓
② 负载测试（预期负载）
→ 达标？→ 继续 ③
→ 不达标？→ **先优化**，回到 ① ✗
③ 压力测试（阶梯加压）
→ 找到拐点与上限，得到容量结论 ✓
④ 稳定性测试（60~80% 容量，长跑）
→ 确认长期无劣化 ✓
⑤ 输出报告：环境 + 参数 + 四件套 + 结论与适用范围 ✓★ 顺序为什么不能反：
如果基线都不稳定（数据波动大），后面的所有对比都不可信 ✓
如果负载测试不达标，先做压力测试只会得出"它确实不行" ✗ ——没有行动价值 ✓
6. 递进示例
6.1 最小示例：基线
text
串行 30 次 → P50 = 14 ms（[T2-003](./T2-003) 实测）
这就是"这个接口在这台机器上的单用户速度"6.2 业务示例：负载测试的判定
text
SLA：P95 < 200 ms
实测（并发 1）：P95 = 39 ms → 达标 ✓
实测（并发 4）：P95 = 119 ms → 达标 ✓
实测（并发 16）：P95 = 393 ms → 不达标 ✗
结论：这个接口的"达标容量"在并发 4~16 之间，约 61~69 QPS★ 注意这个结论的形态：不是"能不能扛"，而是"在哪一点开始不达标" ✓✓
6.3 反例："压到 CPU 100% 就是压透了"
见 5.5 ✓
7. 实测：三种测试的同源数据
本节没有新增代码——它用的是 T2-003 的同一份实测数据 ✓
★ 这本身是重要的一课：
同一份压测数据，按不同目的去读，就得到不同结论 ✓
"做哪种测试"决定的是"怎么施压"与"怎么读"，而不是"用不同的工具" ✓✓
对照表：
| 测试 | 施压方式（本轮） | 读法（本轮） |
|---|---|---|
| 基线 | 串行 30 次 | P50=14ms，P95=21ms |
| 负载 | 并发 1 档 | P95=39ms，对照 SLA 判断 |
| 压力 | 四档阶梯 | 拐点 ≈ 69 QPS，P99 涨 36 倍 |
| 稳定性 | ⚠️ 本轮未做 | 需要长跑（数小时） |
⚠️ 诚实标注：本轮没有做稳定性测试 ✗ ——因为它需要数小时 ✓ ——讲义里明确说明这一点，而不是假装做过 ✓
8. Debug 观察点
- 把"串行 30 次"重复 3 遍：观察 P50 是否稳定（基线不稳 → 后面都不可信）★；
- 对照 SLA 逐档标注"达标 / 不达标"：得到"达标容量" ✓；
- 在压力测试中记录"第一档出现错误"的位置：那是"可用上限"，比"吞吐上限"更保守 ★；
- 计算"拐点的 70%"：这就是建议的运行水位 ✓。
9. 常见错误
| # | 错误 | 说明 |
|---|---|---|
| 1 | 把四种测试混为一谈 ✗ | 测了但没回答任何问题（第 4 节）✗ |
| 2 | 不做基线直接加压 ✗✗ | 没有参照，数据无法解读 ✗ |
| 3 | 用"平均值"当通过标准 ✗✗ | 见 T2-014 ✓ |
| 4 | 只做压力测试不做负载测试 ✗ | 找到极限但不知道"业务是否达标" ✗ |
| 5 | 省略稳定性测试 ⚠️ | 泄漏类问题永远发现不了 ✗✗（5.2） |
| 6 | 按拐点配容量 ✗✗ | 拐点上延迟已不可接受 ✓（5.4） |
| 7 | 压测报告只有数字没有结论 ✗ | "QPS 800"不是结论，"能扛 5 倍大促"才是 ✓✓ |
10. 动手实验
目标：用一份数据回答四个业务问题。
步骤：
- 用 T2-003 的数据，假装 SLA 是"P95 < 200ms"，逐档判定"达标 / 不达标" ✓；
- 算出"达标容量"（在哪个并发区间开始不达标）★；
- 做容量规划：假设大促 300 QPS，算需要几个实例（用达标容量而非吞吐上限）✓；
- 设计一个稳定性测试方案：压到什么水位、跑多久、看哪些指标（提示：内存 RSS、GC 次数、吞吐随时间的变化）★；
- 写一份完整报告（七项，见 T2-014 的 5.6）✓。
验收方式：能说出"为什么容量规划要用达标容量而不是吞吐上限"。
扩展任务：给 LoadTestLesson 加"自动判定达标"：
- 传一个
--sla-p95=200参数； - 每档结束就打印"达标 / 不达标"，并在第一次不达标时停止加压 ★；
- 说明：这个行为为什么比"压满四档"更接近专业工具（提示：避免把环境打到崩溃）✓
11. 练习题
- 判断：压力测试的目的是把系统压垮。（对 / 错）
- 填空：四种测试是 、、、；其中唯一需要长跑的是 ______。
- 简答：为什么"内存泄漏"只能靠稳定性测试发现？
- （代码阅读）
text
基线：P95 = 20 ms
负载（预期峰值）：P95 = 150 ms，SLA 要求 < 200 ms → ?
压力：拐点 400 QPS，拐点处 P99 = 5 s请给出三条结论（各一句话）。 5. （编程）设计一个"稳定性测试的巡检脚本"：每 5 分钟记录一次内存、GC 次数、成功 QPS，并在"内存连续 3 次上升"时告警。
参考答案（要点）
- 错。目的是"知道极限在哪、以及接近极限时会发生什么" ✓ ——压垮是手段，不是目的 ✗（T2-003 5.1）
- 基线、负载、压力、稳定性；稳定性 ✓
- 因为泄漏很慢（每分钟几 MB）→ 10 分钟的压测里看不出 ✗ ——必须跑数小时，让堆增长到能被观测或被 OOM 触发 ✓✓
- 三条结论：
- "预期峰值下达标（P95 150ms < 200ms SLA）" ✓
- "容量上限约 400 QPS，但拐点处 P99 已达 5 秒" ⚠️
- "建议运行水位取拐点的 70% ≈ 280 QPS，此时延迟应在可接受范围" ★
- 要点：定时采样 + 阈值判断 + 状态记忆（"连续 3 次上升"需要保存历史）✓ ——这正是 T2-016 的监控系统在做的事 ✓
12. 掌握标准
- [ ] 能说出四种测试的目的、施压方式、停止条件与产出 ★★★；
- [ ] 知道"稳定性测试不能省"，并知道它能发现哪三类问题 ★★★；
- [ ] 能用同一份数据读出三种测试的结论 ★★；
- [ ] 会用拐点做容量规划，且知道要打折（60~70%） ★★；
- [ ] 会定"多维度、可量化"的通过标准（不只 QPS）★；
- [ ] 知道"压测报告要给结论，不是给数字" ✓。
13. 扩展资源
14. 下一步学习
《服务端监控与瓶颈分析》：找到拐点之后，怎么知道瓶颈在哪。
进度只保存在本机浏览器，可随时清除