Blog
March 28, 2022
How to Use BlazeMeter Service Virtualization and Test Data
Test Data Management,
Service Virtualization
To meet the customer needs in the digital age, it is essential for companies to innovate faster and respond quickly to customer needs. Having a successful DevOps implementation helps companies achieve this elusive goal. Continuous Testing, which is the process of embedding testing as an ongoing aspect of every activity in the software delivery life cycle, is a key factor for DevOps success.
BlazeMeter provides a single shift left continuous testing platform which lets us perform functional testing, performance testing and API monitoring. Service virtualization (also referred to as mock services) and test data are important for high quality testing and to help eliminate dependencies.
Service virtualization helps simulate unavailable and constrained systems and achieve high availability to shift left and to test completely. Every test needs test data. Having a comprehensive test data ensures high quality testing with good coverage. The following diagram shows how test data and virtual services are the foundation for your testing activities.
Let’s talk about how test data and service virtualization work together. BlazeMeter provides an out of the box ability to integrate test data into virtual services. In addition, BlazeMeter also allows the test data to be synchronized across the tests and virtual services which ensures data consistency and provides a complete testing experience. Having high quality test data is essential for service virtualization to service the different testing needs. A combination of on-demand test data generation (using synthetic data) and existing test data (through CSV files and TDM integration) will help generate comprehensive test data to be used in the virtual services.
Virtual services are comprised of transactions which are combinations of request and response pairs associated with a given service. These transactions can be linked to service data entities which contain the different sources of test data as shown below.
Back to topBack to topDefining service data in service virtualization
The data parameters from these service data entities can be used to parameterize the requests and responses to use the test data and provide dynamic responses based on the incoming requests. The test data can either be generated using synthetic data generation or existing test data or a combination of both.
Since virtual services are not stateful, the test data does not get updated or changed when the services handle the requests. This can help eliminate data burnout especially while performing update operations.
Using Synthetic Data Parameters
This type of data source helps generate test data dynamically using examples such as sample US addresses or by user definition of the test data using in-built functions.
US Address – Example data definition
User definition of custom data field – radius
Once the data source has been defined, we can preview the data by clicking on data settings as shown below. Updating the value under ‘Defined Number of Rows’ would generate the desired numbers of rows of data using the seed data for the example fields chosen.
Back to top
Using Existing Data Sources
This involves loading data from CSV files that can be uploaded or from shared folders in the workspace. In addition, customers who have the Test Data Manager product from Broadcom can take advantage of the integration which lets them search for data that matches specific requirements across distributed data sources.
Loading data from CSV involves either creation of new CSV file (data table) or importing existing CSV file. Creating a new data table provides a tabular view where individual cells can be edited, and new rows / columns can be added to create the data table as shown below.
Creating and editing a new data table
Importing existing CSV file will create test data from the CSV data as shown below. There are various options to control the number of rows of test data used which are described at the link. Using these options, you can determine the number of rows of data from all applicable files that will be used, skipped or looped, respectively. For example, instead of using ‘All Rows’, if we specify the ‘Defined Number of Rows’, depending on the size of the file, it will either skip rows (if the defined number is smaller than the number of rows in the CSV file) or loop rows (if the defined number is larger than the number of rows in the CSV file).
Importing existing CSV file
Once the data source has been defined, the next step is to parameterize the request and response data that needs to be substituted as shown below. We can copy the test data parameter value names by clicking the copy button and then paste them in place of the hardcoded values in the request and response.
Parameterizing request parameters
Parameterizing response data
After the transaction is updated and service is deployed using the transactions, the request argument (zipCode) of incoming request will be used to look up the data row from the data set and the response parameters will be substituted with the row data.
Service virtualization data settings
Back to top
Sharing Test Data
There are multiple ways in which test data can be shared by users within the workspace across virtual services, GUI Functional and Performance tests which are as given below.
Using shared folders
Data entity can also be created from existing data sets (CSV files) in shared folders. The CSV files in the shared folders can be used by users across the workspace for GUI Functional, Performance Tests and Service Virtualization. In the attach CSV files from Shared Folders window, new folders / CSV files can be added or deleted as needed.
In addition to creating a new data entity, users can also load a data entity that has been saved to the workspace or import a data entity from exported file.
Back to topSaving to Workspace
Data Entity menu provides option to Save the data entity to the workspace. Once this is done, the test data can be shared by users within the workspace and can be used across performance tests, functional tests, and virtual services.
After we have created test data for a virtual service, optionally, we can save the data entities to share them with users of the Workspace. We can open a saved test data entity in any test with test data support in the same workspace.
Exporting to other workspaces
Exporting the data entity using the ‘Export to File’ option generates a zip file which can then be imported into other workspaces to add the data entity. CSV Files and files from shared folders are not included in the saved data entity.
Using the shared data
Test data shared can be used across other capabilities in Blazemeter such as performance tests and functional tests as shown below.
Loading data entities saved to the workspace
There is the option of loading Data entities shared in the workspace or the option of loading data entities exported from other workspaces. This will ensure the same test data is used across the tests and virtual services.
As shown below, when we added the virtual service to the test, it also loaded the service data which gives the option to use the same test data for the test (performance test in this case). This will ensure the data is consistent across the tests and the corresponding virtual services that support the tests.
Linking test data defined in the virtual service
In addition the above, users have the option of using the BlazeMeter integration of Test Data Manager (TDM) product to consume the tests data.
Back to top
Summary
Test data is a new and key functionality in BlazeMeter which helps users quickly provide data for use in service virtualization instead of hardcoding data. The same test data can be used across the other capabilities like performance and functional tests to ensure data consistency. This will play an important role in helping customers improve the effectiveness of their continuous testing practices and to achieve their DevOps and business goals.