How to test Web Services? – Blog #2

In continuation to my previous blog How to test Web Services? in which we discussed about the re-usable test automation framework for testing web services using Soap UI Pro tool, the emphasis in this blog will be about designing test cases for validating web services.

At a very high level it is a simple request and response model where the data is exchanged in the format of XML i.e. request XML and a corresponding response XML. The definition and details of the web services can be obtained from the WSDL/WADL and the XSD provides the information about the structure and data rules for each of the elements/attributes within the request and response XMLs. Test cases can be derived based on the information provided in these two files.

For sample XSD and XML, refer this site – http://www.cduce.org/manual_schema_samples.html

Based on the data type, occurrence value (min/max), data range specifically for integer values, enumeration list of values of the elements/attributes we can derive the test cases as:
1. Request with 0 occurrence of a mandatory element(s)/attribute (s)
2. Request with multiple occurrences of element(s)/attribute(s)
3. Request with boundary values for the range specific element(s)/attribute(s)
4. Request with values within the enumerated list and values not within the enumerated list.
5. Request only with mandatory elements/attributes
6. Request including the optional elements/attributes

The test cases can be categorized as

• “Schema validation” test cases where the request is sent with an invalid schema, for example missing the open/close tag, missing quotes and incorrect element/attributes, and

• “Functional Validation” test cases where the request is sent with various valid and invalid data combinations. The Schema Validation test cases, however, take a low priority for the reason that such validations are addressed as input data validations in the applications that consumes the web service.

This is the simple checklist for deriving the test cases. Though it is categorized as unit level testing or single service testing, this should be a good starting point to the question of how to design test cases to validate a web service. Eventually, you can add more complex test cases wherein you sequence your web services requests in a very similar way depicting a business transaction (which we term it as multi-service testing or business flow testing)

The validation in the response includes the following:
1. The response code for the given request
2. The appropriate error/response message
3. The actual data within the response XML for the given request

As we now learnt simple techniques to derive test cases for validating a web service, let us further our understanding on structuring the test cases. As a core component of the framework, the test suite template is designed and integrated to the re-usable framework.

Let us go one by one

Summary Sheet – To track the changes and the updates made to the test suite document

Traceability – This sheet provides the Traceability of test coverage for a specific API method and the defects associated with it.

Schema Validation – This sheet is used to derive all the schema validation test cases for a specific API method based on the element/attributes in the request XML and the mandatory/optional properties of each element/attribute

Functional Validation – This sheet is used to derive all the functional validation test cases for a specific API method based on the element/attributes, enumeration values, input data types and boundary value conditions

Request Input - This sheet is used to specify the following inputs for the API methods referred in the test cases designed in schema/functional validation sheets.

API method name – Method name to associate with the request. This will be very helpful when we have multiple methods and more than one request XML (only mandatory elements/attributes, mandatory and optional elements/attributes) to be used for testing a web services

Base XML - A valid request XML with valid Data. This base XML will be used to later transfer the data specified in the functional validation test cases for the specific elements/attributes.

Base Request xPath - The base request xPath based on which the input element/attribute xPath will be constructed for the data transfers based on each test case

Base Response xPath - The base response xPath based on which the expected and output values elements/attributes xPath is constructed and response verification and data retrieval is done

End-Point URL- The end-point URL for specific API method to which the request is sent.

Notes and Guidelines ­– This sheet is more a reference or help sheet explaining the purpose of each sheet within the test suite and guidelines & techniques while filling the data in each sheet.

Hope this blog helped you in understanding a simple technique to derive test cases for validating Web Services. Still more to come in the blogs to follow, keep reading and I appreciate your comments, inputs and feedback.