I would add to Jeffry's excellent layout:

- You can record fat clients that use too many protocols or unsupported protocols to communicate to a backend or database. The only other alternatives are Citrix and Terminal server client scripts. This can include systems that only access shared file systems that are difficult to scale and monitor. These days they can be Cloud resources for something like MS Office 360 that ''appear'' to be local, but use remote storage.

- If you have terminal servers you can use as Load Generators, you can hit higher numbers and not have to worry about installing QTP/UTF on each machine. The Load Generator install has a subset that runs the scripts without the major resource hogs built into QTP, like the recording parts not used during replay.

- Licensing is also based on GUI VUser count, not a license server or per seat installs

- If you have remote locations, you can install LR Load Generator on PCs in the outside offices and then run a single GUI VUser at each site to see what they will see on the rendering side as the load test ramps up.

Some of the other areas can include setup and clean up activities. Then there is a repeatability factor and the analysis of the results where patterns can be ferreted out.

And my all time favorite - you Can answer that nagging question about ''did we meat the SLAs from the end users point of view?!?''. Without a GUI vuser, you had to do it manually with a stopwatch or with a special QTP script to capture times and compare against the various SLAs.

Good Luck

The benefits of running GUI Vusers during a load test are posted below.

1) To see how the functionality of the application gets affected under the heavy load.

2) To measure the end-to-end response time experienced by a typical user on the client side while the application is under load.

3) By including QTP test scripts at specific points in a LoadRunner scenario we can confirm that the functionality of our application does not get affected by the extra load at these sensitive points.

4) When a GUI Vuser script runs on our screen during the LoadRunner scenario, we can watch the actual steps executed by the Vuser in a real time.

5) By having Transactions in your QTP Script, you can understand how long each step or business process takes. This will provide information showing what the End User's application experience would be using the application under load.

6) You will be able to measure the end to end browser based user experience. With a typical web script the browser time is not considered. You are actually measuring client server response time without the browser.
In order to setup / configure PC and QTP you will need to do the following:

1. Add Transactions to your QTP Script
2. Setup The PC Controller to monitor the Windows Resources of the QTP / Load Generator machine. We recommend working with your systems team and select the appropriate windows resources to monitor; for example, CPU Usage, Memory Usage, Processor Time, Processor Queue Length, Available KBytes, Current Disk Queue length, and Context Switches/sec.

Note: For the GUI Vusers, LoadRunner will not provide metrics; such as, ''Through Put'' etc. as you would see for other LoadRunner Protocols.