Release 2.2
BlazeMeter 2.2 was released on April 26, 2026.
BlazeMeter Core MCP Enhancements: Failure Criteria, AI Reporting, and Reliability
Release 2.2 significantly enhances how tests are configured, analyzed, and reported by introducing human‑readable failure criteria, AI‑assisted execution insights, and broader reliability and security hardening. The goal is to make BlazeMeter test results easier to explain, automate, and trust—especially when used by AI agents and advanced workflows.
What’s New
-
Failure Criteria
-
Structured failure‑criteria domain model with human‑friendly labels (KPIs, operators, rule fields)
-
Read‑only
failure_criteria_metacatalog to build valid rules without API calls -
Enhanced
configure_failure_criteriasupport for full rule replacement, enable/disable, thresholds, sliding windows, stop‑on‑violation, and merge guidance
-
-
Execution Reporting and AI Insights
-
ai_analysissupport on executions, with clear ready vs. processing states -
read_anomalies_statsdelivers formatted anomaly counts, labels, and execution context -
Improved
read_summarywith normalized fields and metric explanations for AI interpretation -
More consistent
read_errorsandread_request_stats, including graceful handling of archived or unavailable data -
read_all_reportsto aggregate summary, errors, and request stats in one call
-
-
Reliability, Security, and Compliance
-
Stronger validation aligned with documented tool schemas
-
Security hardening for paths, HTML rendering, traceback sanitization, token handling, and uploads
-
Updated dependencies with MCP CVE remediation and refreshed lockfile
-
Python‑multipart update and Mend (SCA) scanning added to CI
-
-
Developer & Distribution Experience
-
One‑click deeplink install support for MCP clients (VS Code, Cursor)
-
Docker image pull policy set to always pull for fresher runs
-
Project hygiene updates: license, SECURITY.md, logo refresh, Node.js 24 in GitHub Actions
-
How this benefits you
-
Clearer failure rules make test thresholds explainable without exposing raw API details
-
AI agents can interpret execution data more accurately and consistently
-
Faster troubleshooting through unified, normalized reporting
-
Improved security, stability, and trust in automated environments
For more information, see the BlazeMeter MCP GitHub repository.
BlazeMeter HTTP JMeter Plugin
The BlazeMeter HTTP Plugin introduces a unified JMeter sampler for testing HTTP/1.x, HTTP/2, and HTTP/3 (QUIC). It uses an asynchronous, non‑blocking architecture with multiplexing to support high‑concurrency load tests while optimizing CPU and memory usage. This release enables HTTP/3 load testing, which is not available in standard JMeter and many other load‑testing tools.
What’s new
-
Single sampler for HTTP/1.x, HTTP/2, and HTTP/3 (QUIC)
-
Asynchronous, non‑blocking execution model for higher concurrency
-
Improved CPU and memory efficiency for modern and legacy HTTP tests
-
Simplified configuration for advanced HTTP scenarios
How this benefits you
-
Test HTTP/3‑based applications at scale
-
Reduce infrastructure cost through more efficient resource usage
-
Generate more realistic, browser‑like web traffic
-
Adopt the latest HTTP standards without custom tooling
Taurus Cloud: fixed and removed vulnerabilities
The current version of Taurus Cloud (2.4.424-reduced) resolved several identified security vulnerabilities by applying the necessary fixes and removing affected components.
Following vulnerabilities are fixed / removed:
-
CVE-2026-24051 (high) go.opentelemetry.io/otel/sdk
-
CVE-2026-31958 (high) tornado
-
CVE-2026-33186 (critical) google.golang.org/grpc
Service Virtualization: Kafka Support
Service Virtualization now supports Apache Kafka as a messaging protocol, enabling teams to simulate Kafka-based microservices communication without a running Kafka cluster.
Supported capabilities
-
Embedded and external broker support — Choose between an embedded Kafka broker or connect to an external one. Both modes operate within a standard publish-subscribe topic model.
-
Producer simulation — Configure virtual services to simulate Kafka producers publishing messages to specified topics.
-
Consumer response simulation — Simulate consumer behavior and downstream responses to incoming topic messages.
-
Message matching and response — Define match conditions on topic messages and return configured responses automatically.
-
Event flow replay — Record and replay Kafka event flows for consistent, repeatable test scenarios.
How this benefits you
-
Shift left on testing — validate Kafka-dependent services earlier in the development cycle, before infrastructure is provisioned
-
Reduce environment dependencies — no live Kafka cluster required to run tests
-
Improve test reliability — deterministic event replay ensures consistent conditions across runs
Service Virtualization: Enhanced Transaction Sandbox mode
Sandbox Mode, introduced to allow individual transactions to be tested independently without requiring a full Virtual Service setup, has been extended with two significant enhancements. Transactions that leverage test data (datasets) rather than hardcoded values can now be validated within the Sandbox. Additionally, Processing Actions are now fully supported in the Sandbox execution context.
Supported Capabilities
-
Transactions parameterized with test data (dataset-driven request matchers and response values) can now be executed and validated in Sandbox Mode
-
Request matchers and response matchers using data parameters (e.g. ${isbn}) are resolved correctly during sandbox runs
-
Processing Actions defined on a transaction are now invoked during Sandbox execution, mirroring runtime VS behavior
-
The Sandbox now provides end-to-end transaction validation — from matcher evaluation through data resolution and action execution — without deploying to a Virtual Service.
How this benefits you
-
This completes the Sandbox feature, making it a fully capable pre-deployment validation environment for SV users.
-
Teams can now shift left more aggressively — catching issues with data-driven transactions and script logic earlier in the authoring cycle, before any Virtual Service deployment.
-
The result is a faster, less error-prone development loop and greater confidence that transactions will behave correctly in production Virtual Services.