Converting from LoadRunner to JMeter and BlazeMeter - 5 Best Practices
In the past two years, CA Technologies (acquired last year by Broadcom) has onboarded 40 products to performance testing with Apache JMeter™ and BlazeMeter, ~20 of them were migrations from HPE Performance Center/LoadRunner. As the principal engineer in charge of managing these conversions, I’m proud of how we now run more than 36,000 performance tests a year, by implementing an open-source based continuous testing methodology. After converting, our code coverage is better and our products are of higher quality.
I have learned many lessons in the past two years and I would like to share 5 of them with you. You can implement them in your transition to open-source based performance testing. Let’s get started.
1. Teach Performance Testing
Many internal CA teams don’t do performance and load testing, or they implement a narrow version of it. This version might include running a large scale soak test and waiting to see if it crashes the application or not.
Therefore, it’s of utmost importance to teach developers and testers the value of performance testing to development and to code quality. Performance and load testing ensures systems don’t crash, companies provide flawless customer service and the product can develop faster and in a more agile manner, thanks to quicker releases. When integrating testing into Continuous Integration pipelines, the whole process can be automated, making it more efficient and freeing developers from mundane tasks.
After covering the basics, dive into the details of different types of performance tests, like soak tests, spike, functional API, etc. Then, teach them the meaning of different KPIs, like throughput, response time and error rates, and how to view log files. Finally, walk them through the business case of your own product and what the SLAs are, so they can deduce the correct response time, the 95th percentile, what to measure for hits/s etc.
If your company is interested in performance testing training, you can engage with BlazeMeter’s Professional Services.
2. Train on Easy to Use Testing Tools
Many developers were struggling with testing with HP LoadRunner/Performance Center. To overcome these difficulties, it’s important to utilize easy to use testing tools. If the tool is user-friendly for the developers, they will use it and explore its possibilities. If it’s difficult to incorporate in the daily work, only a small fraction of developers/testers will use it. The others will either ignore it or use it minimally.
That’s why it’s also recommended to use open source. Open source tools are always addressing developers’ needs from them (because their developers are their users) and they have wide range support and lots of documentation, as they are being maintained by the community.
Open source JMeter is the most popular open source load testing tool, and for good reason. You can learn how to create scripts in just a few hours, and there is lots of available content and community support for any scenario. This encourages extensive usage. It’s definitely much easier than learning VuGen from HPE LoadRunner. There is also an open source alternative for HPE LoadRunner’s TruClient protocol: the very powerful and popular Selenium.
Once you need more advanced JMeter abilities, like scaling, running multiple tests in parallel, advanced reporting and APM integration, move on to BlazeMeter. BlazeMeter is even easier to use, because of its SaaS GUI. You can also use Taurus if you want to skip JMeter, but we’ll get there in a second.
If JMeter isn’t your cup of tea, let developers choose any other open source tool of their choice, like Gatling or Locust. These tools can all be integrated together and run in parallel, no problem, with Taurus and/or BlazeMeter.
Now, our teams are completely self-sufficient in testing with these tools, and thanks to the conversion we’re running much more sophisticated tests in a wider scope. In fact, moving to easier to use tools has made our developers much more professional.
3. Automatically Convert Your Performance Center LoadRunner Scripts
Teams who ran Performance Center tests in the past had to convert their tests to JMeter. We started out by using the free online script converter, which automatically converted most of the scripts and saved us a significant amount of time. The converter converts most LoadRunner functions. Then, we worked on converting the rest of the scripts with the teams.
The second part of the conversion was setting up on-premise testing. BlazeMeter enables testing from behind the firewall, either as On-premise or as Private Cloud. We spent some time setting up private harbors and private ships, with Docker images.
After setting everything up, we were no longer dependent on HPE LoadRunner/Performance Center, so testing became seamless and teams became completely self-sufficient. We’ve established our own testing best practices and have progressed immensely with our product.
4. Create JMeter Scripts with the Chrome Extension Recorder
After teaching the importance of testing, how to use the tools and converting scripts, it’s time to create new JMeter scripts. Another JMeter advantage is that there’s no need to start each script from scratch. The free Chrome Extension Recorder records the scenario you play out and lets you export it as a JMeter jmx file, or straight to BlazeMeter. The recorder provides you with a skeleton of your script, which you can then edit, fix, add complexities to and improve.
The Chrome Extension recorder is fit for both experienced and novice users. It is an important part of converting to open source because it paves the way to easier script creation and frees more time for test analysis and code writing.
5. Start with JMeter and BlazeMeter, and then Move to Taurus and Jenkins/TeamCity
Don’t rush your team into the highest level of performance testing immediately. Our teams have advanced at different speeds, from no testing or narrow testing to continuous testing every night and to automated testing.
One of the milestones on the way to continuous testing is the movement to Taurus, an open source test automation framework. Taurus runs JMeter, Gatling and many other open source tools, from a CLI. Taurus enables shifting left, by automating tests and running multiple tests from multiple tools in parallel.
Another milestone is integrating your performance tests into a Continuous Integration pipeline, with tools like Jenkins or TeamCity. Your CI tool should run all of your code tests - unit, regression, load, functional, performance end to end, etc., according to the schedule you set up. For example, after every build and as a condition before every release. Our teams have become agile by utilizing Jenkins, which invokes their environment and BlazeMeter performance tests.
We taught our teams Taurus and Jenkins after JMeter, because we wanted them to become proficient in testing before moving on to continuous testing. But Taurus can also operate as a JMeter replacement, or a tool to be used before diving in to JMeter, because Taurus mediates load testing to developers. You can write your script straight into Taurus with easy to use YAML, instead of creating scenario scripts in JMeter, Gatling, etc. These tools are run in the background, but the only skill the developer needs is YAML!
From a few, simple load tests to tens of thousands of sophisticated performance tests, the transition from MicroFocus LoadRunner/Performance Center to open-source JMeter and BlazeMeter has made CA Technologies more agile and improved our code coverage and development. The conversion process requires some initial effort, but it saves resources and makes developers and testers more proficient in a very short amount of time. Every time I look at our test coverage reports, I’m in awe of the transition we’ve made.
Convert to agile testing today. To request a demo for converting your LoadRunner scripts to JMeter or for JMeter or Taurus training, click here.