What are the limitations of Run-Time Viewer at LoadRunner

The LoadRunner Run-Time Viewer is an integral part in many Vuser script development environments. It provides an easy to use verification tool for watching the replay of Web applications while creating and debugging scripts. The HTML document presentation in many cases allows the scriptwriter to easily see if a particular script has generated the appropriate responses from the server during script execution. 

However, in some cases, because of the limitations of the Run-Time Viewer it is not always possible to use it as a final verification tool. There are numerous complex Web applications that will not be correctly displayed in the Run-Time Viewer or the Run-Time Viewer in response to running the script may even generate errors. These problems do not necessarily point to problems with the script itself. It is important to be able to distinguish and isolate Run-Time Viewer errors from script errors (which can often be two distinct events).

The first step in understanding this is to gain an understanding of the basics of the way LoadRunner Web replay works when running in VuGen.

When a Web Vuser is run through VuGen, the default is to have the Run-Time Viewer open and also to have resources downloaded automatically by the script. These two settings coincide with what the user sees -- that is the script runs through and the resources are downloaded and displayed graphically in the Run-Time Viewer. Now, what is really happening here are two separate things (that are only slightly related)?

The first thing that is happening is that the VuGen Web replay engine is running the script through the HP Driver process (mdrv.exe), which actually takes the script and interprets it to run the script. This process happens independently of whether the Run-Time Viewer is opened or closed and is done the same way in VuGen as it is in the Controller (which runs a multithreaded version of the driver process called mmdrv.exe).

 

The Run-Time Viewer displays the Web documents secondarily to the underlying Run-Time Engine and there is no interdependence on the two to operate properly.
Pop-up messages are often related to this because the Run-Time Viewer is making seperate requests from the Vuser.

There is some support for scripting and client side objects (like applets) but it also suffers some limitations (cannot display multiple frames, etc.).

Errors can best be diagnosed thoroughly through the use of the Extended Execution Log (which contains all the information about the requests and responses made during script execution). Generally, for easier debugging it can be helpful to turn OFF Resource Downloading (under the Browser emulation tab in the Run-Time Settings) so that the resources (usually binary data) are not recorded into the Execution Log (which clutters it with useless data).