负载测试最佳实践检查清单

# 性能导向可靠性工程师的负载测试心得 - 每次负载测试都从书面目标开始，例如在每秒500个请求下p95延迟低于300毫秒，而不是模糊的“看看哪里会出问题”。 - 使用k6、Gatling或Locust将负载测试写成代码，并与服务保存在同一仓库中。 - 根据生产日志模拟真实流量：端点组合、负载大小以及请求之间的思考时间。 - 在测试面向互联网的服务时，使用固定到达率的开放工作负载模型，因为封闭模型会隐藏排队延迟。 - 有目的地运行不同类型的测试：冒烟测试、预期峰值负载测试、超出峰值的压力测试、突发测试，以及用于内存泄漏的长时间浸泡测试。 - 以百分位数报告延迟，至少包括p50、p95和p99，绝不只依赖平均值。 - 在测试脚本中定义通过或失败阈值，以便CI能自动使构建失败。 - 在类似生产的环境中运行负载测试，使用相同的实例大小、数据量和配置。 - 种子测试数据需匹配生产基数，因为小型数据库会让所有查询看起来都很快。 - 在测量前预热缓存和连接池，并从结果中排除预热期。 - 从CPU和网络余量充足的机器生成负载，并监控负载生成器自身的指标。 - 将测试结果与服务器端指标、追踪和日志关联起来，以找到真正的瓶颈，而不是猜测。 - 跟踪错误率和超时，与延迟并列；快速响应但返回错误并不算成功。 - 每次运行只改变一个变量，并记录每次结果对应的提交、配置和环境。 - 在每次合并到主分支时运行简短的性能冒烟测试，并在重大发布前运行完整套件。 - 与存储的基线进行比较，并标记超过约定百分比的回归。 - 对按调用收费或强制速率限制的第三方API进行模拟或沙箱化，但对自己的依赖进行真实测试。 - 找到崩溃点并记录系统如何失败：优雅地以429或503拒绝优于崩溃。 - 通过逐步增加负载并测量新容量生效所需的时间，验证自动扩展是否能及时响应。 - 向团队和值班工程师宣布负载测试，未经批准绝不指向共享生产系统。 - 将发现转化为具有明确余量目标的容量计划，例如运行在测试限制的60%以下。