LoadRunner is a commercial performance testing tool supplied by HP. It has a long and varied history resulting in its support of over 30 different interfaces, multiple languages for script creation and a promiscuous non-agent based model for monitoring systems.
LoadRunner is a commercial performance testing tool owned by Hewlett-Packard. LoadRunner's history began in 1994 with a small console to control X-Runner sessions running on X-Windows workstations.
LoadRunner's interface and platform evolution has followed the changes in the industry. By version 4 the LoadRunner controller was available for execution on Windows, including control of WinRunner clients and custom programmed API virtual users. The UNIX Controller continued to be available on multiple platforms though version 5 and was retired when the Windows based controller gained the ability to control UNIX/LINUX based load generators with version 6 of LoadRunner. Version 6 saw the inclusion of the analysis engine and version 8 500 points of SiteScope to handle unified monitoring. Versions numbers 10.x of LoadRunner were skipped altogether in favor of moving from 9.5x directly to version 11 of LoadRunner, announced in the summer of 2010.
LoadRunner supports a varied number of interfaces, many of which have a historical basis in how client server computing has changed over the past two decades. The current version of LoadRunner supports QuickTest Professional exclusively as a GUI Virtual user, leaving behind the support for WinRunner and XRunner. Interfaces as varied as Windows Sockets on the bottom end of the stack and RDP/Citrix at the top end are available. IN between these layers are sandwiched protocol support for databases, distributed computing models, web technologies, specific applications and language templates for times when no in-the-can support exists. With LoadRunner version 9.5 a protocol SDK became available to allow customers to build a custom integration for applications not supported in the as-shipping release of LoadRunner. 2010/2011 saw the beta deployment of a cloud based version of LoadRunner on Amazon Web Services.
LoadRunner's primary development language is 'C,' initially chosen for its light weight and availability across the variety of load generator platforms supported by the tool (UNIX & Windows). With the movement of UNIX vendors away from shipping a compiler with each copy of the UNIX operating system, Mercury moved towards the inclusion of LCC, the lightweight cross platform C compiler: More information on LCC can be found at http://www.cs.virginia.edu/~lcc-win32/ .
While C is the primary language of the tool, LoadRunner supports a number of additional languages for script creation:
- VB
- VB Script
- Java
- JavaScript
- C#
The degree to which one scripting language may be used over another is governed by the protocol or interface in use/under test.
With its wide range of protocol and language support the sweet spot for LoadRunner has been the enterprise sale, where Gartner and other analysts have recognized a dominant market position for LoadRunner in the past. LoadRunner faces market challenges from smaller commercial providers and open source tools that cover single interfaces or subsets of interfaces of LoadRunner, but not the complete suite that is currently supported. LoadRunner also benefits from a robust ecosystem of web sites and support locations, owing to its longevity and position in the market.
Cost is the most common criticism of LoadRunner, not technical capability.
The market for LoadRunner talent is a challenging one. While many resumes exist on the market the vast majority of these resumes are tied to individuals with few foundation or tool skills. The performance market over the past ten years, from 2001 to 2010, has experienced an odd economic condition: While the market is expanding and the number of suppliers has not been able to keep pace, the compensation rates have been dropping. Economists note that in a resource scarce environment the price of a resource will rise to reflect it's scarcity. This has not happened in the market for performance testing skills. Dropping rates in a resource scarce environment reflects an average value of the resource which is declining at a rate faster than the expansion of the market.
The economic contraction from 2009 onward has impacted the mobility of the mature LoadRunner practitioners in the market, resulting in a high number which are location locked and some LoadRunner positions going empty for up to a year because of a lack of local talent to fill the need. Remote work models have been increasingly used to allow for remote mature performance test personnel to fill the need for skills at distant organizations. Lead times to find qualified individuals for staff positions extend to months as solid engineers have 'gone to ground' in fixed positions to ride out the down economic cycle.
The ability to find skilled individuals to staff a performance test practice is the single largest determinant of a positive or negative return on investment for tool purchase and deployment whether that tool is commercial or open source. Unskilled individuals take five to ten times longer to deliver a given test artifact at a lower overall level of quality. This results in an introduction of risk into the last risk gate prior to the deployment of a new application.
