Tag Archives: LoadRunner troubleshooting

Enable Unified Functional Testing (UFT) logs

Leave a reply

Previously, QuickTest Professional used the tool \bin\ClientLogs.exe utility, setting up its section called “QTP”, however for UFT, this option does not capture any logs.

Instructions to collect desired logs:

1. Close UFT.exe, AQTRmtAgent.exe and QTAutomationAgent.exe

2. Locate tool’s “Logs” directory/folder (see A section below)

3. Configure config.xml files (see B section below)

4. Clear “Logs” directory/folder.

5. Reproduce situation. If reproduction requires multiple repetitions/iterations, repeat steps 4 – 5.

Note: Enabling logs as suggested may generate larger logs files, so minimizing the tasks done on UFT to reproduce, and clearing the logs before each attempt of reproduction, may help collecting more accurate information from such logs.

6. (If possible) Collect date and time when issue. Note: this helps narrowing down search within logs.

7. Compress logs

A. Logs location/path/directory

The UFT log files generated from below steps should get created by default under the following path:

%APPDATA%\Hewlett-Packard\UFT\Logs

To navigate to above, go to “Start” > “Run” and type above path. Note: if above path is not found, then:

Review which path is setup for logs, on the configuration file of respective feature. For example for general UFT, under log.config.xml, path is configured to default with below entry:

Ensure UFT and machine is using correct files.

B. Configure config.xml files

1. Create backup of \bin\log.config.xml. Note: this is to “disable” expanded logs by replacing modified files with backup

2. Open on a text editor \bin\log.config.xml

3. If the test execution is longer than 30 min, increase the value of maximumFileSize to 50MB:

4. Change the “level value” under “root” tag to DEBUG (instead of ERROR):

5. Make sure all appender-ref element values are set to “RollingFileAppender”:

6. If involving API scripts, add logger/tag named “HP.ST” as below:

set “level value” to DEBUG, under “LogCatRmtAgent” logger:

7. Save changes on log.config.xml

8. Repeat steps 1 to 5 for below files \bin\log.config.AutomationAgent.xml, THEN save changes.

9. For \bin\log.config.RemoteAgent.xml, repeat steps 1 to 5, THEN

10. For \bin\qeee.log.config.xml, repeat steps 1 to 4, THEN:

1. Make sure all appender-ref element values are set to “QEEE_RollingFileAppender”:

2. Set “level value” to DEBUG, under “HP.QTP.QEEE” logger:

Advertisements

Use rdp_sync_on_window for a partially changing window title

Leave a reply

To use rdp_sync_on_window for a partially changing window title for the following scenario

rdp_sync_on_window(“StepDescription=Window Synchronization 1”,

“Snapshot=snapshot_12.inf”,

“WindowTitle=I am static XXXX YYYYY ZZZZ”,

“WindowState=ACTIVE”,

RDP_LAST);

Need to use sync on the portion of the window name that doesn’t change where XXXX YYYYY ZZZZ change, but the first part (I am static) stays the same.

To achieve this the windowTitle argument comes with regular expression

WindowTitle/RE=

In the above example, we can keep the first part static(I am static) and exclude the 2nd part (XXXX YYYYY ZZZZ)using Regular expression.

LR Controller throws Microsoft Visual C++ Runtime Library Runtime Error

Leave a reply

Using LoadRunner (LR) 11.00 Patch 4 on a machine that was previously running LR 11.50. When trying to open a scenario the wlrun process crashes and the following message is displayed:

Unsupported operation was attempted

Microsoft Visual C++ Runtime Library

Runtime Error!

Program: C:\\Software\\HP\\LoadRunner\\bin\\wlrun.exe

abnormal program termination

This happens on every attempt to open an LR scenario. Uninstalling and re-installing LoadRunner 11.00 or and 11.04 patches does not resolve the problem. Upgrading LoadRunner to version 11.50 is not possible on this machine as it currently has to run with an LR 11.00 license key.

In certain cases uninstalling of LR 11.50 may leave registry keys enabled for the LR 11.50 version that are incompatible with LR 11.00 and therefore cause the 11.00 wlrun process to crash. To resolve the problem try the following steps on a Windows 7 64 bit machine:

Back up the registry.

Run Regit and go to HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{6B2455C3-CAF8-4578-BBA4-B7566F89EBAA}\InprocServer32

Delete any 11.5x subfolders.

On a Windows XP 32 bit machine the invalid 11.5x entry will be found in

HKEY_CLASSES_ROOT\CLSID\{6B2455C3-CAF8-4578-BBA4-B7566F89EBAA}\InprocServer32\11.5x.0.0

Error: “Object doesn’t support property or method ‘indexOf'” when saving the “Speed simulation” run-time settings of a TruClient script

Leave a reply

An error is received when trying to save the “Speed simulation” Run-time settings of a TruClient script:

“Script Error: An error has occurred in the script on this page.

Error: Object doesn’t support property or method ‘indexOf'”

As a result the settings are not saved and the “Save” button becomes disabled.

The issues is caused by missing default values for the speed simulation settings.

To fix the issue for the current script:

1.Open the default.cfg file in the script folder.

2. Go to the [ModemSpeed] section

3. Add values for the ModemSpeedUpload, ModemSpeedDownload and ModemSpeedDownloadAndUpload settings.

For instance:

[ModemSpeed]

ModemSpeedMode=1

ModemSpeedUpload=0

ModemSpeedDownload=0

ModemSpeedDownloadAndUpload=0

4. Save the file and reopen the script in TruClient

5. Go to the Run-time settings > Network > Speed simulation. Changing and saving the values should work now.

To fix the issue for any new scripts, modify the run-time settings templates for TruClient IE and Firefox:

Apply the above changes to the following default.cfg file:

<LoadRunner installation>\template\WebIE\default.cfg

<LoadRunner installation>\template\Web2UI\default.cfg

After saving the changes, any new TruClient script will have the default runtime settings for “Speed simulation”

LoadRunner Upload – Download file / Operative System 4 GB Memory Limitation

Leave a reply

Each operating system has a physical memory limit which reciprocally define the boundaries for memory and address space that can be used by the processes, services, objects and services executed over the current operative system version.

Following is the memory limits that are present in Windows OS and how it affects the mdrv.exe process emulation when uploading/downloading large files, generating a reaction where the mdrv will crash, hangs or result in a memory violation.

 The implementation of LR file uploading/downloading is not optimized for huge file. It always reads all the files to memory before upload. That means, for files with 1 GB in size, mdrv has to   obtain 1 GB sequential memory space in the process for each Vuser. However, mdrv is a 32 bit process. In windows system, a 32 bit process has at most 4 GB in memory space, and only 2 GB of them can be used by developer. If the user tries to upload a file with 2 GB in size, it is almost impossible to find proper memory for it, since the other functions will also use some memory.

When the file size is smaller, like 500 MB to 1 GB, it will be possible to make the upload successful. But when we run the script in controller, we should make the Vuser run in process mode.

From the Operating System perspective and as a workaround it is possible to switch the memory use and memory address space allocation to 3 GB for the application and less 1 GB for the operating system.

In order to increase the memory and address space to 3 GB limit we need to be implement the following steps.

  1. Right-click on the Command Prompt icon in the Accessories program group of the Start menu. Click Run as Administrator.
  2. At the command prompt, enter:

bcdedit /set IncreaseUserVa 3072

  1. Restart the computer.
  2. Run the script one more time in VuGen and in the Controller using the LG as process.

For disabling  the  memory increase here is the command.

  1. Right-click on the Command Prompt icon in the Accessories program group of the Start menu. Click Run as Administrator.
  2. At the command prompt, enter:

bcdedit /deletevalue IncreaseUserVa

  1. Restart the computer.

Configure a proxy server for connecting VuGen to a remote Git server

Leave a reply

VuGen 12.53 supports integration with Git, enabling you to store scripts in a local or a remote Git repository. If a proxy server is needed to access the remote repository, the proxy configuration needs to be set up manually outside of VuGen using a Git command line client.

VuGen does not include a Git command line client, so it must be installed manually.

Follow the instructions below to set up a proxy server for Git:

  1. Install any Git command line client i.e. Git-SMC (the portable version will also work)
  2. Open the Git client (If you installed the Git-SMC run the git-cmd.exe)
  3. Execute the following command (replace the <proxy_server> and <port_number> with the correct values, note the two consecutive hyphens prepending the global option)
    git config –global http.proxy <proxy_server>:<port_number>
  4. To reset the proxy settings execute the following command (note the two consecutive hyphens prepending the global and unset options):
    git config –global –unset http.proxy

VuGen support for recording and replay of HTTP/2 enabled web sites

1 Reply

As of version 12.53 VuGen supports HTTP/2 (including multiplexing) enabled web sites for recording and replay.

In order to enable recording of HTTP/2 the following recording option must be set:

  1. Record > Recording Options > Network > Mapping and Filtering.
  2. Click Options to open the Advanced Port Mapping Settings dialog box
  3. In the SSL Version dropdown, select TLS ALPN.
  4. Click Update.

alpn

ALPN is a Transport Layer Security extension for application layer protocol negotiation within the TLS handshake. It allows the application layer to negotiate which protocol should be performed over a secure connection in a manner which avoids additional round trips and which is independent of the application layer protocols.

In order to enable replaying of HTTP/2, make sure the correct TLS version is set in the script:

web_set_sockets_option(‘SSL_VERSION’, ‘TLS1.2’);

To verify that HTTP/2 was used for replay, enable Advanced Trace in the Log runtime settings. After replay, see the Replay log and note the references to HTTP/2.
Below is an example log from a replay of a HTTP/2 web server.

Action.c(13): The request to server https://<hostname>/” is done with headers:
Action.c(13):     :authority = <hostname>
Action.c(13):     :method = GET
Action.c(13):     :path = /
Action.c(13):     :scheme = https
Action.c(13):     user-agent = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gec
Action.c(13):     ko) Chrome/46.0.2486.0 Safari/537.36 Edge/13.10586
Action.c(13):     accept-encoding = gzip, deflate
Action.c(13):     accept-language = en-US
Action.c(13):     accept = */*
Action.c(13): t=2026ms: 139-byte response headers for “https://<hostname>/” (RelFrameId=1, Internal ID=1)
Action.c(13):     HTTP/2.0 200\r\n
Action.c(13):     Status: 200\r\n
Action.c(13):     Server: nginx\r\n
Action.c(13):     Date: Fri, 03 Jun 2016 07:27:29 GMT\r\n
Action.c(13):     Content-Type: text/html; charset=UTF-8\r\n