Whitening SOA Testing via Event Exposure

Abstract

Whitening the testing of service-oriented applications can provide service consumers confidence on how well an application has been tested. However, to protect business interests of service providers and to prevent information leakage, the implementation details of services are usually invisible to service consumers. This makes it challenging to determine the test coverage of a service composition as a whole and design test cases effectively. To address this problem, we propose an approach to whiten the testing of service compositions based on events exposed by services. By deriving event interfaces to explore only necessary test coverage information from service implementations, our approach allows service consumers to determine test coverage based on selected events exposed by services at runtime without releasing the service implementation details. We also develop an approach to design test cases effectively based on event interfaces concerning both effectiveness and information leakage. The experimental results show that our approach outperforms existing testing approaches for service compositions with up to 49 percent more test coverage and an up to 24 percent higher fault-detection rate. Moreover, our solution can trade off effectiveness, efficiency, and information leakage for test case generation.

Emerging Software Testing Technologies

“…Independent web 2 XML Schema description: https://www.w3.org/XML/Schema#dev 3 WSDL description: https://www.w3.org/TR/wsdl20-primer/ services usually provide just an interface, enough to invoke them and develop some general functional (black-box) tests, but insucient for a tester to develop an adequate understanding of the integration quality between the application and the independent web services. To address this lack, grey box proposals, trying to whitening the SOA testing, can be considered [16,116].…”

Extended Fault Taxonomy of SOA-Based Systems

“…Jinfu et al [22] have identified three types of faults: 1) interaction faults of several parameters of the same service, 2) interaction faults of parameters for different services and 3) vulnerability faults. Through effective testing, one can find the interaction fault [23], [22], [24] between parameters of the same service or interservice fault between two services.…”

“…Ye et al [23] have categorized faults into two major types: type 1 relates to the internal fault to a service and type 2 corresponds to inconsistency faults that cut across different services in a service composition. Different faulty versions of service compositions can be obtained by seeding one fault to every original service compositions using mutation testing techniques.…”

Domain-aware reputable service recommendation in heterogeneous manufacturing service ecosystem

“…Due to business interests and the privacy protection requirement (Ye and Jacobsen 2013;Dou et al 2013), rare manufacturing services offer WSDL documents or detailed QoS information for consumers. In fact, manufacturing services usually represent manufacturing capabilities; thus the tag and the description of services are more important compared with common Web services.…”

“…These methodologies cluster the services into domains based on the Web services description language (WSDL) or the quality of services (QoS). However, for most manufacturing services, there is no WSDL or QoS information available for the clustering due to the business interests and privacy protection (Ye and Jacobsen 2013;Dou et al 2013). In fact, manufacturing services usually represent manufacturing capabilities.…”