Testing web services

Web services are being used more frequently in the development of intranets and extranets. Whether creating web services from scratch or integrating legacy back-end servers via web services, Adam Kolawa, chairman and chief executive officer at Parasoft, illustrates engineering and testing practices to ensure complete web-service functionality, interoperability and security.

Web services are gaining industry-wide acceptance and usage. They are moving from proof-of-concept deployments to actual usage in mission-critical enterprise applications, such as sharing corporate information over intranets, or connecting customers and trading partners via extranets. As companies rely more on web services in the development of intranets and extranets, the importance of quality and reliability will continue to grow, thereby increasing the significance of web-services testing.

Server-functional testing

Server-functional testing is usually the first step in testing any web service – be it an intranet through which employees share information, or an extranet via which business partners exchange information through common servers. In any case, if the server does not work correctly, its performance, security and interoperability are essentially irrelevant. The goal of server-functional testing, therefore, is to ensure that the server delivers the expected responses for any of a wide range of request types and parameters.

The simplest possible functional test involves sending a request and checking whether the server returns a response or an error message. The response can be analysed either by inspection or by running the response through a tool or script that verifies conformance to a specification. The analysis can be as simple as performing a text comparison with the expected response, or as complex as extracting specific information from an XML document and performing application-specific checks. For example, if you have a web service that handles bank transactions, you can perform a server-functional test by sending a valid request (such as a transfer of money) to the server. You can then verify whether a response or an error message is returned from the server.

However, because of the complex nature of web services, testing a server’s functionality can be far from simple. With most web services, it is impossible to anticipate exactly what types of requests clients will send. Traffic may occur with extreme peaks and lows, with users accessing the service using a variety of clients, connections and platforms. With so many differing clients accessing a single web service, the server is bound to encounter unexpected requests either as a result of mistakes (such as a bad Web Services Description Language [WSDL]) or from attempts to breach service security (hackers sometimes trick applications into behaving unexpectedly by sending it invalid inputs).

An effective way to prevent errors caused by unexpected inputs is to perform what some refer to as ‘monkey testing’. This involves throwing the proverbial wrench into the web-services works by sending the service requests with illegal and/or unexpected parameters, then verifying the response with assertions, custom code or other tool-specific verification methods. For example, how will the server react if a customer attempts to transfer more money than is available? Will it return a proper message to the client? Will it allow the transaction? Or will the server just crash and die?

By checking for unexpected conditions and inputs, you enable more thorough tests for what cannot be foreseen. By performing such testing at the unit and application level, you can identify and correct any weaknesses quickly and easily, and before security breaches have the opportunity to occur. Therefore, in order to test the server functionality of a web service, you must be able to emulate many of the types of clients that might access the server, and verify that the server will behave as expected in relation to any type of client request.

Regression testing

After you have verified the server’s functionality, you can rerun your functional tests as regression tests. Regression testing is the process of running all existing test cases and verifying that all test cases pass. The purpose of regression testing is to detect unexpected faults, especially those faults that occur because a developer did not fully understand the internal code correlations when he or she modified or extended code that previously functioned correctly. Regression testing is the only reliable way to ensure that modifications did not introduce new errors into code or to check whether modifications successfully eliminated existing errors. Every time code is modified or used in a new environment, regression testing should be employed to check the code’s integrity. Ideally, regression testing should be performed nightly (during automated nightly builds) to ensure that errors are detected and fixed as soon as possible.

Load testing

After you have performed functional and regression testing on your server, you know that your web service can handle at least one client. But can it handle requests from 100 or even one million? Since a considerable number of clients can potentially have access to a web-service server, the server must be able to handle every request under an extremely heavy load or, at best, fail gracefully. Therefore, the next step in the server-testing process is load testing.

Load testing typically involves exercising your application with virtual users and measuring performance statistics to verify whether the application supports the anticipated traffic load, as well as possible traffic surges, growth and so on. To ensure your virtual users’ experiences effectively predict your actual users’ experiences, you want your virtual users to simulate realistic scenarios. For example, the test could check functionality and response time under different degrees of load increases (sudden surges versus gradual ramp-ups) or different combinations of valid and invalid requests. If the tests reveal unacceptable performance or functionality under load, the next step is to diagnose and repair the source of the bottleneck.

When problems surface under a reasonable load, they typically indicate fundamental design problems, for example, algorithmic problems or inefficient database-application interaction. These are not infrastructure issues that can be resolved by upgrading hardware or fine-tuning system configuration. As a result, it is recommended that you begin load testing as early as possible in the development process. Ideally, you want to begin load testing on a staging server as soon as you can exercise any segment of the application. This way, you can expose and resolve problems before they become more deeply embedded into the application and fixing them requires increased time and effort.

Client testing

Simple Object Access Protocol (Soap) client developers are responsible for making sure clients send requests correctly. If a client sends invalid or improperly formed requests, usually the server cannot deliver the expected results. The process of testing clients is a little different from testing services because clients are the initiators of web-service interactions. This means that from a testing standpoint, there are two main things to verify: whether the client can correctly initiate an interaction by sending a request, and whether the client behaves as expected when he or she receives a response.

The best way to test a particular client depends on the nature of the application. If the client accesses a server that can accept test requests without any harmful side effects, it can access the live server directly during testing. However, you may need to test client functionality by emulating server-supplied responses. Emulating the server is especially useful when the server is still being implemented, has bugs, or should not be accessed during testing. For example, if you have a live system that relays sensitive company information to specific employees, you will not be able to access the server without disrupting ongoing business transactions.

No matter what type of server a client accesses, the same general principle applies: the client sends a request, the server responds, then client success or failure is determined by recording and verifying the request and/or by verifying the server response. The same techniques and tools used to verify server functionality can be used for this purpose. However, server bugs could also be misleading. If the server is not operating correctly, correct client requests might result in incorrect responses, and incorrect requests might result in apparently correct responses. You can ensure server-functionality problems are not confusing your results by first verifying the request, as well as the response, and then testing the simplest possible server implementations (server stubs) instead of, or in addition to, testing actual complex servers.

After verifying that the client sends acceptable requests and can receive responses, you should shift your attention to testing exceptional cases. For example, test that the client behaves properly when the server goes offline by sending the response to an invalid URL. Or use server stubs to simulate the server sending the client invalid data.

Ensuring web-service interoperability and security

Performing functional testing, load testing and client testing will ensure your web service functions properly and without error. However, as web-service development continues to mature, the issues of interoperability and security must also be addressed during the testing process. After all, interoperability is the main reason for utilising web services in the first place, since web services allow for the integration of disparate entities. And because of the flexibility and connectivity provided by web services, proper security measures must be taken to authenticate messages, as well as prohibit outside parties from viewing private messages. Therefore, while being sure to practise the steps necessary for a web service that is free of functional errors, developers must also practise the methods necessary to ensure interoperable and secure web services.

Interoperability

The core technologies that comprise web services (such as Soap, WSDL and XML) are designed to ease interoperability and integration. However, the mere adoption of these technologies does not guarantee seamless interoperability. The main problem that developers face today is that sometimes they inadvertently introduce platform-specific features into the web services they develop. For example, a developer may expose only a Java solution without considering the effects on a .Net client.

Ideally, interoperability would be verified by checking that a service adheres to a comprehensive, universally implemented set of standards. With the recent announcement of Basic Profile 1.0 (BP 1.0) by the Web Services Interoperability (WS-I) organisation, developers now have a set of standards to be followed. BP 1.0 consists of implementation guidelines that define how core web-services specifications should be used together to develop interoperable web services.

By restricting web-service development to technologies specified in WS-I BP 1.0, developers can increase the odds that their systems will interoperate with other systems. In addition to BP 1.0, the WS-I has also developed a set of test tools that automatically check conformance to BP 1.0. In the event of non-conformance, developers can pinpoint exactly what needs to be changed to ensure compliance to BP 1.0 and, ultimately, to ensure interoperability.

Security

Since web services can be accessed across the open internet, security risks become inherent in web-services development. Therefore, developers must know how to implement the proper security standards to ensure authentication, authorisation, data integrity, data confidentiality and proof of identity.

In addition to interoperability, the WS-I has influence over web-services security as well, with its WS-Security specification. The aim of the WS-Security specification is to define the Soap security headers and how they should be used. Developers should configure Soap headers according to the following specifications of WS-Security:

Include security evidence from the client to the server through use of security tokens. Various tokens are available, each containing different types of security evidence in various formats to allow the target endpoint of the message to verify client identity. For example, the username token contains the name of the initiating client and an optional password;
Ensure the message has not been modified through use of an XML Signature. XML Signature is a standard that allows parts of an XML document to be digitally signed, thereby providing proof that the document has not been altered since inclusion of the signature;
Ensure only the intended party can read the Soap message through use of XML Encryption. XML Encryption is a standard that uses cryptography to encrypt the Soap message to hide it from those not intended to view it.

For example, to send a secure Soap message, a client would use WS-Security to create a Soap security header that contains security evidence from the appropriate token. He or she would then sign and encrypt parts of the message to assure integrity and confidentiality. By following the standards set forth by WS-Security, developers can create a more secure and reliable web service, protecting the integrity and confidentiality of a message while authenticating the sender.

When exposing business information and operations via intranets and extranets, you must ensure that each part of your system is reliable, and that all of these parts interact flawlessly and securely. By integrating server-functional testing, load testing and client testing throughout the full web-services-development lifecycle, you can ensure a web-service server works well, regardless of the types and volumes of client requests, and that a web-service client accesses and retrieves correctly whatever data a service has to offer. Also, by following specifications such as BP 1.0, and WS-Security, you can be sure that your web service is interoperable and secure.

Whether you are creating an intranet to enable your employees to obtain and share information or developing an extranet to connect your business to outside vendors, suppliers and other partners, the future of e-business undoubtedly lies in web services. Organisations building and developing web services will do well to move in this direction, while avoiding the pitfalls that will inevitably arise with web-services development.

Dr Adam Kolawa is chairman and chief executive officer at Parasoft. He can be contacted at ak@parasoft.com.