本篇文章将对性能测试做一个简要的介绍。这是针对 ISO25010 标准中指出的“性能”属性或更确切地说是软件产品非功能属性中的“性能效率”进行的测试。

性能效率被定义为在限定资源条件下的表现。[ISO25010]

什么是性能？

性能与 IT 系统执行任务的时间以及此类系统可以处理的负载有关。由于 IT 系统有许多不同的用途，因此用户对性能的期望也会有所不同。通常重要的性能指标包括实时系统的响应时间、批处理的持续时间以及可以同时处理的用户数量。在测试性能时，涉及到 IT 系统的各个层次。每一层都可能对用户体验到的整体性能产生特定的影响。

我们区分以下几种性能测试：

• 负载/压力测试：
  用于评估系统在组件级别以及用户级别上可能达到的预期负载。在组件级别，性能测试将测试组件是否符合基本性能要求，例如每秒数据库事务数、每秒 API 调用等。在用户级别，模拟真实用户场景测试系统性能。压力测试旨在超越常规的负载预期/要求：从未来数月或数年的预期负载增加到旨在让系统崩溃，以测试故障转移/恢复过程。
  
• 功能性性能测试：
  创建的功能应该能够应对多用户和/或高负载情况。例如，正确执行不会相互影响（或其他业务流程）的批处理流程、在多用户情况下正确处理事务。这种测试往往伴随在开发过程中进行。

ISO25010 标准定义了性能的三个子属性：

• 时间性能：响应和处理时间以及吞吐率满足要求的程度。
• 资源利用率：所使用的资源数量和类型满足要求的程度。
• 最大容量：各项指标到达最大限制时所承载的容量。

什么是性能测试

性能测试确定 IT 系统是否符合相关的性能要求。随着性能关键技术集成到我们个人生活的各个方面，如云计算、移动解决方案和“物联网”，正确处理性能要求变得更加重要。

在现实生活中，对性能的要求往往没有明确规定；对于利益相关者而言，显然性能必须良好，但他们往往无法具体说明对他们来说什么是“良好”。在细化用户故事（或其他需求文档）期间，团队成员应特别注意非功能性需求，例如性能效率。即使完全没有性能要求，团队组织和执行性能测试也是有用的。

性能测试的组织

实施成功的性能测试最重要的方面可能就在于组织方面。IT 组织，例如以“性能专家中心”的形式，负责支持部门内有关系统性能的设计、开发、测试和维护实践的变更。这需要实施满足整个部门或项目特定需求的工具和方法，帮助定义和管理性能要求。

在 DevOps 中，性能测试应该能够支持 Sprint 中的工作流程，以及与端到端业务流程相关的 Sprint 或团队之间的工作流程。这种性能测试可以通过应用结构化的性能测试方法并提供对工具和专业知识的便捷访问来完成。

性能测试的技术

性能测试的技术方面必须回答时间性能、资源利用率和最大容量等问题。具体的技术实现取决于可用的工具和基础设施。这些工具的技术实现是通过加载模型、迭代模型和性能指标计划来管理的：

• 加载模型：在逻辑上描述如何加载测试目标（用户配置文件）以及如何测量时间性能。它由性能要求、测试目标的描述和要生成的负载水平组成。
• 迭代模型：在技术层面描述了如何加载测试目标以及如何测量系统容量。
• 性能指标计划：指示测试环境的哪些部分作为测试执行的一部分进行监控，并定义所有性能指标的报告结构。

性能测试实施的组织和技术方面的详细描述会在下面进行介绍。

性能测试的类型

确保正确的性能水平，需要在不同的测试类型中进行。不同类型的性能测试在使用的工具类型、所需的技能集以及最重要的是测试和分析的深度方面存在很大差异。

以下部分描述了最重要的性能测试类型：静态和动态，并概述了与 IT 系统性能相关的活动。

围绕性能进行设计

长期以来，性能指标来源于在设计阶段收集的系统需求并扩展这些需求的性能方面。在许多性能测试活动中，这至少能够知道什么样的性能表现是糟糕的。性能设计将重点放在提前将良好的性能表现考虑在内。例如，设计阶段遵循最佳性能实践。

通过分析这些决策的性能后果来决定是否选择如此设计。性能设计将转化为一组性能需求，稍后将用于验证这些设计选择。

必要时，性能测试专家会参与设计，并使最终的性能要求符合 SMART 原则。

性能测试活动和可交付成果：

（Initial）加载模型：

• 性能要求：在性能方面进行 SMART 产品风险分析，而不是笼统使用“性能是高优先级”的声明
• 测试对象：在一个或多个点击路径或工作流中描述设计的测试对象，这也将允许对某些工作流或测试对象的部分进行性能测试优先级的排序
• 负载水平：获得预期使用水平的估计

（Initial）迭代模型：为了能够应对实际负载水平，必须在从数据库到安全的所有方面进行设计。迭代计划将预期负载的到达方式逐步变为最佳，然后使用性能测试工具模拟该负载

（Initial）性能指标计划：根据负载模型和迭代模型所要求的测量结果梳理性能指标，初始计划规定了要监控的特定组件，以验证规定的要求

围绕性能进行开发

在技术层面上，项目应该在组件（单元测试）和系统（集成测试）层面上考察性能。这意味着在设计和开发中使用基于特定平台的最佳实践。从基于ERP的系统到门户或移动解决方案都有不同的设计选择和性能影响，没有一种万能的解决方案。

需要留意跟上新版本的开发框架以及验证由此产生的性能影响。这种“围绕性能进行开发”的方法将在单元或集成测试期间测试那些特定组件的性能。

性能测试活动和可交付成果：

（Working）加载模型：提供评估开发方法的要求和指标，以及特定的测试脚本
（Working）迭代模型：设计和开发选择产生的特定技术需求可能需要特定平台的工具和培训
（Working）性能指标计划：为了在开发环境中运行，对尚不可用的系统组件设计 Stubs 或者 Mocks 进行模拟

性能测试

除了在开发过程中进行组件性能测试外，还需要在特定时间进行性能验收测试。由于技术上的挑战，单次性能验收测试有时错误地只对系统执行单一指标的测试。

如果负载和迭代模型针对要测试的最终事务的一部分进行了最终确定，则性能测试可以提早开始。甚至性能测试可以在第一个原型产生前进行。性能测试可以在数据库级别或单个 API 上进行。例如，10,000 名访问者访问网站将对特定 API 产生 2,000 次调用，单独的性能测试脚本可在项目早期执行，并汇总收集性能报告。

随着越来越多的组件甚至完整的端到端业务流程变得可用，性能测试将尽可能在接近生产环境的情况下执行。

执行性能测试时的重要活动：

• 网络流量捕获和回放工具：设计、构建和维护类似生产的测试环境，并使用工具创建性能测试脚本以匹配指定的用户配置文件
• 多加载生成器设置：设计和实施性能测试场景，对加载模型中定义的系统进行生产级别的模拟
• 测试实验室设置：设计和维护一个具有足够容量或灵活性的实验室，以在测试场景中运行多个应用程序，例如网络组件、虚拟机管理等
• 环境监控：运行和维护与生产环境中使用的类似工具，性能测试工具能够与这些监控结果相关联

性能监控

生产环境中进行性能监控有多个目标。主要目标是保护业务流程并提供性能下降的早期预警。这是通过监视整个 IT 基础架构中的可用资源来实现的。这可以通过在生产环境中运行性能测试脚本来支持，以评估用户的性能体验。

运行测试脚本和在生产中监控性能的第二个目标是向早期的性能测试提供反馈。设计的测试仍然是用户行为的准确表示吗？这防止继续使用不再代表实际情况的测试和监视设置。例如，当移动设备产生越来越多的流量时，在所有早期执行的性能测试中，设置了移动设备产生的负载与传统基于 PC 浏览器产生的负载相当。这将导致负载和迭代模型的更新。

如果可以使用其他工具或方法来监控性能，也会对早期测试提供反馈。例如，需要更新性能指标计划，以便在不同性能测试种类上进行结果比较。

性能测试作为 IT 交付生命周期的一部分

每个组织在开发流程、基础架构和测试方法方面都有自己特定挑战和流程。结果是要么执行单个种类的性能测试，要么执行性能测试活动的组合。通过在 IT 交付生命周期中集成性能测试，可以进行许多改进，从而实现更彻底的性能测试：

• 使性能成为衡量工作完成的主要部分。这不仅需要额外关注性能的设计和开发，它还需要测试基础设施和工具，以发挥在 sprint 中性能测试的好处
• 及时安排有关 IT 系统版本端到端的性能测试，以便进行持续性能修复
• 促进从端到端性能测试和生产性能监控到 DevOps 信息流任何部分的反馈循环
• 集成在 CI/CD 管道中的专用（单元/组件）的性能验收测试等

以上提议主要是为组织解锁性能测试的能力。这可以通过专业性能测试团队的专家临时或兼职来帮助其他团队完成。另一方面是为所有团队提供可重用的基础设施和工具设置。这种可重用的基础设施要么是标准 CI/CD 管道的一部分，要么可以提供专用的性能测试管道。

由于运行生产规模的性能测试环境涉及成本层面的考量，因此可能需要专门为性能测试的环境做定制。即使使用可以轻松关闭甚至删除的云服务，对标准管道的更高级别的控制也是有用的。为广泛的性能测试做准备所需要的成本可能比设置标准 CI/CD 管道要高得多。触发此类动作必须是经过深思熟虑的决定，而不是像任何人都可以从标准管道触发性能测试一样。