SoapUI中提供的不同负载策略允许您模拟各种类型的负载，随时间的变化，您可以在许多条件下轻松测试目标服务的性能。由于SoapUI还允许您同时运行多个LoadTests（参见下文的示例），可以使用LoadTests的组合来进一步断言您的服务的行为。从LoadTest窗口中的Strategy工具栏中选择所需的LoadTest策略：
我们来看看可用的不同负载策略，看看如何使用它们来进行不同类型的负载/性能测试。
简单的策略 - 基准，负载和SOAK测试
简单策略运行指定数量的线程，每次运行之间具有指定的延迟，以模拟服务器的间隔空间。例如，如果要运行具有10秒延迟的10个线程的功能测试，则将线程设置为10，延迟到10000并随机到要随机化的延迟（即将其设置为0.5将导致5-10之间的延迟）。当创建新的LoadTest时，这是默认策略，并设置在相对较低的负载（5个线程，1000ms延迟）。
简单的策略是完美的基线测试。使用它来声明您的服务的基本性能，并验证没有线程或资源锁定问题。当您想要进行更精细的负载测试或使用长期运行的浸泡测试策略时，可以增加线程数。
既然这不意味着让您的服务瘫痪，像这样的设置可以用于持续的负载测试，以确保您的服务在适度的负载下按预期运行; 设置基准测试，不随机化延迟，添加LoadTest断言，作为安全网络的意外结果，并在命令行中使用LoadTest或Maven插件自动执行。
2.Fixed Rate策略
简单策略不能做的一件事就是在一定时间内保证一些执行，例如，如果您希望每秒启动TestCase 10次，无论执行多长时间。使用简单策略，您可以设置10个线程和一个延迟，但是随着时间的推移，这将非常不可靠。应该使用Fixed-Rate策略; 根据需要设置比率（在我们的情况下为10）运行; 该策略将自动启动所需数量的线程维持TPS的值接近比率。
如标题所示，这里有一些曲折：如果我们的TestCase需要超过一秒的时间才能执行？为了保持配置的TPS值，该策略将在内部启动新线程以补偿这一点; 过了一会儿，由于原来的线程没有在设定的比率内完成，所以可能有10个以上的线程运行。毫不奇怪，这可能导致目标服务变得更慢，从而导致越来越多的线程开始使用配置的TPS值被超越。你可能猜到“Max Threads”设置是为了防止在这种情况下SoapUI超载（本身和目标服务），在这里指定一个值将限制SoapUI允许启动的最大线程数维护配置的TPS，
“Request Level”设置将尝试将TPS维护不在TestCase执行级别，而是依赖于请求级别，例如，如果您具有数据驱动的LoadTest或具有许多请求的TestCase，则希望TPS设置不应用在整个TestCase的执行级别，但在请求级别。
在任何情况下，如果您没有遇到上述“线程拥塞”问题，Fixed-Rate策略对于基线，加载和保温测试非常有用。另一方面，您可能会引起拥塞（甚至可能与另一个LoadTest结合使用），以了解您的服务如何处理此问题，或者在拥塞处理后如何恢复。
可变策略
有几种策略可以用于随时间，每次模拟不同类型的行为而变化负载（线程数）。它们可用于恢复和压力测试，但同样适用于基线测试，无论是自己的还是与其他策略相结合：
运行此策略时间间隔设置为5000，线程数将每5秒更改一次：
Variance策略 - 随着时间的推移，“锯齿形”线中线程的数量随配置而异; 将Interval设置为所需的值，并将“Variance”设置为减少和增加的线程数。例如，如果我们从20个线程开始，将间隔设置为60，将方差设置为0.8，线程数将在前15秒内从20增加到36，然后减少到20，45秒后继续下降到4个线程，最后在60秒后回到初始值。在统计图中，我们可以很容易地跟随这个方差：
Burst策略 - 此策略专为恢复测试而设计，并将其转变为极致; 它运行时配置的Burst Delay不起作用，然后在“Burst Duration”的时间内运行配置线程数并返回睡眠状态。在这里您可以（并且应该！）将线程数设置为一个较高的值（20+），以在短时间内模拟流量的冲击，然后使用包含基本性能的标准基线LoadTest来测量系统的恢复，相关断言 让我们尝试一下这个突发延迟，持续时间为10秒，持续60秒;
该图显示活动的突发。还要注意，分辨率已经更改为250ms（从默认的“数据”值），否则我们在执行“睡眠”期间不会有任何图表更新（因为不会收集数据）。
该Thread策略可以让你线性的改变线程数从一个层次运行到另一个。例如找到哪个线程数量可以实现最大TPS或BPS，或者找到哪个线程数量功能测试错误开始发生。启动和启动结束线程值（例如5到50），并将持续时间设置为相对较长的持续时间（我使用至少30秒每线程值，在这个例子中为1350秒），以获得准确的测量。
Grid策略 - 此策略允许用户在指定的时间间隔内专门配置线程数的相对变化。它的主要用途是更高级的场景和恢复测试，您需要在不同的负载和负载变化下查看服务行为。例如，假设您要运行10秒，20分钟，10分钟，40分钟，10分钟等待60秒。配置您的LoadTest从10个线程开始，然后在网格中输入以下值：
两个值都相对于LoadTest的持续时间和实际的ThreadCount存储; 如果您更改这些，则相应的Grid Strategy值将被重新计算。运行测试显示以下输出：
脚本策略 - 脚本策略是最终的定制可能性; 您指定的脚本会定期调用（LoadTest选项对话框中的“Strategy Interval”设置），并且应在当前时间返回所需的线程数。返回当前值以外的值将启动或停止线程以进行更改。这允许线程数量的任何种类的变化，例如以下脚本随机化5到15之间的线程数。
这里的可能性是无止境的。
4.统计计算和线程数更改
您需要注意的是其中许多策略将改变线程数对统计有重要的影响; 当线程数量发生变化时，通常会更改目标服务的响应时间，从而导致avg，tps等的更改，但由于LoadTest已经在先前的线程数上运行，因此这些运行的结果将会偏移新的ThreadCount的结果。
例如。说你已经跑5个线程了，平均到500ms。使用线程策略可以逐渐增加线程数; 当运行6个线程时，平均增加到600ms，但是由于针对5个线程收集的“旧”值仍然存在，这些将总体导致较低的平均值。有两种方法可以解决这个问题：在LoadTest选项对话框中选择“Reset Statistics”值，或使用LoadTest工具栏中的相应按钮手动重置统计信息; 在任何一种情况下，旧的统计信息将被丢弃。要看到这一点，我们来做一个线程测试，从10到20个线程，300秒（每线程30秒），下面你可以看到结果，这个设置未被选中，然后检查;
在后一种情况下，当线程数量发生变化时，每次重置统计信息时，都会看到“跳转”，逐渐调整为新值。以20线程计算的最终TPS在这两者之间差异在10％左右，显示较低的结果“影响”较高的TPS。
5.同时运行多个负载测试
好的，我们来看一下这个; 我们将使用简单的策略和少量线程创建一个基线测试，同时运行突发策略，以了解基准测试性能在突发之后如何“恢复”
在这里，您可以看到简单的策略（底图）在每次加载突发之后逐渐恢复。
最后的话
希望您对SoapUI中可用的不同负载策略有一个很好的了解，以及如何使用它们来模拟不同的负载测试覆盖情况。您可能已经注意到，SoapUI更侧重于“行为”（了解您的服务如何处理不同的负载），而不是确切的数字，无论如何都难以计算，因为有太多的外部因素影响它。