Load Testing soapUI Tests

What is soapUI Integration?

User Rating: / 7  |  Rate this article: PoorBest 


What it is

soapUI is the market leading web service testing tool, by far. LoadUI bundles the complete soapUI Pro engine and lets you run soapUI TestCases and Mock Services.


Why you need it

It is quite simple:

  1. Load tests that does not assert the functionality of the application under test are useless.
  2. soapUI is the market leading functional testing tool for internet APIs.
  3. soapUI integrates seamlessly into loadUI.

Also, with the soapUI Runner's support for cookies and passing along properties, it is a cornerstone in creating realistic user flows.



SoapUI Runner Tutorial Demo Video

You’ve written great code that should knock your client’s socks off. But before you send those socks flying, you need to make sure your software is completely ready. You need to load test it. By using the SoapUI Runner you can quickly and easily load test all your functional tests from SoapUI directly in LoadUI.

Short tutorial video


Long demonstration video

The soapUI Runner Component

You probably already know LoadUI, our cross-platform, Open Source load testing solution.
LoadUI takes distributed testing to a whole new level. Its visual, drag-and-drop interface enables you to create, configure and redistribute your load tests interactively, and in real time?
In a single test environment, LoadUI provides complete test coverage and supports all the standard protocols and technologies.

Sounds great, right? But you know what’s even better? Integrating LoadUI with the SoapUI and the SoapUI runner, which enables you to import your existing functional tests from SoapUI, with all of SoapUI’s supported protocols, into LoadUI and test them. How cool is that?
It’s the next logical step in the software testing process, if we do say so ourselves.

How the soapUI Runner Works

Connecting a soapUI Runner to other Components

The SoapUI Runner creates a smooth workflow when you’re testing your API. After you’ve created and run all your functional tests in SoapUI, just import them into LoadUI and see how they perform under load.

When you add the SoapUI Runner component to your workspace, just click the browse button and navigate to the SoapUI test suite you want to import. You’ll see a list of all the test steps within that test case, and you can choose which ones to run. LoadUI also transports any test case properties, including session IDs and cookies, as part of the output so other components can pick up and use them.

Benefits of Using SoapUI Runner with LoadUI

Mixing components, such as several SoapUI Runners, enables you to easily create powerful, realistic use cases. For example, you could run a “login” test step, then split your logged-in users between “search” and “browse” test steps. Half of the users could then go to “buy” followed by “logout” test steps while the other half go straight to “logout.”
The SoapUI Runner also updates itself in real time with any changes you make to the SoapUI test suite. If you change anything within the test suite, just wait a few seconds and LoadUI will update as well. This way you don’t have to worry about what happens to your LoadUI test if you need to change something in SoapUI.
Oh, and if all of this isn’t great enough, SoapUI runner integration is available in both Open Source LoadUI and LoadUI Pro. With LoadUI Pro you can also easily see how your SoapUI test cases are affecting your server. Look at anything from RAM  and CPU usage and disk I/O to database performance and resource utilization.

Ready to give it a try? Click here to download a free 14-day trial of loadUI Pro.
Ready to learn more about using the soapUI runner with loadUI? Watch the video above or read the tutorial to get started using the component.





Passing Along TestCase Properties

User Rating: / 4  |  Rate this article: PoorBest 


This tutorial will teach you how to pass on information from a soapUI Runner, such as TestCase Properties or cookies, to subsequent Runners (or other components). This tutorial will continue from where Getting Started with soapUI Integration left off.

Video Tutorial

The second half of this video cover some parts of the written content below.


The soapUI setup

We will use a simple soapUI Project, consisting of two Testcases: Login and Logout.


The Login TestCase first fetches a user from a database and then sends a Login request to a server. Finally, a Property Transfer TestStep saves the session-ID that it got back from the server to a TestCase Property called sessionId.


The Logout TestCase just consists of one TestStep: A Logout request using the TestCase Property sessionID as a parameter value. Please note that it's crucial that both of the TestCases have a TestCase Property with the same name!


The Logout TestStep also has a Not SOAP Fault assertion set, which will fail the TestStep (and thus the TestCase) if the server responds with a SOAP fault. This will happen if the server is requested to end a user session that is not active.

The loadUI setup

This is the setup that we will use in loadUI:


The loadUI setup (click to zoom).

The exact setup does not matter; the important thing is that:

  1. We have one soapUI Runner connected (directly or indirectly) to another soapUI Runner.
  2. The second Runner's needs a value from the first Runner (in this case the sessionId TestCase Property).


That will do, now let's hit that Play button!


You will be able to see the execution count for each individual TestStep:


The second soapUI Runner's requests now completes without failing (i.e. Completed increases and Failures is 0), which mean that it works!

Just to be sure, let's intentionally break the property passing by disabling the Property Transfer TestStep. Remember, this is loadUI, so there is no need to stop the test before doing this:


As expected, the Failed counter will now start increasing on the second soapUI Runner.

Behind the curtains

You will now learn what happened behind the curtains when we disabled the Save session TestStep. To be able to see which values a Virtual User carries, we have routed them through Table Log components. To make it easier to follow, we have also simplified the structure of the scenario.

We trigger a single Virtual User in the first Runner by clicking Run Once...

  1. As expected, the first two TestSteps was run, but not the third one 1_snag_evi.
  2. In the following Table Log, we can see 2_snag_evi that the sessionId was never passed along from the Login Runner. If we would not had disabled the Save session TestStep, the sessionId field would contain some number.
  3. When the Virtual User arrived to the Logout Runner, it sent the logout request 3_snag_evi, but with a blank sessionId parameter.
  4. The server responds with a SOAP Fault, since the request is invalid. Our soapUI assertion Not SOAP Fault triggers and fails the Logout TestCase 4_snag_evi.
  5. The right-most output of Runners is called the Errors output. It spits out an error message each time a Failure occurs. Sure enough, we can see the Not SOAP Fault error message 5_snag_evi.



Getting Started with soapUI integration

User Rating: / 3  |  Rate this article: PoorBest 


The soapUI Runner is the most powerful of the Runners that are bundled with loadUI, but also the most complex one. That is why this tutorial assumes that you are familiar both with the basics of loadUI and the basics of soapUI.

Video Tutorial

The first half of this video corresponds to the written content below.

Setting up a soapUI Runner

Start by creating a soapUI Runner, by dragging it from the component's toolbar to the grid. Proceed by clicking the soapUI Project dropdown and then click Browse to bring up a file browser.


Find the soapUI Project file that you would like to load test and click Open.


The soapUI Runner will now load the first TestCase of the first TestSuite in that soapUI Project. As a result of this, the previously empty table will be populated with that TestCase's TestSteps — a view that should look familiar to any soapUI user.


If you are not happy with the first TestCase of the first TestSuite, just click the soapUI Project dropdown again:


The soapUI Runner is now configured! You may want to test that it works by clicking the Run Once button, and then lean back in your chair and just enjoy the feeling of having the complete soapUI engine encapsulated in a small box.

What's next?

When you feel ready to learn more about the soapUI Runner, I would suggest heading over to either Passing Along TestCase Properties or Advanced Topics.


Advanced Topics

User Rating: / 4  |  Rate this article: PoorBest 


Distributing to agents

External resources (such as XLS-files for DataSources or JKS-files for keystores) that your soapUI-project references will not be distributed to agents. A way to get around this is to simply put the external resources in the agent's file system as well, at the same path.

External libraries

External libraries may be used in Groovy Script TestSteps in soapUI by putting an JAR-file in [soapUI home]/bin/ext and importing the library in the Groovy code. This is documented in detail here.

To be able to run such TestCases in the soapUI Runner, place the same libraries in [loadUI home]/ext, e.g. c:\Program Files (x86)\SmartBear\loadUI 2.0\ext. Failure to do so will result in error messages like this one:

Script2.groovy: 6: unable to resolve class org.apache.http.message.BasicNameValuePair
 @ line 6, column 1.

Debugging Failures

When you get failed TestCases in soapUI, you can always open the error log to see what's going on. This is obviously not the case with the soapUI Runner, but there are alternatives:

Some words about concurrency

Try to avoid writing to TestSuite or Propject properties from your soapUI TestCase, as these properties are shared among all Virtual Users. TestCase Properties on the other hand, are not shared and therefore a much better option.


Read about the difference between soapUI assertions and loadUI assertions, and how we recommend using the two, here.

Parameterizing your TestCase

The soapUI Runner's settings dialog allows you to set (and override) any of the TestCase Properties defined in soapUI in the Properties tab. This is useful if you need to control some aspect of your test from inside loadUI; for example if you want to be able to control the target host called by your service requests in your soapUI TestCase you would:

  1. Define a corresponding property in soapUI and set a default value:


  2. Use that value in your soapUI TestCase via Property Transfers or Property Expansion:


  3. Override the value from inside loadUI to load another target system:


To learn how to parameterize like this from the command line, please refer to the chapter Parameterizing Tests in the Getting Started with Automation article.

The Mock Service Component

The Mock Service Component is used to run a soapUI MockService from loadUI. Read more about it in its article in the component reference section.