To illustrate how service virtualization can be used in a specific application, first an example scenario:
3 steps to the virtual image:
First, a system is built using the first available components. All other required components are virtualized.
Then new components can be introduced into the system one after the other and the virtual components are replaced. In this phase, incremental integration tests can be performed.
Finally, the stage is reached where all components are available. This means that complete end-to-end tests can then be performed, since the phase has been worked towards step by step throughout the entire test process.
Procedure: Two Types
Virtualization can be done in the following two ways:
This is followed by the customization and extension of the virtual stub – for example, as a response to requests with specified error messages.
Service virtualization can be used to create replicas of real services.
The response behavior of the services to be virtualized is simulated. The behavior is freely configurable and can be adapted at any time, for example by new responses, incorrect feedback, program logic or simple return values (true, false). Its complexity does not have to correspond to that of the real services.
Non-availabilities of services are simulated by recorded or synthetically generated response data sets.
Main Applications
Several main application cases exist for the use of service virtualization:
In Detail:
It should be noted that virtualized services cannot reproduce 100% of the behavior of a real application! Therefore it is not a web service replacement! The behavior should be simulated so that the technical interface corresponds to the real system and can be tested, and the first meaningful integration tests can be carried out.
The service virtualization is also strategically valuable, because it can be used in all test stages and phases up to acceptance test (does not correspond to the requirements).
The risk of introducing components can be reduced as the interfaces are tested in advance.
Virtualization can also be carried out for training instances. The infrastructure is not accessed. Thus there is no influence on the production systems.
Since the created (virtual) stubs can be configured individually, the virtualization service can also be used to test load scenarios by setting the response times for each individual stub. However, it should be noted that the behavior of the live system can only be determined vaguely. In this case, service virtualization is only used as an emergency solution if required services cannot be used (for example, if the Schufa environment is not accessible from the test system).
Conclusion:
Service virtualization also reduces the effort required to create available test data sets by allowing functional/process-related changes in the project to be mapped directly to a new test data record (instead of having to incorporate all changes into the existing mock).
