软件性能测试

2020-07-11 23:55:00

跳转至导航跳转至搜索过程，以确定系统在特定工作负载下的响应性和稳定性表现如何。

在软件质量保证中，性能测试通常是为了确定系统在特定工作负载下的响应性和稳定性的表现而执行的测试实践。它还可以用于调查、测量、验证或验证系统的其他质量属性，如可伸缩性、可靠性和资源使用情况。

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

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

压力测试通常用于了解系统中的容量上限。进行这类测试是为了确定系统在极端负载方面的健壮性，并帮助应用程序管理员确定如果当前负载远高于预期的最大值，系统是否会充分发挥作用。

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

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

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

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

隔离测试不是性能测试所独有的，它涉及重复执行导致系统问题的测试。这种测试通常可以隔离和确认故障域。

当Facebook、Google和Wikipedia等全球应用程序通过放置在实际目标大陆(无论是物理机还是云VM)上的负载生成器进行性能测试时，这是一种相对较新的性能测试形式。这些测试通常需要大量的准备和监控才能成功执行。

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

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

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

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

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

负载测试工具很难测量呈现-响应时间，因为它们除了识别网络上没有活动的一段时间外，通常对节点内发生的事情没有概念。要测量呈现响应时间，通常需要将功能测试脚本作为性能测试场景的一部分。许多负载测试工具不提供此功能。

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

然而，性能测试通常不是针对规范执行的；例如，没有人会表示给定用户群的最大可接受响应时间应该是多少。性能测试经常用作性能配置文件调优过程的一部分。我们的想法是找出最薄弱的环节-系统中不可避免地有一部分，如果让它响应得更快，会导致整个系统运行得更快。有时很难确定系统的哪个部分代表这条关键路径，一些测试工具包括(或可以具有提供在服务器(代理)上运行的外接程序)工具，并报告事务时间、数据库访问时间、网络开销和其他服务器监视器，这些可以与原始性能统计信息一起进行分析。如果没有这样的检测，可能需要有人蹲在服务器上的Windows Task Manager上查看性能测试产生了多少CPU负载(假设正在测试Windows系统)。

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

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

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

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

目标系统(硬件)是什么样子(指定所有服务器和网络设备配置)？

每个系统组件的应用程序工作负载组合是多少？(例如：20%登录、40%搜索、30%物品选择、10%结账)。

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

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

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

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

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

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

性能测试的这一部分主要处理创建/编写确定的关键业务流程的工作流。这可以使用各种各样的工具来完成，比如HP LoadRunner、NeoLoad、Apache JMeter、Rational Performance Tester、Silk Performer、Gatling和Flood。

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

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

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

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

性能测试可以与压力测试相结合，以查看超出可接受负载时会发生什么情况。系统会崩溃吗？如果大负荷减少，需要多长时间才能恢复？它的失败是否会造成附带损害？

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

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

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

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

配置测试环境(理想情况下与生产平台完全相同的硬件)、路由器配置、安静的网络(我们不希望结果被其他用户打乱)、服务器工具的部署、开发的数据库测试集等。

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

执行测试-可能会重复(迭代)，以查看是否有任何未考虑的因素可能会影响结果。

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

根据Microsoft开发人员网络，性能测试方法由以下活动组成：

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

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

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

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