We’ve added new browser versions including Chrome version 87, and Firefox version 83 - these versions are set as default.
Now the account logo will be shown as a default in the thumbnail of the Executive Summary reports. To upload a logo, go to settings, click on the account name and add the logo URL:
To keep with our strong password policies, all new users will be required to choose a password with at least 1 special character.
We’ve added a new option to the Network Emulation configuration in a test, allowing you to limit the bandwidth per engine.
Due to browser image improvements introduced in previous releases, we lowered the suggested CPU and RAM requirements by halfs to 1 CPU and 1024 RAM instead of 2 and 2048.
We’ve added new browser versions including Chrome version 86, and Firefox version 81 - these versions are set as default.
Now it’s possible to filter recent test runs by project in the workspace dashboard.
Number of improvements were implemented in latest Charmander image release (v 2.7.7):
Previously, we released the default browser option for Private Locations. Now you can select the default browser version for a Public Location as well. The default version is set to be the latest BlazeGrid browser version (Currently chrome: 85, firefox: 80). When we release new browser versions in BlazeMeter, your test will automatically switch to the latest available browser version, so, you don’t need to manually update the browser version for all your tests.
Now you can view more information in your test result email subject! These include
details on the workspace, project, test name and the test result as “failed” or “passed.” In case the failure criteria was not set or a test ended with no data, your test result will be listed as “completed.”
You can then use these to create relevant rules in your inbox and make your process even more efficient.
We’ve added new browser versions including Chrome version 88, and Firefox version 80 - these versions are set as default.
Our latest addition to Mock Services is the introduction of BlazeMeter Virtual Service Environment (BlazeVSE) – the Service Virtualization/DevTest VSE is now available as a single-click on-demand provisioning option from BlazeMeter CT platform – available in form of Docker container and also ready for seamless deployment on Kubernetes.
Highlights of BlazeMeter Virtual Services Environments:
Find out more details about BlazeVSE in the recent blog article.
Up until now, the pass/fail module in the yaml script was ignored by BlazeMeter, and users had to redefine it in the Failure Criteria section in the test configuration UI. With this new feature, we are translating the majority of Taurus pass/fail capabilities into BlazeMeter's Failure Criteria, so that when a yaml script is uploaded to BlazeMeter the pass/fail module in the script will automatically appear in the test UI.
Now you can also execute a test from Taurus with cloud provisioning, and the pass/fail module will be recognized by BlazeMeter and displayed in the report.
Now you can control and define a list of multiple subscribers to receive the test results email once the test run ends. To add people, just search other users in the workspace by their name or email address.
Your test configuration is still in progress and you don’t want all subscribers to receive the email of this specific run? No worries, before the test starts, you can choose to send the test only to yourself:
Similar to the docker run command, the agent (ship) creation now provides an option to select the Kubernetes templates for roles and deployments used in the Kubernetes setup or the command to run the native Windows (non-docker) environment.
Note that the Kubernetes template will require input from the end-user to properly prepare the yaml for use.
We’ve improved the Kubernetes onboarding by providing an API that returns the service YML needed to deploy BlazeMeter’s ship on Kubernetes. Simply fill in the needed parameters and run the below command:
Curl https://a.blazemeter.com/api/v4/private-locations/<private_location_id>/ships/<ship_id>/k8s-command -X POST --user <Access_key>:<Secret>'
Example output (YML):
- name: AUTO_UPDATE
- name: CONTAINER_MANAGER_TYPE
- name: HARBOR_ID
- name: SHIP_ID
- name: AUTH_TOKEN
- name: A_ENVIRONMENT
namespace: ***USER INPUT REQUIRED***
- apiGroups: [\"\"] # \"\" indicates the core API group
resources: [\"pods\", \"services\", \"endpoints\", \"daemonsets\"]
verbs: [\"get\", \"list\", \"watch\", \"create\", \"update\", \"patch\", \"delete\", \"deletecollection\", \"createcollection\"]
We’ve reduced the size of the Taurus-cloud image from 15.8 to 6 GB and the size of the Taurus-cloud-slim from 10.3 to 4 GB.
Now you can disable or enable overrides to these thread groups with just one click. When Arrivals thread group or Ultimate thread group are being used in a script, the Load Configuration section will be grouped together under one toggle, allowing you to decide if you want the load configuration to be defined in the UI (overriding the original threat group used) or to keep the load configuration as defined in the script (using the Arrivals / Ultimate thread group used in the script).
We have switched the places of “Actual” and “Threshold” columns in the Failure Criteria tab under the report, so that the results are more readable:
Since responseTime.avg threshold 500 ms is smaller than the actual result of 717.71 ms, the test failed.
We have also added two new conditions, “<=” and “>=” to the available failure criteria conditions, and rounded all the Actual values to 2 decimal places.
Now you can get even more information about your private locations. We’ve added more data on the ships that can be displayed, and for each agent you can now see the free disk space (both in GB and in percentage) and the image versions installed on the agent. To see this additional data, hover on the Information icon (“i”) in the Description column under the Private location page.
We’ve added new browser versions including Chrome version 84, and Firefox version 78 - these versions are set as default.
If your OPL functionalities are configured to have default browser versions, you can select the default option in the browser version dropdown. The default version is set to be the latest BlazeGrid browser version (Currently chrome: 84, firefox: 78). If auto-update is disabled for OPL and the latest version is not installed on Ship yet, then tests will be executed using the latest ship browser version
For BlazeMeter account admins, we’ve added a new chart under the usage report displaying the maximum number of virtual users per day. This allows you to easily identify those days with high user activity in your BlazeMeter account. Currently, the report shows performance and functional test usage.
Now users will be automatically logged out after a configured amount of time being idle. For the definition of ‘idle’, viewing an open BlazeMeter tab, even if no action is performed, still counts as an activity. You can define the session timeout on an account level. The configuration is accessible on the “Security” (previously “API Keys”) page in the Account settings and is accessible for admins and account owners:
Once session timeout expires, the user will be logged out of BlazeMeter. In case there’s a BlazeMeter tab open when logged out, the user will get the following message, allowing him to re-login or refresh the page:
We added the information for you to see who in your workspace has modified a test.
Up until now, changing a yaml file in a performance test was a long process of downloading, deleting and editing a file before uploading it back to the test. Based on customer feature requests, we added the option to edit YML scripts directly inside the script editor. We have also added an option to duplicate YML files, allowing users to keep the original script as a backup.
We have transitioned 11 of our API Monitoring Cloud locations from AWS and 1 location from Rackspace, to their respective Google Cloud Platform (GCP) locations. They are: US Virginia, US California, US Oregon, Germany, Australia, Singapore, Hong Kong, Japan, Brazil, India, Canada, and London. The region codes for those locations continue to be the same, and users should not see any impact to their tests. For the complete list of locations and their providers, please check out our docs.
Users can now create automated GUI Functional Tests without needing to code! Just drag and drop actions into place using our new Scriptless Editor. All tests recorded in the BlazeMeter Chrome Extension can also be edited and enhanced this way.
BlazeMeter Scriptless Testing includes many other capabilities like components, loops, custom code, conditionals, and a built in debugging experience . You can read more about it here.