谁会与我们一起规划负载测试
你不知道你的产品在页面变慢或请求失败之前能承受多少流量，也不知道哪一部分会最先垮掉：是代码、数据库，还是你依赖的某个服务。
- 预期因发布、促销或媒体报道而出现流量峰值的团队
- 在迁移数据库、托管或架构之后的工程负责人
- 即将接入一个远比现有任何客户都大得多的客户的 SaaS 团队
从基线到结果
典型的 Web 应用测试流程；停止条件在首次运行之前会与你商定。
基线
记录关键流程在正常流量下的表现，让之后的每一次运行都有一个参照基准。
检查点: 目标与停止标准已获签署确认
加载至峰值
逐步提升至你预期的峰值并保持，同时观察队列、连接池和第三方调用。
检查点: 如果错误超过约定上限则停止
压测超越峰值
分步将负载提升到峰值之上，直到某处崩溃，并记录哪个组件最先失效。
检查点: 在约定的负载上限处停止
突发峰值
发送一次陡峭的激增，然后迅速回落，以查看自动扩缩容和缓存能否干净地恢复。
检查点: 如果恢复停滞则停止
长时间浸泡测试
在较长的时间窗口内维持稳定负载，以暴露缓慢的泄漏和逐渐的漂移。
检查点: 如果内存持续攀升则停止
发现与复测
按对用户的影响对瓶颈进行排序，提出修复方案，并重新运行受影响的场景以确认效果。
当出现故障时: 如果触发了某个停止标准，我们会暂停此次运行，保留日志和指标，并在恢复前与你商定下一步。
在流量找到你的极限之前，先了解它
缓慢的页面和超时往往在流量达到峰值时出现：产品发布、促销、营销活动或月末批处理。性能测试展示你的应用程序、数据库和基础设施在真实负载下的表现，它们会在哪里以及为何出现劣化。我们根据你的分析数据和计划建模流量，在与你商定的环境中测试，将瓶颈追溯到其根本原因，并在修复后重新测试。这也包括调用 AI 模型的功能，其延迟、速率限制和成本会随流量增长。
AI 辅助分析，工程师主导的测试
AI 如何协助
- 根据你的 API 规范、分析数据和访问日志起草负载脚本和流量模型，供工程师审查。
- 将响应时间与追踪数据、数据库查询和资源指标关联起来，指出可能的瓶颈。
- 汇总长时间的测试运行，并将其与早期基线比较，以标记性能回退。
我们的专家负责什么
- 由工程师决定对你的业务而言什么是真实负载，以及哪些阈值算作失败。
- 测试时段、环境和负载上限在任何测试运行之前都会与你商定。
- 每个瓶颈在推荐修复方案之前都会通过性能剖析加以确认。
- 修复方案按影响和工作量排定优先级，然后针对同一基线重新测试。
您将获得什么
负载测试、诊断和容量规划
负载和压力测试
使用 k6、JMeter 或 Gatling 等工具模拟预期和峰值流量，找出响应时间和错误率开始攀升的位置。
尖峰和浸泡测试
突发激增和长时间的耐久运行，揭示扩展缺口、内存泄漏和连接池耗尽问题。
瓶颈分析
慢查询、缺失的索引、重复的数据库调用、阻塞代码和饱和的服务，通过性能剖析和可观测性数据加以追溯。
前端性能审查
在最重要的页面上检查 Core Web Vitals、打包体积、渲染和缓存，并给出具体的修复方案。
第三方和 AI 模型限制
支付网关、模型 API 和其他服务在负载下的表现：速率限制、超时、重试、回退机制和使用成本。
容量报告和基线
你的系统最先在哪里劣化以及需要修复什么，还有可重复的脚本和基线留存在你的代码库中，供未来发布使用。
一次性能测试如何进行
- 01
基线和目标
测量当前表现，为关键流程商定目标响应时间和错误率，并确认测试环境。
- 02
建模真实流量
根据分析数据、日志和业务计划构建场景：用户构成、爬升、峰值和持续负载，包括第三方调用。
- 03
运行和诊断
在观察应用程序、数据库和基础设施指标的同时运行测试，并将每个瓶颈追溯到其根本原因。
- 04
修复、重测、报告
推荐或实施修复方案，重新运行相同场景以确认收益，并交付容量报告。
典型的负载测试需求
我们所界定范围的典型场景，而非客户案例研究。
伴随急剧激增的限量发布
一家店铺计划进行限量商品发售，大多数访客会同时涌入。我们根据过往流量和预期注册量建模这次激增，在预发布环境中运行尖峰测试，并展示哪个组件最先饱和。
数据库迁移后页面变慢
一个团队迁移到了托管数据库，繁忙时段现在感觉很慢。我们针对早期测量结果重新运行相同场景，剖析最慢的查询和连接设置，并通过重测确认每一处修复。
繁忙页面上的 AI 摘要
一款产品在大多数访客都会打开的页面上添加了 AI 生成的摘要。我们测试模型提供商的速率限制、超时和重试在峰值时的表现，检查用户看到的回退机制，并估算使用成本如何随流量增长。
负载测试不涵盖的内容
- 蓄意的拒绝服务攻击不在范围之内；我们生成的是真实流量，而非攻击流量。
- 第三方 API 仅在其条款允许的范围内加载；超出该范围时我们会对其进行打桩，并测试你如何处理它们的限制。
- 功能正确性属于 Software QA & Testing；本服务衡量的是负载下的速度、错误和容量。
- 超出查询、缓存和代码路径之外的修复，例如重新架构或新的托管方案，会在 Cloud Infrastructure 或 Application Modernization & Stabilization 下单独界定范围。
性能工作如何在团队中贯通协作
设计：用户能感知到的速度
设计师审查加载状态、渐进式渲染以及对缓慢操作的反馈，让产品即使在处理耗时时也显得反应灵敏。
工程：从根本原因修复
工程师修复测试中发现的查询、缓存和代码路径，并重新运行同一场景以确认改进效果。
运维：容量和告警
测试结果用于服务器规格选型或自动扩缩、容量和成本规划以及告警阈值，并与运行你基础设施的人员商定。
持续性：及早捕捉性能下降
关键场景在重大发布之前和基础设施变更之后重新运行，使性能回退在用户察觉之前就浮现出来。
常见问题
常见问题解答
性能测试会影响我们的线上用户吗？
通常我们在规格与生产环境相当的预发布环境中测试。如果需要进行生产环境测试，我们会先与你商定时段、负载上限和停止条件，并在第三方提供商的条款有要求时通知他们。
你们能模拟多大的负载？
足以达到你的真实峰值并超越它。当单台机器不够用时，我们会在云中使用分布式负载生成器。目标是找出你的系统在哪里劣化以及为何劣化，而不是产出一个漂亮的数字。
我们应该多久运行一次性能测试？
在重大发布和营销活动之前、基础设施或架构变更之后，以及当你切换某个 AI 功能背后的模型或提供商时。关键场景也可以按计划运行或在你的流水线中运行，以捕捉逐渐出现的性能下降。
你们需要生产数据吗，AI 工具会看到这些数据吗？
大多数测试无需生产数据：我们根据分析数据和匿名化日志建模流量，并生成合成测试数据。AI 辅助分析在你选择的边界内运行：在你掌控的基础设施上进行 私有 / 本地 AI 工程，或在商定的数据处理条款下与商业提供商进行 Claude Code / OpenAI Codex 工程。
