Explore topic-wise InterviewSolutions in .

• 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 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.

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

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

The following are the different types of assertions:

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 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.

• It is a document written in XML and USED to DESCRIBE WEB SERVICES.
• It specifies the location of the service and the operations (or methods) the service exposes.

• Open the request editor.
• In the request editor, click the Add an Assertion to Test Request button.
• Select RESPONSE SLA from the drop down in the Select Assertion dialog box.
• In the Configure Response SLA Assertion dialog box, WRITE 500 and click OK. This will validate that the response of the SLA is fewer than 500.
• Now that you’ve added the assertion, you are going to run the request to validate the response. If all assertions are successful, the SOAP icon should turn green in three places .
• You can also validate the response by adding an X-Path Match assertion.
• In Soap UI Pro you can open the Select X-Path dialog, which lets you select nodes to assert using point-and-click. As a RESULT Soap UI creates the matching X-Path expression that refers to the SELECTED node.
• Soap UI automatically populates the EXPECTED result to match what’s in the response. But of course, you can change this to what’s relevant for you.

This can come in HANDY both from the Project onLoad script (if you want to start your MockServices when the project is opened) or from a TestCase/TestSuite setup script (if you need the MockService running for your functional tests). Here from a TestCase setup script: 

1. def runner = testCase.testSuite.project.mockServices["My MockService"].start()
2. context.mockRunner = runner 

The returned runner OBJECT is required to stop the MockService... so save it to the context and USE it in the tearDown script: 

context.mockRunner.stop() 

Have a look at the WsdlMockService and the WsdlMockRunner CLASSES for more methods and properties that might come in handy.

This can come in handy both from the Project onLoad script (if you want to start your MockServices when the project is opened) or from a TestCase/TestSuite setup script (if you need the MockService running for your functional tests). Here from a TestCase setup script: 

The returned runner object is required to stop the MockService... so save it to the context and use it in the tearDown script: 

context.mockRunner.stop() 

Have a look at the WsdlMockService and the WsdlMockRunner classes for more methods and properties that might come in handy.

GROOVY and JAVASCRIPT

Groovy and JavaScript

• 200 OK This response code indicates that the request was successful.
• 201 Created This indicates the request was successful and a resource was created. It is used to confirm success of a PUT or POST request.
• 400 Bad Requests The request was malformed. This happens especially with POST and PUT requests, when the data does not pass validation, or is in the wrong format.
• 404 Not Found This response indicates that the required resource COULD not be found. This is generally RETURNED to all requests which point to a URL with no corresponding resource.
• 401 UNAUTHORIZED. This error indicates that you need to PERFORM authentication before accessing the resource.
• 405 Method Not Allowed The HTTP method used is not supported for this resource.
• 409 Conflicts This indicates a conflict. For instance, you are using a PUT request to create the same resource twice.
• 500 Internal Server Errors When all else fails; generally, a 500 response is used when processing fails DUE to unanticipated circumstances on the server side, which causes the server to error out.

• Right-click on one of the SOAP interfaces and selects GENERATE Mock Service.
• In the dialog Generate Mock Service you can SPECIFY the local port/path for the service you’re creating but for the MOMENT just click OK.
• Enter the name of your Mock Service in the Name dialog and click OK.
• after creating the Mock Service, you should GET a Mock Service with one operation and one request.

testRunner.testCase.testSuite.project.NAME (ALMOST all ITEMS have a name PROPERTY)

testRunner.testCase.testSuite.project.name (Almost all items have a name property)

Soap UI automatically SAVES EVERYTHING on exit. If you WANT to save your PROJECTS without exiting (for example if you want to commit your project file to CVS) USE the “Save All” option in the main File menu

Soap UI automatically saves everything on exit. If you want to save your projects without exiting (for example if you want to commit your project file to CVS) use the “Save All” option in the main File menu

Data-driven testing is when you store test data (input, expected output, etc) in some external STORAGE (database, spreadsheet, xml-files, etc) and then use that data iteratively in your tests when running them. For example to test your phone-lookup SERVICE, you might have a LIST of names and expected phone-numbers in a database which you would use to “drive” your test, CHECKING that each name gets the RIGHT phone-number back. It’s really quite simple.

Data-driven testing is when you store test data (input, expected output, etc) in some external storage (database, spreadsheet, xml-files, etc) and then use that data iteratively in your tests when running them. For example to test your phone-lookup service, you might have a list of names and expected phone-numbers in a database which you would use to “drive” your test, checking that each name gets the right phone-number back. It’s really quite simple.

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.

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.

We can READ the PROPERTY values into test STEP endpoint, username, header values, password, domain, POST, PUT, GET and DELETE METHOD PROPERTIES.

We can read the property values into test step endpoint, username, header values, password, domain, POST, PUT, GET and DELETE method properties.

PROPERTIES in SOAPUI is USED to RETRIEVE and store data. The data is STORED as key, value or FORMAT.

Properties in SOAPUI is used to retrieve and store data. The data is stored as key, value or format.

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.

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

To parameterize the endpoints in SOAP UI is most important as it is the first step in AUTOMATION testing. It is more time consuming for CHANGING endpoints manually. In order to do that

• DEFINE a project property holding the endpoint
• Change the endpoint to use this property via property expansion
• Ensure that your requests are availing the configured endpoint
• When a request is RUN, the property will inevitably be with its current VALUE. To use a different value just configure the endpoint in the UI, you can use the P option from the command line

To parameterize the endpoints in SOAP UI is most important as it is the first step in automation testing. It is more time consuming for changing endpoints manually. In order to do that

ASSERTIONS compare the parts/all of the RESPONSE MESSAGE to the EXPECTED outcome.

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

SOAP UI uses three levels to structure functional tests:

• TestSuite: It is a pool of test CASES used for combining functional tests into logical units
• TestCase: It is a GROUP of test steps that are bring TOGETHER to test some specific ASPECT of your services. You can augment any number of testcases to test suites
• TestSteps: They are “building blocks” of functional tests in SOAPUI. They together MAKES TestCase and determines the flow of execution of the service to be tested.

SOAP UI uses three levels to structure functional tests:

There are five COMPONENTS are used in web services.

They are:

1. WSDL – Web SERVICE Description Language
2. SOAP – Simple Access Object Protocol
3. UDDI – Universal Description, DISCOVERY and Integration
4. RDF – Resource Description Framework
5. XML – EXTENSIBLE Markup Language

There are five components are used in web services.

They are:

The general FORMAT for READING the custom or default PROPERTY VALUE is ${#levelname#KEY}

The general format for reading the custom or default property value is ${#levelname#key}

SOAPUI can:

• It can do automated TESTING LIKE load TESTS, scenario-based tests and data driven tests
• It has GOT built-in reporting abilities
• It has got unique ability to impersonate web services and run functional and load test against them even before they are executed

SoapUI can:

In general, web service is combined with the following PROTOCOLS:

• 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.

In general, web service is combined with the following protocols:

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.

Inside the SOAPUI GROOVY SCRIPT can be used in TWO places

• Groovy script test step
• Script Assertion- WITHIN test step

Inside the SOAPUI groovy script can be used in two places

Web services are a medium through which web based application can be integrated or communicated over an internet protocol backbone. Web based application can be integrated USING XML, SOAP, UDDI and WSDL. SOAP is USED for transmitting the data; WSDL is used for describing or RELATING the services, UDDI is used for listing what services are accessible, XML is used to tag the data.

Web services are a medium through which web based application can be integrated or communicated over an internet protocol backbone. Web based application can be integrated using XML, SOAP, UDDI and WSDL. SOAP is used for transmitting the data; WSDL is used for describing or relating the services, UDDI is used for listing what services are accessible, XML is used to tag the data.

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

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

Yes.

Yes.

SOAP UI is a free, open source cross-platform functional testing SOLUTION. It enables you to RAPIDLY and easily create and execute automated regression, compliance, functional and LOAD TESTS.

SOAP UI is a free, open source cross-platform functional testing solution. It enables you to rapidly and easily create and execute automated regression, compliance, functional and load tests.