An Environment is a group of configuration settings (initial variables, locations, notifications, integrations, etc.) used when running a test. Every test has at least one environment, but you can create additional environments as needed. For common settings (base URLs, API keys) that you'd like to use across all tests within a bucket, use a Shared Environment.
Environments are great for cases when you need to re-use the same set of test steps with different configurations e.g. executing the same test against your local dev version of an API as well as the live production version.
- Example Multi-Environment Test Configuration
- Selecting and Managing Environment Settings
- Test-specific Environments
- Shared Environments
- Inheriting From Shared Environments
- Default Environment
Example Multi-Environment Test Configuration
Here's an example of environment settings for a test that re-uses steps across three different environments: your local dev environment, a staging server, and a production realm.
Selecting and Managing Environments
There are two primary places you'll interact with your environment settings: the environments switcher (top right of the test editor) and the environment settings editor (above the test steps in the test editor). The switcher determines the current environment you're working with. When you switch between environments, the values in the settings editor will be updated to reflect the currently selected environment.
The environment switcher is where you'll create and delete environments. Create an empty environment by selecting Add Environment or alternately select Duplicate to create a copy of an existing one.
Test environments belong to a single test. They can optionally inherit settings from a shared environment, overriding variables and other settings specific to the test. The following settings are included in an environment:
- Initial Variables
- Initial Scripts
- Locations and Agents
- Email and Webhook Notifications
- 3rd-party Notification and Analytics Services
- SSL Verification and Cookie Handling Behaviors
- Environment Headers and Authentication
Shared environments belong to a bucket and can be used by any test within the same bucket either on their own, or via a test-specific environment set to inherit its settings.
Inheriting From Shared Environments
When a test-specific environment is set to inherit from a shared environment, the shared environment is used as a base that the test environment builds on. Depending on the setting, you may be able to override settings in inheriting test environments:
Initial Variables and Initial Scripts
Locations and Agents
Locations and agents that have been enabled in a shared environment cannot be disabled from an inheriting test environment. Additional locations and agents can be enabled for the specific test environment.
NOTE: You can run API monitoring tests from a private location. Use the Radar agent to bridge BlazeMeter API Monitoring to private APIs not available over the public internet. Note that Radar agent is a wholly separate installation from Private Location agents, and is specific only to BlazeMeter's API monitoring function.
If email notification settings are specified in a shared environment, inheriting test environments can add to the list of team members to receive notifications, but cannot override the frequency or turn off notifications to team members specified in the shared environment.
Callback URLs specified in the shared environment will be called in addition to the callback URLs specified in the inheriting test environment.
Connected services enabled in the shared environment cannot be disabled in the inheriting test environment. You can enable additional integrations in the per-test environment.
Behaviors that have their default values changed in a shared environment cannot be toggled in the inheriting test-environment. Otherwise, they can be toggled On or Off. The default values for behaviors are:
- Retry on Failure - Off
- Stop on Failure - Off
- Validate SSL - On
Headers in the shared environment with the same name as those in a test environment will be overridden by those in the inheriting test environment.
Authentication settings in the shared environment can be overridden by test environment settings.
Every test has a default environment for backwards compatibility. Some features do not support specifying an environment. In these cases, the default is used instead. The default environment can be set by going to a test and selecting 'Settings' from the left nav.
Functions that do not currently support specifying an environment and will fallback to the default are:
- Bucket-wide Trigger URLs
- Batch Trigger URLs
- Trigger URLs with an unspecified environment (missing
- 'Run All Tests' button on the test list page
- 'Run Again' button on the test result page
- AWS CodePipeline test runs