Understanding the Performance Assertions in SoapUI

Let us understand Performance Assertions in SoapUI. In SoapUI the possibilities for asserting the performance and underlying functionality are many. Finding the right mix is not easy. Since LoadTest results are extremely dependent on external factors, networks, disk activity, database backups, etc. Therefore, we recommend creating assertions as a “safety net” for your LoadTest to detect.

For example, if you have a step that usually takes around 300ms and you want to automate the execution of the LoadTest, you could create a “TestStep Average” assertion at around 900ms, which gives a lot of breathing space. Alternatively, you could set the level rather low (400ms) but the minimum-errors setting to a rather high value (100).

Accessing Assertions

Access the assertions for your LoadTest from the Assertions tab at the bottom of the LoadTest window:

Here you can add and configure as many assertions using the toolbar button. Further, add the assertion by right-clicking in the Statistics table. Then, select the desired assertion. After this, double-clicking an assertion opens the corresponding configuration-panel. Also, this allows you to set its configuration as desired.

Available Assertions

As you can see on the above screenshot SoapUI provides 5 assertions for validating the ongoing performance of your services. These all have the following configuration settings in common:

• Firstly, Name – the name of the LoadTest Assertion.
• Secondly, Minimum Requests – this is the minimum number the target testStep or testCase must have been executed before the assertion is applied.
• Subsequently, Max Errors- this is the maximum number of failures that are allowed before the LoadTest fails.
• Lastly, TestStep – the target TestStep, all TestSteps or TestCase the assertion should be applied to.

The available assertions then have specific configuration options as follows:

• First of all, Step Average – asserts that the average value of a TestStep or the entire TestCase doesn’t exceed the specified limit.
• Secondly, Step TPS asserts the TPS (transaction per second) value for the corresponding TestStep or TestCase.
• Subsequently, Step Maximum – Asserts the max value for the corresponding TestStep or TestCase, going over the specified “Max Time” limit fails the assertion.
• Further, Step Status – check that the underlying execution status of the TestStep or TestCase is successful, otherwise the assertion fails.
• Last but not least, Max Errors – check that the number of failures for the corresponding TestStep or TestCase does not exceed the configured “Max Absolute Errors” and/or “Max Relative Errors” value.

Viewing Assertion Errors

When running your LoadTest, assertion failures are shown in the LoadTest Log as they occur.

The toolbar has combo-boxes for filtering which message to display and also contains a button for exporting the log to a comma-separated file.

Double-clicking an entry opens the corresponding result for the underlying TestStep, allowing you to “debug” the failed message exchange, for example double-clicking the first error in the log above shows.

Make your resume stand out and become a Certified SoapUI Testing Professional. Try free practice tests here!

A great career is just a certification away. So, practice and validate your skills to become a Certified SoapUI Testing Professional.