08 May 2007 - 1.7.1 home user-guide eclipse jbossws intellij netbeans maven 1.X/2.X PDF files forums bugs sourceforge






Vote for soapUI at the WSJ Readers' Choice awards in the

'Best Web Services Utility' and

'Best Web Services Testing Tool'

categories

TestCases

soapUI supports functional testing of web services by providing a TestCase metaphor where a number of TestSteps can be executed in sequence. Also, an arbitrary number of LoadTests can be associated with a TestCase for running the TestCase under different load scenarios.

Each TestStep in a TestCase exposes a number of properties which can be read/written/modified by other TestSteps, for example a Groovy Script step can read the "response" property of a Request Step and take some action depending on its value, see Property Expansion for details and examples.

TestStep Types

Currently the following types of steps are available;

Step TypeShort Description
RequestSends a SOAP request and allows the response to be validated using a variety of assertions.
Property TransferUsed for transferring property values between two test steps.
Groovy ScriptRuns a Groovy script that can do more or less "anything".
PropertiesUsed for defining global properties that can be read from an external source.
Conditional GotoAllows any number of conditional jumps in the testcase execution path. Conditions are specified as xpath expression and applied to the previous request steps response.
Delay StepPauses a TestCase run for the specified number of milliseconds
DataSource StepReads external data to be used as input to requests, etc - soapUI pro only
DataSourceLoop StepUsed together with a DataSource to specify looping for external data rows - soapUI pro only
MockResponse StepWaits/Listens for an incoming SOAP Request that can be validated and return a mock response - soapUI pro only

TestCase Actions

The following actions are available from the TestCase nodes' right-button menu:
  • Open TestCase Editor - opens the TestCase Editor described below
  • New LoadTest - prompts to create a new LoadTest for the TestCase
  • Clone TestCase - prompts to clone the entire TestCase, optionally into another TestSuite
  • Clear - prompts to remove all TestSteps from the TestCase
  • Options - show the TestCase Options dialog described below
  • New Step - adds a new TestStep to the TestCase
  • Rename - prompts to rename the TestCase
  • Remove - prompts to remove the TestCase from its TestSuite
  • Online Help - Displays this page in an external browser

The TestCase Editor

Double-clicking a TestCase node in the navigator or selecting its Open TestCase Editor menu option opens the TestCase editor/runner. If the TestCase is currently being load-tested the editor will be mostly disabled.

The editor is divided into the following 4 parts (from top to bottom):

1. A toolbar at the top containing the following actions (from left to right)
  • Run TestCase - runs the testcase (see below)
  • Cancel TestCase - cancels a running TestCase
  • Run Continuously - toggles if the TestCase is to be run continuously When selected, the TestCase will run repeatedly until cancelled with the Cancel TestCase button
  • TestCase Credentials - prompts to set the credentials to be used by all requests in the TestCase. This is useful if you want to run your tests with different credentials
  • TestCase Endpoint - prompts to set the endpoint to be used by all requests in the TestCase. This is useful if you want to run your tests against different servers, etc. The available URL's are collected from the test-requests' operations' interfaces. The selected endpoint is assigned to each request in the TestCase
  • TestCase Options - opens the TestCase Options dialog described below
  • Online Help - Displays this page in an external browser

2. A progress indicator showing how far a TestCase run has proceeded

3. A "TestSteps" tab showing the TestSteps that this TestCase contains. Double-clicking an item in the list opens that items editor view. Right-clicking an item shows a popup-menu with the following actions:

  • Open Editor - opens the associated TestStep editor (if available)
  • Rename - prompts to rename the selected step
  • Delete - prompts to delete the selected step
  • Clone - prompts to clone the selected step and to which TestCase the step should be cloned. The cloned step will be added at the end of the selected TestCase
  • Insert Step -> - shows a list of insertable test-steps at the current position
  • Move down - moves the selected step down one position in the list (this can also be performed with Ctrl-Down)
  • Move up - moves the selected step up one position in the list (this can also be performed with Ctrl-Up)

4. A "TestLog" list showing log-information when running the TestCase:

  • When the TestCase started
  • An entry for each executed TestStep specifying how long it took
  • Optional errors and/or messages reported by each TestStep
  • How long the TestCase took

The "Description" tab contains a single text area for arbitrary documentation for this TestCase

Double-clicking a TestSteps' entry in the log opens a TestStep result viewer for that step if available and as described on each TestStep documentation page (for example the Request Result Viewer).

TestCase Options

Selecting TestCase Options from either a TestCase nodes popup menu in the navigator or from the TestCase Editors toolbar opens a dialog with the following options.

  • Search Properties : When looking för property values without step-specifications (see Property Expansion), check all steps before the current one for the named property.
  • Maintain HTTP Session : Controls if a HTTP Session is to maintained for all requests in the TestCase. Selecting this will reuse cookies, authentication headers, etc
  • Fail on error : Controls if the TestCase is to be cancelled when a TestStep fails with an error, (for example if a contained RequestStep has failed assertions)
  • Fail TestCase if it has failed TestSteps : Controls if the TestCase is to fail if it the "Fail on error" option is not selected and the TestCase ends with one or more TestStep.
  • Discard OK Results : Long-running testcases will eventually consume substantial amount of memory since all teststep results are internally cached for later viewing/reporting. Checking this option will make soapUI only save non-successfull teststep results which will save substantial amounts of memory.
  • Socket timeout : The timeout (in milliseconds) to be used for all requests in the TestCase


Next: Working with TestRequests