一句话定义：压力测试（Load Testing，常简称“压测”）就是在系统正式上线前，用人为制造的流量去冲击它，观察它在多少人同时使用时会变慢、报错或直接崩溃。
打个比方：开业前的餐厅
新餐厅装修好了，但厨师和服务员的配合能不能撑住中午的客流？聪明的做法是开业前找一批朋友假装顾客，先来 10 桌，再来 50 桌，最后塞满 100 桌，同时盯着三件事：上菜要等多久、什么时候门口开始排长队、厨房在第几桌时彻底乱套。
压测就是这套流程。用压测脚本模拟用户请求（登录、搜索、下单），按阶梯逐步加压，同时采集指标：吞吐量（QPS/TPS，每秒处理的请求数）、响应时间（尤其是 P95、P99 这类分位数，只看平均值会被少数极慢请求骗过去）、错误率，以及 CPU、内存、数据库连接池这些资源占用情况。常见结论是“在 X 并发下 P95 响应时间仍在可接受范围”，这个 X 就是容量上限的参考值。
几个容易混淆的邻居
| 类型 | 干什么 | 回答的问题 |
|---|---|---|
| 负载测试 Load Testing | 按预期的峰值流量加压 | 大促那天，我们扛得住吗？ |
| 压力测试 Stress Testing | 一直加到系统崩溃 | 极限在哪？先坏的是哪一环？ |
| 尖峰测试 Spike Testing | 流量瞬间暴涨 | 秒杀开抢那一秒会不会塌？ |
| 浸泡测试 Soak Testing | 中等压力跑很久 | 跑一整夜会不会内存泄漏？ |
| 容量规划 Capacity Planning | 根据压测结果推算资源 | 要加几台机器才够？ |
实际工作中常把它们统称为“压测”，但目的不同，脚本和结论也不同。
做 AI 应用，压测有几处不一样
传统 Web 服务的单次请求几十毫秒，压测主要看数据库和连接池。而大模型应用的单次请求动辄几秒到几十秒，瓶颈往往在 GPU 显存、推理排队，或者上游模型服务的调用频率限制（rate limit）。这时候“响应时间”要拆成首字延迟（TTFT，Time To First AI 词典：Token">Token）和总生成时长分别看，因为流式输出下用户感知的是前者。压测还要区分“排队等待”和“真正推理”的时间，否则加机器也解决不了排队问题。另外，压测会消耗真实 token 额度，用 mock 模型和真实模型要分别跑一轮。各家云厂商和模型服务对并发与限流的规则不同，具体以官方页面为准。
对普通人的意义
很多系统上线首日崩溃，并不是代码有 bug，而是从没在接近真实的流量下跑过：压测环境只有一台机器、测试数据只有几十条，和生产环境完全不是一回事。压测的价值不只是给出一个数字，更是提前暴露“先坏的那一环”——是数据库、是缓存，还是那个没人注意的第三方接口。知道先坏在哪，才知道该先修哪。