Better Software - March 2008 - (Page 29)

• Response Validation: For every SOAP request, the response from the Web service must be evaluated. To determine whether a SOAP response is valid or invalid, a tester should set up pre-defined filters that examine HTTP return codes, SOAP faults, or any businessspecific content contained in a SOAP response. SOAP content-specific filters for response processing are set via XPath expressions. For example, if a SOAP fault is expected for a set of invalid inputs, then an XPath expression such as “soap:Envelope[0]\soap:Body[0]\ soap:Fault[0]\faultcode[0]” would look for the first faultcode node in the SOAP response. A test case with this XPath criterion would mark the SOAP response as valid, indicating that, as expected, an exception did occur for invalid input values. Performance Testing Performance is the second pillar of Web services testing. Testers should verify the scalability of Web services and determine performance, endurance, and stability characteristics of their Web services operations. Once the functional tests are defined, performance tests can be created as follows: 1. Change the SOAPSonar Mode to Performance Mode as shown in figure 8. The test suite configured during functional tests will now be used for performance testing without significant additional effort. 2. Performance parameters such as Protocol HTTP 1.0/1.1, response timeout, and test duration can be configured. We reduced the default run duration of thirty seconds for each test to five seconds per test case. Once the test is started, a real-time run monitor shows the performance test progress. Figure 8: Configuring performance testing for Add(int a, int b) operation After the performance tests are complete, a summary of performance statistics appears in the bottom panel as shown in figure 8. For more detailed performance statistics, a tester can generate reports by clicking the Report View button. For scalability testing, additional virtual clients can be added beyond the default value of 1. Performance Testing Caveats As testers become comfortable with SOA performance testing and move beyond the simple Web service that we have created and tested in this article, a better understanding of performance measurements for Web services is required. Understanding when a Web service has hit its “performance knee” requires deeper content awareness than just examining HTTP return codes for success (e.g., 200 OK) and failure (e.g., 500 Internal Server Error). For Web application testing, HTTPlevel error codes are sufficient; however, for Web services testing, these error codes are inadequate. Testers must examine MARCH 2008 BETTER SOFTWARE Figure 9: Executing design time WS-I Basic Profile interoperability tests www.StickyMinds.com 29 http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - March 2008

Better Software - March 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: Breaking Ground On SOA Software Development Worst Practices Mind the Gap Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

Better Software - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.