1. What are web services?
Web Services normally consist of one or more 'endpoints' that a product provides to allow SOAP/REST requests to interact with the internal functions of the product. These endpoints often consume data, but sometimes can take the form of 'triggers' that need no data in the request.
2. What are the communication channels available for a web service?
HTTP GET & POST with POST
3. What are the different components that can be used in web services?
DataSource(s) ↔ Main product logic ↔ SOAP/REST endpoints ↔ WS Request(s)/Response(s)
Often WS requests emulate actions that can also be performed via web browsers.
4. What are the tools used for testing Web services?
SoapUI, PostMan, WireShark for TCP/IP packet capture & Linux pcap analysis, Chrome/Firefox (+Dev Tools), PuTTY for SSH Connections & Tunnels, WinSCP for file transfer over SSH, Database Client(SQL Queries), Notepad++ for parsing logfiles,config files, XML, HTTP, REST/JSON , XMLNotepad, Eclipse/Java/Groovy/SoapUI Plugins for implementing Selenium/Cucumber automation frameworks.
5. What is WSDL?
Web Service Description Language – an XML file that web service components can use for interacting with each other. Some implementations actually parse a WSDL & build communication methods on-the-fly, while others don't digest it & have non-changeable assumptions.
6. What is the role of the WSDL document in web service testing?
WSDL is an XML file that serves as a 'contract' for a SOAP/REST endpoint, minimally enumerating the various 'functions' available and possibly the data types they consume.
A WSDL XML file can be fed to SoapUI for purposes of standing up & enumerating the various requests. If data elements are simple, SoapUI might fully interpret them but normally data objects are more complex and require referencing product documentation for how to construct them.
For example, a device or user might have an ID, Username, Password, and Type that are sent over as one chunk of data & SoapUI will not readily provide visual cues to assist the end-user.
7. What is SOAP?
Simple Object Access Protocol(now a bit deprecated acronym) is a means to interact with web services and consists of an XML data structure residing inside a //soap:Envelope/soap:Body element and sent in an HTTP POST.
8. What is XML?
Extensible Markup Language, XML is a verbose, yet easily readable way to interact with web services that resides in a SoapEnvelope:Body
9. What is SoapUI?
SoapUI is an IDE tailored to sending WS requests, receiving WS responses, & adding assertions to responses. SoapUI can be extended via Groovy script for more complex assertions and/or driving browser actions when combined with selenium framework hooks.
10. What types of testing can SoapUI perform?
SoapUI traditionally works in the SOAP/REST WS request/response domain, but given its inherent 'testrunner' capabilities can also be used for driving browser actions and – in more esoteric implementations – can be used to drive anything accessible by way of Groovy scripts & thus most anything available to Java.
11. What is the basic method to automate web services in SoapUI?
Import WSDL & let SoapUI create mock requests
Create Project, Test Suites, and Test Cases
Add Test Steps to Test Cases
Note: An 'initialize' Test Suite should be created to restore test environment to a clean state – though this might be possible with just one Test Step
Test Steps normally should:
`include one or more assertions – specifically for HTTP200 & for high value targets in the SOAP response
`employ 'properties' in any SOAP/REST requests so data can be easily conjured from 'properties files' manually or via Groovy script Test Steps
`Restore test environment back to a default state
12. What are SoapUI assertions?
SoapUI 'out of the box' assertions allow for easy manual addition of validation checks for Server Responses [ 200OK, 500ERROR ] and 'Contains' evaluations. More complex assertions normally require Groovy logic. The 'pro' version of SoapUI can consume groovy scripts natively, but 'free' versions require these scripts to be compiled into jars and placed in the /bin folder for consumption at program startup.
While Groovy code can be embedded & intertwined in the Test Steps directly, this is highly discouraged for maintenance reasons as the code in the Test Steps can quickly become deprecated & changes to 100 test steps render automation benefits somewhat moot.
- Log in to post comments