Items to Include in Your Test Plan

Finally, you want to make sure that you think ahead and figure out what type of activity you expect your Web Service to see. For example, you should look at your Web methods and determine what you expect the distribution of calls to be. Something like, “We expect method A to be called 25% of the time, method B to be called 30% of the time, and the other 10 methods to be called with the same frequency over the remaining 45% of the time.” Then, determine how many calls per second you want to be able to handle. If anything, make your estimates a little on the high side. An estimate of three calls per second equals 259,200 calls per day. The load you need to test for depends on whether people or computers will be your primary consumers. At this point in time, no historical data exists to tell just what an average load will look like.

After you determine the load you want to test for, you need to acquire some client machines and write an application that will hit the Web Service at the level you have determined. Plan some time for this and expect bugs to be discovered. At this point in time, no stress testing tools exist for Web Services. Any tools I have used were built for the specific Web Service. Some of the bugs you can expect to see under stress are connection timeouts and refused connections. If you access files or a database, you will probably uncover some race conditions as well that leave the Web Service locked up. Finally, you may see memory usage climb to points that your hardware cannot handle. These are all reasons that you need to see if your Web Service can handle loads at whatever you estimated to be the maximum load.

You will also want to test sending bad data. Send values that the Web Service should not allow. Send messages with the wrong contents. Have clients that send the message but do not wait for the response. This may all sound a little crazy, but it will work and show where you made mistakes in assuming that data would have a particular representation. Make sure that all this bad code can handle the inevitable SOAP Faults. By the time the server is made bulletproof, you will have a large number of SOAP Faults being returned.

In addition to all of this, you will want to include tests that look for things like:

• Time to respond to a message

• Verification that valid data works

• See how much stress the Web Service can take

• Test the Web Service when deployed on a Web Farm

Additionally, you will need to test things specific to your situation.