load-test-plan-guide

压测方案落地操作手册 一、准备阶段 1. 明确压测目标 - 确定压测类型（如负载测试、压力测试、稳定性测试等） - 定义核心指标：如响应时间、吞吐量（TPS/QPS）、错误率、资源利用率（CPU、内存、磁盘I/O、网络）等 - 设定性能基线或预期目标（例如：支持1000并发用户，平均响应时间<2秒） 2. 梳理业务场景 - 识别关键业务路径（如登录、下单、支付、查询等） - 确定各场景的流量占比（用于构造真实流量模型） - 明确数据依赖（如用户账号、商品库存、订单状态等） 3. 准备测试环境 - 搭建与生产环境尽可能一致的测试环境（包括硬件配置、网络拓扑、中间件版本等） - 确保环境隔离，避免影响线上服务 - 配置监控工具（如Prometheus、Grafana、APM系统、日志系统等） 4. 构造测试数据 - 准备足够的测试账号、商品、订单等基础数据 - 数据需具备多样性（如不同用户等级、不同商品类别） - 确保数据可重复使用且不影响后续测试 5. 开发压测脚本 - 使用压测工具（如JMeter、Locust、k6、Gatling等）编写脚本 - 模拟真实用户行为（包括思考时间、操作间隔、参数化请求） - 添加断言和检查点，验证响应正确性 - 支持动态参数（如Token、SessionID、订单号等） 6. 配置压测工具 - 设置并发用户数、 ramp-up 时间、持续时间等参数 - 配置分布式压测（如需大规模并发） - 确保压测机资源充足，避免成为瓶颈 二、执行阶段 1. 预压测试（冒烟测试） - 使用小并发（如10-50用户）运行5-10分钟 - 验证脚本正确性、环境连通性、监控是否正常 - 快速发现明显问题并修复 2. 正式压测执行 - 按预设场景逐步增加负载（如阶梯式加压） - 每个阶段持续足够时间（建议10-30分钟），观察系统稳定性 - 实时监控关键指标，记录异常现象（如超时、错误激增、资源瓶颈） 3. 多场景组合测试 - 模拟混合业务场景（如70%查询 + 20%下单 + 10%支付） - 验证系统在真实流量模型下的表现 4. 极限压测与破坏性测试（可选） - 逐步加压直至系统崩溃，观察故障表现和恢复能力 - 记录系统最大承载能力（如最大并发数、最大TPS） 5. 记录压测过程 - 保存压测日志、监控截图、错误信息 - 记录每次压测的配置参数和结果数据 三、自检与复盘阶段 1. 数据整理与分析 - 汇总各阶段性能指标（响应时间分布、TPS曲线、错误率变化） - 分析系统瓶颈（如数据库慢查询、线程阻塞、GC频繁、网络延迟） - 对比压测目标，判断是否达标 2. 问题定位与验证 - 对发现的性能问题深入排查（如代码热点、SQL优化、缓存策略） - 修复后进行回归压测，验证优化效果 3. 输出压测报告 - 包含：压测背景、目标、环境、场景、结果、问题清单、优化建议 - 附上关键图表（如TPS/响应时间趋势图、资源使用率图） - 明确系统当前性能水位及风险点 4. 团队复盘与改进 - 组织相关方（开发、运维、测试、产品）复盘会议 - 总结经验教训，优化压测流程 - 将压测结果纳入性能基线，用于后续版本对比 5. 归档与知识沉淀 - 保存压测脚本、配置、报告等资料 - 更新压测checklist，形成团队标准操作流程 附：压测Checklist（快速自检） ✅ 压测目标是否明确？ ✅ 测试环境是否与生产一致？ ✅ 监控是否覆盖全面？ ✅ 测试数据是否准备充分？ ✅ 压测脚本是否经过验证？ ✅ 是否进行预压测试？ ✅ 是否记录完整过程数据？ ✅

存档时间线

版本索引永久保留；内容副本只保留最新 1 份，更早版本仅留索引与哈希（存档时间线的证据链不会因此断裂）。

下载存档内容副本