Web Service Testing

The great advantage of Web services is that they empower different types of entities to communicate with one another through platform-independent protocols such as SOAP, XML, and HTTP. However, the tradeoff for this flexibility is that this open, non-native traffic brings with it additional overhead. Take, for example, an enterprise that wants to use a Web service to integrate a J2EE application with a variety of client types or other applications

In this situation, many different types of clients can now access the information contained within the EJBs by going through the Web service layer. But this introduces a potential issue: a new layer of communication has been added with its own overhead and potential for failure into an application whose quality and performance was formerly under control. If the Web service layer makes the application slower or introduces quality issues it could affect application service-levels and negatively impact end users. The only way to ensure that this doesn’t happen is to test the quality and performance of these Web Services before they are deployed.

Web Services are applications that exist within a network. Since web services are being used more and more by businesses, security and testing are essential to web services. Testing ensures that SOA deployments can be reliable and successful for an enterprise. However, there are many gray areas that often occur during testing. To avoid these gray areas it is important to focus on performance, security, SOAP attachments, WSDL, and interoperability.

At a very basic level, one needs to consider how the remote method calls take place via SOAP, how the data is passed, how to test the transport layer, discovery methods, response data, scalability, performance, integrity etc.Testing Approach: Test Case Design, Test Execution shall be Top-Down and Bottom-Up respectively. Documenting test cases for the individual services can be a tedious task and subject matter experts can take part in unit testing the individual service so that they are error-free in the downstream process. This approach facilitates meeting the high-level business requirements and can also be used to create the data contents for the exchanged message. This will avoid the major pitfall of delivering a technically acceptable solution which fails to deliver business value. Once this is done, the data must be formatted into messages (XML) that express service request and replies from consumer and provider respectively.

Test tools must be used before and after publishing a web service. To do this, the WSDL must be loaded into the tool. The tool then acts as a client of the web service and sends SOAP requests. This describes a simple consumer-producer test scenario. Since web services depend on other services, the whole chain must be tested in order to find the problems. If a web service is not performing correctly, it may be due to another web service which it is attached to. This is easy to find if one simply monitors the CPU and memory statistics of each web service as the test transaction occurs. Many performance characteristics must be looked at such as response times and fail/pass ratios.

Security validation is also very important to evaluate when testing web services. This must be taken care of at the message level by using tools such as signatures and encryption. Test cases are also important to look at since a negative test case shows where the web service is inefficient.

SOAP is used to carry complex attachments through a network. These transmissions must also be evaluated to ensure that the attachment is not corrupted. To test a SOAP attachment, one can simply make sure that the upload and download values match and re-calculate the check-sum. The break point for message size must also be figured out.

WSDL acts as an important contract between the consumer and producer. However, this also provides gray area in web services testing since it is often not accessible through a firewall after handled by a partner. To avoid this dilemma, it is important to flatten the WSDL before handing it over to a trading partner. WSDL quality must also be identified.