BlazeMeter Reviews

Whenever I am not able to record the script with the JMeter, I use BlazeMeter extensions to record the scripts. Whenever there is a need to execute something in the cloud, my company uses BlazeMeter.

There are some advantageous features that are available in BlazeMeter. The type of HTML reports that can be downloaded from BlazeMeter can be shown to the clients so that they can be provided with a clear picture in a clean way, allowing even a layperson to be able to understand the metrics our company shows with the help of BlazeMeter.

Whenever we use BlazeMeter for the ramp-up and designing the scenarios in our company, we also use JMeter or other load testing tools, which provide some convenience in areas where the granularity can be maintained in seconds. The ramp-up and ramp-down require our company to use the granularity for a few minutes, making it an area where improvements are required to be able to use the granularity in seconds. From a performance perspective, BlazeMeter needs to be improved.

Whenever we discuss the development stage, JMeter has plug-ins and other extensions in the area of WebSockets, and it is the same case in terms of the kind of extensions provided by JMeter that are available in LoadRunner. BlazeMeter has not found the extensions for WebSockets or Java Applet. Decoding the scripts that contain the applications with Java Applet is not possible with BlazeMeter or even with JMeter, and it includes some Oracle and desktop applications, too.

I have experience with BlazeMeter.

I didn't get much opportunity to work on the tool, but as per my experience, I can say that BlazeMeter serves as an alternate tool whenever my company faces some hurdles or challenges with the JMeter and k6. To record the scripts, I use BlazeMeter as an extension. With BlazeMeter, it is very easy to identify if a request belongs to an application or not, and in the initial phase itself, we can neglect the requests that don't belong to the application. In BlazeMeter, depending upon the requests, users can select a particular domain.

Though the product is scalable, I found the tool to be a bit tricky while setting up the scenario for the stress test and during step-up and step-down kind of scenario setup.

I have experience with Grafana and JMeter.

Whenever a comparison is made between JMeter and BlazeMeter, there are a lot of differences one can observe. With JMeter, our company has to concentrate on the features as it is an open-source tool that works with Java. The configuration of the systems should have some high-end configuration, and the heap size depends upon the load our company uses. JMeter can be used in UI or GUI mode or in a non-GUI mode. If users have to go with a smoke test and the preparation of scripts, the GUI mode of JMeter can be used. For the actual execution of load testing, we have to go with JMeter's non-GUI mode. With the non-GUI mode, until the completion of the test, I could see the percentage of the error, but I couldn't see what kind of error was there in the application. In JMeter, I had to wait until the completion of the entire test. When we use the BlazeMeter cloud as a licensed tool in our company, we do have to deal with the setup of any configuration area. With BlazeMeter, whenever our company executes the load test, parallelly we can monitor what kind of errors we get, and if possible, we can have a word with the development team in parallel and we can solve all the issues so we don't need to wait until the completion of the tests as some of them may be longer than thirty minutes to an hour. In current situations, everything works in the cloud, and every request and every click gets counted in the cost. In BlazeMeter, there is no need to wait till completion of the one hour or until the end of the testing phase. BlazeMeter provides better reporting, but it takes much longer to do so, making it an area of concern where improvements are required. It is not always sufficient to only use BlazeMeter.

The product's initial setup phase was simple.

The solution can be deployed in less than five minutes.

When compared with the cost of the licenses of other tools, BlazeMeter's license price is good.

Currently, I am looking out for Java Applet and Oracle applications. I want something that will support the load testing phase for the tools that Java Applet and Oracle support.

I rate the overall tool between six and seven out of ten.

BlazeMeter is a very good tool to add users and ramp up things, making them a few of its very good features.

BlazeMeter is a very handy tool requiring drag and drop to operate., but I don't think I can generate a JMX file unless I run JMeter, which is one of my concerns when it comes to BlazeMeter. In our company, we are mostly unable to capture logs or events with BlazeMeter. We want BlazeMeter to assimilate a mobile app, especially sincere company deals in mobile apps, and we wish to conduct testing using BlazeMeter. The solution has been good so far, but JMeter is one area that has been tricky for me since I cannot generate events.

I cannot speak about a particular weakness in the tool, but it is a tricky product since those who want to use it need to depend on another tool called JMeter. JMeter is required to get the scripts and JMX file before being able to run on BlazeMeter.

In our company, an APK is generated whenever we develop mobile apps, and when I drag and drop it as a script, a JMX file should be generated, which is a feature not included in the solution. The aforementioned area where the solution lacks can be considered for improvement.

I have been using BlazeMeter for two months. I am currently an end user of the tool using BlazeMeter's trial version.

It is a stable solution. When we compare BlazeMeter with other tools in the market, I can say that the solution's overall performance has also been very good in our company.

It is a scalable solution, but our company currently uses the tool's free version, and we have not opted for its paid version. Considering the aforementioned fact, I can't comment on the solution's scalability though I have heard from one of my friends that the product's scalability is good.

Around 50 people can use the product in my company.

In my company, we haven't contacted the solution's technical support since we are still exploring the product as we are a startup company. We are conducting a trial of all the tools available to us so that we can choose the ones that suit our company at the end of the process.

The tool's implementation is done since my company deals more in mobile apps than web apps.

My company is a health app provider making our process or business completely different in the market. We want a product that is not an API to test the performance of our company's apps, so we consider BlazeMeter to be a good option.

My company is looking for options, like LoadRunner tools, that can be a better choice than BlazeMeter.

My company needs to search for better options since we feel that we will have around a million users once we launch our health app in India. I want a tool that can help me test the app's performance, especially if a million users are using it.

BlazeMeter is a tool that is easy to use.

Interface and report generation capabilities make the tool very handy for its users. The only tricky area in the solution is running BlazeMeter on JMeter, an open-source tool making it a very complex part for me.

There are different technical stacks in the market in which one needs to invest. After the testing phase, one may go for an expensive product in the market. Once there is a stable product in the market and the company can generate revenue, then it is feasible to go for the paid version, which is an option available in JMeter, so I can recommend it to others. BlazeMeter's paid version can be a bit expensive compared to JMeter.

I rate the overall product a nine out of ten.

I'm working for a telecommunications client. We are using BlazeMeter's Mock Services as a priority for performance testing, along with API monitoring. These functions are each used on different projects.

One of the projects for this client is completely based on Mock Services and, with the help of that functionality, we are able to complete end-to-end testing with all the dependent components.

There are third-company suppliers who provide components that need to be tested, but most of the time we do not get those components on time. Normally, we would wait until the development is completed and only then go for automation. But now, with the help of the Mock Services, once we get the source code, we upload it directly into the Mock Services and into the API monitoring. Once we get the tracers, we are ready to point to the actual instances and test things immediately. By the time we get to that stage, we are ready for the market. That means that even before getting the complete component, we can start working with something. There is no need to wait. As a result of the Mock Services, the time it takes us to develop API automation is minimized.

Also, we had a number of performance testing tools, but we had to integrate third-party applications for generating reports. That was a pain point for us when it came to showcasing things to stakeholders so that they could be aware of what was happening. But now, everything is available once the performance testing is completed. We can immediately see the reports, and when a test is running, I can share the execution page with anyone else, as a link. That means they can view exactly what is happening, moment by moment, regarding the response time, request time, and latency. That feature is not available in some of the other applications and possibly not in any of the other applications.

One of the areas that BlazeMeter benefits us is our test cycle times. In the past, if there was a defect with a component, we would have to wait until the issue was fixed. And even though we were not testing that particular component, because of the dependency of that component, we would have to wait until the issue was fixed. If it ended up going beyond the deadline for the release cycle, we would leave that test case for the next release.

With the help of the Mock Services, we are overcoming everything. Wherever we are facing issues, whether they will be long term or temporary, by implementing the Mock Services we can bypass the faulty components that are not needed for our particular testing. In that way, we are able to reduce our cycle times. In addition, we have some physical devices and network devices in our testing. It takes a week to create physical devices in a virtual way. Instead, with the Mock Services we are creating them in a minute, and that helps our end-to-end testing to be completed on time. The benefit of BlazeMeter's Mock Services is that it takes us through our testing early in the cycle.

In a single line of business, in a particular call flow, if we have 1,000 test cases per release, 100 to 200 of them are with the help of the Mock Services. That saves us time, money, and manpower.

And before we had BlazeMeter's API monitoring, if there were 10 components and anything was down, we would not be aware. We would not send a heartbeat every second to all of the components to check whether they were down or up. The API monitoring is a real benefit for us because we are able to schedule it for every 30 minutes or every hour, and we can keep on monitoring a component. If there is a failure, we will immediately be notified by email, even on the weekend. We can take action and report the situation to the data analyst and to the component people so that they can immediately work on fixing it.

The API monitoring is one of the most excellent tools we have come across because of the scheduling and the results. We are able to analyze how stable a component is based on that monitoring.

The most valuable features for us are the API monitoring and the Mock Services.

Another good thing is that we can upload JMX files and schedule and monitor performance testing. We are able to share results and see reports that we can't get in JMeter. In that way, the performance testing is good.

In terms of the range of test tools, when there are API calls we can do automation testing, functional testing, performance testing, and use the Mock Services to create a situation that the APIs are down. We are able to handle everything that has to do with APIs. Whatever we have to test—the functionality, the behavior—we are able to do so with the help of BlazeMeter.

One problem, while we are executing a test, is that it will take some time to download data. Let's say I'm performance testing with a high-end load configuration. It takes a minimum of three minutes or so to start the test itself. That's the bad part of the performance testing.

I don't think they can reduce that time because that's the functionality they have implemented in our BlazeMeter performance testing. But it's a pain point whenever we are running performance testing in a call or a demo, as well as in our live testing when all the business people are there.

The first time I run a given test, if it takes three minutes to download onto my server that's understandable. But every time I rerun the same test, it is downloaded again, because once the test is completed the files that were downloaded are removed. That means I have to wait for three to four minutes again.

We also had a call last week regarding secret keys. In JMX we have some Backend Listeners, such as Kibana, and there are usernames and passwords for them that we have to manually enter. When we upload the JMX file into BlazeMeter for performance testing, the usernames and passwords are viewable. Anyone who has access to BlazeMeter can download the JMX file and the usernames and passwords are visible to all those people. That's an issue with the performance testing.

Also, all the competitors have MQ protocol support, which is lacking in BlazeMeter's Mock Services. Having MQ protocol support in the Mock Services would be great for us. JDBC, the database communication, is also lacking. If we had those things, we would be completely satisfied with BlazeMeter's Mock Services. 

And for the API monitoring, we are missing a data-driven approach. If, for a single API call, we have 50 to 100 test cases, there should be no need for us to create multiple steps or to duplicate the test steps. Instead, if we had a data-driven approach available, we could directly add the test data into an Excel sheet and call it into the single test steps and achieve what we need to do. We have raised this concern to the Perforce team as well, and they said they are working on it.

I've been using BlazeMeter for two year.

It's stable. Sometimes we do face issues, but they are understandable things.

Every month or two months, something will happen in the back end. The UI will say, for example, that performance testing is down due to this or that reason, and that they are fixing it. Sometimes it affects our testing. We will be in a demo or in a call with our stakeholders where we are presenting and something will be down.

We will raise a support ticket and they will say they are analyzing it and fixing it. They won't take much time, but at that time, it's a pain point. But it happens in all tools. Because it is a cloud tool it's expected, but it's not happening very frequently, so we are happy with it.

We have weekly calls with the BlazeMeter support team, and that's a great thing. During those calls they will ask if there are any issues and whether we need something resolved. If we raise any concerns, they immediately help us during that call. If not, they will ask us to raise a ticket and they follow up on it on both sides—on the support side and with us. They will give us updates. I haven't seen any other companies do that. I have been amazed with the basic support.

We also get weekly updates on whatever the roadmap contains and the new features they are going to be implementing. If we have any doubts we address them in the call. We are using some other tools, but we haven't seen this much support from any other company. When it comes to support, Perforce is the best company I have ever come across.

Positive

We haven't had a chance to use the cloud services because of security issues related to our company. We only use the on-prem server. But the cloud services are one of the best things about BlazeMeter when comparing it with its competitors.

We have older tools, like CA DevTest, that we are still using due to dependencies on JMX, MQ, and JDBC steps that are not available with BlazeMeter. With DevTest we are able to handle a lot of the custom extensions. Instead of the Mock Services, we were using the CA DevTest Service Virtualization tool. We want to move completely to BlazeMeter but we can't because of those dependencies.

Ca DevTest is the main competitor, but it doesn't have the performance testing available. Both solutions have pluses and minuses.

DevTest is hard to use. It has too many features for Service Virtualization. If a beginner is trying to learn something in DevTest, it's hard. It might take a month or two months to get some understanding of what the DevTest tool does. BlazeMeter is very simple. Even for beginners, they give some options in the Mock Services. If you're a beginner, you can create a Mock Service and it gives you a description for each and every step. This way, beginners can easily adopt BlazeMeter.

In addition to the step-by-step demos, there is the BlazeMeter University. When we onboard people into BlazeMeter, we ask them to go through those courses. For example, if we are asking them to work on API monitoring, we have them do the course on API monitoring. Once they get the certification, we have them work on the API monitoring. With the BlazeMeter University, there is no need for us to have a separate KB on how it will work or how it will respond. Onboarding people into BlazeMeter is not a problem for us.

We were using the functional testing for APIs, but it has been disabled in our organization. I asked what was the purpose of disabling it and they said it was to make sure that everyone is using the API monitoring. Although we requested that they enable it again for our purposes, so far we haven't had much chance to explore the API functional testing.

Overall, I would rate the solution at seven out of 10 because I have sent some requirements for API monitoring and performance testing on Mock Services separately, to separate teams; things that should be introduced into BlazeMeter. Until those things are available, I am not able to use some of the components 

BlazeMeter can be used for both API and performance testing, it is a multi-facility tool.

If the solution had better support and the documentation was efficient it would do better in the market.

I used BlazeMeter within the past 12 months.

BlazeMeter is a stable solution.

We have not done a lot of scalability testing with BlazeMeter to determine the full capabilities of the solution.

Small enterprises would prefer to use BlazeMeter and those companies which have a favorable budget should choose Micro Focus LoadRunner or Tricentis NeoLoad.

There is minimal support available for BlazeMeter. You have to use the internet and try to do some searches to find solutions to your problems.

I have used many similar solutions similar to BlazeMeter, such as JMeter, which I believe BlazeMeter is a customized version of JMeter. It is difficult to compare BlazeMeter to either Micro Focus LoadRunner or Tricentis NeoLoad because it is more of an open-source solution. You do not receive the high level of support that you do with paid solutions. You have to refer to the internet to resolve issues.

The difficulty level for the installation of BlazeMeter depends on how we want to implement it. It's easy to download and install, but some companies restrict the security side of it. The paid solutions are more secure compared to these open-source solutions.

The solution is free and open source.

BlazeMeter should release frequently updated demo versions of the solution to the market. They can let the internet community test it, such as crowdsourced testing, this would be good for them in the market.

I would recommend this solution to others if they have a small budget and do not have the option to buy another solution. Otherwise, Tricentis NeoLoad and Micro Focus LoadRunner are the best.

I rate BlazeMeter a four out of ten.

The use cases of BlazeMeter encompass a wide range of scenarios, including loop load testing for API-level, web service, or web application load testing. The primary purpose is to simulate various types of loads. For instance, if the load originates from distributed load testing, opting for a dedicated cloud solution would be advisable. This allows testing applications from diverse geographic locations and handling traffic from different tiers effectively. JAMITA cloud is particularly recommended for this situation, as it efficiently manages infrastructure interfaces and resolves technical intricacies associated with infrastructure maintenance.

It simplifies the process by emphasizing the key aspects of writing, uploading, and running scripts for testing purposes.

The most valuable aspect of BlazeMeter is its user-friendly nature, ability to conduct distributed load testing and comprehensive analysis and reporting features. It particularly excels in providing a clear and organized view of load test results.

BlazeMeter has room for improvement in terms of its integration with GitLab, particularly in the context of CI/CD processes. While it has multiple integrations available, the level of integration with GitLab may need further enhancements. It is known to work well with Git and Jenkins, although the extent of compatibility with GitLab is uncertain.

I have used BlazeMeter within the last 12 months.

BlazeMeter is a highly scalable solution. The solution is SaaS and the cloud vendor controls the scalability.

I have not used the support from the vendor.

The initial setup of BlazeMeter is straightforward.

I rate BlazeMeter an eight out of ten.

Previously, to perform performance tests, we had to connect servers in the cloud, configure them to perform the test, and plot the results on a dashboard. BlazeMeter came to simplify all this work.

In terms of deployment, we are using local Linux servers (RHEL 7), and for the cloud, we are using EC2 servers with Amazon Linux. Our cloud provider is Amazon AWS.

With BlazeMeter, our main gains were in agility and efficiency in the execution of performance tests and delivery of post-test reports.

It has helped us to implement shift-left testing. It has certainly helped us to speed up the tests, and with that, we gained time to carry out tests in all development cycles.

It has the ability to build test data on-the-fly, and this on-the-fly test data meets compliance standards, which is very important for us. Real-time data helps us understand the behavior at each level of the test. So, we can define numbers that an application needs to achieve in the test to classify it as being OK or not. This data helps a lot in the real-time investigation. By looking at each level, we can identify the exact moment of degradation or “break”.

It decreased our test cycle times. I believe that we saved at least 50% of the time in preparation for the execution. Using BlazeMeter has greatly simplified our performance testing experience, especially the preparation part.

For me, the best part is that we can graphically see the test result at runtime. It helps us understand the behavior of the application during all stages of the test.

BlazeMeter is a cloud-based and open-source testing platform, which is very important for us because we can be sure that we're using a tool that follows market trends and stays up-to-date.

The Timeline Report panel has no customization options. One feature that I missed was not having a time filter, which I had in ELK. For example, there are only filter requests for a time of less than 5 seconds.

I have been using this solution for approximately 1 year.

It is very stable. We haven't seen any instability or unavailability issues so far.

It is scalable as per our needs. In our working model, the only team that uses BlazeMeter is ours. This solution is used only by our team whose mission is to bring performance tests to projects and squads.

They are very good. In the beginning, they held a workshop with our team, and whenever we ask questions, we are attended to without any problem. I would rate them a ten out of ten.

Positive

We didn't use any other solution. We performed the tests manually.

As soon as we got to know this tool, we realized how important it would be and the benefits it would bring to the company. Its main benefits have been gains in agility and efficiency. 

For the performance tests that we carry out in the company, we only use BlazeMeter. I don't know any other tools. My view of BlazeMeter is that it is a very mature tool that delivers what it has set out to deliver in an excellent way.

I was not involved in its deployment. In terms of maintenance, the only maintenance is setting up new servers for use. This configuration is usually performed by us in the Performance team.

I don't have access to the information about its cost. So, I can't say if we have seen an ROI and if we have reduced our test operating costs.

We did not review other products.

BlazeMeter brings agility and efficiency in the preparation and execution of performance tests. With this, we gain time which is used to increase the scope of tests and anticipate possible problems.

BlazeMeter didn't help bridge Agile and CoE teams because we have a specific team. So, there was no involvement of professionals who work with agile. We gained agility and efficiency, but there was no involvement of any external team.

I would rate BlazeMeter a nine out of ten.

The solution is used as a performance system. 

It has a unique programming dashboard that is very user-friendly. The auto-collision feature is also robust. 

The scanning capability needs improvement. 

I have been using BlazeMeter for a year. 

The solution is highly scalable. Five people are using the solution at present. I rate the scalability an eight out of ten. 

The initial setup is straightforward. The deployment takes few minutes time and a couple of people were involved in the process. 

Overall, I would rate the solution a seven out of ten.

I use BlazeMeter for the different samplers it provides.

The product currently doesn't allow users to run parallel thread groups, making it an area that should be considered for improvement.

I have been using BlazeMeter for two years. My company is a customer of the solution.

Right now, I don't know about the product's stability. I did not experience any downtime or performance issues with the solution.

For support, I generally use Google or other online sources.

Though I have experience with a solution from OpenText, I feel BlazeMeter is the best. The main reason my company chose BlazeMeter was because it was preferred by one of our clients.

The product's initial setup phase was straightforward.

The product's installation deployment phase

The solution can be deployed in thirty minutes.

The solution did not help save money or time, and neither did it improve security since it was mainly used in our company to deal with the network part.

I have not integrated the tool with any other solutions.

Though it is a good tool, there are certain areas where improvements are required in the product.

Compared to BlazeMeter, multiple options are available in the market for people to choose from to meet their requirements.

I rate the overall solution a seven out of ten.