性能测试在 soapUI 中称为 Load Test, 针对一个 soapUI 的 TestCase, 可以建立一个或多个 LoadTest,
这些 LoadTest 会自动的把 TestCase 中的所有步骤都添加到其中， 在运行的时候，soapUI 会自动的使用多个线程来运行这些
TestStep，同时也会监控它们的运行时间， 例如最短时间，最长时间，平均时间等等。这样用户能够很直观的看到 REST
服务的响应时间，从而对性能进行调优。
建立 LoadTest 非常简单，只需要在“Load Tests”上点击右键， 选择"New LoadTest",
然后输入名称即可，下图是一个针对 GetBookList 的性能测试， 可以看到有两个 TestStep : "GetBookList_xml"
和"GetBookList_json" , 100 个线程并发执行， 时间限制是 60 秒。最后的结果是，最短时间 4 毫秒，最长时间
1204 毫秒，平均时间 20.54 毫秒。
性能测试还支持断言，用户可以对一个 TestStep 或 TestCase 设置运行时间要求，例如平均时间大于 2 秒就认为失败，点击图 8 中中的“LoadTest Assertions”就可以设置。 当然根据需要，用户也可以编写脚本来做一些准备工作，或者清除工作。 参见图 8 中的"Setup Script"和“TearDown Script”。
可用不同的加载策略soapUI和soapUI
Pro可以模拟各种类型的负载随着时间的推移,使您轻松地测试的性能在许多条件下目标服务。从soapUI还允许您同时运行多个LoadTests(见一个例子进一步下降),结合LoadTests可以用来进一步维护服务的行为。选择所需的战略LoadTest从策略在LoadTest窗口工具栏:
我们看看可用不同的加载策略,看看他们可以用来做不同类型的负载和性能测试。
1。简单的策略——基线,负载和浸泡测试
简单的策略运行指定的线程数与指定的各运行模拟之间的延迟对服务器的“呼吸空间”。例如如果你想运行功能测试与10秒延迟10个线程,线程设置为10,推迟到10000年,随机延迟的多少你想随机化(即设置0.5将导致延误5至10秒)。当创建一个新的LoadTest这是默认策略和设置在一个相对较低的负载与1000毫秒的延迟(5个线程)。
简单的基准测试的策略是完美的。用它来维护您的服务的基本性能和验证没有线程或资源锁定问题。增加线程的数量,当你想要做更复杂的负载测试或使用长期浸泡测试策略。
因为它并不意味着把你的服务他们的膝盖,这样的设置可以用于连续负载测试,以确保您的服务执行如预期温和负荷;建立一个基线测试,没有延迟的随机化,添加LoadTest断言作为安全网,意想不到的结果和自动执行命令行LoadTest跑步者或maven插件。
2。固定利率策略——简单
简单的策略不做的一件事就是保证在一定时间内执行,例如,如果你想开始你的TestCase
10倍每秒钟执行不管需要多长时间。使用简单的策略可以设置10个线程和延迟补偿的平均差距TestCase的结束和下一秒的开始,但这将是非常不可靠。应该使用固定利率策略相反,根据需要设置率(10)在我们的例子中,你走;策略将自动开始为这个设置所需数量的线程试图维护配置的值。
暗示的标题,这里有一些曲折:如果我们的TestCase执行时间超过1秒?维护配置的TPS价值,内部战略将启动新的线程来弥补,一段时间后,你可能会有许多超过10个线程运行由于原始的没有完成组内。而不是令人惊讶的是这可能导致目标服务变得更慢,导致越来越多的线程被开始与配置的TPS“跟上”的价值。正如你可能猜到“马克斯线程”设置是她阻止soapUI重载(本身和目标服务)在这种情况下,指定一个值将限制线程的最大数量的soapUI将被允许开始维护配置的TPS,如果达到现有的线程必须完成之前soapUI将任何新的开始。
“请求水平”设置将试图维持TPS不是TestCase而是请求的执行水平,例如,如果你有一个数据驱动的LoadTest或者TestCase和许多请求,您希望TPS设置应用而非整个TestCase的执行水平的要求水平。
在任何情况下,固定利率策略用于基线,负载和soak-testing如果你不遇到上述“线程拥堵”问题。另一方面,你可能会引起交通拥堵(甚至结合另一个LoadTest)看到你的服务如何处理这个或拥塞处理后如何恢复。
3所示。可变负荷策略
有几个策略,可用于不同负载(线程)的数量随着时间的推移,每个模拟一种不同的行为。他们可以为恢复和压力测试是有用的,但是,正如对基线测试,结合自己或与其他策略。让我们来快速浏览:
方差策略——这不同线程的数量随着时间的“锯齿”庄园配置;间隔设置为所需的值和方差的线程的数量应该减少和增加多少。例如如果我们从20线程,设置间隔60和方差0.8,线程的数量将从20增加到36在第一15秒,然后减少回20,继续到4线程45秒后,最后返回到初始值后60秒。在统计图中我们很容易遵循这个方差:
2. 破裂的策略——这种策略是专门为恢复测试和方差推向了极端,它并没有配置延迟,然后运行的配置数量的线程“破裂时间”和回到睡眠。这里你可以(而且应该)的线程数量设置为高价值(20 +)来模拟冲击的交通在短时间间隔内,然后用一个标准衡量系统的恢复基线LoadTest包含基本绩效断言。让我们试试这个破裂延迟和60秒10秒的持续时间;
在这里可以看到的活动图,也请注意,该决议已经改为250 ms(从默认的“数据”值),否则我们没有任何图更新在“睡眠”时期的执行(因为没有收集数据)。
3.线程可以线性策略改变从一个水平到另一个线程的数量/
LoadTest的运行。它的主要功能是作为一种手段来确定某些统计数据变化或事件发生时的水平,例如找到ThreadCount的最大的TPSBPS可以实现或发现ThreadCount功能测试的错误开始发生。设置开始和结束线程值(例如5
- 50)并设置持续时间相对较长时间(我每个线程使用至少30秒值,在本例中,将1350秒)获得准确的测量数据(更多内容见下文)。
4.网格策略——这种策略允许专门配置的相对变化的线程数量随着时间的推移,其主要用途是更高级的场景和恢复测试,你需要看到在不同负载下的服务行为和负载变化。比如让你想要运行的60秒10,20,10,40岁,10个线程。配置您的LoadTest开始10个线程然后网格中的输入以下值
两个值存储相对于时间和实际ThreadCount LoadTest;如果你改变这些,相应的网格战略价值将重新计算。运行测试显示以下输出:
5.脚本战略——脚本是终极定制可能性;您所指定的脚本叫做定期(“间隔”战略LoadTest选项对话框中设置),应该返回所需的当前时间的线程数量。返回一个值而不是当前将启动或停止线程调整改变。这允许任何类型的方差的线程的数量,例如下面的脚本随机排列5和15之间的线程的数量
运行这个策略的时间间隔设置为5000线程的数量会改变每5秒:
这里的可能性是无限的。
4所示。统计计算和ThreadCount的变化
这些策略将会改变许多线程的数量有重要影响的统计计算,你需要意识到,当线程的数量发生变化时,这通常会改变目标服务的响应时间,导致改变avg,tps等等。但自从LoadTest已经运行在以前的结果对于那些运行的线程数量将为新ThreadCount倾斜的结果。
比如让你5线程和有平均500 ms。使用线程策略你线程的数量逐渐增加,当运行6线程的平均增加到600
ms但由于收集的“老”值5线程仍然存在,这些总共将导致较低的平均水平。有两种简单的方法解决,选择“重置统计ThreadCount变化”的价值LoadTest选项对话框,或手动重置统计与相应LoadTest工具栏按钮;在这两种情况下旧的数据将被丢弃。看到这个行动让做一个ThreadCount策略从10到20线程测试超过300秒(30秒每个线程),下面你将看到的结果都与这个设置未检查,然后检查;
在后一种你看到“跳跃”统计每次重启时线程的数量变化,逐渐平一个新值。最后TPS计算在20线程不同这两个之间的约10%,显示较低的“影响”更高的结果。
5。同时运行多个LoadTests
好,让我们有一个快速浏览,我们将创建一个基线测试简单的策略和低数量的线程,同时运行一个破裂策略如何基线测试性能“复苏”后,破裂;
在这里你可以看到简单的策略(底部图)逐渐恢复后的负载。
6。最后的话
希望你得到一个很好的概述soapUI的不同策略和他们如何可以用来模拟不同场景和类型的负载。正如你可能已经注意到,soapUI更关注于“行为”LoadTesting(了解您的服务处理程序不同的加载)而不是具体的数字,这是无论如何难以计算因为有太多的外界因素影响。
网友评论