Introduction

Welcome to the Test Data section of the BlazeMeter API reference! This section will cover the APIs used for creating, updating, and utilizing Data Models in Functional and Performance tests, as well as associating Data Models with Virtual Services.

Instead of hard-coding values such as user names, passwords, numbers, or options in your tests, it is recommended to parameterize tests and replace values by dynamic test data. You can load test data from CSV files — or let BlazeMeter generate it for each test run, according to your specific requirements.

Once a Data Entity has been defined in a workspace, you can associate it with any Functional tests, Performance tests, and Virtual Services, and provide it during test execution using APIs. The test data integration uses two APIs, the Asset Repository API and the Test Data API.

The following figure illustrates that test data is available to all components.

This API reference uses the following conventions for your convenience:

• Language bindings are available in cURL.
• You can view the code examples and JSON responses in the column on the right.

Swagger documentation: Links to the API explorer are provided in the following format:

• tdm.blazemeter.com/docs/ for the Test Data Management API
• ar.blazemeter.com/api-doc/v3/ for the Asset Repository API

To use the Swagger documentation, you must first log in to a.blazemeter.com to establish authentication. If you need an account, sign up for a free account (first and last name, and a valid email address are required). If you use cookie authentication in the browser, (for example, if you use a browser plugin to invoke the API,) you must specify a CSRF token. This step is not needed if you use API Key authentication. Currently, the "Try it out" button does not work in the Test Data Management Swagger UI.

Overview

Your Account provides access to different levels of the API:

• Workspaces: Workspaces are the highest level container within an account. Each workspace can contain multiple types of tests. Workspaces also contain resources such as Dedicated IPs, Private Locations, Application Performance Monitoring (APM) credentials, shared folders, and usage alerts. A user with access to a workspace can access any project in the workspace. Each workspace has its own ID, known as a workspaceId, which will be required for use in the APIs.
• Projects: An organizational construct containing tests and their results. Think of it as a single-dimensional tagging system with each test and the test's results associated with one (and only one) project. Each project has its own ID, known as a projectId, which will be required for use in the APIs.
• Tests: Tests are test objects configured with specific parameters and files. Think of a test as the "recipe" for a test which can be run many times. For more information about the testId, see the Performance test and Functional test API documentation.
• Masters: This is the construct that manages the runs of a test and contains the test run's results. For more information about the masterId, see the Performance test and Functional test API documentation.

The following figure illustrates the relationship between the levels.

The test data integration uses two separate APIs:

• The Asset Repository API: A CRUD API to manage assets and asset metadata. Use the Asset Repository API to store test data, to organize assets into packages, and to manage dependencies between assets.

• The Test Data API: Use the Test Data API to generate data for Data Models and for Data Models stored in the Asset Repository, to validate Data Models and Data Models in the Asset Repository, and to read or publish test data values as part of orchestration. To do that, the Test Data API sometimes references the Asset Repository API. This Test Data API also includes an introspection API to find available seed lists and generator functions.