SOA Testing

Many testing techniques and methodologies developed over the years apply to Web Services-based SOA systems as well. Through functional, regression, unit, integration, system and process level testing, the primary objective of testing methodologies is to increase confidence that the target system will deliver functionality in a robust, scalable, interoperable and secure manner.
Web Services are the foundations of modern Service Oriented Architecture (SOA). Typical Web Services include message exchange between front end and backend using SOAP request and responses over the HTTP protocol.
A Web service producer advertises its services to potential consumers through Web Services Description Language (WSDL) – which is an XML file that has details of available operations, execution endpoints and expected SOAP request-response structures.
Techniques such as Black, White and Gray Box testing applied to traditional systems map well into Web Services deployments. However, the following characteristics of Web Services deployments introduce unique testing challenges:

 Web Services are basically distributed and are platform and language atheist.
 Web Services can be chained with dependencies on other 3rd party Web Services that can change without notice.

SOA frameworks are a combination of web components, mid-tier components, back-end and legacy systems, unlike traditional testing approaches, SOA testing approach should include all the aspects of business processes and also its integration framework.
SOA Testing Strategy should not only focus on just the functionality or the front-end clients but also on the integration layers, so its necessary to keep all these things in mind while creating a SOA test plan or strategy.

Following types of testing should be performed to ensure proper E2E testing so that Integration framework is covered.
• Functionality
• Interoperability
• Performance
• Security

The challenge of testing the SOA is the processes flow across application stacks and technologies. Unlike preceding generations of client-server and mainframe systems, SOA systems are not screen-centric but integration-centric. This poses a unique challenge for testing methodologies, which rely heavily on screen verification to validate the integrity of the entire process.
No user interface for the services in SOA; applications Lack of visibility into loosely coupled business level services and dependency on availability of any internal or external services that offers a business function to perform E2E testing.
SOA initiative has thrown complexities in the integration framework that requires complete testing of business workflows across every heterogeneous technology layer of the SOA at both system and component level.
Web service will not always connect with the end users to GUI application. There could be cascading of Web services. Or, one Web service may be calling another. There could be significant real-world business software dependencies between Web services, such as output of one Web service passed out into the other Web service, and so forth, without any GUI being involved. Testing this kind of business process orchestration cannot be done if you are using an indirect GUI-based testing approach, or some sort of unit-level of Web services end-point testing.
This poses a challenge on testing methodologies.

 Test Coverage
 Client level validation
 Service level validation
 Multiple message format
 Test Automation
 Client Simulators (Message simulation)
 Service Simulators
 Automatic test data creation
 Choosing the right test automation tool
 Maintaining pool of testing resources with SOA domain knowledge

Security, compliance, and reliability testing of Web services is vital to successful SOA implementations, particularly those that are externally facing and business critical.
In any software development project, testing requires significant time, effort, and discipline. The following common steps should be followed to assure proper and efficient testing:

• Define a test plan that outlines the testing process and exit criteria
• Derive test cases from use cases or business requirements
• Generate test data and/or scripts for each test case
• Outline the expected results for each test case
• Execute the test cases
• Verify whether the results of the test cases match the expected results
• Generate reports to measure the software's quality against the test cases
• Fix/resolve remaining defects in the software
• Continue executing/verifying/fixing until all test cases succeed and defects are resolved

In House Test Tools

Focus is drawn towards developing & maintaining the in house test tools than the actual testing these tools can look very much customized and cost effective however In-house test tool itself need to undergo testing to ensure it is coded to the specifications and Dependency on in-house tools will impact test schedules & quality of the deliverable in demanding situations plus their actual development is also very time consuming.
Traditional Testing Tools
While testing Web Services SOAP requests needs to be generated manually or using a supported third party vendor testing tool.
Integrating traditional functionality testing tool and other such third party tool is not feasible due to their nature and limitations. A mix of manual and automated process is an additional overhead to sum it all It’s a time consuming and expensive effort
Web Services Testing Tools
These tools Provides robust, reliable, scalable and interoperable solution, they are best fit for UI less testing, just enter WSDL location and they can create basic functional tests for you.
Most of the tools even check your WSDL compliance to WS-I. They also support Asynchronous testing and Data-driven testing using data sources.
These test tools provides a solution for load testing and one of the best features is to fully reuse functional tests for load testing so that saves precious time.
Tools like SOAtest (http://www.parasoft.com) Integrates with Quality Center, TestManager and VSTS Edition for Testers, It features a host of new and extended capabilities, including Microsoft .NET WCF Support, integration with Microsoft VSTS, automated stub creation and deployment from existing test suites, continuous load testing, and advanced XML validation I have used it in my current project for Load testing and I found it good.
Testing like Security penetration testing can easily be done using tools like SOAtest and SOAPsonar(http://www.crosschecknet.com/). SOAPsonar also offers Functional, Performance, Compliance, and Vulnerability testing modes with Comprehensive Identity Management Testing along with Complex WSDL and schema parsing that’s something which should not be missed while testing webservices.
Test data generation for any WSDL version is possible and easily maintainable and depending on existing legacy systems & back-end applications, web services test tools can be tweaked by developing / modifying test scripts to provide an E2E solution for backward compatibility.
Also there is wide range of tools from Greenhat (http://greenhatsoftware.com/ ). If you are looking for open source tools then soap UI (http://www.soapui.org/ ) is the best choice for Web Services its great if you want to test your webservice for Functional testing however they also offer a professional version with some additional features but for a price.
To conclude In order to test SOA successfully you must verify all aspects of a Web service, from WSDL validation, to unit and functional testing of the client and server, to performance, load and security testing. There’s more to testing than reviewing and debugging code and interfaces for particular applications. Web services are not designed as standalone apps; they exist to interact and eventually form the fine-grained building blocks of larger service-oriented architectures. The interaction and process flow needs to be tested thoroughly the Web service Testing tool that you have chosen should address key Web service issues such as interoperability, security, change management, and scalability.

The last and best option is a fully integrated testing solution that enables testers to test at each point and end-to-end. This would include these key capabilities:

1. Creating and sending a message to a provider application;
2. Receiving and verifying a message to a consumer application;
3. Either sending or receiving messages to or from files when the applications aren't available or to isolate the infrastructure, and
4. Testing end-to-end through the user interface of the provider and consumer applications and the messages in between.

Benefits of Testing SOA

• Ensure the reliability, quality, security and interoperability of the Web service.
• Penetration testing integrated with functional testing for complete coverage.
• Uniform test suites can be rolled over from unit testing to functional testing to load testing to security testing.
• Prevent errors, pinpoint weaknesses, and stress test long before deployment.
• Verify data integrity and server/client functionality.
• Identify server capabilities under stress and load.
• Accelerate time to market.

SOA-Service Oriented Architecture

Service-Oriented Architecture, or SOA, enables IT Organizations to make the transition from an application-centric view of the world to a process-centric view, and, because the integration mechanism of SOA (usually Web Services) enables loosely coupled integration, organizations can upgrade or change applications without impacting other applications.
Service-oriented architecture is a group of services that communicate with each other. The process of communication involves either simple data-passing or two or more services coordinating with some activity. Intercommunication implies the need for some means of connecting services to each other. SOA uses the Web services standards and technologies and is rapidly becoming a standard approach for enterprise information systems.
Web services face significant challenges because of particular requirements. There are many problems that are to be addressed when applying the SOA paradigm to a real-time system, which include response time, support of event-driven, asynchronous parallel applications, complicated human interface support, reliability, etc.

Oasis defines SOA as — “An architectural style whose goal is to achieve loose coupling among interacting software agents / services.”
In SOA, application logic is in the middle-tier for me it was Tuxedo, operating within numerous technologies most of the time its integration with third party applications.


(image taken from http://www.sun.com/)

To test SOA, you need to go far beyond merely testing a user interface or browser screen as you never find an attractive UI while testing these apps as most of the time you’ll be sitting at backend verifying XML’s with UNIX , Tuxedo or Tibco and weblogic logs.


(image taken from http://www.tibco.com/)

Web Services (WSDL/SOAP) will be an important component for many SOAs.
Let’s discuss them a bit.
SOAP is a simple XML based protocol to let applications exchange information over HTTP.
Or more simply: SOAP is a protocol for accessing a Web Service. It is important for application development to allow Internet communication between programs.
Today’s applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic.
A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this. SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages. WSDL (Web Services Description Language) is an XML-based language for describing Web services and how to access them.
Basically WSDL is a document written in XML. The document describes a Web service. It specifies the location of the service and the operations (or methods) the service exposes.
when you deploy the code in your test environment normally the wsdl url is present in /init.properties file, before building the code just make sure that the correct URL to which Webservice need to hit is added.
Once code is build then deploy the ear files into weblogic servers and just restart them.
In order to efficiently use a SOA, one must meet the following requirements:

•Interoperability between different systems and programming languages should be present.

•Desire to create a federation of resources. Establish and maintain data flow to a federated data warehouse. This allows new functionality developed to reference a common business format for each data element.