0.1. What it is
An assertion is a logic constraint on a value, e.g. that the time a request takes may not exceed 100ms. Any time that constraint doesn't hold, an Assertion Failure will be created. This means that you can:
- See Assertion Failures in the Statistic Tab. Thus, they can also be compared, reported and styled and are auto-saved together with the test run.
- See Assertion Failures in the Event Log, together with information such as the Assertion's name and the value that failed. All this is auto-saved with the rest of the test run.
- Set a Failure Limit for your project which, when reached, will stop the project.
0.2. Why you need it
One great thing about LoadUI is that it records and saves all statistic data from all VU Scenarios, Components and Server Monitors. However, you shouldn't have to spend your time browsing through hours of chart lines for extraordinary values — instead let Assertions handle that for you!
Assertions are perfect for verifying that your service/application passes the SLA (Service Level Agreement). For example, you can assert that:
0.3. The difference to SoapUI assertions
As you may know, SoapUI also has the concept of assertions, and those assertions can be evaluated by the SoapUI Runner. However, they will not appear in the LoadUI user interface. Here's how we see it:
- SoapUI assertions
- Functional assertions - used to assert that a request is functionally correct. E.g:
- Response is valid SOAP
- Response contains an element called customerId.
- LoadUI assertions
- Performance assertions - used to assert key performance values from the user or server point of view. E.g:
- A request never takes more than 2 seconds.
- The database cache miss rate may not exceed 25% for more than 10 seconds.