你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

性能测试的体系结构策略

适用于此 Azure Well-Architected 框架性能效率清单建议:

PE:06 测试性能。 在与生产环境匹配的环境中执行常规测试。 将结果与性能目标和性能基准进行比较。

本指南介绍测试建议。 性能测试可帮助你评估各种方案中工作负荷的功能。 它涉及到测试工作负荷的响应时间、吞吐量、资源利用率和稳定性,以帮助确保工作负荷满足其性能要求。

测试有助于防止性能问题。 它还有助于确保工作负荷满足其服务级别协议。 如果没有性能测试,工作负荷可能会遇到性能下降的情况,这些性能降低通常是可以预防的。 工作负荷性能可能会偏离性能目标并建立基线。

定义

术语 Definition
混沌测试 旨在通过故意引入随机且不可预知的故障或中断来测试系统的复原能力和稳定性的性能测试。
负载测试 一种性能测试,用于测量典型负载和繁重负载下的系统性能。
性能基线 一组指标,表示通过测试验证的正常条件下工作负荷的行为。
压力测试 性能测试,它会在系统中断之前重载系统。
综合测试 模拟应用程序中用户请求的性能测试。

性能测试有助于收集有关工作负荷的可度量数据。 在足够早地运行测试时,它们还有助于将工作负载构建到正确的规范中。 应在软件开发生命周期中尽早执行性能测试。 通过早期测试,可以捕获并修复开发中的性能问题。 如果生产代码未准备就绪,可以使用概念证明(POC)。

准备测试

准备性能测试是指设置和排列需要有效执行性能测试的资源、配置和测试方案。

定义验收条件

接受条件指定工作负荷需要满足的性能要求,才能被视为可接受或成功。 定义符合性能目标的条件。

查看性能目标。 性能目标定义工作负荷所需的性能级别。 查看为工作负荷建立的性能目标。 性能目标是可能涉及响应时间、吞吐量、资源利用率或任何其他相关性能指标的指标。 例如,响应时间的目标可能低于特定阈值,例如小于 2 秒。

定义验收条件。 将性能目标转换为可用于评估工作负荷性能的特定验收条件。 例如,假设响应时间的性能目标为 2 秒或更少。 验收条件可能是 工作负荷的平均响应时间应小于 2 秒。 使用这些验收条件来确定工作负荷是否满足所需的性能级别。

定义验收条件时,请务必关注用户及其期望。 验收条件有助于确保交付的工作满足用户需求和要求。 请记住将用户视角纳入验收条件的以下注意事项:

  • 用户要求:了解工作负荷的用户需求和目标。 考虑工作负荷应如何执行以满足这些要求。

  • 用户体验:定义捕获所需用户体验的验收条件。 包括响应时间、可用性、可访问性和总体满意度等因素。

  • 功能要求:解决用户期望在工作负荷中看到的特定功能。 围绕这些功能要求定义验收条件,以帮助确保满足这些要求。

  • 用例:考虑用户可能会遇到的不同方案或用例。 根据这些用例定义验收条件,以在实际情况下验证工作负荷的性能。

设置接受阈值。 确定验收条件中的阈值,这些阈值指示工作负荷是否满足性能目标。 这些阈值定义每个指标可接受的性能范围。 例如,假设响应时间的接受条件小于 2 秒。 可以将阈值设置为 2.5 秒。 此级别指示 2.5 秒内的任何响应时间都被视为性能问题。

定义传递条件。 确定工作负荷是通过还是未能通过性能测试,建立条件。 可以将传递定义为满足所有验收条件或达到其特定百分比。

选择测试类型

若要选择正确的性能测试类型,请务必将测试与验收条件保持一致。 验收条件定义需要满足的要求或 bug 修复才能考虑满足的条件。 性能测试应旨在验证工作负荷是否满足这些验收条件,并在指定条件下按预期执行。 将性能测试类型与验收条件保持一致有助于确保测试侧重于满足条件定义的性能预期。

  • 了解验收条件。 查看要求或 bug 修复的验收条件。 条件概述了要满足的特定条件和功能。

  • 确定相关的性能指标。 根据验收条件,确定实现所需结果至关重要的性能指标。 例如,如果接受条件侧重于响应时间,则确定负载测试的优先级可能合适。

  • 选择适当的测试类型。 评估可用的测试类型,并选择最符合已确定的性能指标和验收条件的测试类型。

下表提供了测试类型及其用例的示例。

测试类型 Description 用例
负载测试 模拟真实的用户负载,以测量工作负荷在预期峰值工作负荷下的表现。 确定负载容错。
压力测试 将工作负荷推送到其正常限制之外,以确定其断点并衡量其恢复能力。 确定复原能力和稳定性。
浸泡测试 (耐力测试) 长时间在持续高负载下运行工作负荷,以确定性能下降、内存泄漏或资源问题。 评估一段时间内的稳定性和可靠性。
峰值测试 模拟用户负载的突然增加,以评估工作负荷如何处理突然的需求变化。 测量在高峰期缩放和维护性能的能力。
兼容性测试 跨各种平台、浏览器或设备测试工作负荷的性能。 有助于确保跨各种环境保持一致的性能。

根据工作负荷的特征和要求确定所选测试类型的优先级。 考虑性能指标的关键性、用户期望、业务优先级以及已知问题或漏洞等因素。

选择测试工具

根据要运行的性能测试类型选择适当的工具。 评估测试环境的基础结构、资源和约束。 选择支持所需测试类型的测试工具,并提供监视、度量、分析和报告所需的功能。

应用程序性能监视 (APM) 工具提供对应用程序的深入见解,并且是一个基本的测试工具。 它有助于跟踪各个事务,并通过各种工作负荷服务映射其路径。 测试后,应使用 APM 工具分析和比较测试数据与性能基线。

使用分析工具识别代码中的性能瓶颈。 分析有助于识别消耗最多资源和需要优化的代码区域。 它提供对代码不同部分的执行时间和内存使用情况的见解。

以下步骤可帮助你选择适当的测试工具:

  • 确定测试要求。 首先了解性能测试的特定要求。 请考虑各种因素:

    • 工作负荷的类型
    • 要度量的性能指标,例如响应时间和吞吐量
    • 工作负荷体系结构的复杂性
    • 测试环境,例如基于云的、本地或混合
  • 研究测试工具。 进行研究以确定符合要求的性能测试工具。 考虑市场上可用的商业和开源工具。 查找支持所需性能测试类型的工具,例如负载测试或压力测试,并提供用于测量性能指标的功能。

  • 评估工具功能。 评估每个测试工具提供的功能。 查找模拟实际用户行为和可伸缩性等功能,以处理大型用户负载。 考虑支持各种协议和技术、与其他测试工具或框架集成以及报告和分析功能。

  • 请考虑兼容性和集成。 确定测试工具与现有基础结构和技术的兼容性。 确保工具可以轻松集成到测试环境中,并且可以与监视和分析所需的工作负荷通信。

  • 评估成本和许可。 评估与测试工具关联的成本结构和许可条款。 考虑初始投资、维护成本和支持成本等因素。 另请考虑依赖于用户数或虚拟用户的其他许可要求。

  • 进行 POC。 根据评估选择一些看起来最适合的工具。 执行小规模 POC,以验证特定测试方案中工具的可用性、功能和有效性。

  • 请考虑支持和培训。 评估工具供应商或社区提供的支持和培训级别。 确定文档、教程和技术支持渠道的可用性,以帮助解决在测试过程中可能出现的任何挑战或问题。

创建测试方案

创建测试方案是指设计适合测试工作负荷性能的特定情况或条件的过程。 创建测试方案以模拟现实的用户行为和工作负荷模式。 这些方案为性能测试人员提供了一种方法,用于评估工作负载在不同条件下的表现。

通过测试方案,可以复制各种工作负荷模式,例如并发用户访问、高峰负载周期或特定事务序列。 通过测试不同工作负荷模式下的工作负荷,可以识别性能瓶颈并优化资源分配。

  • 定义用户行为。 通过标识用户在与工作负荷交互时执行的步骤和作来模拟现实的用户行为和工作负荷模式。 考虑登录、执行搜索、提交表单或访问特定功能等活动。 将每个方案分解为表示用户与工作负荷交互的特定步骤和作。 可以包括浏览页面、执行事务或与工作负荷的各种元素交互。

  • 确定数据参与。 确定运行测试方案所需的测试数据。 可能包括创建或生成代表各种方案、用户配置文件或数据卷的实际数据集。 确保测试数据多样化,并涵盖不同的用例,以提供全面的性能评估。

  • 设计测试脚本。 创建自动执行定义的测试方案的测试脚本。 测试脚本通常包括一系列作、HTTP 请求或与工作负荷 API 或用户界面的交互。 使用性能测试工具或编程语言编写脚本,考虑参数化、关联和动态数据处理等因素。 验证测试脚本是否正确和功能。 调试任何问题,如脚本错误、作缺失或错误或数据相关问题。 测试脚本验证对于帮助确保准确可靠的性能测试执行至关重要。

  • 配置测试变量和参数。 在测试脚本中配置变量和参数,以引入可变性并模拟实际方案。 包括参数(如用户凭据、输入数据或随机化),以模拟不同的用户行为和工作负荷响应。

  • 以迭代方式优化脚本。 根据反馈、测试结果或更改要求持续优化和增强测试脚本。 请考虑优化脚本逻辑、参数化和错误处理,或添加额外的验证和检查点。

配置测试环境

配置测试环境是指设置基础结构、软件和网络配置的过程,这些配置需要创建与生产环境非常相似的环境。

若要以提升性能效率的方式设置测试环境,请在配置过程中包括以下步骤:

  • 镜像生产环境。 将测试环境设置为与生产环境非常相似。 考虑基础结构配置、网络设置和软件配置等因素。 目标是确保性能测试结果代表实际条件。

  • 预配足够的资源。 将足够的资源(例如 CPU、内存和磁盘空间)分配给测试环境。 确保可用资源可以处理预期的工作负荷并提供准确的性能度量。

  • 复制网络条件。 在测试环境中配置网络设置,以在实际工作负荷部署期间复制预期的网络条件。 需要包括带宽、延迟和网络协议。

  • 安装和配置依赖项。 安装工作负荷正常运行所需的软件、库、数据库和其他依赖项。 配置这些依赖项以匹配预期的生产环境。

权衡:与维护单独的测试环境、存储数据、使用工具和运行测试相关的成本。 了解性能测试的成本,并找到优化支出的方法。

风险:生产数据可以包含敏感信息。 如果没有可靠的清理和掩码策略,在使用生产数据进行测试时,可能会泄露敏感数据。

执行测试

使用所选的测试工具运行性能测试。 测试涉及测量和记录性能指标、监视运行状况以及捕获出现的任何性能问题。

监视和收集性能指标,例如响应时间、吞吐量、CPU 和内存利用率以及其他相关指标。

使用定义的测试方案将工作负荷置于预期负载之下。 在这些不同的负载条件下执行测试。 例如,使用级别(如正常、峰值和压力级别)分析各种方案中工作负荷的行为。

分析结果

分析测试结果涉及检查性能测试中收集的数据和指标,以便深入了解工作负荷的性能。 目标是确定性能问题,并使用反馈调整应用程序开发中的优先级。 以下作是分析测试结果的关键步骤。

查看性能指标。 查看性能测试期间收集的性能指标,例如响应时间、吞吐量、错误率、CPU 和内存利用率以及网络延迟。 分析这些指标,了解工作负荷的总体性能。

  • 确定瓶颈。 评估性能指标,以确定性能低效的任何瓶颈或领域。 评估可能包括较高的响应时间、资源约束、数据库问题、网络延迟和可伸缩性限制。 查明这些瓶颈的根本原因有助于确定性能改进的优先级。

  • 关联指标。 评估各种性能指标之间的关系和相关性。 例如,分析增加的负载或资源利用率如何影响响应时间。 了解这些关联可以为不同条件下的工作负荷行为提供有价值的见解。 查找一段时间内性能数据的模式和趋势。 分析不同负载级别或特定时间段下的性能。 检测趋势有助于识别季节性变化、高峰使用时间或定期性能问题。

评估验收条件。 将重新测试结果与预定义的验收标准和性能目标进行比较。 评估工作负荷是否符合所需的性能标准。 如果工作负荷不符合验收标准,请进一步调查和优化优化。

循环访问和优化分析。 根据需要进行其他调整和改进。 使用收集的数据和指标诊断特定的性能问题。 诊断可能涉及通过工作负荷组件进行跟踪、检查日志文件、监视资源使用情况或分析错误消息。 深入了解数据,了解性能问题的根本原因。

根据测试结果的分析,确定的性能问题优先级并实施必要的改进。 这些改进可以涉及优化代码、优化数据库查询、改进缓存机制以及优化网络配置。

建立基线

基线提供了一个参考点,用于比较一段时间内的性能结果。 基线应是工作负荷性能的有意义的快照,无需将每个测试用作基线。

考虑工作负荷目标,并记录性能快照,以便随时间推移进行学习和优化。 将这些基线度量用作未来性能测试的基准,并使用这些度量值来确定任何降级或改进。

若要为性能测试建立基线并将其用作未来性能测试的基准,请执行以下步骤:

  • 确定性能指标。 确定要度量和跟踪的特定性能指标。示例包括:

    • 响应时间,或工作负荷响应请求的速度。
    • 吞吐量或按单位时间处理的请求数。
    • 资源利用率,例如 CPU、内存和磁盘使用情况。
  • 记录有意义的度量值。 将测试期间获取的性能指标记录为基线度量值。 这些度量表示比较未来性能测试的起点。

  • 比较将来的测试。 在后续性能测试中,将性能指标与已建立的基线和阈值进行比较。 通过比较,可以识别性能的任何改进或降级。

持续测试

持续测试涉及持续监视和优化测试。 持续测试有助于保持一致且可接受的性能级别。 工作负荷应提供相对于基线的一致且可接受的性能级别。 应随着时间的推移优化工作负荷,以生成符合可接受的性能限制的一致性能。 下面是一些关键做法:

  • 设置降级限制。 定义数值阈值,指定一段时间内可接受的性能降级级别。 通过设置这些限制,可以监视性能波动,并在性能低于定义的阈值时接收警报。

  • 包括质量保证。 将性能要求(例如 CPU 利用率和每秒最大请求数)纳入质量保证过程。 将性能要求与功能要求具有相同的重要性级别对待。 此过程有助于确保在将工作负荷部署到生产环境之前满足定义的性能要求。

  • 自动发出警报。 在实时环境中,快速检测和响应至关重要。 设置使用性能基线作为其参考的自动警报系统。 如果性能存在重大偏差,则会立即通知必要的团队采取行动。

  • 测试更改。 某些性能问题可能仅显示在实时设置中。 对建议的代码和基础结构更改应用全面的测试做法。 使用代码检测来深入了解应用程序的性能特征,例如热路径、内存分配和垃圾回收。 此测试可确保引入的任何更改不会降低超出可接受的限制的性能。

Azure 便利化

执行测试Azure Pipelines 使你能够将性能测试集成到 CI/CD 管道中。 可以将负载测试合并为管道中的一个步骤,以验证应用程序的性能和可伸缩性。

Azure Chaos Studio 提供了一种将实际故障注入应用程序的方法,以便可以运行受控的故障注入试验。 这些试验可帮助你衡量、了解和改进云应用程序和服务复原能力。

Azure 负载测试 是一种负载测试服务,用于在任何应用程序上生成大规模负载。 负载测试提供自动执行负载测试并将其集成到持续集成和持续交付(CI/CD)工作流的功能。 可以定义测试条件,例如平均响应时间或错误阈值,并根据特定的错误条件自动停止负载测试。 负载测试提供一个仪表板,用于在负载测试期间提供 Azure 应用程序组件的实时更新和详细的资源指标。 可以分析测试结果,识别性能瓶颈,并比较多个测试运行,以了解随时间推移的性能回归。

分析结果Azure Monitor 是一种全面的监视解决方案,用于从云和本地环境收集、分析和响应遥测数据。 Application Insights 是监视器的扩展,提供 APM 功能。 可以在开发和测试期间以及生产环境中使用 Application Insights 监视应用程序。

权衡:测试需要时间和技能才能执行,并可能影响运营效率。

性能效率清单

请参阅完整的建议集。