Testing Web services creates an entirely new set of problems for development and testing teams. JUnits can be created to test parts of the Web service, but do not provide the overall functionality needed to ensure adequate validation, and make updating data values difficult. There are also many Web service components to be tested that do not find their way into other, more generic testing tools. Web service testing can become a nightmare very quickly, which is particularly dangerous because this is one area that can involve external partners fairly early in the development process.

SOAPtest provides an entire suite of Web service-focused testing tools that enable the development team and/or testing teams to use one consistent tool for proving out Web services from Web Service Definition Language (WSDL) validation to performance testing without having to build and update testing clients themselves.

One key feature of SOAPtest is the wide array of data sources the tool supports. Creating test data can be time consuming and error prone, but the SOAPtest tool definitely helped lessen the overall effort. SOAPtest supports test data from any ODBC/JDBC connectable database, a .csv file, an internal table, an Excel spreadsheet, or an aggregate of any of those listed. Adding the data source is straightforward - you pick the type and location. I used an Excel spreadsheet provided in the tutorial.

I began by running a series of WSDL validations. WSDL controls access to the Web service by describing the service and indicating location. The screen interface is fairly intuitive; I was quickly able to validate a series of WSDL files.

You can also check that any URL links in the WSDL are still valid. Most interesting is the ability to perform a Web Services-Interoperability Organization validation. An impressive report is generated that can be analyzed by the development and test teams and distributed to your partners as appropriate.

WSDL comparison and regression testing is also supported, allowing the development teams to easily catch and confirm WSDL changes prior to additional testing efforts.

Once the WSDL has been confirmed and validated, the next key step is to ensure that the Web service operations are functional at the unit test level. This is performed by creating a series of unit tests, logically grouped in a series of test suites. SOAPtest supports positive testing (testing expected scenarios), negative testing (error conditions), and regression testing (performing change validation). The test data can be fully or partially from the variety of data sources, or can be generated on-the-fly by the tool. The data-generation aspect is fairly feature-rich and offers the ability to generate the data according to a series of rules defined by the user. One negative was that I attempted to save just the individual test itself and was unable to figure out how to do so.

Once the developer has completed the unit testing, SOAPtest offers the ability to create actual scenario tests. Scenario tests represent business scenarios recreated during the testing process. The scenario tests can be created from scratch or combine a series of already created unit tests merged with additional tests defined by the testing team.

SOAPtest provides a spectrum of data validation abilities. The data can be validated by element, or by only those elements that you wish to compare.

Another key aspect of many Web services is their asynchronous nature. Testing tools that expect the traditional synchronous responses of other applications have difficulty with this typical aspect of Web services. SOAPtest offers the ability to test asynchronous calls that use the communication protocols Parlay, SCP, and WS-Addressing. This is key because the nature of many of these services involves not getting an acknowledgement or response directly. SOAPtest includes a Tomcat server that allows it to test the "Call Back" responses expected when the Result Call back pattern of asynchrony is employed. One suggested update is to have the Tomcat server started automatically when the Call Back test is employed. The results of a series of asynchronous tests are shown in Figure 1

Another key detail when developing Web services involves the importance of security. The very nature of exposing Web services requires security forethought; hence, testing the security features is integral to any Web service validation effort. SOAPtest offers an encryption tool that supports full or partial encryption of messages. Encryption standards offers include Triple DES, AES 128, AES 192, or AES 256. The numbers stand for the bit key sizes. When using encryption testing, be sure to have the JCE (Java Cryptography Extension) Unlimited Strength Jurisdiction Policy File installed as the test will not work without it.

The other key security features offered by SOAPtest include the XML Signer Tool, the XML Verifier Tool, and support for user name and SAML tokens. The XML Signer Tool provides digital signing ability. If your Web service requires certain digital signatures, the tool can be used to validate that functionality. Likewise, the XML Verifier tool allows the user to encrypt/decrypt/ verify the digitally signed message by using a public/private key store file. Key store file formats supported include JKS, PKCS12, BKS, and UBER.

Security Assertion Markup Language (SAML) provides a standard for exchanging security information. SAML provides a means for Web services to exchange authentication and authorization assertions. This gives the team an opportunity to provide identity management services across an organization. SOAPtest supports SAML verification before a failure occurs.

If your Web service testing does not fall within the features identified previously, SOAPtest allows ultimate flexibility by offering custom test scripting abilities. The scripts can be written in Java, JavaScript, or Jython, and the tool supports the importing of files. The code can perform whatever additional testing logic is needed for the testing to complete.

Another key aspect when testing Web services is confirming performance requirements and identifying performance boundaries. SOAPtest is fairly unique among Web service testing tools in that it offers vast capabilities in the Load Testing arena.

Accessing the Load Test toolkit for SOAPtest involves selecting the Load Test tab from the left-hand navigation panel. Once there, existing scenarios can be used from the earlier functional tests, or new scenarios can be created. The tool provides the ability to run these tests across the network by enslaving associated machines. This allows the load levels to be increased dramatically as you can avoid local machine limitations.

Functional tests are incorporated into the Load Testing effort by creating user profiles. Each profile is made up of one or multiple functional tests and can be included or removed from every Load Test effort. I used profiles based on the positive and negative test scenarios created earlier.

Each profile can also be delayed so as to better monitor the impact of each functional test on load. The profile ratio is adjusted using the Profiles tab associated with the scenario. It displays the information graphically and allows adjustments of users and hits per second throughout the scheduled test cycle. Simply right-click anywhere on the graph to create a point, and then move that point to the appropriate location. Hits per second and number of users are also dynamically adjustable.

I created an initial slow increase in users, followed by a dramatic escalation a minute and a half into testing, and then a slight decrease. I also altered my ratio of user profiles to decrease the amount of positive tests over time as well. The duration of the test is also entirely up to the user, and it provides values for days. I opted for minutes - three to be exact. I ran the test and the results are shown in Figure 2.

I could also see a text-based graph summary (see Figure 3).

Many operating system statistics can be added and monitored by the testing community. SOAPtest supports adding SMNP, Windows Perfmon, and JMS monitoring packages. I used the default windows.

SOAPtest allows reports to be generated from all of the test results reviewed. The reports can be generated in HTML, XML, or .csv format.

Conclusion
In conclusion, SOAPtest provides a valuable Web service testing resource across the entire development life cycle. Its interface is easy enough for both developers and testers to master. It encourages the sharing of tests across teams, and provides test suites capable of supporting the smallest unit testing efforts to full Web service load testing. It supports a wide variety of data sources, sophisticated test scenario creation, and automated testing.

Asynchronous Web service validation and complex security verification are additional features that really differentiate SOAPtest from other testing products.

Corporate info:
Parasoft 101 E. Huntington Drive Monrovia, CA 91016 626 305-9090 www.parasoft.com
sales phone: 888 305-0041
sales e-mail: info@parasoft.com