在开始详细介绍之前,让我们先了解一下什么是性能测试。
●在软件测试当中,除需要考虑软件的逻辑功能问题外,软件还需要解决与网络问题相关的问题。这些问题对于软件的正常运行至关重要。
●当软件的可访问性较差时,多数用户会重复进入或刷新再次进入,导致过长浪费时间,甚至会因为频繁访问导致服务器性能超载。性能测试可以在上线前发现并预警该类问题。
●软件的速度和性能与使用的设备和网络息息相关。因此,评估软件在不同设备和网络条件下的运行情况非常重要。
●一个系统可能在特定数量的用户下运行良好,但当用户数量超过该限制时,其接口访问量可能会发生负载情况。因此,有必要进行性能测试来了解在特定条件下系统的表现。
在软件的功能、业务测试稳定后,再进行性能测试。通过性能测试,可以检验服务器的最大承载程度。并防止在上线后,由于服务器负载原因出现损失
一旦软件的基本功能正常工作,测试团队就需要进行性能测试。并在功能平稳的情况下对每次迭代定期执行性能测试。
软件的性能测试有不同的工具和标准。这里我们要说一个重要的性能指标:“吞吐量”。
性能测试中的吞吐量指的是在特定时间段内软件或网站能够处理的请求数量。它是评估系统容量和性能的关键指标之一。
在性能测试中,吞吐量的测量可以帮助我们了解系统在实际负载下的处理能力。通过模拟多个用户同时发送请求,并记录处理这些请求的数量,我们可以获得吞吐量的度量值。
在开始测试之前,我们需要设定一个切合实际的性能吞吐量目标,这样我们才能得到更准确可靠的结果。
在这里,我们汇总了一些重要因素来确定实际吞吐量:
●预期用户数量和类型:根据软件或网站的预期用户群体和使用情况,确定需要模拟的用户数量和访问时长。
●用户行为:确定用户在软件中执行的操作和请求类型,包括浏览页面、搜索、提交表单等。
●请求方式:考虑用户请求的方式,如使用不同的设备、网络速度和带宽等因素,这些因素会影响系统的响应和处理能力。
●暂停和延迟:在性能测试中,考虑到用户之间的暂停时间和请求之间的延迟,以更真实的模拟实际使用情况。
通过模拟真实的用户负载,并在一段时间内记录处理的请求数量,可以计算出吞吐量。吞吐量通常以每秒事务数(Transactions Per Second TPS)的形式表示。
设置适当的吞吐量目标对于性能测试非常重要。这样可以确保软件能够在预期负载下处理请求,并为用户提供良好的性能和响应时间。
总结:性能测试中的吞吐量是指在特定时间段内软件或网站能够处理的请求数量。它是评估系统容量和性能的重要指标,需要考虑用户数量、行为、请求方式以及暂停和延迟等因素来确定实际吞吐量。
想象一下,有一个名为“尊平快餐”的快餐摊位,他们提供汉堡和薯条给顾客。在这个快餐摊位上,有3名工人,每个工人为一位顾客提供食物的时间是固定的,总共需要5分钟。假设有3名顾客排队等候,摊位的工人会依次为他们提供食物。因此,在5分钟内,“尊平快餐”可以为3名顾客提供食物。
这个例子中,每五分钟三个客户是尊平快餐的最大吞吐量。无论有多少顾客在那里等待食物,摊位在特定时间范围内最多只能处理三个客户。随着越来越多的顾客排队等候,他们只能等待轮到他们,形成一个队列。
同样的概念也适用于Web软件的测试。假设一个Web软件每秒接收100个请求,但它每秒只能处理70个请求,那么剩下的30个请求就必须在队列中等待处理。
在性能测试中,我们通常使用每秒事务数(TPS)或吞吐量来表示系统的性能。吞吐量指的是系统每秒处理的请求数量,也可以称为TPS。通过了解软件的吞吐量,我们可以评估其在特定负载下的性能,并为性能优化提供指导。
综上所述,吞吐量是指系统在特定时间范围内能够处理的请求数量。无论是尊平快餐的例子还是Web软件的测试,吞吐量都是一个关键指标,用于衡量系统的性能和处理能力。
在性能测试中,使用Apache JMeter来评估软件的性能是非常常见的。JMeter提供了强大的功能,可以帮助我们确定软件能够处理的最大并发用户数,并提供图形化的分析结果。
为了记录和分析吞吐量的值,JMeter提供了多种监听器选项,包括摘要报告、聚合报告、聚合图和图形结果等。这些监听器可以帮助我们监测和跟踪系统的吞吐量。
此外,JMeter还提供了一个称为"Constant Throughput Timer"的计时器组件,它允许我们设置每秒事务数(TPS)的值,以模拟不同负载条件下的性能测试。
现在,让我们来看一个使用JMeter进行性能测试的示例。假设我们想要对系统进行一次并发测试,使用100个并发线程,并跟踪吞吐量的值。
在确保我们已经安装了最新版本的JMeter并完成了必要的配置后,我们需要创建一个测试计划。
本次测试中,将定义五个ThreadGroup元素。每个ThreadGroup元素都具有不同的启动时间,分别是0、15、25、35和45。启动时间表示每个线程启动的持续时间。每个ThreadGroup元素中配置了100个用户。如果需要配置更多的用户,就需要增加更多的启动时间。
每个线程组都包含一个HTTP请求器,用于在示例网站上发送请求。
在用例1中,配置了一个ThreadGroup元素,包含100个线程且启动时间为0。
"线程数"字段设置为100,表示同时发送100个用户的请求。同样,还可以配置剩下的4个线程组,将它们的启动时间分别设置为15、25、35和45。为每个线程组命名,如前所述,这些HTTP采样器将发送请求到示例网站的主页。
为了按照适当的顺序运行这些线程组,需要在控制面板中选择"测试计划"并勾选"连续运行线程组"选项。这样可以确保线程组按照指定的顺序运行。
"聚合报告"是一种监听器,用于分析和观察测试结果。要使用此监听器,可以右键单击"测试计划",然后选择"添加"→"监听器"→"汇总报告”。接着点击开始图标来运行测试。
现在,让我们来了解如何从聚合报告中获取吞吐量的结果。
第一个启动时间为0的线程组会立即对服务器施加负载,这会导致相当高的吞吐量,但这种情况并不实用,因此不会显示真实的输出。
第二和第三线程组具有实际范围内的启动时间,因此它们更有可能显示出适当的性能吞吐量和请求加载时间。
线程组4和5的启动时间较长,这意味着它们的吞吐量会降低。
因此,可以根据第二和第三线程组的结果来确定可靠的输出。它们会提供更接近实际场景的性能数据。
部署新版本或进行更改的决策取决于软件能够处理特定吞吐量(每秒事务数)。因此,性能测试计划应该设定一定的吞吐量目标。但我们需要确保这些目标是现实的,并且能够代表实际生产环境中的真实特征。
如果我们使用不切实际的条件来进行测试,那么测试计划将是徒劳的。例如,在之前描述的测试计划中,第一个线程组显示了更高的吞吐量值,但它并没有反映实时环境中的真实场景。因为,使用这种方法,我们无法准确评估软件在处理实际负载时的表现。所以,设定适当的测试条件至关重要。
现在,让我们讨论在测试性能吞吐量时需要考虑的一些要点。
适当的测试设计:测试设计决定生成的吞吐量是否与实际情况相符。在实时场景中,每个请求可能不同,并且可能会触发复杂的流程以获得所需的结果。因此,我们需要根据预期的实时环境来设计测试。
代表真实用户:每个软件用户可能会发出影响系统资源的请求。因此,如果在测试场景中没有代表真实用户的情况,那么服务器的资源使用情况可能显示不准确,从而导致测试无法模拟真实条件。
考虑暂停和延迟:在实际环境中,用户需要思考、获取和处理信息,输入字段中的信息等。但是,在这些暂停期间服务器仍在使用资源。因此,请尝试在测试脚本中模拟这些用户行为。
考虑连接速度:软件的用户可能通过不同的网络速度、不同的运营商使用移动网络进行连接。所以,使用能够代表用户的运营商及网络速度。这样可以更好地模拟实际环境中的网络条件。
尾注:
总结起来,吞吐量是性能测试中的关键指标,表示软件在特定时间段内处理请求的能力。然而,吞吐量仅仅是性能测试的一个方面,还需要考虑延迟和响应时间等指标,并创建逼真的测试场景以实现性能测试目标。