IBM DevOps Test Performance helps software testing teams test earlier and more frequently by shifting testing left. IBM DevOps Test Performance validates the scalability of web and server applications, identifies the presence and cause of system performance bottlenecks and reduces load testing. Software testing teams can execute performance tests that analyze the impact of load on applications.
N/A
LoadRunner Professional
Score 8.7 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
Pricing
IBM DevOps Test Performance
OpenText LoadRunner Professional
Editions & Modules
No answers on this topic
No answers on this topic
Offerings
Pricing Offerings
IBM DevOps Test Performance
LoadRunner Professional
Free Trial
No
No
Free/Freemium Version
No
No
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
No setup fee
Additional Details
—
—
More Pricing Information
Community Pulse
IBM DevOps Test Performance
OpenText LoadRunner Professional
Features
IBM DevOps Test Performance
OpenText LoadRunner Professional
Load Testing
Comparison of Load Testing features of Product A and Product B
Go for IBM RPT if: 1. You're testing a Java-based Web application with HTTP protocol 2. You wanted to distribute the load across machines easily 3. Your team is in learning phase/not really introduced to a wide range of performance testing tools Do not go for IBM RPT if: 1. You wanted to test REST or any other advanced protocols 2. Your system under test demands a very high user load 3. Your application is written in .NET or any other platform except Java.
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.
Memory utilization could have been improved.(Eats up system's RAM)! It may crash if a test is conducted with the heavy load if adequate RAM is not available in the VM/host machine.
Licensing could have been made simpler. IBM's licensing method is difficult to follow.
Support for protocols other than HTTP. Not really up to the current trend.
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.
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.
Cost/Licensing: While JMeter is an opensource testing tool from Apache, compared to IBM RPT and HP LoadRunner, RPT is much cheaper than Loadrunner. Functionality:JMeter provides basic functionalities which are adequate for performance testing, however advanced features are not available (such as load testing with GUI, reporting is very basic etc.). But when it comes to Loadrunner, it offers very broad features and supports a variety of protocols. So in this category, Loadrunner is a winner, but RPT is better than JMeter. Ease of operating:JMeter is easy compared to LoadRunner, but it has old GUI and look and feel is not that great to understand. Also, most of the things are to be done in a command line, non-GUI mode. While LoadRunner is very advanced with many options, which also confusing sometimes. But RPT, on the other hand, maintains a balance between simplicity and offering of different features. So winner: RPT.
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.