性能测试 系统测试 可用性测试 性能测试 在本节中，我们将了解性能测试、我们为什么需要它、性能测试的类型以及性能测试过程。 以下是我们将在本节中了解的主题： 什么是性能测试？ 它是非功能测试中最重要的部分。 通过施加一些负载来检查应用程序的行为称为性能测试。 通常，此测试定义服务器响应用户请求的速度。 在对应用程序进行性能测试时，我们将重点关注应用程序的响应时间、负载和稳定性等各种因素。 响应时间：响应时间是服务器响应客户端请求所花费的时间。 负载：这里，负载是指当N个用户同时使用应用程序或一次向服务器发送请求时。 稳定性：对于稳定性因素，我们可以说，当 N 个用户在特定时间内同时使用应用程序时。 我们什么时候使用性能测试？ 一旦软件稳定并移至生产环境，我们将进行性能测试，并且可能会被多个用户同时访问，因此可能会出现一些性能问题。为了避免这些性能问题，测试人员执行一轮性能测试。 由于它是非功能测试，并不意味着我们总是使用性能测试，我们只在应用程序功能稳定时才进行性能测试。 注意：性能测试无法手动完成，因为无法维护其成本高昂且准确的结果。 性能测试的类型 以下是性能测试的类型： 负载测试 压力测试 可扩展性测试 稳定性测试 让我们一一讨论，让您全面了解负载、压力、可扩展性和稳定性性能测试。 负载测试 负载测试用于通过施加一些小于或等于所需负载的负载来检查应用程序的性能，称为负载测试。 例如：在下图中，1000 个用户是客户给定的期望负载，3/秒是我们在执行负载测试时想要达到的目标。 压力测试 压力测试是测试，它通过施加大于所需负载的负载来检查应用程序的行为。 例如：如果我们以上面的例子为例，将期望的负载增加到 1000 到 1100 个用户，目标是 4/秒。在此场景中执行压力测试时，它会通过，因为负载大于（100 向上）实际所需负载。 可扩展性测试 通过增加或减少特定规模（没有用户）的负载来检查应用程序的性能被称为可扩展性测试。向上可扩展性和向下可扩展性测试称为可扩展性测试。 可扩展性测试分为以下两部分： 向上可扩展性测试 向下扩展性测试 向上可扩展性测试 它正在测试我们在特定规模上增加用户数量的位置，直到我们获得崩溃点。我们将使用向上可扩展性测试来找到应用程序的最大容量。 向下扩展性测试 当负载测试未通过时使用向下可扩展性测试，然后开始减少 no。在特定时间间隔内的用户数量，直到实现目标。以便于识别瓶颈（bug）。 稳定性测试 通过在特定时间段内施加负载来检查应用程序的性能称为稳定性测试。 性能测试示例 让我们举一个例子，我们将测试一个应用程序的行为，其中所需负载小于 1000 或等于 1000 个用户。 在下图中，我们可以看到不断增加100 个 up用户以检查最大负载，这也称为向上扩展性测试。 场景 1：当我们有 1000 个用户作为所需的负载，并且 2.7/sec 是目标时间时，这些场景将在执行负载测试时通过，因为在负载测试中，我们将专注于没有。用户，根据要求，它等于 1000 个用户。 场景 2：在下一个场景中，我们将所需的负载增加 100 个用户，目标时间将上升到 3.5\sec。如果我们执行压力测试，这种情况就会通过，因为在这里，实际负载大于 (1100) 所需负载 (1000)。 场景3：在这种情况下，如果我们将所需负载增加三倍 1200 → 3.5\sec: [它不小于或等于所需负载，这就是它失败的原因] 1300 → 4\sec: [它不小于或等于所需的负载。即，失败] 1400 → 崩溃 注1：体积和浸泡测试是一种测试，但不是性能测试。 体积测试 卷测试是测试，它通过插入大量负载数据来帮助我们检查应用程序的行为被称为卷测试，在这里，我们将专注于数据速率的数量而不是用户数量. 注2： Volume 是容量，Load 是数量，即负载测试表示没有。用户数量，容量测试意味着数据量。 浸泡测试 在这种类型的测试中，我们将检查应用程序在环境中的行为，这种行为在很长一段时间内是不支持的，称为浸泡测试。 通常，浸泡测试是一种负面测试，因为我们已经知道服务器或环境不支持。 性能测试流程 性能测试不能手动完成，因为： 我们需要大量资源，这成为一种成本更高的方法。 当我们手动跟踪响应时间时，精度无法保持。 性能测试过程将通过以下步骤完成： 确定性能场景 规划和设计性能测试脚本 配置测试环境并分配负载 执行测试脚本 结果 分析结果 识别瓶颈 重新运行测试 如果我们执行性能测试流程的积极流程，则可以遵循以下流程： 确定性能场景 首先，我们将根据以下因素确定性能场景： 最常用的场景：是指我们可以根据场景找到性能场景，比如Gmail应用中常用的；我们将执行登录、收件箱、发送项目、撰写邮件和注销。 最关键场景：关键场景是指在 Gmail 应用程序登录、撰写、收件箱和注销中经常使用和重要的业务。 海量数据交易：如果我们有海量数据意味着同时使用应用程序的用户数为 n。 一旦我们确定了性能场景，我们将进入下一步。 规划和设计性能测试脚本 在这一步中，我们将在测试工程师机器中安装工具并访问测试服务器，然后我们根据测试场景编写一些脚本并运行该工具。 一旦我们完成了脚本的编写，我们将进入下一步。 配置测试环境并分配负载 写好测试脚本后，我们会在执行前安排好测试环境。并且，根据“使用模式”或提及持续时间和稳定性来管理工具、其他资源和分配负载。 执行测试脚本 完成负载分配后，我们将执行、验证和监控测试脚本。 结果 执行测试脚本后，我们将得到测试结果。并检查在给定的响应时间内结果是否达到目标，响应时间可以是最大值、平均值和最小值。 如果响应没有满足所需的时间响应，那么我们将转向负流，在那里将执行以下步骤： 分析结果 首先，我们将分析测试结果是否符合响应时间。 识别瓶颈 之后，我们将确定瓶颈（错误或性能问题）。由于代码问题、硬件问题（硬盘、RAM 处理器）、网络问题和软件问题（操作系统）等方面的问题，可能会出现瓶颈。找到瓶颈后，我们将执行调优（修复或调整）以解决此瓶颈。 重新运行测试 一旦我们解决了瓶颈，重新运行测试脚本并检查结果是否满足要求的目标。 性能测试出现问题 在对应用程序进行性能测试时，可能会出现一些问题，这些问题也称为性能问题。 性能问题如下： 响应时间问题 可扩展性问题 瓶颈 速度问题 响应时间问题 响应时间是指服务器响应客户端请求的速度。如果用户的请求没有在给定的响应时间内完成，则用户可能会失去对特定软件或应用程序的兴趣。这就是为什么应用程序或软件应该有一个完美的响应时间来快速响应用户的请求。 可扩展性问题 当应用程序无法同时处理 n 个用户和预期的用户请求时，就会出现可伸缩性问题。这就是为什么我们会进行向上扩展测试（检查应用程序的最大容量）和向下扩展测试（当预期时间与实际时间不匹配时）。 Bottleneck 瓶颈是错误的非正式名称，当应用程序受到单个组件的限制并对系统性能产生不良影响时就会发生这种情况。 造成瓶颈的主要原因是软件问题（与操作系统相关的问题）、硬件问题（与硬盘、内存和处理器相关的问题）和编码问题等。 以下是最常见的性能瓶颈： 内存利用率 磁盘使用情况 CPU利用率 操作系统限制 网络利用率 速度问题 当我们对应用程序进行性能测试时，应用程序应该以更快的速度来获得用户的兴趣和关注，因为如果应用程序速度太慢，可能会失去用户对应用程序的兴趣。 性能测试工具 我们在市场上有各种类型的性能测试工具，其中一些是商业工具和开源工具。 商业工具：LoadRunner[HP]、WebLOAD、NeoLoad 开源工具：JMeter 加载程序 它是最强大的性能测试工具之一，用于支持广泛的协议、技术和应用环境的性能测试。 它可以快速确定性能问题的最常见原因。并且还准确预测应用程序的可扩展性和容量。 JMeter Apache JMeter 软件是一个开源工具，它完全是一个 Java 应用程序，旨在加载功能测试行为并测量性能。 通常，它是为测试 Web 应用程序而设计的，但现在也扩展到其他测试功能。 Apache JMeter 用于测试静态和动态资源以及动态 Web 应用程序的性能。 它可用于重现服务器、网络或对象、服务器组上的重负载，以测试其强度或分析不同负载类型下的整体性能。 WebLOAD WebLOAD 测试工具用于测试Web 应用程序的负载测试、性能测试和压力测试。 WebLOAD 工具将性能、可扩展性和完整性结合为一个验证 Web 和移动应用程序的过程。 Neotys Neotys 开发了一个名为 NeoLoad 的测试工具。NeoLoad 用于测试性能测试场景。借助 NeoLoad，我们可以找到 Web 和移动应用程序开发过程中的瓶颈区域。 与传统工具相比，NeoLoad 测试工具速度更快。 除此之外，还有其他一些工具有Electric load、web 压力工具、LoadUI Pro、StresStimulus、LoadView、LoadNinja 和 RedLine13，它们有助于测试软件或应用程序的性能。 系统测试 可用性测试
