Perforce

Perforce BlazeMeter 3.3: Faster API Test Setup and Better Private-Test Governance

Perforce BlazeMeter 3.3 adds automatic application updates in Environment Manager v1.1.0, improved JDK and JMeter bundle handling, and enterprise connectivity options including configurable TLS verification and plugin mirror fallback. API Monitoring now exports request steps as safe cURL commands, imports variable values from Swagger and OpenAPI definitions, and reports variables created by post-response scripts. Radar agent 1.35 also corrects OAuth 2.0 public-client requests sent through private locations by omitting an empty client_secret parameter.

By Chris CarpenterBlazeMeterTest AutomationDevSecOps
perforce-logo.svgPerforce BlazeMeter Logo Transparent.png
Perforce BlazeMeter 3.3: Faster API Test Setup and Better Private-Test Governance cover graphic
Back to Perforce release updates
Release facts
VendorPerforce
ProductBlazeMeter
Version3.3
Published by MeritoAugust 19, 2026
Newer release covered4.1 (October 11, 2026)
Release historyBlazeMeter release history

Environment Manager v1.1.0 adds automatic application update support, giving release owners a more controlled way to keep private test infrastructure current while reducing repeated manual upkeep.

Environment Manager maintenance and enterprise connectivity

The Environment Manager update focuses on operational reliability across distributed enterprise environments. Automatic application update support, improved JDK upgrades, and updated JMeter bundles reduce the friction of maintaining test execution capacity over time.

The release also improves diagnostic and deployment confidence through:

  • Clearer build-number information for support and change records
  • More accurate warnings for outdated resources
  • Session logging with direct access to the log folder
  • Updated dependencies and improved Windows release signing
  • Native Apple Silicon support for teams using supported Mac hardware

For release governance, these changes make it easier to identify what is running, investigate a failed setup, and document the version state of test infrastructure. Update activity should still be governed through approved maintenance windows and post-update validation. The controls matter most when private test locations support critical release gates.

Corporate network conditions receive specific attention. Configurable TLS verification gives platform owners a defined control point for certificate-validation behavior, while a plugin mirror fallback can help maintain access where standard plugin retrieval is constrained by network policy. Security and network teams should document the approved TLS settings and mirror sources rather than treating these options as local workstation preferences.

API Monitoring: reproduce requests without revealing secrets

Request steps in API Monitoring can now be exported as cURL commands. The generated command reproduces the configured method, URL, headers, authentication, and request body, then opens in a pop-up for one-click copying.

This supports practical workflows such as:

  • Attaching a reproducible request to a defect record
  • Handing an API failure to application engineering
  • Comparing monitor behavior with terminal-based diagnostics
  • Capturing evidence during release-readiness reviews

Variables resolve to their values in the generated command, while secrets remain represented as {{variable}}. That distinction is important: teams can share useful diagnostic context without placing sensitive values in chat transcripts, ticket comments, or local shell histories.

The existing From cURL capability has also been corrected to follow standard curl behavior more closely. A command containing a body without an explicit method now imports as POST instead of GET, and request bodies, including JSON payloads, are parsed correctly into the editor. Less re-entry. Fewer avoidable differences between a developer's diagnostic command and the monitored request.

API definition imports retain operational context

Swagger 2.0 and OpenAPI 3.x imports now include variable values defined in JSON or YAML API specifications. BlazeMeter creates those values as populated test variables instead of requiring teams to recreate them after import.

This has a direct workflow impact for organizations that maintain API contracts as delivery artifacts. Imported tests can be closer to executable from the start, which reduces setup variance and helps teams assess a new or changed interface earlier in the delivery cycle.

The capability is also relevant when moving suites from other testing products. A team can export an existing suite to Swagger or OpenAPI, import it, and retain variable values as part of the migration process. Before broad adoption, establish standards for which values belong in specifications, which must remain externally managed, and which should be treated as secrets.

More complete evidence for scripted test behavior

Variables created through post-response scripts now appear in the test report's Variables created section. Previously, the variables were created and used correctly but were not visible beside variables created through UI-based actions.

The report now provides a more complete account of what each request produced. For QA leads and auditors, this improves traceability when scripted logic derives identifiers, tokens, or data needed by later steps. It also shortens investigation time when a monitored flow behaves differently than expected.

Teams should review script conventions as part of this change. Clear variable names, documented purposes, and restricted handling of sensitive values make the expanded reporting more useful during reviews.

Private-location OAuth 2.0 behavior is corrected

Radar agent 1.35 fixes OAuth 2.0 token requests for public clients routed through a private Radar agent. When a client secret is not configured, the agent now omits the client_secret parameter instead of sending it as an empty value.

Some authorization servers reject an empty client-secret parameter for public clients. The correction prevents that failure mode and makes private-location monitoring more representative of intended OAuth behavior. Organizations using private agents should validate affected token flows after upgrading, particularly where identity-provider policies differ across environments.

What release owners should do next

Prioritize a controlled evaluation of the changes that affect your operating model:

  • Plan Environment Manager updates with version checks and regression validation
  • Confirm TLS-verification and plugin-mirror settings with security and network owners
  • Add cURL export to API incident and defect-handoff procedures
  • Test OpenAPI and Swagger imports against approved variable-management standards
  • Review reports for script-created variables in critical API flows
  • Validate OAuth public-client requests through every relevant private location

This is a practical release for teams seeking clearer maintenance signals, lower API test setup effort, and stronger evidence around test execution behavior.

How Merito helps

Merito helps enterprises implement BlazeMeter capabilities within governed delivery workflows. We can assess private-location architecture, define Environment Manager update controls, standardize API monitoring patterns, and connect test evidence to CI/CD release decisions. The goal is not merely to enable features, but to make their ownership, security boundaries, and operational use clear.

Merito is an authorized Perforce reseller and services partner. Our Perforce BlazeMeter team can scope licensing, sizing, and rollout for 3.3, and our enterprise upgrade services help you plan and validate the upgrade with minimal disruption to release schedules.

About BlazeMeter

BlazeMeter licenses, renewals, upgrades and implementation are available through Merito, an authorized Perforce reseller and services partner.

Frequently Asked Questions