{ArticleIndex}

If you are using soapUI to perform functional tests or service simulations, loadUI provides two components that allow you to use your soapUI artifacts as parts of a loadUI testing scenario:

• The soapUI Runner component executes a specified soapUI TestCase each time it receives are trigger message. It allows you can run any soapUI TestCase as part of a loadUI test, giving you the possibility to test any protocol supported by soapUI (HTTP, AMF, JDBC, etc) via the testing functionality of loadUI.
• The MockService component hosts a specified soapUI MockService inside loadUI, allowing to easily providing virtual service simulations as part of your load testing scenarios.

Of course any number of these components can be added to a loadUI Project, allowing you to run multiple soapUI TestCases and MockServices at the same time, in distributed mode, etc, etc.

Let’s start by doing a quick sample walkthrough showing you how to use both of these in a simple setup.

Create your Project

Start by creating a new project in the Workspace view; drag a Project from the Component bar to the left on to the list of Projects, this will display a dialog as follows:

Enter the desired values and be sure to check the “Open the new Project?” checkbox. After pressing OK you will be presented with an empty loadUI Project :

Add a MockService component

We’ll start by adding a soapUI MockService component; scroll to the “Misc” category in the component toolbar to the left and drag a “MockService” component from it to the work area:

Here we will use the MockService that is in the sample soapUI project included with loadUI; click the Browse button on the MockService component and browse to the getting-started-soapui-project.xml in your loadUI\samples folder. Open it and then select the “MockService 1” MockService in the soapUI MockService dropdown. Finish off by starting your test in loadUI with the "Run" button in the top toolbar:

Now the MockService is running! If you click the “Open in Browser” button on the MockService component you should get the following displayed in your system browser:

(this is all the MockService does; return a "Hello World" response)

Add a soapUI Runner Component

Next up is to configure a soapUI TestCase to run against this MockService; this TestCase is included in the same sample project so we’ll start by adding a soapUI Runner component to our setup:

Specify the same getting-started-soapui-project.xml file as the soapUI Project and select the “TestSuite 1” TestSuite and “TestCase 1” TestCase in the corresponding combo boxes. Be sure the loadUI Test is still running and click the “Run Once” button; you should see increased counters in both the soapUI Runner (which executed the specified TestCase) and the MockService component (which handled the request sent by the TestCase).

A "Real Life" Scenario

Now let’s turn this into a more “realistic” scenario. We’ll pretend that we want to test the performance of our target service (in this case the MockService) starting at 100 req/sec and up to 200 req/sec to see if we have any performance degradation. For this we add the following components to our setup:

• A Ramp Generator that ramps from 100 to 200 req/sec over the desired timeframe
• Two Statistics Components:
  • One for visualizing the Avg Response Time
  • One for visualizing the TPS (Transactions per Second)

(One Statistics component could be used for both but since the values have totally different scales I’ve put them in separate).

The setup looks as follows:

Here you can also see the results after running the test;

• The TPS graph (bottom right) increases in line with the increased load from the Ramp Generator, from 100 to 200 requests per second
• The Avg graph (top right) doesn’t change much

Conclusion: Our target service (the MockService) performs just as well at 200 req/sec as it does at 100 req/sec!

Opening in soapUI

Both of these components have a “Open in soapUI” button, if you click it (and have soapUI running) loadUI will tell soapUI to open the corresponding project and item for your editing. For example if you click the button in the soapUI Runner component you will get something like

Here you can see the simple TestCase we have been running; you can modify it and click back to loadUI using the “sync with loadUI” button in the TestCase toolbar which will:

• Save the changes to your soapUI project
• Transfer control back to loadUI
• Refresh the soapUI project used by the soapUI components (so that the changes are applied in loadUI also)

(Read more about the soapUI to loadUI integration at Using loadUI for Load Testing on the soapUI website)

{ArticleIndex}

Let’s dig a little deeper into the workings of the soapUI Runner component which you can use to test any of the protocols supported by soapUI, including JDBC, AMF, REST, SOAP and standard HTTP (please note: JMS is not supported).

A Simple Setup

We’ll start by creating a simple scenario that we will use to illustrate available functionality. We’ll use the sample project included with soapUI as it provides some more advanced TestCases (you can find it attached at the bottom of this document if you don’t have soapUI installed) and corresponding MockServices.

Start by creating a new loadUI Project in the Workspace View:

Then add a soapUI Runner configured to use the soapUI-sample-project and the "Simple Login and Logout w Properties" TestCase in the "Sample Simple TestSuite" TestSuite:

Now add a MockService component to host the required MockService called by the TestCase (included in the same soapUI project file):

Next start the test in loadUI (with the toolbar at the top) and then click the “Run Once” button on the soapUI Runner, you should see increased counters on both the soapUI Runner and the MockService component:

This indicates that the TestCase was successfully executed against the MockService (the TestCase makes two requests to the MockService, therefore the counter values).

TestCase Execution and Output

As mentioned above the soapUI Runner will execute the configured TestCase each time it receives a trigger message to its input terminal (or if you click the “Run Once” button as we did above). The TestCase is run just as it is run inside soapUI; the setup and teardown scripts will be executed, event handlers will be called, etc. etc. It supports both soapUI and soapUI Pro TestCases meaning that DataSource, DataGen and DataSink TestSteps will work just as well.

The soapUI Runner has the basic runner input and output terminals as described in the Components Overview. For the execution results (the left-most terminal) it is possible to configure if only the TestCase results should be output (default) or if the individual results of each soapUI TestStep should be output as well. The later can be configured in the components settings dialog:

For example selecting “TestCase and RequestTestSteps” will allow you to analyze statistics for individual teststeps as well as for the entire TestCase. If we select this option and connect the output of our soapUI Runner to a TableLog we see 3 lines for each time the TestCase executes; one for each Request TestStep and one at the end for the entire TestCase:

Selecting this option also allows us to use the “Source ID” feature of the Statistics Component to see statistics individually for each Request TestStep as shown in the following setup:

As you can see they are all performing similarly. Please note that you will need to run the LoadTest in loadUI to get the "Source ID" combo box on the Statistics component to contain the different TestSteps available

Getting Error information

The soapUI Runner also adds a dedicated output terminal for reporting TestCase errors during execution (second from the right). Connect this to a TableLog component to see all errors and log them to a file if desired. If we add a Fixed-Rate Generator to our setup and increase its load to around 350 req/sec we will start getting errors like this (since the MockService isn’t thread-safe):

(Here you can see the individual errors being logged to the TableLog for further analysis)

If you want these errors to count as global failures in your tests (see Validating Results), the settings dialog has a “Raise Assertion on Error” option that will do this for you (checked by default). Using this you could limit your loadUI Test to stop after a certain number of soapUI TestCase executions have failed (by setting the corresponding Failures limit):

Here we have set the limit to 100, only 14 failures to go before the test stops (and fails).

Parameterizing your TestCase

The soapUI Runner component settings dialog allows you to set (and override) any of the TestCase Properties defined in soapUI in a dedicated "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:
   
   

Outputting Custom Property Values

Correspondingly you might want to be able to post-process some results obtained by the soapUI TestCase with a (custom) component in loadUI. In that case you would:

1. Define a property for this value in your soapUI TestCase (we’ll use the SessionID as an example):
   
   
   
   
   
2. Write some desired value to this property during the execution of your TestCase, for example with a property transfer:
   
   
   
   
   
3. Check the “Add TestCase Properties to Result Message” option in the settings dialog:
   
   

Now each result message will contain the corresponding property and its value as can be seen in the following setup where we have connected the result to a TableLog:

Next Step could be to create a Custom Component that handles result messages in some way based on the value of the custom property.

Synchronizing with soapUI

The “Open in soapUI” button will open the corresponding TestCase in a running instance of soapUI; if the containing soapUI Project is not available in the current soapUI Workspace it will be imported automatically. After making any changes in soapUI make sure to save these as loadUI will automatically reload changed soapUI projects every 5 seconds. Alternatively you can use the “Synchronize with loadUI” button in the soapUI TestCase Toolbar:

This will save the project and transfer control back to loadUI so you can pick up where you left off!