SOAPUI Tutorial for Beginners | Testing SOAP Services

SoapUI is the world’s leading an open-source testing platform.

It is the most widely used automation tool for the testing web services and web APIs of SOAP and REST interfaces.

It is a boon for testers to test functional and non-functional testing, like automated testing, functional, load testing, regression, simulation and mocking without a hindrance because its user interface is very easy to use.

It supports different standard protocols such as HTTP ,REST, AMF, JDBC, SOAP, etc., that exchange an information in structured data like XML, plain text or JSON, etc. with the help of a network services or web APIs in a computer.

Why we use SoapUI?

It is an important tool to test the Web domain, and it is an open-source, cross-platform as well as language independent that encourage Eclipse, NetBeans, and IDEA.

It permit the testers to test functional, non-functional testing, performance testing, regression testing, compilation, and load testing on different Web services and APIs.

Below is the general architecture of the SoapUI.

Test config files: The test config files are the configuration files that contain test data, database connection, variables, expected results and any other environmental setup or test particular details.

Selenium: It is a Selenium of JAR that used anUI automation.

Groovy: Groovy is a library that allow SoapUI to provide groovy as a scripting language to users.

Third-party API: It is a third-party API that is used to made customized test an automation frameworks.

Properties: These are the test requested properties files that are used to hold any dynamically created data. The test property is also using in the configuration of SSL and other security configurations for a test requests.

SoapUI Runner: It is used to run a SoapUI project.

Test Report: A SoapUI creates a Junit

Test style report and the user reporting utility to report a test results.

Some Protocols and Technologies

The below are the essential protocols and technologies used in the SoapUI.

• SOAP stands for a Simple Object Access Protocol
• REST stands for a Representational State Transfer
• WSDL stands for Web Services explanation Language
• HTTP stands for a Hyper Text Transmission Protocol
• HTTPS stands for a Hyper Text Transmission Protocol Secured
• AMF stands for a Action Message Format
• JMS stands for a Java Messaging Services
• JDBC stands for a Java Database Connectivity

Advantages of SoapUI

• It provides a easy and user-friendly Graphical User Interface (GUI).
• Cross-platform desktop-based an application.
• It supports all standard protocols and technologies like HTTP, HTTPS, AMF, JDBC, SOAP, WSDL, etc.
• SoapUI costs less than all other test tools available a market.
• It is used as message broadcasting.
• It offers a fast and well-organized framework that create lots of web services tests.
• It creates mocks where testers can be test real applications.
• It supports drag and drops features to access a script development.
• Transferring data from one response or source to various API calls without manual interaction in the SoapUI tool.
• It facilitates tester and to developer teams to work together.
• SOAPUI tool offers the facility to get data from different sources of web service without developing any code.

Disadvantages of SoapUI

Security testing that requires enhancements.

The Mock response module should be many enhances and simplified.

It takes longer to request big data and dual tasks to a test web services.

SoapUI Testing

The following are the various types of testing in SoapUI tools.

1. Functional Testing

It is a powerful and an innovative features that validate the functional or behavioral tests of web services and applications.

It offers the user-defined scripts that can be customized as per the requirement of a testing.

Drag-Drop: It supports drag and drops features to made and run the most difficult test scenarios. Multi Environment Support: It encourage multi-environment to switch between differnt environments like QA, Dev, and prod environment.

Test Coverage: SoapUI permit testers to dynamically analyse how a SOAP or REST service is covered by a functional testing.

Data Driven Testing: SoapUI permit the tester to debug and develop data-driven tests.

Load Testing

Load testing is used to analyse the web service or web API’s behavior based on particular tasks or load.

Ease of Use: Using a simple user interface and handling the LoadUI agents of SoapUI tools makes load testing very easy and simple.

LoadUI Agents: SoapUI include the number of LoadUI agents to analyse distribution and performance on different parameters.

Performance Monitoring: A SoapUI has an effective and advanced reporting system for collecting test results on different performance parameters for load testing.

Security Testing

It is an important tool that is used to ensure that an authentication and authorization of Web Services and also Web API by using the request and response model in the SoapUI.

Cross-Site Scripting: A cross-site scripting is a security test that scans and find potential risks on particular parameters in structured messages.

Security DatabaseAs the name suggests, the security database that find and scans some potential SQL injections may be damage the database.

Stack Overflow: It is used in the SoapUI web testing tool to scan and also locate massive documents within XML messages that can be cause a stack overflow.

Compliance Testing

A compliance testing consists of a source and data authentication license certificate and different service agreements to validate a web service or web API.

Regression Testing

It is functional testing used in the SoapUI tool to analyse the bugs or malfunctions of the web service.

And it also reverifies the web service after new modify in the current release tools.

In other words, that it is the responsibility of the tester to execute the test suits and certify whether an existing functionalities are not breaking after the new changes to the SoapUI tools and its working fine with a tools.

Features of SoapUI

It offers a simple and easy user interface for Technical and Non -Technical person.

It encourages all standard protocols and technologies to test various APIs and web services.

It offer security or vulnerability testing of the system against malicious SQL commands, boundary limitation scanning, or stack overflows.

It permit own building plugin for the various open-source environment.

SoapUI Integration:

SoapUI tools are integrated with the popular building tools.

Apache Ant:

It is used to built projects and run test suites by using the command line in SoapUI Tools.

Hudson:

It is a Java-based tool, integrated with a SoapUI tool to fastly find bugs on every commit at the code’s click from the development team.

Maven:

It is a project management automation tool for generating only a java-based project.

JUnit:

It is a Java Based unit testing

Framework that is integrated with a SoapUI tool to perform unit testing for the web services and web APIs.

SoapUI Properties

The term properties are used to represent the characteristics of the particular object.

Types of SoapUI properties

1. Default Properties: Default properties are those properties that are inbuilt in the SoapUI tool, or that as soon as the new project madein a SoapUI.

2. Custom / User Defined Properties: Custom or user-defined properties can be explained at any stage of project creation like test case, test suite, test steps, global, etc.

Defining Properties

• SoapUI properties can be explained at multiple levels in a Project.
• Workspace Default Properties
• Project Default Properties
• Service Default Properties
• Operation Properties
• Request Default Properties
• Custom Properties
• Global Properties in SoapUI

SoapUI Assertions

What are Assertions?

Assertions are the validation rules that apply to claims verification results and check whether the targeted web service works the similar way as the expected result.

Assertion can be understood through the use of checkpoints or a check point on every parameter of validations.

For example, send a request to a web server, the web server received the request and create a response. Now, have to validate the server response result using assertion rules include the same result .

Features of Assertions

Assertions include the validation rules which validate the response received by a server during the execution of the test step.

In assertion can explain the specific part of the response message or entire message, that should be validated.

If any test steps do not meet the received response results, an assertions test result will fail the test step.

It denote with the red color in a test execution log.

Types of Assertions

1. 1. Property Content
2. 2. Compliance Status Standard
3. 3. Script
4. 4. SLA
5. 5. JMS
6. 6. Security

Property Content

It is used to check the properties present in the response received after triggering a specific service request.

Contains Assertion: It is used to validate whether a specified string exists in the response in xml. Furthermore, explain regular expressions to check the existence of an expression.

Non-Contains Assertion: It is used to check the non-existence of a particular string in the response xml. Furthermore, explain regular expressions in Not Contains to examine the existence of an expression.

XPath Match Assertion: XPath match is used to select denote content from the target property and match the XPath expression’s result to the expected value in the response xml.

XQuery Match: The XQuery expression is same to the XPath Match, used to select content from the target source and compare or match the XQuery expression result with an expected values in the response XML.

Scripting Assertion: The Scripting assertion enables that the users to run a custom script to perform a user-defined verification.

Compliance, Status and Standards

It is used to check the status of fault messages and schema compliance in response XML.

HTTP Download All Resource: It is used to check all html documents like images, scripts, etc. that are only available after downloading the resources.

Invalid HTTP Status Codes: The Invalid HTTP status code is used to validate whether the target test step has received a result with an HTTP code that is not available in the defined list of HTTP codes.

Not Soap Fault: , a not soap fault is used to find that no soap fault exists in the last received message. Soap Response: It is used to check a whether the last received message is a Soap response message, and it can only applying with any Soap requested TestSteps.

Soap Fault: It is used to determine any soap fault that exists in a last received message. It applies to a Soap Test Steps as well as MockResponse Test Steps only.

WS-Security: It is used to validate a whether the last received message has a valid WS-Security header. The Mock response Test Steps only support it.

Schema Compliance: The Schema Compliance is used to validate a whether the last received XML message follows the WSDL or WADL compliance explanation. Both SOAP and REST Test Steps use the Schema Compliance.

WS-Addressing Request: It is used to check if the last submitted request has a correct WS addressing header. The Mock response Test Steps only support it.

WS-Addressing Response: It is used to check that a last received response XML message has the correct WS address header. The Soap Request Test Steps only support it.

Script

Script Assertion: Script assertions are used to generate custom scripts that execute user-defined validation rules in the response XML file.

Security

Sensitive Information Exposure: It is used to authenticate a received XML response messages that will not disclose a sensitive information to the target system.

SLA

Response SLA: The response SLA is used to check that the last received message’s response time is within the particular time limit. Furthermore, SLA can be implemented with the script tests that send script requests to a server and receive a response.

JMS

JMS Status: It is used to verify whether the JMS request of the test phase has been successfully executed, and it is good for a test steps with the JMS endpoint. It is implemented to handle the test steps request with JMS endpoint.

JDBC

JDBC Status: The JDBC status is used to check that the specified test steps’ request is successfully executed in the SoapUI testing tool. It can only be implemented to a JDBC TestSteps.