Web Service Testing: A Beginner's Guide

What is WebService? Why is it Needed?

In General, software applications are developed to be consumed by the human
beings, where a person sends a request to a software service which in-turn
returns a response in human readable format.
In the modern era of technology if you want to build a software application you
don't need to build each and everything from scratch. There are lots of
readymade services available which you can plug into your application and you
can start providing those services in your application.
For example you want to display whether forecast information you don't need
to collect, process and render the data in your application. You can buy the
services from the people who already well-established in processing and
publishing such kind of data.
Web services allow us to do these kind of implementations. Web Services is
the mechanism or the medium of communication through which two
applications / machines will exchange the data irrespective of their
underline architecture and the technology.
As an example, consider the following WebService
http://www.webservicex.net/stockquote.asmx?op=GetQuote
It gives Share Value for a Company.
Let's find share price for Google (Symbol: GOOG )

The response XML gives the stock price.

This WebService can be called by a Software Application using SOAP or HTTP

protocol.
Web Services can be implemented in different ways, but the following two are
the popular implementations approaches.
1.

SOAP (Simple Object Access Protocol)

2.

REST (Representational State Transfer architecture)

SOAP
SOAP is a standard protocol defined by the W3C Standard for sending and
receiving web service requests and responses.

SOAP uses the XML format to send and receive the request and hence the
data is platform independent data. SOAP messages are exchanged between the
provider applications and receiving application within the SOAP envelops.
As SOAP uses the simple http transport protocol, its messages are not got
blocked by the firewalls.

REST
REST means REpresentational State Transfer; it is an architecture that generally
runs over HTTP. The REST style emphasizes the interactions between clients and
services, which are enhanced by having a limited number of operations. REST is
an alternative to SOAP (Simple Object Access Protocol) and instead of using XML
for request REST uses simple URL in some cases. Unlike SOAP, RESTFUL
applications uses HTTP build in headers to carry meta-information.
There are various code that REST use to determine whether user has access to
API or not like code 200 or 201 indicates successful interaction with response
body while 400 indicates a bad request or the request URI does not match the
APIs in the system. All API request parameters and method parameters can be
sent via eitherPOST or GET variables.
Rest API supports both XML and JSON format. It is usually preferred for mobile
and web apps as it makes app work faster and smoother There is one more
thing one needs to learn

WSDL
WSDL (Web Services Description Language) is an XML based language which will
be used to describe the services offered by a web service.
WSDL describes all the operations offered by the particular web service in the
XML format. It also defines how the services can be called, i.e what input value
we have to provide and what will be the format of the response it is going to
generate for each kind of service.

Web Service Testing

Web Services Testing basically involves
1.

Understand the WSDL file

2.

Determine the operations that particular web service provides

3.

Determine the XML request format which we need to send

4.

Determine the response XML format

5.

Using a tool or writing code to send request and validate the

response

Suppose we want to test a WebService which provides Currency Conversion

Facility. It will the current conversion rates between the different countries
currency. This service we can use in our applications to convert the values from
one currency to the other currency.
Now lets look at above steps

Step 1 to 4: Understading WSDL and

determining operations & XML formats
Currency Convertor WSDL file can be seen @
(http://www.webservicex.net/CurrencyConvertor.asmx?wsdl) which will give the
information about the Currency Convertor web service methods which it will
support, the parameter which we need pass and the type of parameters etc

Step 5: Using a tool or writing code to send

request and validate the response
There are lots of tools available to test web services. SoapUI is one of the
popular tool which will help us to test the web services. In fact you can use the
any programing language which is capable of sending the XML request to the

web service provider application over the http and able to parse and validate
the response XML against the expected result. In our case, we will test the
WebService
1.

Using Java

2.

Using SoapUI

PART 1) WebService Testing Using Apache Axis2

API (Java).
Generally web service takes the request and sends the response in the XML
format.
Apache Axis2 API project is a Java implementation API, which will be used to
create the web services for both server side (service provider) and client side
(service consumer).
Axis2 is capable of sending SOAP messages and Receives & Processes the SOAP
messages. We can write a small Java program using the API to create the web
service. Axis2 will generate the WSDL from Java program which will be used to
communicate the services offered by the web service. We can use the same
Axis2 to generate the Java class (stub) from WSDL file which we can use as a
client program to generate the web service request, to send the request to the
service end point and to process the response.
1.

Basically we will create a simple Java program in which we will instantiate

the stub class.

2.

Using the stub we will invoke the request method by passing all the
required information.

3.

Stub program will convert that request into XML request format and
sends it the service end point which will read the request and processes the
request and sends the response in XML format.

4.

The XML response will be converted into Java class by stub and returned
to the actual program.

Let's look at above steps in detail

Step a) Download the axis2 API
@ https://axis.apache.org/axis2/Java/core/download.cgi & Set the environment
variable 'AXIS2_HOME'

Step b) Create a folder to keep all the generated artifacts

Ex : C:\Axis\Projects\CurrencyConverter
Step c) Open the command prompt and navigate to the folder structure where
you want to generate the artifacts and Run the following command which will
generate the stubs
%AXIS2_HOME%\bin\WSDL2Java -uri
http://www.webservicex.net/CurrencyConvertor.asmx?wsdl -p
org.apache.axis2.currencyconvertor -d adb s

Step d) Once the command is successfully run, you will see the folder with
required files.

Step e) Next we have to create the client program, through which we will send
the actual request using the generated stubs. Open the eclipse and create the
new Java project and select the folder which we have created above.

Step f) Add all the axis2 related jars to project build path, which will be there in
lib folder of the axis2 software folder
(for ex : C:\Axis\axis2-1.6.2\lib)

Step g) Create a new Java class (ex : Client.Java) and instantiate stub object.
Using the stub object we can call all the supported methods of the particular
WebService.

Client.Java Program

package org.apache.axis2.currencyconvertor;

import org.apache.axis2.currencyconvertor.CurrencyConvertorStub.ConversionRate;
import
org.apache.axis2.currencyconvertor.CurrencyConvertorStub.ConversionRateResponse;

import
org.apache.axis2.currencyconvertor.CurrencyConvertorStub.Currency;

public
class Client{

public
static
void main(Java.lang.String
args[]){

try{

//Create the stub object by passing the service end point url
CurrencyConvertorStub stub = new CurrencyConvertorStub(
"http://www.webservicex.net/CurrencyConvertor.asmx");

//ConversionRate is the class which we have to use mention the from and to
currency
//ConversionRate object will be the parameter for the
conversionRate operation
ConversionRate conversionRate = new ConversionRate();
conversionRate.setFromCurrency(Currency.USD);
conversionRate.setToCurrency(Currency.INR);

//Create the ConversionRateResponse object, which is going to be used to catch the

response
//call the conversionRate service using the stub object
ConversionRateResponse conversionRateResponse =
stub.conversionRate(conversionRate);

//We can use the conversionRateResponse object to retrieve the response of the
ConversionRate Service
System.out.println("Conversion Rate from INR to USD : " +
conversionRateResponse.getConversionRateResult());

} catch(Exception e){
e.printStackTrace();
}
}

PART 2) Using SoapUI to Test the WebService

In SoapUI
1.

Go to File > New Soap Project

2.

Enter the project Name and the WSDL URI location

3.

Click OK

1.

Expand the first request and double click on the 'Request1'. It will display
the SOAP request in the XML format.

2.

Enter the From Currency and To Currency

3.

Click on the submit button

4.

Response XML will be displayed right side pane.

As you may conclude, usage of tools like SoapUI expedites your WebService
Testing Effort. Hence SoapUi will be focus of our learning in the succeeding
tutorials.

Summary

Software Applications communicate and exchange data with each other

using a WebService
SOAP and REST are 2 popular protocols to create a WebService
SOAP supports XML based data exchange
REST support XML, Json or exchange of data in simple URL.
WSDL is XML based language which will be used to describe the services
offered by a web service. SOAP is defined using WSDL.
To test WebService you can
o
Create your own code. For instance use Axis2 API for Java
o
Use WebService Test Automation tools like SoapUI
Automation Tools like SoapUI will jumpstart your testing efforts, will
require less coding effort compared to creating your own code using Axis2
API

FAQ
What is Difference between WebService and WebAPI?

Web Service

Defined by W3C, all communication & data

Web API

exchange is based on XML

Web API communication & data exchan

JSON or plain data

It has defined standards WSDL

No defined standard

You cannot compress the data but you can compress

You can compress the data

Example: REST

the HTML request

Example: SOAP

Introduction to SOAPUI
What is SOAP UI?

SOAP-UI is the leading open source cross-platform API Testing tool

SOAP-UI allows testers to execute automated functional, regression,
compliance, and load tests on different Web API.

SOAP-UI supports all the standard protocols and technologies to test all
kinds of API's.

SOAP UI interface is simple that enables both technical and non-technical

users to use seamlessly.

Why use SOAPUI?

SOAP-UI is not just a functional API testing tool but also lets us perform nonfunctional testing such as performance and security test.
Let us discuss the 5 important features of SOAP-UI 1) Functional Testing

A powerful tool allows testers to write Functional API Tests in SoapUI

Supports Drag-Drop feature which accelerates the script development
Supports debugging of tests and allows testers to develop data driven
tests.

Supports Multiple Environments - Easy to switch between QA, Dev and

Prod Environments

Allows advanced scripting (tester can develop their custom code

depending on the Scenario)
2) Security Testing

Has the capability to perform a complete set of vulnerability scan.

Prevents SQL Injection to secure the databases

Scans for Stack overflows that are caused by documents huge in size
Scans for Cross Site Scripting, which usually occurs when service
parameters are exposed in messages.

Performs Fuzzing scan and Boundary scan to avoid erratic behavior of the
services.
3) Load Testing

Distribute the Load Tests across any number of loadUI Agents.

Simulate high volume and real-world load testing with ease.

Allows Advanced custom reporting to capture performance parameters.

Allows End-to-End System Performance Monitoring

4) Supported Protocols/Technologies:
SoapUI has the most comprehensive Protocol Support

5) SOAP-INTEGRATION with Other Automation Tools:

SoapUI integrated very well with popular tools

Maven

Apache Maven is a software project management tool that can manage a

project's build, reporting and documentation from a central repository.
Maven can also execute SOAP-UI tests within Maven Build using simple
commands.

HUDSON

HUDSON, a JAVA based Continous integration tool and integrates with tools
such as CVS, Subversion, Git, Perforce, Clearcase, and RTC. SOAPUI also
integrates with HUDSON, which helps us to spot bugs quickly for each and
every commit by the developers.

JUnit

JUnit is a unit testing framework built in Java, which can control the flow of
tests from SOAP-UI as well.

Apache - Ant

Apache Ant, a Java library which is a command-line tool that helps in building
software. Using SOAP-UI's Command line, we can execute tests within an ANT
Automated Build.

SOAP UI Vs Selenium:
Let's compare SoapUI with Selenium
SOAP UI

Selenium

SOAP UI is NOT used for User Interface Testing. It is

only used for WebAPI or WebService Testing

Selenium is used for User Interface Testing.

Capability to test the data sent and received between

the web browser and a web server. Can test the
protocols/technologies such as REST, SOAP.

Selenium cannot test protocols, but they can test the UI

Able to perform functional, load and security testing

of the above-mentioned technologies.

Selenium can perform only functional testing. Perform

some extent because we can track execution time with
performance but cannot test multi user and multi tenanc
certainly cannot be used for security testing.

It is PROTOCOL Dependent and NOT browser

dependent.

Selenium depends on the browser capabilities.

SOAP UI Vs SOAP UI PRO

We know that there are two flavors of SOAP UI, One being SOAP UI (Open
source version) while the other one is SOAP UI PRO. Let us understand the
difference between these two flavors and we will also discuss when to go for
use what.
Features
Supported Technologies
SOAP/WSDL
REST
JMS
AMF

SOAP UI (Open Source Version)

SO

JDBC
HTTP

Automation
Functional Tests
Load Tests
Mock Services
Code Generation
Command Line
Maven
CI and Build Integration
General Features
Standalone Application
Groovy Code Templates
Multi Environment Support

Floating Licenses

Functional Testing features

WSDL Coverage
Request/Response Coverage
Message Assertion
Test Refactoring
Running of Multiple Tests
Data Source Driven Tests
Scripting Libraries
Unit Reporting
Manual Test Step
Security Testing features
Boundary Scan
Invalid Type

SQL Injection
XPath Injection
XML Bomb
Fuzzing Scan
Cross Site Scripting
Configurable Scans
Reporting
Load Testing Features
Rapid Load Tests from Functional Tests
Configurable Load Strategies
Load Test Assertions
Real-Time Statistics
Performance Monitoring
Statistics Exporting
Setup/TearDown using Groovy Scripting

loadUI Integration
Reporting
Reports
JUnit Reports
Report Data Export
WSDL HTML Report
WSDL Coverage
TestSuite Coverage
TestCase Coverage
Assertion Coverage
Message Recording Coverage

When use SoapUI PRO Version?

Data Driven: PRO Version, helps us to work with an external data source
such as text files, XML, Groovy, Excel, file, and Databases. This helps us to
scale our tests with a range of inputs driven through the above-said sources.

Test Coverage: PRO Version allows testers to get a statistic report which
shows the functionalities that are well tested and also the areas that are NOT

thoroughly tested as well. The drill down reports even pinpoints exactly what
has NOT been tested and what has NOT been asserted.

Test Debugging: You can then run the test to that breakpoint and view
the current value of the SoapUI properties. The Test Debugging Interface
simplifies following Test Flow, Variables, Properties, Requests, Context, and
much more, making test creation and improvement more streamlined.

Multi-Environment Support: Working with multiple environments such

as DEV, QA, Pre-PROD environment can be a daunting task with the open
source version as testers need to change the end points to execute in
different environments. PRO version helps us to switch between
environments seamlessly.

Reporting: PRO version is loaded with many options to customize reports

that generate detailed reports at Project, TestSuite, TestCase or LoadTest
level. It also produces reports in various formats such as PDF, HTML, Word or
Excel.

Security Testing: Both SOAP UI versions has capabilities to test for

security vulnerabilities such as XML bombs, SQL injections, fuzzing, cross-site
scripting. However, only SOAP UI PRO can perform vulnerability scans using
Security Test Generator using a mouse click.

SQL Builder: For Non-Technical testers writing complex SQL Query can be
cumbersome. The SOAP UI PRO's SQL Builder can help them in creating SQL
Query using the SQL Builder's graphical interface. This feature helps us to
accelerate the implementation of data-driven testing.

Support: As part of the license agreement SOAP UI Pro has exclusive

support apart from the online forum support.

We will be using the Open Source version of SoapUI for our training purpose.

SOAP UI Version Timelines

FAQ
What is Difference between WebService and WebAPI?
Web Service

Defined by W3C, all communication & data

Web API

exchange is based on XML

Web API communication & data exchan

JSON or plain data

It has defined standards WSDL

No defined standard

You cannot compress the data, but you can compress

You can compress the data

the HTML request

Example: SOAP

Example: REST

SoapUI can test both Web Service and Web API. As a tester, you can forgot
about these differences and focus your energies on creating an exhaustive
automation suite.

SOAP UI Installation and Configuration:

Complete Guide
In this tutorial, we will demonstrate the steps to download, Install and
Configure SOAP UI (Open Source Version).
Following is the software and hardware requirement for the various platforms.

In this tutorial installation is done on a Windows Environment. The process

remains the same for other OS.
Here is the roadmap for the installation process

Part A: Downloading

Navigate to http://www.soapui.org/
Scroll down and choose the downloader based on your operating system.
In this tutorial, we will install SOAP UI on a 64 bit Microsoft Windows
operating system.

Upon clicking download, the user is automatically forwarded

to http://sourceforge.net/ and the installer download starts automatically.

Part B: Installing
Step 1: After downloading, execute the file as 'Administrator' as shown below

Step 2: In the setup wizard, click 'Next' to continue.

.
Step 3: Accept the license agreement and click 'Next' to continue.

Step 4: Choose the installation directory or leave the default installation

directory as is.

Step 5: Choose the components that you wish to install.

SOAP UI is checked by default and NOT user configurable.

Source Enable, If you would like to get access to the source code of
SOAP-UI. We have not selected it.

Hermes JS Enable, if the application requires JMS testing.

Tutorial Enable, if you want to access SOAP-UI tutorials Post installation.

Step 6: The installation wizard asks the user to download and install 'Load UI'.
Since Load testing is not the context of the discussion, we can proceed without
selecting it.

Step 7: If 'Hermes JMS' is selected in step#5, then the license agreement for
'Hermes JMS' pops up. Accept the license agreement and click 'Next'.

Step 7: Choose the folder location for tutorials or else leave the default location
as is and click 'Next'.

Step 8: Choose the start menu folder location or else leave the default location
as is and click 'Next'.

Step 9: Enable the checkbox 'create a desktop icon' and click 'Next'.

Step 10: The Installation starts and upon completing the same, the wizard
shows the below status. Click 'Finish'.

Step 11: Upon clicking the 'Finish' button, SOAP UI is launched.

1.

Menu Bar

2.

Quick access toolbar

3.

Project Navigation Area

4.

Workspace Properties

5.

Log area

NOTE: You might see an upgrade screen like below. You can just Ignore the
Update

Part C: Configuring
Let us first understand the project structure in SOAP UI.

First step in SOAP UI is to create a workspace. There can be several

projects associated with a workspace. Users can create more than one

workspace. In SOAP UI Pro version, we can seamlessly switch environments

to map it to different end points.

For Each project, we can create several test suites.

For Each Test Suite, there can be several test cases attached to it.

For Each Test Case, there can be several test steps associated with it.
Below is the pictorial representation of a workspace structure in SOAP-UI.

Step 1: First step is to create a workspace. Create a workspace as shown below.

All the artifacts that we are going to create from now on would be contained in
this workspace.

Step 2: Enter a name for the workspace and click 'OK.'

Step 3: Now the user has to select the path where this workspace has to be
saved.

1.
2.

3.

Select the path where the workspace has to be saved

The name of the workspace XML, which has to be located when user
wants to open the workspace in the future.
Click 'Save'.

Step 4: The workspace is created as shown below. We can also access the
workspace properties under 'Workspace Properties' Tab.

Now we have successfully configured SOAP-UI after downloading and installing

such that we can continue to perform testing.

Basic GUI Navigation

FILE MENU:

Understanding the most frequently used navigations within SOAP-UI is

very important for seamless navigation while working on real-time projects.
Let us take a look at the file menu first.

1.

'New SOAP Project' allows user to create a Project by importing SOAP

Request.

2.

'New REST Project' allows user to create a Project by importing REST

Request.

3.

'Import Project' allows user to import the entire project by locating the
corresponding XML.

4.

'Save All Projects' allows user to save all the opened projects in a single
click.

5.

'Close All Open Projects' closes all the projects opened in that workspace.

6.

'Rename Workspace' allows user to rename the previously created

workspace.

7.

'Switch Workspace' allows user to switch between workspaces.

8.

'Preferences' allows user to customize SOAP UI. We will deal with it in

next section.

9.

'Save Preferences' allows user to save their customized settings. When

SOAP UI opened for the next time, it uses the user saved preferences.

FILE >> PREFERENCES >> HTTP SETTINGS:

Now, let us understand the 'Preferences' from the file menu. Upon
Clicking 'Preferences' from 'File' Menu, the below dialog opens.
o
We will go through the most frequently used 'HTTP Settings' in
details.

1.

Denotes the HTTP Version to be used for request and response.

2.

'User-Agent Header' allows user to can be predefined using this option. If

not defined, it uses the default http client header.

3.

Allows user to specify the compression method. It can be either gzip or

deflate or None.

4.

'If Checked', allows compressed response from hosts.

5.

'If Checked' disables decompression of the compressed responses.

6.

'If Checked' closes HTTP connection for each SOAP Request.

7.

'If Checked', allows user to specify authentication information for the

outgoing requests.

8.

Allows user to restrict the maximum number of bytes to be read from a

response. ZERO corresponds to unlimited size.

FILE >> PREFERENCES >> WSDL SETTINGS:

Now, we will go through the most frequently used 'WSDL Settings' in

details.

1.

Cache WSDLs Turns on and off caching of WSDL's

2.

Generates example values in requests

3.

Allows users to always include optional elements in generated requests

4.

Response messages are printed in the response editor

5.

Allows user to specify a directory containing schema (.xsd) files while

validating WSDL requests. Upon changing the contents of this directory SOAP
UI requires a restart.

6.

For the purpose of preserving space, the minimum message size to be

compressed in the SoapUI project file.

FILE >> PREFERENCES >> UI SETTINGS:

1.

2.

Now, we will go through the most frequently used 'UI Settings' in details.

Closes all projects while launching SOAP UI for better startup-time and
consumes less memory.
Displays description whenever available.

3.
4.

Automatically saves all projects while exiting SOAP UI.

Before saving, SOAP UI creates a backup of the project. If enabled, back
up folder has to be mentioned.

5.

Displays and expands the log tabs upon starting SOAP UI.

6.

Displays the 'start up page' dialog upon starting SOAP UI.

7.

Upon disabling tool tip, disables tool tip when user hovers mouse over
the options/buttons while navigation.

HELP:

Let us take a look at the important Help menu options.

1.

Shows the home page of the online help available

at www.soapui.org
2.
Allows registered users to post questions in forum and get online
help from the community.
3.
Checks for the recent updates and installs if there it is available.

4.
Allows user to navigate to the home page of www.soapui.org
5.
Displays the build and version information of the SOAP UI.
The upcoming tutorials will not only make you understand how to create test
suite, test case, and test steps but also let you test SOAP requests and how to
validate them.

SoapUI Tutorial: Create a Project, Test

Suite, TestCase
Understanding the SOAP Protocol
Before we create an SOAPUI Test case, let us understand basics about the SOAP
Protocol. This will help you use SOAP UI to test SOAP requests and response
effectively.
SOAP stands for Simple Object Access Protocol. Below are the properties of a
SOAP Protocol.

It is an XML-based protocol for communicating between two different

systems.

It is a platform and language independent. Hence, a system developed

using Java can communicate with a system developed in.NET.

SOAP requests/response are transported via HTTP.

In this tutorial we will learn
Learn the SOAP Message FORMAT
Create a Project
Creating Test Suite
Creating Test Case
Test Step Insert
Understanding the Soap Response & Log Panels
Sending Request Manually & Reading Response

Learn the SOAP Message FORMAT

A SOAP message is an ordinary XML document containing the following
elements. Message can be either a request message or a response message.

After setting up the workspace which we had performed in the last tutorial, we
have to create projects, test suites, test cases in order to test a given web
service. Let us understand the steps involved in doing the same.

Create a Project
Step 1: Now depending upon the project, we need to import SOAP/REST
protocol. We will create a new SOAP Project.

Step 2: We will make use following SOAP request

http://www.webservicex.net/CurrencyConvertor.asmx?WSDL
1.
2.

3.

Enter the Project Name

Enter the path of the WSDL request. In this
case http://www.webservicex.net/CurrencyConvertor.asmx?WSDL
Click OK

Note:

Upon checking Create sample request for all operation' creates a

sample request for all the available operations in the given WSDL. As soon as
you enter the WSDL address, this option is checked automatically. You may
uncheck it.

Upon checking Create, a Test Suite for the imported WSDL' creates a test
suite within the project for the imported WSDL.

Upon Checking Relative Path' enables the user to save all the files
relative to the project file.

Step 3: Upon creating the SOAP project with the above-said WSDL, we will be
able to see that there are two operations that will be imported into the project.

Step 4)
1.

Expand the first request and double click on the 'Request1'. It will display
the SOAP request in the XML format.

2.

Enter the From Currency and To Currency

3.

Click on the submit button

4.

Response XML will be displayed right side pane.

You may wonder why create Test Cases? When you can directly test WebService
here
Well, you can send a request for one operation. What about others? How many
combinations of FOREX conversion you can do using this operation. You
have to edit the request for each and every combination.
For example: If you want to convert from GPB to INR instead of USD to INR
You need to edit the operation again. So, one has to create a test suite/cases to
have all possible scenarios tested without having to directly edit the operation
itself.

Creating Test Suite

Step 1: Within the project, testers can create a test suite by performing a right
click on the root of the project.

Step 2: We need to enter the name of the test suite and press OK.

Step 3: The created test suite is displayed the navigator pane as shown below.

Step 4: The test Suite window opens in the Right Pane. As we have just created
there are NO test cases. Hence all options are disabled.

Creating Test Case

Step 1: Within a test suite, we can create multiple tests by performing right click
on the 'test suite' and choosing 'New Test Case'.

Step 2: Specify the name of the test case and click 'OK'.

Step 3: The created test case has zero steps as shown below.
Note: We can see that the test case is added with zero test steps for all kinds of
tests available. Upon adding the test steps the numbers in the bracket would
change automatically. The functional test step

should go into 'Test Steps' while a performance test step should go into 'Load
Test' and a security test step should go into 'security Tests'.
Step 4: We can insert a variety of test steps by performing a right click on test
steps and selecting an appropriate test step as shown below. So if you were to
test a REST WebService, you would select the REST Test Request.

Test Step Insert

Now let us add a test step to validate the imported SOAP request.
Step 1: Add a new step 'SOAP Test Request' as shown below.

Step 2: Enter the step name and click OK.

Step 3: Upon clicking 'OK', a dialog pops up to select the operation to invoke. All
the operations are listed, and user can select the operation that they would like
to invoke.

There are two operations that will be listed. Both the Operations are the
same except the SOAP version used.
CurrencyConvertorSoap uses SOAP version 1.1 where as,

CurrencyConvertorSoap12 uses SOAP version 1.2

The Version does not matter for us in this context. Hence you can select
the one of your choice.

Upon Selecting the operation, click 'Ok'

Step 4: While adding a test case, we can add standard assertions. Assertions
also called as checkpoints/validation points which we will be dealing in detail in
the next tutorial.
We can add following checkpoints/assertions while creating test case. Let us
create a test case with the default option which means creating test step
WITHOUT any of the below validation points

Verifies if the response message is SOAP, upon executing the test.

Verifies if the response schema is valid.
Verifies if the SOAP response contains FAULT.

Step 5: Upon creating the test case, the request XML is shown below. The
structure of the XML is explained within the below snapshot.

Step 6: The test step count is now incremented to one as we have just added
one test step. Similarly upon adding load and security tests step, the

corresponding number would be automatically incremented based on the

number of steps added.

Send Request Manually & Reading

Response
Step 1: We would like to convert the currency from USD to INR.

FromCurrency USD

ToCurrency INR
Next,
1.

We need to enter these inputs in place of the question mark which will be
sent as request XML.

2.

After inputting those values into the corresponding XML tags, click
'submit request' button to check the response.

Step 2: Upon submitting a request the web service request is processed by the
webserver and sends back a response as shown below.
By reading the response, we are able to conclude that 1 unit of USD = 63.525
units of INR.

Understanding the Soap Response & Log

Panels

As explained at the beginning of this tutorial the SOAP messages are

transported via HTTP protocol. Let us take a look at the RAW messages. This will
help us learn how the SOAP request and response were transported by HTTP.
Step 1: Click 'RAW' Tab in both SOAP-UI request Window.
1.

The Request is posted to the webserver. Hence, the POST method of Http
is used.

2.

The SOAP Request is transported in the body of the Http message as

shown below

Step 2: Now click 'RAW' Tab in SOAP-UI Response Window to understand how
the response is sent via HTTP.
1.

After processing the request, the Http response code (200) is shown
which means it is a success. The webserver has processed it successfully.

2.

The SOAP response is sent back to the client as part of the body of the
HTTP message.

A Quick snapshot of the Http Response codes for easy understanding and
debugging. The below table will help you to trouble shoot based on the HTTP
code received from the webserver.
Http Code

Description

1xx:

Informational - This means a request received and continuing process.

2xx:

Success - The action was successfully received, understood, and accepted.

3xx:

Redirection - This means further action must be taken in order to complete the request.

4xx:

Client Error - This means the request contains bad syntax or cannot be fulfilled

5xx:

Server Error - The server failed to fulfill an apparently valid request

Step 3: Let us understand the other information that are displayed in the test
case window.
1.
2.

Represent NO header in the request that is being sent

Represents NO attachments in the request that is being sent to the web
server.

3.

4.

Represents 12 header information and the same are displayed upon

clicking on it.
Represents that there are no attachments from the response message.

LOGS PANE:
Logs pane has the complete information regarding the transaction between the
client and the server. Users will be able to see the tabs of the Log pane as
shown below. We will discuss the most commonly used log panes when working
with SOAP-UI.

SoapUI Log Displays the response information from webserver. The same
information is stored in soapui.log file of the SOAP-UI installed folder under
'bin' directory.

Http Log Displays all the HTTP packet transfer. All the information in 'RAW' is
shown in HTTP log.

Error Log Error log displays all the errors that we have encountered during
the entire project session. The same information is available in 'soapuierrors.log' present in the 'bin' directory of the SOAP UI installed location.
Memory Log This tab monitors the memory consumption and displays it in
the form of the chart as shown below. It is really helpful when there is a
memory intensive operation is performed.

Now that we have created test suite, test case, test step and got a response,
next step is to validate the response. We will deal with types of assertions in the
next tutorial.

Assertions in SoapUI: Complete Tutorial

What Is An Assertion?

Assertion means act of affirming or stating something. It can also be

interpreted as check point or a validation point.

Once a request is sent to a web server a response is received. We need to

validate if the response contains the data that we expect. In order to validate
the response, we need to use assertions.

Types Of Assertion
There are various ways of asserting a response; however we will focus on the
commonly used Assertions types while validating a response. Below are the
ones that are available in Open Source version of SoapUI.

Apart from the ones that are listed above, PRO version also has an inbuilt JDBC
Assertion using which we can assert if the web service has updated the
database correctly.
In this tutorial we will study

Contains Assertion
Not contains Assertion
X Path Match Assertion.
X Query Match Assertion
Scripting Assertion

CONTAINS ASSERTION
Searches for the existence of the specified string. It also supports regular
expression.
We will continue with the same example from the previous tutorial.
Step 1: By Default there are no assertions.

The Number of Assertions are shown in the Assertions Tab.

To add a new assertion, click on 'Add New Assertion' button.

Step 2: Now,
1.

Select the Assertion Category.

2.

Select the Assertion Type.

3.

Click 'Add'

Step 3: Let us validate if the string '63' exist in the response. Click 'OK'
Note : We can also ignore case and add regular expression.

Step 4: Upon adding it, immediately assertion is executed and shows if VALID or
INVALID.

Step 5: Now Let us say we change the content of 'Contains Assertion' to '64' and
see what happens.

Step 6: The Assertion is executed and the result is thrown to the user. Since we
don't have the string "64" within the response, the assertion has failed.

NOT CONTAINS ASSERTION

Searches for the Non-existence of the specified string. It also supports regular
expression.
Step 1: Now after clicking on 'add new assertions' button,
1.

Select the Assertion Category.

2.

Select the Assertion Type In this case 'NOT Contains'

3.

Click 'Add'

Step 2: Let us validate if the string 'FromCurrency' exist in the response. Enter
the string 'FromCurrency' and Click 'OK'

Step 3: As soon as an assertion is added, it executes and displays the result. So

far we have added two assertions hence both the assertions are executed and
displayed the result.

Step 4: Now let us change the contents of the 'Not Contains Assertion' and see
what happens. We will check for the non-existence of the string
"ConversionRateResponse".

Step 5 : The string 'ConversionRateResponse' is actually present in the

response, hence the 'NOT Contains' assertion will fail as shown below.

XPATH MATCH ASSERTION

Uses XPath expression to select the target node and its values. XPath, is an XML
query language for selecting nodes from an XML document.
Step 1: Now after clicking on 'Add New Assertions' button,
1.

Select the Assertion Category.

2.

Select the Assertion Type In this case 'XPath Match'

3.

Click 'Add'

Step 2: Add XPath Window opens.

Before Adding XPath, we need to declare the NameSpace. An XML

namespace is a collection of names, identified by a Uniform Resource
Identifier (URI) reference, which are used in XML documents as element and
attribute names. The same is used in SOAP UI XPath Assertion.

For declaring XML Namespace, we just need to click on 'Declare' button

which would do the job for us else we can also manually declare a
namespace ourselves.

After declaring the namespace we need to refer the XPath using the
created name space.

Upon clicking the 'Declare' button, two namespaces will pop up as we

have two URI's. One of them is the schema URL and the other one
corresponds to the actual web service URL. We need to use the actual
namespace where the web service is located and NOT the schema
namespace while referencing XPath.

declare namespace soap='http://schemas.xmlsoap.org/soap/envelope/';

declare namespace ns1='http://www.webserviceX.NET/';

Step 3: Now we need to enter the XPath of the XML node that we need to
validate.
//ns1:ConversionRateResult Gives us the Value of the node enclosed
between <ConversionRateResult> & </ConversionRateResult> and ns1
corresponds to the declared namespace which is pointing
to'http://www.webserviceX.NET/'
After entering the XML, we need to click on 'Select from current' so that value
from the current response would be picked up for comparison going forward.

Step 4: So far,
1.

After declaring the namespaces, we have entered the XPath of XML node
that we need to Validate.

2.

We Need to click 'Select from Current' to make the current value as the
expected value.

3.

The current value is shown to the user which we can modify if required.

4.

Click 'Save'.

Step 5: The added Assertion will be displayed as shown below.

Xquery Match Assertion

It Uses an Xquery expression to select content from the target property. We
need a much bigger response XML in order to understand XQuery better let us
import one other WSDL as shown
below:http://www.webservicex.net/medicareSupplier.asmx?WSDL
Step 1: Perform a Right click on the existing project and select 'Add WSDL'.

Step 2: Perform a Right click on the existing project and select 'Add WSDL'.
Leave other options as default and Click 'OK' Button.

Step 3: All the operations are listed as shown below.

Step 4: Now let us add a test case within the same test suite that we had
created for testing the currency converter.

Step 5: Enter the name of the test case and Click 'OK' Button

Step 6: The test case is created as shown below.

Step 7: Add a new test step of Type 'Soap Test Request' as shown below.

Step 8: Enter the name of the test step. Let us say Supplier_by_City which
would be more meaningful Click 'OK'.

Step 9: Select the Operation that we would like to validate. In this case it is
'MedicareSupplierSoap -> GetSupplierByCity'. Click 'OK'.

Step 10: Enter the Name of the test case and click 'OK'.

Step 11: The Request XML Outline would be displayed as shown below.

Step 12: Now let us find all supplier information for the 'New York' City.
To do so, add the following lines to your code.
<GetSupplierByCity xmlns="http://www.webservicex.net/">
<City>New York</City>
</GetSupplierByCity>
WSDL in the below URL - http://www.webservicex.net/medicareSupplier.asmx?
op=GetSupplierByCity

Step 13: Upon executing the test, we receive the below response

Step 14: Let us say we need to Validate all the Supplier Number. We can't use
XPath Assertion as we need to have hundreds of XPath Assertion. Hence the
usage of XQuery is inevitable in this case.
XQuery Assertion helps us to validate a group of XML response which are
repetitive in nature.

Step 15: Now click on 'Add an assertion',

1.

Select the 'Assertion Category' Property Content in this case.

2.

Select the Assertion Type as 'XQuery Assertion'

3.

Click 'Add'.

Step 16: Similar to XPath Assertion we need to declare the namespace.

1.

Click 'Declare' Button to automatically allow SOAP UI to declare the

namespace. Upon clicking on declare button a 'POP up' with the message
'declare namespace from schema instead' will be displayed to the user. Click
'Yes' to proceed as shown below.
Note: Upon hitting 'Declare button' you might end up with different URL's as
namespace declaration, however, the actual web service location namespace
is what would be considered for coding.

2.

For retrieving all the Supplier Number, We need to write an XPath Query
and we will place it within < SupplierNumber> and </ SupplierNumber> Tags.

3.

Click 'Select from the Current' which will execute from the current
response.

4.

Upon Clicking 'Select from the Current', All the Supplier Number are
listed.

5.

Click 'Save'.

// Namespace declaration
declare namespace soap='http://schemas.xmlsoap.org/soap/envelope/';

declare namespace ns1='http://www.webservicex.net/';

// Placing the result in Myresult Tags

{
// Iterating through all the supplier number
for $x in
//ns1:GetSupplierByCityResponse/ns1:SupplierDataLists/ns1:SupplierDatas/ns1:SupplierData

//Return all the Supplier number within SupplierNumber Tags.

return {data($x/ns1:SupplierNumber)}
}

Step 17: XQuery Assertion is executed and displays the final result in the
'Assertion' Panel as shown below. Now we have successfully added an Xquery
assertion using which we have validated all the supplier Number information.
The same would be compared against the actuals, every time the request is sent
to the webserver.
Note: The actual values won't be displayed. If all actual values are same as that
of the expected values, then it displays VALID else it will display 'Failed'.

Scripting Assertions
This Assertion technique is the most widely used one as it is extremely difficult
to manage and maintain hundreds of assertions.
SOAP UI uses either Groovy Scripting or JavaScript for scripting assertions. The
scripting technique is adopted for developing a framework for testing SOAP.
Scripting assertions are used under following circumstances.

Scripting allows user to perform some operations before and after

executing a TestCase using set up and tear down methods respectively. Set
up is a procedure which is executed before executing a particular
method(example Object creation and Initialization) while tear down is a
procedure which is executed after executing the method(eg: Destroying
objects and clean up). This feature is not available in other Assertion types
and can be done only through coding.

It allows users to perform opening/closing a Project, inorder to initialize

or clean-up Project related settings and also to work with environmental
variables which is very helpful during scripting.

It helps us in asserting a dynamic Response content.

Scripting assertions are used for creating user defined assertions that are
NOT predefined by SOAP UI.
For Demonstrating Script assertions, we will make use of Currency converter
WSDL, the test case 'INR_to_USD' that we had created earlier.
Step 1 : Steps to add groovy script is same as that of other assertions except
that the assertion is not a predefined one. Instead it is a user defined assertion
which offers greater flexibilities than the inbuilt ones.

Select the Test step against which the assertion has to be added.

Click 'Add Assertion' Button as shown below.

Step 2 : Now select the Assertion category.

1.

In this case it is Script.

2.

Select Script Assertion and there no sub-types associated with it.

3.

Click 'Add'.

Step 2 : The Scripting Dialog opens where user will be able to write user defined
script to validate the response XML.

Step 3 : Now let us write a groovy script to validate the Conversion Rate. The
Script is attached below with the comments embedded. It is recommended to
have knowledge on Java Script or Groovy Script before attempting to write your
own script.
//Define Groovy Utils and holder for validating the XML reponse content
def groovyUtils = new com.eviware.soapui.support.GroovyUtils(context)
def holder = groovyUtils.getXmlHolder(messageExchange.responseContent)

//Define the NameSpace

holder.namespaces["ns"] = "http://www.webserviceX.NET/"

//Get the Value of the Node 'ConversionRateResult' and assign to a variable

def conversionRate = holder.getNodeValue("//ns:ConversionRateResult")

//print the value of the conversion rate in the Output pane

log.info "The conversion value from USD to INR is " + conversionRate

//Comparing the value to print 'Pass' or 'Fail'

if(conversionRate=="63.7854")
{ log.info "Pass" }
else
{ log.info "fail"}

1.
2.

3.

Click 'Execute' Button to trigger the execution.

The output of the Script is shown in the Output pane. It has printed both,
Conversion Value as well as the end result (Pass or Fail)
The Information is displayed that 'Script Assertion Passed'. Click OK.

Note: The final Information pop up will always display with the message 'Script
Assertion Passed' as long as the script is syntactically correct. It has got no
correlation with your assertion within the script.

Click OK

Step 4 : Now the assertion Tab displays all the assertions that we had added for
this test suite with the Status against each one of those.

Step 5 : Now
1.

Select the Test Suite from the Navigator tree

2.

Click 'Run' Button

3.

Results would be displayed for the entire test suite.

When To Use Inbuilt Assertion?

When a Response is short such that it can be validated using one of those
inbuilt assertions.

We can also use Inbuilt Assertion if the response sent from the web
server is always static in nature. If it is dynamic, we will not be able to assert
it using inbuilt assertions.

When usage of inbuilt assertions such as Time out assertions and security
assertions becomes inevitable.

Inbuilt Assertions holds good pretty well for one time usage where tests
need not be repeated.

Assertions Options:

The created assertions can be best controlled with the help of control
panel that is highlighted below.

The created assertions allow testers to configure following things from

the assertions tool box.

Option

Description

The selected Assertion moves up the order.

The selected Assertion moves down the order.

Removes the Selected Assertion

Re-configure/Edit the selected Assertion.

Below are the features available exclusively in PRO Version of SOAP UI.
PRO version also helps us to Group assertions so that we can add one more
layer of validation to the created assertions.
AND: All assertions are evaluated as VALID assertion which will result in
PASSED group condition.OR: At least one of the assertions within the group
must be VALID in order to assert a group PASSED condition.

Pro Version also allows Cloning of Assertions: This option lets testers
to allow copying an assertion to a different test step in the same or a
different project.

Disable/Enable Assertions: This option allows any grouped or

ungrouped assertion to be disabled or enabled. If an assertion is disabled, it
is grayed out and when a Test Case is executed, disabled assertions won't be
executed.

Ungroup Assertions: Any grouped assertions can be ungrouped if

testers decide to do so.

Complete List of Methods available in

various assertion types
Asserting Mechanism
PROPERTY CONTENT

Description

Contains

Searches for the existence of the specified string. It also supports regular expression.

Not Contains

Searches for the Non-existence of the specified string. It also supports regular expres

XPath Match

Uses XPath expression to select the target node and its values.

XQuery Match

Uses an Xquery expression to select content from the target property.

Compliance , Status, Standards

HTTP Download all
resource

Validates the HTML Document after downloading and it holds good to any property
HTML.

Invalid HTTP Status

Codes

Verifies if the HTML response contains a status code that is not in the list of defined

Not SOAP Fault

Verifies if the last received message is not a SOAP Fault. It is very obvious that it is a
SOAP Test Steps.

Schema Compliance

Verifies if the last received message is compliant with the WSDL or WADL standard
definition. Holds good for SOAP and REST Test Steps.

SOAP Fault

Verifies if the last received message is a SOAP Fault. It is the inverse of 'NOT SOAP

SOAP Response

Verifies if the last received response is a valid SOAP Response and holds good for SO
Steps only.

Valid HTTP Status

Codes

Verifies if the HTML response contains a status code that is in the list of defined code
of 'Invalid HTTP Status Codes' Assertion.

WS-Addressing
Request

Verifies if the last received request contains appropriate WS-Addressing Headers.

WS-Addressing
Response

Verifies if the last received response contains appropriate WS-Addressing Headers.

WS-Security Status

Validates if the last received message contains valid WS-Security headers and holds g
SOAP Requests.

Script
Script Assertion

Allows users to execute a custom script to perform user defined validations.

SLA
Response SLA

Validates if the response time of the last received response was within the defined lim

JMS
JMS Status

Verifies if the JMS request of the Test Step has executed successfully and holds good
with a JMS endpoint.

JMS Timeout

Verifies if that the JMS response of a test step did not took longer than the specified d

Security
Sensitive Information
Exposure

Verifies if the response message does not expose sensitive information about the targ
use this assertion for REST, SOAP and HTTP Test Steps.

DOWNLOAD THE SOAPUI PROJECT CONTAINING ABOVE ASSERTIONS

Common Errors and Trouble Shooting :

Use the correct namespace. The Name space should be the URL where
the web service is located.

If an error thrown while developing a scripting assertion, use 'log.info' to

print the contents of the variables

If you haven't got the desired output, verify if a valid input is passed in
the request.
For example, in currency converter, if you input the 'From currency' as 'XXX'
which is not existing, the output throws a fault code as 'SOAP-Client' which
means that the issue is with the parameter that is being passed from the
client side.

Ensure that you use the correct syntax while using XPATH and XQuery
assertion. You should NOT use dot instead of colon while using the above
assertion. The Syntax is //namespace:Tagname and NOT
//namespace.tagname. By doing so, you might end up having a message that
'NO match in current response' even though the tag name is correct.