性能测试

在本节中，我们将学习性能测试、为什么我们需要它、性能测试的类型以及性能测试过程。

以下是我们将在此部分理解的主题：

什么是性能测试？

它是非功能测试中最重要的部分。

通过施加一定的负载来检查应用程序的行为被称为性能测试。

通常，这种测试定义了服务器响应用户请求的速度。

在对应用程序进行性能测试时，我们将关注应用程序的响应时间、负载和稳定性等各种因素。

响应时间：响应时间是服务器响应客户端请求所需的时间。

负载：此处，负载表示当 N 个用户同时使用应用程序或同时向服务器发送请求时。

稳定性：对于稳定性因素，我们可以说当 N 个用户同时使用应用程序一段时间。

我们何时使用性能测试？

一旦软件稳定并投入生产，并且可能被多个用户同时访问，我们就会进行性能测试。由于这个原因，可能会出现一些性能问题。为了避免这些性能问题，测试人员会进行一轮性能测试。

由于它是非功能测试，这并不意味着我们总是使用性能测试，我们只在应用程序功能稳定时才进行性能测试。

注意：性能测试不能手动进行，因为它成本高昂且无法保持结果的准确性。

性能测试的类型

以下是性能测试的类型：

• 负载测试
• 压力测试
• 可伸缩性测试
• 稳定性测试

让我们逐一讨论，以便您全面了解负载、压力、可伸缩性和稳定性性能测试。

负载测试

负载测试用于通过施加小于或等于期望负载的负载来检查应用程序的性能，这被称为负载测试。

例如：在下图中，1000 个用户是客户给出的期望负载，而 3/秒是我们执行负载测试时想要达到的目标。

压力测试

压力测试是一种通过施加大于期望负载的负载来检查应用程序行为的测试。

例如：如果我们以上述例子为例，并将期望负载从 1000 增加到 1100 个用户，目标是 4/秒。在这种情况下执行压力测试，它将通过，因为负载（增加 100）大于实际期望负载。

可伸缩性测试

通过在特定规模（用户数量）上增加或减少负载来检查应用程序的性能被称为可伸缩性测试。向上可伸缩性测试和向下可伸缩性测试统称为可伸缩性测试。

可伸缩性测试分为两部分，如下：

• 向上可伸缩性测试
• 向下可伸缩性测试

向上可伸缩性测试

这是一种测试，我们在特定规模上增加用户数量，直到达到崩溃点。我们将使用向上可伸缩性测试来找到应用程序的最大容量。

向下可伸缩性测试

当负载测试未通过时，使用向下可伸缩性测试，然后开始以特定间隔减少用户数量，直到达到目标。这样可以很容易地识别瓶颈（bug）。

稳定性测试

通过施加特定持续时间的负载来检查应用程序的性能被称为稳定性测试。

性能测试示例

让我们举一个例子，我们将测试应用程序的行为，其中期望负载小于 1000 或等于 1000 个用户。

在下图中，我们可以看到100 个以上的用户持续增加，以检查最大负载，这也称为向上可伸缩性测试。

• 场景1：当我们将 1000 个用户作为期望负载，并且目标时间为 2.7 秒时，这些场景在执行负载测试时将通过，因为在负载测试中，我们将关注用户数量，根据要求，它等于 1000 个用户。
• 场景2：在下一个场景中，我们将期望负载增加 100 个用户，目标时间将达到 3.5 秒。如果我们执行压力测试，这个场景将通过，因为这里的实际负载（1100）大于期望负载（1000）。
• 场景3：在这种情况下，如果我们将期望负载增加三倍，例如：
  1200 → 3.5 秒：[它不小于或等于期望负载，因此将失败]
  1300 → 4 秒：[它不小于或等于期望负载，即失败]
  1400 → 崩溃

注1：容量测试和浸泡测试是一种测试类型，但不是性能测试。

容量测试

容量测试是一种测试，它通过插入大量数据负载来帮助我们检查应用程序的行为，这被称为容量测试。在这里，我们将关注数据速率的数量而不是用户数量。

注意事项2
容量是容量，而负载是数量，即负载测试表示用户数量，容量测试表示数据量。

浸泡测试

在这种类型的测试中，我们将检查应用程序在长时间不受支持的环境中的行为，这被称为浸泡测试。

通常，浸泡测试是一种消极类型的测试，因为我们已经知道服务器或环境不支持。

性能测试过程

性能测试不能手动完成，因为

• 我们需要大量的资源，这将成为一种昂贵的方法。
• 而且手动跟踪响应时间无法保持准确性。

性能测试过程将通过以下步骤完成：

• 识别性能场景
• 规划和设计性能测试脚本
• 配置测试环境并分配负载
• 执行测试脚本
• 结果
• 分析结果
• 识别瓶颈
• 重新运行测试

如果我们执行性能测试过程的正向流程，它将遵循以下过程：

识别性能场景

首先，我们将根据以下因素识别性能场景：

最常见的场景：这意味着我们可以根据常用的场景找到性能场景，例如在 Gmail 应用程序中，我们将执行登录、收件箱、发送项、撰写邮件和注销。

最关键的场景：关键场景意味着经常使用且对业务重要的场景，例如 Gmail 应用程序中的登录、撰写、收件箱和注销。

大量数据事务：如果我们有大量数据，意味着 n 个用户同时使用应用程序。

一旦我们识别了性能场景，我们将进入下一步。

规划和设计性能测试脚本

在此步骤中，我们将在测试工程师机器中安装工具并访问测试服务器，然后我们根据测试场景编写一些脚本并运行工具。

一旦我们完成了脚本编写，我们将进入下一步。

配置测试环境并分配负载

编写测试脚本后，我们将在执行前布置测试环境。并且还要管理工具、其他资源并根据“使用模式”分配负载，或提及持续时间和稳定性。

执行测试脚本

一旦我们完成了负载分配，我们将执行、验证和监控测试脚本。

结果

执行测试脚本后，我们将得到测试结果。并检查结果是否在给定响应时间内达到目标，响应时间可以是最大、平均和最小。

如果响应未达到所需的时间响应，那么我们将进入负向流程，其中将执行以下步骤：

分析结果

首先，我们将分析测试结果是否符合响应时间。

识别瓶颈

之后，我们将识别瓶颈（bug 或性能问题）。瓶颈可能由于以下方面而发生，例如代码问题、硬件问题（硬盘、RAM 处理器）、网络问题和软件问题（操作系统）。找到瓶颈后，我们将执行调整（修复或调整）以解决此瓶颈。

重新运行测试

一旦我们修复了瓶颈，重新运行测试脚本并检查结果是否达到所需目标。

性能测试中出现的问题

在对应用程序执行性能测试时，可能会出现一些问题，这些问题也称为性能问题。

性能问题如下：

• 响应时间问题
• 可伸缩性问题
• 瓶颈
• 速度问题

响应时间问题

响应时间是指服务器响应客户端请求的速度。如果用户的请求未在给定响应时间内完成，则用户可能会对特定软件或应用程序失去兴趣。这就是为什么应用程序或软件应该有完美的响应时间，以快速响应用户请求。

可伸缩性问题

当应用程序无法同时接受 n 个用户和预期的用户请求时，就会出现可伸缩性问题。这就是为什么我们要进行向上可伸缩性测试（检查应用程序的最大容量）和向下可伸缩性测试（当预期时间与实际时间不匹配时）。

瓶颈

瓶颈是 bug 的非正式名称，当应用程序受单个组件限制并对系统性能产生不良影响时发生。

导致瓶颈的主要原因是软件问题（与操作系统相关的问题）、硬件问题（与硬盘、RAM 和处理器相关的问题）和编码问题等。

以下是最常见的性能瓶颈：

• 内存利用
• 磁盘使用率
• CPU 利用率
• 操作系统限制
• 网络利用率

速度问题

当我们在应用程序上执行性能测试时，应用程序的速度应该更快，以吸引用户的兴趣和注意力，因为如果应用程序的速度慢，它可能会让用户失去对应用程序的兴趣。

性能测试工具

市场上有各种类型的性能测试工具，其中一些是商业工具和开源工具。

商业工具：LoadRunner[HP]、WebLOAD、NeoLoad

开源工具：JMeter

LoadRunner

它是性能测试中最强大的工具之一，用于支持各种协议、技术和应用程序环境的性能测试。

它能快速识别性能问题最常见的原因。并准确预测应用程序的可伸缩性和容量。

JMeter

Apache JMeter 软件是一款开源工具，完全是一款 Java 应用程序，旨在加载功能测试行为并测量性能。

通常，它最初是为测试 Web 应用程序而设计的，但现在也扩展到其他测试功能。

Apache JMeter 用于测试静态和动态资源以及动态 Web 应用程序的性能。
它可用于在服务器、网络或对象、服务器组上重现高负载，以测试其强度或分析不同负载类型下的整体性能。

WebLOAD

WebLOAD 测试工具用于测试 Web 应用程序的负载测试、性能测试和压力测试。

WebLOAD 工具将性能、可伸缩性和完整性结合在一个流程中，用于验证 Web 和移动应用程序。

NeoLoad

Neotys 开发了一款名为 NeoLoad 的测试工具。NeoLoad 用于测试性能测试场景。借助 NeoLoad，我们可以找到 Web 和移动应用程序开发过程中的瓶颈区域。

NeoLoad 测试工具比传统工具更快。

除此之外，还有一些其他工具，如 Electric load、web stress tool、LoadUI Pro、StresStimulus、LoadView、LoadNinja 和 RedLine13，它们有助于测试软件或应用程序的性能。