Web Services Testing

Web Services Testing This document provides an overview of what are web services? How they can be tested? What tools can be used for Functional as well as for Performance Testing of Web Services? What are the uses of Web Services?

What are web services? Web services are a new breed of Web application. They are self-contained, selfdescribing, modular applications that can be published, located, and invoked across the Web. Web services perform functions, which can be anything from simple requests to complicated business processes...Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service. The full-function web services platform can be thought of as XML, HTTP, SOAP, WSDL and UDDI. At higher levels, one might also add technologies such as XAML, XLANG, XKMS, and XFS -- services that are not universally accepted as mandatory. SOAP (Simple Object Access Protocol) is a protocol specification that defines a uniform way of passing XML-encoded data. It also defines a way to perform remote procedure calls (RPCs) using HTTP as the underlying communication protocol. UDDI (Universal Description, Discovery and Integration Service) provides a mechanism for clients to dynamically find other web services. Using a UDDI interface, businesses can dynamically connect to services provided by external business partners. A UDDI registry is similar to a CORBA trader, or it can be thought of as a DNS service for business applications. Web Services Description Language (WSDL) is a new specification to describe networked XML-based services. It provides a simple way for service providers to describe the basic format of requests to their systems regardless of the underlying protocol (such as Simple Object Access Protocol or XML) or encoding (such as Multipurpose Internet Messaging Extensions). WSDL is a key part of the effort of the Universal Description, Discovery and Integration (UDDI) initiative to provide directories and descriptions of such on-line services for electronic business. WSDL (Web Services Definition Language) provides a way for service providers to describe the basic format of web service requests over different protocols or encodings. WSDL is used to describe what a web service can do, where it resides, and how to invoke it.

Web Service Architecture The following illustration shows the relationship between a Web service (in the center), its client software applications (on the left), and the resources it uses, including databases, other Web services, and so on (on the right). A Web service communicates with clients and resources over standard protocols such as HyperText Transfer Protocol (HTTP) by exchanging XML messages. The WebLogic Server on which the Web service is deployed is responsible for routing incoming XML messages

to the Web service code that you write. The Web service exports a Web Service Description Language (WSDL) file to describe its interface, which other developers may use to write components to access the service.

How to do Functional Testing?

The goal of this testing is fairly straightforward: to ensure that the server delivers appropriate responses for the given requests. However, due to the complexity of Web services, this task is far from simple. With most Web services, it is impossible to anticipate exactly what types of requests clients will send. Enumerating all possible requests is not feasible because the space of possible inputs is either unbounded or intractably large. As a result, it is important to verify whether the server can handle a wide range of request types and parameters. There are several tools available in the market to user for functionality testing. We practically tried one such tool, which is freeware, called Exactor. About Exactor Exactor is a framework for writing automated acceptance tests of the kind advocated by Extreme Programming. Customers or testers write acceptance tests using a simple plain text format. Programmers write the commands specified by the customer tests and connect them to the application being tested.

The format for Exactor test scripts is plain ASCII text. A script is a series of commands that are interpreted by the framework to invoke Java classes written by programmers to carry out the command. Lines beginning with the hash character '#’ are comments and are ignored by the framework. Commands are specified one per line starting at the left hand side of the script; any parameters required by the command are supplied next, separated by white space, i.e. spaces or tabs. The script should be saved with an extension of ".act", although not strictly necessary it enables the script runner to pick up multiple files in a directory. It supports Batch testing. To run the script or multiple scripts in a directory, run the framework class passing the name of the file or directory as an argument

How to do Performance Testing?

Performance testing is an important part of any distributed or Web application testing plan. Inclusion of performance estimates into planning and development cycles ensures that the application delivered to a customer satisfies high load, availability and scalability requirements. This type of test not only provides an absolute measure of system response time, but also targets the regressions on server and application code, examines if the response from the server matches the expected result, and helps to evaluate and compare middleware solutions from different vendors. About JMeter Apache JMeter is a tool that can be used to test applications utilizing HTTP or FTP servers. It is Java based and is highly extensible through a provided API. A typical JMeter test involves creating a loop and a thread group. The loop simulates sequential requests to the server with a preset delay. A thread group is designed to simulate a concurrent load. JMeter provides a user interface. It also exposes an API that allows you to run JMeter-based tests from a Java application. To create a load test in JMeter build a test plan, which is essentially a sequence of operations JMeter will execute. The simplest test plan normally includes the following elements: • Thread group - These elements are used to specify number of running threads and a ramp-up period. Each thread simulates a user and the ramp-up period specifies the time to create all the threads. For example with 5 threads and 10 seconds of ramp-up time, it will take 2 seconds between each thread creation. The loop count defines the running time for a thread. The scheduler also allows you to set the start and end of the run time. • Samplers - These elements are configurable requests to the server HTTP, FTP, or LDAP requests. This tutorial focuses on the Web service requests only. • Listeners - These elements are used to post process request data. For example, you can save data to a file or illustrate the results with a chart. At the moment the JMeter chart does not provide many configuration options; however it is extensible and it is always possible to add an extra visualization or data processing module.

What are the uses of Web Services? The following characteristics of Web services make them well suited for creating integrated systems on the Internet or intranets. Reusable Just like other component technologies, once you have written code and exposed it as a Web service, you or others may use that code again and again from various applications. Once you've written and tested your code, it's easy to make use of it in new applications. Because Web services use standard XML protocols, these components can be consumed by a much wider variety of users than with previous component based technologies. Flexible Because Web services communicate using extensible XML documents (instead of small pieces of data), they can more easily accommodate changing data and content over time. This also encourages packaging may activities into a single method call over the network. This greatly improves the efficiency of your applications, especially over high-latency networks such as the Internet or corporate WANs (Wide Area Networks). Standards-Based Web services are built on standard technologies such as HTTP and XML. All Web service messages are exchanged using a standard XML messaging protocol known as SOAP (Simple Object Access Protocol), and Web service interfaces are described using documents in the WSDL (Web Services Description Language) standard. These standards are all completely agnostic of the platform on which the Web services were built. Implement SOA Web services, is one of the ways you can implement SOA. The benefit of implementing SOA with Web services is that you achieve a platform-neutral approach to accessing services and better interoperability as more and more vendors support more and more Web services specifications. Note: The Tools specified here are the freeware tools available on internet at free of cost. There are several tools available in the market which can make your work easier. They are specified just for examples only.