SoapUI - Quick Guide


Advertisements

SOAP - Introduction

SOAP is the acronym for Simple Object Access Protocol. It is defined by World Wide Web Consortium (W3C) at https://www.w3.org/TR/2000/NOTE-SOAP-20000508 as follows −

SOAP is a lightweight protocol for the exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it; a set of encoding rules for expressing instances of application-defined data types; and a convention for representing remote procedure calls and responses.

SOAP - Important Features

Following are some important features of SOAP.

  • It is a communication protocol designed to communicate via Internet.

  • It can extend HTTP for XML messaging.

  • It provides data transport for Web services.

  • It can exchange complete documents or call a remote procedure.

  • It can be used for broadcasting a message.

  • It is both platform and language independent.

  • It is the XML way of defining what information is sent and how.

  • It enables client applications to easily connect to remote services and invoke remote methods.

Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the initial focus of SOAP is remote procedure calls transported via HTTP. Other frameworks such as CORBA, DCOM, and Java RMI provide similar functionality to SOAP, but SOAP messages are written entirely in XML and are therefore uniquely platform- and language-independent.

SOAP - Messages

A SOAP message is an ordinary XML document containing the following elements −

  • Envelope − Defines the start and the end of the message. It is a mandatory element.

  • Header − Contains any optional attributes of the message used in processing the message, either at an intermediary point or at the ultimate end-point. It is an optional element.

  • Body − Contains the XML data comprising the message being sent. It is a mandatory element.

  • Fault − An optional Fault element that provides information about errors that occur while processing the message.

All these elements are declared in the default namespace for the SOAP envelope −

https://www.w3.org/2001/12/soap-envelope

The default namespace for SOAP encoding and data types is −

https://www.w3.org/2001/12/soap-encoding

Note − All these specifications are subject to change. Thus, keep updating yourself with the latest specifications available on the W3 website.

SOAP - Message Structure

The following block depicts the general structure of a SOAP message −

<?xml version = "1.0"?> 
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">  
   <SOAP-ENV:Header> 
      ... 
      ... 
   </SOAP-ENV:Header>  
   <SOAP-ENV:Body> 
      ... 
      ... 
      <SOAP-ENV:Fault> 
         ... 
         ... 
      </SOAP-ENV:Fault>  
   </SOAP-ENV:Body>  
</SOAP_ENV:Envelope> 

SOAP - What is REST?

REST is the acronym for Representational State Transfer. It can be defined as an architectural style of designing softwares. REST is not a specification or W3C standard. Hence, it is easier to work with RESTful Services. It doesn’t require any middleware specification framework.

REST - Important Features

Following are some important features of REST.

  • It relies on stateless, client-server, cacheable communication protocol – virtually in all cases, HTTP is used.

  • It is light-weighted alternative of WebService and RPC (Remote Procedure Call) like SOAP-WSDL.

  • It represents everything in unique ID or URIs.

  • It makes the use of standard HTTP methods, such as GET, POST, PUT, DELETE.

  • It links sources together.

  • REST resources could have multiple representations.

  • Any named information is considered as a Resource. For example: An image, a person, a document, all can be considered as an example of resource and represented as a unique ID or a URI.

  • World Wide Web itself, based on HTTP, can be viewed as REST based architecture.

REST services are Platform and Language independent. Since it is based on HTTP standards, it can easily work in the presence of firewalls. Like WebServices, REST doesn’t offer any inbuilt security, session management, QoS guarantee but these can be added by building on top of HTTP. For encryption, REST can be used on top of HTTPS.

SoapUI - Introduction

SoapUI is a tool which can be used for both functional and non-functional testing. It is not limited to web services, though it is the de-facto tool used in web services testing.

SoapUI - Important Features

Following are some important features of SoapUI.

  • It is capable of performing the role of both client and service.

  • It enables the users to create functional and non-functional tests quickly and in an efficient manner using a single environment.

  • It is licensed under the terms of the GNU Leaser General Public Licence (LGPL).

  • It is purely implemented using JAVA platform.

  • It supports Windows, Mac, multiple Linux dialects.

  • It allows testers to execute automated functional, regression, compliance, and load tests on different Web API.

  • It supports all the standard protocols and technologies to test all kinds of APIs.

SoapUI can be used to test complete RESTful API and SOAP Web Service testing. It supports Functional Testing, Performance Testing, Interoperability Testing, Regression Testing, Load Testing, and much more.

It is user friendly as well as it is easy to convert functional test into non-functional tests such as Load, Stress testing.

SoapUI - Capabilities

SoapUI is rich in the following five aspects −

  • Functional Testing
  • Security Testing
  • Load Testing
  • Protocols and Technologies
  • Integration with other tools

Let’s learn more about each of these capabilities.

Functional Testing

  • SoapUI allows the testers to write functional API tests in SoapUI.

  • SoapUI supports Drag-Drop feature that accelerates the script development.

  • SoapUI supports debugging of tests and allows testers to develop data driven tests.

  • SoapUI supports multiple environments making it easy to switch among QA, Dev, and Prod environments.

  • SoapUI allows advanced scripting (the tester can develop their custom code depending on the scenarios).

Security Testing

  • SoapUI performs a complete set of vulnerability scan.

  • SoapUI prevents SQL Injection to secure the databases.

  • SoapUI scans for stack overflows, caused by documents huge in size.

  • SoapUI scans for cross-site scripting, which occurs when service parameters are exposed in messages.

  • SoapUI performs fuzzing scan and boundary scan to avoid erratic behavior of the services.

Load Testing

  • SoapUI distributes the load tests across n number of LoadUI agents.

  • SoapUI simulates high volume and real-world load testing with ease.

  • SoapUI allows advanced custom reporting to capture performance parameters.

  • SoapUI allows end-to-end system performance monitoring.

Protocols & Technologies

SoapUI supports a wide range of protocols −

  • SOAP – Simple Object Access Protocol
  • WSDL – Web Service Definition Language
  • REST – Representational State Transfer
  • HTTP – Hyper Text Transmission Protocol
  • HTTPS – Hyper Text Transmission Protocol Secured
  • AMF – Action Message Format
  • JDBC – Java Database Connectivity
  • JMS – Java Messaging Service

Integration with Other Tools

  • Apache Maven Project
  • HUDSON
  • JUnit
  • Apache – Ant and more….

SoapUI - NG Pro

SoapUI is an open source free version tool with basic features of testing, while SoapUI NG Pro is a commercialized tool having advanced features of reporting, data-driven functionality and much more.

Comparison

The following table compares and contrasts the various features of SoapUI and SoapUI NG Pro.

Features SoapUI SoapUI NG Pro
Supported Technologies
SOAP Yes Yes
WSDL/WADL Yes Yes
REST Yes Yes
JMS Yes Yes
AMF Yes Yes
JDBC Yes Yes
HTTP Yes Yes
General Features
Standalone Application Yes Yes
Multi Environment Support No Yes
Floating Licence No Yes
WSDL Coverage No Yes
Request/Response Coverage No Yes
Message Assertion Yes Yes
Test Refactoring No Yes
Running multiple tests Yes Yes
Data Source Driven Test No Yes
Scripting Libraries No Yes
Unit Reporting No Yes
Manual test steps Yes Yes
Reporting
Junit Reports No Yes
Report Data Export No Yes
WSDL HTML Report Yes Yes
Test Suite Coverage No Yes
Test Case Coverage No Yes
Assertion Coverage No Yes
Message Recording Coverage No Yes

SoapUI - Installation & Configuration

SoapUI is a cross-platform tool. It supports Windows, Linux, and Mac operating systems.

Prerequisites

  • Processor − 1GHz or higher 32-bit or 64-bit processor.

  • RAM − 512MB of RAM.

  • Hard Disk Space − Minimum 200MB of hard disk space for installation.

  • Operating System Version − Windows XP or later, MAC OS 10.4 or later.

  • JAVA − JAVA 6 or later.

Download Process

Step 1 − Go to www.soapui.org and click Download SoapUI.

Download

Step 2 − Click ‘Get It’ to download SoapUI Open Source. It will start downloading 112MB .exe file in the system. Wait till the download process is complete.

Testing Downloads

Installation Process

Step 1 − After downloading, run the .exe file as “Run as administrator”.

Exe File

Windows will start the set up process as shown in the following screenshot.

Install Wizard

Step 2 − Once set up, the process window displays the following screen, click Next.

Process Window

Step 3 − Accept the license agreement and click Next.

License Agreement

Step 4 − Choose the installation directory or keep it as the default path selected by the system. Click Next.

Installation Directory

Step 5 − Choose the components that you want to install. Click Next.

Component

Step 6 − Accept the License Agreement for HermesJMS and click Next.

License for Hermes

Step 7 − Select the target directory to save tutorials and click Next.

Target Directory

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

Default Location

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

Desktop Icon

Now, the installation starts. It will take a few minutes to complete.

Installation Starts

Step 10 − After completion of installation, click Finish in the following wizard.

Installer

Upon clicking on Finish, SoapUI is launched.

  • Menu bar
  • Tool bar
  • Project Navigation Bar
  • Workspace Properties
  • Log Panel
Getting Started

Configuration Process

The first step is to create a workspace that can contain multiple projects.

Step 1 − Go to File → New Workspace.

Workspace

Step 2 − Add the name of workspace and click OK.

Sample Workspace

Step 3 − Now, select the path where workspace xml will be saved.

Step 4 − Select the path and click Save.

New Workspace

Workspace is created as shown in the following screenshot. Workspace properties is also exhibited.

Properties

SoapUI - WSDL

WSDL stands for Web Services Description Language. It is a standard format for describing a web service. WSDL was developed jointly by Microsoft and IBM. WSDL is pronounced as 'wiz-dull' and spelled out as 'W-S-D-L'.

WSDL ─ A Brief History

WSDL 1.1 was submitted as a W3C Note by Ariba, IBM, and Microsoft for describing services for the W3C XML Activity on XML Protocols in March 2001.

WSDL 1.1 has not been endorsed by the World Wide Web Consortium (W3C), however it has just released a draft for version 2.0 that will be a recommendation (an official standard), and thus endorsed by the W3C.

WSDL ─ Points to Note

WSDL is an XML-based protocol for information exchange in a decentralized and distributed environment. Some of the other features of WSDL are as follows −

  • WSDL definitions describe how to access a web service and what operations it will perform.

  • It is a language for describing how to interface with XML-based services.

  • It is an integral part of Universal Description, Discovery, and Integration (UDDI), an XML-based worldwide business registry.

  • WSDL is the language that UDDI uses.

WSDL Usage

WSDL is often used in combination with SOAP and XML Schema to provide web services over the Internet. A client program connecting to a web service can read the WSDL to determine what functions are available on the server. Any special datatypes used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the functions listed in the WSDL.

Understanding WSDL

WSDL breaks down the web services into three specific, identifiable elements that can be combined or reused once defined.

The three major elements of WSDL that can be defined separately are −

  • Types
  • Operations
  • Binding

A WSDL document has various elements, but they are contained within these three main elements, which can be developed as separate documents and then they can be combined or reused to form complete WSDL files.

In this tutorial, we are following CurrencyConverter WSDL: http://www.webservicex.net

Format and Elements

CurrencyConverter WSDL will look like the following −

Currency Converter

Response

Binding Elements

WSDL ─ Port Type

The <portType> element combines multiple message elements to form a complete one-way or round-trip operation. For example, a <portType> can combine one request and one response message into a single request/response operation. This is most commonly used in SOAP services. A portType can define multiple operations.

Example

Port Type
  • The portType element defines a single operation, called ConversionRate.
  • The operation consists of a single input message ConversionRateHttpPostIn.
  • The operation for Output message is ConversionRateHttpPostOut.

Patterns of Operation

WSDL supports four basic patterns of operation −

One Way

The service receives a message. The operation therefore has a single input element. The grammar for one-way operation is −

<wsdl:definitions .... >  
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions> 

Request ─ Response

The service receives a message and sends a response. The operation therefore has one input element, followed by one output element. To encapsulate errors, an optional fault element can also be specified. The grammar for a request-response operation is −

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions> 

Solicit ─ Response

The service sends a message and receives a response. The operation therefore has one output element, followed by one input element. To encapsulate errors, an optional fault element can also be specified. The grammar for a solicit-response operation is −

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions> 

Notifications

The service sends a message. The operation therefore has a single output element. Following is the grammar for a notification operation −

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions> 

WSDL ─ Binding & Service

The <binding> element provides specific details on how a portType operation will actually be transmitted over the wire.

  • The bindings can be made available via multiple transports including HTTP GET, HTTP POST, or SOAP.

  • The bindings provide concrete information on what protocol is being used to transfer portType operations.

  • The bindings provide information where the service is located.

  • For SOAP protocol, the binding is <soap:binding>, and the transport is SOAP messages on top of HTTP protocol.

  • You can specify multiple bindings for a single portType.

Binding Services

Service

The <service> element defines the ports supported by the web service. For each of the supported protocols, there is one port element. The service element is a collection of ports.

Web service clients can learn the following from the service element −

  • Where to access the service,
  • Through which port to access the web service, and
  • How the communication messages are defined.

The service element includes a documentation element to provide human-readable documentation.

<wsdl:service name = "CurrencyConvertor">
   <wsdl:port name = "CurrencyConvertorSoap" binding = "tns:CurrencyConvertorSoap">
      <soap:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorSoap12"binding = "tns:CurrencyConvertorSoap12>
      <soap12:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorHttpGet" binding = "tns:CurrencyConvertorHttpGet">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:portname = "CurrencyConvertorHttpPost"binding = "tns:CurrencyConvertorHttpPost">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port> 
</wsdl:service> 

SoapUI - Project

The SoapUI project is the central point in all SoapUI testing. Once the project is created, the user can create and run functional tests, load tests, create mock services, and much more.

In this chapter, we will discuss two things - How to −

  • Create a SOAP project
  • Add a WSDL

Create a SOAP Project

Step 1 − In the navigator on the left side of the screen, right-click on the “Project” and select “New SOAP Project”.

SOAP Project

Or go to File and select New Soap Project.

Select File

On selection, a new pop-up window opens -New Soap Project.

Step 2Project Name: Enter a project name - it is the user input field. Initial WSDL: It is not mandatory. It depends on the user. The user can provide WSDL or add after the creation of Project.

In this case, we create a project and add the WSDL later.

Create Project

Step 3 − Click OK. It will create a new project and will be visible on the left side navigation panel.

Navigation Panel

Add a WSDL

SOAP Projects are based on WSDL. It is not necessary to start by importing a WSDL, but it makes testing easier since the WSDL contains all information that is required to test a webservice such as information about the requests and responses, what they contain and much more, which simplifies SoapUI testing.

Step 1 − To add a WSDL, right-click on the Project name (SOAP – Example) and select Add WSDL.

Add WSDL

On selection, WSDL wizard is displayed.

Step 2WSDL Location: Enter a WSDL as http://www.webservicex.com or browse it from the computer.

Step 3 − As soon as WSDL is entered, 3 checkboxes – Create Requests, Create TestSuite, Create MockServices will be enabled. Based on requirement, the user can check one or multiple checkboxes.

By default, the checkbox of Create Requests is checked.

Create Request

Step 4 − Click OK. WSDL is added successfully in the Project. It can be verified by observing the left navigation panel. Inside the project, there are multiple operations, and requests are added according to WSDL.

Multiple Operation

Details View

To get more details of the Project, double-click the Project Name, it will open a new window with various details.

In Overview tab, various information is provided such as −

  • File Path − It displays the location of the saved project xml.

  • Interface Summary − Interface name and WSDL associated with it.

  • Test Summary − It displays test suites, test cases, test steps, assertions added to the project.

Detail View

The user can double-click the Interface Name to get the interface details. It will open a new window and display the WSDL related information. These are very useful for browsing and examining a WSDL.

In Overview tab, it lists WSDL Definitions, Definition parts, and Operation details.

Definition Part

Similarly, Service Endpoints lists the details of endpoints.

Endpoint

In WSDL Content tab, all details of WSDL in XML/schema format are provided as shown in the following screenshot.

Content Tab

SoapUI - TestSuite

TestSuite is a collection of Test Cases that can be used for grouping functional tests into logical units. Any number of TestSuites can be created inside a SoapUI project to support massive testing scenarios.

Creation of TestSuite

Step 1 − Within a project, right-click on the interface (next to the project name) and then click ‘Generate TestSuite’.

Here, SOAP – Example is a Project name while CurrencyConvertorSoap and CurrencyConvertorSoap12 are interfaces.

Generate Testsuite

Step 2 − A new wizard opens. Select the choices based on the requirement.

Step 3 − Once the selection is made, click OK.

Create Testsuite

Step 4 − Check the checkbox of Generate LoadTest. This will generate a LoadTest for each TestCase created in this TestSuite.

Step 5 − Enter the TestSuite name in the new wizard and then click OK.

Testsuite Name

The created TestSuite displays in the navigation panel as shown in the following screenshot.

Display Navigation

Step 6 − Double-click the TestSuite Name, and the TestSuite window opens at the right panel. Since there no TestCases are added, it is blank.

Right Panel

TestSuite properties can be seen at the bottom of the Navigation Panel. New Custom Properties can be added at the TestSuite level.

Custom Properties

SoapUI - TestCase

A TestCase is a collection of TestSteps assembled to test some specific aspect of web service(s). The user can add n number of TestCases to a TestSuite and even modularize them to call each other for complex testing scenarios.

Creation of TestCase

Step 1 − Within a TestSuite, the user can add multiple test cases. Right-click on the Test Suite and select “New Test Case”.

New Testcase

Step 2 − Enter the name of the TestCase and click OK.

TestCase Name

The created TestCase has zero test steps as of now. TestCase is added with zero TestSteps for all kinds of tests available. Once the TestSteps are added, the numbers in the bracket would change automatically. The functional TestStep should go into 'Test Steps' while a performance TestStep should go into 'Load Test', and a security TestStep should go into 'Security Tests'.

Functional Test

Step 3 − Double-click the TestCase Name, and a TestCase window opens on the right hand side panel. Since there are no TestSteps added, it is blank as seen in the following screenshot.

Testcase Window

SoapUI - TestStep

TestSteps are the "building blocks" of functional tests in SoapUI. These are added to a TestCase and used to control the flow of execution and validate the functionality of the web service(s) to be tested.

Insertion of TestStep

Step 1 − Right-click on TestSteps. Add Step and select an appropriate TestStep from the list. For example, if the user has to test a REST WebService, the user would select the REST Test Request.

Add Step

Step 2 − Add a TestStep to validate the imported SOAP request by selecting TestSteps → Add Step → SOAP Request.

Step 3 − Enter the name of the TestStep and click OK in the wizard.

Specify Name

Upon clicking 'OK', a dialog box pops up to select the operation to invoke. All the operations are listed, and the users 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 whereas, CurrencyConvertorSoap12 uses SOAP version 1.2.

Step 4 − Select first one – CurrencyConvertorSoap and click OK.

Testrequest

While adding a TestCase, different standard assertions can be added. Assertions are also called as checkpoints/validation points of SOAP request/response.

Step 5 − Let us create a TestCase with a default option which means creating a TestStep WITHOUT any of the following 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.
Add Request to Case

Step 6 − Upon clicking OK, the following request XML screenshot pops up.

Request XML

The test step count is now incremented to one as a functional TestStep added. Similarly, upon adding load and security TestSteps, the corresponding number automatically increases based on the number of steps added.

Incremented

SoapUI - Request & Response

Request Setup

Here, we will perform the conversion of the currency from INR to USD.

  • FromCurrency – INR
  • ToCurrency – USD

Next, enter these inputs in the place of the question mark which will be sent as a request XML. After placing those values into the corresponding XML tags, click 'Submit request' button to check the response.

Submit Request

Response

Upon submitting a request, the web service request is processed by the web-server and sends back a response as shown in the following screenshot.

By reading the response, it can be concluded that 1 unit of INR = 0.0147 units of USD.

Web-server Response

HTTP Request

SOAP messages are transported by HTTP protocol. To view the HTTP request, click RAW at SoapUI Request window (left side).

HTTP Request

The Request is posted to the web-server. Hence, the POST method of Http is used.

The SOAP Request is transported in the body of the http message, which is shown as follows.

POST http://www.webservicex.com/currencyconvertor.asmx HTTP/1.1 
Accept-Encoding: gzip,deflate 
Content-Type: text/xml;charset = UTF-8 
SOAPAction: "http://www.webserviceX.NET/ConversionRate" 
Content-Length: 353 
Host: www.webservicex.com 
Connection: Keep-Alive 
User-Agent: Apache-HttpClient/4.1.1 (java 1.5) 

HTTP Response

Click the 'RAW' Tab in SOAP-UI Response Window to understand how the response is sent via HTTP.

After processing the request, the http response code (200) is shown which means it is a success. The web-server has processed it successfully.

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

HTTP/1.1 200 OK 
Cache-Control: private, max-age = 0 
Content-Type: text/xml; charset = utf-8 
Content-Encoding: gzip 
Vary: Accept-Encoding 
Server: Microsoft-IIS/7.0 
X-AspNet-Version: 4.0.30319 
X-Powered-By: ASP.NET 
Date: Sun, 22 Jan 2017 19:39:31 GMT 
Content-Length: 316 

Http Response

Following HTTP codes are used to send in responses by the Web-server and are very useful for debugging.

HTTP Code Description

1xx:

Informational − This means a request was received and there is a 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 a bad syntax or cannot be fulfilled.

5xx:

Server Error − The server failed to fulfil an apparently valid request.

SoapUI - Properties

Properties are a central aspect of more advanced testing with SoapUI. Functional Testing properties are used to parameterize the execution and functionality of tests.

  • Properties can be used to hold the endpoints of services, making it easy to change the actual endpoints used during test execution.

  • Properties can be used to hold authentication credentials, making it easy to manage these in a central place or an external file.

  • Properties can be used to transfer and share session ids during test execution, so multiple test steps or test cases can share the same sessions.

Defining Properties

Properties can be defined at many levels in a project.

  • Properties that are common at the project-level can be defined at the Project level.

  • Similarly, TestSuite and TestCase specific properties can be defined at their respective levels.

  • Project specific properties are defined in the Custom Properties tab.

Defining Properties

For example, a property “ToCurrency” can be defined at the Project level by clicking the "+" symbol and entering the Property Name and Value.

ToCurrency

Accessing Property

A property can be accessed anywhere in the Project by using Property Expansion.

Structure would be as −

  • ${#Project#PropertyName} – For Project Level

  • ${#TestSuite#PropertyName} – For Test Suite level

  • ${#TestCase#PropertyName} – For Test Case level

  • ${TestStepName#PropertyName} – For Test Step level

  • ${#MockService#PropertyName} – For MockService property

  • ${#Global#PropertyName} – For Global properties, found in File → Preference → Global properties tab. This property can be used across all projects

  • ${#System#PropertyName} – For System Property, found in Help → System properties

  • ${#Env#PropertyName} – For environment variable

The same structure can be placed at Request XML to get the value of specific attribute during run-time.

Same Structure

A property can also be considered as a variable in a computer program. If the user wants to define something which can be used somewhere else too, Properties are very useful. Properties can also define dynamically but it is dependent on Groovy script.

SoapUI - Property Transfer

Sometimes there is a requirement to extract some value from a response message and include it in the subsequent request(s). In such a case, we need to have a mechanism to retrieve a specified value and transfer it to the other elements of the project. SoapUI supports such functionality through the Property Transfer TestStep.

Adding Property Transfer

Step 1 − Select the TestCase or TestStep, right-click → Add Steps → Property Transfer.

Adding Property

Step 2 − Enter the TestStep name and Click OK.

Rate Transfer

Step 3 − RateTransfer step is added and a new wizard will open.

New Wizard

Step 4 − Click the Adds a new property transfer icon + at the top-left corner in the property transfer window. It will be prompted to enter a name for the transfer. Enter Rate and click OK.

Rate

Transferring a Property

Once the transfer is created, Source and Target panes need to specify the relevant XPath expressions to extract and replace the property values. In the drop-down box next to Source, various levels of SoapUI projects are listed that can be used as the source of property transfers. By default, the closest TestStep will be shown.

In this case, it is the Request – INR to USD TestStep. The drop-down list next to Property shows the source property which is used in the transfer, which can either be request, response, or service endpoint.

Transfer Property

Step 1 − Select Response and go to Path language. The user can select XPath, Xquery, or Jason to define the property. In this case, select XPath.

Path Language

Step 2 − To get the declaration of source xml, click ns and specify XPath.

Step 3 − Specify the target where the value extracted from the above XPath expression is to be transferred. The target pane is used at the bottom of the property transfer window for that.

Step 4 − Transfer extracted value of ConversionRateResult from response of RequestINRtoUSD step.

Target − Properties

Property − ConversionRate (a new property added, it doesn’t have any value initially).

Target Property

Step 5 − Once the test case runs successfully, property “ConversionRate” gets updated based on the response.

Following is the screenshot initially.

Conversion Rate

Following is the screenshot after a successful run.

Successful Run

Similarly, Target may be a next Request XML. If Target is SOAP request, we need to provide XPath to identify the target attribute.

SoapUI - Logs Pane

Logs pane stores the complete information regarding the transaction between the client and the server. Users will be able to see the various tabs of the log pane. We will discuss the most commonly used log panes while working with SoapUI in this chapter.

Transaction Properties

SoapUI Log

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

UI Log

HTTP Log

HTTP log displays all the HTTP packet transfer. All the information in 'RAW' is shown in HTTP log.

Http Packet Transfer

Error Log

Error log displays all the errors encountered during the entire project session. The same information is available in 'soapui-errors.log' present in the 'bin' directory of the SoapUI installed location.

Memory Log

This tab monitors the memory consumption and displays it in the form of the chart as shown in the following screenshot. It is really helpful when a memory intensive operation is performed.

Memory Log

SoapUI - Assertions

Assertion can be interpreted as a checkpoint or a validation point. Once a request is sent to a web server, a response is received. It is required to validate the response which contains the data as expected or not. In order to validate the response, SoapUI has an assertions feature.

Points to Note

  • Assertions are used to validate the message received by a TestStep during execution.

  • It compares the part of the message or the entire message to some expected value.

  • Any number of assertions can be added to a TestStep, each validating some different aspect and content of the response message.

  • After a TestStep executes, all its assertions are applied to the received response and if any of them fail the TestStep is marked as failed in the TestCase view.

  • Failed entry shows in the test execution log.

Execution Log

Type of Assertions

SoapUI supports a wide range of assertions in response.

Following are the list of assertions supported by SoapUI.

Assertion Description
Property Content
Contains Checks for the existence of the specified string. It also supports regular expression.
Not Contains Checks for the non-existence of the specified string. It also supports regular expression.
XPath Match Uses XPath expression to select the target node and its values. Compares the result of an XPath expression to an expected value.
XQuery Match Uses an Xquery expression to select the content from the target property. Compares the result of an XQuery expression to an expected value.
Compliance, Status, Standards
HTTP DOwnload All Resource Downloads all resources referred to be an HTML document (images, scripts, etc.) and validates that they are all available. Applicable to any property containing HTML.
Invalid HTTP Status Codes Checks that the target TestStep received an HTTP result with a status code not in the list of defined codes. Applicable to any TestStep that receives HTTP messages.
Not SOAP Fault Validates that the last received message is not a SOAP Fault. Applicable to SOAP TestSteps.
Schema Compliance Validates that the last received message is compliant with the associated WSDL or WADL schema definition. Applicable to SOAP and REST Test Steps. The schema definition URL supports Property Expansions (e.g. ${#System#my.wsdl.endpoint}/services/PortType? wsdl).
SOAP Fault Validates that the last received message is a SOAP Fault. Applicable to SOAP TestSteps SOAP Request - validates that the last received request is a valid SOAP Request. Applicable to MockResponse Test Steps only.
SOAP Response Validates that the last received response is a valid SOAP Response. Applicable to SOAP TestRequest Steps only.
Valid HTTP Status Codes Checks that the target TestStep received an HTTP result with a status code in the list of defined codes. Applicable to any TestStep that receives HTTP messages.
WS-Addressing Request Validates that the last received request contains valid WS-Addressing Headers. Applicable to MockResponse TestSteps only.
WS-Addressing Response Validates that the last received response contains valid WS-Addressing Headers. Applicable to SOAP TestRequest Steps only.
WS-Security Status Validates that the last received message contained valid WS-Security headers. Applicable to SOAP Test Steps.
Script
Script Assertion Allows the users to execute a custom script to perform user-defined validations. Applicable to TestSteps only (i.e. not properties)
SLA
Response SLA Validates if the response time of the last received response was within the defined limit. Applicable to Script TestSteps and TestSteps that send requests and receive responses.
JMS
JMS Status Validates that the JMS request of the target TestStep is executed successfully. Applicable to Request TestSteps with a JMS endpoint.
JMS Timeout Validates that the JMS statement of the target TestStep did not take longer than the specified duration. Applicable to Request TestSteps with a JMS endpoint.
Security
Sensitive Information Exposure Verifies if the response message does not expose sensitive information about the target system. We can use this assertion for REST, SOAP and HTTP TestSteps.
JDBC
JDBC Status Validates that the JDBC request of the target TestStep executed successfully. Applicable to JDBC TestSteps only.
JDBC Timeout Validates that the JDBC statement of the target TestStep did not take longer than the specified duration. Applicable to JDBC TestSteps only.

SoapUI - Troubleshooting

In SoapUI, the users face many generic common issues that could be sort out with a little alertness. Some of these most common issues are the following −

Issue − Namespace is defined wrongly. Use the correct namespace. The namespace should be the URL where the web service is located.

Solution − If an error is thrown while developing a scripting assertion, use 'log.info' to print the contents of the variables.

Issue − If a fault-code is received as response XML, it may be due to the invalid input.

Solution − Verify the input of request XML.

Example − In the currency converter, if the input of the 'FromCurrency' is '123' 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.

Request

Parameter

Response

Fault Code

Issue − No match in current response when using XPath or XQuery.

Solution

  • Use the correct syntax while defining XPath or XQuery.
  • Verify colon is used and not dot while declaring the namespace.
  • Ensure that XPath and XQuery are correct.
Not Match Response

SoapUI - Performance Testing

Performance testing is one of the most common important checkpoints in Web Service testing. Performance Testing is defined as artificially creating or simulating the load and measuring how the environment handles it.

This means it doesn’t necessary have to be how a system performs under high load, it can also be how it performs under base load or expected load. It doesn’t even have to be structured, automated, or created in TestWare such as SoapUI; simply refreshing the web browser over and over again very fast is also a Load Test.

Types of Performance Testing

Following are the types of Performance Testing −

  • Baseline Testing − Examines how a system performs under expected or normal load and creates a baseline against which the other types of tests can be compared.

  • Load Testing − Includes increasing the load and see how the system behaves under higher load. During Load Tests, the user can monitor response times, throughput, server condition and much more. The goal of Load Testing is not to break the target environment.

  • Soak Testing − The goal of testing is to make sure no unwanted behavior emerges over a longer period of time.

  • Scalability Testing − Scalability Testing is very much like Load Testing, however instead of increasing the number of requests, it increases the size or the complexity of the requests sent. For example, sending large requests, large attachments, or deeply nested requests.

Key Aspects in Web Service

Two aspects stand out in the unique characteristics of Web Service performance.

First Aspect

On the server side, XML/JSON processing is going on, both XML/JSON parsing and serialization. The thing that often fails first is the processing of the payloads. The reasons of failure can be multifold; it can be in the platform, the weaknesses of the application server, or it can be an implementation issue in the shape of unnecessarily complex WSDLs. It could also mean that the code is making a request to a database that is slow in responding.

Testing Aspect − The complexity of parsing the XML/JSON payload means that there is a need to put extra focus on Scalability Testing. It also means that WSDLs should be examined closely. If the requests and responses are either complex or larger, or if they include large attachments, focus should be on emphasizing the complexity and see how it behaves under load.

Second Aspect

Another factor frequently encountered is security. Secure sites behind HTTPS have considerably lower performance and in Web Service testing we can add a layer of WSSecurity to the layer of HTTP security, decreasing the performance even more.

Testing Aspect − The issue of security means, there is a need to focus on performing testing of requests that are secure. If the entire Web Service is secure it means Load Testing is more important, especially if WS-Security and token handling is used.

SoapUI - Load Testing

Load testing is a specific form of performance testing that is conducted to assess the behavior of the system under a specific load. In SoapUI, we generally use the term "load testing" for all types of non-functional testing, however SoapUI supports all types of performance assessments of web services such as load, stress, and endurance.

Points to Note

  • Load testing is quite unique in SoapUI; a functional test case that allows creating and modifying performance tests quickly.

  • The main differentiator is that performance tests in SoapUI generally is created from the existing functional tests. This allows to quickly create advanced performance tests.

  • Web Service performance can be validated under different load scenarios. Maintain functional validations to see that they don't break under load, run several load tests simultaneously to see how they affect each other and much more.

Creation of Load Test

Step 1 − Right-click Functional Test Case and select New Load Test.

New Load Test

Step 2 − Enter the name of Load Test and click OK in the dialog wizard.

Dialog Wizard

Load Test will open and the Load Test is created as shown in the following screenshot.

Open Load Test

Execution of Load Test

When a new Load Test is created, it is preconfigured to run for 60 seconds (top right) with 5 threads using the Simple load strategy.

Modify these values as per requirement and Run. Note − The user should be aware of Load Testing configuration and concepts.

Load Configuration

The user will see the statistics table in the middle, beginning with collecting data and after 60 seconds should have a finished LoadTest.

Statistic Table

Adding an Assertion

Step 1 − In the LoadTest editor, select the LoadTest Assertion tab at the bottom of the editor.

Load Test Assertion

Step 2 − Click the Add Assertion button in the LoadTest Assertion menu bar to add an assertion.

Assertion Button

Step 3 − The Add Assertion dialog will open. Select Step Maximum. Select Maximum sets a Max Time in milliseconds that the responses are allowed to take, if the time exceeds what we've set, the test will fail. Click OK.

Max Error

Step 4 − The TestStep Max Assertion window will open. As seen in the following screenshot, we allow a max response of one second, 1000 milliseconds. Let's not modify anything. Click Ok.

Step Maximum

The Step Maximum assertion will now be successfully added.

Added Maximum

Step 5 − Now run the test again. If the responses take too long, you should see the numbers in the err column add up quickly.

Error Column

SoapUI - RESTful Web Services

A web service is a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks such as the Internet in a manner similar to inter-process communication on a single computer. This interoperability (e.g., between Java and Python, or Windows and Linux applications) is due to the use of open standards.

Web services based on REST Architecture are known as RESTful Web Services. These web services use HTTP methods to implement the concept of REST architecture. A RESTful web service usually defines a URI (Uniform Resource Identifier), which is a service that provides resource representation such as JSON and a set of HTTP methods.

All REST testing capabilities of SoapUI are based on a logical representation known as REST service. We should not confuse this with the term "service" here, since it is not a service implementation but a mapping of the RESTful service that is being invoked. We can add as many REST Services as we can in a SoapUI project. Each represents a particular RESTful service. They are as follows −

SoapUI - JDBC Connection

SoapUI allows managing database operation using a TestStep called JDBC Request.

Step 1 − Right-click on TestStep and select Add Step → JDBC Request.

JDBC Request

Step 2 − Enter the step name and click OK.

New Step

JDBC Step is added. Double-click step, and the JDBC wizard will open.

JDBC Wizard

To create a JDBC connection, the user needs to provide valid Driver and Connection String. These parameters are used to identify the type of database and create a connection to use the database.

For MySQL, database driver can be com.mysql.jdbc.Driver. Similarly, for other database, there is a predefined driver that can be found by the document section of the database.

Step 3 − Connection String should be in the following format −

Jdbc:mysql://[host]:[port]/[database]?[property][=value] 

Here, property is the username and password along with other parameters required to connect with a database.

For example,

jdbc:mysql://localhost:8089/xxx_DB?user=root&password=root 

Step 4 − Click Test Connection. On successful connection, it will display SUCCESS otherwise provide the details of failure.

Test Connection

SoapUI - JDBC Property

JDBC has its own Add property section that can be used as a variable in SQL Query.

Let’s see how it behaves −

Suppose, SQL Query that needs to perform in JDBC step is Select * from Currency where CurrencyCode = ‘xxx’.

In this scenario, CurrencyCode can be changed based on the request input. If the user provides a hard-coded value, JDBC step won’t execute for those currency given in request.

To overcome such scenarios, JDBC supports the add property, where a property Code can be defined and it will keep changing using Property Transfer Step.

SQL Query will run based on the current value of Property Code and SQL Query will parameterize the CurrencyCode =:Code.

Click Add Property + and the name as Code and give value or keep blank to use Property Transfer step to provide it.

Add Property

SoapUI - JDBC Assertion

JDBC Request can also make use of most of the assertions with SOAP request TestSteps. In SoapUI, most of these assertions are independent from TestSteps. Hence, the assertions such as Contains and XPath Match can be used with JDBC Request TestStep.

By clicking the Add an assertion icon at the top menu of JDBC Request TestStep, the user can find out what assertions are supported by the TestStep.

In addition to the generic assertions, there are two JDBC Request TestStep specific assertions −

JDBC Timeout − This assertion can be used to verify whether the current SQL query is executed within the specified Query Timeout property value.

JDBC Status − In order to check whether the SQL statement is executed successfully, we can use the JDBC Status assertion.

JDBC Status

To set the Query Timeout, provide the value respective of Property Query Timeout on the left side of the screen. Please keep in mind, it accepts value in milliseconds (ms).

Property Query
Advertisements