Finding a Relative Testing approach for Service Oriented Architecture

A SOA (Service Oriented Architecture) is an enterprise-scale IT architecture for linking resources on demand. In a SOA, resources are made available to participants in a value net, enterprise, and line of business. Service-oriented applications can be expensive to test because services are hosted remotely, are potentially shared among many users, and may have costs associated with their invocation. For interactive web services development SOA is a good approach. To find the desire outcomes from this architecture, we have to test this architecture than we can develop desire services from this architecture. There lots of works has done to test this architecture, like unit and integration testing are used to test this architecture but these methods cannot give hundred present testing capacity. In this paper we are concentrating to find a right approach to test the SOA. Regression testing is a better approach, rather than the previous methods


I. INTRODUCTION
Service-oriented computing promises greater flexibility and efficiency in application development by enabling applications to be composed using third-party services. The term service-oriented architecture refers to a style of building reliable distributed systems that deliver functionality as services, with the additional emphasis on loose coupling between interacting services. Initiatives for service-oriented architecture (SOA) and on demand business are being adopted at various corporations to meet the operating challenges of business in the 21st century. Currently, the primary focus is to apply SOA concepts incrementally to existing information technology (IT) systems to exploit short-term business benefits. SOA is a design pattern which is composed of loosely coupled, discoverable, reusable, inter-operable platform agnostic services in which each of these services follow a well-defined standard [8]. Enterprises who are in the early stages of their SOA initiatives or those contemplating starting a SOA initiative should also address the impacts of SOA as it pertains to testing. Success of any deployment in an enterprise depends on the quality assurance process undertaken. SOA testing is quite different from traditional testing. It requires its own type of test architecture and tester skills. SOA testing spans several levels taking into account both functional and non-functional aspects of the individual services and the interenterprise federations of systems. A comprehensive and maintainable testing methodology is critical for the successful functional testing of a service-oriented system.
Regression testing help identify changes between a selected product release and a previous release of the product called a baseline. A baseline is recorded snapshot of desirable product behaviour. Regression testing is also known as validation testing and provides a consistent, repeatable validation of each change to an application under development or being modified. Each time a defect is fixed, the potential exists to inadvertently introduce new errors, problems, and defects. An element of uncertainty is introduced about ability of the application to repeat everything that went right up to the point of failure. [2] It is important to understand that regression testing doesn't test that a specific defect has been fixed. Regression testing tests that the rest of the application up to the point or repair was not adversely affected by the fix.

II. PRESENTATION OF RESEARCH
Mainly our research has been exploratory on the following points:


What do you know about Regression Testing selection method?
 How the regression testing method applied in practice?
 How can we improve the current testing methods with the help of regression testing approaches?
 What is the best approach in regression testing method?
In order to address the first and fourth questions two different kinds of systematic literature reviews have been conducted: a systematic review on regression test selection and a systematic mapping on software product line testing [5]. To justify this approach we also give a comparison table of different regression testing approaches.

III. PRINCIPAL OF SOA
There we are explaining some fundamental principles that a Service-oriented Architecture (SOA) should expose.

A. Explicit Boundaries
Services are inextricably tied to messaging in that the only way into and out of a service are through messages. A service invocation should as a general pattern not rely on a shared context; instead service invocations should be modelled as stateless.

B. Shared Contract and Schema, not Class
Starting from a service description (a contract), both a service consumer and a service provider should have everything they need to consume or provide the service. Following the principle of loose coupling, a service provider cannot rely on the consumer's ability to reuse any code that it provides in its own environment; after all, it might be using a different development or runtime environment.

C. Autonomous
Related to the explicit boundaries principle, a service is autonomous in that its only relation to the outside world at least from the SOA perspective is through its interface. In particular, it must be possible to change a service's runtime environment, e.g. from a lightweight prototype implementation to a full-blown, application server-based collection of collaborating components, without any effect on its consumers. Services can be changed and deployed, versioned and managed independently of each other. A service provider cannot rely on the ability of its consumers to quickly adapt to a new version of the service; some of them might not even be able, or willing, to adapt to a new version of a service interface at all.

D. Wire formats, not Programming Language APIs
Services are exposed using a specific wire format that needs to be supported. This principle is strongly related to the first two principles, but introduces a new perspective: To ensure the utmost accessibility a service must be accessible from any platform that supports the exchange of messages adhering to the service interface as long as the interaction conforms to the policy defined for the service. For example, it is a useful test for conformance to this principle to consider whether it is J a n u a r y 1 2 , 2 0 1 4 possible to consume or provide a specific service from a mainstream dynamic programming language. This consideration can serve as a litmus test to assess whether the following criteria are met:  All message formats are described using an open standard, or a human readable description.


The semantics and syntax for additional information necessary for successful communication, such as headers for purposes such as security or reliability, follow a public specification or standard.


The semantics and syntax for additional information necessary for successful communication, such as headers for purposes such as security or reliability, follow a public specification or standard.
 At least one of the transport (or transfer) protocols used to interact with the service is a standard network protocol.

E. Loosely coupled
Most SOA proponents will agree that loose coupling is an important concept. Unfortunately, there are many different opinions about the characteristics that make a system -loosely coupled‖. There are multiple dimensions in which a system can be loosely or tightly coupled. Dimensions include:  Time: When participants are loosely coupled in time, they don't have to be up and running at the same time to communicate.
 Location: If participants query for the address of participants they intend to communicate with, the location can change without having to re-program, reconfigure or even restart the communication partners.
 Type: In an analogy to the concept of static vs. dynamic and weak vs. strong typing in programming languages, a participant can either rely on all or only on parts of a document structure to perform its work.
 Cardinality: There may be a 1:1-relationship between service consumers and service providers, especially in cases where a request/response interaction takes place or an explicit message queue is used.
 Interface: Participants may require adherence to a service-specific interface or they may support a generic interface. If a generic interface is used, all participants consuming this generic interface can interact with all participants providing it. [7]  WSDL (Web Services Description Language) By the above discussion we can define the web services in single sentence. -A Web service is a software system designed to support interoperable machine-to-machine interaction over a network.‖ a web service is a basically a 'method' or 'function'. SOAP is the 'instructions' and 'data' to this method. It will outline data types, and possibly a bunch of data as well. It is an XML format.

VI. REGRESSION TESTING APPROACHS
Testing of SOA is a major task because only creating a better services is not sufficient for and system. Without testing we cannot say that our service is working properly, according to the desired requirement. There are such testing attempts for SOA, like unit testing and integration testing has already done but these are not sufficient to test the web services because some instant changes has performed in the web services and they cannot test each time.
Regression Testing in SOA is one of the major matters of concern because of the dynamic nature of the Service binding and the adaptability to accommodate the changed requirement. The actual configuration of the service is known only at run time, so It becomes very complex to verify whether the changes made in earlier version of the system are correct or not and it does not affect the functionality and performance of the existing system.
There are many approaches of the regression testing which are described as follows. Later on this paper we also compare these methods in a comparison

VII. WHY THE REGRESSION TESTING
Regression test helps to identify changes between a selected product release and a previous release of the product-called a baseline. A baseline is recorded snapshot of desirable product behaviour [3]. This expected behaviour is then used to ensure that nothing has been broken in the system as a result of changes introduced in a program module. Establishing a regression testing framework is crucial for building reliable and stable software products. Regression testing is usually performed by running some, or all of the test cases created to test modification in previous versions of the software.

VIII. SCENARIOS FOR FINDING FAULT
The process of the regression testing for Service is not only including the external interface's testing, but also including testing the basic services that web Service relied on. J a n u a r y 1 2 , 2 0 1 4

Fig: Composite Service testing scenarios
In the above diagram we show the testing scenarios of a web service. Now it is describing in following points.
2. After calling M1, will call M2 (also in implementation part m1 is call M2) 3. After invoking M2 it generate the self-result may be normal/abnormal.

4.
After that M1& M2 both return the result normal/abnormal. 5. Now call the M3.

And it will return the result may be normal/abnormal
It's important to locating fault in a module. Many testing symbols are produced in the test script. These symbols record the testing information, including the test steps number and the interface name of a service. The symbol is relate to the normal information and exception information that be collected during execution.

A. TEST PROCESS
Now we will define the test process of the regression testing method. It is finite state machine. The test process is a 5tuple TP = (Q,, d, q0, S ) . Where TP is the testing process.
 q0 is the initial state.
 q1 is a state the parsing script input data  q2 is a state that parsing script needs to display the value and type  q3 is a state that parsing the script to perform the web service.  Features of the Technique J a n u a r y 1 2 , 2 0 1 4

XI. SCOPE OF THE SURVEY
To the best of our knowledge no survey work has been published on Regression Testing of SOA. Hence our focus in this paper is to present a comparison of the various testing methodologies and advantages and disadvantages of these various approaches of regression testing. The survey will help to develop an automated testing approach which would be more relevant considering scenario and challenges posed by SOA based application.
There one more thing is that there are many testing tools which are based on the regression testing approaches like Soatest, TestMaker testing tool, SoapUI, E-Test, etc are available. By using these tools we can find our approach.

XII. CONCLUSION
Regression Testing in Service-Oriented Architecture is one of the important testing activities which require a lot of effort to test the system because of the dynamic nature of the system. In this paper we made an effort to put the different issues involved with Regression Testing and the analysis among different approaches which will be helpful for the automation of the SOA based Regression Testing and by using the model base regression testing we give an approach to test the Service-Oriented Architecture applications.