How to correlate a Winsock script in LoadRunner

For LoadRunner 7.51 and later, users can correlate the dynamic value for a Winsock script from VuGen's Tree View. Below is further information on how it can be accomplished.

In LoadRunner, to use the Tree View for correlation:

1. Open the script in VuGen.
2. Choose View > Tree View.
3. The Tree View will open with the following structure: 

Function call in the LoadRunner script listed on the left panel.
Snapshot of the page in the right panel which can be viewed in either Text View or Binary View
To correlate in LoadRunner:

Select the lrs_recieve function on the left panel of the Tree View. The contents of the received buffer are displayed in the right panel.
Select either Text View or Binary View. If you work in Text View, you need to clear the Read-only check box in the upper right corner.
Search for the dynamic value that you want to capture.

Highlight that value, right-click, and select Create Parameter. There are two ways to create a parameter: 

If the offset of the dynamic value is fixed, highlighting that value will set the correct values forData Range in the Create Parameter window. This creates the function lrs_save_param.
If the offset values are not fixed (when the send buffer is parameterized and the response of the server changes in length), look for fixed left and right boundaries to capture the value. Then check Extract Parameter data using boundaries and set the left and right boundaries correctly. This creates function lrs_save_search_string.

VuGen will pop-up with an option for applying the correlation to all occurrences of the value in the script.
If you select Yes, VuGen will automatically search for this value in all the lrs_send buffers and replace the values with the parameter name.
If you select No, the correlation will be applied to the current location only.

Recording Problems in LoadRunner

Here, I’m going to describe some common recording problems / issues of Load Runner and how to resolve them. Normally, these problems are faced by everyone. I would request you all that leave your comments for the problems you face and how you tackle them.

1. Firefox is not supported: Only Internet Explorer is supported for Web (Click and Script). To record browser activity on Firefox, use the Web (HTTP/HTML) protocol.
2. Application behaves differently while being recorded: If your application behaves differently during recording, than it does without recording, you should determine if the recording problem is unique to Web (Click and Script). The effect may be that a Web page will not load, part of the content is missing, a popup window does not open, and so forth. Create a new Web (HTTP/HTML) script and repeat the recording. In the event that the recording is OK in Web (HTTP/HTML), we recommend that you disable socket level recording. The problem may be the result of an event listener. Use trial and error to disable event listeners in the Web Event Configuration Recording Options, and then re-record your session as a Web (Click and Script) user. To disable an event listener:
   • Open the Recording Options. Select Tools > Recording Options and select the GUI Properties:Web Event Configuration node.
   • Click Custom Settings and expand the Web Objects node. Select an object.
   • Select Disabled from the list in the Record column for the relevant Web object. If the recording still does not work, enable the listener you previously disabled, and try disabling another one. Repeat these steps until your recording succeeds.
3. Dynamic menu navigation was not recorded: A dynamic menu is a menu that dynamically changes depending on where you select it. If the dynamic menu navigation was not recorded, record again using "high" event configuration mode. To set the configuration level to high:
   • Open the Recording Options. Select Tools > Recording Options and select the GUI Properties:Web Event Configuration node.
   • Move the slider to High.
4. Certain user actions were not recorded: Check if there is a Java applet running inside the browser. If not, record the script with the Web (HTTP/HTML) protocol.

Client certificates in Truclient

When certificates are missing in TruClient ‘s Firefox, it is common to receive the following message during replay of the scripts, after which it fails

Certificate Error "Untrusted Connection…".

In such cases, the below procedure should resolve the problem:

Verify the security certificate is present in Firefox settings. Open the stand-alone Firefox installed on your system or the one in %vugen_path%\bin\firefox\firefox.exe.

Go to Tools > Options > Advanced > Encryption. The Certificate Manager window should appear.

Use the tabs to navigate through the certificate store that you would like to view. In case there are missing certificates, they need to be imported.

Close Firefox

Go to Firefox’ profile directory. On Windows 7 machines with stand alone Firefox installed the profiles are usually located in "C:\Users\Administrator\Appdata\Roaming\Mozilla\Firefox\Profiles\.default".

Copy key3.db and cert8.db to %vugen_path%\dat\LrwebToMasterProfile folder.

Create a new script.

This should overcome the Untrusted Connection message and allow the script to continue executing.

HTTP protocol and URI fragments

I've been working to create JMeter scripts for load testing an intranet web application and usually I tend to use the JMeter recording proxy, but as I was already familiar with the application and how it works and this was just another small addition to existing scripts, I just duplicated an existing HTTP Sampler and changed the path and some parameters/headers as needed. So I used Google Chrome developer tools to see what's the path I need to send the HTTP Request to and got:

So I copied the path part of the URI: "/message/1002#1003" and put it into my JMeter script, to generate the same HTTP request:



The thing is that when running this request from JMeter, I got a HTTP 500 error. I was going mad, this made no sense, running the same request with all needed headers/cookies from Chrome worked. I looked into the server's Apache access log and noted that when sending the request from JMeter for the path "/message/1002#1003", indeed there was a record for this path with a result of 500. The surprise was when I generated the same request from Google Chrome, I saw in the Apache logs that there is a request with a 200 result, but the path is "/message/1002", without the trailing "#1003"!!

That got me starting to think, why would a browser send the trailing part after the '#', it made no sense, as the application/web server don't care which part of the results we are looking for, the result will be the same with any given values after the '#' sign. It should be with the scope of the browser/client only and never sent to the HTTP server as part of the URI.

Looking at the Spec, (http://tools.ietf.org/html/rfc3986#section-3.5 - fifth paragraph) I found the approval to what I was looking for:
Fragment identifiers have a special role in information retrieval systems as the primary form of client-side indirect referencing, allowing an author to specifically identify aspects of an existing resource that are only indirectly provided by the resource owner. As such, the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme. Although this separate handling is often perceived to be a loss of information, particularly for accurate redirection of references as resources move over time, it also serves to prevent information providers from denying reference authors the right to refer to information within a resource selectively. Indirect referencing also provides additional flexibility and extensibility to systems that use URIs, as new media types are easier to define and deploy than new schemes of identification.For conclusion - now I know that:

Google Chrome Dev tools doesn't show the real Request URL (while others like HTTP Watch do).
Apache JMeter will sometimes send the values after the '#' sign in the path (HC3.1 and Java implementations will skip it, but HC4 will send it).
The name for this '#' sign when speaking about the HTTP Protocol is "URI fragment".
In any way - during future testing, it will make no sense to include URI fragments as part of the path, as they are only handled by the client / browser and in JMeter it make no sense.

Why Apache JMeter is better than HP Load Runner?

Few months ago I had a session with a friend of mine on performance testing and discussed the future load testing projects in his organization and on-going performance issues with current deployed systems.
During this session he shared with me his plans to invest on upgrading the current HP Performance Center 9.52 (Enterprise style Load Runner) to the new HP QC-PC 11 Platform during 2012.

It was after about a year or so I was familiar with JMeter and I was really pushing him to try it instead of Load Runner, as I found it much more reliable to work with.
I was trying to convey that instead of investing on licenses he can invest on better HR, better performance engineers.

So after some comparisons we made during this session, we got to a point where any lacking capabilities of JMeter in compare to Load Runner, is something that he can work around or live with.
The bottom line of that session was that there is nothing in Load Runner that he currently can't get out of JMeter (with some customizations and Plugins and aside of other protocols than HTTP/s).

Then he raised a question I never heard before:

What can JMeter give me, which Load Runner cannot?
I was always thinking the opposite way, always trying to compare with the leading product, with the "mature" product which is Load Runner.
I never thought that JMeter can provide something better than Load Runner other than it's being Free and Open Source.

So having this question echoing my mind for few months, I just had an enlightenment:

Community and support
JMeter has a strong supporting and prosperous community, questions asked or bugs found on the product got answers and fixes in a manner of minutes or hours (even on weekends!).
Bugs I found and reported got fixed in few hours and were publicly available on the next build (which is made on a daily basis or so).
With HP support I had a terrible experience, waiting hours for first response.
So whenever I found a bug in Load Runner I knew that if I will report it, I will probably have to wait for the next content pack or minor version for a few weeks in the good case (or usually forget about it and work-around it).
Even more than this – try googling for Load Runner errors / questions / topics and you find almost nothing that really helps you.

Scripting language
JMeter is java based, mostly you don't need to code anything, you only see a (gray) swing-based application and you easily play with test items which control the load test.

Load Runner is C based and you need to learn a propriety functions to generate the desired script.
Now who develops a web application in C? it is much easier to J2EE and even .Net developers (OO languages) to extend or work with a Java based application.

Simplicity
JMeter shows you everything you need in order to control the HTTP flow of the desired scenario, this way you know exactly what you are asking for and you know what response to expect.

Load Runner is hiding a lot in order to have a cleaner script code, this driving you crazy when you need to understand why certain things are working in a different way than what you expect.
Even with the new Ajax supporting engine "TruClient" they are doing the same trick – they hide things in these script "Levels", in order to make the script look nicer and you - a mad performance engineer who doesn't understand why the script behaves as it behaves.

Stupid-prof
JMeter force it's user to understand how web applications works, what is HTTP Request, what are headers, how a browser behaves and so on.

Load Runner is for everyone, so you find yourself trying to understand what is this load test engineer is talking about because he doesn't know what he is talking about.
I saw too many times load tests being executed by people who doesn't know the difference between a cookie and a header, or what is java script and where it being executed.
Do you want someone like this being responsible for you application performance or load stability? I wouldn't.

Conclusion:

Of course JMeter has drawbacks which are fully documented on the net when comparing jmeter and load runner .My point is that you can invest your budgets on utilities and you should, but you must invest some time in comparing the free utility with the expensive one.
In this case, if you are performance testing web based applications, JMeter may be better option for you.

What is Mobile Application Load Testing?

Mobile application testing for performance testing is not the same as traditional performance testing. Mobile is a whole new game and the testing requirements for all attributes are much steeper due to the unpredictability.

The purpose of load testing is to determine whether the application can maintain the required number of users with acceptable rejoinder times. The intention of propensity testing is to standard the maximum load of simultaneous users an application can sustain before experiencing system failure while the intention of stress testing is to validate an application’s constancy and dependability over an comprehensive period of time.

On the server side: we need to understand variations in response times, streaming resource intensive packets, delays in delivery of messages, application crashes etc.
On the client side: we need to address the usual discrepancy of application behavior on various platforms and handsets, memory and CPU consumption, loading speed and battery issues.

How to Test Mobile Application?
Performance test your mobile applications for a variety of mobile: Android, iOS, Windows Phone, Blackberry, etc. It's a key point to simulate mobile network speeds of mobile standards: GPRS, EDGE, UMTS (3G), HSDPA, HSPA+ and LTE.

Select right automation testing tool for the success of mobile application testing program:
The tool should support all desired platforms
The tool should support testing for various screen types, resolutions and input mechanism
The tool should be connected to the external system to carry out end-to-end testing
Use weighted device platform matrix method to identify the most critical hardware/platform combination to test.

Check the end-to-end functional flow in all possible platforms at least once.
Conduct performance testing, UI testing and compatibility testing using actual devices.
Measure performance only in realistic conditions of wireless traffic and maximum user load.

Because mobile devices usually access the network with lower bandwidth, setting the appropriate bandwidth is essential to realistically simulate mobile traffic.

What is HP LoadRunner?

HP LoadRunner software allows you to prevent application performance problems by detecting bottlenecks before a new system or upgrade is deployed. The testing solution LoadRunner enables you to test rich Internet applications, Web 2.0 technologies, ERP and CRM applications, and legacy applications. It gives you a picture of end-to-end system performance before going live so that you can verify that new or upgraded applications meet performance requirements. And it reduces hardware and software costs by accurately predicting application scalability and capacity.
How it works?

Load Runner is divided up into 3 smaller applications:

The Virtual User Generator allows to determine what actions you would like the Vusers, or virtual users, to perform under stress within the application. You create scripts that generate a series of actions, such as logging on, navigating through the application, and exiting the program.
The Controller takes the scripts that you have made and runs them through a schedule that you set up. Tell the Controller how many Vusers to activate, when to activate them, and how to group the Vusers and keep track of them.
The Results and Analysis program gives you all the results of the load test in various forms. It allows to see summaries of data, as well as the details of the load test for pinpointing problems or bottlenecks.

LoadRunner can emulate hundreds or thousands of concurrent users to put the application through the rigors of real-life user loads, while collecting information from key infrastructure components (Web servers, database servers etc). The results can then be analysed in detail, to explore the reasons for particular behaviour.

The LoadRunner Testing Process

Planning the Test
Creating the Vuser scripts
Creating the Scenario
Running the Scenario
Analyzing Test Results
HP LoadRunner in the Cloud

In May 2010, HP announced that an on-demand version of the application performance testing software would be available via Amazon Elastic Compute Cloud. HP LoadRunner in the Cloud is offered as beta software in the U.S. and is available with pay-as-you-go pricing. The software is intended for performance testing for businesses of very big size. HP LoadRunner in the Cloud is part of a portfolio of cloud computing solutions offered by HP Software Division.