Web Services Testing
Web service testing is management of all the data files (typically XML, but not always). There are tools that do this file management for you, but you should have a game plan for files that need to be managed manually. When testing track three files: a request file, an expected response file, and an actual response file.
The naming convention picked up along the way is to put a “-rq.xml”, “-rs.xml”, or “-result.xml” on the end of all files. That way for each file name you have a set of XMLs that paint the entire picture for that test case. Once you get a naming convention worked out, get the files into source control if you don’t have a tool that keeps them all straight for you.
Tools available for testing webservice: SoapUI, WebInject etc.
Some details about WebInject:
WebInject consists of the WebInject Engine (test runner) and an optional User Interface (GUI). The WebInject Engine can be run on its own from the command line, or called from the GUI.
There is a configuration file named ‘config.xml’ that is used to store configuration settings for your project. All settings and constants must be enclosed in the proper tags, and simply need to be added to the config.xml file (order does not matter).
Test Case Setup: Test cases are written in XML files (using XML elements and attributes) and passed to the WebInject engine for execution against the application/service under test. There are several parameters (attributes) you can use in your cases. The only required parameters are the ‘id’ and the ‘url’.
The following example of a test case file shows how you can use them:
verifypositive=”verify this string exists”
verifynegative=”verify this string does not exist”
Execution: Test execution is done through the WebInject interface which also has the monitoring window displaying the status in graphical mode.