1. 压测基础概念：压力测试、性能测试、负载测试、稳定性测试的区别与联系
在进入 Go 后端压测实战之前，必须厘清几个经常被混淆的核心概念。很多团队在制定测试方案时，将“压力测试”与“性能测试”混为一谈，导致测试目标模糊、结果无法指导优化。本节从定义、目标、方法和度量维度四个层面，系统梳理四类测试的本质区别与内在联系。
1.1 四类测试的核心定义与目标
| 测试类型 | 英文术语 | 核心目标 | 典型问题 |
|---|---|---|---|
| 性能测试 | Performance Testing | 评估系统在正常负载下的响应速度、吞吐量和资源效率 | “系统在 1000 QPS 下平均延迟是多少？” |
| 负载测试 | Load Testing | 验证系统在预期业务负载下能否稳定运行 | “双十一峰值 5000 QPS 时系统是否正常？” |
| 压力测试 | Stress Testing | 找出系统的极限承受能力和瓶颈点 | “系统在多少 QPS 时开始报错或崩溃？” |
| 稳定性测试 | Stability / Soak Testing | 验证系统在长时间持续运行下是否存在内存泄漏、资源耗尽等问题 | “系统连续运行 72 小时后性能是否衰减？” |
实战提示：在 Go 后端项目中，性能测试通常作为基准（Benchmark）先行，负载测试用于容量规划，压力测试用于确定熔断阈值，稳定性测试用于发现 goroutine 泄漏和内存增长问题。四者构成完整的质量验证闭环。
1.2 四类测试的度量维度对比
不同测试类型关注的度量指标各有侧重。下表列出每类测试最核心的 3 个度量维度：
| 测试类型 | 首要指标 | 次要指标 | 辅助指标 |
|---|---|---|---|
| 性能测试 | 平均延迟（Avg Latency） | 吞吐量（TPS/QPS） | CPU 利用率、内存占用 |
| 负载测试 | 错误率（Error Rate） | P99 延迟 | 并发连接数、数据库连接池状态 |
| 压力测试 | 最大并发数（Max Concurrency） | 系统崩溃点（Breakpoint） | GC 频率、goroutine 数量 |
| 稳定性测试 | 内存增长趋势（Memory Trend） | 延迟漂移（Latency Drift） | goroutine 泄漏数、文件描述符数 |
1.3 四类测试的关系与演进流程
下图展示了从性能测试到稳定性测试的典型演进路径，以及各测试阶段之间的数据反馈关系：
1.4 四类测试的典型场景与 Go 后端实践
- 性能测试：在 Go 服务上线前，使用
go test -bench对核心函数做微基准测试，或使用 wrk/ghz 对 HTTP/gRPC 接口做宏观基准。输出结果作为后续测试的对比基线。 - 负载测试：根据业务预估的峰值 QPS（如 2000 QPS），使用 k6 或 Locust 模拟真实用户行为，验证 Go 服务在预期负载下的延迟和错误率是否达标。
- 压力测试：逐步增加并发数直至系统出现 5xx 错误或延迟超过 500ms，记录此时的 QPS 和资源消耗，用于设置限流阈值和熔断策略。
- 稳定性测试：以 70%~80% 的峰值负载持续运行 24~72 小时，监控 Go 运行时指标（goroutine 数、GC 暂停时间、堆内存增长），排查内存泄漏和 goroutine 泄漏。
Go 后端特别关注点：Go 的 goroutine 和 GC 机制使得稳定性测试尤为重要。一个被遗忘的 goroutine 泄漏在 1 小时内可能只消耗 10MB，但 72 小时后可能膨胀到 2GB，导致 OOM。稳定性测试是发现这类问题的唯一可靠手段。
1.5 常见误区与避坑指南
| 误区 | 错误做法 | 正确做法 |
|---|---|---|
| 混淆压力测试与负载测试 | 用压力测试的结果来评估系统容量 | 负载测试使用预期峰值，压力测试用于找极限 |
| 忽略稳定性测试 | 只做短时间压测就上线 | 至少执行 24 小时稳定性测试，监控内存和 goroutine |
| 性能测试不设基线 | 每次测试独立进行，无法对比 | 每次代码变更后重新运行基准测试，对比延迟和吞吐量 |
| 测试环境与生产差异过大 | 在低配机器上压测，结论用于生产 | 尽量使用与生产一致的 CPU 核数、内存和网络拓扑 |
1.6 四类测试的协同工作模型
在实际项目中，四类测试并非串行执行，而是形成持续反馈的闭环。下图展示了一个典型的 Go 后端压测协同模型：
重要提醒：不要试图用一次测试覆盖所有目标。性能测试、负载测试、压力测试、稳定性测试各有独立的测试脚本、指标阈值和通过标准。在 Go 后端项目中，建议为每类测试建立独立的配置文件（如
perf.yaml、load.yaml、stress.yaml、soak.yaml），避免参数混淆导致测试结论失真。