JMeter, from Apache, is a load and performance testing tool.
$0
LoadRunner Professional
Score 8.6 out of 10
N/A
A solution simplifies performance load testing for colocated teams. With project-based capabilities, so teams can quickly identify abnormal application behavior.
N/A
OpenText UFT One
Score 8.0 out of 10
N/A
Unified Functional Testing (UFT, formerly known as HP UFT and before that QuickTest Professional or HP QTP) is a functional and performance testing tool acquired by Micro Focus from Hewlett-Packard Enterprise, now from OpenText.
N/A
Pricing
Apache JMeter
OpenText LoadRunner Professional
OpenText UFT One
Editions & Modules
No answers on this topic
No answers on this topic
No answers on this topic
Offerings
Pricing Offerings
JMeter
LoadRunner Professional
OpenText UFT One
Free Trial
No
No
No
Free/Freemium Version
Yes
No
No
Premium Consulting/Integration Services
No
No
No
Entry-level Setup Fee
No setup fee
No setup fee
No setup fee
Additional Details
—
—
—
More Pricing Information
Community Pulse
Apache JMeter
OpenText LoadRunner Professional
OpenText UFT One
Considered Multiple Products
JMeter
Verified User
Manager
Chose Apache JMeter
More threads supported, open-source, more reliable, and easy to work with. The User interface is very elegant and simple to use, as compared to other competitors.
It is very costlier than Jmeter to manager for a multi-seat license. All company does not procure the license for costlier tools. Maintaining Load Runner scripts is difficult than JMeter scripts. You need skill resources to create and maintain the loadrunner scripts and tools. …
It has very powerful capabilities and for free!!! It's ease of use and installation and easy to get started are highlights. A lot of community support and youtube videos from JMeter developers to help you understand various functionalities within JMeter to support you. You can …
I have evaluated LOADUI (web free version) and it was a very unstable tool and I could not rely on those results completely as I was not sure how the tool was performing. It only generated the top 10 less transaction times and when Jmeter was in use, it was very effective in …
LoadRunner and Silk Test were the tools I used in the past to compare with JMeter. I thought LoadRunner had a more commercial appearance and it comes with HP support from your service provider. It also comes at a steep price. JMeter and LoadRunner have a similar learning curve …
We found BlazeMeter's service to fit great with our JMeter scripts, since they execute our JMeter scripts and provide excellent reporting tools and graphs, besides multi region and infrastructure to support different configurations of multiple concurrent users. I have used HP …
Micro Focus LoadRunner fit well into our portfolio of tools with its long track record, ability to test near any application technology we adopt and allow for a single / cohesive toolset to drive our performance testing needs.
While soasta is currently being used for cloud related applications, LR is specifically used to address the load testing on on-premise servers in our case.
Loadrunner stacks up very well against these tools. All software have certain very strong features and that is what differentiates LoadRunner from all of these. It has accurate results and data. Reports are also very well formatted. Different data can be integrated and other …
The biggest point of using HP LoadRunner is the response time numbers captured after executing the tests were more accurate when we generated the same by using tools like JMeter or NeoLoad though it involves a certain licensing cost but what [we] needed was trust and accuracy …
Most of the above tools are pretty popular in the industry. These are tools that are way cheaper compared to the industry giant LoadRunner. Yet these tools have their own limitations and drawbacks. In BlazeMeter the user load cannot be modified during the test run. JMeter and Bl…
It was faster to script in HP LoadRunner than in JMeter. The main issue is the expense involved in the cost of the virtual users in HP LoadRunner. In time, it may be more cost effective to switch to JMeter when the number of virtual users increases.
Most of the test tools are similar in nature to what they do. Every tool has its own quirks, making them necessary to understand how and what they do, before we get to start using them; which also happens to be the key to good automation testing. Considering the HP toolset, …
JMeter is well suited for Java applications where the user can script the scenario once and make changes to accommodate for as many numbers of users for load test execution. The image and selection of any files or exporting files scenario is handled well.
It is less appropriate to test Ajax applications where it is required to script click per use.
Micro Focus LoadRunner and its suite of tools, specifically VuGen works wonderfully for us for all web, http/https and web service calls. We've been able to build tests for near any scenario we need with relative ease. As long as we have crafted up requirements for our scenarios / scripts to managed scope, we've had high success working with scripting and data driving. Our main tests are web service calls - typically chained together to form a full scenario with transactions measuring the journey or a similar (measure along the way) journey through a browser. For web services we will use VuGen and browser we've shifted to Tru Client I have had little-to-no experience scripting against a thick client where a ui-driven test would be required. I know its possible but quite costly due to the need to run the actual desktop client to drive tests. We've been fortunate enough to leverage http calls to represent client traffic.
UFT is well suited if the price is not an issue, and if the requirement is about testing different technologies. If the application is based on Legacy platforms like Siebel or Mainframe, UFT fares quite well. For low cost web-based projects, there are other cheap and open source tools available. If it is about API testing or Mobile Testing, it is better to use other tools like TOSCA.
Easy of use - in generate load like HTTP requests, and processing/analyzing the responses. No coding is necessary at the basic level, just need to understand load testing and the infrastructure being tested.
Automatic management of things like cookies to help with session state support - so you don't specifically have to worry about it or handle it
Lots of testing/configuration options to suit your needs in making the right load generation (sampling requests), and analyzing the results, including any pre and post processing of the results first. Things like the Beanshell/BSF pre/post processors, response assertion, regular expression extractor, XPath extractor, CSV data set config
There is a JMeter cloud service called BlazeMeter that I think would be useful for those that need to scale up high load without provisioning their own systems. I've not personally tried it though, but I recently attended a meetup presentation that highlighted nice useful features that BlazeMeter provides. One should evaluate the service if they are considering JMeter and need to expand beyond existing hardware resources.
The simple front end will allow novice users to easily grasp the basics of automation and give them confidence to try things for themselves.
UFT can scale up and run across multiple machines from a single controller, such as ALM, enabling hundreds of tests to be executed overnight.
There is an active support community out there, both official HPE based and independent users. This means if you do encounter a problem there is always someone out there to help you.
The later versions have many add-ins to plug in to other tools within the QA world.
Expert users are able to utilise the many native functions and also build their own to get the most out of the tool and impress people as they walk past and see the magic happening on the screen.
UFT also has LeanFT bundled with it, allowing automated testing at the api level - if you can convince the developers to let you in there.
Jmeter requires many tweaks with respect to its configuration file and thread properties. users need to edit theses files themselves. There could be some interface where we can edit this fields.
Jmeter cannot handle more threads and hangs up when we increase the number of threads. This causes lot of inconvenience. In these situations, user can be notified that such change would be lead to slow performance so that user can do as required. The same appears when we try to view huge files on graph listener.
Jmeter should optimize the read and write access to output csv since it acts as overhead to the I/O performance. This affects our test results for the application which we are testing.
HP LoadRunner with new patches and releases sometimes makes no longer support older version of various protocols like Citrix, which makes the task time-consuming when using older versions of LoadRunner for some of the cases. So it should support older version as well while upgrading.
Configuring HP LoadRunner over the firewall involves lots of configuration and may be troublesome. So, there should be a script (power shell script for Windows or shell script for Linux users) to make it easy to use and with less pain.
I would like to see the RunTime Viewer of Vugen in HPLoadRunner based on the browser I selected in the run-time configuration to make it feel more realistic as a real user.
Licensing cost is very high when we need to perform a test on application for a specific group of users.
Its licensing cost is very high making it a very expensive tool. due to this many organisations are exploring options of license free tools like Selenium for automation. Though learning curve is large in case of Selenium but it is very cost effective & you an get lot of support online for Selenium.
Though the scripting time is less since its easy to create automation scripts, the execution time is relatively higher as it takes the lot of CPU & RAM.
Though UFT is quite stable but during long execution cycles we do get frequent browser crashing issues.
In terms of costing TestComplete is also one option which is not free but comes with modular pricing. You can buy what you need, when you need.
Price, Wiki and user sharing. Having access to the information provided by the developers and other open source providers is key for me. The ability to share information and get answers directly is very important to success in software testing. And the price of this product currently is amazing. Too many companies charge way too much money for products that are far behind in their value and pertinence
The purpose related to performance and load testing through Apache JMeter works fine but the usability of the tool should be improved quite a lot. If someone starts with the Jmeter fresh without prior experience, they need to put more efforts in understanding the tool. The UI is not that great which is the main reason not to give high rating on usability.
I have been using JMeter for the last year. By using this tool, you can make sure the system will work under varied loads. It helps us to simulate real time scenarios by creating required virtual users and make sure the application will work under load. Perform load, stress, and stability testing using JMeter.
Customer service is not that great. It's difficult to get hold of someone if an issue is supposed to be addressed on an urgent basis. No online chat service readily available.
HPE are quick to reply and it's possible to get through to the actual developers shuold the case warrent it. Their online system allows updates and tracking of all incedents raised.
I have used LoadRunner and Silkperformer, and so far Jmeter turns out be the easiest to use of all these. While each of them have their own ROI, Jmeter can be picked by anyone in hours and start testing within a day. While with other tools, we need to get license, install them (takes a while) and setup tests and firewalls, etc.
1. It works solid for automate SAP and S/4 Hana applications and Fiori too. 2. Teams are well versed about UFT One 3. Able to handle maintained execution results 4. Publish Automation execution results in well manner to the leadership team/stake holders 5. More help content available 6. Able to understand non technical resources about normal view.
The scripts created with traditional web/http protocol are not robust thus re-scripting is required after most every code drop. Troubleshooting and fixing the issue takes more time therefore in most cases we do re-scripting to keep it simple and save time.
In ideal world you would rather spend more time doing testing than scripting in that case mostly you could use an Ajax TruClient protocol. This type of script will only fail when an object in the application is removed or changed completely. This way of scripting will save you more time and helps you maintain the scripts with less re-work effort on a release basis. On the long run you will have a better ROI when you use Ajax TruClient protocol for scripting.
Reduces the total workload of keeping the team to test older (regression) functionality. QA testers can concentrate on ad-hoc and exploratory testing, saving time and effort across the entire project.
Has built a better infrastructure for the client applications on which we can rely on for stability and providing regression results for any new features being developed.
Led the applications a step closer to implementing agile practices and DevOps across the entire organization. Thus, providing a better turnaround time of new features to the customers and less maintenance headaches for the BAU team to address.