Log Options In Load Runner Runtime Settings

As a part of Business Process Testing activity, it is a tester’s role to debug all the scripts before it reaches the execution phase. In LoadRunner we can make use of the logging options provided in the runtime settings for the same. It allows us to select the level of details about script playback that are to be displayed at the replay log.

• There two types of logs available in load runner to specify the level of information to be logged during the replay,

1. Standard Log

2. Extended Log

Standard Log

• A standard log displays the details about the set of functions executed and the messages displayed
• This can be used to validate whether the functions are executed as expected

Extended Log

• This is used for logging not only the function calls but also additional details such as parameter substitution, request headers, request body, response headers and the response body. The extended log has three log levels;

1. Parameter Substitution

It adds the details about the parameters substituted and the dynamic values that were captured.

2. Data returned by server

The response header and the response body details for each request is contained in the replay log if this option is selected, i.e. it captures the data that is returned from the server.

3. Advanced trace

With this option enabled, the replay log almost looks like a generation log as it contains details about every request and response that has been sent to and received from the server.

Manual Correlation with extended log

• Extended logging feature is preferred for debugging a script as we can inspect the values to be correlated

To conclude the above, logging the function calls, requests, and responses will be helpful for debugging the script but they utilize the system resources heavily. So the logging is to be disabled for long scenarios. Besides, when going for an execution with very large number of vusers, it is recommended that we disable the logging feature altogether by unchecking the enable logging option.

Thanks For Reading This Blog. Know More About: LoadRunner

Tips for Handling Recording Problems In LoadRunner

When we were using LoadRunner for our Business Process Testing engagements we have encountered certain recording problems. We have listed down some of the most common problems and the steps that should be followed to troubleshoot those issues.

Problem 1: NOT PROXIED error in the recording events log.

This error occurs when there is some sort of spyware software installed on the system.

To troubleshoot this issue follow the below steps:

1. Use process explorer to get the list of dlls getting hooked into Internet Explorer.

2. Compare the list with the dlls from a machine where you can record.

3. Run Ad-Aware software. To download this, visit http://www.lavasoftusa.com/software/adaware/. This usually eliminates the spyware programs.

4. Make sure to check carefully the processes running on the machine. If you find any suspicious DLL\exe, just google the name and see if it’s a known spyware. If so, uninstall the software related to this DLL\executable.

5. Sort the list of DLLs by ‘Path Name’ in Process Explorer. The DLLs to scrutinize carefully are the ones which are not located in LoadRunner\bin and c:\windows\system32 or c:\winnt\system32.

Problem 2: “Cannot connect to remote server” in the recording log

This error occurs when the communication from this server and on that particular port should not be filtered

To troubleshoot this issue follow the below steps:

Try port mapping if it is a HTTPS site.

Go to Recording Options > Port Mapping and add the Target Server’s IP address, Port Number as 443, Service ID as HTTP, Connection Type as SSL. Make sure “Test SSL” returns success. Change the SSL Ciphers and SSL Version to achieve success for “Test SSL”.

Problem 3: “Connection prematurely aborted by the client” error in the recording log.

This error occurs when the communication from this server and on that particular port should not be filtered

To troubleshoot this issue follow the below steps:

Try port mapping with Direct Trapping. Here’s how we can do direct trapping

a. Enable the Direct trapping option:

[HKEY_CURRENT_USER\Software\Mercury Interactive\LoadRunner\Protocols\WPlus\Analyzer]

“EnableWSPDebugging”=dword:00000001

“ShowWSPDirectTrapOption”=dword:00000001

“EnableWSPDirectTrapping”=dword:00000001

b. Before Recording Multi-Web, add port mapping entries for HTTP/TCP (and NOT SSL) connections.

Set their ‘Record Type’ from ‘Proxy’ to ‘Direct’.

c. Start recording.

Problem 4: Application sends a “Client Side” certificate to the server and waits for server authentication.

This error occurs because LoadRunner sits in between the client and server, it takes this certificate information from the client and pass it on to the server. So, you need to have the certificate in .pem format.

To troubleshoot this issue follow the below steps:

Use openSSL to convert the client side certificate to .pem format and add it in the port mapping in recording options

In Internet Explorer:

1. Choose Tools > Internet Options. Select the Content tab and click Certificates.
2. Select a certificate from the list and click Export.
3. Click Next several times until you are prompted for a password.
4. Enter a password and click Next.
5. Enter a file name and click Next.
6. Click Finish

In Netscape:

1. Choose Communicator > Tools > Security Info.
2. Click on the Yours link in the Certificates category in the left pane.
3. Select a certificate from the list in the right pane, and click Export
4. Enter a password and click OK.
5. Enter a filename and save the information.

The resulting certificate file is in PKCS12 format. To convert the file to PEM format, use the openssl.exe utility located in the LoadRunner bin directory. To run the utility:

Open a DOS command window.

Set the current directory to the LoadRunner bin directory.

Type openssl pkcs12 -in <input_file> -out <output file.pem>

Enter the password you chose in the export process.

Enter a new password (it can be the same as before).

Enter the password again for verification.

In Recording Options > Port Mapping > check the option for “Use specified client side certificate” and point to the saved .pem file.

Problem 5: Server sends a certificate to the client for authorization and only when authorized by the client a connection can be established between the client and server. This is mostly true for Java based applications. The error we get is “No trusted certificate found”

This error occurs since the recorder is in between client and server, you should authorize the certificate from the server. So, your wplusca.crt should be in the server’s certificate repository.

To troubleshoot this issue follow the below steps:

Copy wplusca.crt file into the certificate repository of the server.

1. Locate keytool.exe executable (usually under JRE_ROOT\bin directory).

2. Add its directory to the PATH environment variable.

3. Locate cacerts file (with no extension) under JRE_ROOT\lib\security directory.

4. Copy the attached cacert.pem to this directory.

5. Make this to be the current directory in the command prompt.

6. Execute:

keytool -list -keystore cacerts

7. It will ask you for the password, reply:

“changeit”

8. It will list all the CA certificates installed (usually 25).

Notice the number of certificates.

9. Execute:

keytool -import -file cacert.pem -keystore cacerts -alias mercuryTrickyCA

10. It will ask you for the password, reply:

“changeit”

11. It will ask you if you are sure you want to add the certificate to the store, reply:

“yes”

12. Execute:

keytool -list -keystore cacerts

13. It will ask you for the password, reply:

“changeit”

14. It will list all the CA certificates installed.

The number of certificates should be bigger by 1

Problem 6: The recording log does not indicate any error but the connection between the client & Server has ended abruptly. This could happen possibly due to the ‘WPLUSCA’ certificate with a private key

This error occurs when because the recorder sends the ‘WPLUSCA’ certificate with a private key to the server for authentication while recording.

To troubleshoot this issue follow the below steps:

1. Go to LoadRunner\bin\certs and make a copy of the WPlusCA.crt file.

2. Open it in a notepad

3. Delete the portion between “Begin RSA Private Key” and “End RSA Private Key”

4. Save the file.

5. Now right click the file and choose “Install certificate” and follow the on screen instructions.

This will now send a certificate without the private key and if the server accepts the communication will continue.

Problem 7: “Failed to resolve hostname” error in the recording log

If VuGen box is not able to resolve the server name that is given in URL, it throws this error in the recording log and then crashes the IE

To troubleshoot this issue follow the below steps:

Modify hosts file on the vugen machine with server name and any IP address

The above problems are some of the common problems when we are using LoadRunner for Performance Testing. The above mentioned troubleshooting steps will help you to fix these issues if they occur during your performance testing assignment.

Thanks For Reading This Blog. Please Know More About: LoadRunner