How to emulate C function lr.vuser_status_message() in TruClient JavaScript code?

How to emulate C function lr.vuser_status_message() in TruClient JavaScript code?

How does one emulate the C function lr.vuser_status_message() — using the Ajax TruClient?

Using LR.log(“…”, “Status”) doesn’t’ work when “errors/warning only” log level is checked in run time settings.

You can use the C code function like the following:

void log_status()

{

lr_vuser_status_message( "%s", lr_eval_string( "{my_message}" ) );

}

Put the above in a C function file.

The usage from TruClient is in an “Evaluate JavaScript code” step with suitable code:

LR.setParam("my_message","text to show in Vuser status bar”);
LR.evalC("log_status");

Error: “TE_wait_cursor failed: col = xx, row = xx, stable = xx, timeout = xx, Timeout”

Error: "TE_wait_cursor failed: col = xx, row = xx, stable = xx, timeout = xx, Timeout"

RTE runs fine in both the Controller and injector machines’ VuGen, but within a scenario, it fails on the injector (remote) machines with the error:

"Error -17999 : TE_wait_cursor failed: col = xx, row = xx, stable = xx, timeout = xx, Timeout"

To resolve this problem edit the termset.pts file on the remote machine

Note:
You can also use this solution for different errors, but only if the error occurs solely on remote hosts.

A common problem with RTE is that the Terminal Type is not transmitted to the remote machine. You should check this by viewing the terminal on the remote machine. (This can be reached by right-clicking on the Vuser line in the Controller while running scenario — click on "Show Vuser," then you can see the Terminal Type (by the screen color and the type also should be written there).

If the Terminal Type is wrong (e.g., the screen is a blue vt100), look at the termset.pts file in the Vuser temporary directory on the remote machine. (The Vuser temporary directory can be found by clicking on "Generator," highlighting the host name, and clicking on "Details.") It contains the line:

Emulation-Type = 3270-Display

in the [Terminal Settings] section.

If necessary copy the termset.pts file from the Vuser directory to <LoadRunner>\bin\ptdef.pts on the remote machine.

Also make sure that the Vuser temporary directory on the remote machine in its path contains no spaces.

Error: “TE_wait_cursor failed: col = xx, row = xx, stable = xx, timeout = xx, Timeout”

Error: "TE_wait_cursor failed: col = xx, row = xx, stable = xx, timeout = xx, Timeout"

RTE runs fine in both the Controller and injector machines’ VuGen, but within a scenario, it fails on the injector (remote) machines with the error:

"Error -17999 : TE_wait_cursor failed: col = xx, row = xx, stable = xx, timeout = xx, Timeout"

Terminal Configuration file is not being transferred to the Load Generator. It is not possible to check the terminal on the remote machine as the user hasn’t started yet ( "Show Vuser" not enabled yet for running vusers ). It is necessary for the Load Generator machine to have this information, otherwise, synchronization problems can appear.

To fix this issue follow the below steps.

Include files in Script

From the directory open the .usr file with a notepad. Then, add the .pts file under the [ExtraFiles] section of the script. Example:

[ExtraFiles]

termset.pts=

Add the file in the Controller Group

Right-click on the Script/Group and select Details > More > Files Tab > Add. This will allow you to navigate to the script folder and select the .pts file to be sent to all Load Generators running the script.

Web Click and Script Tips and Tricks

Web Click and Script Tips and Tricks

General Overview of Web Click and Script Protocol

The Web Click and Script protocol is introduced in VuGen 8.1 FP2. The major advantage of the Web Click and Script protocol is that it supports client side JavaScript during replay. As a result, the need for correlation is drastically reduced and hence scripting time is reduced as well. It introduces a GUI-level scripting API, and an extremely quick way to generate load testing scripts.

* With Web (Click and Script) you will save valuable scripting time. The easy-to-use script eliminates the need for correlation.
* New intuitive API functions describe user actions on Web objects (button, text link etc.).
* In tree view, the steps are grouped according to their pages.
* In snapshot viewer, the object corresponding to the active step is highlighted.
* Can create a Business Process Report (Microsoft Word format) summarizing the VuGen script.
* The LoadRunner QuickStart contains an appendix illustrating the new Web (Click and Script) features. Access the QuickStart from the Windows Start menu Mercury LoadRunner > QuickStart.

VuGen Version and Requirement

VuGen 8.1 FP2 and above

Supported browser: Only Internet Explorer 6

Supported Operating Systems: WinXP/2000/NT (not Win2003)

Recording Options

GUI Properties tab is related with the new features available in Web Click and Script.

Breakdown of Recording options available under GUI Properties -> Advanced

Enable out of context recording: VuGen does not natively support the recording of ActiveX controls and Java applets. You can instruct VuGen to create a URL-based script for ActiveX controls and Java applets, so that they will be replayed. Since these functions are not part of the native recording, they are referred to as out-of-context recording (enabled by default).

Record rendering: Record the values of the rendering-related properties of DOM objects (e.g. offsetTop), so that they can be used during replay. Note that this may significantly decrease the replay speed. (disabled by default).

Record `click’ by mouse events: Record mouse clicks by capturing mouse events instead of capturing the click() method. Enable when the recorded application uses the DOM click() method, which may result in generating multiple script functions for the same user action. (enabled by default)

Web Event Configuration: Changing the settings under this recording option will affect how sensitive VuGen is to capturing events when navigating a webpage. When moving the mouse over an image on a webpage, the web event configuration decides whether to record this as an event or to record an event only when a mouse click occurs.

Choosing the “High” Web Event configuration option slows down the recording and could also result in some events being captured twice. This setting should be used when events that are expected are not captured.

Choosing the “Basic” Web Event configuration option is the fastest. This setting should be used unless certain expected events are not captured.

For more detailed information on custom web event configuration, please click on the Help button on the Web Event Configuration box.

Best Practices

• Use the mouse and not the keyboard as far as possible.

• To capture events, work only on browser windows opened by VuGen

• Wait until the page loads completely before going on to the next step of the business process.

• Always start recording on a new script. Do not record over an existing script.

• Avoid using context menus i.e. menus which pop up when clicking an item in a GUI.

• DO NOT reorder functions or move them from one section of the script to another.

Limitations

• Records and emulates on Internet Explorer version 6 only

• Does not support recoding on Windows 2003

• Does not support VBScript and Applets

• Does not support user actions on ActiveX objects and Macromedia Flash

• Supports only English language applications

• Scalability is lower than the Web HTML protocol

• Replay snapshots may differ slightly from the actual Web page

• Modal Dialogs are not supported

• The automatic generation of web_reg_find statements for page titles does not work in Web Click and Script. Workaround is to manually add the web_reg_find after the script has been recorded.

Tips and Tricks

• When the HTML contains code such as Offsettop or Offsetleft (which are properties used to give the coordinates of the element) : Enable record rendering related property values under Recording Options -> GUI Properties -> Advanced.

• To record “mouse over”, “mouse down” events on a webpage : Change the Web Event Configuration to High under Recording Options -> GUI Properties -> Web Event Configuration.

• If the script continually fails on a particular step: Try replacing that step with Alternative Navigation . Right click on that step and choose “Replace with alternative navigation” on the menu that comes up.

• If a “Button Not Found” error is seen: Check to see if the value in the script is the same as that reported in the replay log. If not, replace the value in the script by that reported in the replay log.

Example:

The following is recorded in the script:

web_button(“BUTTON”,

“Snapshot=t2.inf”,

DESCRIPTION,

“Type=submit”,

“Tag=BUTTON”,

“ID=”,

“Value=<B id=a>Google Search</B>”,LAST);

Hint: The replay log contains:

Name=”btnG”, Id=””, Value=”<B id=”a”>Google Search</B>”, Text=”Google Search” [MsgId: MMSG-26000]

Change the script step as follows:

web_button(“BUTTON”,

“Snapshot=t2.inf”,

DESCRIPTION,

“Type=submit”,

“Tag=BUTTON”,

“ID=”,

“Value=<B id=\”a\”>Google Search</B>”,LAST);

• If the HTML element ID changes dynamically: Use the ordinal attribute instead of the ID attribute.

Example:

web_image_link(“IMG_52549_2”,

“Snapshot=t2.inf”,

DESCRIPTION,

“Alt=”,

“ID=IMG_52549”,

ACTION,

“ClickCoordinates=33,28”,

LAST);

In the above example, the ID=IMG_52549 changes each time.

Solution:

web_image_link(“IMG_52549_2”,

“Snapshot=t2.inf”,

DESCRIPTION,

“Alt=”,

//”ID=IMG_52549″, Commented out as it is dynamic

“Ordinal = 12” //This is the ordinal of the image on the page.

ACTION,

“ClickCoordinates=33,28”,

LAST);

Text Check Verification in Web Click and Script

Text Check Verification in Web Click and Script

Use the Verification argument in the Description section of a function.

Note:
LoadRunner 8.1 FP4 is required for this feature.

The Verification argument in the Description section can be used in the following functions:

  • web_browser
  • web_element
  • web_list
  • web_text_link
  • web_table
  • web_text_area

Web_XXX("some name",
DESCRIPTION,
?
VERIFICATION,
["ContainsText[/RE]=some text",]
["DoesNotContainText[/RE]=some text",]
[ACTION,]
?
LAST);

Examples:
web_browser("Sync",
"Snapshot=t2.inf",
DESCRIPTION,
ACTION,
"Sync",
VERIFICATION,
"ContainsText=Products",
LAST);

The Verification will pass if the resulting page has the word "Products" in it.

web_browser("Sync",
"Snapshot=t2.inf",
DESCRIPTION,
ACTION,
"Sync",
VERIFICATION,
"ContainsText/RE=Prod*",
LAST);

The Verification will pass if the resulting page has the string "Prod" followed by any characters.

Note:
Without the "/RE" the actual string Prod* will be searched for and if this is not found the Verification will fail.

web_browser("Sync",
"Snapshot=t2.inf",
DESCRIPTION,
ACTION,
"Sync",
VERIFICATION,
"DoesNotContainText=Junkcharactersasdfgf;lkjhj",
LAST);

The Verification will pass if the string "Junkcharactersasdfgf;lkjhj" is not found.

Click and Script browser rendering time

Click and Script browser rendering time

Is there a way to control the transaction end time in "Web Click and Script" so that it doesn’t include browser rendering times?

can "Web Click and Script" generate the "same" timings as the "Web HTML/HTTP" protocol?

As rendering time is time spent in the browser to generate the image, in web protocol we don’t have it. As in C&S, there is a setting to record with rendering information so we can built the information as it is in the browser, So, it is more logically simulated somehow, but not in the extent, as we need to identify the object position.

In Summary: we can’t say we have full rendering time but, on the other hand there is no way to disable building the object information. It is not possible to disable browser rendering times in Click and Script protocols.