性能测试最关键的一个方面是能够模拟应用程序的实际负载。但是，确定目标负载的并发用户数是不够的。在测试阶段使用的相同目标负载下，经过测试的应用程序可能会失败。或者当问题是系统中的瓶颈时，应用程序可能会在测试负载下失败。发生这些事情是因为除了目标负载之外，开发人员和性能测试人员还应该关心在测试执行期间如何分配负载也就是模拟各种负载压力场景。

JMeter 的 Ramping-Up

虽然有很多 JMeter 的参数负责负载分配（比如 Number of threads'线程数'，Loop Count'循环次数'或 Duration'持续时间'），但其中一个参数可能不是那么容易理解，并且它的适当值参数可能并不总是很明显。 此参数称为 ramp-up 斜坡上升。

Ramp-up 是 JMeter 将所有 users (threads)"测试用户（线程)"添加到测试执行所需的时间。 或者换句话说， JMeter 开始执行所有线程需要多长时间。

例如：

• 1000 个目标线程，加速 1000 秒：JMeter 将每秒添加一个用户
• 1000 个目标线程，持续 100 秒：JMeter 每秒将增加 10 个用户
• 1000 个目标线程，50 秒加速：JMeter 每秒将增加 20 个用户

在本文中，我们将重点介绍如何应用 JMeter 的 Rame-up 斜坡上升来模拟我们应用程序的不同负载情况也就是类似 Loadrunner 中的压测场景配置。

配置 JMeter 压测场景

我们将测试某一 web 网站。 我们将应用具有相同目标线程值的各种负载，但具有不同的上升周期组合。

1.创建一个具有目标线程数的线程组（假设为 100）。
右键单击 - >添加 - >线程 - >线程组
将线程数的值更改为 100.现在让我们假设您要运行我们的测试 5 分钟。 因此，您需要在 Duration“持续时间” 字段中指定值 300。 现在，让我们将线程组中的 “Ramp-Up Period” 字段保持为空。

2.添加一个访问 Web 主页的 HTTP Request Sampler "Http 请求采样器"。
右键单击 Thread Group - > Add-> Sampler - > HTTP Request
我将其名称更改为 “BlazeDemo home page”。 添加 “blazedemo.com” 作为服务器名称，并确保将该方法设置为 GET。

3.查看包含用户分布的图表。
这样的图表可以帮助我们可视化负载模式并检查我们要测试的内容。 JMeter 不提供开箱即用的这些选项，但您可以轻松安装 “自定义插件包”，其中包含许多有用的侦听器（可通过Jmeter-GraphsGeneratorListener此链接找到安装说明）。 其中一个插件被称为"Active Threads Over Time"。 添加该侦听器：
添加 - >监听器 - > jp@gc - Active Threads Over Time

请记住 ，如果您有大量目标线程，则加速期不应为 0。 Ramp-up 0 意味着性能脚本将在测试执行开始时立即添加所有线程，因此它会立即给您的应用程序带来非常严重的负载。

当然，有时您可能希望模拟此类负载，例如在 Spike performane test "峰值测试"期间，但这是一个单独的案例，具有单独的最佳实践方法（在下面介绍）。 但即使使用峰值测试，我们通常也不希望所有用户都在测试的第一秒立即执行。

这种情况看起来并不符合实际情况，通常这种负载加压没有任何意义。 如果您有一个 Web 应用程序，用户通常会或多或少地逐渐访问您的站点，并且您的服务器有足够的时间进行适当的调整和扩展。

加速分配应根据您的需求而定。 因此，首先需要做的是了解您的测试目标。 最好的方法是从生产环境中学习并找出当前网站的负载模式。 但与此同时，在许多情况下，它足以创建一个线性加速，显示用户逐渐进入您的网站或应用程序。

创建线性负载加速

1.返回线程组并将 Ramp-Up 周期更改为 120。

因为测试持续时间是 300 秒，所以在 2 分钟内加速，我们有 3 分钟的保持时间。 重要的是，在加速结束并且所有用户都启动并运行之后，有足够的保持时间。 保持时间确认系统可以处理负载并且性能保持稳定且不会恶化。

在这个测试中，我们确定了 3 分钟的保持时间，但在您的情况下，所有这些值都将基于您的特定需求和您要模拟的场景。

2.运行测试，查看活动用户数量如何逐渐增长 2 分钟。

这种负载称为 Linear“线性”。 这种方法适用于主要关注目标负载的许多用户。 但是,这种方法不是最佳实践。 为什么？ 因为如果服务器在线性加速期间在某个负载下表现不佳，通常很难隔离并确定哪个负载。 我们不清楚我们的服务器可以处理哪些负载以及哪些负载不能处理。

这就是为什么按步骤执行加载要好得多。 所以让我们将测试持续时间分成几个阶段。

创建步进负载加速

我们仍然想测试 100 个用户，但我们会逐步逐步提升他们。 我们将从 25 个持有一段时间负载的用户开始，看看服务器如何处理它。 之后我们将增加 25 个到 50 个，另外 25 个到 75 个，最后 25 个到 100 个用户。 这种方法效果更好，更可靠。

不幸的是，JMeter 不支持开箱即用的步进加载步骤。 但是您可以轻松安装名为Ultimate Thread Group终极线程组的相应插件。 此插件为您提供了非常强大的控制线程组加压负载能力和灵活性，可以为您的测试应用程序模拟各种负载场景。

1. Ultimate Thead Group 类似于默认的'Thread Group'JMeter 元素，可以通过以下方式找到：

右键单击左侧的元素选项卡 - >添加 - >线程（用户）- >jp@gc - Ultimate Thread Group

2.在创建'Ultimate Thread Group'元素之后，我们可以从最初的'Thread Group'复制我们的'BlazeDemo home page'请求采样器和'Active Threads Over Time'监听器。

3.Ultimate Thread Group 提供了一个'Threads Schedule' 线程计划表，您可以在其中配置不同的线程组。 您可以决定线程数量（'Start Threads Count'），每组开始添加到测试执行之前的延迟（'Initial Delay，sec'），线程组的加速期（'Startup Time'），sec'），在减速前线程组的持续时间（'Hold Load For，sec'）以及指定所有线程组应该关闭的速度（'Shutdown Time'）。 所有线程组同时启动，但每个线程组都有自己的 Intial Delay“初始延迟” 值，这有助于分别从每个组中分离用户。

Ultimate Thread Group“终极线程组” 插件的另一个重要功能是，您可以在下图中看到预期的负载分布，并根据您的需要调整分配值，甚至在运行脚本之前并且没有考虑到棘手的计算。

让我们将测试分为 4 个步骤，每分钟增加 25 个用户。 在这种情况下，我们的'Threads Schedule' 线程计划表将如下所示。

Spike Testing 峰值测试

这种负载灵活性可能有用的另一个很好的例子是峰值测试。 基本上，峰值测试是一种性能测试，其中应用程序在意外的增量和负载减少下进行测试，以查看它在这种情况下的行为以及是否能够处理这种峰值。 让我们调整我们的'Threads Schedule'来模拟某种峰值测试。 要模拟该模式，我们需要使用 Shutdown Time“关闭时间” 列来负责线程减速。

总结

这样利用 Ultimate Thread Group 的 Threads Schedule 配置压测场景计划,就可以做到和 Loadrunner 一样的负载加压策略了.