软件性能测试定义中文

From Wiki

软件性能测试

在软件质量保证中，性能测试通常是一种测试实践，用于确定系统在特定工作负载下的响应能力和稳定性方面的表现。它还可以用于调查、测量、验证或验证系统的其他质量 属性，例如可扩展性、可靠性和资源使用。

性能测试是性能工程的一个子集，是一种计算机科学实践，它致力于将性能标准构建到系统的实现、设计和体系结构中。

测试类型[编辑]

负载测试[编辑]

负载测试是最简单的性能测试形式。通常进行负载测试以了解系统在特定预期负载下的行为。此负载可以是应用程序在设定持续时间内执行特定数量事务的预期并发用户数。该测试将给出所有重要业务关键事务的响应时间。数据库、应用服务器等也在测试过程中被监控，这将有助于识别应用软件和安装软件的硬件的 瓶颈。

压力测试[编辑]

压力测试通常用于了解系统容量的上限。进行此类测试是为了确定系统在极端负载方面的稳健性，并帮助应用程序管理员确定在当前负载远高于预期最大值的情况下系统是否能够充分执行。

浸泡测试[编辑]

浸泡测试，也称为耐久性测试，通常用于确定系统是否能够承受持续的预期负载。在浸泡测试期间，会监控内存利用率以检测潜在的泄漏。同样重要但经常被忽视的是性能下降，即确保在长时间持续活动后的吞吐量和/或响应时间与测试开始时一样好或更好。它本质上涉及在很长一段时间内对系统施加大量负载。目标是发现系统在持续使用下的行为。

尖峰测试[编辑]

尖峰测试是通过突然增加或减少大量用户产生的负载，并观察系统的行为来完成的。目标是确定性能是否会受到影响，系统是否会失败，或者它是否能够处理负载的急剧变化。

断点测试[编辑]

断点测试类似于压力测试。随着时间的推移应用增量负载，同时监视系统的预定故障条件。断点测试有时被称为容量测试，因为它可以确定最大容量，低于该容量系统将执行其所需的规范或服务水平协议。应用于固定环境的断点分析结果可用于根据所需硬件或应在云环境中触发扩展事件的条件来确定最佳扩展策略。

配置测试[编辑]

不是从负载角度测试性能，而是创建测试以确定系统组件的配置更改对系统性能和行为的影响。一个常见的例子是尝试不同的负载平衡方法。

隔离测试[编辑]

隔离测试并非性能测试所独有，而是涉及重复导致系统问题的测试执行。这样的测试往往可以隔离和确认故障域。

互联网测试[编辑]

这是一种相对较新的性能测试形式，当全球应用程序（例如 Facebook、Google 和维基百科）从放置在实际目标大陆上的负载生成器（无论是物理机器还是云虚拟机）进行性能测试时。这些测试通常需要大量的准备和监控才能成功执行。

设定绩效目标[编辑]

性能测试可以用于不同的目的：

• 它可以证明系统满足性能标准。

• 它可以比较两个系统以找出哪个性能更好。

• 它可以衡量系统或工作负载的哪些部分导致系统性能不佳。

许多性能测试是在没有设置足够现实的、面向目标的性能目标的情况下进行的。从业务角度来看，第一个问题应该始终是“我们为什么要进行性能测试？”。这些注意事项是测试业务案例的一部分。性能目标将根据系统的技术和目的而有所不同，但应始终包括以下一些内容：

并发性和吞吐量[编辑]

如果系统通过某种形式的登录过程识别最终用户，那么并发目标是非常可取的。根据定义，这是系统预期在任何给定时刻支持的最大并发系统用户数。脚本事务的工作流可能会影响真正的并发性，尤其是当迭代部分包含登录和注销活动时。

如果系统没有终端用户的概念，那么性能目标很可能基于最大吞吐量或事务率。

服务器响应时间[编辑]

这是指一个系统节点响应另一个系统节点的请求所花费的时间。一个简单的示例是从浏览器客户端到 Web 服务器的 HTTP“GET”请求。就响应时间而言，这是所有负载测试工具实际测量的。在系统的所有节点之间设置服务器响应时间目标可能是相关的。

渲染响应时间[编辑]

负载测试工具很难测量渲染响应时间，因为除了识别“线上”没有活动的时间段之外，它们通常对节点内发生的事情一无所知。要测量渲染响应时间，通常需要将功能测试脚本作为性能测试场景的一部分。许多负载测试工具不提供此功能。

性能规格[编辑]

详细说明性能规范（要求）并将其记录在任何性能测试计划中至关重要。理想情况下，这是在任何系统开发项目的需求开发阶段，在任何设计工作之前完成的。有关详细信息， 请参阅性能工程。

但是，性能测试通常不是针对规范执行的；例如，没有人会表达给定用户群的最大可接受响应时间应该是多少。性能测试经常用作性能配置文件调整过程的一部分。这个想法是为了确定“最薄弱的环节”——系统中不可避免地会有一部分，如果让它响应得更快，就会导致整个系统运行得更快。识别系统的哪一部分代表这条关键路径有时是一项艰巨的任务，一些测试工具包括（或可以具有提供的附加组件）在服务器（代理）上运行并报告事务时间、数据库访问时间的工具、网络开销和其他服务器监视器，可以将其与原始性能统计数据一起进行分析。服务器上的 Windows 任务管理器，以查看性能测试产生了多少 CPU 负载（假设正在测试 Windows 系统）。

性能测试可以在网络上进行，甚至可以在全国不同地区进行，因为众所周知，互联网本身的响应时间因地区而异。它也可以在内部完成，尽管随后需要配置路由器以引入通常会在公共网络上出现的延迟。负载应该从实际点引入系统。例如，如果系统用户群的 50% 将通过 56K 调制解调器连接访问系统，而另一半通过 T1 访问系统，则负载注入器（模拟真实用户的计算机）应该通过相同的连接组合注入负载（理想）或模拟此类连接的网络延迟，遵循相同的用户配置文件。

对预计在高峰时间使用系统的可能峰值用户数进行说明总是很有帮助的。如果还可以说明什么构成了最大允许的 95% 响应时间，则可以使用喷油器配置来测试所提议的系统是否满足该规范。

要问的问题[编辑]

性能规范至少应询问以下问题：

• 具体来说，性能测试的范围是什么？哪些子系统、接口、组件等在本次测试范围之内和之外？

• 对于所涉及的用户界面 (UI)，每个界面预计有多少并发用户（指定峰值与标称值）？

• 目标系统（硬件）是什么样的（指定所有服务器和网络设备配置）？

• 每个系统组件的应用程序工作负载组合是什么？（例如：20% 登录、40% 搜索、30% 项目选择、10% 结帐）。

• 什么是系统工作负载组合？[可以在单个性能测试中模拟多个工作负载]（例如：30% 工作负载 A、20% 工作负载 B、50% 工作负载 C）。

• 任何/所有后端批处理过程的时间要求是多少（指定峰值与标称值）？

先决条件[编辑]

系统的稳定构建必须尽可能接近生产环境。

为确保一致的结果，性能测试环境应与其他环境隔离，例如用户验收测试(UAT) 或开发。作为最佳实践，始终建议拥有一个尽可能类似于生产环境的独立性能测试环境。

测试条件[编辑]

在性能测试中，测试条件与预期的实际使用情况相似往往是至关重要的。然而，在实践中这很难安排而且也不完全可能，因为生产系统会承受不可预测的工作负载。测试工作负载可能会尽可能模仿生产环境中发生的情况，但只有在最简单的系统中才能准确复制这种工作负载变化。

松散耦合的架构实现（例如：SOA）为性能测试带来了额外的复杂性。要真正复制类似生产的状态，共享公共基础设施或平台的企业服务或资产需要协调性能测试，所有消费者都在共享基础设施或平台上创建类似生产的交易量和负载。由于此活动非常复杂且耗费金钱和时间，一些组织现在使用工具在其性能测试环境 ( PTE ) 中监控和模拟类似生产的条件（也称为“噪声”），以了解容量和资源需求并验证/ 验证质量属性。

时间[编辑]

性能测试工作从开发项目开始并延伸到部署对于新系统的成本性能至关重要。检测到性能缺陷越晚，补救成本就越高。这在功能测试的情况下是正确的，但由于其范围的端到端性质，性能测试更是如此。性能测试团队尽早参与至关重要，因为获取和准备测试环境和其他关键性能要求非常耗时。

工具[编辑]

性能测试主要分为两大类：

性能脚本[编辑]

这部分性能测试主要涉及创建/编写关键识别业务流程的工作流脚本。这可以使用多种工具来完成。

上面列表中提到的每个工具（既不详尽也不完整）都采用脚本语言（C、Java、JS）或某种形式的可视化表示（拖放）来创建和模拟最终用户工作流程。大多数工具都允许进行称为“记录和重播”的操作，性能测试人员将在其中启动测试工具，将其挂接到浏览器或胖客户端，并捕获客户端和服务器之间发生的所有网络事务。在这样做的过程中，开发了一个脚本，可以对其进行增强/修改以模拟各种业务场景。

性能监控[编辑]

这构成了性能测试的另一面。通过性能监控，可以观察被测应用程序的行为和响应特征。在性能测试执行期间通常会监视以下参数

服务器硬件参数

• CPU利用率

• 内存利用率

• 磁盘利用率

• 网络利用率

作为第一步，这 4 个参数生成的模式很好地指示了瓶颈所在。为了确定问题的确切根本原因，软件工程师使用分析器等工具来衡量设备或软件的哪些部分对性能不佳的影响最大，或者建立吞吐量水平（和阈值）以维持可接受的响应时间。

技术[编辑]

性能测试技术使用一个或多个 PC 或 Unix 服务器充当注入器，每个模拟大量用户的存在，并且每个都运行自动化的交互序列（记录为脚本，或作为一系列脚本来模拟不同类型的用户交互）与正在测试其性能的主机。通常，单独的 PC 充当测试指挥，协调和收集来自每个喷油器的指标，并整理性能数据以用于报告目的。通常的顺序是增加负载：从几个虚拟用户开始，然后随着时间的推移将数量增加到预定的最大值。测试结果显示了性能如何随负载变化，以用户数量与响应时间的关系给出。有多种工具可用于执行此类测试。此类工具通常执行一套测试，模拟真实用户对系统的测试。有时结果可能会出现异常，例如，虽然平均响应时间可能是可以接受的，但一些关键事务的异常值需要相当长的时间才能完成——这可能是由低效的数据库查询、图片等引起的。

性能测试可以与压力测试相结合，以了解当超过可接受的负载时会发生什么。系统会崩溃吗？如果减少一个大的负载，需要多长时间才能恢复？它的失败会造成附带损害吗？

分析性能建模是一种在电子表格中对系统行为进行建模的方法。该模型包含事务资源需求的测量值（CPU、磁盘 I/O、LAN、WAN)，按交易组合（每小时业务交易）加权。将加权的事务资源需求相加得到每小时的资源需求，除以每小时的资源容量得到资源负荷。使用响应时间公式（R=S/(1-U)，R=响应时间，S=服务时间，U=负载），可以根据性能测试的结果计算和校准响应时间。分析性能建模允许根据实际或预期的业务用途评估设计选项和系统规模。因此，它比性能测试更快、更便宜，尽管它需要对硬件平台有透彻的了解。

承担的任务[编辑]

执行此类测试的任务包括：

• 根据内部专业知识（或缺乏），决定是使用内部资源还是外部资源来执行测试。

• 从用户和/或业务分析师那里收集或引出性能要求（规范）。

• 制定高级计划（或项目章程），包括要求、资源、时间表和里程碑。

• 制定详细的性能测试计划（包括详细的场景和测试用例、工作负载、环境信息等）。

• 选择测试工具。

• 指定所需的测试数据和包机工作（经常被忽视，但对于执行有效的性能测试至关重要）。

• 使用选定的测试工具和策略，为每个被测应用程序/组件开发概念验证脚本。

• 制定详细的性能测试项目计划，包括所有依赖项和相关时间表。

• 安装和配置喷射器/控制器。

• 配置测试环境（最好是与生产平台相同的硬件）、路由器配置、安静的网络（我们不希望其他用户打乱结果）、部署服务器工具、开发数据库测试集等。

• 试运行测试 - 在实际执行预定义用户的负载测试之前，进行试运行以检查脚本的正确性。

• 执行测试——可能重复（迭代）以查看是否有任何未说明的因素可能影响结果。

• 分析结果 - 通过/失败，或关键路径调查和纠正措施建议。

方法论[编辑]

性能测试 Web 应用程序[编辑]

根据 Microsoft Developer Network，性能测试方法论包括以下活动：

1. 确定测试环境。确定物理测试环境和生产环境以及测试团队可用的工具和资源。物理环境包括硬件、软件和网络配置。从一开始就透彻了解整个测试环境可以提高测试设计和规划的效率，并帮助您在项目早期识别测试挑战。在某些情况下，必须在整个项目生命周期中定期重新审视此过程。

2. 确定性能验收标准。确定响应时间、吞吐量和资源使用目标和约束。一般来说，响应时间是用户关心的，吞吐量是业务关心的，资源使用是系统关心的。此外，确定那些目标和约束可能无法捕获的项目成功标准；例如，使用性能测试来评估哪种配置设置组合将产生最理想的性能特征。

3. 计划和设计测试。确定关键场景、确定代表性用户之间的可变性以及如何模拟该可变性、定义测试数据并建立要收集的指标。将此信息整合到一个或多个系统使用模型中，以便实施、执行和分析。

4. 配置测试环境。当功能和组件可用于测试时，准备执行每个策略所需的测试环境、工具和资源。确保在必要时对测试环境进行资源监控。

5. 实施测试设计。根据测试设计开发性能测试。

6. 执行测试。运行并监控您的测试。验证测试、测试数据和结果收集。执行经过验证的测试以进行分析，同时监视测试和测试环境。

7. 分析结果、调整和重新测试。分析、合并和共享结果数据。进行调整更改并重新测试。比较两个测试的结果。所做的每项改进都会返回比先前改进更小的改进。你什么时候停下来？当您遇到 CPU 瓶颈时，您的选择是改进代码或添加更多 CPU。