performance-testing-strategy

性能测试策略设计器

通过有针对性的问题收集背景信息，并运用行业最佳实践，指导 QA 工程师设计一套完整、结构化的性能测试策略。

重要： 在生成任何输出前，务必先收集背景信息（步骤 1）。在了解系统及其约束条件之前，不要直接给出建议。

输出格式

完成步骤 1 后，提供一份包含以下部分的策略文档：

1. 被测系统（SUT）概要 — 你对应用的了解
2. 建议的测试顺序 — 要运行哪些类型的测试、按什么顺序运行，以及理由
3. 各项测试的定义 — 每种类型的目标、用户负载、持续时间、爬升时间和成功标准
4. 要收集的指标 — 响应时间、吞吐量、错误率、基础设施指标
5. 风险和前置条件 — 开始测试前必须具备的条件

---

步骤 1 — 收集背景信息

只询问你尚不了解的信息。按以下类别逐步了解；当信息足以设计策略时即可停止。不要一次性提出所有问题——将问题自然地分组，并在继续前等待回答。

A. 应用概况

• 这是什么类型的应用？（Web 应用、移动端后端、微服务、批处理作业、流处理管道）
• 使用什么协议？（HTTP/REST、GraphQL、WebSocket、gRPC、消息队列）
• 它是有状态的（会话、身份验证令牌）还是无状态的？
• 它是否依赖外部服务？（第三方 API、数据库、缓存、消息代理）
• 基础设施会自动扩缩容，还是容量固定？

B. 流量和使用模式

• 当前或预期的峰值负载是多少？（请求数/秒、并发用户数、事务数/天）
• 流量是稳定的（例如内部工具）还是突发的（例如限时抢购、营销活动、定时批处理）？
• 是否已知高峰时段？（一天中的时段、星期几、季节性活动）
• 典型用户流程是什么样的？（一系列操作，而不只是单个端点）

C. SLA 和验收标准

• 是否有响应时间目标？（例如 p95 < 1s、p99 < 2s）
• 是否有吞吐量目标？（例如必须处理 500 RPS）
• 可接受的错误率是多少？（例如负载下错误率 < 0.1%）
• SLA 是按端点定义、全局定义，还是两者都有？

D. 环境和约束

• 测试将在哪种环境中运行？（生产环境克隆、预发布环境、专用性能测试环境）
• 该环境是否与生产流量隔离？
• 是否有数据方面的约束？（测试用户、脱敏数据、数据量）
• 是否有需要注意的基础设施限制？（共享数据库、限流器、WAF、CDN）
• 可用的测试窗口有多长？（可用于运行测试的小时数或天数）

E. 范围和目标

• 这是首次性能测试，还是发布前的回归测试？
• 是否有特定的关注点或风险促使开展此次测试？（新功能、峰值活动准备、事件复盘、容量规划）
• 将使用什么负载测试工具？（询问时不要推荐工具——策略与工具无关）

---

步骤 2 — 选择测试类型

只推荐符合既定目标和风险的测试类型。不要默认推荐全部五种——根据收集到的背景信息说明每项建议的理由。

当用户需要了解每种测试类型的详细定义、参数和决策标准时，加载 references/TEST-TYPES.md。

快速选择指南

情况	推荐测试
首次测试，没有基线	烟雾测试 → 负载测试
发布前回归检查	烟雾测试 → 负载测试
低风险内部工具（≤ 50 位用户，没有外部 SLA）	仅烟雾测试 → 负载测试 — 到此为止，不要添加压力测试或突发测试
为流量高峰事件做准备（黑色星期五、发布）	烟雾测试 → 负载测试 → 突发测试
调查持续流量下的性能下降	烟雾测试 → 负载测试 → 耐久测试
找出系统的崩溃临界点	烟雾测试 → 负载测试 → 压力测试
生产级系统的完整策略	烟雾测试 → 负载测试 → 压力测试 → 突发测试 → 耐久测试
时间有限（< 4 小时）	仅烟雾测试 → 负载测试

执行顺序规则

始终先运行烟雾测试。 切勿直接跳到压力测试或突发测试——基线有问题会浪费时间，并产生误导性结果。

---

步骤 3 — 定义每项测试

针对每种推荐的测试类型，给出精确的定义。使用以下模板。以用户数或 RPS 表示负载，切勿使用特定于工具的语法。

烟雾测试

Goal:          Verify the test setup works and the system handles minimal load
Users:         2–5 virtual users
Duration:      2–5 minutes
Ramp-up:       None (inject all users at once) or 30 seconds
Success:       0 errors, all responses within 2× the SLA threshold
When to skip:  Never — always run smoke first

负载测试

Goal:          Measure behavior under expected production load
Users:         Peak load × 1.0 (baseline) and peak load × 1.2 (safety buffer)
Duration:      30–60 minutes of steady state (after ramp-up)
Ramp-up:       10–20% of total duration (e.g., 10 min ramp for a 60 min test)
Success:       Error rate < 0.1%, p95 within SLA, p99 within 2× SLA
When to skip:  Only if a load test was run recently with no system changes

压力测试

Goal:          Find the maximum load before degradation or failure
Users:         Start at peak load; increase by 20–25% each step until breaking point
Duration:      Until failure or throughput plateaus — typically 30–90 minutes
Ramp-up:       Staircase: add load increments every 5–10 minutes
Success:       Identify the breaking point; confirm graceful degradation and recovery
When to skip:  When the only goal is SLA validation (not capacity exploration)

突发测试

Goal:          Verify behavior during sudden, large traffic bursts
Users:         Baseline load → sudden jump to 2–5× peak → return to baseline
Duration:      10–20 minutes total (the spike itself: 2–5 minutes)
Ramp-up:       Instantaneous spike; gradual recovery back to baseline
Success:       System survives without crashing; recovers to baseline SLA within a defined window
When to skip:  When traffic is inherently steady with no burst patterns

耐久／浸泡测试

Goal:          Detect issues that only appear over time: memory leaks, connection exhaustion, resource drift
Users:         70–80% of peak load (sustainable, not maximum)
Duration:      2 hours minimum; 8–24 hours for critical or long-running systems
Ramp-up:       Standard ramp (10–15 min)
Success:       Response times and error rates at the end are within 10% of values at the start of steady state
When to skip:  Short-term regression only — note the risk and schedule a soak test later

---

步骤 4 — 定义指标

当用户询问要收集哪些指标、如何设置 SLA 阈值，或基础设施侧需要监控什么时，加载 references/METRICS-AND-SLAS.md。

每项测试都必须收集的最低限度指标

应用级（由负载测试工具收集）：

• 响应时间：p50、p90、p95、p99 — 切勿只依赖平均值
• 吞吐量：每秒请求数或每秒事务数
• 错误率：失败请求的百分比（超时 + 错误响应）
• 随时间变化的并发用户数／活跃会话数

基础设施级（通过监控收集 — APM、指标平台、云仪表板）：

• CPU 利用率（持续高于 70% 时应调查）
• 内存利用率（在耐久测试中留意持续上升的趋势）
• 网络 I/O（饱和表明是基础设施瓶颈，而非应用程序瓶颈）
• 数据库：连接池使用情况、慢查询率、锁等待
• 特定于运行时的指标（如适用）：堆使用量、垃圾回收频率和暂停时长

说明： 所有指标都使用通用术语表示，切勿包含特定于运行时的标志、API 调用或平台名称。使用“堆使用量”和“GC 暂停时长”，不要使用 -XX:+HeapDumpOnOutOfMemoryError、process.on()、HeapInuse 或任何语言／运行时语法。步骤 4 和 5 中的策略必须始终与工具无关。

---

步骤 5 — 前置条件检查清单

运行任何测试之前，请确认：

• 测试环境已隔离 — 测试流量不会影响真实用户或生产数据
• 测试数据已准备就绪 — 准备真实规模的用户、产品、订单或领域实体数据
• 已定义数据策略 — 明确测试数据如何使用：循环使用、随机化，或每次运行使用唯一数据
• 监控已启用 — 在测试开始之前启动指标收集
• 已有基线指标 — 至少要有可供比较的烟雾测试结果
• 团队成员可随时响应 — 有人能够监控测试，并在需要时停止测试
• 已有回滚计划 — 适用于可能导致数据损坏或服务中断的测试
• 第三方服务已设置存根或限流 — 避免产生实际费用或触及合作伙伴配额
• 已为测试配置限流器／WAF — 或在测试环境中绕过这些限制
• 已屏蔽告警 — 避免在有意进行压力测试或突发测试时产生值班噪声

---

常见策略错误

1. 未进行负载测试就先进行压力测试

没有负载测试基线就运行压力测试，意味着你无法区分“系统在 500 位用户时崩溃”和“系统在 100 位用户时就已经无法正常运行”。

2. 未隔离就在生产环境中测试

即使是只读负载测试，也可能导致生产事故（数据库 CPU 飙升、缓存驱逐、触发限流器）。务必使用隔离环境。

3. 使用不切实际的用户流程

只测试单个端点（例如健康检查）无法告诉你真实的用户行为。根据分析数据或业务需求，模拟排名前 2–3 的用户旅程。

4. 忽略请求之间的思考时间

请求之间没有思考时间，产生的负载会比真实用户高出 10–100×。每个场景都必须包含反映实际用户行为的合理暂停。

5. 未监控基础设施

如果只知道响应时间，却不了解 CPU、内存和数据库状态，就无法诊断系统性能下降的原因。负载测试期间，务必同时运行基础设施监控。

6. 耐久性测试时间过短

5 分钟的浸泡测试无法发现任何问题。内存泄漏和连接耗尽通常会在持续负载 30–120 分钟后出现。最低可行的浸泡测试时长：2 小时。

7. 将测试结果视为绝对真理

结果仅对所测试的环境、数据量和配置有效。务必将这些条件与结果一并记录——在只有生产数据 10% 的预发布环境中进行的测试，不能代表生产环境的容量测试。

8. 测试了错误的工作负载模型

并发用户数与到达率（RPS）不能互换。要弄清楚系统应使用固定数量的并发用户（闭合模型）进行测试，还是使用固定的新请求到达率（开放模型）进行测试。使用错误的模型会产生误导性的吞吐量数据。

---

参考资料

• 测试类型——详细参数与决策标准
• 指标、SLA 与监控指南