SOA测试

Question

SOA测试与传统的应用程序测试有何不同

Answer 1

As each "service-provider" should have a standard, business-oriented interface (usually provided with WSDL technology), then the following properties might be different:

• The services being provided shouldn't change from revision to revision of the modules, unless you are making extensive changes to the business itself.

• A module shouldn't care who it's clients are, which makes module-testing easier.

• Ideally, the services being consumed are provided by a directory, and not hard-coded into the modules; if this holds, then testing parts of the system -- some modules but not all -- becomes much easier as well.

Edit:

• And, as others have pointed out, you need to test conformance to the specification, and not if the present components of the system work with each other. For example, a web page might be displayed ok by Internet Explorer, but still not conform to the specification, and thus be unusable with other browsers. When you go SOA, you expect to be able to replace providers of a service seemlessly.

Answer 2

Typically SOA service tests are black box , where you use only consider the published WSDL contract, however, sometimes it is necessary to make direct validation in databases, especially when there is no capability (operation) that can be used to make the validation.

Also as a modern SOA platforms typically share resources with other service implemetation, it is important to simulate a processing load greater than or equal to the volume of production and evaluate the impact of memory, processing and I/O consumption, avoiding negative impact on services already deployed.

The most complex concern is related to contract and implementation evolution, on how to implement new functionality without breaking the existing clients, this can be specially cumbersome because there are syntax and semantic issues, for instance:

• incompatible syntax: the new contract version can have new element, but cannot have new required elements , because this will break older clients, this kind of problem is usually avoided by running automated tests implemented with both current and new contracts .
• validation abstraction: oftentimes, canonical model (xml schemas), are shared with several services in order to avoid type conversion and provide a common business language, they usually do not have all the validation required by all service operations. Then, the necessary validation logic is done directly in the service implementation . If the new version of the service implements a new set of validations that are not in the published contract, the clients must be notified and the scenarios should be tested.

The tools I commonly use are: SOAP UI and JMeter , and create custom automated tests using a in house developed framework.

Answer 3

The think you must remember is that within an environment where there are a lot of dependencies, you must have all that dependencies mapped and all paths must be tested.

Having services, they must be used with a lot of clients, so every client should follow the test cases.

With services, you also need to pay attention to network issues. Make the traditional tests putting a lot of traffic in the network and switch off to see how it works.

Besides that, having services do not require other kind of different approach. Just control all the inputs and outputs.

Answer 4

Few (valuable?) advices:

The definition of services should lead to the use of Mock framework, to validate your services consumers without relying on the implementation of the providers.

Check the robustness of your consumers: what happens when messages are lost, when a service provider is unavailable.

Answer 5

Soa testing just ensures that all independent services behave in the expected manner, all the while adhering to the input and output contract established by these services. I found an interesting SOA testing tool and it is FREE SOArite .

Answer 6

SOA testing can be defined as an extension of traditional testing.

Similar to that of traditional application where we first do unit testing of components and then component level functionality testing followed by a module level then followed by end to end application testing we have service (which sometimes is a set of components put together to achieve certain task) level unit testing, followed by functional testing, and then a process (composite service or a business process) level testing, end to end integration testing etc.

As process dwell across different types of services some of which may be wrappers, some services also can have communication constrains load constrains, service level agreements all these complicate the process of testing and these should be considered which coming up with a test strategy.