SoapUI Interview Questions and Answers

Simple Object access protocol (SOAP) is that uses XML to interact with web applications. It uses XML based content to communicate between two client machines across any network.

REST (Representational State Transfer) is an architectural style of designing software’s. 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.

SOAP UI (Simple Object access protocol User Interface) is an open source testing tool. It is world most used Functional and Non functional testing tool. It can be used for SOAP and RESTful API Web services Testing.

Web services are web components that transfer data between client and server. Client sends a web request to the server and the server then responds to client. The response and request are related and different requests evoke the corresponding response.

Web Service is a web component or software program that can be accessed on the Internet. It is mainly used to communicate with the web based applications through XML messaging concepts. For example, if we want to access a particular location using Google Maps, we can use the corresponding web service URL. For that we have to pass the appropriate inputs.

The core features are:

• Web Services Inception
• Web Services Development
• Web Services invoking
• Web Services simulation and mocking
• Web Services functional compliance and security testing

Majority of the functional testing is carried out via the GUI; the biggest challenge of webservices is that they do not have a UI.

In general, web service is combined with the following protocols. They are,

• HTTP / POST
• HTTP / GET
• SOAP

While exposing the web services, these channels will be used for communication with the clients. Here HTTP / POST protocol transfers the information between the clients with secure mode. HTTP / GET protocol allows the clients to view transferred data partially at the browser’s address bar. SOAP is used for transferring the confidential data safely.

There are five components are used in web services. They are,

• WSDL – Web Service Description Language
• SOAP – Simple Access Object Protocol
• UDDI – Universal Description, Discovery and Integration
• RDF – Resource Description Framework
• XML – eXtensible Markup Language

To perform functional testing for web services, we can use the following tools.

• SoapUI
• RESTClient – This is a Firefox plug-in
• JMeter – Specially made it for performance testing tool and also we can do functional testing the web services.

WSDL stands for Web Service Description Language and is a document written in XML. It uses XML to define the service layer document which consists of origin of the web service, headers, port types, request and response data. This one can provide the information about web methods and web service.

It describes:

• Origin of the web service
• Header information
• Port type
• Input and output messages

Validating webservices in only possible with WSDL document because to configure web services in SoapUI, WSDL document is mandatory. If the WSDL document is not valid, SoapUI will throw an exception immediately.

Universal Description Discovery and Integration (UDDI) is a directory or global repository where all the web services can be found. A new Web service can also be registered through this. This is also the place where WSDL detailed definitions are found.

It uses the discovery layer which is used in the web services. UDDI has all the information about the web services in detail.

Generally, all the SOAP based web services are written by using XML language which uses standard message format that is accepted across the universe. In this format, it is easy to read, identify the errors, avoids interoperability problems etc.

Here’s the sample SOAP message format.

POST /InStock HTTP/1.1

Host: localhost

Content-Type: application/soap+xml; charset=utf-8

Content-Length: 399

SOAPAction: “http://www.example.com/soap-envelope”

<?xml version=”1.0??>

<soap:Envelope xmlns:soap=”http://www.example.com/soap-envelope”>

<soap:Header>

</soap:Header>

<soap:Body>

<m:TutorialName>SoapUI</m:TutorialName>

</soap:Body>

</soap:Envelope>

Since its XML based, it is platform and programming language independent. RPC (Remote procedure calls) are sometimes blocked by firewalls and proxy servers- Soap overcomes that.

Envelope element is the top most tag which identifies the XML document as a SOAP message. Followed by Envelope element, you see the header element that has header information. The Body element specifies the call and response information. Finally, you have a Fault element which contains errors and status information.

A protocol is a set of standard rules that helps to communicate the hardware devices through the software applications. There are different types of protocols used in the Internet and Intranet applications. They are

TCP which stands for Transmission Control Protocol. It has the rules to exchange the messages between two different Internet applications.

Internet Protocol uses the rules for sending and receiving the information between two different Internet addresses.

Similarly, HTTP, FTP and DHCP protocols are used the set of rules to transfer the data other than Internet applications.

XML (eXtensible Markup Language) is a mark-up language that is used for storing, sharing and formatting data. In general, an XML document is built by the tags. For more info and examples, check out this article 

SoapUI is a webservices testing tool and SoapUI Pro is its commercial version. SoapUI can help create functional, security and load testing test suites. SoapUI Pro does all that with advanced drag and drop, data driven testing, advanced reporting and coverage analysis.

• SoapUI offers us to perform automation testing which includes functional testing, load testing and data driven testing.
• It also provides in build reporting tool and export test results log provision
• We assert our services using various types of assertions

In a SoapUI project, the following order should be maintained.

• TestSuite – This is combination of functional tests and logical blocks
• Testcase – Its a group that contains several test steps for the specific aspects of the service.
• Teststep – it contains the set of functional tests

• Create a project and add the WSDL file
• Add test suites, Test cases and Test cases- in that order
• Include custom programming/validation using by adding Groovy steps
• Call external data sources if using
• Add assertions if necessary
• Then RUN.

Assertions compare the parts/all of the response message to the expected outcome.

Assertions are the one of the major feature in SoapUI. It offers the following types of assertions.

• Simple contains
• Schema compliance
• Simple not contains
• Soap Faults
• Response SLA
• XPath Match
• XQuery Match
• WS security status
• Script Assertion
• WS- Addressing Request or Response Assertion

Additionally Equals assertion is introduced in SoapUI NG Pro version.

In SoapUI, XPath assertion is used for asserting the web service response value by specifying the absolute path. If the absolute path is matched with the response value, then the test case or test suite will be considered as PASS otherwise it will be notified as FAILED. We can see the results of assertion at bottom of the screen where the Assertion tab will have resultant information.

Data driven testing means to store our test data which includes input and expected output in an external data source called Excel / Database / XML file. Later, we need to iterate the data source using respective component. In SoapUI, Datasource and Datasource Loop test steps are used for performing data driven testing.

The following are the different types of assertions:

• Contains & Not Contains
• XPath match
• XQuery match
• Schema compliance
• Soap Faults
• Response SLA
• WS security Status
• Script Assertion
• WS- Addressing Request or Response Assertion

Receive a response to a request as you normally would follow the below steps:

• Create a project, add WSDL
• Add Test suite, Test case and Test steps
• Run the request

To add assertions:

• Click on the Add Assertions at the top of log tabs.
• Configure the assertions as per the type and data required.

Groovy is a scripting language which internally includes all the java libraries – it helps us to customize and add custom validations to SoapUI tests

Yes -Groovy steps and JavaScript steps.

The basic Test suite is a way for us to group tests in SoapUI. When you need a different set of tests, you just have to create a new test suite and create tests as required under it as test cases.

The response values can be saved by clicking on the required request and choosing the “Dump file” location in its properties.

In SoapUI, there are three levels of properties available. They are,

Custom Properties or Project Level Properties:

These properties are added several times based on our needs and they can be utilized at any test suites, test cases or test steps that belong to the current project.

Test Suite Level Properties:

Tester can add his own properties with relevant information under the test suites. These properties are available under the corresponding test suite only.

Test case Level Properties: If the tester needs to store their test data within the test cases they can create their own properties inside the test case. So these properties can be accessed within the respective test cases.

Parameterizing feature is most important when we automate the test cases and also this is the beginning of the test step creation process. Let us have look into this.

• Create project which has the endpoint information
• If necessary, change the endpoint and assign to the property through the property expansion test step
• Make sure the request information available in the given endpoint address
• During the execution time, property will hold the test value. Providing different input value to the property it is easy to do it through the IDE.

In SoapUI, we can use Groovy Script in the following two places.

• Groovy Script Test step under the test case
• Script Assertion Test Step

SOAP is a protocol and REST is architecture. It allows us to send SOAP envelops to REST based applications.

• REST supports different message formats but SOAP permits XML only.
• REST services are faster and easy to handle.
• SOAP is tied with SMTP and HTTP protocols whereas REST relies on HTTP only.
• SOAP is more secure and structured format.
• REST does not depend on any specific standards as it supports various messaging formats like JSON, CSV and XML.
• SOAP web services allow us to build the client with RESTful services.
• SOAP was introduced for distributed computing.
• After REST’s entry, it accommodated the web by its performance and scalability as it is a light weight component.
• REST is stateless whereas SOAP is a state-ful specification.
• REST uses Uniform Resource Identifier (URI) and it has the methods like GET, PUT, POST and DELETE to expose their resources.
• SOAP uses named operations and interfaces to achieve its business logics.

Resource Description Framework- RDF contains the description of the web resources such as title, author, content, and copyright information. It is written using XML.

• Excel Files
• CSV Files
• ODBC Sources
• SQL / ADO Objects