一、压测目标与KPI设定：从模糊到精准的量化管理
作为13年测试老兵，我见过太多团队因目标不清晰导致压测失效的案例。大促压测的核心目标应围绕系统容量边界验证、瓶颈定位与优化、高可用性验证三大维度展开。
1.1 容量边界验证：避免“拍脑袋”决策
传统压测常以“支撑XX万订单”为目标，但缺乏对业务场景的拆解。例如，某电商团队曾设定“双11支撑500万订单”目标，却未考虑订单结构差异：
- 普通订单：单商品、无优惠，系统处理简单；
- 促销订单：多商品组合、满减优惠、跨店计算，涉及复杂逻辑。
实际压测中，促销订单的TPS（每秒事务数）比普通订单低60%，导致系统在300万促销订单时即崩溃。因此，目标需按业务场景拆解，例如： - 普通订单：支撑400万，TPS≥2000；
- 促销订单：支撑100万，TPS≥800。
1.2 瓶颈定位：从“表面现象”到“根因分析”
压测不仅是验证系统能否扛住流量，更要通过指标分析定位瓶颈。例如，某次618压测中，系统响应时间突然从200ms飙升至5s，团队初步判断为数据库连接池耗尽。但通过以下步骤深入分析：
- 监控指标对比：对比CPU、内存、磁盘I/O、网络带宽等指标，发现数据库CPU使用率仅30%，但等待锁的线程数激增；
- 日志分析：检查数据库慢查询日志，发现某张订单表的联合查询未使用索引；
- 代码审查：定位到订单服务中一处N+1查询问题，导致每次请求触发多次数据库查询。
最终通过添加索引和优化查询，将响应时间降至300ms。关键点：压测需结合监控、日志、代码多维度分析，避免“头痛医头”。
二、压测场景设计：模拟真实，覆盖极端
大促压测的场景设计需兼顾常规流量与极端峰值，以下为实战中总结的场景设计方法论。
2.1 基础场景：验证系统基本能力
- 阶梯增压测试：从低并发（如100用户）逐步增加至目标并发（如10万用户），观察系统响应时间、错误率、资源使用率的变化，定位线性增长阶段的瓶颈。
- 稳定运行测试：在目标并发下持续运行2-4小时，验证系统长时间运行的稳定性，例如内存泄漏、连接池耗尽等问题。
2.2 促销专项场景：模拟真实业务逻辑
- 秒杀场景：模拟“0点抢购”的瞬时高峰，例如1秒内涌入10万请求，需结合令牌桶算法限制请求速率，避免系统被打死。
- 库存扣减场景：模拟多用户同时抢购同一商品，验证分布式锁、Redis原子操作等机制的可靠性。
- 支付洪峰场景：模拟用户集中支付时的第三方接口压力，例如支付宝/微信支付接口的QPS限制，需通过异步队列削峰填谷。
2.3 异常场景：提升系统容错性
- 服务降级测试：模拟依赖服务（如物流、库存）不可用时，系统是否能自动降级到备用方案（如显示“库存紧张”）。
- 数据倾斜测试：模拟热点数据（如某款爆品）被高频访问，验证缓存、分库分表等策略是否能避免单点过载。
- 网络分区测试：模拟部分节点与主节点网络断开，验证分布式系统（如Zookeeper、Etcd）的脑裂处理能力。
三、压测工具选型：开源与商业的平衡
13年测试生涯中，我使用过JMeter、Gatling、Locust等开源工具，也接触过LoadRunner、PTS等商业工具。以下为工具选型的核心原则。
3.1 开源工具：灵活但需二次开发
- JMeter：适合HTTP接口压测，但分布式压测配置复杂，需通过JMeter插件或结合Docker实现分布式。
- Gatling：基于Scala的异步压测工具，适合高并发场景，但脚本编写需掌握Scala语法。
- Locust：Python编写的分布式压测工具，支持自定义协议（如WebSocket、Dubbo），适合需要灵活扩展的场景。
3.2 商业工具：开箱即用但成本高
- LoadRunner：功能全面，支持多种协议（如HTTP、TruClient、Citrix），但license费用昂贵，适合大型企业。
- PTS（压测宝）：云原生压测工具，支持按需付费，无需维护压测集群，适合中小企业快速开展压测。
建议：初创团队可先用Locust或Gatling开源方案，待业务规模扩大后再考虑商业工具。
四、压测执行与优化：从“压完即止”到“持续改进”
压测执行不是终点，而是系统优化的起点。以下为压测后的优化流程。
4.1 压测报告解读：关键指标分析
压测报告需包含以下核心指标：
- 响应时间：P90、P99值是否符合业务要求（如支付接口P99≤500ms）；
- 吞吐量：TPS/QPS是否达到预期；
- 错误率：HTTP 5xx错误率是否≤0.1%；
- 资源使用率：CPU、内存、磁盘I/O是否在安全阈值内（如CPU≤70%）。
4.2 优化策略：分层治理
- 应用层优化：缓存热点数据、异步处理非核心逻辑（如日志写入）、合并数据库操作（如批量插入）；
- 中间件优化：调整数据库连接池大小、优化MQ消息堆积策略、启用HTTP长连接；
- 基础设施优化：扩容服务器、使用SSD替代机械硬盘、启用CDN加速静态资源。
4.3 持续压测：建立压测常态化机制
大促压测不应仅在618、双11前开展，而应建立月度压测或代码变更后压测的机制。例如，某团队在每次代码发布后自动触发压测任务，确保新功能不会引入性能回归。
五、总结：压测是技术，更是方法论
13年测试生涯让我深刻体会到：压测不是一次性的任务，而是一个持续优化的过程。从目标设定到场景设计，从工具选型到执行优化，每个环节都需结合业务特点量身定制。希望本文的实战经验能为正在备战618、双11的团队提供参考，让系统在高并发下依然稳定如初。