Hybrid performance testing using Noise Generation in LoadRunner 12.02

In Real world scenario, there will be 20-30 % of idle users(may be higher/lower for some apps) and we also include them while taking the volumetrics but those idle users majorly access the website and then remain idle or closes the session by doing nothing and we call those as NOISE.

With LoadRunner 12.0 HP has provided us the option to generate NOISE along side normal testing and we shall see the purpose of that noise and how we can build a hybrid test scenario using Noise Generation option in LoadRunner. With that we have 2 approaches to web performance testing...

1. Create relatively complex tests with transactions, complicated flows, parameterization, checkpoints etc. Such tests, of course, require a complex script and can produce large amounts of interesting data.
2. Create a heavy load on the server by having the same URL accessed simultaneously by a large number of real or virtual users utilizing the power of load testing. The test typically consists of very few lines of code, and won’t be able to produce any sophisticated data. It can only determine the response times and whether the server has crashed or not. We call this “noise generation”, not out of disrespect, but to illustrate that such a test would create a massive and not quite coherent load on the server application.

Traditionally HP LoadRunner has been providing the means for enabling the first approach, so that users can test complex business flows and perform a detailed analysis of the resulting data. However, in some cases it’s enough to execute such flows for a relatively small fraction of vusers, while the rest can just generate load on the server in order to simulate stress conditions for the more “sophisticated” vusers.

HP introduced the “Noise Generation” feature in LoadRunner for precisely this reason. It lets you implement a hybrid testing model:  run large amounts of reasonably-priced vusers, which will generate a ‘primitive’ load by accessing a single URL, and alongside them, a smaller number of ‘proper’ vusers, which will gather the ‘interesting’ data.

Here are the main characteristics of the ‘noise’ vusers:

1. They’re 10 times cheaper than the regular ones! If you purchase a license for, let’s say, 100 Web vusers, you’ll be able to run 100 regular vusers (as before), or 50 regular and 500 noise ones (which you’re getting for the price of 50 regular), or 10 regular and 900 noise – any combination, as long as the amount of full-scale vusers plus the amount of the noise vusers divided by 10 doesn’t exceed the number of purchased licenses. (Note:- With trail version HP is giving license to 50 Vusers and that means 500 noise user load by default)
2. No VuGen scripting is needed in order to build a noise vuser script. Just input the number of vusers and the URL you’d like to put under stress, and LoadRunner will take care of everything else behind the scenes.
3. A noise vuser works by simply sending an HTTP GET request to the specified URL, once per test iteration.
4. Although noise vusers can run alongside a script based on any protocol, the main goal of this feature is to support Web-based protocols, such as Web HTTP, Mobile HTTP, Flex, SAP Web etc. Nevertheless, if your application under test has a Web interface of any sort, you can apply a load to it using the Noise Generation feature, even if the main testing is being done using a different technology.

 So, how does this feature work? Very simply! As mentioned above, no recording or VuGen scripting is needed. When you’re defining your testing scenario in the Controller, just press the familiar “Add group” button, and you’ll see the new “Noise Generator” option:

Select the ‘Use a Noise Generator’ checkbox, and type the URL, which will be the target of the noise generation.  Select the Load Generator machine as usual (unless you’re working in the percentage mode), the number of vusers (remember that you can use 10 of these vusers for the same price as a regular vuser) and the group name (although you don’t have to do the latter, the Controller will auto-generate it based on the URL’s domain):

Note that the “noise_” prefix is automatically added to the noise group names, in order to distinguish them.

The ‘Details’ dialog will reflect the fact that it’s a noise group we’re talking about in the script type and the ’View Script’ button will be disabled:

Since the “noise” script is rather primitive, there’s not much you can do in the way of configuring it. However, one thing is particularly important. If you want to get meaningful data from the script execution, make sure that either the “action as a transaction” or the “step as a transaction” option (which is the same thing in this case, since the script’s main action contains exactly one step) is turned on in the Run-time settings. That way you’ll be able to obtain accurate measurements at the end of the script run:

And that’s it! You’re ready to run your hybrid Web+noise test, and the ‘noise’ groups will run just like any other. 

How to calculate Virtual User "footprint"

Originally authored by Mark Tomlinson in HP.com and i felt its very useful for everyone.

One of the most common questions we get about LoadRunner Virtual Users relates to the resources required to execute the scripts on the Load Generator.  One advantage of the maturity of LoadRunner is that we have supported so many different drivers and protocols and environments over the past 2 decades.  We've learned so much about how to give a more detailed response to really advise users on how much Load Generator resources will be required to be successful.  You might imagine that the answer isn't black & white or even close to a 1 sentence answer.  Here are some simple ideas that can help you determine how to configure your Load Generators.

For Memory: each protocol has different parts that affect how much memory is required, so there is no single answer across all virtual users - Web is different RDP, which is different from SAP Click & Script, which is different from RMI-Java.  Some vuser types have external drivers (like ICA, RDP or SAP) so the guidelines didn’t include the footprint for the external executable driver. The Click & Script vuser types really can confuse you, because these seem like new versions of old protocols...but that's not actually true - the C&S protocols are completely new architecture, but more than anything, every vuser’s memory foot print is GREATLY impacted by the following factors:

• the size of the driver library (this is fairly static)
• the # of lines of code included in the recording (varies greatly by customer)
• the # and size of parameters included in the recording (varies greatly by customer and script type)

For CPU: of course, each driver has slight differences in CPU overhead, but for the most part they are all very efficient (and - yes, we will continue to improve Click & Script to be better!!) the amount of CPU used on a LoadRunner load generator will vary by the following factors:

• iteration and pacing, which controls how “active” the vuser is (varies greatly by customer)
• stress testing scenarios usually use more CPU, as opposed to real-world testing which has slower vusers (but more of them)
• customized code or extra script processing (like string manipulation, or calculations) will chew up more CPU

For Disk: the main thing here is logging, the more customers increase the details and amount of logging the more disk will be consumed external parameter files (writing or reading from individual vuser threads) will really hammer local disk some vusers with external driver executables will have additional logging of their own, or caching of content.

For Network: the result of multiple virtual users running on single load generator is a concentration of all those vusers network traffic on single NIC the payload of network api calls varies greatly for each and every different application stress testing (e.g. fast iteration pacing, no think-times) could easily result in over-utilization of NIC bandwidth

When it comes to calculating your virtual user footprint, it's actually quite easy.  But first, let me tell you that not everyone should need to do extensive calculations of the virtual user resource utilization.  This is important *only* when you have a very high number of virtual users or a very limited number of Load Generators.  The basic approach is to run a preliminary test with just 1 script, while you measure the resource utilization on the Load Generator directly.  You are specifically interested in the mmdrv.exe process on the Load Generator, which is LoadRunner's primary multi-threaded driver.  Measuring the private bytes reserved by this process for 1, 2, 3, 4 then 5 then 10 virtual users will give you some clue as to how much memory is required by each additional virtual user added.  Simultaneously you should monitor CPU, Network and Disk just to determine if there are any excessive utilizations.

It is important to note that you should be gathering information about the performance of your script running on the Load Generator - using the same run-time settings that you will use during the full scenario run.  If you are stress testing with very little think time or delay, then you'll want to use those same settings.

Source:- http://h30499.www3.hp.com/t5/HP-LoadRunner-and-Performance/How-To-Understand-and-calculate-Virtual-User-quot-footprint-quot/ba-p/2407591#.VNPsedLF_ng

How to correlate a value with dynamic boundaries in VuGen

If you are checking this post, seems the left and right boundaries are killing your time. Lets check how to deals with those dynamic boundaries using the text flags of VuGen.


You can use one of the following flags after the text, preceded by a forward slash:
/IC to ignore the case.
/DIG to interpret the pound sign (#) as a wildcard for a single digit.
/ALNUM to interpret the caret sign (^) as a wildcard for a single US-ASCII alphanumeric character. There are three syntaxes: ALNUMIC to ignore case, ALNUMLC to match only lower case, and ALNUMUC to match only upper case.

eg: email\u003d\"notification+mkuw__3d@facebookmail.com
In the above server response if you have to capture the highlighted part(in RED), the left and right boundaries have some alphanumeric chars and if they are dynamic then you have to follow the below approach.

web_reg_save_param("account_notify",
        "LB/DIG=email\u00#d\\"",
        "RB/DIG=__#d@facebookmail.com",
        "Ord=1",
        "Search=Body",
        LAST);

and for instance lets say that "u003d" in the left boundary itself is dynamic, then below will be our approach.

web_reg_save_param("account_notify",
        "LB/ALNUMIC=email\^^^^^\\"",
        "RB/DIG=__#d@facebookmail.com",
        "Ord=1",
        "Search=Body",
        LAST);

ALNUMIC means the boundary is an alphanumeric and IC asks it to ignore the case(upper or lower)

How to calculate doc download time in LoadRunner

Lets says that we have a document in one of the pages that we record in VuGen and we have to capture the time it takes to download only that file, then Use the below steps after the step which downloads the file.
Note that the RecContentType=application/pdf for the step

web_url("BCAction.do",
        "URL={url}//BCAction.do?choice=display&ctno=1234567890",
        "Resource=1",
        "RecContentType=application/pdf",
        "Referer=",
        "Snapshot=t24.inf",
        LAST);

 time = web_get_int_property(HTTP_INFO_DOWNLOAD_TIME);        
 lr_output_message("The time in ms to download CSS PDF is: %d",time);


Some more information about Web_get_int_property
The web_get_int_property function returns specific information about the previous HTTP request.
The meaning of the return value depends on the HttpInfoType argument. HttpInfoType can be any of the following options. The first constant in each pair (HTTP_*) is for C, the second (object.HTTP_*) is for object oriented languages(Java scripts).

HTTP_INFO_RETURN_CODE or object.HTTP_INFO_RETURN_CODE
The return code in HTTP response header.

HTTP_INFO_DOWNLOAD_SIZE or object.HTTP_INFO_DOWNLOAD_SIZE
The size (in bytes) of the last download, including the header, body, and communications overhead (for example, NTLM negotiation).

HTTP_INFO_DOWNLOAD_TIME or object.HTTP_INFO_DOWNLOAD_TIME
The time in (milliseconds) of the last download.

HTTP_INFO_TOTAL_REQUEST_STAT or object.HTTP_INFO_TOTAL_REQUEST_STAT
Returns the accumulated size of all headers and bodies since the first time web_get_int_property was issued with HTTP_INFO_TOTAL_REQUEST_STAT.

HTTP_INFO_TOTAL_RESPONSE_STAT or object.HTTP_INFO_TOTAL_RESPONSE_STAT
Returns the accumulated size, including header and body, of all responses since the first time web_get_int_property was issued with HTTP_INFO_TOTAL_RESPONSE_STAT

This function is supported for all Web scripts, and for WAP scripts running in HTTP mode only. It is not supported for WAP scripts running in Wireless Session Protocol (WSP) replay mode

Using continue on error in VuGen

In the run time settings we see the option "Continue on Error" which is used when you want to continue executing the script even after encountering a failure/error.

In some cases you dont want to use Continue on Error option in Run time settings but want to use that for a specific part of the script, below steps can help you to do that.

In the below example, you want to capture a dynamic value and at that same time that dynamic value can appear intermittently. It comes for 1 iteration but not the other, so i have used "Notfound=Warning", and because script fails if value is not found I have placed lr_continue_on_error at the start and end of that step.

// Set Continue On Error
    lr_continue_on_error(1);

// Save the error message if any
    web_reg_save_param("error_message",
        "LB=Message0 >> ",
        "RB=\r\n",              
        "Search=Body",
        "IgnoreRedirections=Yes",
        "Notfound=Warning",
        LAST);

    Web_url("name",
               "..........",
               LAST);

// Turn off Continue On Error
    lr_continue_on_error(0);

How to use JavaScript in your HP LoadRunner scripts

This post was written by Boris Kozorovitzky, from the HP LoadRunner R&D team.

JavaScript is rapidly becoming the driving force behind the Internet. Any website, small or large, has some parts written with JavaScript to enhance the user experience. Browser vendors constantly improve the speed in which JavaScript is parsed and executed in their browsers. This increase in speed is now to the point that it’s become one of the key benchmarks for every browser version. When we performance test a website, a web application, or even a REST service we can be sure that JavaScript plays some role in the business process we are about to test.

HP LoadRunner uses C as the native language for scripting HTTP/HTML scripts, but it allows integration and use of JavaScript code with relative ease. To learn more about this integration, consult Using the LoadRunner JavaScript Enginechapter in the HP LoadRunner User Guide. 

If you haven't experienced HP LoadRunner, this is your opportunity to download it for yourself.

Why would we want to use JavaScript in our script?

There are four main reasons:

• JavaScript often offers a more intuitive experience which is easier to implement than in C.
• The JavaScript regular expression library simplifies the challenge of working with regular expressions.
• Numerous JavaScript libraries that assist with any coding task (e.g. string manipulation) are available.
• Client-side logic is often implemented in JavaScript. Inserting snippets of the original JavaScript code means you don’t have to translate the JavaScript client logic into C code.

This article explores the following scenario: We are testing a web server application which is used for authentication. Our goal is to receive an authentication token from the server and use the token in all future communication with the server. The authentication process is as follows:

1. Send an HTTP GET request to the “/challenge” REST API to get a challenge string.
2. Perform some calculation on that string and generate a unique password using a proprietary encryption algorithm.
3. Send a GET request to the “/token” REST API passing the password generated in step 2 as a query parameter.

(If you are unfamiliar with some of the terms in this process you should read my my previous post about Load testing of a REST API, using HP LoadRunner’s web_custom_request).

For this scenario we run a simple web server which serves static values (using Node.js). The server code is available as an attachment to this article (web_js_example_server.zip).

Getting the challenge string

Our first goal is to obtain the challenge string from the server. We type the following step into our script to make the required REST API call:

    web_custom_request("challenge",
        "URL=http://localhost:3000/challenge",
        "Method=GET",
        "RecContentType=application/json",
          LAST);

We want to capture the server response in a parameter. To this end, we add a web_reg_save_param step before our request and save the response body into a parameter named “challenge”:

    web_reg_save_param("challenge","LB=","RB=","Search=Body",LAST);

Calculating the password                                                                                               

Now that we have the challenge string we can use some JavaScript manipulations to generate the password.

First we need to enable JavaScript for our script. To do this, open the Run-Time Settings (F4) and go to Internet Protocol > Preferences > Set advanced options.  Click on Options…, and in the dialog that opens (scroll all the way down), set Enable running JavaScript code to Yes (as in the screenshot below) and then click OK on both dialogs.

Next we need to create a new JavaScript file that contains our code. Right-click the Extra Files node in the Solution Explorer and select Create new file… Name the new file calcPassword.js and press OK.

We know that the string returned by the server is a JSON object which contains an array with some strings. The last member of that array is a number which tells us the index of the string we want to extract from the array and encrypt using the proprietary algorithm. We add a new JavaScript function that extracts the value from the array:

function getPassword(stringData){
    var data = JSON.parse(stringData);
    var index = data[data.length - 1];
    var value = data[index];
}

The required value is stored in the “value” variable, and now we have to apply the encryption function. Luckily for us, the server code is written in JavaScript since it runs on Node.js and it already has a module called crypto.js which implements the proprietary cryptographic algorithm. Import the crypto.js file into the script by right-clicking the Extra Files node in theSolution Explorer and selecting the Add files to script… option. Select the file crypto.js from our server folder (you would typically ask for this file from the R&D team). Edit the file so that it contains only the function we need (this step is not mandatory and is performed for clarity, we could use the original file):

   function encrypt(data) {
    return data.toString().split("").reverse().join("");
  }

(I don’t recommend using this function as a real life encryption method as it only reverses the input string J)

Now we can update our getPassword function to call the encrypt function:

function getPassword(stringData){
    var data = JSON.parse(stringData);
    var index = data[data.length - 1];
    var value = data[index];
    return encrypt(value);}

Now we just add the web_js_run step to run our JavaScript code:

    web_js_run(
        "Code=getPassword(LR.getParam('challenge'));",
        "ResultParam=password",
        SOURCES,
        "File=crypto.js", ENDITEM,
        "File=calcPassword.js", ENDITEM,
        LAST);

The parameters are straightforward but you can always consult the product documentation if you are not sure. In this case we call the getPassword function defined in the JavaScript file. We want to pass it the parameter we got from the REST API call. We use the LR.getParam utility function (implemented in JavaScript) to pass that parameter as string to thegetPassword function. The result of the function is stored in the parameter defined by the ResultParam argument (“password” in our case). Finally we have the source files that contain our JavaScript code added as “File=…” arguments separated by the ENDITEM constant.

Obtaining the token

Our final step is obtaining the token from the server. We could just use the password parameter to create the URI, but that would be a mistake because we need to encode the URI first. We can do it easily using another web_js_run call (since JavaScript natively supports URI encoding). This time the call is quite simple:

    web_js_run(
        "Code='http:/'+'/localhost:3000/token?password=' + encodeURI(LR.getParam('password'));",
        "ResultParam=uri",
        LAST);

(Note that we split up the ‘//’ string in the ‘Code’ parameters into two separate sub-strings.  If we were to pass it in as a single string “//”, LoadRunner would report error -26312, “Using "//" line comments in argument of type 'code' is illegal/unsupported”)

Now we add the step that makes the final call with the calculated URI to the appropriate REST API:

        web_custom_request("get token",
        "URL={uri}",
        "Method=GET",
        "RecContentType=application/json"
        LAST);

The result from the server is as expected:

Action.c(25): t=1987ms: 38-byte response body for "http://localhost:3000/token?password=damhA" (RelFrameId=1, Internal ID=4)

Action.c(25):     "4f6dfbce-412f-4c6c-8bac-7d7d66a6b822"

Conclusion

Enhancing your HTTP/HTML script with JavaScript code is easy and useful. There are numerous scenarios where this capability can be employed to shorten scripting time and create a much more robust script. The HP LoadRunner User Guide is key to understanding the full potential of this feature as it includes a built in function library that links the JavaScript code to your test script’s code.

HP LoadRunner 11.5 features

                                   On June 5th 2012, HP launched HP ITPS Applications software version 11.5. This 11.5 set of releases focuses on HP Application Lifecycle Management (ALM), HP Performance Center (PC) , HP LoadRunner and HP Sprinter, as well as the new HP lab management automation feature which is supported in both HP ALM 11.5 and HP PC 11.5.(These solutions are available from June 30th, 2012.)

Virtual User Generator (VUGen): a new interface that brings insight

HP LoadRunner 11.50 introduces an innovative VUGen (Virtual User Generator) interface with redesigned IDE and Design Studio. It is now easier than ever to record, replay, and debug scripts using the new VUGen. The improvements include:

•Usability

− It has a modern and intuitive look and feel, flexible panes, and layouts.

− The improved editor is now context-sensitive, supports code completion, and provides enhanced coloring and formatting. It also supports editing features such as highlighting, intelli-type,

watchlist, copy/paste, color coding, etc.

− A true C language debugger has been added.

− The Solution Explorer makes it easier to group multiple scripts, access script items, and perform script-related operations (e.g. comparison). 

− New capabilities are added to search and replace in log and snapshots.

− Step Navigator replaces tree view for single view of the script with easy filtering and search.

− A persistent framework helps maintain a custom look and feel for the script developer.

− Context sensitive help provides needed assistance for the application element that is being used at the time, at the touch of a button (F1).

• New Correlation Studio

The new Correlation Studio hosts all correlation functionality in one place: record-based correlations, replay-based correlations, correlation rules, and correlation from snapshot. Correlations can now be found based on server responses during recording, in many cases eliminating the need to replay iteratively to find dynamic values. It also includes new APIs for locating parameters based on XPath and Regular Expressions. The new Correlation Studio interface and new APIs make scripting easier, faster, and more intuitive.

• Data format extension (DFE) for GoogleWeb Toolkit (GWT) 

The DFE feature is designed to simplify scripting of applications that exchange formatted data; by turning the formatted data into a more readable format the script can be easily correlated and parameterized. GWT DFE is the latest addition to the already supported formats of Base64, JSON, URL Encoding, XML, and Prefix-Postfix. GWT support includes:

− Formatting the GWT RPC data into readable and correlate-able content

− Adding more data (i.e. object field names)

− Enabling simple parameterization

− Solving specific correlations for GWT

• Extensibility

New in version 11.50, users can extend on the functionality of the all-new VUGen IDE itself by developing add-ins that are integrated into the user interface.

• Collaboration

Community sharing allows integration into the HP online community and helps the script developer to be more efficient and productive. Easily access forums, blogs, and Twitter, or add your own search engine to enable access directly from within the development environment.

• Recording 64-bit applications

Support for recording 64-bit applications has been added to the existing support for 64-bit operating systems. These 64-bit applications can usually be recognized when the “*32” suffix is not displayed in the Windows Task Manager for their process (replay is 32-bit based).

• IPv6 support

IPv6-based applications can be tested in addition to applications based on IPv4. Support includes IP Spoofing.  Note: internal PC/LR communication (e.g. Controller-Load Generator) is still IPv4 based.

Seven new protocols

• Mobile protocols

New protocols have been added to enable developing scripts for mobile applications. The Mobile Apps protocol (in Web bundle) is used for native applications and Mobile TruClient (RIA bundle) is used for browser-based mobile applications.

• Ajax TruClient for Internet Explorer (IE 9)

This new addition to the Ajax TruClient family expands support to Internet Explorer (IE)-based applications. Applications that work in IE standard mode can be quickly scripted utilizing the same

TruClient technology that has revolutionized scripting for Firefox Web applications.

• Enhancements on TruClient for Firefox

The modern Ajax TruClient Firefox protocol was moved to Firefox 8 providing better performance.  It now supports HTML5 and allows creating functions to easily reuse and share code. Also added were “Think Time” recording, global event handlers to support asynchronous behavior, an API for URL filtering (black and white list), an API for setting HTTP headers, and the ability for automatic transactions per step.

• Web protocol asynchronous support

Support for asynchronous behavior has been added to Web (HTTP/HTML) VUser scripts, and Web-based functions inside Flex, silverlight, and Web Services VUser scripts. This new capability enables recording of poll, long poll, and push interactions required for advanced Web applications that contain various asynchronous communication designed to keep the information current and up to date. These unique communication patterns are recognized automatically and the recorded script is updated accordingly.

• Web Services enhancements

The Web Services protocol includes new features for better security support, improved handling of WCF (Windows Communication Foundation). The Web Services protocol includes the following enhancements: improved UI for security settings including addressing versions, easier certificate selection, flexible definition of signature and encryption algorithms, the option to exclude timestamps, and support of custom extensions to WCF.

• Flex enhancements

New capabilities have been added to better support Flex environment. These new capabilities include:

− Web correlation mechanisms (rules, studio, and response-based correlation, Web correlation APIs)

− Web requests support

− Adobe Flex platform jars bundled in the product so application jars are not needed for message serialization

− RTMP FMS streaming, RTMPT and RTMPS, and GraniteDS support

• .NET4 support

With this release, .NET4 support has been added to the existing support for .NET frameworks 2-3.5.

Extensibility for greater functionality

HP LoadRunner provides best-of-breed extensibility by allowing engineers to include custom code in their scripts and increase their functionality, or use different languages such as JavaScript,Java and VBScript to write custom scripts. Customers can also leverage Microsoft Visual Studio to edit their scripts and take 

advantage of its advanced IDE. HP LoadRunner also provides APIs for integrating load testing into your build management or other automated system. New in version 11.50, users can even extend on the functionality of the all-new HP VUGen IDE itself by developing add-ins that is integrated into the user interface.

 Analysis enhancements

A set of enhancements were added in the analysis, such as:

• New RTMP (real time messaging protocol) Flex Graphics

• TruClient breakdown graphs

• Ability to apply granularity to many graphs

• Global option of absolute/relative time on graphs

Integration with Service Virtualization

HP Service Virtualization helps “virtualize” components, and hence helps remove dependencies. Integrate with HP Service Virtualization and use simulated services to facilitate load testing business

processes that contain services that are not readily available or too costly.

VUGen for HP Business Process Monitoring

For customers that leverage scripts from VUGen to HP Business Service Management (BSM), it is required to record HP Business Process Monitoring (BPM) scripts using VUGen. The following

enhancements were added on Business Process Monitoring:

• Scripts parameterization

Support script parameterization from within BSM script repository to reduce script maintenance overhead.

• Easy script upload

Multiple scripts can now be uploaded into an existing folder in the script repository using drag-and-drop functionality.

A new set of supported environments

• Microsoft Windows Server 2008 R2 SP1

• Windows 7 SP1 (32 and 64 bit)

• Internet Explorer 9

Driving the DevOps trend: HP Lab Management

A challenge that performance testing teams often face is setting up a lab to run the tests. Often times, they are dependent on other teams to set up the lab. There may be stringent process and time requirements that may not be feasible. Infrastructure may not be ready when the build is ready. And build readiness is often unpredictable. These dependencies could become a roadblock, especially when they need to run tests on short notice in an Agile world. Also, if the lab is not set up correctly, this can lead to issues.

HP Lab Management allows testing teams to provision and deploy a test lab themselves in a hybrid delivery environment (bare-metal or virtual, in-house or in the cloud), through HP Performance Center. Leveraging an out-of-the-box integration with HP Continuous Delivery Automation (CDA), users are able to define the infrastructure topology, application configuration, and associated components (middleware, databases, etc.), and then deploy with the appropriate application build as needed. This model-driven approach helps eliminate user errors in lab configuration, thereby making the testing efforts more relevant and accurate.

Testing teams can also schedule tests along with the lab deployment, so that the execution can be kicked off when a new build is ready to be tested. Because the test environment can be provisioned and torn down dynamically, and not left idle, utilization of test infrastructure can also be dramatically improved through HP Lab Management.

HP Lab Management helps bring dev, test, and ops teams closer in a DevOps trend, since the same model can be used across the application lifecycle, whether in dev, test, staging, or production.

Bridging the gap between Development and Operations

HP’s long-standing ability to bridge the gap between performance testing and production performance monitoring has further been enhanced in this release. HP Performance Center now can incorporate actual production performance profiles and data in order to better replicate application behavior when testing.  

Information regarding production usage can now be directly imported from HP Business Service Management (BSM), or from third-party solutions such as Webtrends, to HP Performance Center.

HP Performance Center gives the performance testing team insight into how an application actually is used in production and how it actually performs. This helps create better testing scenarios that reflect real production usage. Based on this insight, they are able to plan and execute performance tests that are more accurate and realistic representations of application performance.

Similarly, HP SiteScope monitoring metrics and configuration can be imported to accelerate setup in testing environment.

Source - Hp.com 
*For more information - Data sheets and white papers: hp.com/go/performancevalidation & hp.com/go/loadrunner

**For HP LoadRunner 11.50 and HP Performance Center 11.50 Tutorials (Technical videos) - http://h30499.www3.hp.com/t5/HP-LoadRunner-and-Performance/HP-LoadRunner-11-50-and-HP-Performance-Center-11-50-Tutorials/ba-p/5687253#.UFIEpbJlSrs