Contract-Based Testing for Web Services

Abstract

Service-oriented architectures introduce some important issues that need to be considered when performing software testing. In a service-oriented scenario, users just invoke a service, instead of physically integrating it (as it happens for components). The service provider can decide to maintain the service, and the user could not be aware of that. The dynamically constructed service-based system has to be tested dynamically and automatically at runtime without human intervention. This paper examines the use of Design by Contract for web service descriptions, and explores the issues and solutions of automatic test case generation and test oracle generation in the context of WS testing based on contracts. In our approach, the traditional concept of contracts (pre-condition, post-condition, and invariant) is extended to contain richer information, such as process control, to support automatic test generation. Contracts are used to specify the relation between a component and its clients as a formal agreement, expressing each party's rights and obligations. Contracts can be expressed in the OWL-S process model. By checking whether the web service respects its contracts, we can ascertain its validity. Therefore, contracts provide the basis for the automation of the testing process. Test case generation includes test data generation and test process generation. Valid test data are generated for all WS behaviors using the complete WS input and precondition. The control constructs of contracts are transformed to Petri-Net model, and then generated test process based on the Petri-Net behavior analysis. A test oracle provides a means for determining whether an implementation functions according to its specification. Using the output and effect of the contract of a web service and corresponding test cases, it can automatically derive the expected state for every Perform in the test case. The actual state of an executing web service in terms of Perform and their properties can be monitored and collected. Using the actual state acquired from an execution monitor, it can automatically compares the expected and actual states after each Perform to verify the correctness of the web service for the test case.

A journey to highly dynamic, self-adaptive service-based applications

“…Most testing approaches for service-based applications addressed the problem of generating and automatically executing test cases (e.g., see Dai et al 2007;Bai et al 2007b;de Almeida and Vergilio 2006;Heckel and Mariani 2005). This includes deriving test cases from service descriptions (black box tests) and from service compositions (white box tests).…”

Whitening SOA Testing via Event Exposure

“…Many approaches have been proposed to generate test cases for Web services based on WSDL [3], [48], an ontology [71], a decision table [60], a graph [81], model checking [82], and a contract [25], to just name a few. Some of these approaches (e.g., contract-based solutions) are similar to our constraint-based approach, but they provided no solutions to trade off the effectiveness, efficiency, and information leakage in test case generation.…”

XML-manipulating test case prioritization for XML-manipulating services

“…Bai et al (2007) and Bai and Kenett (2009) further propose a framework to support this group testing proposal by enforcing check-in and check-out features of web service registries, and study how to prioritize risky (also known as harmful) test cases to be executed earlier. Dai et al (2007) and Di Penta et al (2007) propose to add contracts to service descriptions to serve as a kind of correctness criterion (or test oracle) to check test results. Chan et al (2005Chan et al ( , 2007 use metamorphic relations of applications to test stateless scientific web services.…”