Using proxy recording for local AUTs in LoadRunner 12.00

(This post was written by Gal Shadeck, from the LoadRunner R&D Team)

 

LoadRunner 11.52 introduced a new feature called Proxy Recording – a way to record remote applications under test. This includes applications installed on mobile devices, or computers without the VuGen installed. Many users have successfully adopted this feature and given us positive feedback, so we decided to go one step further and offer proxy recording for local Web applications in LoadRunner 12.00. Of course, recording applications that run on the same machine as VuGen has been possible since the very beginning of LoadRunner’s history, but unfortunately traditional Web recording techniques caused difficulties for some customers. You can find out how we improved this situation in the recent blog post "5 tips to solve the most common problems seen in Web recording". So adding Proxy Recording as an alternative recording mechanism should be beneficial for our customers and save a lot of time spent with needless troubleshooting.

 

So, how does it work? The process is very simple. All you need to do is create a new Web HTTP/HTML script, go to the Recording Options dialog, navigate to the HTTP Properties -> Advanced tab and check the “Use the LoadRunner Proxy to record a local application” option:

 

p1.png

 

(Some of you will notice that this setting replaces the one that said “record using earlier recording engine”; as of LoadRunner 12.00, we have discontinued the support of the “old recording engine”, which was also proxy-based and aimed to achieve the same goals as the new Local Proxy Recording feature. We found that it was clunky and full of limitations, and so had limited application.)

 

After that, you can start a recording in the usual fashion. Unlike the “remote proxy recording” scenario, there’s no need to select a special “proxy” option in the “Start Recording” dialog. If you’re going to record from Internet Explorer, (or another application that uses default Windows proxy settings) then there’s no need to configure any proxy settings within the application under test. In this situation they will be automatically configured to point to the local machine at the start of the recording and restored to their original values at its end. Just record the way you’re used to, and the proxy mechanism will be invoked transparently behind the scenes:

 

p2.png

 

Still, even though we’ve made an effort to make this feature transparent to the end-user, introducing an additional proxy server complicates the process a little bit, and so some additional tweaking may be required. Here’re some tips:

 

1) Problem: When trying to record Firefox or Chrome, nothing is being recorded.


Solution: When recording any application that defines its own proxy settings (different from the Windows/IE ones), they need to be manually configured to use the system settings or point to the local machine:
p3.png

 

or:

 

p4.png

 

By default we’re using port #8888, but there’s a small chance that it’ll be occupied by another application. In order to make absolutely sure which port is used for proxy recording, start a recording using IE and look at its proxy settings.

 

Note that in such cases, you’ll need to restore the original application proxy settings after the recording is completed.

 

2) Problem: A firewall may block VuGen proxy from listening on an intranet address


Solution: Add a corresponding rule/exception to the firewall configuration. Here’s an example for the McAfee firewall (note the auxiliary process HP.LR.ProxyRecorder.exe):

p5.png

 

3) Problem: The browser denies the certificate that we’re using for decrypting the SSL traffic

p6.png

Solution: Either ignore the warning (every browser gives you that option), or import the root certificate of VuGen proxy and add it to trusted list. In order to do the latter, you’ll need to navigate to http://127.0.0.1:{proxy_port}/proxyroot.cer (Obtaining the correct port number is described above), download the certificate and import it, again using the Internet Options dialog:

 

p7.png

 

4) Problem: The recording process was interrupted in the middle (e.g. the application under test crashed), and now it’s impossible to surf the Web on the test machine

 

Solution: The proxy settings were configured to point to the local machine, but had not been restored to their original values. So, they need to be restored manually.

 

 

Note that the operations described in cases 2 and 3 only need to be performed once per machine.

 

We hope you’ll find this feature useful. Feel free to leave us a comment in the box below. You can also learn more about HP LoadRunner at the product homepage here.

 

By the way, this is not the only proxy-related addition in LoadRunner 12.00. We also added support for creating scripts from Fiddler capture files, but that’ll be a subject of another post. Stay tuned!

 

Download the latest version of HP LoadRunner here.

 

Thanks to Gal for providing this article!

 

 

 

Labels: HP LoadRunner
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author
Malcolm is a functional architect, focusing on best practices and methodologies across the software development lifecycle.


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation