6. Why do we test web services?

Why do we Test Web services?

ans: 1. To Validate service is working fine or not.

2. Whether the given request is sending response or not.

3. To Validate HTTP Protocols.
4. 

Different sorts of testing

As with any other application, there are different sorts of testing you can carry out on web services:

Proof-of-concept testing

Web services are a new type of software. Because of this, you will need to understand if the architecture you have chosen for your web service is the correct one. There are many different choices to be made - which tool vendor to use, which programming language and which database backend, for example. If you can clarify and resolve these issues before you start developing, or early on in the development life cycle, then you will save a lot of time and money further on down the line. Because most of the questions you need to resolve will concern scalability issues (Will the architecture we’re using really cope with 1,000 simultaneous users?), a proof-of-concept test is normally a cut-down load test (see below). There’s no need to run it on powerful hardware, or get exact answers; your aim is to answer the question, "Am I going in the right direction?".

Functional testing

This is to ensure that the functionality of the web service is as expected. If you have a web service that divides two numbers, does it give the expected result? If you pass in a 0 as the denominator, does it handle this correctly? Does your web service implement security/authentication as it is meant to? Does your web service support all the communications protocols it is meant to? Because your web service can be accessed by clients that you can’t control, what happens if they make requests you aren’t expecting? Bounds testing and error checking are especially important.

Regression testing

A regression test is normally a cut-down version of a functional test. Its aim is to ensure that the web service is still working between builds or releases. It assumes that some area of functionality was working in the past, and its job is to check that it still does. If your development team has changed the method that divides two numbers, does that method still work? Does the method that multiplies two numbers still work? Is the performance still acceptable? Since regression testing is, by its nature, a repetitive task then it must be automated. This is true for traditional applications and websites; it is even truer for UI-less web services.

Load/stress testing

This White Paper will concentrate on load and stress testing. The aim of load/stress testing is to find how your web service scales as the number of clients accessing it increases. You have carried out functional and regression testing, so you know that your web service will cope with a single user. What you need to know now is if it will cope with 10, 100 or 1,000 users, or how many users it will cope with. If you double the number of users, do response times stay the same? If you double the number of servers running your web service, does its capacity double? The following section in this White Paper will go into more details about these issues.