您的应用程序可以与十个用户完美配合。促销日，一万块会发生什么？ 负载测试与压力测试描述了两种不同的方法来回答这个问题，将它们混合起来会导致测试无法证明您认为它们所做的事情。

本指南解释了每一项显示的内容、相关测试类型以及如何读取结果。我们在 Python 3.13 上使用模拟数字运行了下面的小百分位数计算。 k6 脚本是说明性示例，我们没有执行，并且用户计数和目标是发明的，因此请用您自己的脚本替换它们。仅针对您拥有或有权测试的系统运行这些测试，因为大流量可能看起来像是攻击并导致真正的中断。

简短的回答

负载测试问：我们能否处理我们期望的流量，并在执行过程中达到我们的目标？ 压力测试会问：在失败之前我们能承受多少，我们如何失败，以及我们恢复的速度有多快？

想想一座桥。负载测试驱动预期数量的卡车通过并确认一切正常。压力测试不断增加权重以了解其极限，以及是否首先发出警告。幸运的是，破坏软件比破坏桥梁的成本要低。

负载测试与压力测试并排

什么是负载测试？

负载测试模拟您期望的实际流量，并测量系统的行为方式。它需要一个测试目标，例如：“在 500 个并发用户下，95% 的结账请求在 800 毫秒内完成，错误率低于 1%。”

这是 k6 脚本的样子。 k6 测试是用 JavaScript 编写的，thresholds 将您的目标转换为通过或失败结果：

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "5m", target: 500 },   // ramp up
    { duration: "20m", target: 500 },  // hold at expected peak
    { duration: "2m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/products");
  sleep(1);   // think time, as real users pause
}

sleep很重要。在没有思考时间的情况下，每个虚拟用户都会不断地攻击服务器，产生的流量比相同数量的真实用户多得多。

什么是压力测试？

压力测试故意超出预期水平。你并不是想通过。您想要以下问题的答案：

• 在什么水平上性能开始下降？
• 哪个组件首先失败：数据库、应用程序服务器还是第三方调用？
• 它会优雅地失败并出现明显的错误，还是会崩溃并丢失数据？
• 当流量下降时它会自行恢复吗？

export const options = {
  stages: [
    { duration: "5m", target: 500 },    // expected peak
    { duration: "5m", target: 1000 },   // beyond it
    { duration: "5m", target: 2000 },   // further
    { duration: "5m", target: 4000 },   // likely to break
    { duration: "10m", target: 0 },     // recovery: does it come back?
  ],
};

最后的恢复阶段经常被遗忘，但它可能是最有价值的阶段。一个能够很好地处理故障但如果不手动重启就无法恢复的系统仍然意味着需要有人在半夜修复故障。理想情况下，在极端负载下，系统应以受控方式停止工作，返回明确的 503 响应，而不是超时。

秒杀、浸泡等类型

负载和压力测试属于更广泛的性能测试系列：

浸泡测试可以发现短期测试从未发现的问题。一个小的内存泄漏可能在二十分钟内看起来无害，但只会在两天后导致服务瘫痪。峰值测试适合闪购等流量不会逐渐增加的活动。

重要的指标

为什么平均值会产生误导

平均值隐藏了真实人们抱怨的缓慢请求。为了证明这一点，我们生成了 100 个模拟响应时间，其中 95 个响应时间很快（80 到 200 毫秒），5 个非常慢（2.5 到 4 秒），然后计算了常见的统计数据：

import math, random, statistics

random.seed(3)
times = [random.randint(80, 200) for _ in range(95)] \
      + [random.randint(2500, 4000) for _ in range(5)]

def pct(values, p):
    values = sorted(values)
    return values[math.ceil(p / 100 * len(values)) - 1]

print("avg", round(statistics.mean(times)), "p50", pct(times, 50),
      "p95", pct(times, 95), "p99", pct(times, 99), "max", max(times))

# avg 302 p50 150 p95 199 p99 3740 max 3896

仔细看看这些数字。平均 302 毫秒说明没有人。典型的请求大约需要 150 毫秒，而慢速请求则需要 3 秒以上。即使 p95 在 199 毫秒时看起来也很健康，只有 p99 揭示了问题。像 p95 这样的数字意味着 95% 的请求都这么快或更快。

百分之一的请求并不是罕见的事件。如果一个页面发出 50 个请求，则缓慢的 p99 会影响很大一部分页面浏览量。在对你来说重要的百分位上设定目标，然后一起考虑几个。

工具

其中任何一个都可以运行负载和压力测试。选择适合您团队技能的功能，而不是追逐功能列表。要在管道中使用它，请参阅什么是 CI/CD。

如何计划测试

1. 设定目标。 使用真实分析来查找峰值流量并定义目标。
2. 选择旅程。 以真实的比例模拟真实的用户行为，例如浏览、搜索和结帐。仅点击主页并不能证明什么。
3. 使用现实环境。 小型临时服务器无法预测生产。请注意任何差异。
4. 准备数据。使用真实的卷，因为在 100 行上快速的查询可能会在 1000 万行上爬行。
5. 警告人们。告诉您的运营团队和任何第三方，不要意外地对支付提供商进行负载测试。在适当的情况下模拟外部服务。
6. 从小处开始。 首先运行一个小冒烟测试以确认您的脚本有效。
7. 监控一切。如果没有服务器指标，您将看到那个它放慢了速度，但没有为什么.
8. 重复。每次修复后再次运行它，并保留基线进行比较。

读取结果

数据库是常见的瓶颈，因此如果查询是问题所在，请阅读我们的 SQL 查询优化指南。表的最后一行是一个重要的陷阱：始终检查生成负载的机器的运行状况。

常见错误

• 混淆用户与请求。 明确目标是指并发用户数还是每秒请求数。
• 忽略思考时间。这会增加流量并产生误导性结果。
• 测试太晚。 发布前一周，没有时间修复架构问题。
• 使用单个端点。 真实流量混合读取、写入和搜索。
• 缓存隐藏了一切。相同的重复请求可能只会测试您的缓存，因此请改变数据。
• 测试一次。 每个版本的性能都会发生变化，因此请定期运行测试。

最后的话

运行负载测试以确认您可以处理预期的流量，并进行压力测试以了解无法处理时会发生什么情况。从小事做起：选择最重要的用户旅程，设定一个明确的目标，并在启用监控的情况下针对登台进行简短的测试。第一次运行通常会教会你一些东西，你可以从那里开始构建。

常见问题

继续学习