负载测试
Load Testing
高级通用负载测试（Load Testing）是按预设的用户量或请求量持续访问系统，观察它在预期业务压力下的响应和稳定性。它帮你判断产品上线后能否承受日常高峰，例如多人同时提交表单时会不会变慢或报错。
你可能会说：「帮我看看网站在很多人同时使用时，会不会变慢、报错，最多能稳稳接住多少人。」
动手看看报名高峰的负载测试
活动报名 · 负载测试持续 10 分钟模拟用户同时提交报名表
当前负载：250 人
预期高峰：250 人
平均响应时间
180 ms
提交错误率
0.1%
预期高峰内：提交保持稳定
拖动并发用户数，模拟越来越多人同时提交报名表。对照下面的响应时间和错误率，看系统能否撑住预期的 250 人高峰。
要点负载测试要看哪些事？
- 1
先说清楚要模拟什么流量
我们得先估计用户会做什么、请求会来得多频繁。比如活动报名网站，高峰时可能很多人打开页面，只有一部分人提交表单；如果只反复请求首页，测出的结果就解释不了报名是否顺畅。
- 2
同时观察速度和失败情况
测试时逐步施加负载，记录请求耗时、失败比例和每段时间完成的请求数。再结合服务端日志与资源使用情况看瓶颈：页面变慢可能是数据库查询拖住了请求，而不一定是前端页面太重。
- 3
用目标和环境解释测试结果
“能承受多少人”离不开使用场景。你可以先约定目标流量和可接受的响应时间，再在接近正式环境的配置、数据量下测试；如果测试环境的机器或数据库不同，结果就只能作为线索，不能直接当作上线保证。
容易混淆的地方
负载测试关心系统在预期业务流量下表现如何；压力测试则继续把流量推高，观察系统何时撑不住、失败后如何恢复。它也不同于功能测试：一次提交表单成功，只能说明这条流程在当时可用，不能说明许多人同时提交时仍然顺畅。
什么时候用
适合用
- 活动报名即将开放，预计短时间有很多人访问和提交，想验证页面与接口在预期高峰下的表现。
- 给 AI 工具接入批量生成任务后，想知道多人同时发起任务时，接口速度和失败情况会怎样变化。
- 数据库查询或缓存方案改动后，想在同一组流量条件下比较改动前后的响应表现。
不适合用
- 只想确认新表单能否正确保存一条记录，这时先做功能测试或端到端测试更直接。
- 还没有可运行的产品，只是在讨论用户是否需要这个功能，这时先做原型验证或用户访谈。
- 怀疑某个接口在完全没人访问时也会返回错误，先用单次请求和日志定位故障更合适。
练一练选一个答案，看看解释
你的报名网站预计开放后会有一波访问高峰。单人填写和提交都正常，你想判断现有服务能否接住这波流量。下一步选哪种做法？
让 AI 帮你做复制给 AI Agent 直接用
请为这个报名网站设计负载测试：以预期高峰流量为目标，模拟浏览页面和提交表单两类操作，逐步增加流量，记录响应时间、失败比例和吞吐量，并结合服务端指标指出瓶颈。先列出需要我确认的流量假设与测试环境差异。