[New Feature GA]: Browser-Based Performance Testing  

Now Available for All Enterprise Customers

BlazeMeter’s Browser-Based Performance Testing is now generally available for all Enterprise plans as of July 20.

This powerful capability allows you to run performance tests using real browsers, with no need to write or maintain JMeter scripts. It is ideal for:

• Applications with dynamic or unpredictable UIs, such as Salesforce-style platforms
• Teams that lack access or time to maintain scripted test flows
• Quickly simulating realistic browser traffic using a UI-driven approach
• Organizations seeking a modern alternative to LoadRunner TruClient

You can define test scenarios in three ways:

• Record a flow using the BlazeMeter Chrome Extension
• Build manually using intuitive Actions and Groups
• Upload a YAML-Selenium script generated by BlazeMeter’s Shift-Left Converter or Chrome Extension

Availability and Usage:

• Feature is automatically enabled for all Enterprise accounts
• Browser-based usage is billed at 1 virtual user = 100 variable units, based on your existing plan

To get started, visit the Browser-Based Performance Testing documentation.

If you have questions, contact support-blazemeter@perforce.com.

[API Testing & Monitoring]: Delete Tests Directly from the Dashboard 

You can now delete tests without opening individual test settings. From the Dashboard, click the trash icon next to any test to remove it permanently. This also deletes the associated test history, making test management faster and more efficient. 

[API Testing & Monitoring]: Script-Based Assertions Now Counted and Displayed 

Post-response script assertions are now included in all standard validation workflows. They will:

• Appear in the total assertion count in the UI, API, and email notifications
• Be visible in the Assertions section of test result pages
• Provide a complete and accurate view of validation coverage, whether defined via UI or code

[API Testing & Monitoring]: New Bucket Creation Options For Greater Control

You now have more flexibility when creating a new Bucket. During creation, you can:

• Mark the Bucket as Private, if your role permits it
• Require the Bucket name to be unique across your workspace

These options are available as checkboxes beneath the Bucket name field, allowing more secure and consistent setup from the start.

[Service Virtualization]: Messaging Support for ActiveMQ Classic & ActiveMQ Artemis

BlazeMeter Service Virtualization now supports ActiveMQ Classic and ActiveMQ Artemis, expanding JMS-based messaging simulation to include two of the most widely used message brokers in enterprise environments.

Highlights include:

• Virtualization of both JMS producers and consumers
• Full support for Point-to-Point (Queue) and Publish-Subscribe (Topic) messaging models
• Request/Reply support for simulating synchronous flows over asynchronous systems
• Message recording from virtualized producers or consumers to auto-generate realistic Messaging Virtual Services

These capabilities enable comprehensive end-to-end testing of asynchronous systems without needing access to live infrastructure. They enhance test coverage, resiliency, and scalability.

[Service Virtualization]: Enhanced Messaging Configuration & Connection Validation

We’ve simplified Messaging Broker configuration to accelerate setup and reduce friction.

New features include:

• A Test Connection button to validate broker connectivity before launching a Virtual Service, helping catch setup issues early
• Support for dynamic name/value pairs in the Configurations tab, eliminating hardcoded values and improving environment flexibility

These updates promote reusable configurations and help teams maintain clean, scalable service definitions across test environments. 

[API Testing & Monitoring]: AI Script Assistant: Now Converts Postman Scripts

The AI Script Assistant has been enhanced to help convert Postman scripts into BlazeMeter-compatible syntax for API Monitoring.

Trained using real-world examples submitted by users, the assistant now supports most common patterns, making it easier to migrate tests and reduce manual script rewrites.

Note: Some highly custom logic may still fall outside current support, but coverage and accuracy continue to improve rapidly.

[API Testing & Monitoring]: DNS Errors Now Reported as Custom Status Code (50000)

 To improve visibility and automation, DNS errors are now exposed as a dedicated custom status code: 50000.

This code can be used in:

• Assertions
• Extractions
• Post-response scripts

This allows your tests to detect and respond to DNS issues programmatically, reducing the need for manual result inspection and increasing workflow resilience.