soapui接口性能测试（一）---- 创建并运行一个性能测试

1. soapui使用性能测试

SoapUI中的LoadTest用于在您所需的持续时间内使用多线程（与“虚拟用户”相同）时重复运行现有的功能TestCase来断言您的目标服务。LoadTests在导航器中显示为此TestCase的子项;

（这里可以看到“Test and Buy TestCase”TestCase有四个LoadTests定义）。

您可以从TestCase右键菜单或TestCase工具栏中使用New LoadTest选项为您的TestCase创建任意数量的LoadTests 。在导航器中双击LoadTest窗口（新创建的LoadTest将自动打开）。

1.1。运行LoadTest

SoapUI允许您使用您的硬件可以负担的多个线程（“虚拟用户”）运行LoadTest，主要取决于内存，CPU，目标服务响应时间等。设置所需的值并启动LoadTest在LoadTest窗口的左上角使用“run”按钮。

TestCase在loadtest内部针对每个配置的线程进行克隆，并使用其自己的上下文，脚本，属性等启动。TestCase将访问TestCase及其TestSteps的唯一“复制”，它可以避免在TestStep和TestCase级别（但不是更高级别）的线程问题。

如果您的TestCase修改了Test Suite或项目属性，这将在公共共享的父对象上完成。

“Thread Startup Delay”在负载测试选项对话框中设置可用于每个线程的开始之间的延迟。

根据选择的限制和策略，LoadTest将按照配置运行，直到由于以下原因之一终止：

• 已达到其配置限制
• 使用LoadTest工具栏上的“ 取消”按钮取消了用户
• 当该断言的允许错误的最大数量超过时，LoadTest被终止

如果限制是基于时间的，则LoadTest选项对话框中的“ Cancel Running”选项允许您控制正在运行的线程在达到界限是否应该被允许完成或取消当前testcase。在同一个界面中，“Cancel Excessive”选项可控制当线程计数减少时（例如使用突发策略）时是否应取消过多的线程。

多个LoadTests可以并行执行，以测试更高级的场景，只需一次打开几个窗口并并行运行。一个示例场景可能是一个负载测试，包括一个simple策略的LoadTest生成基线流量，另一个LoadTest使用Burst策略，它在突发中创建高流量; 在每个突发之后，基准LoadTest可以断言系统根据需要处理和恢复。

1.2。统计收集

当LoadTest运行时，每次执行的TestCase完成时，使用收集的数据持续更新LoadTest统计信息(界面的列表)，从而允许您在LoadTest执行时交互监控目标服务的性能。如果您的TestCase包含循环或长时间运行的TestSteps，则可能需要一些时间来更新统计信息（因为它们在TestCase完成时被收集），在这种情况下，请在LoadTest选项对话框中选择“TestStep Statistics”选项以获取更新TestStep级别的统计信息，而不是TestCase级别（这需要在内部进行更多的处理(影响性能)，这就是为什么默认情况下被关闭）。

统计数据的收集和计算是异步执行的（即独立于实际的TestCase执行），因此它不会直接影响实际的LoadTest执行。此外，“ LoadTest选项”对话框中的“ Statistics Interval”设置控制从基础统计模型更新统计信息表的频率，如果需要更多或更少频繁的更新，请更改此值。

快速提示： 几个策略还允许您在执行期间更改线程数，从而使您可以在LoadTest进度时交互地更改负载并监视结果。如果要在线程数量更改时重置计算的统计信息（因此avg和tps等数字不会与以前的结果相违背），请确保选中“LoadTest选项”对话框中的“ Reset Statistics”。

1.3。TPS / BPS计算

对于除TPS（每秒事务）和BPS（每秒字节数）之外的所有列，统计表中不同值可以通过两种不同的方式直接计算的（由LoadTest选项对话框的“Calculate TPS/BPS”设置）;

• 根据实际时间（默认）：
  • TPS：CNT /秒通过，即运行10秒并处理100请求的TestCase将获得TPS为10
  • BPS：字节/传递的时间，即运行10秒并处理100000字节的TestCase将获得10000的BPS。
• 基于平均执行时间：
  • TPS：（1000 / avg）* 线程数，例如avg = 100 ms，十个线程将给出TPS为100
  • BPS：（bytes / CNT）* TPS，即每个请求的平均字节数* TPS。

为了更好地了解这两者之间的差异，我们来创建一个小例子; 一个具有两个groovy脚本的TestCase，第一个睡眠900ms，第二个为100ms。我们将用10个线程运行10秒，理论上应该导致100次执行我们的TestCase;

根据传递的时间计算TPS，两个测试步骤的值相同，因为它们在10秒钟内执行相同次数。它们的单独执行速度不会影响该值。

现在让我们改变TPS的计算方式是基于平均值（在LoadTest选项对话框中）： 

当我们现在运行测试时，我们得到以下内容：

这里，第一个测试步骤的假设TPS计算为11，因为使用10次平行运行，平均时间为909ms。第二个测试阶段得到100 TPS，再次用10个平行运行计算，平均运行99ms（如果这是持续的性能，我们理论上可以在每秒钟内“挤压”100个请求）。

这两个使用哪一个取决于你; 使用单步TestCases，您应该从两者获得大致相同的结果，但是当您的TestCases包含许多步骤时，两种方式都有其优缺点（如上所示）。

统计图

在执行期间，LoadTest工具栏有两种类型的图表可供选择：统计和统计历史。这些的主要目的是随着时间的推移可视化选定的统计数据，以便能够发现突发和意外的变化。显示统计数据是相对的（不是绝对的），因此图形对于分析精确数据不是很有用。两个图都有一个频率设置，用于控制图形更新的频率; 将其设置为“data”将以与统计表相同的间隔更新图形。或者，如果您想要其中一个固定频率选择。

该统计图表显示了所选步骤或随着时间的推移，整个测试用例所有相关的统计数据，让你看到价值如何变化，当你增大一定比例的线程数：

正如你可以看到，绿色线（线程）在测试一半后跳转，这也导致平均预期跳跃和每秒事务的微小变化，尽管我们增加了我们没有获得的线程数，吞吐量相应增加（因为平均响应时间增加）。

该统计数据历史图表显示让你对它们进行比较及查看所有步骤选定的统计值是否随着时间的推移变化。对于相同的测试，我们可以比较avg的变化：

以上图表包含TestCase中每个TestStep的一行，其显示与我们的Statistics表中的TestStep相同的颜色：

当线程数增加时，我们可以看到两个TestSteps的平均更改类似。

1.4。TestStep具体要记住的事情

LoadTests的多线程执行有一些TestStep特定的含义，您应该在设计和运行LoadTest时注意：

• 运行TestCase：如果您的TestCase包含“Run TestCase”步骤，则不会为LoadTest中的每个线程克隆其目标TestCase; 所有线程将各自执行目标TestCase的相同实例。在选项对话框中的“run mode”选项可用于控制在这种情况下的行为; 将其设置为“Create isolated copy”（将执行此操作）或“Run primary TestCase（等待运行完成，线程安全）”，这将同步对目标TestCase的访问。“Create isolated copy“将提供更好的性能，但是对于每次执行，对目标TestCase的内部状态的任何更改都将丢失。
• DataSource：可以在LoadTest中的线程之间共享DataSources，从而允许您在用于驱动测试的数据之间划分线程。这可以派上用场，但确实有一些你应该明白的配置问题，在这里阅读更多：数据驱动的LoadTests。
• DataSink：就像DataSource一样，DataSink也可以共享，导致所有的线程写入同一个DataSink。请记住，在LoadTest的整个运行期间，共享的DataSink将用于所有线程，这可能相当多的数据。
• DataGen：DataGen属性可以设置为在线程之间共享，这对于用于生成唯一ID的DataGen Number属性很有用（如果该属性未设置为共享，每个线程将获得相同的数字序列）。