Soap UI

SoapUI
user manual

Date: Reference:

EJIE S.A.
Mediterranean, 3 Tel. 945 01 73 00 Fax. 945 01 73 01
01010 Vitoria-Gasteiz
Posta-kutxatila / Section: 809
01080 Vitoria-Gasteiz
www.ejie.is

This document is the property of EJIE, S. A. and its content is confidential. This document may not be
reproduced, in whole or in part, or shown to others, or used for purposes other than those who have led
to their delivery, without the prior written permission of EJIE, S.A. . In the case of be delivered under a
contract, their use shall be limited to what has been expressly authorized in the contract. EJIE, S. A. shall
not be liable for any errors or omissions in the editing of the document.

Documentation Control
document title: SoapUI. User Manual

Historical versions of
code: Version: Date: Summary changes:

1.1 20/05/2009 First Version.

2.0 26/3/2010 Change to SoapUI Version 3.5

2.1 07/27/2010 Added glossary and structuring document

2.2 26/04/2011 Added usage guide Basic Profile

changes since the last version
added glossary and structuring document

Control of
Responsible dissemination: Ander Martinez
approved by: Ander Martinez
Signature: Date:
Distribution:

file references
Author: Consulting in areas of knowledge
file name: SoapUI. User Manual v2.2.doc
Location:

SoapUI. User Manual 2/74

Content

Chapter/section Page

1 Introduction 5
2 5
3 Basics SoapUI 5
3.1 5
3.2 prerequisite Glossary of terms 6
3.3 first steps. 6
3.4 User Interface 9
3.4.1 . The browser 10
3.4.2 . Main Menu 11
3.4.3 . Tabs 14
3.5 log preferences 15
3.5.1 . HTTP Settings 17
3.5.2 . Proxy Settings 18
3.5.3 . SSL Settings 19
3.5.4 . WSDL Settings 21
3.5.5 . UI Settings 24
3.5.6 . Editor Settings 25
3.5.7 . Integrated Tools 27
3.5.8 . WSI Settings 28
3.5.9 . Global Properties
functional tests 30 4 30
31 4.1 Introduction
4.2 TestSuites 36
4.3 test cases 40
4.3.1 . Test Requests 47
4.3.2 . Property transfers 59


4.3.3 . Conditional Gotos 62
4.3.4 . Properties Step 63
4.3.5 . Delay Step 64
4.3.6 . Run test cases 65
4.3.7 . Tests (JMS HermesJMS) 67
4.3.8 . Test of interoperability. WS-I Basic Profile 71
5 Integration of tools 73


1 Introduction

In this manual describes the various aspects that must be known to the user on the tool SoapUI 3.5
2 Basics

SoapUI is a powerful tool designed to assist in the development and testing of applications. Allows you
to perform the testing of the web, with dozens of features including a simple interface easy and
intuitive, allows the use of methods of capture and replay, being a tool of great help in the testing of
load of great scope, detailed reports, graphs etc. .!

SoapUI brings embedded Microsoft's Internet Explorer browser, allowing the monitoring and control of
the actions that are produced in it
This allows:
- capture screenshots of the parameters of the cgi, the pages and the time nested framesets.
- Modify catches them and be able to run at any time without the need for return run.
- Record catches such as scripts and sharing within the work environment.
- Capture the statistics of operation while a test is running.
- Test for regression that the entire areas of the complex sites on the web in a single click.

For additional information about the product access to your web page:

http://www.soapui.org/
3

Prerequisites

SoapUI SoapUI 3.1 is a simple tool for new users, but it is necessary to have a series of prior knowledge
in order to get the most out of the functionality that SoapUI provides. It is recommended, although not
strictly necessary, that the user has basic knowledge of the following technologies:

WSDL: basic concepts, such as services, ports, "bindings", port types, related to the XML schemas

SOAP: basic concepts related to WSDL ( "bindings", etc), different types of encoding (soap-encoded /
literal) and message types (document / rpc).

XML: Both knowledge of the XML itself as of related technologies, such as xpath, XML Schema,
namespaces, etc.


3.2 Glossary of terms

test case: SoapUI supports functional testing of Web services by providing a test case with a number of
steps that can be executed in sequence. It is analogous to a "use case" of the business.

TestSuite: Serves as a container for an arbitrary number of test cases. When you run a TestSuite,
including test cases can be run both in sequence and in parallel
TesStep: is called to each step that can be defined in a "use case" can be, http requests, SOAP requests,
groovy scripts etc. ..
Groovy: alternative dynamic language based on the Java Platform
assertions: conditions that are evaluated after obtaining the response and that its compliance indicates
that a correct operation
MockService: serves us to mimic the behavior of the real services in a controlled way.
They are used for testing to other services that await a response from a WS in particular for their
methods.

WS-I: Acronym for Web Service Interoperation. http://www.ws-i.org This organization has set some
rules to indicate how they should be used the existing standards
WSS: Acronym for Web Service Security. Provides security at the service
3.3 first steps.

The following describes the steps needed to create a new web service project in SoapUI.

1. Launch SoapUI

SoapUI 1 start Menu
2. Create a new project. For this reason we have two options, right click on the node "Projects" on your
browser and on the shortcut menu click on the option "new WSDL Project" or menu "File" - > "new
WSDL Project"


2 Creating a new project
NOTE: It is possible that either the URL of invocation to the web service methods, such as the URL to
access the WSDL require certificate-based authentication. If we find ourselves in that case, we must
adapt the SSL configuration for the SoapUI wizard of new project ends satisfactorily.

3. We follow the wizard for the creation of new project, providing data that will tell us.

The "Project Name" we put the name you want to assign within the own work area (workspace) of the
SoapUI.
"Initial WSDL" indicate the URL to the file descriptor of the web service. It is possible both indicate a
file of the local file system as indicate a remote URL. For example:
https://www.dgsfp.mineco.es/Pruebas/Upload.Asmx?wsdl The checkbox 'Create Requests" if it is
activated, it tells you how to SoapUI that must autogenerate a sample request form for each method
published by the web service.
The checkbox "Create Project File" if it is enabled will make us more open a screen in the wizard to
indicate the name of the file where you will save the definition of the project. This step can be
performed a posteriori from the menus of the soapUI.


3 Window new project creation wizard

4 selection window of the name and location of the file of project definition

5 Window load WSDL
4. Once the project is created. We can explore the different methods that exposes, as well as launch
requests for test, once we finalize the parameters of that in each case requires the web service.


3.4 user interface

SoapUI is a typical desktop application, which has a user interface with structure similar to that available
in the current IDEs, such as can be Eclipse, IDEA, or NetBeans. The majority of actions are shortcuts or
tooltips.

The soapUI window is divided into the following views:

1. Left Side: Browser projects.

2. Right Side: Region where open editors and viewers.

3. Bottom left: the properties pane shows information of the selected object in the browser.

4. Bottom right: Shows different log messages of the soapUI.


3.4.1 . The browser
The following objects are displayed in the dependency tree browser:
Projects node: the workspace of soapUI.
or Project node(s): one per project in the workspace.
Interface node(s): one for each interface in the project.
Operation node(s): one for each operation in the interface
or Request node(s): for each response created by an operation.
Node(s) TestSuite: for each TestSuit in the project.
Node(s) test cases: for each test case in each TestSuit
or Node TestSteps: contains the testcases node(s) TestStep: test cases for each step, along with a
colored icon indicating the status of this step or Node LoadTest directory: contains the testcases'//
before tb contained the same but now is at a premium, I do not know whether or not to change, watch
it.
LoadTest directory Node: for any test search content in the test case.
Node(s) MockService: for each project in the MockService Node(s) MockOperation: MockOperation for
each in the MockService.
or node(s) MockResponse: by each MockResponse content in a MockOperation.


the dependency tree can be navigated using standard actions of the keyboard. An associated object in
the control panel can be opened by double-clicking or selecting it and pressing enter.

3.4.2 . Main Menu
The majority of shares in the soapUI are implemented through the buttons on the toolbar or by clicking
with the right mouse button. The following options are available in the main menu:

File menu (file menu)
or New WSDL Project WSDL): Start the new project wizard
or WSDL Import Project (Import project): Allows you to select the configuration file for a project of
existing SoapUI. The project will be added to the existing workspace
or Import Remote Project (Import project remote): Allows you to indicate the URL of a remote project.
The project will be added to the existing workspace
or Save All Projects (Save all projects): Saves the changes to all the open projects in the workspace,
or Open All Closed Projects (Open all closed projects) - Open all closed projects in the workspace
or Close All Open Projects (close all open projects): Closes all open projects in the workspace. Prompts
for confirmation
or Rename): Renames the workspace. The name is displayed in the root node of the browser
or New Workspace (New Workspace): Allows you to define a new workspace
or Switch Workspace (Change workspace): Allows you to choose the workspace that we want to open
or Preferences): sets the global preferences for soapUI.
or Save Preferences (Save Preferences): Saves the current global settings
or Import Preferences (Import preferences): Import global settings from another location (for example a
previous installation of SoapUI). After the search, it is necessary to restart SoapUI to activate all the
configurations
or Recent): contains submenus with the editors, projects and workspaces more recently accessed
or Exit (exit): to exit the soapUI.
or Exit without saving save): to exit the SoapUI without saving
or Online Help (online help): launches the official website of documentation in an external browser.


6 "File" menu Tools Menu (tools Menu) Contains actions for invoking external tools. This integration is
described in the section "Error! Is not the source of the reference. ".


7 menu "Tools"
menu Desktop (desktop Menu) Shows actions related to the current menu

or Switch Windows (Exchange windows): opens a window to switch to another open editor
or Maximize Desktop (Maximize escrtorio): hides/shows the browser and tabs in log
or Close Current (Closing current): closes the active pane of the desktop
or Close All (close all): closes all open views of the desktop
or Closes Others (Close other): closes all open views of the desktop minus the that is active at the
moment.

Menu 8 "Desktop"
Help Menu (help menu)
or User Guide): open the user guide of soapUI.


or Getting Started (quick start): Opens the documents of the quick start soapUI or System Properties):
opens a list of the properties of the system defined.

Window 9 "System Properties"
or soapUI.org: opens the home page of the program or About soapUI http://www.soapui.org SoapUI
(On SoapUI): Displays version information.

10 "Help" menu

3.4.3 .

SoapUI log Tabs. User Manual 14/74

By pressing the right mouse button in the workspace of the soapUI, one can observe a certain number of
windows in log, each displaying on the screen the corresponding output.

11 Tab of log
by pressing right mouse button on a tab in log displays a shortcut menu with options for cleaning the
log, enabled or disable it, copy the selected lines to clipboard, etc. it is also possible to export the entries
in the log to a file. Another option is to limit the maximum number of lines available (by default 1000),
and that when you exceed this limit, the oldest lines will be wiped off the log.

The various tabs of log available with the following:

SoapUI log: general notifications and messages.
Http log - Displays the data sent and received by http. Disabled during stress tests.
Jetty log: related to health notifications from the mock-service.
Script log: The scripts are launching these messages using the log object available (it is disabled during
the tests of stress but can be enabled from /File/Preferencess/UI settings).
Error log: a log with information on the errors that occurred during the execution. Do not have to be
only soapUI errors, but that can be produced by any other service or server that is not available.
Memory Log: Displays information about the memory usage.

SoapUI using log4j to create the logs, it is possible to adapt the configuration of log4j, renaming the
log4j.xml file, calling him "soapui-log4j.xml" and later by moving it to the bin directory of soapUI.

3.5

These preferences are the tabs that are displayed when you select the option "Preferences" in the menu
"File".

HTTP Settings Tab Description Edit options related to HTTP
Edit the http address of the proxy and the proxy authentication settings to use


WSDL Settings Edit options related to WSDL
UI Settings Edit options related to UI Editor Settings Edit options related to the editor
Tools Edit routes of the integrated tools.
Edit validation options related to WSI Settings "WS-I Basic Profile"
Global Properties manage global properties.
Coverage Options Settings related to the coverage

the menu item "File" is an action called "Import preferences" that allows you to import the global
preferences from an XML file

12 Import global preferences

SoapUI. User Manual 16/74 (reference for a

3.5.1 . HTTP Settings
below describes the fields of configurable HTTP:

Configuration Description
changes the user agent header http. If there is no User-Agent header no specified will be used the
HttpClient header by default.
Disable the HTTP Keep-Alives asking that the closure of the close connections after http connection after
each request. This request can have a negative effect on the performance of the application, but we will
get some more realistic results.
Sends authentication headers with each request without having received an authentication challenge.
This is a danger of Preemtively security authentication, but improves performance since it only requires
a request for authentication instead of two.
Include request in time includes the time it took to write the petition in the computation of time taken.
Include response in time includes the time it took to read the body of the response taken in the
computation of time.
Tells SoapUI that you must not perform a "URL encode" endopoints Preencoded endpoints for the web
services.
Socket timeout time maximum for the http response (in milliseconds).
Maximum number of bytes to read from a response (0= Max Response Size unlimited)
Specifies the maximum number of connections to a host Max Connections Per Host specific. Increase
this value if you're running LoadTests with more than 500 threads in a host.
Increase this value if you're running LoadTests Max Total Connections with more than 2000 threads.
The local address to use when sending requests, you can be overwritten to request level (with the
corresponding address Bind property) and also at the system level by setting the variable
soapui.bind.address
maintains the mockEngine running even when you stop the MockService. You get the best of times
Leave MockEngine start for new services mock and in addition, you get 404 errors when you call a mock
service stopped, in place of a connection failure.


13 HTTP Configuration by default
3.5.2 . Proxy Settings
below describes the configuration parameters for proxy:

Option Description
the proxy hostname indicate the http proxy to use
proxy port indicate the port of the http proxy to use
user name of the user name to authenticate to the proxy proxy user password of the user password for
the proxy autenticase proxy in the

a list of hosts to exclude separated by a comma. Example:
Excluded "00:8080, myserver.com" does not use a proxy from 127.0.0.1 on port 8080 and myserver in
any port.

14 Proxy Settings by default
3.5.3 . SSL Settings
below describes the configuration parameters for SSL:

keystore Path to keystore with client certificates.


keystore password password of the keystore.
Mock Enable SSL enables support for SSL in MockServices
Mock Port Port for SSL connections
Mock KeyStore Keystore File to use for SSL certificates
Mock Password Password of the keystore.
Mock Key Password Password by default for the keys.
Mock TrustStore truststore to use (optional).
Mock TrustStore Password Password for the truststore.


15 Example SSL Configuration
3.5.4 . WSDL Settings

below describes the configuration parameters for WSDL:

Configuration
Cache Description WSDLs Enables/disables the cache of WSDLs.
Generates sample values in the requests if you have Sample Values of the schema.


generates comments with information of the type in new Type Comment requests always include
optional elements in the requests include Optional generated.
Format the response messages in the editor of Pretty Print responses.
Generates part-elements in the request message to the Attachment mime Parts-attachments of the RPC
messages (required by some ws-stacks).
Not the valid content-type of a mime-attachment against the Not Content-Type Validation type
specified in the SOAP-Binding
specifies the directory that contains the schema files ( .xsd) that should be added automatically Schema
directory when parseen or validate wsdls or requests. Change the value of this directory requires
restarting the program.
Tells soapUI that name interfaces imported with the name corresponding to its soap/http binding, and
not with its portType. This ensures that the WSDLs that Name with Binding contain bindings for both
soap 1.1 and soap 1.2 , will have unique names during import. Default value is "true".
It is a list of types and global elements of XML-Schema, Excluded Types of the form name@namespace,
that will be used when generating requests and replies shows.
Select this option to not allow redefinitions of Strict Schema Types schema types in the XSDs
included/imported from a WSDL specified.
It is the minimum size of a message to be compressed and preserve the space. The compression is
accomplished by using gzip and the result is encoded in base64 file compression in the limit of the
project. For large requests, you can save more than 90% of space in the file, but requests are no longer
understandable and comparable.
Formats the project files when they are saved.
Makes it easier to work with a control system Project Files Pretty Print versions (SCM). This option
increases the size of the project files. Also will be formatted cache files for WSDL/XSD

SoapUI. User Manual

16 22/74 configuration by default WSDL

SoapUI. User Manual

23/74

3.5.5 . UI Settings
below describes the configuration parameters relating to the user interface:

closes all the projects at boot time to improve the Close projects starting time and minimizes the
memory consumption.
Sort projects sorts the projects in alphabetical order in the browser.
Sorts the requests in alphabetical order in the Sort browser requests.
Sorts the TestSuites in alphabetical order in the Sort browser TestSuites.
Backup folder indicates the folder where to save the backups.
Indicates the maximum time interval (in minutes) for a project without running the autosave. If this to 0,
soapUI will save autosave Interval automatically all the projects that do not have tests running on the
specified interval.
Indicates the design of the desktop to use. Change in the type of desktop configuration will be applied
when we close the Preferences window.
Disables the use of the look & feel by default, and uses the native L&F specified by the JRE.
The log keeps active during the groovy LoadTests, do not disable the log of Groovy which can be used for
debugear etc.
Show Log tab Expands tabs of log when you start the soapUI.

SoapUI. User Manual

17 24/74 Configuration UI

3.5.6 . Editor Settings
below describes the configuration parameters relating to the editor:

the editor Configuration Source

SoapUI. User Manual

Description
Specifies the font to use for the XML editor
Pressing this button will open a dialog where you can select the typeface and size desired.
25/74

Number of lines in the
number of lines XML Groovy
Disable auto-resizing
of the View tab request
Validate requests

SoapUI. User Manual

shows the default number of lines in all XML editors (Alt+L in the editors for this option is changed).
By default shows the line numbers in all editors Groovy (Alt+L in the editors changed this option).
Disables the automatic resizing of editors in the requests/responses.
Puts the design of the tab as default layout for the editors of requests/responses.
Enables the automatic validation of requests before they are submitted from a editor of requests. Select
this option is the same as using Alt-V in the editor.
26/74

18 Configuration editor by default
3.5.7 . Integrated Tools

here are the paths to the external tools that we want to integrate in SoapUI.

SoapUI. User Manual were 27/74 hydrocephalic newborn infants operated

19 Configuration of paths of external tools
3.5.8 . WSI Settings
These settings are related to the validation WS-I.

Verbose Description Settings Sets the verbose output of the tool WS-I
provides that results will display in the report results generated type.


Failure Message includes the fault messages defined in the report
includes a description of each test-assertion in the Assertion Description report.
Path to the installation of the testing tools WS- Location I.
Displays the log window when running Show Log tools WS-I.
If selected, the reports generated HTML Output Folder will be exported automatically to this folder.


20 Setting of WS-I by default
3.5.9 . Global Properties
manages the global properties, if a property file SoapUI has been specified, the contents of these files
are available on the table. The option "Enable overwriting" can make the global properties always
overwritten other properties referenced.

21 Configuration of global properties by default

4 functional tests


SoapUI supports functional testing of Web services by providing a test case with a number of steps that
can be executed in sequence. At present, there are six types of steps that provide many possibilities for
test. The test cases are organized in a group of tests and in the same project you can create multiple
groups of tests.

The functional tests, in soapUI, can be used for a variety of purposes:

test drive: validates that each operation of the Web service works as indicated compatibility testing:
validates that the result returned by the Web service is compatible with its definition Test of
processes: valid that a sequence of invocations of Web Services is running a business process testing
required guided by data: valid than any of the above works as a requirement of input data from
external sources (for example, a database or another Web service)
4.1 Introduction


In soapUI, the functional tests can be used to validate functional requirements, both to invoke the Web
Services themselves ( = "unit tests") as a sequence of requests (= " integration tests" ). In addition, it is
possible to add logic to the tests using Groovy scripts, allowing, for example, to interact with a database
or perform a complex flow of testing.

Create a Test Case from a request
once you have configured some requests, you can create a test case to verify its behavior:

Selects the second button on the toolbar in the editing window of request.
"Add this request to a test-case") If there is no group of Test/test case in your draft, soapUI will open a
window to ask you the names of these, you can specify something like "IMSERSO TestSuite" and
"IMSERSO test case" SoapUI will open a window to enter the name of your test request, for example
"Step 1 - AppendRequest".
The corresponding TestSuite/test cases are created and the request will be added as test cases, which
is a copy of the original petition (in this way, you can continue to use it without modifying the test
request) A editor test requests almost identical to the standard, opens with the new test cases; differs
by adding assertions of functionality.


22 Example of running a test case

add assertions
assertions are conditions that are evaluated after obtaining the response and that its compliance
indicates that a correct operation:

Selects the second button on the toolbar in the edit window of the petition ( "Add an assertion to this
test request" ).
Begins by adding an assertion in accordance of schema, which shall be responsible for verifying that
the petition is compatible with the associations defined in the schema WSDL. The assertion is displayed
in the list of assertions below of the editors of request/response. (See bottom picture) The request is
sent by clicking on the green button located at the top left.
SoapUI will launch the request and validate the answer. If all goes well the petition-test should be
presented with a green background in the navigation tree.


23 Add assertion's request support for a test case

24 sending a request

25 Summary of the result assertions of the

TestSuite assertions Launch


once they are all the test cases with their assertions, it is possible to launch all the test case, to this:

Double-clicking on the node in the test case in the left box of navigation, which will open the Launcher
of the test case.
Launches all the tests by clicking on the green arrow labeled "Run this test case", SoapUI will send all
the requests for test and validate them accordingly. The result will be displayed during the execution.

Launches your tests from the command line using one of the command-line tools available.

IMSERSO test case results 26

SoapUI. User Manual

4.2 35/74 TestSuites

a TestSuite serves as a container for an arbitrary number of test cases. When you run a TestSuite,
including test cases can be run both in sequence and in parallel, as described below.

Create TestSuites
Select the option "Generate TestSuite" of the menu interface to open a window and generate a full
TestSuite to the selected interface. The dialog box contains the following options:

27 create a new TestSuite


28 options for the generation of the TestSuite
TestSuite: Select if you want to create a TestSuite into an existing one or a new one.
Style: there are 2 different types of styles:
1. One test case for each operation: creates a TestSuite with a test case for each operation 2. Create
new Empty Requests: creates an empty request with optional content in requests for test created
Operations: select operations that you want to generate.
Generate LoadTest directory: creates a load test by default for each test case generated.

Actions of the TestSuite
The following actions are available from the menu that appears when you right click on the node of the
TestSuite.

Open TestSuite Editor: opens the Launcher of the TestSuite. Described below.
Disable/Enable TestSuite: Disables/enables the TestSuite.
New Test Case: displays a window to define a new test case in the test group.
Clone TestSuite: generates a window to clone a TestSuite, including all the test cases and TestSteps.
Launch TestRunner: opens a dialog box to run the TestSuite from the command line.
Rename: Opens a window to rename the TestSuite.


Remove: displays a window to clear the TestSuite project. All the TestSuite that also contains will be
erased Online Help: Opens the online help page in the browser.

29 Shortcut Menu node TestSuite

label details of TestSuite
The label of "details" that is in the lower left corner, shows the following values when the testsuite is
selected in the navigation tree.

Name: the name of the current

30 Properties TestSuite TestSuite
TestSuite Launcher
by double-clicking on the browser of the TestSuite, open the Launcher of TestSuite that contains a list of
test cases and a toolbar. A progress bar is displayed for each test case. When you double-click on a test
case opens its editor of test cases. If a test case is testing its load, its progress bar is shown and the test
cases will not be launched during the execution of the TestSuite.

The available buttons in the toolbar from left to right are:

Run: run the selected test cases.
Cancel: Cancel the current execution.


New Test Case: opens a window to create a new test case in this TestSuite.
Run in Sequence: determines whether the test cases must be executed in sequence.
Run in Parallel: determines whether the test cases must be executed in parallel.

The state-run in sequence/parallel is preserved and also applies when you run a TestSuite using one of
the command-line tools expert or a plugin.

After the progress bar comes a list of the test case that contains, followed by a series of inspectors for
the test cases (from left to right):

Description: a partial description for the TestSuite.
Properties: properties of the TestSuite.
Setup script: a script to run when the test case is running.
Teardown Script: a script to run when the test case completes.

The registration window of the TestSuite below, shows all the steps/results of the last executions
TestSuite launched.


31 Result

Test Case execution TestSuite

SoapUI 4.3 supports functional testing of Web services by providing a test case with a number of steps
that can be executed in sequence. In addition, an arbitrary number of load tests can be associated with
a test case to run under different load scenarios.

Each test case in a TestSuite shows a number of properties that can be read, written or


modified by other TestSteps, for example one step in a Groovy script you can read the response
property of a step of request and take some action on the basis of their value, see the Expansion
property for more details and examples.

Types of TestSteps
are currently available the following TestSteps:

Step Type Description
sends a SOAP request and allows the Request response be validated using a variety of assertions
used to transfer the values of property ownership transfer between two TestSteps runs a script that
Groovy Groovy Script can do more or less "anything" is used to define global properties Properties that
can be read from an external source.
Allows any number of conditional jumps in the execution path of the Conditional Goto test case. The
conditions are specified as XPath expression and apply to the previous request response steps.
Pause the execution of a test case Step Delay during a specified number of milliseconds.
Running another test case within one Run Test Case Step already existing runs a Rest Request defined in
the Rest Request project Test
Test HTTP request is running an http call
listening to a SOAP response that is valid Mock Response and returns a response
request mock JDBC executes a request to a database
running MFA request a petition MFA


32 types of TestSteps

actions of the test case
the following actions are available from the menu that appears when you right-click on the node in the
test case:

Show Test Case Editor: opens the editor of the test case.
Disable/Enable Test Case: disables or enables the test case.
Options: displays the options window of the test case.
Add Step: adds a TestStep to the test case.
New LoadTest directory: opens a window to create a new load test for the test case.
Clone test case: opens a window to clone all the test cases, optionally in another TestSuite.
Clear: displays a window to delete all the TestSteps of test cases.
Rename: Opens a window to rename the test case.
Remove: displays a window to delete the test case of the TestSuite.
Launch Runner: Opens the dialog box to launch the pitcher of the test case of soapUI.
Move Test Case Up: Moves the current test case upwards in the list of test cases.
Move Test Case Down: Moves the current test case down in the list of test cases.
Online Help: Opens the online help page in the browser.

SoapUI. User Manual 42/74 42/74 42/74

33 shortcut menu node
Label test cases in detail of the test case
the tab of "details" that is in the lower left corner, shows the following values when the test case is
selected in the navigation tree
Name: the name of the current test case.

Clone a test case
to select "Clone test case" from the menu in the test case opens the following dialog box:

SoapUI. User Manual

Test Case 43/74 43/74 43/74 34 Clone
If you select clone to another project, soapUI opens a window to clone the interfaces required for this
project.

The editor of test cases
by double-clicking on the node in the Test Cases of the browser or by selecting "Show Test Case Editor"
on the menu of options opens the editor of test cases, which allows you to edit and run the test cases. If
the test case is doing a load test, the editor will be in its most disabled. The editor is divided in 4 parts
(from top to bottom):

a toolbar to run or cancel and the configuration options a progress bar that shows the status and
progress of the test case TestSteps Tab: the list of test cases of the TestSteps a series of inspectors
for the test cases (from left to right):
Description: a partial description for the test case Properties: properties of the test case Setup
script: a Groovy script to run when you run the test case Script teardown: a Groovy script to run when
terminates execution of the test case The record of the test cases to view and export the results. The
next entries are displayed:
When starts the test case An entry for each TestStep executed, indicating how has taken Errors
and/or optional messages reported by each TestStep How long it took for the

SoapUI test cases. User Manual 44/74

The toolbar of the editor of the test case
the main toolbar contains the following actions (from left to right)
Run Test Cases: running the test cases.
Cancel Test Case: cancels the execution of a test case.
Run Continuously: when you select the test case runs continuously. To stop the process you have to
press the button to cancel the test case.
Test Case Credentials: opens a window to configure the credentials to be used in all the requests of
the test case. It is quite useful if you want to run your tests with different credentials.
Test Case Endpoint: opens a window to set the end point for use in all the requests of the test case. It
is useful if you want to run your tests against different servers, etc.
The URLs available are listed in the interfaces of requests for operation.


Test Case Options: opens the Options dialog of the test cases described below.

List of TestSteps
The tab "TestSteps" contains a list of the TestSteps currently configured for this test case. To double-
click on a TestStep from the list, open the editing window for that item. When you right mouse button
on a TestStep shows a popup menu with the following actions:

Open Editor: opens the TestSteps associated editor (if available) Disable/Enable TestStep: disables or
enables the implementation of the TestStep.
Insert Step: displays a list of the TestSteps that can be inserted at the current position Rename:
Opens a window to rename the step created.
Delete: opens a window to delete the selected step.
Clone TestStep: displays a window to clone the selected step.
Move Step Up: Moves the selected step up one position in the list (can also be done with ctrl-arrow
above).
Move Step Down: Moves the selected step down one position in the list (it may also be done with
ctrl+down arrow).
Step specific actions: depends on which test cases is selected.
Online Help: opens the help page in the browser online Append step: displays a list of types of
TestStep aggregates for a test case
by double-clicking on the entry of a TestStep registry, open the viewer of the results of the TestStep
selected if you are available and described in the documentation page of each TestStep (for example,
the results display the request).

Options of the test case
by selecting the options of the test cases of the test cases of the node in the navigator menu or the
toolbar


of tools of the editor of the test case opens a dialog box with the following options.

Search Properties: when you look at the values of the property without the specifications of the step,
checks all the steps before the current name for the property.
Session: controls that an HTTP session is maintained for all requests in the test case.
The choice of this reuse cookies, authentication of headers, etc.
Abort on error: controls whether the test case has to be canceled when a TestStep fails with an error
(for example, if a request for a step has failed assertions).
Fail test case on Error: controls whether the test case is going to fail, if the option "Fail on error" is not
selected and the test cases end up with one or more TestSteps.
Discard OK Results: the long-running of the test case eventually consumes a large amount of memory
as the results of the TestSteps internally are frisked for later viewing and presentation. When you select
this option, soapUI will only save the results without success of the TestSteps which should save you
significant amounts of memory.
Socket timeout: the timeout (in milliseconds) that will be used for all the requests of the test case.
Test Case timeout: the timeout (in milliseconds) to wait before cancel or fail the execution of a test
case.

35 Options of a test case
4.3.1 . Test
the TestRequests Requests are one of the main features when working with soapUI. Extends standard
requests with the possibility to add any number of assertions that apply to the response received by the
request. This is, it verifies that the response contains what is expected to contain.

To create a TestRequest can be done in 2 ways. Since the standard requests using the action "Add to
test case" or via the popup menu of the editor of test cases with the option "Add Step -> Test
Request", which will display a window that must be entered for that interface or operation has to


be created the request.

In both cases, a dialog box will be displayed to standard add assertions to test the web service more
quickly.

The TestRequests are sent manually through the actions of sending their editors or when you run the
test case that contains the request. The response of the request is validated against the assertions of
requests and the icon of the request changes to reflect the result of the validation; green means that all
the validations were good and red that some failed. An icon with a gray background indicates that the
request has not yet been sent to validate, a white background indicates that the TestRequests lack of
assertions.

Actions of the TestRequests
The following actions are available when you right click on the node of the TestRequest menu:

Open Editor: opens the TestStep editor associated (if available).
Disable/Enable TestStep: disables or enables the implementation of the TestStep.
Insert Step: displays a list of the TestStep that can be inserted at the current position.
Rename: Opens a window to rename the selected step.
Delete: opens a window to delete the selected step.
Clone TestStep: displays a window to clone the selected step.
Move Step Up: Moves the selected step up one position in the list (can also be done with ctrl-arrow
above).
Move Step Down: Moves the selected step down one position in the list (it may also be done with
ctrl+down arrow).
Change Operation: opens a window to modify the operation of the TestRequest.
Select Operation: selects the TestRequest in the browser.

SoapUI. 48/74 User Manual

details the tab on the TestRequest
tab of the "Details" in the lower left corner shows the same properties that when a TestRequest node is
selected in the navigation tree to a standard request.
Adds two read-only properties:

Interface: the interface name for this TestRequest Operation: the name of the operation for this
TestRequest

Change operation
to select "change operation" of a TestRequest opens the following dialog box:

SoapUI. User Manual

36 49/74 Window "Change Operation"
The list of interfaces samples the interfaces available for the current project. The list of operations will
updates respectively.

The TestRequest editor
when you double click a TestRequest, both in the browser, such as in the box of the editor of the test
case, opens the editor request, which is more or less a copy of the standard editor of request with the
following exceptions:

The second button on the toolbar "Add to test case" has been replaced by "Add Assertion", which will
display a window to add an assertion to the TestRequest.
The action of clone now cloned the TestRequest request and attached the cloned the container of test
case underneath the table request/response is a box that contains 2 new tabs; the tab "Assertions Is
Not Given" (assertions) and the tab "Request Log" of requests).

All other features of editing, presentation and validation are the same as in the editor of request.

The tab of assertions
the tab list of assertions assertions that have been configured for the TestRequest. By double-clicking on
an assertion of the list opens the settings dialog box of assertions (if available). You can add as many
assertions as necessary and can sometimes be useful to add the same type of assertions several times
with different configurations.
A circle painted on the side of the assertion indicates the status of this according to the last answer
received; red = the assertion failed along with any error messages, green = assertion ok, gray = the
assertion has not been executed.
The following actions are available by right-clicking on the menu from the list of assertions:


Add assertion: displays a window to add a new assertion to the list.
Set up (if possible): opens the settings dialog box of the selected assertion.
Clone (if possible): opens a window to clone the selected assertion.
Disable: Enables/disables the assertions selected.
Rename: displays a window to rename the selected assertion.
Remove: opens a window to delete the selected assertion.

The toolbar contains buttons for adding, configuring, and erase an assertion.

The register tab of request
The register tab of request shows the date and time of dispatch, the duration and the size of the
response to a TestRequest. This can be convenient if you want to manually compare the response times
and the size.

Assertions of response
One of the main features of soapUI is the ability to create assertions about the content of the SOAP
responses. Are supplied a series of different assertions in order to meet the needs of quality for testing.
Currently the following assertions are available.


Type Description Schema validates the response message against its xml schema Compliance
Simple Contains checks for the existence of a
simple symbol not checks the non-existence of a symbol contains
verifies that the answer is a soap fault SOAP fault
Not SOAP fault verifies that the answer is not a soap fault
SOAP verifies that the answer is a valid response SOAP response
specified checks whether a given XPath expression coincides with a XPath Match predefined value
checks to see if a particular XQuery expression matches a predefined value Match XQuery verifies that
the response time is less than one Response SLA
allows the use of a Groovy script to Enforce the exchange Script Assertion messages
WS-security checks that the processing of WS-Security is correct Status

assertions marked with () are "assertions only", which indicates that can only be added once the
TestRequest.

Assertion schema in accordance of
the assertion of conformity of schema verifies that the answer is compatible with the xml schema of the
messages. If it is not, a list of validation errors, such as those shown in the tab of the editor validation
request, are shown and the assertion fails. The list of errors is also displayed in the tab of assertion of
the TestRequest editor; if possible, you can double-click on the errors to highlight the line of the
validation error.

The assertion has a single configuration parameter that is shown when creating/configures an assertion
in accordance to the schema, the URL to the WSDL definition that is used for validation. By default this is
the URL of the definition that contains the interface of operations of the TestRequest.

The assertion in accordance of schema is directed to a basic profile compatible with WSDL messages
and, therefore, only supports messages encoded verbatim (rpc and document). The validation of SOAP
messages-encoded is not supported and will result in a validation error.

We need to take into account the fact that a SOAP-Fault only will be a validation schema if the detail
element contains part of the message that is defined in the corresponding link and that will not be
compatible

SoapUI. User Manual

with its corresponding 52/74 communication scheme (see later, the assertion of SOAP-Fault in relation
to the validations of response messages SOAP-Fault).

Simple Contains
the assertion "Simple Contains" checks the existence of a specific substring in the response received.
In all cases is not parsing and validation.
The assertion has 3 configuration parameters that are displayed in a window when you create or
configure a simple container assertion:

The options are:
Content: the content to search.
Ignore Case: Ignore differences between uppercase and lowercase letters.
Regular Expression: evaluates as a regular expression.

Simple Not Contains
the assertion "Simple NotContains" checks the non-existence of a specific substring in the response
received. In all cases is not parsing and validation.
The assertion has the same configuration parameters as described for the container of assertions above.

SOAP fault
the assertion "SOAP fault" checks that the response received is a soap fault. This assertion has no
configuration parameters.

Not SOAP fault
the assertion "Not SOAP fault" checks that the response received is not a soap fault. This has to be used
next to the conformity of schema as a SOAP fault is not validated against any schema (at least there is a
part of the fault defined in the WSDL and the fault is present in the response). This assertion has no
configuration parameters.


SOAP response
validates that the answer is a valid SOAP message. This is the minimum assertion that should be added
to collect empty answers or pages of HTTP error. This assertion has no configuration parameters.

SLA Response
The assertion "Response SLA" verifies that the response time is less than the time limit indicated.

Assertion WS-Security Status
The assertion "WS-Security Status" verifies that the input message headers has valid WS - Security.

XPath Match
the assertion "XPath Match" allows for the specification of an XPath expression to be evaluated in
relation to a response message received and compare your result with a predefined value. Expressions
can select everything from values of attributes, to make evaluations boolean or select the response of
the entire body (XmlUnit is used internally to compare the XML elements, hierarchies or nodes).
Internally, soapUI uses the XPath engine Saxon 8.8 which has support for XPath 1.0 and XPath 2.0.
The configuration dialog for the assertion XPath Match is divided into 2 zones, the upper that contains
the desired XPath expression and at the bottom that contains the expected result.


The toolbar to the top of the XPath contains the following action:
declares: Adds a statement in the name space for all the namespaces that are currently defined in the
underlying message in response to the XPath expression. Saxon uses this syntax for namespace
declarations for that can be used later in the XPath expression.

The toolbar to the lower part contains the following actions (from left to right):
Select from current: evaluates the XPath expression specified against the current reply message (if
available) for the underlying request. The output is written to the results area of the configuration dialog
Test: evaluates the XPath expression specified against the current reply message (if available) for the
underlying request and compare this result with the value specified in the results area. This is essentially
the same comparison that is done during an assertion "true".
Allow Wildcard: Allows the use of the wildcard '' attributes and elements of values. These are to be
avoided during the comparison (see a later tutorial).

The button bar below shows the following:
Help: opens the help page online in the

SoapUI navigator. User Manual 55/74

Save: Saves the values of the current results XPath and closes the dialog box.
Cancel: Dismisses the values of the current results XPath and closes the dialog box.
The dialog is non-modal window so you can go to re-focus in soapUI and, for example, select the
underlying values of the response message.

XPath assertions by creating
the recommended method for creating an assertion XPath is the following:
1. Send the TestRequest and waiting for their response (therefore there is a response to test) 2. Create
the assertion of XPath and start adding namespace declarations to the XPath expression with the button
"declare" 3. Now add the XPath expression after the declarations of the namespaces, count ( //ns1:Item)
in the above screenshot 4. Use the button "Select from current " to evaluate the XPath expression
against the result available and check that returns what is expected, 10 in the above screenshot 5. Again
check by pressing the key "Test" that should return a message of OK since the test compared the
outcome of the selection with the XPath value previously selected.

Match
the Assertion XQuery XQuery Match assertion is configured exactly as the XPath assertion Math that has
been described previously, the only difference is that the expression is evaluated as an expression
XQuery 2.0 .


This assertion is useful when you want to ensure a subset of the data and, for example, does not depend
on other data. In the example in the screenshot, an ordered list of ids is created from the response and
is compared against a predefined list, resulting in an assertion which will not fail if the items come in a
different order and/or get more/other data "around" the id of the element.

Script assertion
The assertion "script" allows arbitrary validations (see examples below). When you create or double-
click on an assertion "script", a Groovy script editor this is how it looks then

SoapUI. User Manual 57/74 57/74 57/74

The assertion "script" can be run against the last message exchange with the run button in the top left.
The script has access to the following objects:
messageExchange: the messageExchange for the current request / response. It gives direct access to
the content of the messages, HTTP headers, attachments, etc.
context: the TestRunContext runs the current test case, which is now going to be an instance of
WsdlTestRunContext log: a standard object of log4j Logger available for the arbitrary searches of
information
an assertion "script" should launch a exception with the error message to fail the assertion. You can also
use a statement built in Groovy for a easy syntax of the assertion, as shown in the examples below. If
the assertion is valid, it will return nothing or a status message that is displayed in the register of the test
case.

Examples of assertion script
Validate a certain response time:

assert messageExchange.timeTaken < 400
Validate the existence of an HTTP response header:

assert messageExchange.responseHeaders[ "x-amz-id-1 '] != null
validate the existence of a specific element using GroovyUtils (although this would be easier with a
standard XPath assertion - Contains):

def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context ) def holder =
groovyUtils.getXmlHolder( messageExchange.responseContent )
assert holder[ " //ns1:RequestId"] != null


4.3.2 . Property Transfers
The Property-Transferes are properties TestStep that transferred between containers of property within
the same scope as the Property-Transfer of TestStep (that is to say, that contains your test cases, your
TestSuite, project, and the destination properties). The step can contain an arbitrary number of
"transfers" by specifying a property of origin and destination with expressions of optional XPath/XQuery.
The Property-Transferes used the same engine of Saxon XPath/XQuery described for assertions XPath
and XQuery.

The editor
The editor Property-Transferes Property-Transferes opens by double-clicking on a step of a Property-
Transfer browser or in the list of TestStep editor of test cases.
The editor contains a list of transfers set to the left, by selecting a transfer of the list will show your code
and the target expression of XPath and XQuery to the right.
The drop-down list at the top right is used to specify the origin and ownership to be transferred. The
destinations and properties are specified with the drop-down list in the east. If the properties contain a
XML followed by an XPath expression you can specify even more, by selecting the value to transfer or
move.


The following buttons are available in the toolbar at the top:
Add: displays a window to add a new transfer to the list.
Delete: opens a window to delete the selected transfer.
Copy: opens a window to create a copy of the selected transfer.
Rename: displays a window to rename the selected transfer.
Run - runs the selected transfer, i.e. transfers the value according to the settings made. To work
correctly the origin and the destination property have to be available ( for example a response from a
TestRequest ).
Run all: runs all the transfers, that is, it passes the values specified. To work correctly the origin and
the destination property have to be available ( for example a response from a TestRequest ).
Declares: declares the namespace of the XPath fields of origin and destination. The namespace in the
source field is extracted from the response message from the TestRequest selected. The spaces in the
name of the target field is extracted from the corresponding request messages the TestRequests. If any
of these are not available, soapUI shows a window to define all the available names the schemas
associated.

The transfer log from the bottom of the editor shows all the transfer made by the Property-Transfer
while the editor is open, including both the carried out using the toolbar buttons

SoapUI. User Manual

tools of 60/74 and during the execution of a test case/TestSuite. The toolbar of the transfer log contains
a "clear" button to delete your current content.

Running a transfer
after the execution of a test case, each transfer of the Property-Transfer is done by selecting the
properties specified by the source step, property and optional XPath expression and copying its value to
the property specified by the step of destination you can use an optional XPath expression.
If the XPath expressions are specified, soapUI will seek to replace the destination node with the origin
node if they are of the same type. If not (for example, when text is assigned () to a @attribute), soapUI
will do everything possible to copy the value.
XPath expressions of source and destination must be aimed at existing nodes in their respective
properties. The source property, obviously, requires the node so that it can be selected and the
destination property requires the node so that it can be found and overwritten.
If any of the transfers fails due to lack any XPath expression, an error is displayed and the step may fail
or continue depending on if the option "Fail on error" has been selected for such a transfer. The
execution of a test case only is aborted if the option "Fail on error" of the test case has been selected, as
described in the options of the test case.
The following options are available for each transfer:
Fail transfer on error: Property-Transfer fails if an error occurs ( for example the lack of a source
property).
Set null on missing source: cancels the error of the lack of source values and sets the target property
to null in these cases.
Transfer text content: When the XPath expression pointing to nodes elements, your text content is
transferred in place the elements by themselves (necessary for backward compatibility with soapUI 1.5
).
Ignore empty/missing values: cancels the errors for the lack of source values and ignores their
corresponding transfers.
Transfer to all: If the XPath expression of destination you select multiple nodes, the value of the
property of origin shall be established in all these nodes instead of only the first.
Use XQuery: interprets the XPath expression of origin specified as an XQuery expression, allowing the
transfer of complex data/processed instead of just "simple" copy.

Working with
a Property-Transfer Property-Transfer can be created in the following ways:
1. First you must create the 2 TestStep between which there is to perform the transfer 2. Create a
Property-Transfer in the configuration dialog by using the "Add" button 3. TestStep Selects the source
and destination and its corresponding properties from the drop-down lists.
4. If any of the properties contains XML, there is that proceed by defining the namespace in the XPath
expressions using the button "defines". Then there is that add the XPath expressions that specify where
to select and copy it. In the screenshot above, both expressions are //ns1:SessionId, indicating that the
sessionID element will be copied from the previous response to the next request (which must be
available, but preferably empty) 5. Test the transfer by selecting the "run" button and verifies that the
values of the next request have been successfully copied. Any error will be shown either in the main
record of soapUI (at the bottom) or in a pop-up window.
6. Repeat steps 3-5 for each transfer added to the

SoapUI ValueTransfer. User Manual 61/74

4.3.3 . Gotos Conditional steps of conditional Goto evaluate an arbitrary number of XPath conditions of
the reply message from the previous request and transfer the execution of test cases to the TestStep
associated with the first condition that evaluates to true. This allows conditional execution of routes of
test cases, where the result of some requests controls how to move around in the test case. If there are
no conditions that match the current response, the execution of the test case continues after the Goto
step on a regular basis.

Example of scenarios:
ramifications that depend on the results returned by a request Restart after a long delay in
surveillance tests On several occasions wait and check the value of state before continuing ( for
example in a batch process )
conditions used the same engine that Saxon XPath described for the XPath assertions. Remember that a
condition it must evaluate to a Boolean value to be valid (see examples below).

The editor of the conditional Goto
the editor of the conditional Goto opens by double-clicking on a TestStep of a conditional Goto, both in
the browser, such as in the list of TestStep editor of test cases.
The editor contains a list of conditions set to the left, by selecting a condition from the list displayed on
the right, the expression of such a condition and a drop-down list for the TestStep destination.
The test button of the condition will evaluate the condition with the current response and display the
result (a response message must be available for the previous TestRequest).


The following actions are available in the toolbar at the top:
Add: displays a window to add a new condition to the list.
Copy: opens a window to create a copy of the selected condition.
Delete: opens a window to delete the selected condition.
Rename: displays a window to rename the selected condition.
Run: running conditions and shows the condition that matches the current response (a response
message must be available for the previous TestRequest).
Declares: declares the namespace in the expression field of the selected condition. The namespace is
removed from the current reply message from the previous request for a response.

4.3.4 . Step
a Property-Step Properties allows you to define an arbitrary number of properties that can be used from
the Property-Transfers and from the steps of a Groovy script. The properties, optionally, can be read
from and written to a file of properties under implementation, for example, if you want to specify some
external properties (passwords, endpoints, etc) or if you want to write some results in a file for later
reporting.

Property Editor
The editor property step is simple:

The toolbar contains the following ( from left to right):
Add Property: opens a window to add a new property.
Remove Property: displays a window to delete the selected property Load from: optional field that
contains a file/URL/property system that contains the code for the properties. The specified file or the
URL will be read as a standard properties file and the value of the property shall be allocated to the
steps of property.
If the field is set to the name of a system of property, this property you must specify a file or a URL that
will be read later, as has been described Select Properties Source: allows the selection of a local file
that contains the properties


to be read. The selected file will be read and the values of the properties contained will be assigned to
the properties that match on the steps of property (a window will be displayed if you try to create
properties that are not available) Save to: optional field that contains a file or a system of property
that contains the target name of the file of properties. The indicated file will be created as a standard
file of properties and property values contained in it will be written in the same. If the field is set to the
name of a system of property, this property must specify a file that will be created later, as has been
described.
Select Properties Target: allows selection of a local file in which the properties should be written in
the box that appears under the toolbar displays the properties defined and their values, the values and
the names can be changed by the standard edition.

Tab ownership details
the detail tab of the step property ( bottom left ) contains the following:
Name: the name of the step property.
Description: a small description of the step property.
Create missing on Load: creates the file properties owned by origin that are not currently defined.
Save before Load: used to save the existing properties before loading new ones of the files owned by
origin and destination.

Execution of the step
when a step of property runs during a test case, take the following actions:
properties are read or written from a source if it is specified as described above (depending on the
option "Save before load.) The properties are written or read to a objective if it is specified as
described above (depending on the option "Save before load.) properties are all copied to the current
TestRunContexts properties to make them available to the property of Expansion
4.3.5 . Delay
The TestStep Step delay can be inserted into any position in a test case to pause the execution of a test
case for a specified number of milliseconds to insert a step of delay is used the menu option "Insert
Step" which has been described above. By clicking with the right mouse button in the step of delay and
if you select the option "Set Delay Time" you can adjust the number of milliseconds to pause (default is
1000ms).


4.3.6 . Run
the test case execution step of a test case allows you to run another test case within the current,
optionally you can adjust the returned properties of the test case destination.
This can be useful to split complex test cases into smaller parts or share some functional tests between
test cases.
After selecting "Run Test Case" when you create a new TestStep displays the following dialog box:

Select the TestSuite and the test cases from the drop-down lists. The list of "Return Properties" contains
the properties of the test cases defined test cases for the destination. Select the properties whose
values should be copied and returned to the step of execution of the test cases after run.

The editor of the execution step of a test case


once created, the editor opens the execution step of the test case that contains (from top to bottom) a
toolbar with buttons to execute, cancel, configure, and open the test case objective a table that
contains the same properties as test case objective. Only the values for the properties they are editable.
A record of test case that shows the output of the last execution

implementation
when it is running a test case, the following occurs:
1. The values that contain the properties and are not marked as properties to return are copied to the
test case objective 2. Runs the test case objective 3. Properties marked as properties to return are
copied to the objective of the test case execution step of the test case 4. If the objective test case fails,
then also fails the execution step of the test case
the property manipulated in step 1 and 3 can be seen as an argument of input / output for the test case,
allowing it to be run with different values. This could be combined with a DataSource for the execution
of a test case with a full range of input values.
After you run it, the record of the test case should contain the same output as it is noted in the record of
the test cases for test case objective.


4.3.7 . Tests (JMS HermesJMS)
version 3.5 of SoapUI, includes support to the evidence JMS, to cover this functionality is supported by
the project HermesJMS.
It is a console HermesJMS extensible, which enables us to interact with JMS providers, finance easy
navigation and search for queues and "topics". This fully integrated with JNDI allowing manage stored
objects, create the JMS session "connection factories" and use any defined destination.

For additional information about the product access to your web page:
http://www.hermesjms.com/confluence/display/HJMS/Home

Execution


in the tools menu select the option HermesJMS that we will open the external utility.

SoapUI. User Manual

Configuration 68/74 weblogic8
We create a new session with the following configuration

SoapUI. User Manual

69/74

in the tab of providers, you must configure the libraries necessary for the server, in our case

would simply be add weblogic.jar.

SoapUI. User Manual

70/74

4.3.8 . Test of interoperability. WS-I Basic Profile

is SoapUI tool integrated with the WS-I Basic Profile 1.1 . This tool, promoted by the Web Services
Interoperability Organization (WS-I' ), allows you to check if a Web service is designed to be
interoperable, and complies with the specifications of Basic Profile.

Through the use of this tool, we will look at the WSDL file of the service, and a report will be generated,
where it is indicated if it complies with the specification Basic Profile or not.

In order to use the tool, in the first place needs to be configured in the file option from the menu
Preferences WS-I settings, as explained in the item 3.5.8 of this document.

In the option Tool location, you must specify the path where are the tools are installed WS-I.
By default, with the installation of the SOAPUI, the tools are installed in the folder: C: \Program
Files\eviware\soapUI-3.5 \WSI-test-tools.

Once the configuration is complete, to generate the report for interoperability of Basic Profile, select the
option "Check WSI Compliance" of the menu interface. This option will launch the process of validation
of the WSDL of the Service, and generate a report on the results.


in the results report, a summary is displayed, in the paragraph Summary, where it indicates if the WSDL
specifications comply with the WS-I Basic Profile or not.

In addition, it shows the detail of the points analyzed, and in the event of an error, indicating the reason
of the same.


5 tools integration

SoapUI can be integrated with various tools and frameworks for web services, including:

1. Code generation tools that allow generation of customers of a web service or implementation
artifacts, from an existing WSDL in a project of SoapUI.

2. "WS-I Tools" integrates the validation of web services against "WS-I Basic Profile".

3. Apache fail over because Tcpmon deadlocks provides functionality of traffic monitoring HTTP.

SoapUI is not included in the installation the different tools. It is necessary to install individually with
each one of them and then tell you to SoapUI the path to the tool. The different paths are listed from
the Preferences screen- >Tools. Below is an example of how it could be that window:


37 configuration example of paths of external tools

SoapUI. User Manual

74/74

Soap UI

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Soap UI

Transféré par

Droits d'auteur :

Formats disponibles

SoapUI

Vous aimerez peut-être aussi