系统上线前为什么建议做压力测试？

结论：只要高峰负载没有可靠证据，或过载会造成明显业务损失，上线前就应做与风险相称的性能测试。

压力测试不是为了得到一个好看的 QPS 数字，而是确认核心业务在目标负载下是否满足响应和成功率要求、哪个资源先到极限、超过极限后能否受控拒绝并恢复。滚水科技会从真实业务模型出发决定测试深度，不用“设备超过 1000 台”或“用户几十人”作为统一分界线。

在安排里程碑、资源与验收节奏时，还可以对照 一份压力测试报告通常会看哪些核心指标？ 和 系统上线后的第一个月最容易出哪些问题？你们怎么保障平稳过渡？；这些内容补充了需要放在同一项决策中考虑的上下文。

功能正确不等于高峰可用

功能测试通常在少量、顺序执行的请求下验证结果是否正确；生产流量却会带来并发写入、锁竞争、连接池耗尽、缓存失效、消息积压、重试放大和第三方限流。单个接口响应很快，也不能证明“登录—查询—下单—支付回调”混合运行时稳定。容量还会随着代码、数据量、索引、依赖版本和云资源变化，因此旧报告不能永久证明新版本。

测试方式	主要回答	典型负载形状	不能替代什么
基线/负载测试	目标业务量下是否达标	按真实比例逐步升至目标	极限和长时间稳定性
压力/极限测试	拐点在哪、过载怎样失败	持续加压至阈值之外	真实突发与恢复全过程
峰值/突刺测试	流量骤增时队列、扩缩容和限流是否有效	短时间陡增、陡降	长期泄漏和资源累积
浸泡测试	内存、连接、队列或数据是否随时间恶化	中高负载持续较长窗口	突发峰值
故障叠加测试	依赖变慢或节点故障时是否级联	负载同时注入延迟、断连或限额	完整灾备演练

Google SRE 的生产服务实践建议用负载测试而非历史经验建立资源与容量的关系，并测试超出额定容量后的服务行为；其级联故障章节指出应测试容量边界、过载失败模式，以及渐增和突发两类负载。这些原则说明为什么要测，但不为某个项目规定统一并发数。

一场可信压测从负载模型开始

先从生产预测或现有日志确定用户、设备、任务和时间分布，把“并发用户”转换成可执行场景：每类操作占比、思考时间、请求大小、数据基数、长连接数、批处理和定时任务。交易系统要包括创建、查询、取消及回调；IoT 要包括在线连接、心跳、遥测、指令和重连风暴；内容平台要把上传带宽、转码和读取混合起来。

测试环境应说明与生产的差异，包括实例规格、数量、网络、数据库数据量、缓存预热、外部依赖是实连还是桩。禁止在未授权情况下对生产或第三方接口直接加压。短信、支付、地图等服务若有费率和限流，应使用供应商沙箱或受控模拟，并单独验证契约；否则压测结果只是把第三方拒绝误当成本系统容量。

通过条件在运行前确定，例如某核心场景的业务成功率、P95/P99 响应时间、队列积压上限和恢复时间。Grafana k6 的指标说明将请求量、失败率和时延作为常用起点，并支持按条件设置阈值；示例数值只是工具示例，不应复制成项目 SLA。

什么时候可以缩减，但不能凭感觉跳过

低频内部工具若用户数、任务频率和资源余量都有证据，可以只做轻量基线与关键查询测试；复用成熟 SaaS 且容量由供应商承诺时，应核对其 SLA、限额和自己的集成，而非重复测试供应商内部。尚未验证商业需求的原型也可把测试控制在避免数据损坏和明显故障的程度。

相反，营销活动、交易、设备控制、批量导入、视频上传、实时计算或明确 SLA 的系统，应覆盖高峰、过载和恢复。压测发现瓶颈后，要重测验证优化，并保留脚本、版本、配置、原始结果和监控时间线。滚水科技以“目标场景达标且失败方式可控”作为上线证据，不以固定 2—5 人天或一张总结截图代替结论。