Glossary

This section covers the various terms that are used throughout the APIs.

Account ID

This is the unique identifier of your account.

You find it by looking at your BlazeMeter URL, using the following pattern:

https://a.blazemeter.com/app/#/accounts/123456/workspaces/54321/dashboard

The number that comes after /accounts/ in the example above is the Account ID.

It can also be found in the response of these Test Data APIs:

Asset Dependencies

An example of an Asset dependency is that a Virtual Service uses test data from a specific Data Entity. Assets within the Asset Repository of one workspace can depend on each other; the dependency has a type and can be within one Asset Package, or inter-package.

Asset Package

Assets within the same workspace can be organized in Asset Packages. For example, a package can contain all the assets describing one application or one service. Packages are versioned.

Asset Repository

The Asset Repository stores all shared Assets for a workspace. An Asset is a test data entity, such as a CSV file.

An Asset is comprised of the following parts:

  • Type – There are multiple types of assets, for example, data-mode, mock-svc, publish-configuration, data-model file.
  • Metadata – These key-value pairs are used for filtering and other purposes.
  • Data – The data stored in the asset can be a JSON document or binary file.

An Asset Repository's scope is that of a BlazeMeter workspace. This means you cannot search assets and packages across workspaces, nor can you create dependencies between assets from different workspaces.

Data Model ID

The Data Model ID is the unique identifier of a Data Model for test data generation. It is used in the following APIs:

It is found in the response of the following APIs:

Project ID

This is the unique identifier that identifies a given project in the URL. For more information about how to find this value, see Get the Project ID.

Test Data Model

To manage test data for a service or a web application, you create a data model for it. A data model consists of one or more Data Entities. Data Entities can be in relationships with one another (currently only a 1-to-1 relationship is supported). The Data Model is a JSON document based on a JSON schema.

Test Data Entity

A Data Entity is a set of data parameters that you typically use together in a test run, such as username and password pairs of tester accounts. A Data Entity contains a type declaration for each parameter, and the so-called Data Requirements for the parameter. Data Parameters can reference each other, and they can also reference parameters from another entity in the same data model.

Test Data Requirements

A Data Requirement is an ECMAScript expression (specifically, ES6 with some syntax extensions) which defines the test data that is supposed to be in an instance of the property.

The requirements section is BlazeMeter's custom extension of the JSON Schema. In this section, you define requirements for the values of each property. The requirements are expressions using ECMAScript 6 syntax, such as “randInt(x,y) + 10” or "$name".

Requirements commonly rely on BlazeMeter data generator functions, such as randText(5,10). For more information about supported functions and their arguments, see Get List of Data Generator Functions, Get List of Seedlists, and Get List of CardIssuers.

The following example shows a Data Requirement that generates values for the three data parameters, name, email, and age, and initializes them using function calls and string concatenations.

Test Data Requirements

{ "data":{  
    "type":"datamodel", 
        "attributes":{ 
            "id":"datamodel/Accounts", 
            "title":"User Account Data", 
            "description":"user account data includes name, age, and email", 
            "type":"object", 
            "kind":"tdm", 
            "repeat":1, 
            "properties":{ 
                "name":{ "type":"string"}, 
                "age":{"type":"integer"}, 
                "email":{"type":"string"} 
            }, 
            "requirements":{ 
                "name":"randText(5, 10)", 
                "email":"$name + '@acme.com'", 
                "age":"randRange(18,99)"
            } 
        } 
    }
}

The properties section is where you declare data properties and their types. The syntax is based on the property type section of the JSON Schema specification.

The following examples declare three data parameters, name, email, and age as strings and integer, respectively:

Test Data Requirements: Properties

"properties":{ 
    "name":{"type":"string"}, 
    "age":{"type":"integer"}, 
    "email":{"type":"string"} 
}

In the requirements, you can also use standard JavaScript expressions such as yield, await, new, delete, typeof, void, instanceof, in, arrow functions, spread, shift; variables; and operators, such as the plus operator in $name + '@acme.com' for string concatenation. Valid number literals are limited to decimal literals; hex, octal and binary literals are not supported.

Test Data Requirements: Requirements

"requirements":{ 
    "name":"randText(5,10)", 
    "email":"$name + '@acme.com'" 
    "age":"randRange(18,99)"
}

Test Data Model Inheritance

A Data Model can extend one or more other models and override their parameters within a test with local values.

Entity Data Source

Some Data Requirements in an Entity may need to read data from sources such as CSV files.

Entity Data Target

An Entity Data Target describes which actions to perform with test data during a Data Model Publish to a test environment. The action can be to publish a Virtual Service, to generate a CSV file, to read data to initialize values, to publish data to an API endpoint, to delete data from the test environment, and more.

Test Data Model Publish

Before a test is executed, BlazeMeter can generate the requested test data and publish Entity Data Targets to your test environments. This helps ensure that test data required in the test environment is in a consistent state.

Workspace ID

This is the unique identifier that identifies a workspace. It is used in the URL and in the following APIs:

It is found in the response of the following APIs:

Master ID

This is the unique identifier that identifies a test run.