Structuring and Running Tests

This page contains information on standalone ReadyAPI that has been replaced with ReadyAPI.
To try the new functionality, feel free to download a ReadyAPI trial from our website.

1. Test Structure

SoapUI structures functional tests into three levels; TestSuites, TestCases and TestSteps.

1. A TestSuite is a collection of TestCases that can be used for grouping functional tests into logical units. Any number of TestSuites can be created inside a ReadyAPIject to support massive testing scenarios.
2. A TestCase is a collection of TestSteps that are assembled to test some specific aspect of your service(s). You can add any number of TestCases to a containing TestSuite and even modularize them to call each other for complex testing scenarios.
3. TestSteps are the "building blocks" of functional tests in soapUI. They are added to a TestCase and used control the flow of execution and validate the functionality of the service(s) to be tested.

Lets look at these in a little more detail:

TestSuites (as mentioned above) are created at the project level for grouping TestCases into logical units. For example if you have a banking system to test you might have one TestSuite for account-related TestCases and another for TestCases related to payments. Your project can contain any number of TestSuites and you can see and execute them all (in sequence or parallel) from the Project TestSuites tab:

Create new TestSuites either from the project popup menu ("New TestSuite") or with the corresponding button on top of the list of TestSuites shown above.

A TestSuite can in turn contain any number of TestCases which can be executed either in sequence or parallell from the TestSuite window;

Creating TestCases is performed in the same manner as creating TestSuites; either from the containing TestSuite popup menu ("New TestCase") or with the corresponding button on top of the TestCase List. A TestCase contains an arbitrary number of TestSteps which are configured to validate the functionality of your target service(s), for example a TestCase in the TestSuite for payments mentioned above might validate a certain type of payment by first performing it and then checking the contents of the database for the updated data. Opening a TestCase reveals a similar view to the above containing a list of contained TestSteps together with related actions;

When a TestCase is executed, the contained TestSteps are run in the displayed order (branching or looping as configured via dedicated TestSteps or scripts).

2. Test Execution

All the above views have a toolbar at the top with buttons executing contained test items.

In the case of TestSuites and TestCases these can be executed either in sequence or parallell, as configured with the corresponding toolbar buttons.

The execution order of TestSteps in a TestCase is always in the order they are displayed, branching/looping can be achieved with dedicated teststeps or scripts.

The progress bar immediately under the toolbar shows current execution status and is colored either red or green depending on the test outcome.

Since the exact number of execution steps can not be known in advance (due to scripting possibilities, etc), the progress bar might not always show a number/value that is in line with the number of steps/items executed.

3. Test Output

All above views also contain an execution log at the bottom that shows ongoing information on executed teststeps and their status.

Items in this list can be double-clicked to show more details on the actual execution, for example if we double click the entry for the [Test Request: logout] TestStep above (last in the log), we will get the following window showing the actual messages sent and received, together with related properties and assertion results:

Depending on the type of TestStep different information is shown. Also, if the underlying data has been discarded from memory (for example because of the "Discard OK Results" setting in the TestCase Options dialog), it will not be available for viewing. Read more on the intrinsics of TestCase Execution.

4. Reporting

ReadyAPI also adds a "Create Report" button to the top toolbar, allowing you to export the results of the current execution to a nicely formatted document, for example if we create the default TestSuite report for the above TestSuite execution we get the following PDF:

Read more on reporting in SoapUI in the Reporting Section.