Contract-based testing for web services

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.