Software Testing Social Network

Article Index
How to approach Web Service Testing ?
Page 2
All Pages

Operating the test system

There are a lot of great tools available for testing web services. MindReef SoapScope is a fine commercial option, and SoapUI is a fine open source option. You will find them both to have all the basic features I've needed. SoapScope is a bit better about data trending and analysis. SoapUI has a few more technical features for test execution. You could also try using IBM Rational for SOA Quality, which is an Eclipse-based tool focused on Web service testing. It's a latecomer, but has a nice feature set.

More often then not, you will use homegrown tools written in Ruby and Java to perform Web service testing. It gives you more control over the interfaces, features, and a working knowledge of what's actually going on in the test tool you're using. There are some drawbacks like support and documentation. Even the open source SoapUI team does a fantastic job in support -- they turned around a defect for me in 24 hours once. That's better then you'll see from MindReef or IBM for sure.

Try a couple of tools before you settle. You could switch between the different tools based on the team you are working with and what you are tying to do. Once you've compared a couple of them you'll figure out which features you really need and which are nice but optional.

Evaluating the test results

Evaluating the results for Web service tests can sometimes be really easy, and sometimes painful. There are couple of things you'll want to practice getting good at:

    * writing XSLTs to transform your actual response to mask out values you don't care about (server dates for example);
    * writing Xpath queries to check for specific values in an XML document;
    * learning all the command line options on your favorite diff-tool;
    * and ensuring you have at least one person on the team that knows the schema inside and out and can see the entire mapping document in their head when they look at the response files.

The better you are at the first three, the less important the last one is. It is also found that custom logging (both in your test execution tool and in the Web service under test) can also help add visibility to the results. Depending on what you're testing, sometimes you can cut out the need for file comparison entirely.
    
Once you get up to speed with the basics of manually testing the Web service, performance testing is normally trivial. Some of the tools have the ability to generate load built in. If you're using a homegrown option, all you need to do is thread your requests and you have the same ability. Getting the usage model right can sometimes be a challenge, but it's doable.

Other concerns that come into play can be authentication/authorization and encryption.

   

< Prev		Next >