SOAP UI Interview Questions and Answers for 2025

This SoapUI interview question is a regular one, be ready to tackle it. We can differentiate API mocks and API virtualization under the following categories: 

• Purpose: API mocks are typically used to test the functionality of an application without depending on the actual API. On the other hand, API virtualization is used to simulate an API's behavior when it is unavailable or when it is necessary to test with different scenarios. 
• Implementation: API mocks are usually implemented within the application itself, while API virtualization is implemented using tools like SOAPUI, Mountebank, or WireMock. 
• Control: API mocks offer more control over the responses and behavior of the simulated API as they are created within the application. API virtualization offers less control as it simulates the actual API and its responses. 
• Flexibility: API mocks are more flexible as they can be easily modified to test different scenarios, while API virtualization is limited to simulating the actual API's behavior. 
• Maintenance: API mocks require less maintenance as they are within the application and are managed by the development team. API virtualization requires more maintenance as it involves setting up and managing a separate tool. 

Here are five best practices for API virtualization: 

• Use realistic data and examples to create more accurate test scenarios. 
• Isolate specific API operations to focus on testing one aspect at a time. 
• Quickly change responses to simulate errors and test how your application handles them. 
• Simulate different network conditions and server capacities to see how your application performs under different circumstances. 
• Avoid load testing on live APIs and use virtual APIs to save money and avoid being throttled. 

Several load-testing scenarios can be useful for testing an API: 

1. Baseline testing: This involves testing the API with normal or expected levels of traffic to establish a baseline performance. 
2. Stress testing: This involves testing the API with higher-than-expected levels of traffic to determine the maximum capacity of the API and identify any performance issues. 
3. Endurance testing: This involves testing the API over an extended period of time to ensure it can handle sustained levels of traffic. 
4. Peak traffic testing: This involves testing the API during times of expected high traffic, such as during a sale or promotion, to ensure it can handle the increased load. 
5. Spike testing: This involves testing the API with sudden bursts of traffic to see how it handles sudden spikes in traffic. 
6. Multiuser testing: This involves testing the API with multiple users concurrently to see how it handles multiple requests at the same time. 
7. User load testing: This involves testing the API with a specific number of users to see how it performs under different levels of user load. 

API virtualization can help address challenges in API testing by; 

• Allowing for parallel development, isolating development and testing teams from frequent changes in real APIs 
• Running performance tests against virtual APIs instead of third-party services 
• Setting up a virtual API sandbox, generating mock data, and virtualizing APIs for use in integration testing.

It can also improve test coverage and reduce the risk of disruptions from untested APIs. By using API virtualization, we can speed up the development process, improve the quality of APIs, and reduce testing costs.

To perform distributed load testing with SOAPUI, follow these steps: 

• Set up a load test in SOAPUI by adding a load test step to a test case and configuring the desired settings, such as the number of threads and the ramp-up period. 
• Install the LoadUI Distributed Load Testing plugin and configure it to connect to the LoadUI Distributed Load Testing Server. 
• In the load test step, click on the "Distributed" tab and select the LoadUI Distributed Load Testing Server as the target. 
• Configure the load distribution settings, such as the number of nodes and the load distribution type. 
• Run the load test and monitor the results in the LoadUI Distributed Load Testing Server. 
• Analyze the results to identify any performance issues and optimize the API's performance. 

Some key performance indicators (KPIs) that should be monitored during load testing include: 

• Response time: This is the time it takes for the API to respond to a request. A longer response time can indicate performance issues or bottlenecks. 
• Throughput: This is the number of requests that the API can handle within a certain period of time. A lower throughput can indicate performance issues or capacity constraints. 
• Error rate: This is the percentage of requests that result in an error. A higher error rate can indicate issues with the API's reliability or stability. 
• Resource utilization: This is the amount of resources (e.g., CPU, memory, network) that the API is using. High resource utilization can indicate performance issues or bottlenecks. 
• Concurrent users: This is the number of users accessing the API concurrently. Monitoring the number of concurrent users can help identify the maximum capacity of the API and identify any performance issues. 
• Latency: This is the delay between when a request is made and when it is received by the API. Higher latency can indicate network or infrastructure issues. 
• Transactions per second: This is the number of transactions (e.g., API requests) that the API can handle per second. Monitoring this KPI can help identify performance issues or capacity constraints. 

WSDL (Web Service Description Language) is an XML-based language used to describe web services in a standardized way. It lets different software systems talk to each other via the internet using common protocols like HTTP. A WSDL document explains what operations a web service can do, as well as the structure of the input and output data it can handle.

SoapUI is a tool that helps you test web services and APIs. You can use it to send requests to a web service, get responses back, and do other testing tasks. If you have a WSDL file, you can import it into SoapUI to automatically generate a request template for each operation in the WSDL. This lets you easily test the web service by filling in the request values and sending them off. SoapUI can also be used for functional and load testing of web services, as well as mocking web services for testing purposes. 

There are several code generation tools that can be used with SoapUI to generate client-side code for accessing web services. Some examples include: 

1. Apache CXF: This is an open-source tool for generating client-side code for web services in a variety of languages, including Java, C++, and Python. 
2. JAX-WS: This is a Java API for creating web services and clients. It includes a tool called wsimport that can be used to generate client-side code from a WSDL file. 
3. wsdl2java: This is a command-line tool that is part of the Apache CXF project. It can be used to generate client-side code in a variety of languages, including Java and C++. 
4. wsimport: This is a command-line tool that is part of the Java JDK. It can be used to generate client-side code for accessing web services from a WSDL file. 
5. Web Service Client: This is a feature of the Eclipse IDE that can be used to generate client-side code for accessing web services. It can generate code in a variety of languages, including Java, C++, and C#. 

These are just a few examples of code-generation tools that can be used with SoapUI. There are many other tools available as well, depending on the programming language and platform you are using. 

GraphQL is a query language for getting data from APIs that enables you to request exactly the data you need in a flexible way. In a GraphQL request, you specify the data you need in the form of a query. The service gathers all the requested data and forms it in a JSON object, the structure of which corresponds to the request query. This way, the client application knows exactly where to find the specific piece of data it needs to work with.

For example, if you want to get a list of customer names, your GraphQL query might look like this:

{ 
  customers { 
    name 
  } 
} 

The response from the server would then be a JSON object with an array of customer objects, each containing a "name" field.

In addition to querying data, you can also use GraphQL to add or modify data on the server through a process called a mutation. In a mutation request, you specify the mutation to be performed and provide the necessary fields, and the server responds with the modified data. You can also specify which fields should be included in the response. For example, the following mutation adds a new customer to the server and requests the ID of the added customer:

mutation { 
  addCustomer(name: "Test", email: "test@example.com") { 
    id 
  } 
} 

The server's response would then be a JSON object with the ID of the added customer.

To send GraphQL queries and mutations in SoapUI, you can use the "GraphQL Request" test step. In the test step, you can specify the GraphQL query or mutation in the "Query" field at the top of the "Request" tab. If you are using variables in your query or mutation, you can specify their values in the "Query Variables" panel using JSON format.

You can also use property expansions in your queries and mutations by right-clicking within the editor and selecting the "Get Data" context item to insert the expansion. The method of the GraphQL request can be changed from the drop-down list at the top of the "Request" tab. GraphQL queries support both the POST and GET methods, while mutations only support the POST method. 

If you want to save the server response to a file, you can specify the file name in the "Dump File" property. To save memory, you can also set a maximum size for the response data that SoapUI will show in the editor.  

To use variables in a GraphQL query in SoapUI, you can declare the variables in the query and specify their values in the "Query Variables" panel. Let's say you have the following GraphQL query that accepts two variables, "name" and "email":

query createCustomer($name: String, $email: String) { 
  createCustomer (name: $name, email: $email) { 
    id 
    name 
    email 
  } 
} 

To specify the values of the "name" and "email" variables, you can add them to the "Query Variables" panel in JSON format like this:

{ 
  "name": "John Smith", 
  "email": "john.smith@example.com" 
} 

Then, when you send the request, SoapUI will include the variable values in the query and send them to the GraphQL service. The service will use the values of the variables in the query to return the requested data.

There are several challenges to using script-based tools for API testing and performance testing. One challenge is that these tools are often designed for UI testing and may not have native capabilities for parsing JSON or XML, chaining multiple API requests, or validating API schema. This can make it difficult to create sophisticated test scenarios and accurately test the functionality of APIs.

Another challenge is that these tools often require custom coding, which can be time-consuming and may require specialized expertise. If the code doesn't run the first time correctly, it can be difficult to debug and fix in a short amount of time. 

Additionally, maintaining and managing these scripts can become complex and time-consuming as they grow in size, particularly if you are working with open-source solutions or big-name load-testing tools. 

There are several ways you can simulate load in SoapUI, as follows: 

1. Load Test: You can create a load test to simulate a specific number of concurrent users making requests to a service over a period of time. You can configure the number of threads (users), the ramp-up time (how long it takes to reach the maximum number of threads), and the test duration. You can also add assertions to verify the service's behavior under load. 
2. Stress Test: A stress test is similar to a load test, but it is designed to push the service to its limits by increasing the number of threads and the test duration until the service starts to fail. You can use a stress test to determine the maximum load that a service can handle. 
3. Security Test: You can use a security test to simulate a denial-of-service (DoS) attack on a service by sending a large number of requests in a short period of time. You can configure the number of threads and the test duration to create the desired load. 
4. LoadUI: You can use LoadUI, a load testing tool from the same company as SoapUI, to create more advanced load tests with additional features and options. LoadUI allows you to create load tests using a visual interface, create test scenarios with multiple steps and conditions, and integrate with other tools and services. 
5. Third-party tools: There are also many third-party tools that you can use to simulate load on a service, such as Apache JMeter, LoadRunner, and Gatling. These tools offer a variety of options and features for creating and running load tests. 

SoapUI provides several options for generating test documentation and reports. Here are some ways you can use SoapUI to generate reports: 

1. Load Test Report: You can generate a Load Test report after running a load test, which includes information about the test configuration, results, and performance statistics. You can customize the report template and include additional details as needed. 
2. TestCase Report: You can generate a TestCase report for a specific TestCase, which includes information about the TestCase, its steps and assertions, and any issues or errors that were encountered during execution. You can customize the report template and include additional details as needed. 
3. Printable Reports: You can generate printable reports in SoapUI that include information about the project, TestCases, and test results. You can customize the report template and include additional details as needed. 
4. Integration with other reporting tools: You can also use SoapUI to generate reports that can be integrated with other reporting tools, such as Jenkins or Bamboo. You can use the built-in integration features or use the command-line interface to generate the reports and integrate them with other tools.

Overall, SoapUI provides a range of options for generating test documentation and reports, including the use of custom reporting templates and integration with other reporting tools. This can help you to easily create professional-quality reports for your test results and share them with stakeholders as needed. 

There are several security scans available in SoapUI, including scans for SQL injection, XPath injection, boundary testing, handling of invalid types, and more. These scans work by sending malicious requests to the target service and trying to provoke a response that could indicate a security vulnerability. By using these security scans, you can identify potential security vulnerabilities in your target service and take steps to address them.

To add a security scan to a test step in your security tests, you can use the "Add Security Scan" button or the right-click menu option in the Security Test window. This will open a configuration window where you can define which parameters in the request will be used for testing and configure specific settings for the security scan. The configuration window also has tabs for setting up assertions to validate the response and configuring the strategy for permutating multiple parameters. These options are common to most security scans.

This is a frequently asked question in SoapUI automation interview questions. To handle dynamic values in your SoapUI test cases, you can use property expansion. Property expansion allows you to use variables in your test cases and set their values at runtime. You can use property expansion by enclosing a variable name in curly braces, like this: ${variable}. 

To set the value of a variable in your test case, you can use the "TestCase Properties" tab in the test case editor. In the "TestCase Properties" tab, you can add new properties by clicking the "Add Property" button and entering a name and value for the property. You can then use the property in your test case by using property expansion, like this: ${property_name}. 

An example of using property expansion in SoapUI might be testing a web service that returns a list of users from a database. You could create a test case that sends a request to the web service and receives a response with a list of users. Then, you could use property expansion to search for a specific user in the list. For example, you might set a property called "user_id" to the ID of the user you want to search for and then use property expansion to search the response for a user with a matching ID. You could use an XPath Match assertion to check that the response contains a user with the expected ID, like this: //user[@id='${user_id}']. If the response does not contain the expected user, the assertion will fail, and the test case will be marked as unsuccessful. 

To parse a complex XML response in a SoapUI test case using Groovy, we can use the XmlSlurper class. This class allows us to parse an XML string and access the data in a hierarchical manner using XPath expressions. Here is an example of how we can use the XmlSlurper class to parse an XML response:

def xmlSlurper = new XmlSlurper() 
def xmlResponse = xmlSlurper.parseText(response) 
// Extract the value of the "name" field 
def name = xmlResponse.'**'.find { it.name() == 'name' }.text() 
// Extract the value of the "age" field 
def age = xmlResponse.'**'.find { it.name() == 'age' }.text() 
// Extract the values of the "skills" field, which is a list of nodes 
def skills = xmlResponse.'**'.findAll { it.name() == 'skills' }.collect { it.text() } 
// Extract the value of the "address" field, which is a nested node 
def address = xmlResponse.'**'.find { it.name() == 'address' }.'**'.find { it.name() == 'street' }.text() 

To manipulate an API request in a SoapUI test case using Groovy, We can use the Request object, which represents the request that is being sent to the API. We can access this object in our test case and modify its properties as needed. Here is an example of how we can use the Request object to manipulate an API request:

// Add a custom header to the request 
request.addHeader('X-Custom-Header', 'some value') 
// Modify the request payload 
request.setRequestContent(newPayload) 
// Set the request method (e.g., GET, POST, PUT, DELETE) 
request.setMethod('POST') 
// Set the request endpoint 
request.setEndpoint('http://example.com/api/v1/users') 

When a TestCase is run under a LoadTest in SoapUI, several properties are made available in the TestCase context object that can be useful during scripting. These properties include: 

1. ThreadIndex: Contains the 0-based index of the current thread. 
2. RunCount: Contains the number of times this thread has executed the TestCase. 
3. TotalRunCount: Contains the total number of times the TestCase has been run during the execution of the LoadTest. 
4. LoadTestRunner: Gives access to the LoadTestRunner running the LoadTest. 
5. LoadTestContext: Gives access to the LoadTestContext running the LoadTest. 
6. Interactive: A Boolean value indicating whether the LoadTest is being run from the UI or not. 

You can use these properties, for example, to uniquely name output files for each thread, to access shared resources between TestCase execution, or to determine if the TestCase is being run as part of a LoadTest or on its own. 

There are several options for minimizing memory consumption when running a LoadTest in SoapUI: 

• In the LoadTest Options dialog, you can disable the collection of historical statistics, which can reduce the amount of data stored in memory. You can also set a limit on the number of assertion failures saved in the LoadTest log. 
• In the global Preference ReadyAPI (if using the ReadyAPI version) Settings tab, you can disable printable reports, which can also help to reduce the amount of data stored in memory. 
• You can use the memory log at the bottom of the main window to monitor memory consumption and trigger the Java Garbage Collector manually if necessary. 
• You can also try increasing the memory settings for SoapUI to allow it to use more memory. 

By combining these options, you should be able to minimize memory consumption when running a LoadTest in SoapUI.

There are several ways to handle authentication in a SoapUI request. One way is to use basic authentication, which involves sending a base64-encoded username and password in the HTTP header of the request. To do this in SoapUI, you can set the "Authentication" property of the request to "Basic" and enter the username and password in the "Username" and "Password" fields.

Another way to handle authentication is to use a custom authentication script. For example, you can use the following Groovy script to add an authentication token to the request header:

def request = messageExchange.requestContent 
def authToken = getAuthToken() 
request.setHeaderField("Authorization", "Bearer " + authToken) 

An SQL injection attack is a type of cyber attack where malicious code is inserted into an SQL statement through user input in order to gain unauthorized access to a database or server. This can be done through a web service by sending malicious SQL code in a parameter field and hoping that the server will execute it. These types of attacks can be very harmful, as they can lead to the theft of sensitive information such as credit card numbers. 

SoapUI has a feature called the SQL Injection Security Scan that allows users to test for vulnerabilities in web services by injecting malicious SQL code into specified parameters and using assertions to check for sensitive data exposure or unauthorized logins. Users can configure the scan to run on failed TestSteps and adjust the waiting time between requests and the strategy for combining attacks on multiple parameters. The Advanced tab also allows users to review and edit the list of malicious strings used in the scan. By using these features, SoapUI can help users ensure that their web services are properly protected against SQL injection attacks. 

The HTTP Monitor in SoapUI is a tool that allows users to capture and analyze HTTP traffic between a client and a server. It can operate in two modes: proxy mode, where SoapUI acts as a standard HTTP proxy forwarding messages from the client to the specified host, or HTTP tunnel mode, where the client sends its requests directly to SoapUI, which tunnels the request to the target host and returns the response. The HTTP Monitor also supports WS-Security and SSL decryption, so users can decrypt and verify signatures in incoming messages or decrypt SSL-encrypted traffic. Once started, the HTTP Monitor displays logged messages in a table and provides advanced views and inspectors for analyzing the selected message in detail. Users can filter entries and perform other actions through the toolbar.  

In SoapUI, global properties can be set through the Global Properties preferences tab, which contains a standard property table. These properties can also be specified or overridden by adding a -Dsoapui.properties argument in the soapui.bat/.sh file and specifying a properties file. 

For example, if you have a properties file named "properties.txt" containing "test.a.property=test!" in the SoapUI bin folder, you can add the argument "-Dsoapui.properties=properties.txt" to the java arguments in the SoapUI.bat file. This can be useful for specifying global endpoints or authentication settings. In addition to global properties, system properties can also be set directly from the command line when running any of the SoapUI bat/sh files by using the argument "-Dproperty.name=value". 

Properties can also be set at the project, test suite, test case, and mock service level by adding a "soapui.properties.=pathtopropertiesfile" value to the global or system properties, where "shortened-name-of-object" is the name of the corresponding object with only characters. For example, if you have a TestSuite in your project named "TestSuite 1", you can set "-Dsoapui.properties.TestSuite1=testsuite1props.properties" which will load the properties in the specified file ("testsuite1props.properties") into the "TestSuite 1" TestSuite properties.

SoapUI provides many ways to use scripts in testing projects to customize the behavior of the project. These scripts can be written in groovy language. Some of the ways in which they can be used are as follows:: 

• Groovy Script TestSteps in TestCases 
• Script Assertions for SOAP or REST responses 
• Setup/TearDown Scripts for TestCases, TestSuites, and LoadTests 
• Startup/Shutdown Scripts for MockServices 
• Before/After-Request Scripts for MockServices 
• MockOperation Dispatch Scripts 
• MockResponse Scripts 
• AfterLoad/BeforeSave Scripts for Projects 

All project-related artifacts in SoapUI are called ModelItems. You can access the children of a ModelItem using the following methods (note that XX refers to the type of the child): 

• getXXCount() 
• getXXByName(String name) 
• getXXAt(int index) 
• getXXList() 
• getXXs() 

For example, if you want to access a specific TestCase in a TestSuite, you could use getTestCaseByName("My TestCase") or getTestCaseAt(0). To iterate through all of the TestCases in a TestSuite, you could use a for loop like this: 

For (testCase in testSuite.testCaseList). 

To access the parent object of a ModelItem, you can use the name of the parent's type as a property. For example, if you want to access the TestSuite that a TestCase belongs to, you can use testCase.testSuite. You can also use this method to navigate "upward" in the object model to access higher-level parent objects. For example, you can access the Project that a TestSuite belongs to by using testSuite.project. 

We can add custom HTTP headers with the help of the RequestFilter.filterRequest event handler. Here are some lines of code demonstrating the same.

// Get the request headers to map 
def requestHeaders = request.requestHeaders 
// Remove an existing header if present 
requestHeaders.remove("X-tokenHeader") 
// Create a custom header 
def customHeader = ["X-tokenHeader": "value"] // Replace "value" with your desired value 
// Add the custom header to the request headers map 
requestHeaders.putAll(customHeader) 
// Set the modified request headers map on the request object 
request.requestHeaders = requestHeaders 

To change the value of an XML node using the XmlHolder object in SoapUI, you can use the XPath expression to locate the desired node and then assign it a new value. After making the desired changes, you can save them by using the updateProperty method. 

Here's an example of using the XmlHolder object to modify an XML request in SoapUI:

// Get the XmlHolder object for a request named "Update User" 
def groovyUtils = new com.eviware.soapui.support.GroovyUtils(context) 
def holder = groovyUtils.getXmlHolder("Update User#Request") 
// Change the value of the "firstName" node 
holder["//firstName"] = "John" 
// Change the value of the "lastName" node 
holder["//lastName"] = "Doe" 
// Save the changes to the request 
holder.updateProperty() 

 This code would locate the "firstName" and "lastName" nodes in the "Update User" request and change their values to "John" and "Doe", respectively. The updateProperty method is then called to save these changes to the request.

To remove empty XML elements from a request in SoapUI, you can use a script that utilizes the XmlHolder object. First, you can use the getXmlHolder method to get an XmlHolder object for the desired request. Then, you can use the getDomNodes method and an XPath expression to locate any nodes that consist only of whitespace. Once you have located these nodes, you can use the removeXobj method to remove them. Finally, you can use the updateProperty method to save the changes and write the updated request back to the test step. Here is an example of this process:

// Get the XmlHolder object for a request named "Update User" 
def groovyUtils = new com.eviware.soapui.support.GroovyUtils(context) 
def holder = groovyUtils.getXmlHolder("Update User#Request") 
// Locate empty elements and remove them 
holder.getDomNodes("//*[not(node())]").each { it.removeXobj() } 
// Save the changes to the request 
holder.updateProperty() 
// Write the updated request to the test step 
context.requestContent = holder.xml 

This code gets the XmlHolder object for the "Update User" request and then uses the getDomNodes method and an XPath expression to locate all empty elements in the request. It then removes these elements using the removeXobj method and saves the changes using the updateProperty method. Finally, it writes the updated request back to the test step using the requestContent property of the context object.  

To change all occurrences of a string in a response message before it gets validated in SoapUI, you can use the afterRequest event handler of the RequestFilter and the replaceAll method of the String class. First, get the response content using the httpResponse.responseContent property of the context object. Then, use the replaceAll method to replace all occurrences of the desired string with the new string. Finally, write the updated content back to the response using the httpResponse.responseContent property of the context object. Here is an example of this process:  

// Check if the request has a response 
if (request.response == null) return 
// Get the response content as a string 
def responseContent = context.httpResponse.responseContent 
// Replace all occurrences of the target string with the replacement string 
responseContent = responseContent.replaceAll("555", "444") 
// Save the updated response content back to the context 
context.httpResponse.responseContent = responseContent 

 This code will replace all occurrences of the string "555" with the string "444" in the response content. The updated response content will then be used for validation in subsequent assertions.