Start Testing Now BlazeMeter University Submit a Support Request My Support Tickets

Importing and Exporting Tests

Avatar
BlazeMeter Support
  • Updated

API Monitoring & Testing: Importing and Exporting Tests

You can export tests to our API Monitoring Export Format, and import request definitions from other services to create API Monitoring tests.

Exporting API Tests

The API Monitoring Export Format is a JSON representation of your API Test's steps.

You can export all the tests in a bucket. Open a bucket's dashboard and click Export Now at the bottom of the page.

bucket-dashboard-export-tests.jpg

Or, you can export individual tests. Open a test and select the Export option on the left-hand side menu.

test-overview-export-test.jpg

You can import the downloaded file into any team's bucket to create a new test with the same step information. To learn more about the structure of exported tests, visit our API Test Detail specification.

Importing API Tests

The following import formats are supported:

API Monitoring Export Format

You can import API Monitoring test steps that have been previously exported to our API Monitoring Export Format. Importing and exporting API tests is useful for sharing tests between teams or accounts. Imported tests must have at least one test step, and fewer than 100 steps.

SmartBear Ready! API / SoapUI

From within Ready! API (under Projects), export your test suite as a Swagger 2.0 JSON file (right click on suite, Export Swagger) and use the BlazeMeter API Monitoring Swagger importer to create tests from the export.

Swagger 2.0 API Definitions (JSON, YAML)

You can import or specify a URL for a Swagger 2.0 API definition in JSON or YAML format into a BlazeMeter API Monitoring test. Each definition parses out to one test, and each Operation Object corresponds to one test request step. JSON pointers are supported, but multi-file uploads are not.

You have the option to import all the paths in the JSON or YAML into a single test, and for BlazeMeter to add an Accept request HTTP header based on the content type of the response.

Because the Swagger specification describes what types of values may appear in a request, but doesn't necessarily specify actual values, we make heavy use of placeholders in the form of variables. When you first import a test, you'll have to give values to these variables.

Host

The top-level Swagger host field is extracted and set to a variable {{host}}. It acts the base url for every request in a test. If no host field is present, we default {{host}} to yourapihere.com but you can change it after the import is completed.

basePath

If a basePath is present on the Swagger object, it is prepended to all request paths. For example, an API with host yourapihere.com, a basePath /v2, and a path /resource would get assembled to yourapihere.com/v2/resource.

Parameters

Parameters on the Swagger Object are parsed based on the type of parameter. Both parameters at the Paths Object level, and at the Operation Object level are honored, with any Operation-level parameter overwriting a Paths-level parameter of the same name. For all parameters, we make use of the name and in fields. Form parameters use additional information from their Operation Object's consumes field.

  • Query Parameters

    For each query parameter object, we extract the name field and use it as a query parameter field name. The value of the query parameter is set to an uninitialized variable of the same name. For instance, a query parameter named "id" would get appended onto a query string: as ?id={{id}}. It is up to you to set the value of the variable to a real ID to use in a request step.

  • Header Parameters

    Header parameters are parsed out of the header parameter object in the same way as query parameters; however, the value of the name field, and corresponding uninitialized variable are set as the header name and value in a test request step.

  • Path Parameters

    Path parameters are replaced by uninitialized variables. A Swagger path with a parameter like /user/{id} is imported as /user/{{id}}.

  • Form Parameters

    Form Parameters are parsed same way as Query parameters, with the exception that if multipart/form-data is the only content-type listed in the Operation Object's consume field, we skip parsing the form parameters.

  • Body Parameters

    When a body parameter is present, an uninitialized variable set to the parameter object's name appears as the raw body. We do not currently support parsing of a body's Schema object.

Security Requirement Object

If a Security Requirement Object is present on an Operation Object, we first determine if there's an entry of type APIAuth. If there is, we parse the corresponding object the same way we would a query parameter object, if the in field is "query," or a header parameter object, if the in field is "header." If there is no APIAuth type object, and there's an object of type "basic," we set basic auth in the test request step as follows: username gets a value of {{username}}, and password gets the value {{password}}.

Tip: If you would like to test and monitor any API that implements OAuth 2.0, refer to this knowledgebase.

OpenAPI Specification 3.x (JSON, YAML)

You can import or specify a URL for an OpenAPI Specification 3.x in JSON or YAML format into a BlazeMeter API Monitoring test.

The following options are available:

  • You can import all the paths in your Swagger file into a single test. If unchecked, an file with multiple paths will be imported as multiple tests.

  • You can let BlazeMeter add an Accept request HTTP header based on the content type of the response

Postman

We currently allow imports of Postman dump files--which, in their data, include all collections, environments, globals, and header presets--as well as imports of individual Postman collections v1. Header presets, environments (except for global variables), and scripts are not supported and will be ignored. Learn more about Postman data formats.

Postman Dump Files

Each collection is turned into an API test, and any globals are turned into initial variables in each test.

Postman Collections v1

Importing an individual collection will create a single test. Variable values are not included because they are not present in the collection file.

HTTP Archive Files (HAR)

Currently, the only HAR field we support is entries, which represent HTTP requests. Pages, comment, browser, creator are ignored.

You can generate a HAR file from Fiddler and Charles Proxy from their Export menus.

VCR Cassettes

VCR versions 1 and 2 are supported, and we accept import formats in YAML or JSON. Currently not supported are the body-encoding field, and the http version fields on the response object.

Paw

Install the BlazeMeter API Monitoring (Runscope) API Test generator extension in Paw and upload the generated file using the API Monitoring Export Format.

Have more questions? Submit a request

0 Comments

Article is closed for comments.