What are the limitations of RunTime 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 script writer 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 errors may even be generated by the Run-Time Viewer in response to running the script. 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 happenning here are two seperate 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 Mercury 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 the driver process called mmdrv.exe).
The script's statements are executed and requests are sent to the server so it can return the data to the client. Note that with a website the normal progress of events goes like this:
1. Client connects to the server.
2. Client requests a document (usually an HTML file such as index.html).
3. Server responds by sending the requested document if it is found.
So, for one simple request to the server made by the user, two requests are actually generated by the client application (the browser) in order to display the complete webpage.
All of this happens in the background by the client in order to download ALL of the resources that may be referenced on a given webpage. This continues for any objects on the page including images (e.g., .gifs, .jpgs, etc.) as well as other objects like ActiveX controls and Java Applets in addition to other requests generated by JavaScript activities (such as rollover images). In general, the user is unaware these extra requests are being generated.
During replay with LoadRunner the same basic series of events is happenning. If Resource Downloading is turned on in the Vuser Run-Time Settings each resource mentioned on the webpage will be downloaded automatically by the LoadRunner Run-Time Engine during replay. Typically, what happens at this point is the webpage is downloaded and saved to a file (with a name like t#.html) in the "Result1\Iteration#" directory that gets created in the Vuser script directory during execution. LoadRunner also stores the HTML in memory and parses through it to download all of the resources that are mentioned in that page. At this point if the Run-Time Viewer is turned OFF that would be the end of the replay events. However, if the Run-Time Viewer is turned ON, then the following happens. A reference to the document to retrieve is passed to the Run-Time Viewer as an input so that it will then go out to the network and retrieve the same document for display. It does the same thing as the LoadRunner Run-Time Engine and what a browser does -- that is, it will download all of the resources referenced on the page as well.
It is important to note that the Run-Time Viewer download of the page is secondary to the actual replay engine. There is no dependency between the two entities. To actually see the data being retrieved by the Vuser (using the replay engine) you can change the Vuser Logging options to enable "Data returned by server" under the Log tab. This will then print to the execution log all of the data returned by the server at run-time (again, regardless of the status of the Run-Time Viewer). This log is an authoritative account of the activity of the Vuser and the data being sent to it during execution.
One reason this is so important is the fact that errors can appear in the Run-Time Viewer that do not necessarily indicate script level problems. Because the Run-Time Viewer is an embedded browser component (basically built off of Internet Explorer components available within the system) it does not feature all of the capabilities of a real browser (like support for frams, complex scripting, and some Applets and ActiveX controls). Also, because it is making requests outside of the Virtual User script there may be pop-up messages boxes prompting for user authentication (even though usernames/passwords may be included in the script via a web_set_user() function). Again, this is because the Run-Time Viewer is actually making requests independent of the script and thus the server demands authentication as though the request is coming from a seperate browser instance (which it is).
One way to see that this is true is to run the script with the Extended Execution Log and with the Resource Downloading in the Run-Time Settings turned OFF. When the script is replayed no resources will be downloaded by the script but the Run-Time Viewer will still display the resources (like images).
Troubleshooting the Run-Time Viewer:
In general, problems and error messages that appear as pop-up messages boxes are limited in scope to being Run-Time Viewer limitations. With the Run-Time Viewer disabled, these same message boxes (usually reporting such things as scripting errors or asking for user authentication) will not be generated by the script replay. Although they appear as errors during script execution they are really display limitations of the Run-Time Viewer itself and not necessarily representative of script failure.
In addition, although there is some basic support for ActiveX controls, Applets and JavaScript, all of the functionality of these technologies will not work all of the time in the Run-Time Viewer. It is possible for simple instances to work in this environment (see http://java.sun.com when replayed in a Web script and you can see the applets displayed) but sometimes the application is to complex for proper support.
Problems that do get reported in the Run-Time Viewer as actual text displayed in the Viewer itself can indicate a problem during script execution. This may be because the requested page actually generates the same problem in the Run-Time Viewer as the underlying LoadRunner Run-Time Engine. As always, the best way to determine replay failure is to go back to the Extended Log that can be generated during script execution. This reports the client/server communication in full (with all extended log options checked) and can be used as a reference for understanding more about what the error that was generated was. A simple text search through the Extended Execution Log for some error message appearing in the Run-Time Viewer can show whether the problem reported in the Run-Time Viewer is actually occurring at the network level for the vuser itself.
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 seperate requests are being made by the Run-Time Viewer 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).
Navigation for Runtime viewer setting:
Ref doc:cblogs
Please post yout valuable comments.
feel free to post your comments to testingblog4u@gmail.com :)
