Mercury LoadRunner

VuGen 8.1 FP2 – Web Click and Script

Overview

Web Click and Script (“WCS”) feature provides an easy way of recording scripts for Web based
applications. Unlike classical “Web HTTP/HTML” scripts, WCS scripts are recorded at a higher
presentation layer and deals with GUI objects and actions like pressing a button, filling a text
box, clicking on an image, etc. They also execute the client-side Javascript code like a browser
does.

A WCS script would remind an experienced LoadRunner user of Citrix scripts.

Benefits

1. WCS scripts are more intuitive, self-explanatory.

2. WCS scripts generally have lesser lines of code compared to Web HTTP/HTML scripts, and
hence are less cluttered.
3. In almost all cases, WCS would eliminate the need for correlation. This would result in
a more robust script.
4. Certain applications used client-side Javascript to compute dynamic values that are passed
between various pages. Web HTTP/HTML scripts had no straightforward way of capturing
and correlating such data. Since WCS scripts execute client-side Javascript code, they are
the preferred way to record such applications.
5. Since WCS also executes Javascript code, the resultant performance data is more realistic.

How to use this feature

To record script in WCS, simply choose Web Click and Script as the protocol in VuGen.
In the recording options, choose “GUI-based script”. Rest of the options can remain as default.
You may note that many recording options that were available in Web HTTP/HTML are not
present in WCS. It would be prudent to investigate certain important options and the impact of
their non-availability.

Once the browser opens, the actual recording process remains largely the same as before. You
can insert transactions, checkpoints, comments, and perform navigational flows. It is
recommended to avoid using the mouse and rely on keyboard commands.

Web HTTP/HTML and WCS protocols can’t be combined. However WCS can be combined
with other protocols like Citrix.

Possible Limitations and Issues

1. Since WCS deals with GUI objects, the internal properties like naming, coordinates,
ordinals, etc. for such objects becomes very important. For example, WCS script functions
like web_image_link have arguments to specify coordinates. Similarly web_browser function
has an argument called “Sync”.
2. As per Mercury documentation, WCS has been tested with 200 users per Load Generator.
Chances are that in a real usage scenario, this limit could be even lower. Hence for large
volume tests, we may want to use a higher number of load generators.
3. Memory and CPU requirements per VU are likely to be higher since the VUs also execute
Javascript code. These requirements might need to be verified via a POC.
4. Recording is limited to Internet Explorer on Windows. However, this should not be a major
problem.
Further Actions

1. POC to establish the memory and CPU requirements for WCS.

2. A best-practices guide on how to effectively utilize WCS. It should include tips and tricks,
troubleshooting guidelines, common pitfalls, etc.