Web Services Testing with soapUI

3.7 (3 reviews total)
By Charitha Kankanamge
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Web Services Testing and soapUI

About this book

Quality is a key to success of service-oriented projects. Utilization of proper tools is important to the outcome of web service testing methodology. Being the leading open source web services testing tool, soapUI helps to build robust and flexible automated tests in a productive manner.

"Web Services Testing with soapUI" guides you on adopting best web service testing mechanisms with the industry leading open source testing tool, soapUI. You will learn to use soapUI effectively in testing service-oriented solutions focusing on testing functional as well as non-functional characteristics of web services. SoapUI is capable of testing JDBC data sources, web applications, RESTful services and web services exposed over transports such as JMS. The book discusses all these features and much more, in detail, through practical and clear examples.

This book is focused on learning soapUI in order to test web services in an effective manner. It starts with a general introduction to service-oriented architecture (SOA) followed by testing aspects of service-oriented solutions. This book aims to give readers a comprehensive overview of usage of soapUI in SOA and web services testing projects.

Starting with an overview of SOA and web services testing, you will quickly get your hands dirty with a sample project which makes use of open source web service engine, Apache Axis2. All demonstrations and hands-on exercises are based on this sample project. The tests in a soapUI project are organized into TestSuites, TestCases and TestSteps. You will also learn how soapUI can be used for both functional and non-functional testing. The book then teaches how by using groovy scripting and integrating with Junit and maven, soapUI can easily be used in automated web services testing.

By the end, you'llhave learned to test functional and non-functional aspects of web services and automate by integrating into continuous build systems using soapUI.

Publication date:
October 2012


Chapter 1. Web Services Testing and soapUI

Web services are one of the key building blocks of service-oriented solutions. Because of their usage and importance in the enterprise applications, the project teams are expected to be knowledgeable and familiar with the technologies which are associated with web services and service-oriented architecture(SOA). The testing aspect of web services in particular is one of the key topics which needs to be discussed when you work with web services.

Web servics testing can be performed using many approaches. The client APIs included in web service frameworks such as Apache Axis2 can be used to programatically invoke web services. In addition to that, number of properitory and open source tools are avaialble to test web services automatically. soapUI is one such free and open source testing tool that suppots functional and non-functional evaluations of web services.

We will discuss the following topics in this chapter which will provide you with an introduction to the basic concepts of SOA, web services testing, and soapUI:

  • Overview of some of the key characteristics of web services

  • The role of web services in SOA

  • Approaches of testing web services

  • Web services testing challenges

  • Introduction to soapUI

  • Installing soapUI


SOA and web services

SOA is a distinct approach for separating concerns and building business solutions utilizing loosely coupled and reusable components. SOA is no longer a nice-to-have feature for most of the enterprises and it is widely used in organizations to achieve a lot of strategic advantages. By adopting SOA, organizations can enable their business applications to quickly and efficiently respond to business, process, and integration changes which usually occur in any enterprise environment.

Service-oriented solutions

If a software system is built by following the principles associated with SOA, it can be considered as a service-oriented solution. Organizations generally tend to build service-oriented solutions in order to leverage flexibility in their businesses, merge or acquire new businesses, and achieve competitive advantages. To understand the use and purpose of SOA and service-oriented solutions, let's have a look at a simplified case study.

Case study

Smith and Co. is a large motor insurance policy provider located in North America. The company uses a software system to perform all their operations which are associated with insurance claim processing. The system consists of various modules including the following:

  • Customer enrollment and registration

  • Insurance policy processing

  • Insurance claim processing

  • Customer management

  • Accounting

  • Service providers management

With the enormous success and client satisfaction of the insurance claims processed by the company during the recent past, Smith and Co. has acquired InsurePlus Inc., one of its competing insurance providers, a few months back.

InsurePlus has also provided some of the insurance motor claim policies which are similar to those that Smith and Co. provides to their clients. Therefore, the company management has decided to integrate the insurance claim processing systems used by both companies and deliver one solution to their clients.

Smith and Co. uses a lot of Microsoft(TM) technologies and all of their software applications, including the overall insurance policy management system, are built on .NET framework. On the other hand, InsurePlus uses J2EE heavily, and their insurance processing applications are all based on Java technologies. To worsen the problem of integration, InsurePlus consists of a legacy customer management application component as well, which runs on an AS-400 system.

The IT departments of both companies faced numerous difficulties when they tried to integrate the software applications in Smith and Co. and InsurePlus Inc. They had to write a lot of adapter modules so that both applications would communicate with each other and do the protocol conversions as needed.

In order to overcome these and future integration issues, the IT management of Smith and Co. decided to adopt SOA into their business application development methodology and convert the insurance processing system into a service-oriented solution.

As the first step, a lot of wrapper services (web services which encapsulate the logic of different insurance processing modules) were built, exposing them as web services. Therefore the individual modules were able to communicate with each other with minimum integration concerns. By adopting SOA, their applications used a common language, XML, in message transmission and hence a heterogeneous systems such as the .NET based insurance policy handling system in Smith and Co. was able to communicate with the Java based applications running on InsurePlus Inc.

By implementing a service-oriented solution, the system at Smith and Co. was able to merge with a lot of other legacy systems with minimum integration overhead.

Building blocks of SOA

When studying typical service-oriented solutions, we can identify three major building blocks as follows:

  • Web services

  • Mediation

  • Composition

Web services

Web services are the individual units of business logic in SOA. Web services communicate with each other and other programs or applications by sending messages. Web services consist of a public interface definition which is a central piece of information that assigns the service an identity and enables its invocation.

The service container is the SOA middleware component where the web service is hosted for the consuming applications to interact with it. It allows developers to build, deploy, and manage web services and it also represents the server-side processor role in web service frameworks. A list of commonly used web service frameworks can be found at http://en.wikipedia.org/wiki/List_of_web_service_frameworks; here you can find some popular web service middleware such as Windows Communication Foundation (WCF), Apache CXF, Apache Axis2, and so on. We will use Apache Axis2 as the service container for sample projects within the context of this book. Apache Axis2 can be found at http://axis.apache.org/.

The service container contains the business logic, which interacts with the service consumer via a service interface. This is shown in the following diagram:


Usually, the message transmission between nodes in a service-oriented solution does not just occur via the typical point-to-point channels. Instead, once a message is received, it can be flowed through multiple intermediaries and subjected to various transformation and conversions as necessary. This behavior is commonly referred to as message mediation and is another important building block in service-oriented solutions. Similar to how the service container is used as the hosting platform for web services, a broker is the corresponding SOA middleware component for message mediation. Usually, enterprise service bus (ESB) acts as a broker in service-oriented solutions.


In service-oriented solutions, we cannot expect individual web services running alone to provide the desired business functionality. Instead, multiple web services work together and participate in various service compositions. Usually, the web services are pulled together dynamically at the runtime based on the rules specified in business process definitions. The management or coordination of these business processes are governed by the process coordinator, which is the SOA middleware component associated with web service compositions.

We looked into the primary building blocks of service-oriented solutions and the corresponding SOA middleware components. Next, we are going to discuss some of the distinguished elements associated specifically with web services. These are SOAP messaging, Web Services Description Language (WSDL), message exchanging patterns, and RESTful services.


Simple Object Access Protocol

Simple Object Access Protocol (SOAP) can be considered as the foremost messaging standard for use with web services. It is defined by the World Wide Web Consortium (W3C) at http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ as follows:

SOAP is a lightweight protocol for 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 datatypes, and a convention for representing remote procedure calls and responses.

The SOAP specification has been universally accepted as the standard transport protocol for messages processed by web services. There are two different versions of SOAP specification and both of them are widely used in service-oriented solutions. These two versions are SOAP v1.1 and SOAP v1.2.

Regardless of the SOAP specification version, the message format of a SOAP message still remains intact. A SOAP message is an XML document that consists of a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body.

The structure of a SOAP message is shown in the following diagram:

The SOAP Envelope is the wrapper element which holds all child nodes inside a SOAP message.

The SOAP Header element is an optional block where the meta information is stored. Using the headers, SOAP messages are capable of containing different types of supplemental information related to the delivery and processing of messages. This indirectly provides the statelessness for web services as by maintaining SOAP headers, services do not necessarily need to store message-specific logic. Typically, SOAP headers can include the following:

  • Message processing instructions

  • Security policy metadata

  • Addressing information

  • Message correlation data

  • Reliable messaging metadata

The SOAP body is the element where the actual message contents are hosted. These contents of the body are usually referred to as the message payload.

Let's have a look at a sample SOAP message and relate the preceding concepts through the following diagram:

In this example SOAP message, we can clearly identify the three elements; envelope, body, and header. The header element includes a set of child elements such as <wsa:To>, <wsa:ReplyTo>, <wsa:Address>, <wsa:MessageID>, and <wsa:Action>. These header blocks are part of the WS-Addressing specification. Similarly, any header element associated with WS-* specifications can be included inside the SOAP header element.

The <s:Body> element carries the actual message payload. In this example, it is the <p:echoString> element with a one child element.


When working with SOAP messages, identification of the version of SOAP message is one of the important requirements. At first glance, you can determine the version of the specification used in the SOAP message through the namespace identifier of the <Envelope> element. If the message conforms to SOAP 1.1 specification, it would be http://schemas.xmlsoap.org/soap/envelope/,otherwise http://www.w3.org/2003/05/soap-envelope is the name space identifier of SOAP 1.2 messages.


Alternatives to SOAP

Though SOAP is considered as the standard protocol for web services communication, it is not the only possible transport protocol which is used. SOAP was designed to be extensible so that the other standards could be integrated into it. The WS-* extensions such as WS-Security, WS-Addressing, and WS-ReliableMessaging are associated with SOAP messaging due to this extensible nature. In addition to the platform and language agnosticism, SOAP messages can be transmitted over various transports such as HTTP, HTTPS, JMS, and SMTP among others. However, there are a few drawbacks associated with SOAP messaging. The performance degradations due to heavy XML processing and the complexities associated with the usage of various WS-* specifications are two of the most common disadvantages of the SOAP messaging model. Because of these concerns, we can identify some alternative approaches to SOAP.


Due to the complexities accompanied with the SOAP model, Representational State Transfer (REST) architecture has emerged as a result. RESTful web services can be considered as a lightweight alternative to the bulky and complex SOAP based web service standards. In RESTful web services, the emphasis is on point-to-point communication over HTTP, primarily using plain old XML (POX) messages. We will discuss RESTful web services in detail in Chapter 8, Getting started with REST Testing.

Java Script Object Notation

Java Script Object Notation (JSON) is a lightweight data exchange format similar to XML. It is based on a subset of JavaScript language. JSON uses key value pairs to represent data which are carried inside the message. The following example shows how the XML payload of a SOAP message can be represented in JSON:

The corresponding JSON format of the preceding XML payload is represented by:

You may refer to http://www.json.org for more details about JSON.


Web Services Description Language

According to the WSDL 1.1 specification, WSDL is defined as:

WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services)

In simple terms, WSDL provides a formal definition of the web service through abstract and concrete definitions of the interface. The following diagram shows the main structure of a WSDL document:

WSDL is an XML document with a <definitions> element at the root and the child elements, <types>, <message>, <portType>, and <binding>. These can be explained as follows:

  • The <types> element is used to define the data types used by the web service usually through a XML schema. The schema can be defined inline as a child element of <types> or can be imported from an external URL.

  • The <message> element defines an abstract representation of all the messages used by the web service. A message consists of logical parts, each of which is associated with a definition within some type in the XML schema of the web service. The following image is an example of a message:

  • The <portType> element is an abstract representation of the operations and message exchange patterns used in the web service. Operations represent a specific action performed by a web service and which can be related to the public methods used by a program. Operations have input and output parameters and those are represented as messages. Hence, an operation consists of sets of input and output messages. This is evident from the following image:

    In the preceding example, the SampleServicePortType element includes a single child element, <wsdl:operation name="echoString">, which itself includes two child elements to define the input and output messages processed by the echoString operation.

  • The <binding> element connects the abstract web service interface defined by <portType> and <message> elements into a physical transport protocol. A binding represents a particular transport technology that the service uses to communicate. For example, SOAP v1.1 is one such commonly used binding.

We will discuss about the WSDL in detail in Chapter 2, The Sample Project, using the one that is used in the sample project.


Message exchanging patterns

As we have already discussed, the web services communicate with each other and the other programs by sending messages. If we consider two SOAP processing nodes, the communication pattern between the two entities can be defined as a message exchanging pattern (MEP). The primary message exchanging patterns are:

  • Request-response

  • Fire and forget

In a request-response pattern, when a source entity (service requester) transmits a message to a destination (service provider), the provider should respond to the requester. This is the most commonly used message exchanging pattern and we will use this in most of the examples in this book.

In the following diagram, a service requester sends a SOAP request message to a service provider:

Upon receiving the SOAP request message, the service provider responds with a SOAP response as shown in the following diagram:

When a response to a request message is not expected from a web service (or service provider), it is known as a fire and forget message exchange pattern. For example, if we send a ping request to a web service, we do not expect a response message back.


SOAP Faults

Before concluding our discussion on web services and the associated concepts, we should look at the fault handling mechanism of web services. Faults can be returned by web services due to various reasons. For example, if the request message does not conform to the XML schema of web service, the service responds back with a SOAP Fault. The SOAP Fault element is used to carry such faults occurred during web service communication. This element must be included inside body of a SOAP message. A typical SOAP 1.1 Fault message consists of the following child elements:

  • faultcode: The faultcode element is used to define the type of the fault. For example, if the problem of message transmission is due to the server, the associated faultcode is Server. Similarly, we can use VersionMismatch, MustUnderstand and Client error codes as appropriate.

  • faultstring: The faultstring element is intended to provide a human readable explanation about the fault.

  • faultactor: The faultactor element provides an indication about the responsible party who caused the fault to occur in the message path.

  • detail: The detail element is used to carry application specific error information related to the body element. For example, if the payload of the SOAP request is unable cannot be processed by web service, the associated response should include the detail element inside the SOAP Fault.

In the case of SOAP v1.2 messaging, faultcode is renamed to Code and faultstring is renamed to Reason. In addition to that, a SOAP v1.2 Fault message can include the optional child elements, Node, Role, and Detail. A detailed explanation of SOAP 1.1 Faults can be found at http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383507. SOAP 1.2 Faults are explained in detail at http://www.w3.org/TR/soap12-part1/#soapfault.


Approaches of testing web services

We discussed a set of concepts most associated with web services. Now, it is time to look in to the testing aspects of web services. As we noticed, web services are loosely coupled and autonomous components which are individual units of business logic in SOA. This facilitates a distinguished approach for testing web services. Because of the loosely coupled nature, the services do not maintain tight, cross-service dependencies with each other. Therefore, once a particular web service is implemented, it can be tested independent from others.

This gives the ability to testers to follow a component level testing methodology. Before moving into various integrations, a web service can be tested to verify both functional and non-functional requirements. Once the service is enhanced with different attributes such as security policies, then such a service can also be tested individually to ensure that it functions properly before taking the integration scenarios into account. This gives great flexibility for testers and provides agility to testing processes.

We can identify a set of common approaches for testing web services as follows:

  • Unit testing

  • Functional testing of web services

  • Integration testing of web services

  • Performance testing

Let's discuss each of these approaches in detail.

Unit testing of web services

A web service is a unit of business logic and it consists of one or more operations. These operations must be tested individually in order to make sure the intended business problems are addressed by web service operations. Therefore, similar to how individual methods in a computer program are tested as units, web service operations must also be unit tested. Unit tests can be developed using the unit test framework associated with the programming language which is used to implement the web services. For example, if web services are written in Java, JUnit framework can be used as the unit testing framework. Generally, it is the responsibility of the author of the web service to write a sufficient number of unit tests to cover the logic of the web service operations.

Functional testing

Once a web service is deployed in a service container, it is subjected to a comprehensive functional verification. The purpose of functional testing of a web service is to ensure that the expected business functionality is given by the web service. There are many approaches to perform functional testing as explained below.

Tool assisted testing

The primary objective of using tools for web service testing is to support the automatic generation and submission of web service requests. As the web service interface is a machine readable XML document, it is not an easy task to read the WSDL and derive tests manually. Therefore, tools can be used to point to the WSDL and generate the corresponding requests automatically, so that the testers can send them to the service with or without alterations. soapUI is a good example of such a testing tool, which can be used in functional testing of web services.

Using client APIs provided by service container middleware

The life for a web service is given by the service container middleware where the service is hosted. Usually, the middleware providers ship the associated client API libraries which can be used to invoke web services programmatically without using any third party tool.

Integration testing of web services

Web services do not essentially run alone. Instead they are integrated with multiple components such as brokers or service coordinators. Once a service is integrated or joined with another component, we should carry out tests to make sure that such integrations do not break the system. For example, in a service-oriented solution, if a service consumer application sends a message to a web service but the message does not conform to the advertised schema of the web service. In this case, the web service usually responds with a SOAP fault. However, if we want to take such a request and transform the request SOAP message such that it is valid according to the schema, then we do not want to ask the consumers of our web service to change the client applications as the service schema is modified. This type of message transformation is achieved by using a broker component, in other words, enterprise service bus (ESB) middleware. According to the transformation rules defined in the enterprise service bus, the request is converted into the correct format and forwarded to the web service. This is a typical example of web service integration. In order to test this type of integration, the request message should be forwarded to the ESB component instead of directly sending it to the web service. Tools such as soapUI can easily be used to send the messages to desired target locations appropriately.

Performance testing of web services

Once we are satisfied with the functional aspects of the web service, it should be tested thoroughly for performance. This includes load and stress testing the web service as well as measuring the performance under various conditions. We can use various open source or commercial tools in web services performance testing. Apache JMeter (found at http://jmeter.apache.org/) is a good example of an open source testing tool which can be used to test web services. The functional tests which we create on soapUI can easily be extended to test the performance of web services. We will discuss the performance testing capabilities of soapUI in detail in Chapter 5, Load and Performance Testing with soapUI.

The common challenges of Web services testing

When compared to traditional testing approaches, there are some unique challenges associated with web services testing.

Use of external web services

The autonomous and loosely coupled nature of web services introduces a greater level of scalability and extensibility to the system. All services included in a system are not necessarily built in-house. Some web services can be developed and hosted by third parties. These services can be dynamically discovered and used according to the business requirements. Though this accelerates the delivery of solutions, testing such a system becomes complex because the quality assurance and availability of the third party services are out of your control.

Implications of using complex standards and protocols

Web services, especially SOAP-based services can use various WS-* specifications. When testing web services which adhere to specifications such as WS-Security, the tester should possess a fair amount of knowledge about the standards and concepts to carry out testing effectively. This introduces a higher learning curve for testers to get started with the testing of web services.

Web services can also be exposed over multiple transport protocols. Thus, testing is not limited to one particular transport such as HTTP. The same web service can be made accessible over transports such as JMS or VFS which requires changes in the testing setup as well as a different set of test scenarios.

Headless nature of web services

In traditional web application testing, test scenarios can be identified quite easily by studying the GUI of the components. As we discussed previously, the operations of web services are exposed to the outside world via machine-readable service contracts (such as WSDLs). Thus, during the early stages of web services development, testers need to use WSDLs as the reference for the derivation of test scenarios which can be difficult as compared to exploring a GUI.

As we proceed with the chapters of this book, we will learn how soapUI addresses some of the aforementioned challenges and make the life of a web services tester easier.

We have discussed the fundamentals of SOA and web services testing. Now, we are ready to explore the world of web services testing with soapUI.


What is soapUI?

The primary objective of designing testing tools is to assist people in testing software by reducing the time taken by test execution. There are different types of tools which can be used for functional and non-functional testing. Some of the tools are designed to automate user interface based interactions and some are used to derive various types of requests messages automatically and transmit them to applications with or without modifications. Some tools support both of these aspects.

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. In web services testing, soapUI is capable of performing the role of both client and service. It enables users to create functional and non-functional tests quickly and in an efficient manner by using a single environment.

The first release of soapUI (v1.0) was in October 2005. Ole Lensmer, while working in a project related to SOA, felt the need for a testing tool to support agile development. Therefore, he started to develop soapUI in his spare time. Eventually, the project was open sourced and the community grew. Ever since, a number of versions have been released with various new features and enhancements and the newest version of soapUI is 4.0.1 at the time of writing this book.

The originator of soapUI, Ole Lensmer was managing the project releases through a company called Eviware for the past few years. In July 2011, Eviware was acquired by SmartBear Software (http://smartbear.com/) and now soapUI is part of SmartBear Software.

soapUI is a free and open source utility, which means you can utilize the various features provided by the tool freely as well as you are allowed to make modifications to the source code of soapUI and suit it according to your requirements. soapUI is licensed under the terms of the GNU Lesser General Public License (LGPL). It has been implemented purely using Java platform hence it runs on most operating systems out of the box.

It should be noted that soapUI is also distributed as a non-free commercial version known as soapUI Pro, which basically provides users with custom utilities and enhanced production level testing capabilities. All our discussions and examples are based on the free version of soapUI for your convenience.


soapUI v4.0.1 was the newest version at the time of writing the book. Therefore, it is used throughout the context of this book. However, we will not discuss any version specific topics, so the older 3.x versions of soapUI can also be used to try out the sample projects and demonstrations.


Capabilities of soapUI

The primary goal of the authors of soapUI is to provide users with a simple and user-friendly utility which can be used to create and run functional as well as non-functional tests through a single test environment. Based on that objective, soapUI has become the world's leading SOA and web service testing tool. soapUI can be installed with no configuration overhead in most of the common operating systems which allow users to start using the tool without spending time on configuring various installation prerequisites.

By using the easy-to-use Java Swing-based GUI, you can start creating functional tests with zero coding. Eventually, the same functional tests can be used for load and performance testing through the same test environment. This gives users a great flexibility since all functional and non-functional tests can be managed through a single point of access.

Let's look at some of the important features of soapUI which we are planning to discuss in the following chapters.

  • Complete coverage of functional aspects of web services and web applications: soapUI supports most of the standards used in web applications, such as message transmission through HTTP, HTTPS transport as well as JMS. It also supports testing SOAP and RESTful web services. Specifically, soapUI supports most of the web service specifications such as WS-Security, WS-Addressing, among others.

  • Service mocking: Using soapUI mock services, you can simulate the web services before they are actually implemented. This gives you the ability to test the web service consumer applications without waiting until the web service providers are implemented.

  • Scripting: Either using Groovy or JavaScript, soapUI allows you to do various pre- or post-processing test configurations such as dynamic mock responses, initialize or cleanup tests, dynamic mock operation dispatching, and so on.

  • Functional testing : soapUI lets you do functional verifications against web services, web applications, and JDBC data sources. You can validate responses of your tests using various in-built and custom assertions. It also allows you to add conditional test steps to control the test execution flow.

  • Performance testing: With just a few clicks, you can generate performance and load tests quickly using soapUI.

  • Test automation: soapUI can be integrated into automated test frameworks such as JUnit, and the tests can also be launched through Apache Maven and Apache Ant build frameworks. It can also be integrated into continuous integration tools such as Hudson or Bamboo.

In addition to the preceding features, the proprietary version of soapUI, soapUI Pro, provides users with data-driven testing capabilities, HTTP recording, and test reporting facilities which are not in scope of this book.


Installing soapUI

We looked at the major features provided by soapUI and discussed the tool in general. It is time to explore the easy and straightforward soapUI installation on some of the popular operating systems.

System requirements

To be able to run soapUI, you should have Java Development Kit (JDK) v1.6 running in your system. As soapUI is implemented in Java, it runs on many operating systems including Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, various Linux flavors such as Ubuntu, Red Hat, Fedora, SuSE, and CentOS, and Mac OS X v10.4 or higher.

We can summarize the system requirements to install and run soapUI as follows:

Operating System

Java version



Disk Space

Microsoft Windows XP

Microsoft Windows Vista

Microsoft Windows Server 2003


Microsoft Windows Server 2008

JDK v1.6.x

512 MB (minimum)

1 GHz or higher, 32 or 64-bit processor

200 MB hard disk space (minimum)



Red Hat





JDK v1.6.x

512 MB (minimum)

1 GHz or higher, 32 or 64-bit processor

240 MB hard disk space (minimum)

Mac OS:

Mac OS X v10.4 or higher

Mac OS X Server v10.4 or higher

JDK v1.6.x

512 MB (minimum)

1 GHz or higher, 32 or 64-bit processor

140 MB hard disk space (minimum)

Let's discuss the installation procedure of soapUI in each of the preceding operating systems in detail.

Installing soapUI on Linux

soapUI is distributed as two different installers for your convenience. You could either download the binary archive (ZIP) of the installer or the installer script.

First, we will look at the installation procedure of the binary archive. Perform the following steps:

  1. Download the Linux binary zip version (for example soapui-4.0.1-linux-bin.zip) of the latest soapUI release from http://www.soapui.org.

  2. Extract the downloaded binary distribution into a directory in your local file system, for example /home/user/soapui.


    We will refer to the extracted directory as SOAPUI_HOME.

  3. Go to SOAPUI_HOME/bin and run the soapui.sh startup script as follows:./soapui.sh. This will launch the soapUI graphical user interface.


If you encounter a Permission denied error when running the soapui.sh script, make sure to change the file permission mode by granting executable privileges to the user by executing the chmod command as chmod 755 soapui.sh.

You can also install soapUI using the Linux installer by performing the following steps:

  1. Download a soapUI Linux installer (for example soapUI-x32-4_0_1.sh) from http://www.soapui.org.

  2. After the file is downloaded, give executable permissions by running the command, chmod 755 soapUI-x32-4_0_1.sh.

  3. Run the installer as follows: ./soapUI-x32-4_0_1.sh.

  4. This will launch the installer UI as shown in the following screenshot:

Now, you can proceed through the installation wizard. You will be asked to accept the license agreement at the next step of the wizard. Simply click on I accept the agreement option and click on Next. You will be required to specify a destination directory for soapUI to be installed.

At the next step of the installation wizard, you can select which components you need to include in soapUI, such as; Hermes JMS, soapUI source files, and tutorials. Simply accept all options and click on Next. You will be prompted with the license agreement for Hermes components at the next step. Accept the license agreement and click on Next to proceed through the wizard. Then, you will be asked to specify a directory for soapUI tutorials. Enter a location which is in your filesystem and click on Next. You will be asked for a directory where soapUI symlinks are created for executables such as the soapui.sh file. Enter a directory and click on Next. You can check the Create a desktop icon checkbox to create an icon on the desktop so can you can easily launch soapUI. Finally, click on the Next button to start the installation.

The soapUI installation screen will look like the following screenshot:

soapUI installation on Windows

Similar to the preceding installation procedure on Linux, soapUI can be installed on a Windows operating system either using Windows installer or Windows binary archive.

Let's look at the installation steps of Windows binary archive. They are as follows:

  1. Download the Windows binary zip version (for example soapui-4.0.1-windows-bin.zip) of the latest soapUI release from http://www.soapui.org.

  2. Extract the downloaded binary distribution into a directory in your local filesystem, for example C:/soapui.


    We will refer to the extracted directory as SOAPUI_HOME. This will launch the soapUI GUI.

  3. Go to SOAPUI_HOME/bin and run the soapui.bat startup script by executing the command: soapui.bat.

The steps for soapUI installation using the Windows installer are almost the same as the steps given in the Linux installer. You just need to double-click on the installer (soapUI-x32-4_0_1.exe) and it will launch the soapUI installation wizard.

Installing soapUI on MacOS

soapUI installation on Mac OS is straightforward and similar to the preceding steps which we described for Linux and Windows installers.


A glance at soapUI user interface

soapUI is a self-explanatory testing tool. The easy-to-use user interface makes it simple to work with soapUI for any type of user. With a few clicks, you can start testing a web service or a web application with minimum effort. This highly usable and flexible user interface helped soapUI to become the most user-friendly and easier SOA and web service testing tool among the testing community.

Once soapUI is launched, you will be shown the starter user interface as shown in the following screenshot:

In soapUI, all tests are organized under a central element, known as Projects. Just by right-clicking on the Projects node in the left-hand side pane in soapUI GUI, a new soapUI project can be created as shown in the following screenshot:

I will leave it to you to navigate through the rest of the UI elements on your own before starting with sample projects. You will find a lot of materials on the soapUI official website related to these features. We will explore through the soapUI user interface as we proceed through the demonstrations and samples in the rest of the chapters.



Web services are the individual units of business logic in SOA. In order to test web services, we must possess a good understanding about SOA and web services as well as the associated technological components. This chapter has been dedicated to build that foundation.

We started to look into soapUI, the world's leading and most complete SOA and web services testing tool. We discussed the primary goals and objectives of using soapUI in web services testing. We looked at a bit of history of soapUI and its distribution models. Finally, the steps of installing soapUI on Linux, Windows, and Mac OS were explained.

Now, we have soapUI running on our systems. Let's get our hands dirty with a sample project in the next chapter.

About the Author

  • Charitha Kankanamge

    Charitha Kankanamge is Manager, Quality Assurance and Senior Technical Lead at WSO2 with more than 9 years of experience in Software Quality Assurance. Charitha is specialized in SOA and middleware testing. He lead the WSO2 QA team since 2007. He is also a committer of the Apache Software Foundation contributing to Apache web services project. Charitha is interested in researching new technologies in software-testing space as well as new trends in agile and exploratory testing processes. Prior to joining WSO2, Charitha has worked at Virtusa inc. for 3 years where he was involved in multiple on-site and off-shore project assignments. In his rare offline moments, he enjoys playing guitar and watching movies. Charitha has been involved in reviewing two books, Apache Jmeter, Emilly H. Halili and Quick Start Apache Axis2, Deepal Jayasinghe both being published by Packt Publishing. Charitha can be reached through his blog: http://charithaka.blogspot.com

    Browse publications by this author

Latest Reviews

(3 reviews total)
I think this book is good for starting point. It describes a SOAP message structure, transport protocols and other SOA stuff. It was good summary for me. Acctualy this book was also good starting point to learn testing aspects. I think also a book such this one could describes a little bit deeper groovy testing or more complex features of SoapUI.
Web Services Testing with soapUI
Unlock this book and the full library for FREE
Start free trial