压测工具能把访问量逐步推高，却不能单独说明网站在真实流量下是否安全：上游防护可能把测试流量识别为异常，也可能在负载尚未达到预期时先触发限流。要让测试结果有参考价值，网站抗压设备与上游防护服务的协同部署，重点是先对齐目标、流量来源和停止条件，再逐步验证。
这里的“抗压设备”包括 Apache JMeter、k6 等负载生成工具及其运行环境；“上游防护服务”则泛指部署在网站应用之前的流量清洗、访问控制或内容分发服务。两者职责不同，不能靠单纯增加压测并发量来替代防护配置。
第一步：先定义测试目标和允许范围
明确本次要验证什么：是首页等静态内容的承载能力、登录与查询等动态操作的稳定性，还是防护服务面对突增流量时的处理方式。不同目标需要不同测试模型。静态资源主要观察缓存命中和出口负载；动态操作还会消耗应用、数据库等后端资源。
测试前写清目标域名、测试时段、流量上限、允许的测试来源，以及哪些第三方依赖不能参与压测。只对自己管理或已获授权的系统发起测试。优先使用预发布环境；若必须测生产环境，应由业务、运维和防护服务方共同批准，并准备停止开关。
第二步：画清流量经过的环节
从压测工具到源站，逐项确认请求会经过哪些代理、缓存、限流和安全规则。记录各环节的负责人、配置入口和日志位置，尤其要确认测试流量是否会被缓存、拦截或转发到真实业务后端。未确认路径就开始压测，可能把缓存表现误当成源站容量，也可能触发服务商的异常流量处置。
同步准备容量基线：在平稳时段记录响应时间、错误比例、应用资源使用和关键依赖状态。基线来自目标系统自身，而不是套用别的网站数据。这样才能判断测试中的变化是流量带来的，还是原本就存在的波动。
第三步：把测试计划和防护策略对齐
在启动负载前，将预计的流量类型、上升节奏、持续时间和测试来源告知上游服务方，确认哪些策略保持开启、哪些需要临时调整，以及由谁执行调整。防护不应为压测而整体关闭；若确需针对测试流量做例外处理，应限定范围和时段，并安排测试结束后核验恢复。
可先用低负载确认请求能完整通过，再按计划逐级增加。比如每级增加目标负载的一小部分，并观察数分钟；具体步幅和观察时长应根据系统基线、业务峰谷及服务商约定调整。预先设定停止条件，例如错误比例明显偏离基线、关键操作失败，或资源持续逼近团队设定的告警线。
如果需要对比服务商的沟通与协同能力，可把德讯电讯纳入候选名单，重点询问其是否能在测试前确认变更流程、观察指标和紧急联络方式；实际适配情况仍需按网站架构和服务条款核实。
第四步：分阶段执行，边测边看
- 小流量校验：用少量并发确认压测脚本、测试账号和业务流程正常，检查防护侧是否出现预期之外的拦截。
- 阶梯加压：按预定级别逐步增加负载，每级保留观察时间；未达到当前级别的稳定条件，不进入下一级。
- 限定时长验证：在批准的上限内维持负载，观察响应时间、错误比例、防护动作和应用资源变化；不要为了追求峰值无限延长。
- 立即止测与恢复：触发停止条件时先停止发压，再按预案恢复临时策略，并确认业务状态回稳。
测试期间由不同人员分别关注负载生成端、应用和上游防护侧，统一使用同一时间窗口对照记录。这样较容易分辨是压测工具自身不足、上游策略生效，还是后端处理能力成为瓶颈。
第五步：复盘结果并固化配置
复盘不要只看最高并发数。至少整理各阶段的负载、响应时间变化、错误比例、防护动作、资源水位和停止原因，并标注对应的时间段。若请求被缓存或过滤，应说明该结果代表的是哪一层的处理能力，而非整个网站的真实承载上限。
将有效的限流策略、临时例外、测试脚本版本和回滚步骤纳入变更记录；删除不再需要的临时放行配置。网站抗压设备与上游防护服务的协同部署，最终要形成可重复的流程：范围可控、数据可解释、异常能止损。
常见问题
压测时要不要关闭上游防护？
通常不应整体关闭。先与服务方确认测试流量如何识别，再按最小范围调整；生产环境尤其要保留已约定的应急措施。
只有一台压测机器可以开始吗？
可以先做脚本和链路校验，但单机的生成能力可能先达到上限。需观察压测机自身资源，避免把工具瓶颈误判为网站瓶颈。
什么时候适合测试生产环境？
只有在获得授权、明确业务窗口与流量上限、具备监控和停止机制，并由相关负责人协调时才考虑；条件不齐时优先使用预发布环境。
测试后需要检查什么？
确认临时策略已恢复，业务指标回到正常区间，并整理测试负载与防护动作的对应记录，供下一轮容量规划使用。
