(PDF) Distributed, Cross-Platform, and Regression Testing Architecture for Service-Oriented Architecture

Advances in Computer Science and its Applications (ACSA), ISSN: 2166-2924, Vol. 1, No. 1, March 2012 http://worldsciencepublisher.org/journals/index.php/ACSA/article/download/135/158 Distributed, Cross-Platform, and Regression Testing Architecture for Service-Oriented Architecture Youssef Bassil LACSC – Lebanese Association for Computational Sciences Registered under No. 957, 2011, Beirut, Lebanon Email:

Abstract– As per leading IT experts, today’s large enterprises are going through business transformations. They are adopting service-based IT models such as SOA to develop their enterprise information systems and applications. In fact, SOA is an integration of loosely-coupled interoperable components, possibly built using heterogeneous software technologies and hardware platforms. As a result, traditional testing architectures are no more adequate for verifying and validating the quality of SOA systems and whether they are operating to specifications. This paper first discusses the various state-of-the-art methods for testing SOA applications, and then it proposes a novel automated, distributed, cross-platform, and regression testing architecture for SOA systems. The proposed testing architecture consists of several testing units which include test engine, test code generator, test case generator, test executer, and test monitor units. Experiments conducted showed that the proposed testing architecture managed to use parallel agents to test heterogeneous web services whose technologies were incompatible with the testing framework. As future work, testing non- functional aspects of SOA applications are to be investigated so as to allow the testing of such properties as performance, security, availability, and scalability. Keywords – Testing Architecture, Service-Oriented Architecture, Web-Service, Cross-Platform Testing, Regression Testing 1. Introduction over multiple distributed server machines; it is cross- platform as it supports the testing of heterogeneous web Many of today’s enterprises are converting their services built using heterogeneous technologies; and it is information systems into new IT models based on e- capable of regression testing as it supports partial testing services called Service-Oriented Architecture or SOA for of sub-systems that have been recently changed or short [1]. Fundamentally, SOA is the practice of updated. All in all, the proposed architecture is meant to designing and developing information systems using automate the testing of complex and heterogeneous SOA- loosely-coupled interoperable software components [2]. based systems while achieving a good level of efficiency, SOA offers a number of benefits and advantages, such as performance, and quality. flexibility, agility, reusability, scalability, maintainability, and interoperability [3]. However, adopting SOA comes 2. Service-Oriented Architecture with significant challenges, mostly related to the testing of SOA-based systems [4]. In fact, as SOA is an Service-Oriented Architecture (SOA) is a model for integration of several heterogeneous components, each system development based on loosely-integrated suite of built using different technologies and having services that can be used within multiple business incompatible interfaces, validating and verifying the domains [5]. Commonly, SOA is built using web service operation of SOA can be viewed as a complex and software components which are designed to support challenging computing problem. interoperable machine-to-machine interaction over a This paper presents a number of already existing network. Predominantly, web services use SOAP (Simple approaches and techniques for testing SOA applications Object Access Protocol), an XML-based protocol, to from different test levels including unit, integration, communicate over the HTTP protocol. Besides, they use regression, distributed, and functional testing. WSDL (Web Service Description Language) to describe Furthermore, this paper proposes a new automated, their internal functionalities and UDDI (Universal distributed, cross-platform, and regression testing Description, Discovery, and Integration), a global registry architecture for testing SOA applications and their web and repository, to register and store their WSDLs [6]. service components. It is made out of a test engine unit Web services are governed by the producer- capable of conducting regression testing; a test code consumer/provider-requester model in which the provider generator unit capable of generating client scripts for test owns the necessary equipment to host web services, and execution; a test case generator unit capable of generating the requester connects to these web services and starts test conditions, variables, and data sequences; a test calling their exposed functions through method executer unit capable of applying test cases to web invocation mechanism. Several styles and types of web services; a test monitor unit capable of evaluating the services exist, they include but not limited to SOAP, testing results; and a database that stores valuable testing REST, .NET Remoting, RMI, RPC, and others. Figure 1 parameters throughout the testing process. depicts the provider-requester model of a SOAP-based The proposed architecture has many benefits: It is web service. distributed as it supports parallel testing of web services Advances in Computer Science and its Applications (ACSA), ISSN: 2166-2924, Vol. 1, No. 1, March 2012 http://worldsciencepublisher.org/journals/index.php/ACSA/article/download/135/158 In practice, SOA can be tested using different test levels and techniques which can be summarized as follows [10]: Unit Testing: It is the process of testing individual web services in isolation. The web service is disconnected from the SOA and tested separately in offline mode. Unit testing is usually conducted by developers to verify that the basic functionalities of web services are working correctly and according to specifications. Integration Testing: It is the process of testing the Figure 1. Provider-Requester Model of Web Services SOA as a collection of web services that are working 3. Testing SOA together in a group. It, in fact, focuses on testing web service interfaces to determine if communication and Software testing is an investigation carried out to information sharing between them are working correctly determine whether a software is working correctly and according to specifications. according to specifications [7]. The scope of software Regression Testing: It is the process of re-testing an testing includes the validation and verification of the SOA that has been lately modified or updated to ensure system’s functional as well as non-functional properties. that it does not fail due to the newly introduced repairs. In that sense, the testing process can be defined as: Since each time a defect is fixed, there is a possibility that new errors get introduced, regression testing re-executes  Find if a software product is free of defects and is previously successful tests and checks whether previously producing a correct output and; working web services are still working correctly and according to specifications.  Find if a software product meets the customer’s Functional Testing: It is the process of testing the requirements as well as other technical basic functionalities of an SOA application. For example, requirements that guided its design and testing if a web service that is exposing an addition development. function is able to add two numbers correctly and according to specifications. As manual testing is a laborious and time consuming Non-Functional Testing: It is process of testing the process, test automation has been employed thoroughly in non-functional aspects of an SOA application which many domains and fields. In essence, test automation includes such properties as quality, performance, security, uses software to perform, control, and monitor the availability, interoperability, and other features already execution of testing. It utilizes test cases which are set of agreed on in the design specification stage of the SOA input variables and their expected output that the test project. executer will apply to the software under test to determine whether it is working correctly according to specifications [8]. 4. SOA Testing Challenges Since SOA-based systems are form of software, they should be tested too; however, since they are composed Testing SOA is somehow an intricate and a of a collection of fine-grained software components challenging computing problem, and that is due to several distributed over a network, they must be tested from a reasons, some of which are outlined below [11, 12]: service-by-service viewpoint i.e. testing each web service of the SOA in isolation; from an end-to-end viewpoint i.e. 1. SOA are distributed in that they are composed of testing the SOA as an aggregate of sub-systems; and from web service components dispersed over different an interface-by-interface viewpoint i.e. testing the hardware and operating system platforms; thus, interoperability between the different web services of the testing must cover the different deployment SOA [9]. The different steps for testing SOA applications configurations. can be outlined as follows: 2. SOA are dynamic in that they implement adaptive behaviors such as adding new services, integrating 1. For a given SOA system under test, generate and new services, and removing old ones; execute a set of test requests. consequently, performing an effective regression 2. Receive and evaluate the returned responses. testing can be a challenging task. 3. If the evaluation yields to a negative feedback, 3. SOA are complex in that they can be seen as a then the cause could be located in any of the web mesh of interacting services each having specific services that make up the SOA system under test: functionalities and capable of different operations; i. Repeat the above steps but for every service in thus, designing test cases for test automation can isolation. be a complicated and a demanding task. ii. Find the malfunctioning web service, and 4. SOA are closed in that they are made out of closed refine it accordingly. services that run on the provider’s side and clients 4. Repeat step 1 to step 3 until a positive feedback is have no control over their implementations; thus, obtained. Advances in Computer Science and its Applications (ACSA), ISSN: 2166-2924, Vol. 1, No. 1, March 2012 http://worldsciencepublisher.org/journals/index.php/ACSA/article/download/135/158 preventing white-box testing methods that are service that has successfully passed the test. The essential to conduct exhaustive system validation. proposed testing steps are as follows: 5. SOA are remote in that their services are commonly located on the provider’s server; and 1. Connect to a particular UDDI registry, possibly therefore, testing SOA can be costly, especially, if located on the Internet, to search for a certain web services are charged on a per-use basis. Moreover, service component to test. Once its WSDL is service providers could suffer from denial-of- found, binding occurs between the web service, service (DoS) in case of massive testing. now called WSUT (Web Service under Test), and 6. SOA are heterogeneous in that their services the testing framework. deliver no standard interfaces for inter- 2. The test case generator generates a test case that communication as they are built using contains a series of function calls and data incompatible technologies, platforms, and parameters. Afterwards, the test engine connects to programming languages; thus, it would be the WSUT and executes the test cases by calling necessary to build multiple types of test engines the functions of the WSUT through the SOAP each pertaining to a particular service platform. protocol. The test engine then receives the response results from the WSUT and compares 5. Existing SOA Testing Approaches them with the expected results. 3. If both results match, then the WSUT is confirmed This section reports the recent research achievements to pass the test, and its URL is saved into the log related to SOA testing including basic unit testing, file; otherwise, the WSUT is confirmed to be distributed testing, testing by redundancy, integration defected and thus it is discarded. testing, and regression testing. 4. The above steps are repeated for testing another web service. 5.1. Basic Unit Testing Figure 3 depicts the inner-workings of this approach. A basic unit testing was proposed by [13]. The idea centers on testing individual web services using a test case generator and a test case executer. The proposed testing steps are as follows: 1. Code Generation: The necessary client code, also known as test script, is generated. Its purpose is to emulate a client consumer and to execute test cases. 2. Test Case Generation: A test case generation tool, the JCrasher, is used to generate test suites which are mainly composed of test cases. 3. Test Execution: The generated test cases are executed by invoking the various functions of the Figure 3. Another Typical Basic Unit Testing web services under test. Web services responses are then collected and validated against original 5.1.1. Drawbacks system’s specifications. 1. Serial testing: The generation and execution of Figure 2 depicts the various modules of the basic unit test cases are done sequentially; parallelism or testing approach. distribution of testing processes is not exploited. 2. No support for regression testing: In case of an update, all SOA components must be re-tested all over again. 3. No support for integration testing: All web services are tested in isolation; group testing is not exploited. 4. Single-platform testing: only SOAP-based web services can be tested; testing other types of web services such as REST or RMI is not exploited. 5.2. Distributed Testing Figure 2. Typical Basic Unit Testing A distributed SOA testing approach was presented by Another basic unit testing technique was proposed by [15] in which test cases are generated automatically based [14]. The approach uses a test case generator to generate on the WSDL of the web service under test. The WSDL test suites; a test engine executer to monitor the execution file is first parsed and transformed into a structured DOM of test cases; and a log file to store the URL of the web tree. Then, test cases are generated and executed by a Advances in Computer Science and its Applications (ACSA), ISSN: 2166-2924, Vol. 1, No. 1, March 2012 http://worldsciencepublisher.org/journals/index.php/ACSA/article/download/135/158 series of agents on distributed server machines. The approach employs multiple service brokers that can perform SOA testing simultaneously, each of which is equipped with a test case generator and a test execution controller. Below are the different units of this proposed distributed approach. Figure 4 shows the operation of these components. 1. Test Case Generator: It connects to the WSDL of the web service under test and automatically generates the necessary test cases which will be stored in a central database. 2. Test Execution Controller: It controls the execution of test cases in a distributed Figure 5. Testing By Redundancy environment. Its job is to retrieve test cases from 5.3.1. Drawbacks the test database, assign them to test agents, monitor test runs, and collect test results. Accuracy is dependent on the number of web services: 3. Test Agents: They are dispersed in a LAN or The system will perform poorly if the number of web WAN area. An agent is a proxy that performs services is minimal; whereas, the precision of the voting remote testing on target services with specific system will increase as more web service are evaluated. usage profiles and test data. 4. Test analyzer: It analyzes test results, evaluates 5.4. Integration Testing the quality of services, and produces test reports. [17] proposed an XML-based testing framework named Coyote for service integration testing in SOA. Coyote consists of two modules: a test master and a test engine. The test master allows testers to convert WSDL specifications into test scenarios and test cases, as well as performing non-functional analysis such as dependency, completeness, and consistency analysis. On the other hand, the test engine interacts with the web services under test, and provides tracing information. Integration testing is done during the development life cycle after the completion of the system specification phase. Every sub- Figure 4. Distributed Testing for SOA system is tested using a stub proxy which houses all the 5.2.1. Drawbacks required test suites and test scripts. The testing process goes top-down from the root SOA system to the leaf web 1. No support for regression testing: In case of an service. This way, every child web service is verified update, all SOA components must be re-tested all whether it can communicate with its parent service. A over again. top-down approach has two foremost advantages: It is 2. No support for integration testing: All web easy to implement, and broken function calls and links services are tested in isolation; group testing is not can be discovered more efficiently. Figure 6 depicts the exploited. Coyote top-down testing approach. 3. Single-platform testing: only SOAP-based web services can be tested; testing other types of web services such as REST or RMI is not exploited. 5.3. Testing by Redundancy [16] proposed a collaborative redundancy-based verification and validation testing technique for SOA applications. In this approach, testing is conducted by evaluating multiple redundant web services at the same time. Then using a voter, the test engine compares the Figure 6. Coyote Integration Testing results of all web services under test. Only the web service, whose output is different from the other ones, is 5.4.1. Drawbacks assumed to contain a fault. The advantage of this approach is that it does not require generating or 1. Top-down approach: Bugs are harder to be found implementing the client code. Evaluation is solely done and can interrupt the testing process. by voting. Figure 5 shows the basic test architecture of 2. No support for regression testing: In case of an this technique. update, all SOA components must be re-tested all over again. Advances in Computer Science and its Applications (ACSA), ISSN: 2166-2924, Vol. 1, No. 1, March 2012 http://worldsciencepublisher.org/journals/index.php/ACSA/article/download/135/158 3. No support for integration testing: All web SOA systems. It supports the testing of multiple web services are tested in isolation; group testing is not services simultaneously using different instances of exploited. testing elements executed over distributed servers. In 4. Single-platform testing: only single-protocol web addition, it supports test planning and scheduling for services can be tested; testing multiple types of multiple types of web services built using heterogeneous web services such as REST or RMI is not technologies, programming languages, and platforms. exploited. Finally, it supports regression testing by re-running previously executed test suites on the sub-systems that 5.5. Regression Testing changes have been made to them. Below are the basic features and advantages of the proposed testing [18] proposed a regression testing approach for testing architecture: SOA applications. The role of regression testing is to uncover new software faults, called regressions, in  Distributed: It is capable of testing multiple web existing parts of a system after changes have been made services concurrently on different machines, to them [19]. In this method, test cases are first generated, achieving better performance and higher and then read by a test harness module which executes throughput. test cases over the various web services under test. The  Cross-Platform: It is capable of testing test harness module then collects the web service heterogeneous web services built using different responses and stores them into a separate database to be platforms, different standards, and different later compared if they match the expected results. In case programming languages. changes occur to the system, previously run tests are re-  Regression Testing: It is capable of partial testing executed to check whether or not the behavior of the for system parts that have been changed recently, whole SOA system has changed. Figure 7 depicts the improving the quality assurance efficiency regression testing architecture for SOA systems. and reducing the time to re-validate SOA systems after changes have been made to them. From a design standpoint, the proposed testing architecture consists of two parts: The part where the SOA application under test executes and the part where the testing framework executes. Figure 8 depicts these two parts together with their units and modules. Figure 7. Regression Testing Architecture 5.5.1. Drawbacks 1. Test suites complexity: Test cases can be too large if changes come in too fast. 2. Low performance: Exhaustive test can increase the testing execution time and reserve a lot of resources. 3. Single-platform testing: only single-protocol web services can be tested; testing multiple types of web services such as REST or RMI is not exploited. 6. Proposed Testing Architecture Based on the previous discussion of various SOA testing techniques, it is obvious that most of them can only support the testing of web services that are built using homogeneous technologies. However, it is no longer expected to test an SOA application that was designed using unified standards and protocols. Furthermore, all these previously discussed techniques are single-server single-machine systems, in that, testing multiple web services cannot be done in a parallel fashion but sequentially one after the other. Figure 8. Parts of the Proposed Testing Architecture This paper proposes a new automated, distributed, cross-platform, and regression testing architecture for Advances in Computer Science and its Applications (ACSA), ISSN: 2166-2924, Vol. 1, No. 1, March 2012 http://worldsciencepublisher.org/journals/index.php/ACSA/article/download/135/158 6.1. The SOA Part The database unit stores generated test cases along with the IDs of the web services under test, in addition to Essentially, the SOA part of the proposed testing other miscellaneous testing parameters. In fact, the chief architecture is majorly composed of web services under purpose of the database is to assist in the regression test, parallel agents, end-point adapters, and a central testing process. It permits the test engine unit to middleware. effectively retrieve and re-use the proper minimum set of The web services under test can be of any type and previously stored test parameters and to execute them technology including SOAP, REST, .NET, Java or any whenever a partial change has been made to the SOA X-technology; thus, providing a cross testing platform for application. That way, the test engine can check whether SOA-based systems. the SOA behavior has changed and whether previously The parallel agents ensure a distributed testing by fixed defects have recurred after fractional system working as load balancers that distribute the test-load updates. across multiple servers to achieve optimal resource utilization and to maximize throughput during the testing 7. Experiments & Results process. All test requests sent to web services under test are allocated to a free agent that, in turn, allocates them in As a proof of concept, a sample SOA application was a round robin fashion to any available back-end server tested using the proposed testing architecture. The target machine to process the request. Agents constantly go on was to test a SOAP-based web service to prove the and off as test requests flow throughout the SOA. distributed testing capability of the parallel agents and the Adapters are end-point connectors that bridge a test cross-platform testing capability of the middleware. The request with its destination service. They provide specifications for the conducted experimentation are standardization and interoperability as they permit the below: interaction between the test engine and the different web services under test regardless of their underlying  Web service under test: A web service that technologies and standards. contains an addition function to add two integer Adapters are supported by a central middleware that numbers. provides two interfaces: The first interface is from the  Technology of the web service under test: SOAP SOA under test side which is mainly represented by the  ID of the web service under test: 5 end-point adapters, and the second interface is from the  Test case: Calling function add(x, y) and sending testing framework side. The latter provides a unified integers 10 and 20 as test parameters. XML interface to format test requests sent by the test  Test code: Implementation of the add(x, y) engine to the web services under test. The test engine, function. through the middleware, sends XML-formatted test requests to web services under test regardless of their Below is the sequence of steps that were executed underlying technologies. The middleware then converts during the experimentation: the received XML test requests into a format that is compatible with the addressed web service. As a result, Step 1: The test code generator unit generated the the middleware provides a transparent communication client code, and stored it into the database together with between the test engine and the different web services of the ID=5 of the service under test. the SOA under test despite their incompatible Step 2: The test case generator unit generated the test technologies and platforms. case, namely the function call add(10, 20), and stored it into the database together with the ID=5 of the 6.2. The Testing Framework Part service under test. Step 3: The test engine unit connected to the Basically, the testing framework is composed of middleware and sent through it a test request to the several units each having a particular task to achieve and SOAP-based web service under test in XML format. they are: The test request represents a particular test case The test engine unit coordinates, controls, and composed of a function call alongside with a set of data manages the various testing units and their processes, and parameters, in this case add(10, 20). The middleware is capable of performing regression testing. first received the test request message and converted it The test code generator unit generates test scripts and from XML format into the protocol of the web service client code necessary to execute the test cases. under test, in this case the SOAP protocol. The test case generator unit generates all test Step 4: The middleware routed the converted test scenarios, data suites, variables, and conditions necessary request to the adapter that is compatible with the to create test requests and function calls and parameters service under test, in this case, the SOAP adapter. for the web services under test. Step 5: The adapter then located a free agent to handle The test executer unit executes the generated client the test request. Once located, the free agent tried in code on the test cases, dispatches test requests, and sequence to locate the best machine on the network to collects testing results. process the request. The test monitor unit evaluates and compares the Step 6: The agent bound to the web service under test results obtained from the test executer unit and the results which executed the test request and returned back the obtained from the web services under test. integer 30 as the addition results of 10+20 in a SOAP Advances in Computer Science and its Applications (ACSA), ISSN: 2166-2924, Vol. 1, No. 1, March 2012 http://worldsciencepublisher.org/journals/index.php/ACSA/article/download/135/158 message. The SOAP adapter received the response and provides interoperability between the testing framework routed it to the middleware. The middleware then and the SOA application; and regression testing by converted the SOAP message into XML and forwarded employing a database that stores all successfully executed it to the test monitor unit. test cases so that they can be re-used to cover recent Step 7: The test executer unit executed the client code system modifications. Essentially, the testing framework using the same test case, and reported the integer 30 as comprises several testing units including test engine, test results. code generator, test case generator, test executer, and test Step 8: The test monitor unit then compared the results monitor units. Experiments conducted showed that the obtained from the web service response and the results proposed testing architecture managed to use parallel obtained from the test executer unit. As both results agents to allocate testing processes to distributed server matched, the executed test case was marked as machines and succeeded in exploiting its middleware to successful in the database. Generally, if both results test heterogeneous web services whose technologies were match, the corresponding test case is marked as incompatible with the testing framework. successful in the database; otherwise; it is flagged as As future work, testing non-functional aspects of SOA unsuccessful, and another test case is executed. applications are to be investigated, bringing in a complete testing solution that can not only test SOA functional Below are two messages observed during the operations but also non-functional qualities such as experimentation: The first is the XML test request sent by performance, security, availability, and scalability. the test executer unit to the middleware, and the second is its equivalent SOAP message converted by the Acknowledgments middleware and sent to the web service under test: This research was funded by the Lebanese Association <request> <WS-ID>5</WS-ID> for Computational Sciences (LACSC), Beirut, Lebanon, <function-to-call>add</function-to-call> under the “Simulation & Testing Research Project – <parameters> STRP2012”. <param>10</param> <param>20</param> References </ parameters > <timestamp>2/25/2012 05:22:17PM </timestamp> [1] Faisal Hoque, e-Enterprise: Business Models, Architecture, and </request> Components, Cambridge University Press, 2000. [2] Thomas Erl, Service-Oriented Architecture: Concepts, <?xml version="1.0"?> Technology, and Design, Prentice Hall, 2005. <soap:Envelope [3] Offermann, P. Hoffmann, M. Bub, Benefits of SOA: Evaluation xmlns:soap="http://www.w3.org/2001/12/soap-envelope" of an implemented scenario against alternative architectures, soap:encodingStyle="http://www.w3.org/2001/12/soap- Enterprise Distributed Object Computing Conference Workshops, encoding"> EDOCW-2009, 13th, 2009. [4] G. Canfora and M. Di Penta, Service-oriented architectures <soap:Body> testing: A survey, in Proceedings of the 31st International Spring <m:add> Seminar on Electronics Technology (ISSSE 2008), Budapest, <m:x>10</m:x> Hungary, 2008, pp. 78–105. <m:y>20</m:y> [5] Nicolai M. Josuttis, SOA in Practice, O’Reilly, 2007. </m:add> [6] Fielding, Roy T., Taylor, Richard N, Principled Design of the </soap:Body> Modern Web Architecture, ACM Transactions on Internet </soap:Envelope> Technology (TOIT), (2002), 2(2): 115–150. [7] Ron Patton, Software Testing, 2nd ed., Sams Publishers, 2005. [8] Cem Kaner, Exploratory Testing, Quality Assurance Institute It is worth noting that in case of performing regression Worldwide Annual Software Testing Conference, Orlando, FL, testing, only the test cases that were previously tested and 2006. marked as successful and whose ID matches the ID of [9] G. Canfora and M. Di Penta, SOA: Testing and self-cheking, in Proceedings of the International Workshop on Web Services web service that has been modified, are fetched from the Modeling and Testing, Palermo, Italy, 2006, pp. 3–12. database and re-used to re-evaluate this particular web [10] Luciano Baresi, Test and Analysis of Web Services, 1st ed., service. Springer, 2007. [11] C. Bartolini, A. Bertolino, S. Elbaum, and E. Marchetti, Whitening SOA testing, in Proceedings of the 7th joint meeting of the 8. Conclusions & Future Work European software engineering conference and the ACM SIGSOFT symposium on the foundations of software engineering, Amsterdam, The Netherlands, 2009, pp. 161–170. This paper presented an extensive review for the [12] Scott Barber, SOA Testing Challenges, Technical Report, various methodologies and research achievements related PerfTestPlus, 2006. to SOA and web service testing. It, additionally, [13] [13] Evan Martin, Suranjana Basu and Tao Xie, Automated discussed the different challenges that SOA applications robustness testing of web services, In Proceedings of the 4th International Workshop on SOA And Web Services Best Practices go through when testing their functional and non- (SOAWS), 2006. functional properties. Furthermore, this paper proposed a [14] Abbas Tarhini, Hacène Fouchal, Nashat Mansour: A Simple novel architecture for testing SOA applications. It Approach for Testing Web Service Based Applications, IICS, supports the following features: Distributed testing by 2005, pp.134-146 [15] Bai, X., Dong, W., Tsai, W.T., Chen, Y., Wsdl-based automatic employing parallel execution agents that can distribute test case generation for web services testing, In the IEEE the testing process over multiple machines; cross- International Workshop on Service-Oriented System Engineering platform testing by employing a central middleware that Advances in Computer Science and its Applications (ACSA), ISSN: 2166-2924, Vol. 1, No. 1, March 2012 http://worldsciencepublisher.org/journals/index.php/ACSA/article/download/135/158 (SOSE), Los Alamitos, CA, USA, IEEE Computer Society, 2005, pp.215–220. [16] Tsai, W.T., Chen, Y., Paul, R.A., Liao, N., Huang, H., Cooperative and group testing in verification of dynamic composite web services, In the Proceedings of the 28th International Computer Software and Applications Conference (COMPSAC 2004), Hong Kong, China, 2004, pp. 170–173. [17] Tsai, W.T., Paul, R.J., Song, W., Cao, Z., Coyote: An XML-based framework for Web services testing, In the 7th IEEE International Symposium on High-Assurance Systems Engineering (HASE 2002), Tokyo, Japan, 2002, pp.173–176. [18] Di Penta, M., Bruno, M., Esposito, G., Mazza, V., Canfora, G., web services regression testing, In Baresi, L., Nitto, E.D., eds.: Test and Analysis of web Services, Springer, 2007, pp205–234. [19] Glenford Myers, The Art of Software Testing, Wiley Publishers, 2004.