性能测试中的吞吐量：为什么它很重要

软件测试人员采用多种技术来检查应用程序的质量。性能测试是团队测试软件的速度、响应时间、可扩展性和可靠性的决定性措施之一。

在本文中，我们将讨论性能测试中吞吐量的核心问题。

性能测试中吞吐量的基础知识

在开始详细介绍之前，让我们先了解一下性能测试的一些要点。

为什么要进行性能测试？

性能测试很重要，因为：

• 除了常见的逻辑或功能问题之外，应用程序还面临着决定其可靠性的网络问题。

• 当应用程序可访问性体验不好时，客户很容易感到沮丧。

• 应用程序速度和性能根据使用区域的不同而变化。因此判断应用程序在不同速度和网络下的性能非常重要。

• 系统可以与特定数量的用户完美配合，但当用户数量超过该限制时，系统的行为可能会有所不同。因此，检查特定条件下的性能测试基础知识是必要的。

您应该什么时候开始性能测试？

您可以在软件应用程序的开发阶段尽早开始性能测试。通过这种方式，您可以优化您的网络服务器并防止后期的业务成本。

在部署应用程序后发现性能问题意味着需要花费大量的工作时间来纠正问题。所以它可能非常昂贵。

一旦应用程序的基本网页开始工作，质量保证团队就必须进行初始负载测试。从那时起，他们应该定期为每个构建执行性能测试。

应用程序性能测试有不同的工具和标准。这里我们要讲一个重要的衡量标准，即吞吐量。

什么是性能测试中的吞吐量？

每个软件应用程序或网站都有大量执行不同请求的用户。测试人员需要确保应用程序在上线之前满足所需的请求容量。

在此过程中需要测量一些性能测试基础知识。吞吐量就是其中之一。我们先来了解一下性能测试中什么是吞吐量。

吞吐量是一个关键指标，显示软件应用程序在特定时间（秒、分钟或小时）内可以处理的请求数量。

在开始测试之前，我们需要设定一个现实的性能吞吐量目标，这样我们才能得到更精确、更可靠的结果。

以下是确定实际吞吐量的一些重要因素：

• 将使用应用程序或网站的用户的估计数量和类型。

• 用户行为，即他们将使用应用程序执行哪些操作。

• 连接类型将影响系统的响应并最终影响用户体验。

• 暂停和延迟对系统的影响。

现实场景中的吞吐量

在这里，我们将通过一个现实例子来解释吞吐量的概念。想象一下有一个名为“美味汉堡”的快餐摊。他们为顾客提供汉堡和薯条。

假设“Yummy Burgers”摊位上有 3 名工作人员，每名工作人员总是需要 5 分钟才能将食物提供给一位顾客。

因此，如果他们有 3 位顾客排队，由 3 名工作人员服务，这意味着“Yummy Burgers”可以在 5 分钟内为 3 位顾客提供食物。

因此，如果我们需要制作“Yummy Burgers”的性能报告，则会显示其吞吐量为每五分钟三个顾客。

Yummy Burgers 面临的困境是，无论有多少顾客在外面等待食物，他们在特定时间范围内可以处理的最大数量总是相同的，即三个。这是最大吞吐量。

随着越来越多的顾客排队购买食物，他们必须等待轮到自己，从而形成队列。

同样的概念也适用于 Web 应用程序的测试。

如果 Web 应用程序每秒接收 100 个请求，但它每秒只能处理 70 个请求，则其余 30 个请求必须在队列中等待。

在性能测试中，我们将吞吐量表示为“每秒事务数”或 TPS 。

JMeter 性能测试的吞吐量：

使用Apache JMeter来测试软件应用程序的性能非常流行。 JMeter 有助于确定应用程序可以处理的最大并发用户数，并为性能测试提供图形分析。

JMeter 提供了很多方法来记录吞吐量的值。这里给出了一些可用于此目的的 JMeter 侦听器：

• 总结报告
• 综合报告
• 聚合图
• 图表结果

JMeter 还提供了一个计时器组件“ Constant Throughput Timer” ，您可以使用它来设置每秒事务数 (TPS) 的值来测试应用程序的负载。

现在，我们将使用 JMeter 展示吞吐量在性能测试中的使用情况。假设我们要使用 100 个并发线程进行示例测试并跟踪吞吐量的值。

假设我们的系统上安装了最新版本的 JMeter，并且我们已经执行了所有其他所需的配置。现在，我们必须制定一个测试计划。

1. 测试配置

在此测试中，我们将定义五个 ThreadGroup 元素。每个元素都有不同的启动时间，即 0、15、25、35 和 45。启动时间是启动每个线程的持续时间。我们将在这些 ThreadGroup 元素中配置 100 个用户。

如果我们想要配置更多的用户，那么将需要更多的启动时间。

这些线程组将有一个 HTTP 采样器，它将在示例网站（假设 www.samplesite.com）的主页上生成请求。

在用例 1 中，我们有一个配置有 100 个线程的 ThreadGroup 元素，其启动时间为 0。

它将“线程数”字段设置为 100。这意味着 100 个用户将同时发送请求。同样，我们也可以配置其余 4 个线程，并将它们的启动时间设置为 15、25、35 和 45。此外，为每个线程组命名采样器。

如前所述，这些 HTTP 采样器将指向示例网站的主页。

有必要以正确的顺序运行这些线程组。为此，从控制面板中选择“测试计划”，然后选中“连续运行线程组”字段。

2 测试结果分析

“聚合报告”是一个监听器，用于分析和观察测试结果。要使用此侦听器，请右键单击“测试计划”并选择：

添加 → 监听器 → 聚合报告

然后单击开始图标运行测试。

现在，让我们看看如何从聚合报告中了解吞吐量结果。

第一个加速时间为 0 的线程组显示所有线程通过立即启动在服务器上施加即时负载。该场景吞吐量相当高，但不实用。因此，这不会显示实际的输出。

第二和第三线程组具有实际范围的加速时间，因此它们更有可能显示适当的性能吞吐量和请求加载时间。

线程组四和五具有较长的启动时间，这意味着它们的吞吐量将会下降。

因此，可以从第二和第三线程组结果确定可靠的输出。

测试吞吐量时要记住的要点：

部署新版本或更改的决定取决于应用程序处理特定 TPS 的能力。因此，性能测试计划有一定的吞吐量目标。但我们需要确保这些目标是现实的并代表了作品的真实特征。

如果我们用不切实际的条件来通过测试计划，那么一切都是徒劳的。例如，我们上面描述的测试计划对于第一个线程组具有较高的吞吐量值，但它并没有描述实时环境的实际场景。

因此，通过使用此类方法，我们无法正确了解我们的应用程序是否要处理实际负载。因此，设置合适的测试至关重要。

现在，我们将讨论测试性能吞吐量时需要考虑的一些重要点。

• 适当的测试设计：测试设计确定生成的吞吐量是否现实。在实时场景中，每个请求可能不同，也可能会触发复杂的流程以获得所需的结果。所以我们需要根据预期的生活环境来操纵测试。

• 真实用户的表示：每个应用程序用户都可能有影响系统资源的请求。因此，如果测试场景中没有代表真实用户，结果可能会显示后端的资源使用情况不准确，因此测试将无法模拟正确的条件。

• **==考虑暂停和延迟：==**在实时环境中，用户需要思考、获取和处理信息、在字段中输入信息等。但服务器在暂停期间仍然使用资源。因此，尝试将这些用户行为合并到您的脚本中。

• 连接速度：应用程序的用户通过不同的网络速度、区域或移动网络进行连接。因此，有必要选择代表此类用户连接的带宽。

结论

简而言之，吞吐量是Web应用程序的一个至关重要的性能指标。但是，仅依赖吞吐量指标是不够的。因此，需要检查延迟和响应时间。

创建实际吞吐量以实现设定的性能测试目标也非常重要。