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