Runs a soapUI TestCase and outputs all its TestCase Properties. This gives you the power and flexibility of SoapUI (SOAP, REST, AMF, JDBC, Sessions, Cookies, Scripting, DataSources etc.) to LoadUI.
Learn how to use it in Getting Started with SoapUI Integration.
0.1. Main view
||Trigger Input||Connect a Generator here to control the runner execution
|Project||The SoapUI project containing the TestCase to Execute. Click here to change the SoapUI project file or the selected testSuite/testCase|
|TestSuite||The TestSuite to use for the Execution (use the project menu to change)|
|TestCase||The SoapUI TestCase to execute (use the project menu to change)|
|Open in SoapUI
||Opens the TestCase in SoapUI
||Runs the test once|
|Abort Running TestCases
||Aborts all the running TestCases that have not yet completed|
||The number of requests that have been started|
||The number of currently running samples
||The number of samples that have completed successfully
||The number of queued samples
||The number of samples discarded due to the queue being full
||The number of failed samples
||Resets the display counters
||The result of each run sample
|Requests Currently Running
||Outputs the number of samples currently running concurrently|
||Outputs the result of failed samples. Very useful for debugging when connected to a Table Log.
0.2. Compact View
||Status Display||Same as for the full view|
||Assertion on error||Raises a failed assertion upon error
|Output level||The level of outputting result messages. This allows for statistics per TestStep, instead of just per TestCase.|
|soapUI settings||The location of the SoapUI settings file to use|
|Project password||Allows you to provide a password if the SoapUI project is password-protected|
|Add TestCase Properties to Result Message||Adds the SoapUI TestCase Properties to the result message, at the end of each run|
|Close connections between each request||Forces the runner to close all network connections between each request.|
|Disable all SoapUI assertions||Disables all SoapUI assertions (this will not affect the SoapUI Project file).|
|Make all datasources shared
||If your SoapUI project uses data-sources, enabling this option will cause LoadUI to use a single data-source for all VUs instead of using separate ones. This is similar to enabling the "Shared" option in SoapUI. In most cases, you should keep this option checked for load tests.|
||TestCase Properties||Allows you to set the SoapUI TestCase Properties before each run.
||Max concurrent requests||The maximum number of concurrent requests the SoapUI Runner will allow. If the number of concurrent requests gets past this value, which can occur if the server under test cannot keep up with the load generated, LoadUI will start queuing requests.|
||Max queue size||The maximum number of requests to be queued (see previous item). If the queue gets filled, LoadUI will start discarding requests.
It's important to note that each Virtual User that passes a soapUI Runner gets its own isolated copy of the SoapUI TestCase, but actually shares the rest of the soapUI Project with all other VU's running a SoapUI TestCase belonging to the same SoapUI Project. This means that you should avoid writing to TestSuite or Project Properties, as they are shared between all VU's and will likely cause a ConcurrentModificationException, if not synchronized.
0.8. Debugging Failures
This topic is covered here.
The soapUI Runner uses the proxy settings defined by the SoapUI settings file (see the General tab in the soapUI Runner's Settings).
0.10. Common for all Runners
Advanced topics that are common for all Runner components can be found here.