性能测试

性能测试概述

性能测试是在网站、Web 应用程序或 API 上施加一定数量的并发用户或请求，按照计划的曲线逐渐增加需求，并记录变化情况：响应时间、吞吐量、错误率，以及系统为保持响应所使用的服务器、数据库和网络容量。输出结果是一组数字，用于与目标值比较，而非对网站速度的主观感受。

目标可以是公共网站、通过门户或 SaaS 应用程序的身份验证流程、一系列 API 调用，或防火墙后的内部 Web 应用程序。

目标不是让网站总体加速，而是确认其最重要的页面、工作流程和 API 调用在预期流量下满足定义的要求。一个结账流程对单个用户可能正常，但当数百客户同时下单时可能变慢或超时。

功能测试确认页面或交易正常运作。性能测试衡量随着流量增加，页面或交易是否仍保持快速、稳定和可靠。

你可以进行哪些性能测试？

性能测试通常涵盖四种 HTTP/S 目标：网站、Web 应用程序、API 和内部 Web 应用程序。每种目标需要不同的脚本和测量方式。

为什么性能测试很重要

性能测试的价值在于在用户发现问题之前给出明确答案：

• 瓶颈在发布前暴露。缓慢查询或连接池不足会出现在测试报告中，而不是客户支持队列。
• 容量和扩展计划得到验证。自动扩展规则、CDN 缓存设置和实例大小在流量验证之前都是假设。
• 实现收益的流程得以保护。登录、搜索、结账、文件上传及其背后的 API 调用是优先测试的路径。
• 高峰活动减少慢响应、错误和宕机。活动发布、促销、注册窗口和季节性销售通常有可预测的流量模式，可提前测试。
• 回归问题被捕捉。代码、API、数据库、基础设施和外部服务的变更都会对性能产生细微影响，且累积于多个发布。
• 发布决策和服务等级目标有事实依据。一个对目标的 p95 数字比“感觉慢”更易于行动。

性能测试的类型

每种类型采用不同的流量形态，以回答不同问题。大多数方案会组合多种类型。

耐久测试和浸泡测试是同一种测试的两个名称，不是两种类型。负载测试和压力测试之间的界线也是团队最常混淆的，单独有页面讨论：负载测试与压力测试。

性能测试是总类。每种类型改变流量大小、速率和持续时间。

性能测试与负载测试的区别

性能测试是评估系统在不同条件下速度、稳定性、扩展性和资源利用的广义实践。负载测试是性能测试的一个子集，聚焦于预期和峰值流量。

术语常被混用，因为负载测试通常是团队首次运行的性能测试。其他类型测试用于发现系统崩溃点、长期性能衰退或扩展问题。

包含压力测试的比较，请阅读性能测试 vs. 压力测试 vs. 负载测试。

如何进行性能测试

以下步骤适用于着陆页、结账流程或身份验证的 API 序列。

1. 定义目标和验收标准

明确测试必须证明的数字要求。例如：结账流程在 1,500 并发用户时，p95 响应时间小于 2 秒；错误率低于 0.5%；订单 API 支持每秒 400 笔交易。没有通过/失败标准的测试只能产生数据，无法做出决策。

2. 建模网站、应用或 API 流量

采集网站分析、访问日志、APM 数据和业务预测。识别关键页面或流程，流量如何分配，高峰并发，请求率，步骤间思考时间，地域分布和每个会话的 API 调用数。页面浏览量不等于并发用户：每日 100,000 次页面浏览，峰值并发可能只有几百个会话，模型应明确说明。

3. 准备代表性测试环境

尽量匹配生产的 Web 堆栈、应用版本、数据库容量、CDN 和缓存行为、API 依赖、集成和扩展规则。使用安全的测试账号和支付沙盒。环境必须差异化时，记录差异，避免误将结果视为生产保证。

4. 选择测试类型和方法

根据步骤 1 的问题选择负载、压力、突发、耐久、容量、扩展性或组合测试。然后确定生成流量的方法。HTTP/S 测试直接发送请求，适合对页面和 API 进行高请求量测试。真实浏览器测试运行 JavaScript，跟踪多步骤用户行为，更准确测量用户等待时间。许多团队同时进行协议测试以覆盖规模，以及少量真实浏览器用户测试用户体验。

5. 建立基线

在不变条件下运行中等负载控制测试，确认脚本完成、测试数据有效，负载生成器非瓶颈。记录结果和测试条件，以便后续因缓存、测试数据或环境差异导致的比较失真有据可查。

6. 运行测试并监控整体系统

沿计划的负载曲线（平滑攀升、阶跃或突发）逐步增加压力，而非一次施加未说明数量的用户。收集 Web 服务器、应用、基础设施、数据库、网络和外部服务的数据，与测试结果一同分析。无服务器端数据，只能确认性能下降，却无法定位原因。

7. 分析瓶颈

先与验收标准对比结果，然后在同一时间窗口内，将缓慢交易或错误与 CPU、内存、数据库、缓存、队列、连接池、网络及依赖行为关联分析。定位到具体组件及其性能下降条件时停止，不要仅停留在平均响应时间。

8. 修复、复测和自动化

每次改变一个关键变量，重复相同场景并与基线比较。随后将更小的回归测试纳入 CI/CD，关键交易每次构建均运行，大型测试安排于主要发布、活动和季节高峰前。

关键性能测试指标

测试指标描述用户体验，系统指标帮助解释原因。两者均需在同一测试周期内收集，以定位原因。

测试指标识别症状，服务器、数据库和监控数据定位原因。LoadView 性能报告覆盖测试端，从汇总图表到每个会话的瀑布图，帮助追踪慢交易。但服务器端数据需通过自有监控或 APM 与测试时间线匹配采集。

如何解读性能测试结果

多数 Web 系统表现出以下几种模式。单一模式不足以断定根因，但指示后续调查方向。

当吞吐量平稳且响应时间开始快速上升时，系统很可能已达到容量极限。

何时执行性能测试

性能测试非发布前一次性的任务。典型触发时机：

• 设计早期，在架构和重要用户路径确定阶段，变更成本低。
• 关键变更后，包括代码、数据库模式、基础设施或集成的变更，以及外部脚本和 CDN 配置调整。
• 在 CI/CD 流程中，对关键交易进行简短回归检查。
• 重大发布、活动、季节高峰和迁移前，以事件预测流量水平开展测试。
• 生产事件后，确认修复在触发条件下有效。
• 定期执行，捕获无单次发布导致的性能漂移。

性能测试与网站速度测试的区别

网站速度测试通常在无其他流量干扰下，加载单一页面或会话，报告加载耗时，适用于前端优化和版本间对比。

性能测试施加变化量级的流量或并发用户，观察网站、应用或 API 随需求增加的表现。两者均报告页面或响应时间，但性能测试额外测量系统承载用户数、峰值错误率、吞吐量瓶颈和稳定持续时长。速度测试表现出色的页面，在数百并发会话下仍可能失败。

如何选择性能测试工具

评价云性能和负载测试工具时，应根据需执行的测试类型，而非单纯功能数量：

• 支持网站、多步骤 Web 应用及所使用的 API 协议，包括鉴权流程。
• 能模拟真实流量：浏览器路径、API 序列、思考时间、数据变异和可调整的负载曲线。
• 提供满足峰值需求的足够规模，且测试节点分布符合用户区域。
• 支持协议测试、真实浏览器测试或两者结合，视测量需求而定。
• 生成有用的分布指标、错误详情、每交易结果及可与非测试人员共享的报告。
• 集成 CI/CD 及服务器端监控、可观测性工具。
• 支持防火墙内测试内部应用。
• 便于负责创建和复测的人员维护。

性能测试最佳实践

• 从具体的业务或工程问题出发，设计测试方案。
• 基于分析、日志和预测构建负载模型，而非凭猜测。
• 测试登录、搜索和结账等关键交易，而非仅主页。
• 使用现实数据量和尽可能匹配生产环境，差异须记录。
• 区分被测系统问题和负载生成配置限制。先检查负载生成器 CPU 和网络。
• 聚合分布指标、错误、吞吐和服务器资源数据在同一时段分析。
• 诊断时一次变动一个关键变量。
• 保存基线，每次改动后比较同一场景。
• 包含外部依赖和地域延迟，确保覆盖真实用户路径。

使用 LoadView 进行性能测试

LoadView 是云端负载测试平台，可测量网站、多步骤 Web 应用和 API 在不同流量下的性能。流量源自托管云，无需建设维护负载生成基础设施。

针对请求量问题，HTTP/S 测试发送数千并发请求，报告响应时间、吞吐量和端点错误。针对用户路径问题，Web 应用负载测试在真实浏览器中运行脚本，测量 JavaScript 执行和渲染时间。脚本用 EveryStep Web Recorder 录制，只需点击一次路径。API 负载测试覆盖 REST 和 SOAP 端点，包括鉴权和多步骤调用序列。

负载曲线可调：分步负载曲线在设定周期内平滑变化并发用户；基于目标的曲线在固定时间内实现所需交易率；动态可调曲线允许测试过程中调整用户数。流量可来自 40 多个分布区域的地理分布网络，涵盖区域延迟和 CDN 行为。

报告显示执行计划、每分钟交易数、响应时间和错误类型，并配备每会话瀑布图，帮助追踪慢请求。LoadView 与 Jenkins、Azure DevOps 和 CircleCI集成。Jenkins 和 CircleCI 可用失败会话阈值，构建失败当错误率超限。内部应用可通过白名单静态 IP 或本地安装的负载注入器进行防火墙内测试。

性能测试常见问答