Service Virtualization Use Cases and Capabilities

Integrating Service Virtualization with BlazeMeter tests helps remove common testing constraints in a way that makes it easier to associate the virtual service with your tests. Virtual services in BlazeMeter also empower your ecosystem of developers and testers to collaborate and reuse assets.

Consider the following use cases:

Performance Testing with Service Virtualization

Service Virtualization helps you handle situations where a piece of your application might not be available for testing when you need it. When combined with BlazeMeter performance testing functionality, Service Virtualization can make performance testing easier and more powerful.

The following scenarios are examples where Service Virtualization is needed for performance testing:

  • You can load test the whole system, but it can be difficult to discern what might be slowing things down at the component level. You also want to test specific services in isolation to see how they perform under load.
  • You want to start performance testing early, but some services are still in development and not completely ready to be included.
  • You need to run performance tests against third party APIs but cannot do so without affecting the live service. It's possible that the third-party API provides a sandbox environment for performance testing, but using these environments can incur costs that you would rather avoid.

In each of these scenarios, the ability to virtualize the service in question removes the constraint and enables timely and fast performance testing.

Service Virtualization also supports functional testing in BlazeMeter.

Empower Developers to Test with Service Virtualization

The simplicity of Service Virtualization and its availability as an integrated part of BlazeMeter turns virtualization from what used to be either individualized in-code work at the developer level, or centrally managed COE work at the QA level, into a highly collaborative exercise that works for any organizational paradigm.

Consider the following examples of how you can collaborate across roles with Service Virtualization:

  • Developers who prefer to build their virtual services in open-source tools like Wiremock can export those definitions into BlazeMeter for broader usage.
  • Virtual services created on demand by developers and testers are available for other team members to reuse, or leverage to create similar services. As the team builds a library of Transactions for a given service, team members who need to test will increasingly find that the needed Transactions already exist, and spinning up a virtual service is as simple as selecting those Transactions.
  • A QA COE can improve, augment, and organize Transactions contributed by the whole team in a way that makes them more powerful and easier to find.

All of these scenarios ultimately empower developers to test with Service Virtualization in a more convenient and accessible manner.

Self-Defining Test Assets

Testing has historically required the creation of various assets required to complete the tests (like virtual services) in different tools without any unifying platform. Service Virtualization takes BlazeMeter in a direction where tests start to become self-defining assets.

In BlazeMeter, with Service Virtualization fully integrated, you can now associate your test with virtual service data during test creation. You can also manage virtual services as a test dependency directly in your test scripts.

The more information you can build into the test itself about what it needs to run, the more efficient and self-defining your tests become.