Reuse your functional tests for load testing with UFT and LoadRunner integration

ictb_LoadRunner_Suit_48x48.pngUFTIcon.pngWe all know that you can use HP Unified Functional Testing (UFT) to create complex tests that examine the full spectrum of your application's functionality and API. But what is the next step? How can you make the most of your results? 


After creating a test in UFT, you can add it to the list of scripts in HP LoadRunner’s Controller, just like  you would with any script created with VuGen, LoadRunner's script generation tool. You can then assign virtual users to it and execute it in a load testing scenario.


LoadRunner can integrate UFT into a load testing scenario in the form of GUI or API Vuser scripts. These scripts, after having been designed and debugged in UFT, can be used as the basis of your load test.


You can use GUI and API scripts in LoadRunner to:

  • Check how your application's functionality is affected by heavy load
  • Measure the response time that a typical user experiences while the application is under load (end-to-end response time)
  • Load test a business process that could not be scripted using VuGen, but can be scripted using UFT

There is a special advantage of using a GUI Vuser script as part of your LoadRunner scenario—the GUI Vuser script runs on your screen during the scenario. This allows you to watch the actual steps executed by the Vuser in real time.


When UFT and LR are installed on the same machine, you can create tests that are initially compatible with LoadRunner, or you can convert existing UFT tests to LoadRunner compatible tests. It’s very easy:

  • To convert an existing API test to a LR compatible script, click the Enable for Load Testing button on the UFT toolbar
  • To prepare an existing GUI test for LoadRunner, include StartTransaction and EndTransaction statements in your actions and make sure that there are no references to external actions or resources

Now that we’ve piqued your interest in functional testing, check out our other posts on the Future of Testing blog to see our other insights on the topic.

neeman | ‎04-24-2013 12:08 AM

Hi Malcolm,


Great post!

Thorough and to the point



| ‎04-24-2013 11:05 AM

I balk at the idea of using GUI scripts for load tests.  It means that for each VUser you would need a seperate system (ie: load generator).  This quickly becomes impractical and cost-prohibative for most load tests over a dozen users simultaneously, let alone the several hundred VUsers that are typically needed for anyone who gets a cost benefit from load testing (ie: mid-large companies). 


Unless you've got some way of converting a GUI script to a HTTP-layer script, or a way to generate hundreds of low cost VMs for GUI replication, this probably won't gain traction with anyone running load tests.


The idea does sound good, though, until you think through the implementation.

| ‎04-24-2013 10:29 PM

Hi Plymouth, thanks for the comment.  


I agree that since you can only run one GUI script per load generator, it's impractical and not cost-effective to undertake large-scale load testing using GUI scripts.  But I think that it does have its place if, for example, you want to measure the end-user experience when a small number of virtual users are running.

NaveenKumar N(anon) | ‎04-27-2013 07:27 AM

Awesome news from HP. Always HP rocks.

Thank you,

NaveenKumar Namachivayam

James Pulley(anon) | ‎04-28-2013 02:12 PM

There is nothing new here.   GUI Virtual Users have been a part of the Loadrunner definition for as long as the product has been in existence, first with XRunner, then XRunner/WinRunner, then WinRunner/QTP and now QTP.

It would be considered poor practice to leverage GUI Virtual users for 100% of the load.  Also, when properly set as part of a functional testing framework the base scripts used for functional testing would be overly heavy, not properly formed/Structured for performance testing purposes.

Can you directly reuse a functional testing script?  Yes.  Can you Drive a ride-on lawnmower across the country?  Yes.   Although I would recommend an alternate path for efficiency purposes.

| ‎05-05-2013 11:51 AM

Quite interesting article...! Thanks!


Can some examples and demo be included....


It may not be as easy as it appears to be....

| ‎05-06-2013 12:17 AM

Thanks, aadithyaks.  The technical procedure for converting a functional test to a load test is pretty simple, as described in the blog.  However, as James Pulley and Plymouth point out, the capability is there if and when you need it, but you wouldn't want to base your load testing strategy exclusively around it.


Do any readers have an example to share?

cchallender(anon) | ‎04-24-2014 12:25 PM

Great article. The author is very knowledgable in this technology space. Recently, I heard him speak at a conference and HP is doing some very innovative work in the functional and performance testing suites.

| ‎04-24-2014 12:32 PM

Thanks, cchallender!  You might be interested in checking out my post describing what I learned at the conference :)

priyatiwari (anon) | ‎07-18-2014 06:41 AM


Is it possible to reuse the UFT scripts in HP performance center as well. Also, can you please share the process by which UFT scripts can be imported in Vugen.

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.
Showing results for 
Search instead for 
Do you mean 
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.