Hi,
To retrieve the data form data base :
1. In the remote machine à H:\ :Create a notepad and copy below code
2. Update the required SQL query in the below string “Sqlquery” and query should retrieve only one value .(while editing the query selectà Editàx.vbs)
3. Update the required server .(In the below code dev 90 is connected iiy replce 90 with 73,91,………….. as per requirement and environment ).
4. Then save it with “VBS” extension and double click the file .
5. Verify the result in the H:\SQLResult.txt
strConn = "DRIVER={SQL Server};SERVER=sqlvirdev0090\dev90,6090;Database=rr_ge_db01;"
Set con = CreateObject("adodb.connection")
con.Open strConn
Sqlquery = "(select rx_i from rx where asgn_rx_i='80087139')"
Set Value = con.Execute(Sqlquery)
dbvalue = Value.fields(0)
'MsgBox dbvalue
Set txt = CreateObject("scripting.filesystemobject")
Set txt1 = txt.createtextfile("H:\ SQLResult.txt", True)
txt1.writeline dbvalue
Friday, November 12, 2010
WCF client test using VSTS 2008
Select WCF test client: C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE
Click on WCF TEST client.exe file
Click on Add Service
Enter wsdl file url to import the service
Click on ok button
Click on methods
Double click on Get Authorized Search Scopes
Select new proxy check box and click on invoke button
Click on OK button
The request will be populated
We can change the config file by right clicking on config file.
Identity
Headers
Binding
Security
Save the config file
Click on Yes button
Soap request and response on xml tab
Click on WCF TEST client.exe file
Click on Add Service
Enter wsdl file url to import the service
Click on ok button
Click on methods
Double click on Get Authorized Search Scopes
Select new proxy check box and click on invoke button
Click on OK button
The request will be populated
We can change the config file by right clicking on config file.
Identity
Headers
Binding
Security
Save the config file
Click on Yes button
Soap request and response on xml tab
Good document for Controller
2. INTRODUCTION TO LOADRUNNER
2.1 What is the Purpose of Load Runner?
LoadRunner is used to create a load or stress on a system, and can be used to measure the responsiveness of the system to that load. The key concept behind LoadRunner is the use of virtual users, or vusers. To perform a load test, a system needs many users to access the system concurrently, often one hundred or more. Performing such a test with people is a logistical nightmare. LoadRunner overcomes this problem through the use of vusers.LoadRunner is a Testing Tool used for Testing the Performance of an application by emulating an environment in which multiple users work concurrently. LoadRunner will apply load on the application and Test Maximum Load an application can support. While the application is under load, LoadRunner accurately measures, monitors and analyzes a system’s performance and functionality.
2.2 The components of the LoadRunner.
1. VirtualUserGenerator
The virtual user generator is used to generate scripts for all non-GUI vusers. The virtual user generator records the behavior of the client software, and automatically generates a script that can be used by the controller to run vusers.
2. Controller
Once vuser scripts have been created, they can be added into the controller in varying quantities to produce the demand on the system that is required.
3. Analyzer
The load analyzer utility presents the results of running a scenario in a variety of graphical and tabular forms. These graphs and tables can be used to determine the acceptability of a system, and to determine areas of concern.
2.3 What is the Sequence to use LoadRunner?
Creating Vusers Scripts.
Here, we create Vuser scripts that contain tasks performed by each Vuser, tasks performed by Vusers as a whole, and tasks measured as transactions by using VirtualUserGenerator.
Creating the scenario.
A scenario describes the events that occur during a testing session. It includes a list of machines, scripts, and Vusers that run during the scenario. We create scenarios using LoadRunner Controller. We can create manual scenarios as well as goal-oriented scenarios. In manual scenarios, we define the number of Vusers, the load generator machines, and percentage of Vusers to be assigned to each script. For web tests, we may create a goal-oriented scenario where we define the goal that our test has to achieve. LoadRunner automatically builds a scenario for us.
Running the scenario.
We emulate load on the server by instructing multiple Vusers to perform tasks simultaneously. Before the testing, we set the scenario configuration and scheduling. We can run the entire scenario, Vuser groups, or individual Vusers.
Monitoring the scenario.
We monitor scenario execution using the LoadRunner online runtime, transaction, system resource, Web resource, Web server resource, Web application server resource, database server resource, network delay, streaming media resource, firewall server resource, ERP server resource, and Java performance monitors.
Analyzing test results.
During scenario execution, LoadRunner records the performance of the application under different loads. We use LoadRunner’s graphs and reports to analyze the application’s performance.
3. CONTROLLER
3.1 About controller
More than one Vuser can be tested using the Load runner Controller. Controller will execute the scenarios .It will make hundred of vusers running in the single system.
3.2 Procedure for creation of scenario in controller.
LoadRunner Controller is used to manage and maintain scenarios (events that occur during each testing session).
To run a scenario
1. Start->Programs->Mercury LoadRunner->Applications-> Controller
By default the controller opens with the NewScenerio dialog box. If it does not open on startup you can open it by choosing File->New.
2. You can select one of two methods to create a scenario: Manual Scenario or Goal-Oriented Scenario. In a manual scenario, you create the scenario yourself by defining the number of Vuser groups you want to run, and building a schedule for LoadRunner to run these groups. You can also create a manual scenario by defining the total number of users to be used in the scenario, and assigning a percentage of the total number of Vusers to each script. If you want to create a scenario using the Percentage Mode, select Use the Percentage Mode to distribute the Vusers among the scripts.In a goal-oriented scenario, you define the goals you want your test to achieve, and LoadRunner automatically builds a scenario for you, based on these goals.
3. Select the script you want to run the scenario.
4. In Design view give the Quantity (No of vusers) and Click editschedule button and set the settings according to the requirements.
The Load Runner Controller enables the creation of scenario which are of two types:
Manual Scenario
You build a manual scenario by creating groups and specifying the script, the load generator, and the number of Vusers included in each group.
When the Load Runner is launched the above screen comes up. Scripts can be added to the scenario by clicking on the Add Button. The other buttons are self-explanatory and for their explanation please refer to the LoadRunner Controller Users Guide Chapter 5.
Manual Scenario Design Tab
The Scenario Schedule Pane describes the Schedule Name, Mode, Scenario Duration and Load Behaviour. These will be described in greater detail in the section on scheduling a scenario.
The Scenario Groups pane lists all enabled and disabled Vuser groups, their paths,the load generator machines, and the number of Vusers assigned to each group.
3.3 Configuring runtime settings
The configurations of settings that have been used for Maconomy Load Testing are:
Run Logic: the number of iterations decided on the scenario
Pacing: As soon as the previous iteration ends.
Log: The messages should generally be logged at the level of Standard Log. However Extended Logging can be enabled when doing some investigation into a problem especially for sending Result Files to mercury for their investigation. But for the purpose of performance testing Extended Logging should never be enabled as it will adversely affect the results.
Think Time: This should generally be as Replay Think Time, Use Random percentage of recorded think time(50%to 150% ) and Limit Think time to 5 seconds. These are no hard and fast values and can be changed if considered suitable.
Miscellaneous: Use default.
Speed Simulation: Use default
Browser Emulation: Use default
Proxy: No proxy (default condition)
Preferences: Use default except for Advanced Options. Click on options button. In the Advanced Options box select change the following:
HTTP-request connection timeout (sec) to 1000 seconds
HTTP-request receive timeout (sec) to 1000 seconds
Step download timeout (sec) to 1000 seconds
Content Check: Use default.
3.4 Configuration of Load Generator
Clicking on the Generator tab opens up a box as shown below:
The load generator, which actually generates the load, is installed on a machine which is separate from Controller. So the name or the IP address of the machine needs to be added against the script as shown in the Scenario Groups screen shot. The screenshot above gives a ready reference of all the load generators that have been configured and their status.
3.5 Scheduling a Scenario
An important factor in creating a scenario is developing a test that actually portrays user behaviour. The type of actions is captured is by the Vuser script. Scheduling the script captures the timing of actions.
It is essential that the scenario of a test is accurately estimated otherwise the usefulness of the results of Load Testing might be undermined. Load Runner provides various techniques for creating an acceptable simulation of Real life scenario.
Through the Scenario Start dialog box shown in the screen shot below:
You can instruct Load Runner to begin executing a scenario with a delay, or you can specify the number of minutes you want the Load Runner to wait after the Run command has been executed. You can even specify the specific time at which you want the scenario to begin executing.
Through the Scenario Builder as displayed below you can control the execution of your scenario by limiting the scenario duration, gradually running Vusers within a scenario, gradually stopping Vusers within a scenario. Please refer to appendix 1 on how to simulate work load models.
• Limiting the Scenario Duration: The scenario can be made to run until completion, can be made to run for a certain duration after rampup, or can be run indefinitely. If the scenario is made to run for a certain duration after ramp up then irrespective of the number of iterations the scenario will run for the defined time.
• RampUp: All the Vusers can be made to run simultaneously or a delay can be given between groups of Vusers before they start running. In Maconomy generally we need to give a ramp up time to reduce the levels of concurrency in Transactions and also to more accurately simulate the real life scenario as its highly unlikely that all the users would be performing the same transaction at the same time. The ramp up time, generally given for Maconomy is ‘10 users every 30 seconds’. But any suitable value can be given.
• RampDown: There are two options either all the Vusers can be stopped simultaneously or a certain number of users can be brought to a stop in a certain timeframe.
3.6 Scheduling a Vuser group
After creating a Vuser group, you can schedule the groups script execution by setting:
• The amount of time after the start of the scenario that the group must wait before it starts running
• The number of vusers that will run within a specified period of time
• The number of Vusers that will be stopped within a specified period of time
• The amount of time the group will run
To schedule a Vuser group select the ‘Schedule by Group’ option in the scenario builder to get the box as shown below
The Start Time Tab gives the time delay between the start of the Scenario and the start of the Group. The other three tabs have basically the same meaning as explained above for ‘Scheduling by Scenario’.
3.7 Rendezvous Point
Rendezvous points are used to cause multiple Vusers to perform tasks at exactly the same time, there by creating intense user load on the server.
The rendezvous point can be inserted at any point in the script before the transaction that you want to be performed under concurrent load.
From the Vugen menu go to Insert->Rendezvous in the box that comes up enter for the rendezvous point.
Setting the Rendezvous Policy
1. From the Controller menu choose Scenario->Rendezvous. The Rendezvous Information dialog box opens.
2. Select a rendezvous from the Rendezvous box, and click the Policy button.
3. In the Policy section, select one of the following three options;
• Release when X% of all Vusers arrive at the rendezvous
• Release when X% of all running Vusers arrive at the rendezvous
• Release when X Vusers arrive at rendezvous.
From the point of view of Maconomy we might need to measure some important transactions like Costing, Printing through rendezvous points.
The rendezvous points can be temporarily disabled/enabled from a scenario.
3.8 Starting the Scenario
Click on the start scenario button.
In the Run tab of Scenario you will be prompted to enter the path of the results directory as shown in the screen shot below
Enter any suitable path for the results directory. And click on OK. Once this is done the scenario will start executing.
The run tab of the scenario will look as below.
The vusers will move from Down->Pending->Init->Ready->Run state.
You can view information on Transaction Response Times, Number of Running vusers as the scenario runs. Any errors that come up during the run will be immediately highlighted as red against the errors field. (in the Scenario Status box). Trouble Shooting of commonly occurring errors will be explained later in the document. The errors that occurred during the execution of the scenario are stored in a mdb file in the results folder.
Clicking on the vusers button will give information on the status of each of the vusers whether they are initialising/running/passed/failed etc through the below window that comes up.
Clicking on the highlighted icon will give the execution log for the selected vuser as shown below.
Once the scenario has run fully all the vusers would have moved to the Passed/Failed/Error Status and there would be no vuser in running mode.
LOADRUNNER GENERAL PROBLEMS AND LIMITATION
Problem Description: The Controller uses up all the memory though no scenario is running.
Problem Description: The Controller stops responding if a load test scenario issues a high number of errors
Problem Description: How to send the Controller output information to a file instead of viewing it from Controller itself
Problem Description: Are past Execution logs from VuGen saved somewhere
Problem Description: How to enable logging in Controller and where are Vusers log files stored
Problem Description: How to change the Execution and Recording logs to collect different amounts of information
Problem Description: How to disable mdrv###.log files under Vuser hosts
Problem Description: How to enable logging in Controller and where are Vusers log files stored
Problem Description: Where are the results of the WinRunner scripts stored for the GUI Vusers
Problem Description: The output.mdb file is blank after executing a scenario
Problem Description: The Controller displays "Loading Data..." but the error text is not shown in the output window
Problem Description: Generator or Vuser or Show output or Error or Transaction window does not open in the Controller
Problem Description: How to stop Vusers so they exit directly rather than gradual exiting
Problem Description: How to renumber Vusers in LoadRunner 7.5 or above
Problem Description: How to refresh Vuser scripts in the Controller
Problem Description: How to remove the scripts that are listed in "Available Scripts"
Problem Description: How to initialize more than 50 Vusers at a time
Problem Description: Common connectivity problems between Controller and Generator
Problem Description: Error: "-29989: Process 'lr_bridge.exe' was not created..."
Problem Description: How to run a scenario from the command line (Controller's Command Line Arguments)
Problem Description: How to run a scenario at a specific (absolute) time
Problem Description: Setting scenario start time in LoadRunner does not work
Problem Description: Wlrun.exe does not close when executing a scenario via command line option
Problem Description: How to read in string/text content from the command line in the Controller
Problem Description: Running LR from the command line does not collate results from a remote machine
Problem Description: Running LR from the command line does not collate results from a remote machine
Problem Description: How to modify the heartbeat time-out
Problem Description: How to set the "Save as" directory opened by VuGen or Controller
Problem Description: Cannot connect to the host machine from the Controller
Problem Description: Can the user run multiple Controllers using a network installation
Problem Description: Can different versions of LoadRunner be used together in a scenario
Problem Description: How to enter a new license key for LoadRunner
Problem Description: Accessing the Output window in the Controller increases the size of output.mdb
Problem Description: Some Vusers do not wait for other Vusers at the rendezvous point
Problem Description: C++ run-time error when running a Scenario
Problem Description: Scenario scheduler does not ramp down at the specified time
Problem Description: How to show more than 20 measurements in the Controller online monitor
Problem ID: 26375
Problem Description: The Controller uses up all the memory though no scenario is running
The Controller seems to be utilizing all the memory resources. Without any scenario running, the user noticed that the memory utilization for wlrun.exe increase drastically.
Diagnosis:Some processes or services on the machine might be interfering with the normal Controller operation.
________________________________________
Solution: Identifying processes that might interfere with the Controller
To verify the processes or services that might interfere with the Controller, you can use the Process Viewer. This application helps to list all the DLLs that are loaded.
Apart from that, it has been observed that the following might interfere with wlrun.exe:
• VNC (Virtual Network Computing) client
• SPYWARE ( using software like Ad-Aware )
• ExeSpy2000
Problem ID: 21925
Problem Description: The Controller stops responding if a load test scenario issues a high number of errors
The LoadRunner Controller stops responding if a load test scenario issues a high number of errors during scenario execution.
________________________________________
Solution: Configure the Controller to write errors to a text file
By default, the Controller writes errors to an Access database (output.mdb, created in the scenario results).
Work-around:
Configure the Controller to write errors to a text file.
Problem ID: 15075
Problem Description: How to send the Controller output information to a file instead of viewing it from Controller itself
________________________________________
Solution: Set "ExportMessagesToFile" to 1 in wlrun7.ini
Starting with LoadRunner 7.5, the output window information is saved in output.mdb file under the resutls folder . To set LoadRunner to use a different database, you need to go to Analysis -> Tools -> Options -> Database and set the database default before running a scenario.
If you need to view the data using a text file, you will need to
1. Run the Controller once and shut it down to reset the configuration files
2. In order to set /unset the text file mode please open wlrun7.ini using a text editor. This file can be found in your systems WinNT folder, or in your accounts 'WINDOWS' directory. Simply do a quick search for this on your hard drive.
3. Go to the [output] section and set "ExportMessagesToFile" to 1. If you do not see this entry, add it as following
[output]
ExportMessagesToFile=1
Note:If these messages are not important and you cannot prevent them then you can block these messages by making the following change in the wlrun7.ini (Close the Controller before making these changes):
[output]
BlockOutputMessages=1
************************************************************************
Problem ID: 15827
Problem Description: Are past Execution logs from VuGen saved somewhere
The user executed several runs in VuGen, are all the Execution logs saved?
________________________________________
Solution: Only the most recent Execution log is saved as output.txt in the main script directory
Execution logs are saved in output.txt in the main script directory. However, it is always overwritten during each run in VuGen. You need to back up the output.txt file after each run in order to save each Execution log.
Problem ID: 17005
Problem Description: How to enable logging in Controller and where are Vusers log files stored
________________________________________
Solution: Set the Run-Time settings to 'Always send messages'
To turn on logging for the Vusers in the Controller
1. Go to the Run-Time settings
2. In the log tab, select "Always send messages"
3. You can set the log detail level as you wish
4. Run the script
To see the message on the log file:
1. The Controller if the scenario is still up.
a. Click on "Vusers" in the Controller.
b. Right-click on one of the Vusers.
c. Select "Show Vuser log."
2. The result folder.
a. Go to the result directory (the location is specified in the Controller's Result-> Result settings).
b. Go to the "log" folder.
c. All Vusers' log files are saved as GroupName_VuserID.log.
Problem ID: 11377
Problem Description: How to change the Execution and Recording logs to collect different amounts of information
________________________________________
Solution: Turn on "Full Trace Recording Log" from the Recording Option
For extended Recording log information, look at the Tools -> Recording Options -> Advanced tab, which will allow you to choose "Full Trace Recording Log" to enable additional data collection. This option is available with the 'Single Protocol' template only.
For the Execution log, you want to go to the Vuser -> Run-Time Settings Log tab, which has three options for the Execution Log:
• Parameter substition - Prints the values of the parameters in your script.
• Data returned by server - All the HTTP data returned by the server.
• Advanced Trace - Additional information about the requests being submitted by the client.
Generating all three debugging options when running the script is the preferred method for debugging script exection. The data returned by server is the largest amount of data, and as long as you generate that, you might as well get the other two for added information.
The Execution log records all the information that is passed from the client to the server. It is the definitive guide to the conversation between the two. When debugging replay, it is important to realize the limitations of the Run-Time Viewer and turn to the Execution log to debug replay. Two tricks to speed up execution when replaying with the Extended log enabled are
1. Turn of resource downloading in the Run-Time Settings.
This will prevent all the binary data from being printed into the exection log (it is usually pretty useless anyway).
2. Click on the Recording Log tab during replay so VuGen does not have to update the Execution log on screen.
If you turn on the Extended log, it will generate large log files. Ensure you have enough disk space on which to store these files. If running a scenario with the Extended log, remember there will be a log file for each Vuser. Not only will this be a lot of large log files, but the host machine will spend a lot of time writing log files and not running Vusers, so fewer can run with the given resources compaired to when logging is disabled. It is not recommended to run a scenario with Extended log turned on.
************************************************************************
Problem ID: 3962
Problem Description: How to disable mdrv###.log files under Vuser hosts
________________________________________
Solution: Use command line option
For Unix hosts:
1. Add the script as usual to the Controller
2. Click on 'details...'
3. Click on 'more'
4. On the 'Command line' option, add the following:
-drv_log_file /dev/null
For Windows hosts:
1. Add the script as usual to the Controller
2. Click on 'details...'
3. Click on 'more' 4. On the 'Command line' option, add the following:
-no_drv_log
************************************************************************
Problem ID: 17005
Problem Description: How to enable logging in Controller and where are Vusers log files stored
________________________________________
Solution: Set the Run-Time settings to 'Always send messages'
To turn on logging for the Vusers in the Controller
1. Go to the Run-Time settings
2. In the log tab, select "Always send messages"
3. You can set the log detail level as you wish
4. Run the script
To see the message on the log file:
1. The Controller if the scenario is still up.
a. Click on "Vusers" in the Controller.
b. Right-click on one of the Vusers.
c. Select "Show Vuser log."
2. The result folder.
a. Go to the result directory (the location is specified in the Controller's Result-> Result settings).
b. Go to the "log" folder.
c. All Vusers' log files are saved as GroupName_VuserID.log.
Problem ID: 14559
Problem Description: Where are the results of the WinRunner scripts stored for the GUI Vusers
Where are the test results of the WinRunner scripts stored for GUI Vusers and how are they archived?
________________________________________
Solution: The test results are in the Temp directory of the machine on which the script is to be run
When running a load test, LoadRunner FTPs the WinRunner script into the Temp directory of the machine on which the script is to be run. The WinRunner results will be on that machine in the Temp directory. You will need to look for the WinRunner test script folder, which should be the same as if you were running WinRunner by itself, and the test results will be in the script folder.
The hard part will be determining which folder in the Temp directory was created as LoadRunner creates the folder dynamically. Check the date stamps of the folders and choose the most recently created one.
The load test results are saved in the location specifed in the Controller.
Problem ID: 22040
Problem Description: The output.mdb file is blank after executing a scenario
After executing a scenario using LoadRunner 7.5, the user notices the output.mdb file is empty even though there were a lot of errors, warnings, or output messages while running the scenario.
Diagnosis: The size of the output.mdb file is limited to 400 KB. If there are a lot of messages in the scenario execution (i.e., exceeding 400 KB), it will set the file to 0 KB.
________________________________________
Solution: Apply Patch LR75P26 - LoadRunner 7.5 Controller Fixes an empty mdb after Scenario finished running
This is a know problem in LoadRunner 7.5 with output.mdb where file size limitation is 400 KB. You need to apply Patch LR75P26 (LoadRunner 7.5 Controller Fixes an empty mdb after Scenario finished running) from the Patches database (Downloads -> Patches -> LoadRunner -> 7.5 -> General -> LR75P26) on the Customer Support website
************************************************************************
Problem ID: 22334
Problem Description: The Controller displays "Loading Data..." but the error text is not shown in the output window
When trying to open the error window in the Controller, the window appears, but hangs with the message "Loading Data...."
________________________________________
Solution: Upgrade the MDAC version on the Controller machine
This problem has been reported for the following cases:
1. MDAC version
You can find the MDAC version on your machine from Microsoft Knowledge Base Article 301202 - HOW TO: Check for MDAC Version. Make sure that you have MDAC 2.6 or higher installed. You can get the latest MDAC version from Free Downloads.
2. "List separator" setting
If you have a non-English environment, the "list separator" option on the machine is most likely set to be a semicolon. Go to Start -> Settings -> Control Panel -> Regional options, and under the "Number" tab, change the "list separator" to be a comma.
************************************************************************
Problem ID: 15350
Problem Description: Generator or Vuser or Show output or Error or Transaction window does not open in the Controller
Clicking on the "Generator" or "Vuser" or "Show Output" or "Error" or "Passsed / Failed transaction" button in the Controller does not open the window.
Diagnosis:The initialization file for the Controller is corrupted.
________________________________________
Solution: Delete wlrun7.ini from the C:\winnt directory
1. Close the LoadRunner Controller.
2. Go to the C:\winnt (or C:\windows for windows XP )folder and delete the wlrun7.ini file.
3. Go to/bin folder and run OutputWindow.reg.
4. Reopen the Controller. The problematic windows should now open when you click on it.
Alternatively, if you do not wish to lose other settings, open wlrun7.ini in a text editor. Look for a section similar to:
[DockablePlace]
OUTPUT_FRAME_PLACE=113,846,587,1186,
TRANS_FRAME_PLACE=110,200,450,345
Simply replace the numeric values there, with the X coordinate of the window, its Y coordinate, width and height. "300,300,600,500," are usually reasonable values to start with. Then you need to save your scenario if necessary, and restart the Controller.
************************************************************************
Problem ID: 15390
Problem Description: How to stop Vusers so they exit directly rather than gradual exiting
________________________________________
Solution: Set the exit mode to "Stop immediately"
Open the Controller, click on the Run tab, and go to Tools -> Options -> Run-Time Settings. In the "When stopping Vusers" category, select "Stop immediately."
Problem ID: 15338
Problem Description: How to renumber Vusers in LoadRunner 7.5 or above
________________________________________
Solution: Renumber the Vusers in the "Run" screen
1. Go to the the Run screen of the Controller
2. Locate the "Group Name" column.
3. Right-click on the desired group name and select "Renumber."
Note: When you renumber the groups, the Vusers will change their IDs.
************************************************************************
Problem ID: 13604
Problem Description: How to refresh Vuser scripts in the Controller
After scripts have been modified in the VuGen, scripts in the Controller are not affected. How can the user make sure that updated scripts are being run?
________________________________________
Solution: Click on the "Refresh" button in Details
Go to the Design tab in the Controller and select one group. Click on Details, then click on the Refresh button. By doing this, the Controller will use the latest script in scenario. Follow the same procedure for all the groups in a scenario.
************************************************************************
Problem ID: 11297
Problem Description: How to remove the scripts that are listed in "Available Scripts"
How can the user remove the scripts that are listed in "Available Scripts" when creating a new scenario?
________________________________________
Solution: Delete the unwanted script entries from the registry
All recently accessed URL information is stored in the registry under HKEY_CURRENT_USER\Software\Mercury Interactive\RecentScripts.
To remove unwanted URL:
1. Go to Start -> Run and type in regedit to open the Registry Editor.
2. Open the HKEY_CURRENT_USER -> Software -> Mercury -> Recent Scripts folder. This lists all the files listed in the "Available Scripts" section when the Controller is launched.
3. Delete those entries you no longer want to appear.
Problem ID: 13349
Problem Description: How to initialize more than 50 Vusers at a time
During a scenario, the Controller will not allow more than 50 users to initialize at one time. This is in spite of the fact that the Vuser Quota for Initializations is set to 999 in the Controller's Tools -> Options menu.
________________________________________
Solution: The number of users that may be initialized is governed by two settings
The number of users that may be initialized at one time is governed by two settings. There is one overall setting that you can access under Tools -> Options -> Runtime Settings.
In addition to this, the initialization limit is also governed for each host machine.
1. Go to the Design Tab of the Controller.
2. Click on the "Generators" button. A new window will come up.
3. Bring up the Details of a generator.
4. Go to the Runtime Quota tab. This is where you will find an Initialization Limit for the host machine itself.
5. Set both limits accordingly.
Problem ID: 25162
Problem Description: Common connectivity problems between Controller and Generator
User is facing connectivity problems between Controller and Generator machines. The connection drops in middle of a scneario or can not connect to the Generator machine at all. LoadRunner returns the following eror :
Error: Load Generator failed.
Failed to connect - reason timeout.
Error -10343: Communication error: Failed to connect to remote host [server name: ]. (sys error message - ) [MsgId: MERR-10343]
Error -29989: Process "lr_bridge.exe" was not created on remote host "" ,reason - communication error. [MsgId: MERR-29989]
________________________________________
Solution: Troubleshooting a connectivity problem
Different problems can cause the above error. Some of the things you can verify include:
1. Make sure that you apply the same LoadRunner version and Service Pack on the Controller and Load Generator machines.
2. Make sure that you can ping the Controller and host machine bidirectionally. You may need to add the IP address and machine name on the host file:
a. Go to the host machine.
b. Navigate to C:\WINNT\system32\drivers\etc\.
c. Open the hosts file in a word editor.
d. At the end of the file, add another line with the IP address and machine name of the Controller machine.
Example:
111.111.111.111 MI_Controller
e. Repeat steps a - d for all the host machines.
f. Repeat steps a - d for the Controller machine, but adding the IP and machine name of the hosts machines.
3. Make sure that the LoadRunner Agent is running either as a process or a service on the remote host machine. Refer to Problem ID 10464- How to set LoadRunner Agent as a service or process after installation to do this.
4. Make sure the Controller and host are connected to the network. In some networks, the Microsoft LOOP back IP address 10.10.10.10 is used when a computer is not connected to the network. As a result, the Controller will not be able to detect the host machine. You will need to stop the loop back service, connect to the network, and make sure that the machine has a valid IP address.
5. If there are multiple network cards in the machines, please refer to Problem ID 11685 - Using LoadRunner with machines that have multiple NICs.
6. It might as well be possible that some network environment issue might be the cause and the network monitor can be used to diagnose the problem. Make sure that you are using the latest driver and firmware for your network cards and routers. Also try to force the network card to use 100Mbs/Full Duplex instead of the 'Detect automatically the best speed settings'. In case of miscommunication with the router or other network device the automatic settings could be set in an inappropriate way and have huge consecuencies on the network performances.
Problem ID: 11569
Problem Description: Error: "-29989: Process 'lr_bridge.exe' was not created..."
When trying to connect to a remote host using the hostname, the LoadRunner Controller gives the following error:
"- 29989: Process 'lr_bridge.exe' was not created on the remote host 'host_name', reason - communication error [msgId: MERR-29989]"
However, it is able to connect using the IP address.
________________________________________
Solution: Troubleshooting a connectivity problem
Different problems can cause the above error. Some of the things you can verify include:
1. Make sure that you apply the same LoadRunner version and Service Pack on the Controller and Load Generator machines.
2. Make sure that you can ping the Controller and host machine bidirectionally. You may need to add the IP address and machine name on the host file:
a. Go to the host machine.
b. Navigate to C:\WINNT\system32\drivers\etc\.
c. Open the hosts file in a word editor.
d. At the end of the file, add another line with the IP address and machine name of the Controller machine.
Example:
111.111.111.111 MI_Controller
e. Repeat steps a - d for all the host machines.
f. Repeat steps a - d for the Controller machine, but adding the IP and machine name of the hosts machines.
3. Make sure that the LoadRunner Agent is running either as a process or a service on the remote host machine. Refer to Problem ID 10464- How to set LoadRunner Agent as a service or process after installation to do this.
4. Make sure the Controller and host are connected to the network. In some networks, the Microsoft LOOP back IP address 10.10.10.10 is used when a computer is not connected to the network. As a result, the Controller will not be able to detect the host machine. You will need to stop the loop back service, connect to the network, and make sure that the machine has a valid IP address.
Problem ID: 13352
Problem Description: How to run a scenario from the command line (Controller's Command Line Arguments)
Is there a way to start the Controller via a Command Prompt?
Specifically, what arguments can be used to start the Controller, run an existing Scenario, shut down the Controller, and bring up the Analysis?
________________________________________
Solution: Command line arguments for the LoadRunner Controller
Note:
1. Make sure that the Controller is shut down before starting the scheduled task.
2. When running the Controller via the Command Line, Controller will be shut down automatically after the scenario ends.
Command line parameters are parameters that the Controller receives when it is invoked. They are used to instruct the Controller on how to behave. When invoked, the Controller checks all the received parameters and sets its startup environment accordingly. If no parameters are passed, the Controller uses its default settings.
By passing parameters in the command line, you may set the Controller and the scenario’s settings without the need to manually define them in the Controller UI. For example, you can instruct the Controller whether to connect to TestDirector on startup by using the ConnectToTD parameter, save the results to a directory other than that defined in the scenario by using the ResultName parameter, or invoke Analysis upon scenario termination with the InvokeAnalysis parameter.
The most common use of the Command Line is done by TestDirector. TestDirector includes a special program called "Test Run Scheduler," which was designed for scheduling the Controller to run scenarios at a specific date and time. It automatically invokes the Controller and runs scenarios. Results are saved in the TestDirector database. To do that, TestDirector must set the scenario’s environment by supplying the Controller with specific parameters.
Predefined rules:
• When one or more parameters are not passed, the Controller uses its default settings.
• Results will always be overwritten.
• The Controller will automatically terminate upon scenario termination and the results will be then collated.
• The Controller’s settings are loaded from wlrun5.ini located in the Windows directory.
• The following parameters are supported on all Windows 9x and Windows NT platforms.
Switches for LoadRunner/TestDirector integration:
• ConnectToTD - Should the Controller connect to TestDirector on startup (0/1 or ON/OFF).
• TDServer - TestDirector server name. Must be a computer name with TestDirector installed.
• TDDB - Database name. For example, "lrun."
• UserName - User name.
• Password - Password for the user name.
• TestPath - Path to scenario in the TestDirector database. For example, "[TD]\Subject\LoadRunner\Scenario1." If the path includes white spaces, use quotation marks.
• TestId – Test ID (for TestDirector only).
• ResultCleanName - For use with ResultCycle only, for example, "Res1."
• ResultCycle - TestDirector cycle, for example, "LR_60_SP1_247." To define the results path in TestDirector, the Controller must be provided with two parameters: ResultCycle and ResultCleanName.
Run-Time Switches:
• Run – Runs scenario, dumps all output messages into res_dir\output.txt and closes the Controller.
• InvokeAnalysis - InvokeAnalysis will set a flag in the Controller, which will invoke Analysis upon scenario termination (If not used, the scenario value will be taken).
Results Switches (for File System):
• ResultName - Full results path, for example, "C:\Temp\Res_01."
• ResultCleanName - Results name, for example, "Res_01."
• ResultLocation - Results directory. For example, "C:\Temp".
• Note:
o If the scenario does not specify a results directory and one of the above parameters was not passed, the scenario will not run!
o The results will always be automatically collated upon scenario termination.
o The results will always be automatically overwritten.
Command Line Syntax examples:
• Wlrun.exe –TestPath C:\Temp\Scenario1.lrs -ResultName C:\Temp\Res1 –Run –InvokeAnalysis
• Wlrun.exe –TestPath C:\Temp\Scenario1.lrs –ResultLocation C:\Temp –ResultCleanName Res1 –Run
• Wlrun.exe –ConnectToTD on –TDServer localhost –TDDB lrun –UserName yaniv18 –Passwordb#12GcSA –TestPath "[TD]\Subject\Trash for LR/TD Integration\Scenario1" –Run
• Wlrun.exe –ConnectToTD 1 –TestPath "[TD]\Subject\Trash for LR/TD Integration\Scenario1"
5. If there are multiple network cards in the machines, please refer to Problem ID 11685 - Using LoadRunner with machines that have multiple NICs.
6. It might as well be possible that some network environment issue might be the cause and the network monitor can be used to diagnose the problem. Make sure that you are using the latest driver and firmware for your network cards and routers. Also try to force the network card to use 100Mbs/Full Duplex instead of the 'Detect automatically the best speed settings'. In case of miscommunication with the router or other network device the automatic settings could be set in an inappropriate way and have huge consecuencies on the network performances.
Problem ID: 2782
Problem Description: How to run a scenario at a specific (absolute) time
How can the user execute a scenario at a specific (absolute) time in the day (e.g., 8pm) instead of using a relative "time from now."
________________________________________
Solution: Use scenario scheduler of Controller or Windows Scheduler
Using Scenario Scheduler of Controller:
1. Open the scenario in the Controller.
2. Go to Design Tab -> Edit Schedule -> Scenario Start time and set the time when you want to start the scenario.
3. You need to click on Start Scenario button so that the Controller can trigger the scenario once the start time comes up.
Using Windows Scheduler:
Scenario Scheduler of Controller is limited to the effect that it can only be sheduled to be run at one time. In order to re-run it the scenario has to be edited again. Instead, you can do the following:
1. You can have the scenario run from command line in a batch file as per Problem ID 13352 - How to run a scenario from the command line(Controller's Command Line Arguments).
2. Then you schedule this batch file to run at different times from the Windows Scheduler.
Problem ID: 15478
Problem Description: Setting scenario start time in LoadRunner does not work
In the LoadRunner Controller, under Scenario menu -> Start time, the scenario start time is set to a specific time. However, the LoadRunner scenario does not start at the set time.
________________________________________
Solution: Click on "Start Scenario"
After setting up the scenario start time, click on the "Start Scenario" button in the Controller. A pop-up menu will come up showing the count down to the start time the scenario.
Problem ID: 15717
Problem Description: Wlrun.exe does not close when executing a scenario via command line option
When executing a scenario via the command line option
wlrun -TestPath D:\temp\testscenario.lrs -ResultName "D:\temp\res" -Run
even if the Controller GUI interface has disappeared, wlrun.exe seems to continue to run for sometime.
________________________________________
Solution: Wlrun.exe shuts down after a delay
Depending on the scenario setting and results, wlrun.exe might take a longer time to shut down. There have been cases seen where wlrun.exe shutdowns 5-10 minutes after the Controller GUI interface disappears.
************************************************************************
Problem ID: 9277
Problem Description: How to read in string/text content from the command line in the Controller
How can the user get string or text information from the command line?
Example:
Command line parameter: -host
Value : server
This command line is entered as -host server in the Controller's command line text box. How can the user capture the value "server" and use it as a string in the script?
________________________________________
Solution: Use lr_save_string(lr_get_attrib_string("host"), "server");
You can capture the value for "server" using the lr_get_attrib_string() function.
Example:
lr_save_string(lr_get_attrib_string("host"), "server");
The lr_get_attrib_string() function will capture the string "server" from the command line, and the lr_save_string() function will insert the value into a parameter called [server].
Problem ID: 22476
Problem Description: Running LR from the command line does not collate results from a remote machine
LoadRunner is not collating the results from a remote Load Generator machine when running from the command line.
Note:
The user is running LoadRunner 7.51 SP1.
________________________________________
Solution: Contact Customer Support for Patch LR751SP1P17
Please contact Mercury Customer Support for Patch LR751SP1P17 - LoadRunner 7.51 SP1 Fixes several bugs in launching Controller through command line.
Problem ID: 16855
Problem Description: How to modify the heartbeat time-out
When starting a scenario and connecting to the remote host, the Controller machine's CPU reaches 100% and its user interface freezes.
Diagnosis: This could happen if there are a lot of remote hosts (several hundreds) or when there are large data files to be transferred.
________________________________________
Solution: Minimize heartbeat frequency so the hosts will send less heartbeat messages to the Controller
In LoadRunner, all hosts manage heartbeat mechanisms with the Controller. By default, each host sends four messages in two minutes with frequency of 30 seconds until heartbeat failure is reached. This could cause a problem when there are a lot of hosts or large data files.
To work around the issue, you need to minimize the heartbeat frequency so that the hosts will send less heartbeat messages to the Controller. Since LoadRunner waits time-out*4 before it reaches heartbeat failure, you can increase the time-out value of the Controller and Load Generator machines (so as to minimize the frequency) or minimize the heartbeat messages.
To minimize the heartbeat messages:
1. Close the Controller, and stop the LoadRunner Agent process/service.
2. Modify the mdrv.dat file in the\dat directory.
3. Add the following lines to the end of [Launcher] section:
ExtCmdLine= -HB_TIMEOUT //to modify timeout
ExtCmdLine= -HB_TIMEOUT_LIMIT //to modify the number of messages
Example:
[Launcher] ExtPriorityType=launcher WINNT_EXT_LIBS=launcher.dll WIN95_EXT_LIBS=launcher.dll LINUX_EXT_LIBS=liblauncher.so SOLARIS_EXT_LIBS=liblauncher.so HPUX_EXT_LIBS=liblauncher.sl AIX_EXT_LIBS=liblauncher.so LibCfgFunc=launchext_configure UtilityExt=two_way_comm ExtMessageQueue=0 SecurityMode=On ExtCmdLine= -HB_TIMEOUT 120000 ExtCmdLine= -HB_TIMEOUT_LIMIT 5
Note:
• The "-HB_TIMEOUT 120000" option sets the time-out to send heartbeat messages every 120 seconds.
• The "=-HB_TIMEOUT_LIMIT 5" option sets the number of times to resend heartbeat messages to 5.
4. Repeat steps 2-3 for the mdrv.dat file in\launch_service\dat directory of the Load Generator machine.
Note:
If you change the heartbeat to be every 2 minutes, the Controller will be able to establish a connection, however since the hosts still send heartbeat messages it cause the UI to get stuck every 2 minutes for half minute.
Problem ID: 3709
Problem Description: How to set the "Save as" directory opened by VuGen or Controller
When doing a "Save as," is it possible to specify which directory is brought up by default in VuGen and the Controller?
________________________________________
Solution: Defining the default directory for VuGen and the Controller
To change the default directory that comes up, modify the following file entries:
For VuGen
In the "vugen.ini" file located in the WinNT directory.
[General]
LastScriptPath=D:\TEMP\scriptname
For the Controller
In the WinNT directory, there is the configuration file for the Controller. It is called wlrunX.ini where X is a number that changes depending on the version of the Controller used. For LoadRunner 6.x, the file is called wlrun5.ini. For LoadRunner 7.x and higher it is wlrun7.ini.
[General]
DefaultScenarioDir=D:\TEMP\scenario_name.lrs
Problem ID: 10315
Problem Description: Cannot connect to the host machine from the Controller
Diagnosis: AOL is installed on the machine.
________________________________________
Solution: Cannot have AOL and the Controller on the same machine
LoadRunner conflicts with AOL. You cannot use AOL and the Controller on the same machine.
Here is the work-around that you can try:
Steps to disable "AOL - WAN Network Driver"
1. Right-click on the "My network places" icon on the desktop, then click on "Properties."
2. Right-click on "Local Area Connection" (for AOL), then click on "Disable."
3. Only after this, try to launch the Controller and connect.
Problem ID: 17845
Problem Description: Can the user run multiple Controllers using a network installation
How does a network installation work? Is it possible to access the Controller from multiple workstations if a network installation is done on the server and workstation installation is done on each individual workstation?
________________________________________
Solution: Purchase multiple Controller licenses to run multiple Controllers
Network installations allow for installing all the setup files for various LoadRunner components on a shared network drive of a server. A corresponding workstation installation will create LoadRunner program group on each workstation. This will aid in saving lots of disk space on the local machine and a global update facility for any kind of patches and upgrades. However, the Controller workstation has to be pre-determined as a license needs to be installed on the local workstation only and not on the shared network drive of the server where network installation is done. This means Controller is still a single workstation and will not be running on all workstations. You need to purchase multiple Controller licenses to run multiple Controllers.
Problem ID: 11422
Problem Description: Can different versions of LoadRunner be used together in a scenario
Can different versions of LoadRunner be used together in the same scenario?
Example:
Controller Version: LoadRunner 7.5
Host Version: LoadRunner 7.51
________________________________________
Solution: The same version of LoadRunner must be on all machines in a scenario
Because the communications protocol is constantly being updated between versions (even minor versions), you have to ensure that all machines being used are on the exact same version of LoadRunner. This goes for any patches installed as well.
Example:
If the Controller is on LoadRunner 7.51 with xxx patch, the hosts have to be on LoadRunner 7.51 with xxx patch.
Problem ID: 11369
Problem Description: How to enter a new license key for LoadRunner
How to enter the new license key in LoadRunner when LoadRunner is already installed.
________________________________________
Solution: Steps to add a new license when LoadRunner is already installed
Follow the steps below to add/update LoadRunner license key on an existing install:
For LoadRunner 8.1:
1. Close the Controller
2. Go to Start -> Programs -> LoadRunner -> LoadRunner -> Configuration
3. Click on the "License" menu
4. Click on "New License" and type in the new license key
5. Click, and to close the window
6. Bring up the Controller again.
For LoadRunner 8.0:
1. Close the Controller
2. Go to Start -> Programs -> LoadRunner -> LoadRunner
3. Click on the "License" menu
4. Click on "New License" and type in the new license key
5. Click, and to close the window
6. Bring up the Controller again.
For LoadRunner7.0 - 7.8 Feature Pack1
1. Bring up the Controller and go to Help -> About LoadRunner.
2. Click on "New License" and type in the new license key.
3. Click.
4. Close the Controller and restart it; the new license key will be in effect
Problem ID: 23086
Problem Description: How to configure the Controller to open different versions of Analysis
The Analysis tool can be launched directly from the Controller by clicking on Tools -> Analysis. How can the user configure the Controller so it launches a different version of Analysis tool installed on the same machine as a stand-alone component?
________________________________________
Solution: Configure AnalysisPath in wlrun7.ini to point to the desired path
1. Go to the C:\Winnt directory and open the wlrun7.ini file.
2. Find the [Tools] section.
3. Add or modify the AnalysisPath entry so that it points to the desired installation of Analysis.
Example:
[Tools]
AutoAnalysis=0
AnalysisPath=\bin\analysisui.exe
Problem ID: 24730
Problem Description: Accessing the Output window in the Controller increases the size of output.mdb
Accessing the Output window in the Controller increases the size of output.mdb in the result folder.
Example:
The user ran a scenario that output x number of messages. If the user does not access the output window in the Controller during scenario execution, the size of output.mdb is relatively small. However, if the user accesses the output window, the size of output.mdb could double or triple in size.
Diagnosis:The MS Access database (.mdb) is updated each time the Output window is accessed. If the user accesses the output.mdb file after the scenario, he will see that MS Access actually creates new views and temporary tables to display the data while he accesses the Output window. The temprorary views and tables is the cause of the size differences.
________________________________________
Solution: Compact and repair the database
To reduce the size of output.mdb so that it is the same with a scenario where the Output window in the Controller was not accessed, you need to compact and repair the database.
1. Open the output.mdb file in MS Access 2000 or MS Access 97 .
2. Go to Tools -> Database Utilities -> Compact and Repair Database.
For LoadRunner 7.51 SP 1 or above, there is an option to print output messages to a text file instead of the Access database. For further information, refer to Problem ID 15075 - How to send the Controller output information to a file instead of viewing it from Controller itself.
************************************************************************
Problem ID: 16965
Problem Description: Some Vusers do not wait for other Vusers at the rendezvous point
The user created a script with a rendezvous point set. When replaying it in the Controller, the Vusers do not wait for other Vusers. LoadRunner Vusers sometime exit the rendezvous point even though not all Vusers have arrived.
________________________________________
Solution: Increase the timeout between Vusers
The LoadRunner rendezvous point will timeout after 30 seconds by default. This means the Vusers will continue running if either of the following conditions apply:
• All the users have reached the rendezvous point, or
• 30 seconds has passed.
If you would like to change the conditions, so that Vusers exit the rendezvous point only when 100% of the Vusers reach the rendezvous point, do the following:
1. In the Scenario, go to Scenario -> Rendezvous.
2. Highlight the rendezvous name and select "Policy."
3. Select the relevant settings, and verify that you increased the timeout (so that timeout will not occur).
Again, you need to set the value for timeout between Vusers to be high enough so that timeout will not happen before all Vusers reach the rendezvous point.
Problem ID: 16971
Problem Description: C++ run-time error when running a Scenario
When trying to run a scenario, the following error comes up as a pop-up window:
"Assertion failed!
Program:....s\Mercury Interactive\LoadRunner\bin\wlrun.exe
File:S:\EventServer03\nt\app\EsDll\ESEngin.cpp
Line:90
Expression: Gran>=1"
Diagnosis:This error might appear if there is a problem with the LoadRunner installation.
________________________________________
Solution: Verify the LoadRunner installation
There are many reasons that can lead to the problem above. Things you can verify includes:
1. Make sure that LoadRunner was installed with a local administrator account.
2. Verify that you are logged into the machine as the local administrator.
3. Go to C:\winnt folder and delete: wlrun.ini, wlrun5.ini and wlrun7.ini.
4. Go to\bin folder and run register_controller.bat.
5. The assertion errors can also occur due to a corrupted scenario. If you are using saved scenario file, try to create a new scenario and run the test.
Problem ID: 17136
Problem Description: Scenario scheduler does not ramp down at the specified time
After setting up a schedule for LoadRunner Vusers to ramp up and ramp down after certain duration, the scenario does not stop at the specified time.
________________________________________
Solution: Verify the Vuser stop behavior
The Vuser stop behavior will affect the time when the scenario ends. To verify the Vuser stop behavior:
1. From Controller, go to Tools -> Options -> Run-Time Settings
2. The available stop options include:
a. Wait for the current iteration to end before stopping
b. Wait for the current action to end before stopping
c. Stop Immediately
Install Patch LR75P22 scheduler ramp
Problem ID: 26817
Problem Description: How to show more than 20 measurements in the Controller online monitor
By default, the Controller online monitor only shows 20 measurements for each graph. Additional measurements enabled will be in the "hidden" option. Is there any way to increase this?
________________________________________
Solution: Modify the value of MaxDispMeasurments
You can enable the Controller online monitor to display more than 20 measurements for selected categories of graphs.
Example:
• System Resource Graphs
• Runtime Graphs
• Transaction Graphs
• Web Resource Graphs
• Streaming Media
To display more than 20 measurements:
1. Go to the\dat\online_graphs directory.
2. Open the relevant .def files using word editor:
System Resource Graphs - online_resource_graphs.rmd
Runtime Graphs - online_runtime_graphs.def
Transaction Graphs - online_transaction_graphs.def
Web Resource Graphs - online_web_graphs.def
Streaming Media - online_web_graphs_mms.def
3. Locate the monitor for which you want to display more than 20 measurements.
4. Modify the value of MaxDispMeasurments=.
Example:
To display 30 Measurements for the Windows Resources Monitor:
1. Open online_resource_graphs.rmd from\dat\online_graphs.
2. Locate the ;--- Windows Resources --- section.
3. Change the value of MaxDispMeasurments= to 30.
Example:
MaxDispMeasurments=30
Modify the value of MaxDispMeasurments 1-14689s
5. Suggested debugging steps if Controller crashes
Make sure that you login as a local administrator
Login to the Controller machine with a local administrator account. Currently, Mercury do not support running Controller using a domain account. Using domain account may cause unexpected behaviors.
Make sure that there are sufficient Disk Space
Make sure that you have enough disk space available on the controller and load generators. During scenario execution, the events are written onto the Load Generator machines and are saved locally until the scenario finished; where results are send back to the Controller. If the machine does not have enough disk space, it can cause problem.
Check if the size of the output.mdb file in the results folder is more than 2 GB
If the output.mdb file becomes greater than 2GB during a load test, Controller is unable to write into it anymore and cause a crash. If the size of output.mdb file is larger than 2 GB, divert the output to a text file as per Problem ID 15075 - How to send the Controller output information to a file instead of viewing it from Controller itself
Run the Controller’s batch files to register DLLs
Sometimes, DLLs can become unregistered or the registry can become corrupted to a point where a program's DLLs cannot be found. The purpose of batch files is to reregister them into the system's registry so that the programs can locate them. Use the following steps to do this:
1. Shut down the Controller.
2. Navigate to the\bin directory, and look for the following files:
• register_controller.bat
• set_mon.bat
3. Create a duplicate copy of the file, in the same location.
4. Open up the duplicated file. In it, you should see several entries like the following:
regsvr32 /s webbrwsr.dll
Remove the "/s" from each of these statements, but leave a space between the "regsvr32" and the DLL name.
5. Save the changes.
6. Double click on the batch file to run it. You should get several pop-up messages similar to the following:
Note: You could get failure messages for escomps.dll and resmonps.dll. You can safely igonore these errors. But you should not get any other failure messages. If you do, then that DLL is the problem file. Try registering this from the command prompt:
Example: regsvr32 < LoadRunner >\bin\
If this does not work, try copying the DLL from the CD or ask support for the DLL to try registering it manually. Retry the same action that caused the error.
Verify the CPU usage on the machine
Verify the CPU usage on the machines. Ideally, they should be below 80% usages. If necessary, distribute the Vuser load to other machines.
Try to recreate the Controller’s initialization file
Sometimes, the initialization files can become corrupted (e.g. after a crashed). You will have problem in launching or using the Controller after that. Use the following steps to do delete the initialization file so that a new copy will be created:
1. Shut the Controller.
2. Navigate to the C:\Winnt ( or C:\Windows for Windows XP machine )
3. Delete all files that begin with wlrun*. For example,
wlrun.ini, wlrun5.ini, wlrun7.dft, wlrun7.hst, wlrun7.ini
Check the temporary environment variables
Unlike the earlier window’s versions, Window 2000 and Window XP have the default environment set to c:\Document and Settings\\Local Settings\Temp instead of c:\Windows\temp. This long path with a space can cause several problems on LoadRunner. To resolve the issue, change to a directory without empty spaces. For further information, please refer to Problem ID 15500 - How to set the system's TEMP and TMP directories.
Verify if Hyper Threading is enabled
Verify if Hyper Threading is enabled. If so, you will need to disable it. LoadRunner does NOT support Intel Hyper-Threading technology. Hyper-Threading can be disabled in the BIOS. For more information, refer to
http://www.microsoft.com/windows2000/docs/hyperthreading.doc.
Verify the MDAC version
Make sure that you have MDAC 2.6 or higher installed. You can find the MDAC version on your machine by referring to the information on Microsoft Knowledge Base Article 301202 - HOW TO: Check for MDAC Version. You can download the latest MDAC version from MDAC Downloads
Reboot
When programs crash, they leave the system in an unstable state. This can cause many other problems that seem to have no apparent reason for happening or has not happened before. When the system is rebooted, it resets the system into a more stable state. This should be done after any program crashes.
Verify the information in the event viewer
Sometimes, if a program crashes, it does not give any clues for what had happened. By using the Windows event viewer, it may be possible to find some clue as to what happened when the crash occurred. The event viewer can be launched from Start Programs Administrative Tools Event Viewer.
Verify other programs are interfering with Controller
To find out whether hooked DLLs are possibly causing a problem, you can use a third party utility call "Process Explorer." This utility has the ability to view the DLLs loaded by an application. It can be downloaded free of charge from the following link:
http://www.sysinternals.com/ntw2k/freeware/procexp.shtml
This can be used to see if LoadRunner loaded any other program's DLLs. Use the following steps to do this:
1. Unzip the .zip file, which was downloaded from the above URL, into a directory where you wish to install Process Explorer.
2. Start the Controller.
3. Run the Process Explorer (procexp.exe) from the directory into which you unzipped it (step a).
4. Select wlrun.exe (Controller) from the top section of Process Explorer.
5. The bottom section should be displaying a list of DLLs. If it is showing handles for the application, go to the "View" menu and select "DLLs." It should look like the screenshot below:
6. Search through the list to see if any other program's DLLs are loaded. Normally, only DLLs from the\bin directory and standard Microsoft directories are loaded. For example, if you see wbhook32.dll (McAfee VirusScan hooking DLL) loaded by LoadRunner, then you would want to shut down the anti-virus software.
Shut down all unnecessary processes
Some programs are designed to have certain DLLs "hook" or be loaded into another program's memory space. Normally, this should not have any effect on the application itself. However, it can interfere with some programs and cause them to behave erratically or crash. (Verify if there are other programs that interfering with Controller )
For such, it would be recommended to shut down all processes that are not necessary, regardless if they hook into LoadRunner or not. Any programs that run as an icon in the system tray or on the taskbar are the first candidates for termination. Also, you can look through the list of processes in the Task Manager (right-click on the taskbar and select "Task Manager"). Some processes are system processes, which may not be able to be shut off, but any processes that can be shut down should be.
Disable anti-virus software
It is known that anti-virus software is intrusive when they are set to look for viruses. However, in searching for viruses, the software can interfere with a program's proper execution. This could cause problems and sometimes crashes. This is why, for debugging purposes, we would recommend turning off the anti-virus software.
The icon for the anti-virus software resides in the system tray (where the clock is located). Normally, you should be able to right-click on the icon and select "disable." However, some setups do not allow a user to turn off the anti-virus software. It is recommended to speak to a system administrator to get the anti-virus program disabled for a short period for debugging the problem.
(Verify if there are other programs that interfering with Controller )
Reinstall
In case that all the above steps fail, the only recourse left would be to try to uninstall LoadRunner. It is possible that either a previous version of LoadRunner was on the machine before the current installation or that the installation did not go properly although the installation did not give any errors. It is recommended that a full uninstall be done in this case. The following steps are for a full uninstall:
1. Make sure that, all running LoadRunner processes (including the Controller, VuGen, Analysis and the Remote Command Launcher (for 6.x) or the LoadRunner Agent Process/Service (for 7.x) are closed.
2. Backup any existing scripts that may have been saved in the LoadRunner installation folder (The scripts are sometimes saved in a 'scripts' subdirectory under the LoadRunner installation folder.).
3. Run the uninstall program from the LoadRunner program group (or) use the Windows add/remove programs from the Control Panel. If any prompt is given about removing shared files, remove all the shared dlls that are reported as no longer being in use. In the very rare instance this causes a problem for some other application it may be necessary to re-install that other app. This is not generally a problem because every application should have registered which DLLs it needs to run.
4. Reboot the machine after the Uninstall wizard is complete. This will complete the basic uninstall procedure.
5. Delete all LoadRunner Folders. (Including the ones in the start up menu for Remote Command Launcher (LoadRunner 6.x) or Agent Process (LoadRunner 7.x)
6. If the installation is LoadRunner 6.x then delete the Borland Folder (Usually in c:\Borland or c:\BDE).
7. Do a search for the following files and remove them from all locations -- they will be replaced during the re-install.
a. wlrun.*
b. vugen.*
8. Bring up the registry editor: (Start Run regedit).
9. Delete the following keys:
a. Only for LoadRunner 6.x
HKEY_LOCAL_MACHINE\SOFTWARE\BORLAND
b. If Load Runner is the only Mercury Interactive product on this machine, then delete
HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive.
HKEY_CURRENT_USER\SOFTWARE\Mercury Interactive.
c. Else delete
HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive\LoadRunner.
HKEY_CURRENT_USER\SOFTWARE\Mercury Interactive\LoadRunner.
10. Empty the Recycle-bin.
After you remove these items, you can re-install LoadRunner. Also, make sure that you do not have any anti-virus programs running while you are installing LoadRunner. That has been known to cause some problems with the installation of LoadRunner.
NOTE: Reinstallation should only be done for the following certain circumstances.
1. The crash only happens on a particular machine.
2. Some feature that was previously working is now crashing.
3. The above options were tried before hand.
Modify the heartbeat timeout
In LoadRunner, all hosts manage heartbeat mechanisms with the Controller. By default, each host sends four messages in two minutes with frequency of 30 seconds until heartbeat failure is reached. This could cause a problem when there are a lot of hosts or large data files.
To work around the issue, you need to minimize the heartbeat frequency so that the hosts will send less heartbeat messages to the Controller. Since LoadRunner waits time-out*4 before it reaches heartbeat failure, you can increase the time-out value of the Controller and Load Generator machines (so as to minimize the frequency) or minimize the heartbeat messages.
To minimize the heartbeat messages:
1. Close the Controller, and stop the LoadRunner Agent process/service.
2. Modify the mdrv.dat file in the\dat directory.
3. Add the following lines to the end of [Launcher] section:
ExtCmdLine= -HB_TIMEOUT //to modify timeout
ExtCmdLine= -HB_TIMEOUT_LIMIT //to modify the number of messages
Example:
[Launcher] ExtPriorityType=launcher WINNT_EXT_LIBS=launcher.dll WIN95_EXT_LIBS=launcher.dll LINUX_EXT_LIBS=liblauncher.so SOLARIS_EXT_LIBS=liblauncher.so HPUX_EXT_LIBS=liblauncher.sl AIX_EXT_LIBS=liblauncher.so LibCfgFunc=launchext_configure UtilityExt=two_way_comm ExtMessageQueue=0 SecurityMode=On ExtCmdLine= -HB_TIMEOUT 120000 ExtCmdLine= -HB_TIMEOUT_LIMIT 5
Note:
• The "-HB_TIMEOUT 120000" option sets the time-out to send heartbeat messages every 120 seconds.
• The "=-HB_TIMEOUT_LIMIT 5" option sets the number of times to resend heartbeat messages to 5.
4. Repeat steps 2-3 for the mdrv.dat file in\launch_service\dat directory of the Load Generator machine.
Note:
If you change the heartbeat to be every 2 minutes, the Controller will be able to establish a connection, however since the hosts still send heartbeat messages it cause the UI to get stuck every 2 minutes for half minute.
Make sure that there are sufficient memory available
To check available memory on a machine:
Right-click the status bar, and select Task Manager. Select the Performance tab to check the physical memory available. Select the Processes tab to check which processes have high memory consumption in the CPU column.
To free up memory:
• Close any unnecessary processes running on the machine, and try running the scenario again.
• Restart your computer.
• If the problem persists, reduce the number of virtual users that you are running on the same machine.
To enlarge the size of your virtual memory:
1. Click Start -> Settings -> Control Panel -> System.
a. For Windows 2000, select the Advanced tab, and click Performance Options.
b. For Windows NT, select the Performance tab.
2. In the Virtual memory section, click Change.
3. In the Drive list, click the drive that contains the paging file you want to change.
Under Paging file size for selected drive, type a new paging file size in megabytes in the Maximum size (MB) box, and then click Set.
To boost performance, and allow more Virtual Users to run on the load generator machine:
• On Windows 2000 machines, select Start -> Settings -> Control Panel -> System -> Advanced -> Performance Options, and select the Background Services option.
On Windows NT machines, select Start -> Settings -> Control Panel -> System Properties > Application Performance. S
2.1 What is the Purpose of Load Runner?
LoadRunner is used to create a load or stress on a system, and can be used to measure the responsiveness of the system to that load. The key concept behind LoadRunner is the use of virtual users, or vusers. To perform a load test, a system needs many users to access the system concurrently, often one hundred or more. Performing such a test with people is a logistical nightmare. LoadRunner overcomes this problem through the use of vusers.LoadRunner is a Testing Tool used for Testing the Performance of an application by emulating an environment in which multiple users work concurrently. LoadRunner will apply load on the application and Test Maximum Load an application can support. While the application is under load, LoadRunner accurately measures, monitors and analyzes a system’s performance and functionality.
2.2 The components of the LoadRunner.
1. VirtualUserGenerator
The virtual user generator is used to generate scripts for all non-GUI vusers. The virtual user generator records the behavior of the client software, and automatically generates a script that can be used by the controller to run vusers.
2. Controller
Once vuser scripts have been created, they can be added into the controller in varying quantities to produce the demand on the system that is required.
3. Analyzer
The load analyzer utility presents the results of running a scenario in a variety of graphical and tabular forms. These graphs and tables can be used to determine the acceptability of a system, and to determine areas of concern.
2.3 What is the Sequence to use LoadRunner?
Creating Vusers Scripts.
Here, we create Vuser scripts that contain tasks performed by each Vuser, tasks performed by Vusers as a whole, and tasks measured as transactions by using VirtualUserGenerator.
Creating the scenario.
A scenario describes the events that occur during a testing session. It includes a list of machines, scripts, and Vusers that run during the scenario. We create scenarios using LoadRunner Controller. We can create manual scenarios as well as goal-oriented scenarios. In manual scenarios, we define the number of Vusers, the load generator machines, and percentage of Vusers to be assigned to each script. For web tests, we may create a goal-oriented scenario where we define the goal that our test has to achieve. LoadRunner automatically builds a scenario for us.
Running the scenario.
We emulate load on the server by instructing multiple Vusers to perform tasks simultaneously. Before the testing, we set the scenario configuration and scheduling. We can run the entire scenario, Vuser groups, or individual Vusers.
Monitoring the scenario.
We monitor scenario execution using the LoadRunner online runtime, transaction, system resource, Web resource, Web server resource, Web application server resource, database server resource, network delay, streaming media resource, firewall server resource, ERP server resource, and Java performance monitors.
Analyzing test results.
During scenario execution, LoadRunner records the performance of the application under different loads. We use LoadRunner’s graphs and reports to analyze the application’s performance.
3. CONTROLLER
3.1 About controller
More than one Vuser can be tested using the Load runner Controller. Controller will execute the scenarios .It will make hundred of vusers running in the single system.
3.2 Procedure for creation of scenario in controller.
LoadRunner Controller is used to manage and maintain scenarios (events that occur during each testing session).
To run a scenario
1. Start->Programs->Mercury LoadRunner->Applications-> Controller
By default the controller opens with the NewScenerio dialog box. If it does not open on startup you can open it by choosing File->New.
2. You can select one of two methods to create a scenario: Manual Scenario or Goal-Oriented Scenario. In a manual scenario, you create the scenario yourself by defining the number of Vuser groups you want to run, and building a schedule for LoadRunner to run these groups. You can also create a manual scenario by defining the total number of users to be used in the scenario, and assigning a percentage of the total number of Vusers to each script. If you want to create a scenario using the Percentage Mode, select Use the Percentage Mode to distribute the Vusers among the scripts.In a goal-oriented scenario, you define the goals you want your test to achieve, and LoadRunner automatically builds a scenario for you, based on these goals.
3. Select the script you want to run the scenario.
4. In Design view give the Quantity (No of vusers) and Click editschedule button and set the settings according to the requirements.
The Load Runner Controller enables the creation of scenario which are of two types:
Manual Scenario
You build a manual scenario by creating groups and specifying the script, the load generator, and the number of Vusers included in each group.
When the Load Runner is launched the above screen comes up. Scripts can be added to the scenario by clicking on the Add Button. The other buttons are self-explanatory and for their explanation please refer to the LoadRunner Controller Users Guide Chapter 5.
Manual Scenario Design Tab
The Scenario Schedule Pane describes the Schedule Name, Mode, Scenario Duration and Load Behaviour. These will be described in greater detail in the section on scheduling a scenario.
The Scenario Groups pane lists all enabled and disabled Vuser groups, their paths,the load generator machines, and the number of Vusers assigned to each group.
3.3 Configuring runtime settings
The configurations of settings that have been used for Maconomy Load Testing are:
Run Logic: the number of iterations decided on the scenario
Pacing: As soon as the previous iteration ends.
Log: The messages should generally be logged at the level of Standard Log. However Extended Logging can be enabled when doing some investigation into a problem especially for sending Result Files to mercury for their investigation. But for the purpose of performance testing Extended Logging should never be enabled as it will adversely affect the results.
Think Time: This should generally be as Replay Think Time, Use Random percentage of recorded think time(50%to 150% ) and Limit Think time to 5 seconds. These are no hard and fast values and can be changed if considered suitable.
Miscellaneous: Use default.
Speed Simulation: Use default
Browser Emulation: Use default
Proxy: No proxy (default condition)
Preferences: Use default except for Advanced Options. Click on options button. In the Advanced Options box select change the following:
HTTP-request connection timeout (sec) to 1000 seconds
HTTP-request receive timeout (sec) to 1000 seconds
Step download timeout (sec) to 1000 seconds
Content Check: Use default.
3.4 Configuration of Load Generator
Clicking on the Generator tab opens up a box as shown below:
The load generator, which actually generates the load, is installed on a machine which is separate from Controller. So the name or the IP address of the machine needs to be added against the script as shown in the Scenario Groups screen shot. The screenshot above gives a ready reference of all the load generators that have been configured and their status.
3.5 Scheduling a Scenario
An important factor in creating a scenario is developing a test that actually portrays user behaviour. The type of actions is captured is by the Vuser script. Scheduling the script captures the timing of actions.
It is essential that the scenario of a test is accurately estimated otherwise the usefulness of the results of Load Testing might be undermined. Load Runner provides various techniques for creating an acceptable simulation of Real life scenario.
Through the Scenario Start dialog box shown in the screen shot below:
You can instruct Load Runner to begin executing a scenario with a delay, or you can specify the number of minutes you want the Load Runner to wait after the Run command has been executed. You can even specify the specific time at which you want the scenario to begin executing.
Through the Scenario Builder as displayed below you can control the execution of your scenario by limiting the scenario duration, gradually running Vusers within a scenario, gradually stopping Vusers within a scenario. Please refer to appendix 1 on how to simulate work load models.
• Limiting the Scenario Duration: The scenario can be made to run until completion, can be made to run for a certain duration after rampup, or can be run indefinitely. If the scenario is made to run for a certain duration after ramp up then irrespective of the number of iterations the scenario will run for the defined time.
• RampUp: All the Vusers can be made to run simultaneously or a delay can be given between groups of Vusers before they start running. In Maconomy generally we need to give a ramp up time to reduce the levels of concurrency in Transactions and also to more accurately simulate the real life scenario as its highly unlikely that all the users would be performing the same transaction at the same time. The ramp up time, generally given for Maconomy is ‘10 users every 30 seconds’. But any suitable value can be given.
• RampDown: There are two options either all the Vusers can be stopped simultaneously or a certain number of users can be brought to a stop in a certain timeframe.
3.6 Scheduling a Vuser group
After creating a Vuser group, you can schedule the groups script execution by setting:
• The amount of time after the start of the scenario that the group must wait before it starts running
• The number of vusers that will run within a specified period of time
• The number of Vusers that will be stopped within a specified period of time
• The amount of time the group will run
To schedule a Vuser group select the ‘Schedule by Group’ option in the scenario builder to get the box as shown below
The Start Time Tab gives the time delay between the start of the Scenario and the start of the Group. The other three tabs have basically the same meaning as explained above for ‘Scheduling by Scenario’.
3.7 Rendezvous Point
Rendezvous points are used to cause multiple Vusers to perform tasks at exactly the same time, there by creating intense user load on the server.
The rendezvous point can be inserted at any point in the script before the transaction that you want to be performed under concurrent load.
From the Vugen menu go to Insert->Rendezvous in the box that comes up enter for the rendezvous point.
Setting the Rendezvous Policy
1. From the Controller menu choose Scenario->Rendezvous. The Rendezvous Information dialog box opens.
2. Select a rendezvous from the Rendezvous box, and click the Policy button.
3. In the Policy section, select one of the following three options;
• Release when X% of all Vusers arrive at the rendezvous
• Release when X% of all running Vusers arrive at the rendezvous
• Release when X Vusers arrive at rendezvous.
From the point of view of Maconomy we might need to measure some important transactions like Costing, Printing through rendezvous points.
The rendezvous points can be temporarily disabled/enabled from a scenario.
3.8 Starting the Scenario
Click on the start scenario button.
In the Run tab of Scenario you will be prompted to enter the path of the results directory as shown in the screen shot below
Enter any suitable path for the results directory. And click on OK. Once this is done the scenario will start executing.
The run tab of the scenario will look as below.
The vusers will move from Down->Pending->Init->Ready->Run state.
You can view information on Transaction Response Times, Number of Running vusers as the scenario runs. Any errors that come up during the run will be immediately highlighted as red against the errors field. (in the Scenario Status box). Trouble Shooting of commonly occurring errors will be explained later in the document. The errors that occurred during the execution of the scenario are stored in a mdb file in the results folder.
Clicking on the vusers button will give information on the status of each of the vusers whether they are initialising/running/passed/failed etc through the below window that comes up.
Clicking on the highlighted icon will give the execution log for the selected vuser as shown below.
Once the scenario has run fully all the vusers would have moved to the Passed/Failed/Error Status and there would be no vuser in running mode.
LOADRUNNER GENERAL PROBLEMS AND LIMITATION
Problem Description: The Controller uses up all the memory though no scenario is running.
Problem Description: The Controller stops responding if a load test scenario issues a high number of errors
Problem Description: How to send the Controller output information to a file instead of viewing it from Controller itself
Problem Description: Are past Execution logs from VuGen saved somewhere
Problem Description: How to enable logging in Controller and where are Vusers log files stored
Problem Description: How to change the Execution and Recording logs to collect different amounts of information
Problem Description: How to disable mdrv###.log files under Vuser hosts
Problem Description: How to enable logging in Controller and where are Vusers log files stored
Problem Description: Where are the results of the WinRunner scripts stored for the GUI Vusers
Problem Description: The output.mdb file is blank after executing a scenario
Problem Description: The Controller displays "Loading Data..." but the error text is not shown in the output window
Problem Description: Generator or Vuser or Show output or Error or Transaction window does not open in the Controller
Problem Description: How to stop Vusers so they exit directly rather than gradual exiting
Problem Description: How to renumber Vusers in LoadRunner 7.5 or above
Problem Description: How to refresh Vuser scripts in the Controller
Problem Description: How to remove the scripts that are listed in "Available Scripts"
Problem Description: How to initialize more than 50 Vusers at a time
Problem Description: Common connectivity problems between Controller and Generator
Problem Description: Error: "-29989: Process 'lr_bridge.exe' was not created..."
Problem Description: How to run a scenario from the command line (Controller's Command Line Arguments)
Problem Description: How to run a scenario at a specific (absolute) time
Problem Description: Setting scenario start time in LoadRunner does not work
Problem Description: Wlrun.exe does not close when executing a scenario via command line option
Problem Description: How to read in string/text content from the command line in the Controller
Problem Description: Running LR from the command line does not collate results from a remote machine
Problem Description: Running LR from the command line does not collate results from a remote machine
Problem Description: How to modify the heartbeat time-out
Problem Description: How to set the "Save as" directory opened by VuGen or Controller
Problem Description: Cannot connect to the host machine from the Controller
Problem Description: Can the user run multiple Controllers using a network installation
Problem Description: Can different versions of LoadRunner be used together in a scenario
Problem Description: How to enter a new license key for LoadRunner
Problem Description: Accessing the Output window in the Controller increases the size of output.mdb
Problem Description: Some Vusers do not wait for other Vusers at the rendezvous point
Problem Description: C++ run-time error when running a Scenario
Problem Description: Scenario scheduler does not ramp down at the specified time
Problem Description: How to show more than 20 measurements in the Controller online monitor
Problem ID: 26375
Problem Description: The Controller uses up all the memory though no scenario is running
The Controller seems to be utilizing all the memory resources. Without any scenario running, the user noticed that the memory utilization for wlrun.exe increase drastically.
Diagnosis:Some processes or services on the machine might be interfering with the normal Controller operation.
________________________________________
Solution: Identifying processes that might interfere with the Controller
To verify the processes or services that might interfere with the Controller, you can use the Process Viewer. This application helps to list all the DLLs that are loaded.
Apart from that, it has been observed that the following might interfere with wlrun.exe:
• VNC (Virtual Network Computing) client
• SPYWARE ( using software like Ad-Aware )
• ExeSpy2000
Problem ID: 21925
Problem Description: The Controller stops responding if a load test scenario issues a high number of errors
The LoadRunner Controller stops responding if a load test scenario issues a high number of errors during scenario execution.
________________________________________
Solution: Configure the Controller to write errors to a text file
By default, the Controller writes errors to an Access database (output.mdb, created in the scenario results).
Work-around:
Configure the Controller to write errors to a text file.
Problem ID: 15075
Problem Description: How to send the Controller output information to a file instead of viewing it from Controller itself
________________________________________
Solution: Set "ExportMessagesToFile" to 1 in wlrun7.ini
Starting with LoadRunner 7.5, the output window information is saved in output.mdb file under the resutls folder . To set LoadRunner to use a different database, you need to go to Analysis -> Tools -> Options -> Database and set the database default before running a scenario.
If you need to view the data using a text file, you will need to
1. Run the Controller once and shut it down to reset the configuration files
2. In order to set /unset the text file mode please open wlrun7.ini using a text editor. This file can be found in your systems WinNT folder, or in your accounts 'WINDOWS' directory. Simply do a quick search for this on your hard drive.
3. Go to the [output] section and set "ExportMessagesToFile" to 1. If you do not see this entry, add it as following
[output]
ExportMessagesToFile=1
Note:If these messages are not important and you cannot prevent them then you can block these messages by making the following change in the wlrun7.ini (Close the Controller before making these changes):
[output]
BlockOutputMessages=1
************************************************************************
Problem ID: 15827
Problem Description: Are past Execution logs from VuGen saved somewhere
The user executed several runs in VuGen, are all the Execution logs saved?
________________________________________
Solution: Only the most recent Execution log is saved as output.txt in the main script directory
Execution logs are saved in output.txt in the main script directory. However, it is always overwritten during each run in VuGen. You need to back up the output.txt file after each run in order to save each Execution log.
Problem ID: 17005
Problem Description: How to enable logging in Controller and where are Vusers log files stored
________________________________________
Solution: Set the Run-Time settings to 'Always send messages'
To turn on logging for the Vusers in the Controller
1. Go to the Run-Time settings
2. In the log tab, select "Always send messages"
3. You can set the log detail level as you wish
4. Run the script
To see the message on the log file:
1. The Controller if the scenario is still up.
a. Click on "Vusers" in the Controller.
b. Right-click on one of the Vusers.
c. Select "Show Vuser log."
2. The result folder.
a. Go to the result directory (the location is specified in the Controller's Result-> Result settings).
b. Go to the "log" folder.
c. All Vusers' log files are saved as GroupName_VuserID.log.
Problem ID: 11377
Problem Description: How to change the Execution and Recording logs to collect different amounts of information
________________________________________
Solution: Turn on "Full Trace Recording Log" from the Recording Option
For extended Recording log information, look at the Tools -> Recording Options -> Advanced tab, which will allow you to choose "Full Trace Recording Log" to enable additional data collection. This option is available with the 'Single Protocol' template only.
For the Execution log, you want to go to the Vuser -> Run-Time Settings Log tab, which has three options for the Execution Log:
• Parameter substition - Prints the values of the parameters in your script.
• Data returned by server - All the HTTP data returned by the server.
• Advanced Trace - Additional information about the requests being submitted by the client.
Generating all three debugging options when running the script is the preferred method for debugging script exection. The data returned by server is the largest amount of data, and as long as you generate that, you might as well get the other two for added information.
The Execution log records all the information that is passed from the client to the server. It is the definitive guide to the conversation between the two. When debugging replay, it is important to realize the limitations of the Run-Time Viewer and turn to the Execution log to debug replay. Two tricks to speed up execution when replaying with the Extended log enabled are
1. Turn of resource downloading in the Run-Time Settings.
This will prevent all the binary data from being printed into the exection log (it is usually pretty useless anyway).
2. Click on the Recording Log tab during replay so VuGen does not have to update the Execution log on screen.
If you turn on the Extended log, it will generate large log files. Ensure you have enough disk space on which to store these files. If running a scenario with the Extended log, remember there will be a log file for each Vuser. Not only will this be a lot of large log files, but the host machine will spend a lot of time writing log files and not running Vusers, so fewer can run with the given resources compaired to when logging is disabled. It is not recommended to run a scenario with Extended log turned on.
************************************************************************
Problem ID: 3962
Problem Description: How to disable mdrv###.log files under Vuser hosts
________________________________________
Solution: Use command line option
For Unix hosts:
1. Add the script as usual to the Controller
2. Click on 'details...'
3. Click on 'more'
4. On the 'Command line' option, add the following:
-drv_log_file /dev/null
For Windows hosts:
1. Add the script as usual to the Controller
2. Click on 'details...'
3. Click on 'more' 4. On the 'Command line' option, add the following:
-no_drv_log
************************************************************************
Problem ID: 17005
Problem Description: How to enable logging in Controller and where are Vusers log files stored
________________________________________
Solution: Set the Run-Time settings to 'Always send messages'
To turn on logging for the Vusers in the Controller
1. Go to the Run-Time settings
2. In the log tab, select "Always send messages"
3. You can set the log detail level as you wish
4. Run the script
To see the message on the log file:
1. The Controller if the scenario is still up.
a. Click on "Vusers" in the Controller.
b. Right-click on one of the Vusers.
c. Select "Show Vuser log."
2. The result folder.
a. Go to the result directory (the location is specified in the Controller's Result-> Result settings).
b. Go to the "log" folder.
c. All Vusers' log files are saved as GroupName_VuserID.log.
Problem ID: 14559
Problem Description: Where are the results of the WinRunner scripts stored for the GUI Vusers
Where are the test results of the WinRunner scripts stored for GUI Vusers and how are they archived?
________________________________________
Solution: The test results are in the Temp directory of the machine on which the script is to be run
When running a load test, LoadRunner FTPs the WinRunner script into the Temp directory of the machine on which the script is to be run. The WinRunner results will be on that machine in the Temp directory. You will need to look for the WinRunner test script folder, which should be the same as if you were running WinRunner by itself, and the test results will be in the script folder.
The hard part will be determining which folder in the Temp directory was created as LoadRunner creates the folder dynamically. Check the date stamps of the folders and choose the most recently created one.
The load test results are saved in the location specifed in the Controller.
Problem ID: 22040
Problem Description: The output.mdb file is blank after executing a scenario
After executing a scenario using LoadRunner 7.5, the user notices the output.mdb file is empty even though there were a lot of errors, warnings, or output messages while running the scenario.
Diagnosis: The size of the output.mdb file is limited to 400 KB. If there are a lot of messages in the scenario execution (i.e., exceeding 400 KB), it will set the file to 0 KB.
________________________________________
Solution: Apply Patch LR75P26 - LoadRunner 7.5 Controller Fixes an empty mdb after Scenario finished running
This is a know problem in LoadRunner 7.5 with output.mdb where file size limitation is 400 KB. You need to apply Patch LR75P26 (LoadRunner 7.5 Controller Fixes an empty mdb after Scenario finished running) from the Patches database (Downloads -> Patches -> LoadRunner -> 7.5 -> General -> LR75P26) on the Customer Support website
************************************************************************
Problem ID: 22334
Problem Description: The Controller displays "Loading Data..." but the error text is not shown in the output window
When trying to open the error window in the Controller, the window appears, but hangs with the message "Loading Data...."
________________________________________
Solution: Upgrade the MDAC version on the Controller machine
This problem has been reported for the following cases:
1. MDAC version
You can find the MDAC version on your machine from Microsoft Knowledge Base Article 301202 - HOW TO: Check for MDAC Version. Make sure that you have MDAC 2.6 or higher installed. You can get the latest MDAC version from Free Downloads.
2. "List separator" setting
If you have a non-English environment, the "list separator" option on the machine is most likely set to be a semicolon. Go to Start -> Settings -> Control Panel -> Regional options, and under the "Number" tab, change the "list separator" to be a comma.
************************************************************************
Problem ID: 15350
Problem Description: Generator or Vuser or Show output or Error or Transaction window does not open in the Controller
Clicking on the "Generator" or "Vuser" or "Show Output" or "Error" or "Passsed / Failed transaction" button in the Controller does not open the window.
Diagnosis:The initialization file for the Controller is corrupted.
________________________________________
Solution: Delete wlrun7.ini from the C:\winnt directory
1. Close the LoadRunner Controller.
2. Go to the C:\winnt (or C:\windows for windows XP )folder and delete the wlrun7.ini file.
3. Go to
4. Reopen the Controller. The problematic windows should now open when you click on it.
Alternatively, if you do not wish to lose other settings, open wlrun7.ini in a text editor. Look for a section similar to:
[DockablePlace]
OUTPUT_FRAME_PLACE=113,846,587,1186,
TRANS_FRAME_PLACE=110,200,450,345
Simply replace the numeric values there, with the X coordinate of the window, its Y coordinate, width and height. "300,300,600,500," are usually reasonable values to start with. Then you need to save your scenario if necessary, and restart the Controller.
************************************************************************
Problem ID: 15390
Problem Description: How to stop Vusers so they exit directly rather than gradual exiting
________________________________________
Solution: Set the exit mode to "Stop immediately"
Open the Controller, click on the Run tab, and go to Tools -> Options -> Run-Time Settings. In the "When stopping Vusers" category, select "Stop immediately."
Problem ID: 15338
Problem Description: How to renumber Vusers in LoadRunner 7.5 or above
________________________________________
Solution: Renumber the Vusers in the "Run" screen
1. Go to the the Run screen of the Controller
2. Locate the "Group Name" column.
3. Right-click on the desired group name and select "Renumber."
Note: When you renumber the groups, the Vusers will change their IDs.
************************************************************************
Problem ID: 13604
Problem Description: How to refresh Vuser scripts in the Controller
After scripts have been modified in the VuGen, scripts in the Controller are not affected. How can the user make sure that updated scripts are being run?
________________________________________
Solution: Click on the "Refresh" button in Details
Go to the Design tab in the Controller and select one group. Click on Details, then click on the Refresh button. By doing this, the Controller will use the latest script in scenario. Follow the same procedure for all the groups in a scenario.
************************************************************************
Problem ID: 11297
Problem Description: How to remove the scripts that are listed in "Available Scripts"
How can the user remove the scripts that are listed in "Available Scripts" when creating a new scenario?
________________________________________
Solution: Delete the unwanted script entries from the registry
All recently accessed URL information is stored in the registry under HKEY_CURRENT_USER\Software\Mercury Interactive\RecentScripts.
To remove unwanted URL:
1. Go to Start -> Run and type in regedit to open the Registry Editor.
2. Open the HKEY_CURRENT_USER -> Software -> Mercury -> Recent Scripts folder. This lists all the files listed in the "Available Scripts" section when the Controller is launched.
3. Delete those entries you no longer want to appear.
Problem ID: 13349
Problem Description: How to initialize more than 50 Vusers at a time
During a scenario, the Controller will not allow more than 50 users to initialize at one time. This is in spite of the fact that the Vuser Quota for Initializations is set to 999 in the Controller's Tools -> Options menu.
________________________________________
Solution: The number of users that may be initialized is governed by two settings
The number of users that may be initialized at one time is governed by two settings. There is one overall setting that you can access under Tools -> Options -> Runtime Settings.
In addition to this, the initialization limit is also governed for each host machine.
1. Go to the Design Tab of the Controller.
2. Click on the "Generators" button. A new window will come up.
3. Bring up the Details of a generator.
4. Go to the Runtime Quota tab. This is where you will find an Initialization Limit for the host machine itself.
5. Set both limits accordingly.
Problem ID: 25162
Problem Description: Common connectivity problems between Controller and Generator
User is facing connectivity problems between Controller and Generator machines. The connection drops in middle of a scneario or can not connect to the Generator machine at all. LoadRunner returns the following eror :
Error: Load Generator failed.
Failed to connect - reason timeout.
Error -10343: Communication error: Failed to connect to remote host [server name: ]. (sys error message - ) [MsgId: MERR-10343]
Error -29989: Process "lr_bridge.exe" was not created on remote host "" ,reason - communication error. [MsgId: MERR-29989]
________________________________________
Solution: Troubleshooting a connectivity problem
Different problems can cause the above error. Some of the things you can verify include:
1. Make sure that you apply the same LoadRunner version and Service Pack on the Controller and Load Generator machines.
2. Make sure that you can ping the Controller and host machine bidirectionally. You may need to add the IP address and machine name on the host file:
a. Go to the host machine.
b. Navigate to C:\WINNT\system32\drivers\etc\.
c. Open the hosts file in a word editor.
d. At the end of the file, add another line with the IP address and machine name of the Controller machine.
Example:
111.111.111.111 MI_Controller
e. Repeat steps a - d for all the host machines.
f. Repeat steps a - d for the Controller machine, but adding the IP and machine name of the hosts machines.
3. Make sure that the LoadRunner Agent is running either as a process or a service on the remote host machine. Refer to Problem ID 10464- How to set LoadRunner Agent as a service or process after installation to do this.
4. Make sure the Controller and host are connected to the network. In some networks, the Microsoft LOOP back IP address 10.10.10.10 is used when a computer is not connected to the network. As a result, the Controller will not be able to detect the host machine. You will need to stop the loop back service, connect to the network, and make sure that the machine has a valid IP address.
5. If there are multiple network cards in the machines, please refer to Problem ID 11685 - Using LoadRunner with machines that have multiple NICs.
6. It might as well be possible that some network environment issue might be the cause and the network monitor can be used to diagnose the problem. Make sure that you are using the latest driver and firmware for your network cards and routers. Also try to force the network card to use 100Mbs/Full Duplex instead of the 'Detect automatically the best speed settings'. In case of miscommunication with the router or other network device the automatic settings could be set in an inappropriate way and have huge consecuencies on the network performances.
Problem ID: 11569
Problem Description: Error: "-29989: Process 'lr_bridge.exe' was not created..."
When trying to connect to a remote host using the hostname, the LoadRunner Controller gives the following error:
"- 29989: Process 'lr_bridge.exe' was not created on the remote host 'host_name', reason - communication error [msgId: MERR-29989]"
However, it is able to connect using the IP address.
________________________________________
Solution: Troubleshooting a connectivity problem
Different problems can cause the above error. Some of the things you can verify include:
1. Make sure that you apply the same LoadRunner version and Service Pack on the Controller and Load Generator machines.
2. Make sure that you can ping the Controller and host machine bidirectionally. You may need to add the IP address and machine name on the host file:
a. Go to the host machine.
b. Navigate to C:\WINNT\system32\drivers\etc\.
c. Open the hosts file in a word editor.
d. At the end of the file, add another line with the IP address and machine name of the Controller machine.
Example:
111.111.111.111 MI_Controller
e. Repeat steps a - d for all the host machines.
f. Repeat steps a - d for the Controller machine, but adding the IP and machine name of the hosts machines.
3. Make sure that the LoadRunner Agent is running either as a process or a service on the remote host machine. Refer to Problem ID 10464- How to set LoadRunner Agent as a service or process after installation to do this.
4. Make sure the Controller and host are connected to the network. In some networks, the Microsoft LOOP back IP address 10.10.10.10 is used when a computer is not connected to the network. As a result, the Controller will not be able to detect the host machine. You will need to stop the loop back service, connect to the network, and make sure that the machine has a valid IP address.
Problem ID: 13352
Problem Description: How to run a scenario from the command line (Controller's Command Line Arguments)
Is there a way to start the Controller via a Command Prompt?
Specifically, what arguments can be used to start the Controller, run an existing Scenario, shut down the Controller, and bring up the Analysis?
________________________________________
Solution: Command line arguments for the LoadRunner Controller
Note:
1. Make sure that the Controller is shut down before starting the scheduled task.
2. When running the Controller via the Command Line, Controller will be shut down automatically after the scenario ends.
Command line parameters are parameters that the Controller receives when it is invoked. They are used to instruct the Controller on how to behave. When invoked, the Controller checks all the received parameters and sets its startup environment accordingly. If no parameters are passed, the Controller uses its default settings.
By passing parameters in the command line, you may set the Controller and the scenario’s settings without the need to manually define them in the Controller UI. For example, you can instruct the Controller whether to connect to TestDirector on startup by using the ConnectToTD parameter, save the results to a directory other than that defined in the scenario by using the ResultName parameter, or invoke Analysis upon scenario termination with the InvokeAnalysis parameter.
The most common use of the Command Line is done by TestDirector. TestDirector includes a special program called "Test Run Scheduler," which was designed for scheduling the Controller to run scenarios at a specific date and time. It automatically invokes the Controller and runs scenarios. Results are saved in the TestDirector database. To do that, TestDirector must set the scenario’s environment by supplying the Controller with specific parameters.
Predefined rules:
• When one or more parameters are not passed, the Controller uses its default settings.
• Results will always be overwritten.
• The Controller will automatically terminate upon scenario termination and the results will be then collated.
• The Controller’s settings are loaded from wlrun5.ini located in the Windows directory.
• The following parameters are supported on all Windows 9x and Windows NT platforms.
Switches for LoadRunner/TestDirector integration:
• ConnectToTD - Should the Controller connect to TestDirector on startup (0/1 or ON/OFF).
• TDServer - TestDirector server name. Must be a computer name with TestDirector installed.
• TDDB - Database name. For example, "lrun."
• UserName - User name.
• Password - Password for the user name.
• TestPath - Path to scenario in the TestDirector database. For example, "[TD]\Subject\LoadRunner\Scenario1." If the path includes white spaces, use quotation marks.
• TestId – Test ID (for TestDirector only).
• ResultCleanName - For use with ResultCycle only, for example, "Res1."
• ResultCycle - TestDirector cycle, for example, "LR_60_SP1_247." To define the results path in TestDirector, the Controller must be provided with two parameters: ResultCycle and ResultCleanName.
Run-Time Switches:
• Run – Runs scenario, dumps all output messages into res_dir\output.txt and closes the Controller.
• InvokeAnalysis - InvokeAnalysis will set a flag in the Controller, which will invoke Analysis upon scenario termination (If not used, the scenario value will be taken).
Results Switches (for File System):
• ResultName - Full results path, for example, "C:\Temp\Res_01."
• ResultCleanName - Results name, for example, "Res_01."
• ResultLocation - Results directory. For example, "C:\Temp".
• Note:
o If the scenario does not specify a results directory and one of the above parameters was not passed, the scenario will not run!
o The results will always be automatically collated upon scenario termination.
o The results will always be automatically overwritten.
Command Line Syntax examples:
• Wlrun.exe –TestPath C:\Temp\Scenario1.lrs -ResultName C:\Temp\Res1 –Run –InvokeAnalysis
• Wlrun.exe –TestPath C:\Temp\Scenario1.lrs –ResultLocation C:\Temp –ResultCleanName Res1 –Run
• Wlrun.exe –ConnectToTD on –TDServer localhost –TDDB lrun –UserName yaniv18 –Passwordb#12GcSA –TestPath "[TD]\Subject\Trash for LR/TD Integration\Scenario1" –Run
• Wlrun.exe –ConnectToTD 1 –TestPath "[TD]\Subject\Trash for LR/TD Integration\Scenario1"
5. If there are multiple network cards in the machines, please refer to Problem ID 11685 - Using LoadRunner with machines that have multiple NICs.
6. It might as well be possible that some network environment issue might be the cause and the network monitor can be used to diagnose the problem. Make sure that you are using the latest driver and firmware for your network cards and routers. Also try to force the network card to use 100Mbs/Full Duplex instead of the 'Detect automatically the best speed settings'. In case of miscommunication with the router or other network device the automatic settings could be set in an inappropriate way and have huge consecuencies on the network performances.
Problem ID: 2782
Problem Description: How to run a scenario at a specific (absolute) time
How can the user execute a scenario at a specific (absolute) time in the day (e.g., 8pm) instead of using a relative "time from now."
________________________________________
Solution: Use scenario scheduler of Controller or Windows Scheduler
Using Scenario Scheduler of Controller:
1. Open the scenario in the Controller.
2. Go to Design Tab -> Edit Schedule -> Scenario Start time and set the time when you want to start the scenario.
3. You need to click on Start Scenario button so that the Controller can trigger the scenario once the start time comes up.
Using Windows Scheduler:
Scenario Scheduler of Controller is limited to the effect that it can only be sheduled to be run at one time. In order to re-run it the scenario has to be edited again. Instead, you can do the following:
1. You can have the scenario run from command line in a batch file as per Problem ID 13352 - How to run a scenario from the command line(Controller's Command Line Arguments).
2. Then you schedule this batch file to run at different times from the Windows Scheduler.
Problem ID: 15478
Problem Description: Setting scenario start time in LoadRunner does not work
In the LoadRunner Controller, under Scenario menu -> Start time, the scenario start time is set to a specific time. However, the LoadRunner scenario does not start at the set time.
________________________________________
Solution: Click on "Start Scenario"
After setting up the scenario start time, click on the "Start Scenario" button in the Controller. A pop-up menu will come up showing the count down to the start time the scenario.
Problem ID: 15717
Problem Description: Wlrun.exe does not close when executing a scenario via command line option
When executing a scenario via the command line option
wlrun -TestPath D:\temp\testscenario.lrs -ResultName "D:\temp\res" -Run
even if the Controller GUI interface has disappeared, wlrun.exe seems to continue to run for sometime.
________________________________________
Solution: Wlrun.exe shuts down after a delay
Depending on the scenario setting and results, wlrun.exe might take a longer time to shut down. There have been cases seen where wlrun.exe shutdowns 5-10 minutes after the Controller GUI interface disappears.
************************************************************************
Problem ID: 9277
Problem Description: How to read in string/text content from the command line in the Controller
How can the user get string or text information from the command line?
Example:
Command line parameter: -host
Value : server
This command line is entered as -host server in the Controller's command line text box. How can the user capture the value "server" and use it as a string in the script?
________________________________________
Solution: Use lr_save_string(lr_get_attrib_string("host"), "server");
You can capture the value for "server" using the lr_get_attrib_string() function.
Example:
lr_save_string(lr_get_attrib_string("host"), "server");
The lr_get_attrib_string() function will capture the string "server" from the command line, and the lr_save_string() function will insert the value into a parameter called [server].
Problem ID: 22476
Problem Description: Running LR from the command line does not collate results from a remote machine
LoadRunner is not collating the results from a remote Load Generator machine when running from the command line.
Note:
The user is running LoadRunner 7.51 SP1.
________________________________________
Solution: Contact Customer Support for Patch LR751SP1P17
Please contact Mercury Customer Support for Patch LR751SP1P17 - LoadRunner 7.51 SP1 Fixes several bugs in launching Controller through command line.
Problem ID: 16855
Problem Description: How to modify the heartbeat time-out
When starting a scenario and connecting to the remote host, the Controller machine's CPU reaches 100% and its user interface freezes.
Diagnosis: This could happen if there are a lot of remote hosts (several hundreds) or when there are large data files to be transferred.
________________________________________
Solution: Minimize heartbeat frequency so the hosts will send less heartbeat messages to the Controller
In LoadRunner, all hosts manage heartbeat mechanisms with the Controller. By default, each host sends four messages in two minutes with frequency of 30 seconds until heartbeat failure is reached. This could cause a problem when there are a lot of hosts or large data files.
To work around the issue, you need to minimize the heartbeat frequency so that the hosts will send less heartbeat messages to the Controller. Since LoadRunner waits time-out*4 before it reaches heartbeat failure, you can increase the time-out value of the Controller and Load Generator machines (so as to minimize the frequency) or minimize the heartbeat messages.
To minimize the heartbeat messages:
1. Close the Controller, and stop the LoadRunner Agent process/service.
2. Modify the mdrv.dat file in the
3. Add the following lines to the end of [Launcher] section:
ExtCmdLine= -HB_TIMEOUT
ExtCmdLine= -HB_TIMEOUT_LIMIT
Example:
[Launcher] ExtPriorityType=launcher WINNT_EXT_LIBS=launcher.dll WIN95_EXT_LIBS=launcher.dll LINUX_EXT_LIBS=liblauncher.so SOLARIS_EXT_LIBS=liblauncher.so HPUX_EXT_LIBS=liblauncher.sl AIX_EXT_LIBS=liblauncher.so LibCfgFunc=launchext_configure UtilityExt=two_way_comm ExtMessageQueue=0 SecurityMode=On ExtCmdLine= -HB_TIMEOUT 120000 ExtCmdLine= -HB_TIMEOUT_LIMIT 5
Note:
• The "-HB_TIMEOUT 120000" option sets the time-out to send heartbeat messages every 120 seconds.
• The "=-HB_TIMEOUT_LIMIT 5" option sets the number of times to resend heartbeat messages to 5.
4. Repeat steps 2-3 for the mdrv.dat file in
Note:
If you change the heartbeat to be every 2 minutes, the Controller will be able to establish a connection, however since the hosts still send heartbeat messages it cause the UI to get stuck every 2 minutes for half minute.
Problem ID: 3709
Problem Description: How to set the "Save as" directory opened by VuGen or Controller
When doing a "Save as," is it possible to specify which directory is brought up by default in VuGen and the Controller?
________________________________________
Solution: Defining the default directory for VuGen and the Controller
To change the default directory that comes up, modify the following file entries:
For VuGen
In the "vugen.ini" file located in the WinNT directory.
[General]
LastScriptPath=D:\TEMP\scriptname
For the Controller
In the WinNT directory, there is the configuration file for the Controller. It is called wlrunX.ini where X is a number that changes depending on the version of the Controller used. For LoadRunner 6.x, the file is called wlrun5.ini. For LoadRunner 7.x and higher it is wlrun7.ini.
[General]
DefaultScenarioDir=D:\TEMP\scenario_name.lrs
Problem ID: 10315
Problem Description: Cannot connect to the host machine from the Controller
Diagnosis: AOL is installed on the machine.
________________________________________
Solution: Cannot have AOL and the Controller on the same machine
LoadRunner conflicts with AOL. You cannot use AOL and the Controller on the same machine.
Here is the work-around that you can try:
Steps to disable "AOL - WAN Network Driver"
1. Right-click on the "My network places" icon on the desktop, then click on "Properties."
2. Right-click on "Local Area Connection" (for AOL), then click on "Disable."
3. Only after this, try to launch the Controller and connect.
Problem ID: 17845
Problem Description: Can the user run multiple Controllers using a network installation
How does a network installation work? Is it possible to access the Controller from multiple workstations if a network installation is done on the server and workstation installation is done on each individual workstation?
________________________________________
Solution: Purchase multiple Controller licenses to run multiple Controllers
Network installations allow for installing all the setup files for various LoadRunner components on a shared network drive of a server. A corresponding workstation installation will create LoadRunner program group on each workstation. This will aid in saving lots of disk space on the local machine and a global update facility for any kind of patches and upgrades. However, the Controller workstation has to be pre-determined as a license needs to be installed on the local workstation only and not on the shared network drive of the server where network installation is done. This means Controller is still a single workstation and will not be running on all workstations. You need to purchase multiple Controller licenses to run multiple Controllers.
Problem ID: 11422
Problem Description: Can different versions of LoadRunner be used together in a scenario
Can different versions of LoadRunner be used together in the same scenario?
Example:
Controller Version: LoadRunner 7.5
Host Version: LoadRunner 7.51
________________________________________
Solution: The same version of LoadRunner must be on all machines in a scenario
Because the communications protocol is constantly being updated between versions (even minor versions), you have to ensure that all machines being used are on the exact same version of LoadRunner. This goes for any patches installed as well.
Example:
If the Controller is on LoadRunner 7.51 with xxx patch, the hosts have to be on LoadRunner 7.51 with xxx patch.
Problem ID: 11369
Problem Description: How to enter a new license key for LoadRunner
How to enter the new license key in LoadRunner when LoadRunner is already installed.
________________________________________
Solution: Steps to add a new license when LoadRunner is already installed
Follow the steps below to add/update LoadRunner license key on an existing install:
For LoadRunner 8.1:
1. Close the Controller
2. Go to Start -> Programs -> LoadRunner -> LoadRunner -> Configuration
3. Click on the "License" menu
4. Click on "New License" and type in the new license key
5. Click
6. Bring up the Controller again.
For LoadRunner 8.0:
1. Close the Controller
2. Go to Start -> Programs -> LoadRunner -> LoadRunner
3. Click on the "License" menu
4. Click on "New License" and type in the new license key
5. Click
6. Bring up the Controller again.
For LoadRunner7.0 - 7.8 Feature Pack1
1. Bring up the Controller and go to Help -> About LoadRunner.
2. Click on "New License" and type in the new license key.
3. Click
4. Close the Controller and restart it; the new license key will be in effect
Problem ID: 23086
Problem Description: How to configure the Controller to open different versions of Analysis
The Analysis tool can be launched directly from the Controller by clicking on Tools -> Analysis. How can the user configure the Controller so it launches a different version of Analysis tool installed on the same machine as a stand-alone component?
________________________________________
Solution: Configure AnalysisPath in wlrun7.ini to point to the desired path
1. Go to the C:\Winnt directory and open the wlrun7.ini file.
2. Find the [Tools] section.
3. Add or modify the AnalysisPath entry so that it points to the desired installation of Analysis.
Example:
[Tools]
AutoAnalysis=0
AnalysisPath=
Problem ID: 24730
Problem Description: Accessing the Output window in the Controller increases the size of output.mdb
Accessing the Output window in the Controller increases the size of output.mdb in the result folder.
Example:
The user ran a scenario that output x number of messages. If the user does not access the output window in the Controller during scenario execution, the size of output.mdb is relatively small. However, if the user accesses the output window, the size of output.mdb could double or triple in size.
Diagnosis:The MS Access database (.mdb) is updated each time the Output window is accessed. If the user accesses the output.mdb file after the scenario, he will see that MS Access actually creates new views and temporary tables to display the data while he accesses the Output window. The temprorary views and tables is the cause of the size differences.
________________________________________
Solution: Compact and repair the database
To reduce the size of output.mdb so that it is the same with a scenario where the Output window in the Controller was not accessed, you need to compact and repair the database.
1. Open the output.mdb file in MS Access 2000 or MS Access 97 .
2. Go to Tools -> Database Utilities -> Compact and Repair Database.
For LoadRunner 7.51 SP 1 or above, there is an option to print output messages to a text file instead of the Access database. For further information, refer to Problem ID 15075 - How to send the Controller output information to a file instead of viewing it from Controller itself.
************************************************************************
Problem ID: 16965
Problem Description: Some Vusers do not wait for other Vusers at the rendezvous point
The user created a script with a rendezvous point set. When replaying it in the Controller, the Vusers do not wait for other Vusers. LoadRunner Vusers sometime exit the rendezvous point even though not all Vusers have arrived.
________________________________________
Solution: Increase the timeout between Vusers
The LoadRunner rendezvous point will timeout after 30 seconds by default. This means the Vusers will continue running if either of the following conditions apply:
• All the users have reached the rendezvous point, or
• 30 seconds has passed.
If you would like to change the conditions, so that Vusers exit the rendezvous point only when 100% of the Vusers reach the rendezvous point, do the following:
1. In the Scenario, go to Scenario -> Rendezvous.
2. Highlight the rendezvous name and select "Policy."
3. Select the relevant settings, and verify that you increased the timeout (so that timeout will not occur).
Again, you need to set the value for timeout between Vusers to be high enough so that timeout will not happen before all Vusers reach the rendezvous point.
Problem ID: 16971
Problem Description: C++ run-time error when running a Scenario
When trying to run a scenario, the following error comes up as a pop-up window:
"Assertion failed!
Program:....s\Mercury Interactive\LoadRunner\bin\wlrun.exe
File:S:\EventServer03\nt\app\EsDll\ESEngin.cpp
Line:90
Expression: Gran>=1"
Diagnosis:This error might appear if there is a problem with the LoadRunner installation.
________________________________________
Solution: Verify the LoadRunner installation
There are many reasons that can lead to the problem above. Things you can verify includes:
1. Make sure that LoadRunner was installed with a local administrator account.
2. Verify that you are logged into the machine as the local administrator.
3. Go to C:\winnt folder and delete: wlrun.ini, wlrun5.ini and wlrun7.ini.
4. Go to
5. The assertion errors can also occur due to a corrupted scenario. If you are using saved scenario file, try to create a new scenario and run the test.
Problem ID: 17136
Problem Description: Scenario scheduler does not ramp down at the specified time
After setting up a schedule for LoadRunner Vusers to ramp up and ramp down after certain duration, the scenario does not stop at the specified time.
________________________________________
Solution: Verify the Vuser stop behavior
The Vuser stop behavior will affect the time when the scenario ends. To verify the Vuser stop behavior:
1. From Controller, go to Tools -> Options -> Run-Time Settings
2. The available stop options include:
a. Wait for the current iteration to end before stopping
b. Wait for the current action to end before stopping
c. Stop Immediately
Install Patch LR75P22 scheduler ramp
Problem ID: 26817
Problem Description: How to show more than 20 measurements in the Controller online monitor
By default, the Controller online monitor only shows 20 measurements for each graph. Additional measurements enabled will be in the "hidden" option. Is there any way to increase this?
________________________________________
Solution: Modify the value of MaxDispMeasurments
You can enable the Controller online monitor to display more than 20 measurements for selected categories of graphs.
Example:
• System Resource Graphs
• Runtime Graphs
• Transaction Graphs
• Web Resource Graphs
• Streaming Media
To display more than 20 measurements:
1. Go to the
2. Open the relevant .def files using word editor:
System Resource Graphs - online_resource_graphs.rmd
Runtime Graphs - online_runtime_graphs.def
Transaction Graphs - online_transaction_graphs.def
Web Resource Graphs - online_web_graphs.def
Streaming Media - online_web_graphs_mms.def
3. Locate the monitor for which you want to display more than 20 measurements.
4. Modify the value of MaxDispMeasurments=.
Example:
To display 30 Measurements for the Windows Resources Monitor:
1. Open online_resource_graphs.rmd from
2. Locate the ;--- Windows Resources --- section.
3. Change the value of MaxDispMeasurments= to 30.
Example:
MaxDispMeasurments=30
Modify the value of MaxDispMeasurments 1-14689s
5. Suggested debugging steps if Controller crashes
Make sure that you login as a local administrator
Login to the Controller machine with a local administrator account. Currently, Mercury do not support running Controller using a domain account. Using domain account may cause unexpected behaviors.
Make sure that there are sufficient Disk Space
Make sure that you have enough disk space available on the controller and load generators. During scenario execution, the events are written onto the Load Generator machines and are saved locally until the scenario finished; where results are send back to the Controller. If the machine does not have enough disk space, it can cause problem.
Check if the size of the output.mdb file in the results folder is more than 2 GB
If the output.mdb file becomes greater than 2GB during a load test, Controller is unable to write into it anymore and cause a crash. If the size of output.mdb file is larger than 2 GB, divert the output to a text file as per Problem ID 15075 - How to send the Controller output information to a file instead of viewing it from Controller itself
Run the Controller’s batch files to register DLLs
Sometimes, DLLs can become unregistered or the registry can become corrupted to a point where a program's DLLs cannot be found. The purpose of batch files is to reregister them into the system's registry so that the programs can locate them. Use the following steps to do this:
1. Shut down the Controller.
2. Navigate to the
• register_controller.bat
• set_mon.bat
3. Create a duplicate copy of the file, in the same location.
4. Open up the duplicated file. In it, you should see several entries like the following:
regsvr32 /s webbrwsr.dll
Remove the "/s" from each of these statements, but leave a space between the "regsvr32" and the DLL name.
5. Save the changes.
6. Double click on the batch file to run it. You should get several pop-up messages similar to the following:
Note: You could get failure messages for escomps.dll and resmonps.dll. You can safely igonore these errors. But you should not get any other failure messages. If you do, then that DLL is the problem file. Try registering this from the command prompt:
Example: regsvr32 < LoadRunner >\bin\
If this does not work, try copying the DLL from the CD or ask support for the DLL to try registering it manually. Retry the same action that caused the error.
Verify the CPU usage on the machine
Verify the CPU usage on the machines. Ideally, they should be below 80% usages. If necessary, distribute the Vuser load to other machines.
Try to recreate the Controller’s initialization file
Sometimes, the initialization files can become corrupted (e.g. after a crashed). You will have problem in launching or using the Controller after that. Use the following steps to do delete the initialization file so that a new copy will be created:
1. Shut the Controller.
2. Navigate to the C:\Winnt ( or C:\Windows for Windows XP machine )
3. Delete all files that begin with wlrun*. For example,
wlrun.ini, wlrun5.ini, wlrun7.dft, wlrun7.hst, wlrun7.ini
Check the temporary environment variables
Unlike the earlier window’s versions, Window 2000 and Window XP have the default environment set to c:\Document and Settings\
Verify if Hyper Threading is enabled
Verify if Hyper Threading is enabled. If so, you will need to disable it. LoadRunner does NOT support Intel Hyper-Threading technology. Hyper-Threading can be disabled in the BIOS. For more information, refer to
http://www.microsoft.com/windows2000/docs/hyperthreading.doc.
Verify the MDAC version
Make sure that you have MDAC 2.6 or higher installed. You can find the MDAC version on your machine by referring to the information on Microsoft Knowledge Base Article 301202 - HOW TO: Check for MDAC Version. You can download the latest MDAC version from MDAC Downloads
Reboot
When programs crash, they leave the system in an unstable state. This can cause many other problems that seem to have no apparent reason for happening or has not happened before. When the system is rebooted, it resets the system into a more stable state. This should be done after any program crashes.
Verify the information in the event viewer
Sometimes, if a program crashes, it does not give any clues for what had happened. By using the Windows event viewer, it may be possible to find some clue as to what happened when the crash occurred. The event viewer can be launched from Start Programs Administrative Tools Event Viewer.
Verify other programs are interfering with Controller
To find out whether hooked DLLs are possibly causing a problem, you can use a third party utility call "Process Explorer." This utility has the ability to view the DLLs loaded by an application. It can be downloaded free of charge from the following link:
http://www.sysinternals.com/ntw2k/freeware/procexp.shtml
This can be used to see if LoadRunner loaded any other program's DLLs. Use the following steps to do this:
1. Unzip the .zip file, which was downloaded from the above URL, into a directory where you wish to install Process Explorer.
2. Start the Controller.
3. Run the Process Explorer (procexp.exe) from the directory into which you unzipped it (step a).
4. Select wlrun.exe (Controller) from the top section of Process Explorer.
5. The bottom section should be displaying a list of DLLs. If it is showing handles for the application, go to the "View" menu and select "DLLs." It should look like the screenshot below:
6. Search through the list to see if any other program's DLLs are loaded. Normally, only DLLs from the
Shut down all unnecessary processes
Some programs are designed to have certain DLLs "hook" or be loaded into another program's memory space. Normally, this should not have any effect on the application itself. However, it can interfere with some programs and cause them to behave erratically or crash. (Verify if there are other programs that interfering with Controller )
For such, it would be recommended to shut down all processes that are not necessary, regardless if they hook into LoadRunner or not. Any programs that run as an icon in the system tray or on the taskbar are the first candidates for termination. Also, you can look through the list of processes in the Task Manager (right-click on the taskbar and select "Task Manager"). Some processes are system processes, which may not be able to be shut off, but any processes that can be shut down should be.
Disable anti-virus software
It is known that anti-virus software is intrusive when they are set to look for viruses. However, in searching for viruses, the software can interfere with a program's proper execution. This could cause problems and sometimes crashes. This is why, for debugging purposes, we would recommend turning off the anti-virus software.
The icon for the anti-virus software resides in the system tray (where the clock is located). Normally, you should be able to right-click on the icon and select "disable." However, some setups do not allow a user to turn off the anti-virus software. It is recommended to speak to a system administrator to get the anti-virus program disabled for a short period for debugging the problem.
(Verify if there are other programs that interfering with Controller )
Reinstall
In case that all the above steps fail, the only recourse left would be to try to uninstall LoadRunner. It is possible that either a previous version of LoadRunner was on the machine before the current installation or that the installation did not go properly although the installation did not give any errors. It is recommended that a full uninstall be done in this case. The following steps are for a full uninstall:
1. Make sure that, all running LoadRunner processes (including the Controller, VuGen, Analysis and the Remote Command Launcher (for 6.x) or the LoadRunner Agent Process/Service (for 7.x) are closed.
2. Backup any existing scripts that may have been saved in the LoadRunner installation folder (The scripts are sometimes saved in a 'scripts' subdirectory under the LoadRunner installation folder.).
3. Run the uninstall program from the LoadRunner program group (or) use the Windows add/remove programs from the Control Panel. If any prompt is given about removing shared files, remove all the shared dlls that are reported as no longer being in use. In the very rare instance this causes a problem for some other application it may be necessary to re-install that other app. This is not generally a problem because every application should have registered which DLLs it needs to run.
4. Reboot the machine after the Uninstall wizard is complete. This will complete the basic uninstall procedure.
5. Delete all LoadRunner Folders. (Including the ones in the start up menu for Remote Command Launcher (LoadRunner 6.x) or Agent Process (LoadRunner 7.x)
6. If the installation is LoadRunner 6.x then delete the Borland Folder (Usually in c:\Borland or c:\BDE).
7. Do a search for the following files and remove them from all locations -- they will be replaced during the re-install.
a. wlrun.*
b. vugen.*
8. Bring up the registry editor: (Start Run regedit).
9. Delete the following keys:
a. Only for LoadRunner 6.x
HKEY_LOCAL_MACHINE\SOFTWARE\BORLAND
b. If Load Runner is the only Mercury Interactive product on this machine, then delete
HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive.
HKEY_CURRENT_USER\SOFTWARE\Mercury Interactive.
c. Else delete
HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive\LoadRunner.
HKEY_CURRENT_USER\SOFTWARE\Mercury Interactive\LoadRunner.
10. Empty the Recycle-bin.
After you remove these items, you can re-install LoadRunner. Also, make sure that you do not have any anti-virus programs running while you are installing LoadRunner. That has been known to cause some problems with the installation of LoadRunner.
NOTE: Reinstallation should only be done for the following certain circumstances.
1. The crash only happens on a particular machine.
2. Some feature that was previously working is now crashing.
3. The above options were tried before hand.
Modify the heartbeat timeout
In LoadRunner, all hosts manage heartbeat mechanisms with the Controller. By default, each host sends four messages in two minutes with frequency of 30 seconds until heartbeat failure is reached. This could cause a problem when there are a lot of hosts or large data files.
To work around the issue, you need to minimize the heartbeat frequency so that the hosts will send less heartbeat messages to the Controller. Since LoadRunner waits time-out*4 before it reaches heartbeat failure, you can increase the time-out value of the Controller and Load Generator machines (so as to minimize the frequency) or minimize the heartbeat messages.
To minimize the heartbeat messages:
1. Close the Controller, and stop the LoadRunner Agent process/service.
2. Modify the mdrv.dat file in the
3. Add the following lines to the end of [Launcher] section:
ExtCmdLine= -HB_TIMEOUT
ExtCmdLine= -HB_TIMEOUT_LIMIT
Example:
[Launcher] ExtPriorityType=launcher WINNT_EXT_LIBS=launcher.dll WIN95_EXT_LIBS=launcher.dll LINUX_EXT_LIBS=liblauncher.so SOLARIS_EXT_LIBS=liblauncher.so HPUX_EXT_LIBS=liblauncher.sl AIX_EXT_LIBS=liblauncher.so LibCfgFunc=launchext_configure UtilityExt=two_way_comm ExtMessageQueue=0 SecurityMode=On ExtCmdLine= -HB_TIMEOUT 120000 ExtCmdLine= -HB_TIMEOUT_LIMIT 5
Note:
• The "-HB_TIMEOUT 120000" option sets the time-out to send heartbeat messages every 120 seconds.
• The "=-HB_TIMEOUT_LIMIT 5" option sets the number of times to resend heartbeat messages to 5.
4. Repeat steps 2-3 for the mdrv.dat file in
Note:
If you change the heartbeat to be every 2 minutes, the Controller will be able to establish a connection, however since the hosts still send heartbeat messages it cause the UI to get stuck every 2 minutes for half minute.
Make sure that there are sufficient memory available
To check available memory on a machine:
Right-click the status bar, and select Task Manager. Select the Performance tab to check the physical memory available. Select the Processes tab to check which processes have high memory consumption in the CPU column.
To free up memory:
• Close any unnecessary processes running on the machine, and try running the scenario again.
• Restart your computer.
• If the problem persists, reduce the number of virtual users that you are running on the same machine.
To enlarge the size of your virtual memory:
1. Click Start -> Settings -> Control Panel -> System.
a. For Windows 2000, select the Advanced tab, and click Performance Options.
b. For Windows NT, select the Performance tab.
2. In the Virtual memory section, click Change.
3. In the Drive list, click the drive that contains the paging file you want to change.
Under Paging file size for selected drive, type a new paging file size in megabytes in the Maximum size (MB) box, and then click Set.
To boost performance, and allow more Virtual Users to run on the load generator machine:
• On Windows 2000 machines, select Start -> Settings -> Control Panel -> System -> Advanced -> Performance Options, and select the Background Services option.
On Windows NT machines, select Start -> Settings -> Control Panel -> System Properties > Application Performance. S
Introduction to Performance Testing
1.1 Why Performance Testing?
Main purpose of performance test is not to find bugs but to eliminate bottlenecks and establish a baseline for future regression testing.
For a Web application, you need to know at least two things:
• expected load in terms of concurrent users or HTTP connections
• acceptable response time
Once you know where you want to be, you can start on your way there by constantly increasing the load on the system while looking for bottlenecks.
To take again the example of a Web application, these bottlenecks can exist at multiple levels, and to pinpoint them you can use a variety of tools:
• at the application level, developers can use profilers to spot inefficiencies in their code (for example poor search algorithms)
• at the database level, developers and DBAs can use database-specific profilers and query optimizers
• at the operating system level, system engineers can use utilities such as top, vmstat, iostat (on Unix-type systems) and PerfMon (on Windows) to monitor hardware resources such as CPU, memory, swap, disk I/O; specialized kernel monitoring software can also be used
• at the network level, network engineers can use packet sniffers such as tcpdump, network protocol analyzers such as ethereal, and various utilities such as netstat, MRTG, ntop, mii-tool
When the results of the load test indicate that performance of the system does not meet its expected goals, it is time for tuning, starting with the application and the database. You want to make sure your code runs as efficiently as possible and your database is optimized on a given OS/hardware configurations. Another common goal of performance testing is to establish benchmark numbers for the system under test.
Main purpose of performance test is not to find bugs but to eliminate bottlenecks and establish a baseline for future regression testing.
For a Web application, you need to know at least two things:
• expected load in terms of concurrent users or HTTP connections
• acceptable response time
Once you know where you want to be, you can start on your way there by constantly increasing the load on the system while looking for bottlenecks.
To take again the example of a Web application, these bottlenecks can exist at multiple levels, and to pinpoint them you can use a variety of tools:
• at the application level, developers can use profilers to spot inefficiencies in their code (for example poor search algorithms)
• at the database level, developers and DBAs can use database-specific profilers and query optimizers
• at the operating system level, system engineers can use utilities such as top, vmstat, iostat (on Unix-type systems) and PerfMon (on Windows) to monitor hardware resources such as CPU, memory, swap, disk I/O; specialized kernel monitoring software can also be used
• at the network level, network engineers can use packet sniffers such as tcpdump, network protocol analyzers such as ethereal, and various utilities such as netstat, MRTG, ntop, mii-tool
When the results of the load test indicate that performance of the system does not meet its expected goals, it is time for tuning, starting with the application and the database. You want to make sure your code runs as efficiently as possible and your database is optimized on a given OS/hardware configurations. Another common goal of performance testing is to establish benchmark numbers for the system under test.
HP Video LR tips
Tips
The best thing you can do is to record a macro when you import one txt file manual.
Then look at the recorded code and add the code lines to Workbooks.OpenText .
If you want to format or skip a columns then you see you can add FieldInfo in OpenText
FieldInfo:=Array(Array(1, 2), Array(3, 4))
This example change the format of column 1 and 3 (column number, format number)
This are the format numbers
xlGeneralFormat General 1
xlTextFormat Text 2
xlMDYFormat Month-Day-Year 3
xlDMYFormat Day-Month-Year 4
xlYMDFormat Year-Month-Day 5
xlMYDFormat Month-Year-Day 6
xlDYMFormat Day-Year-Month 7
xlYDMFormat Year-Day-Month 8
xlSkipColumn Skip 9
Merge txt files
Replace
Print #1, "Copy " & Chr(34) & foldername & "*.csv" _
With
Print #1, "Copy " & Chr(34) & foldername & "*.txt" _
If you use it for txt files then you can change the delimiter or maybe you want to use FixedWidth.
The best thing you can do is to record a macro when you import one txt file manual.
Then look at the recorded code and add the code lines to Workbooks.OpenText .
More information
Copy every TXT or CSV file that you select in a new worksheet of a newly created workbook
http://www.rondebruin.nl/txtcsv.htm
For more information about importing txt files visit Chip Pearson's site.
http://www.cpearson.com/excel/imptext.htm
Saving XL files as Text/CSV (J.E McGimpsey)
http://www.mcgimpsey.com/excel/textfiles.html
Manual Correlation
Objectives
After completing this you should be able to:
• Determine when manual correlation is required.
• Correlate dynamic values using the create parameter option.
Why Perform Manual Correlation?
Sometimes "Scan for Correlation" fails to find values that must be correlated for proper playback.
Example:
The server returns to the browser a time stamp, formatted as 12:13:14. JScript
in the browser reformats and sends it to the server on the next request as 121314.
Scan for correlation will never find this. The string from the server must exactly match the string to the server.
In such a case, manual correlation is the only solution.
Manual Correlation - Procedure
To perform manual correlation, there are six steps. Each step will be discussed in detail.
1. Play back the script with the ‘Data returned by server’ setting and determine
whether the error is due to correlation.
2. Identify the first step that gets the dynamic value.
3. Determine the value to correlate.
4. Create a parameter for the dynamic value by adding a web_reg_save_param
function to the script.
5. Parameterize the dynamic value in the script every time it occurs.
6. Verify correct execution.
Set Run-time Settings
Figure 11-1 Enable Data Returned by Server in RTS
Correlation issues are best understood by choosing ‘Data returned by server’ within RUN-TIME SETTINGS and playing back the script. This allows you to see the dynamic value in the REPLAY LOG sent out by the server. Viewing the source code in the REPLAY LOG also helps in drilling down to the issue.
If it was not selected before playback, select the script and play back again.
Examine Replay Log
Figure 11-2 Investigate the Replay Log
Play back the script at least once. If there is an error, troubleshoot to confirm that the error is not due to buggy code or another application error. Investigate the REPLAY LOG.
Make a note of the step name that failed.
In the example above, the checkpoint failed, indicating that the text we were looking for could NOT be found on the replay. The next step is to investigate the TEST RESULTS.
1.b Test Results Reveals the Problem
Figure 11-3 Test Result Reveals the Problem
In the example above, the TEST RESULTS reveal that the Checkpoint failed the page was reached incorrectly (probably a bad user session value).
This indicates that the recorded script contains hard-coded data that is dynamic. The solution will be to capture the server-generated number every time the script is run and input it where needed. Correlating the script will allow us to accomplish this.
Determining the Step
Figure 11-4 First Step that Retrieves the Server-Generated Value
Once it is established that an error requires correlation, the next step is to find the step that calls for the server-generated value.
1. Switch to TREE VIEW if in WORKFLOW or SCRIPT VIEW.
2. Double-click on the failed step in the REPLAY LOG. This will take you to the step that has failed in TREE VIEW.
3. Make sure you can see the snapshots, by enabling Snapshot view with VIEW ?
Snapshot ? VIEW SNAPSHOT. Snapshot will appear in the right pane.
4. Click on the VIEW REPLAY SNAPSHOT button , and click the SERVER RESPONSE
tab. Click on the BODY link.
5. The current step shows the snapshot of the login.pl page. Is this the page that gets the session value? Review the message in the snapshot view. The message indicates that you reached the page incorrectly (probably a bad user session value). Therefore, this indicates this is not the step that first retrieves the server-generated number.
6. The previous step - Url: WebTours, is the page that is requesting the session value.
The dynamic value returned by the server should be captured here in a parameter in order to supply the dynamic value to the failed step, “login.pl.“
Determining the Value to Correlate
Figure 11-5 Value to Correlate
1. Display both the Recording and Replay Snapshots for step that first gets the servergenerated data. This allows you to see the different between the record and
playback values.
2. Review the snapshots. In our example, the only difference is the userSession value.
Copying the Dynamic Value
Figure 11-6 Switch to Recording Snapshot
1. Make sure that you are on the step that first gets the server-generated data.
In our example, Url: WebTours step.
2. Switch to SCRIPT VIEW.
3. Locate and copy the dynamic value.
Searching For the Dynamic Value
Figure 11-7 Search for the Dynamic Value
1. Return to TREE VIEW.
2. Select the step where the dynamic value is called from.
3. Switch to the SERVER RESPONSE tab.
4. Click BODY under the SERVER RESPONSE tab.
5. Expand the steps inside of the BODY.
6. Select the step that contains the dynamic value.
7. Press CTRL + F and paste the value into the FIND WHAT box.
8. Click FIND.
9. Keep searching by pressing F3 until you find the number.
Creating a Parameter
Figure 11-8 Create a Parameter
1. Select the entire dynamic value to be correlated.
2. Right-click on the number, then select CREATE PARAMETER from the pop-up
menu.
Parameterize Each Occurrence of Dynamic Value
Figure 11-9 Parameter the Dynamic Value in the Script
1. Click YES on the confirmation message to replace the 1576849332
the hard-coded value with a parameter.
Parameterized Dynamic Value - Script View
Figure 11-10 Parameter Added in Script View
SCRIPT VIEW shows more detail compared to the TREE VIEW. The function
web_reg_save_param adds the parameter to the failed step Submit Data: login.pl.
The parameter “WSCParam_Text1” will capture the dynamic value from the WebTours
step and supply the dynamic value to the failed step.
How does the web_reg_save_param work? When you run the script, the
web_reg_save_param function scans the subsequent HTML page that is accessed. It
searches for an occurrence of the left boundary followed by any string and then followed by the right boundary. When such an occurrence is found, VuGen assigns the string between the left and right boundaries to the parameter named in the function's argument.
After finding the specified number of occurrences, web_reg_save_param does not
search any more HTML pages and continues with the next step in the script.
Reviewing the web_reg_save_param Function
Figure 11-11 Function Arguments
This is the function that is used for correlation (to capture system-generated data and supply it as input data to the required step).
The web_reg_save_param looks for the characters between (but not including) the
specified boundaries and saves the information beginning one byte after the left
boundary and ending one byte before the right boundary.
Where Was the web_reg_save_param Added?
Figure 11-12 Parameter Added in Script View
The web_reg_save_param function is added before the step that first gets the dynamic value.
web_reg_save_param is a registration type function. It registers a request to find and save a text string in a parameter within the web page that was retrieved.
The operation is performed only after executing the next action function. This parameter then supplies the dynamic value to the required step.
Note: When a parameter has been inserted in this way, it appears in green, just like the surrounding text, rather than in purple, as is found when inserted using VuGen’s Insert Parameter feature.
Verifying Correct Execution
Figure 11-13 Replay Log
To verify correct execution, ensure that EXTENDED LOG, PARAMETER SUBSTITUTION
and DATA RETURNED BY SERVER are checked in the RUN-TIME SETTINGS.
During playback, when VuGen executes the web_reg_save_param
statement, three things occur (using the example in the above figure):
1. VuGen creates the parameter "WSCParam_Text1" specified in the first
argument (1).
2. When the next step is executed, VuGen searches the HTML source of that page for the text specified by the left and right boundary arguments in the statement.
3. When the value is found, VuGen places it into the defined parameter
{WSCParam_Text1}.
Thereafter, whenever VuGen encounters a reference to {WSCParam_Text1} in the
script, it will plug in the value stored in the parameter.
Summary
how to:
• Determine when manual correlation is required.
• Correlate dynamic values using the create parameter option.
Auto Correlation During Recording
Objectives
After completing this you should be able to:
• Create correlation rules to auto correlate during recording.
• Import and export correlation rules.
When to Correlate During Recording
Figure 12-1 Existing Correlation Rules
Correlate during recording when:
• The web application server is on the RECORDING OPTIONS list of known server
types (to handle session data).
• You can determine rules for correlation because context is known in advance.
About Automatic Correlation During Recording
• VuGen can correlate dynamic data based on predefined rules in the Recording
Options.
• Define correlation options before you record a script.
• If server-generated data gets re-used by the client, VuGen automatically correlates it (or prompts the user to choose between correlating while recording or later).
Determining Which Correlation Method to Use
• After every recording, you find the script requires correlation. You may continue to correlate using the after recording correlation method.
or
• You may create a custom correlation rule to correlate during recording if the
context is known in advance. This will be a one-time task. After setup, all future recordings will add the correlation in the script during recording.
Note: Correlating during or after recording results in the same script. It is just a matter of which method you prefer.
Correlating During Recording – Procedure
To define a new rule and set the recording options to correlate during recording:
1. ENABLE CORRELATION DURING RECORDING in Recording Options.
2. Create a new application.
3. Create a new rule for the newly created application. Define properties for the new rule.
4. Record the script.
5. Play back the script to verify correct execution.
To instruct VuGen to correlate your statements during recording, use one of the
following methods:
1. Built-in Correlation
2. User-Defined Rule Correlation (the focus of this lesson)
The above steps are for creating a user-defined correlation rule. Define the rule before you begin the recording session.
If the application has unique rules and you are able to determine them, you can define correlation rules using the Recording Options. User-defined rules must be created before you record a session. Create the rules in the Recording Options dialog box. The rules include information, such as the boundaries of the dynamic data you want to correlate and specifications about the match, such as binary, case matching, and the instance number.
Another time to define an auto-correlation rule is when the same correlated values are seen multiple times in the script or across different recordings. Once the rules are determined through auto-correlation after recording or manual correlation, they can be added to the correlation rules. This avoids having to manually correlate or scan for correlations after each recording.
Enabling Correlation During Recording
Figure 12-2 Enable Correlation Rules
Before recording the script, perform the following steps:
1. Open the RECORDING OPTIONS dialog by selecting TOOLS ? RECORDING
OPTIONS
2. Select the CORRELATION node.
3. Check ENABLE CORRELATION DURING RECORDING. If the application server
exists in the list, indicate the servers to which the correlation rules apply.
Select the checkboxes next to the server names to enable rules for that server. If the server name is not in the list, continue with the steps to create correlation rules for your application.
Creating a New Application
Figure 12-3 Create New Application WebTours
1. Select an application from the list or click NEW APPLICATION and enter a
meaningful name.
Creating a New Rule
Figure 12-4 Create New Rule
2. Click the NEW RULE button. A new rule is added under the newly created
application.
Defining Properties for the New Rule
Figure 12-5 Define Properties for the New Rule
In the Actions option, instruct VuGen where to search for the criteria. Select an ACTION from the list.
Parameter Prefix: Uses a prefix in all automatically generated parameters based on this rule. Prefixes prevent you from overwriting existing user parameters. In addition, prefixes allow you to recognize the parameter in your script more easily.
For example, in Siebel-Web, one of the built-in rules searches for Siebel_row_id prefix.
Match Case: Matches the case when looking for boundaries.
Use "#" for any digit: Replaces all digits with a hash sign. This will allow you to find text strings that match everything except for numerical digits. For example, if the left boundary is HP193, it will be matched with HP284. In the left boundary box, specify HP###.
Regenerating the Script
Figure 12-6 Regenerate the Script
If you have already recorded the script, then created the rules, simply regenerate the script to apply the newly created correlation rule to the script.
Note: This will overwrite ANY custom changes that have been made. It is
recommended to save the script as a different name before regenerating the script.
1. Select TOOLS ? REGENERATE SCRIPT and click OK on the pop-up message.
2. The rule will automatically add the correlation to the script.
Recording a New Script
Figure 12-7 Correlation Rule Auto Applies to the New Script
After creating the rule when you record a new script, the rule is automatically applied and correlates the script.
Note: Make sure to check ENABLE CORRELATION DURING RECORDING in the
RECORDING OPTIONS.
Creating Rules after Correlation Scan
Figure 12-8 Another Approach to Creating Correlation Rules
The second method of creating a rule allows you to create a rule from one of the detected correlation results. You can create a rule directly from the CORRELATED RESULTS tab.
1. Play back the script at least once.
2. Once the script fails, determine if the error needs to be correlated.
3. Scan the script for dynamic values.
4. Select the correlation result and click CREATE RULE. This is also available from the right-click menu. VuGen displays the properties based on which rule will be created. VuGen adds this rule to the list of Correlation Studio rules. You can view this rule in the RECORDING OPTIONS - CORRELATION node.
Adding the rule will not correlate the current script. You will still have to correlate the script by clicking on the correlate button. The rule will be applied the next time you record a script.
Exporting and Importing Rules
Figure 12-9 Export Then Import Correlation Rules
Once custom rules are created, they can be exported from the machine where the rules were created and imported onto the machine that needs the custom rules.
As a best practice, make sure that one person creates the custom correlation rule and that other script writers import the rule to their machine.
Exporting Rules
Figure 12-10 Select the Rule to Export
To export a set of correlation rules, or just one rule, do the following:
1. Select TOOLS ? RECORDING OPTIONS and select the INTERNET PROTOCOL:
CORRELATION node in the Recording Options tree.
2. Select the ENABLE CORRELATION DURING RECORDING option.
3. Click the EXPORT button. The CHOOSE APPLICATION TO EXPORT window opens.
4. Select the rules to export.
5. Click EXPORT on the CHOOSE APPLICATION TO EXPORT window.
6. Choose a desired location and file name. The file will be saved with the .cor
extension.
Importing Rules
Figure 12-11 Import Rule
To import a set of correlation rules:
1. Click the IMPORT button. The IMPORT CORRELATION SETTINGS FROM A FILE
window opens.
2. Select the file and click on the OPEN button. This will import the custom correlation rules to the new machine.
Summary
how to:
• Create correlation rules to auto correlate during recording.
• Import and export correlation rules.
Advanced Manual Correlation
Objectives
After completing this you should be able to:
• Correlate a script by manually using WDiff.
• Manually insert the web_reg_save_param correlation function.
• Parameterize the dynamic value in a script.
Manual Correlation – Procedure
To perform manual correlation, there are six steps. Each step will be discussed in detail.
1. Play back the script with ‘Data returned by server’ and determine if error is due to correlation.
2. Determine which dynamic values to correlate using WDiff.
3. Find the left boundary, right boundary and occurrence of the dynamic value.
4. Add web_reg_save_param function to the script.
5. Parameterize the dynamic value in the script every time it occurs.
6. Verify correct execution.
Playing Back the Script with ‘Data returned by server’
Figure A-12 Enable Data Returned by Server in RTS
Correlation issues are best understood by choosing ‘Data returned by server’ within Run-time Settings and playing back the script. This allows you to see the dynamic value in the REPLAY LOG sent out by the server. Viewing the source code in the REPLAY LOG also helps in drilling down to the issue.
If the ‘Data returned by server’ was not selected before playback, select the option and replay the script again.
Investigating Errors in the Replay Log
Figure A-13 Investigate the Error
Play back the script at least once with ‘Data returned by server’ RUN-TIME SETTINGS. If there is an error, troubleshoot to confirm that the error is not due to buggy code or another application error. Investigate the REPLAY LOG - make a note of the step name that failed.
In the example, the checkpoint failed, indicating that the text you were looking for could NOT be found on the replay. So the next step is to investigate the TEST RESULTS.
Investigating the Test Results
Figure A-14 Test Results Reveal the Problem
In the example above, the TEST RESULTS reveal the Checkpoint failed because the page was reached incorrectly (probably a bad user session value).
This indicates that the recorded script contains hard-coded data that is dynamic. The solution will be to capture the server-generated number every time the script is run and input it where needed. You can accomplish this by correlating the script.
Comparing two Scripts Using WDiff
Figure A-15 Wdiff Highlights the Differences
Once it is established that the error requires correlation, the next step is to find the dynamic values to be correlated.
This lesson will show you how to use the WDiff utility to find the values. To determine which values are dynamic in the application but hard-coded in the script, complete the following steps:
1. Create two scripts with the same user steps. The idea is to compare the contents of two nearly identical scripts to see which recorded values are different.
2. Select TOOLS ? COMPARE WITH VUSER. This opens the OPEN VUSER USER
dialog. Select the twin script from the dialog. VuGen compares the script currently visible with the script you selected. All the differences are highlighted in yellow.
Identifying Values for Correlation
Figure A-16 Values to Correlate
Wdiff highlighted differences between the two scripts.
If you see many lines highlighted in yellow, correlate only the values to be reused. At this point, help from developer, DBA, or functional expert may be useful to identify which values are reused by the business process.
Copying Dynamic Value
Figure A-17 Copy the Value into Notepad
Copy the dynamic value from WDiff original script to Notepad. This value can then be used to search in the GENERATION LOG to find the left and right boundaries.
Crtl+C does not work in WDiff, so highlight the line you want copied, then select
EDIT ? COPY. Paste the line in Notepad and make sure to copy only the dynamic value from Notepad.
In this example, the dynamic value is 96447.9789388416tQzVAtcpQVzzzzzHcQHzzpcfHf.
Identifying Left and Right Boundaries
Figure A-18 Search for the Dynamic String in Generation Log
1. Click the GENERATION LOG.
2. Open the FIND dialog (Ctrl+F).
3. Paste the copied value 96447.9789388416tQzVAtcpQVzzzzzHcQHzzpcfHf into
the FIND WHAT box.
4. Click the FIND button.
Once the value is found, note the right and left boundaries. Include the use space as part of the boundaries, if necessary.
Try to keep one of the boundaries long enough to be uniquely identified. The longer one of the boundaries, the less likely that you will have to use the ORD (occurrence) argument.
Note: In SCRIPT VIEW, certain characters (such as the double quotation marks) have special functions. To include such a character as part of boundary text, precede that character with a backslash. In script functions, the backslash indicates that the character which follows is meant to be processed as text.
Determining Location of Correlation Function
Figure A-19 Determine the Step
1. Double-click on the error in the REPLAY LOG. This will take you to the failed step.
2. The snapshot for the failed step: Submit Data: login.pl. This shows the action
that happened after the value was entered. This proves it is not the step that needs correlation.
3. Click on the previous step: Url: WebTours. This step retrieves the dynamic value.
This is the step that needs to be correlated so that the dynamic value returned by the server can be captured in a parameter and supply the dynamic value to the failed step.
Adding the web_reg_save_param Function
Figure A-20 Parameter Added in Script View
To add the function to the script:
1. First, position the cursor above the step that retrieves the dynamic data. In our
example, Url: WebTours.
2. Select INSERT ? NEW STEP. Enter web_reg_save_param in the FIND FUNCTION
field. Complete the PARAMETER NAME, LEFT BOUNDARY, and RIGHT BOUNDARY
fields. Click the OK button.
Note: Provide a meaningful name to the PARAMETER NAME value.
Parameterizing the Dynamic Value in the Script
Figure A-21 Parameter Added
Replace the hard-coded value of the parameter name you created in the
web_reg_save_param.
web_reg_save_param is a registration function. It registers a request to find and save a text string in a parameter within the web page that retrieves the value.
The operation is performed only after executing the next action function. This parameter then supplies the dynamic value to the required step.
Note: When a parameter has been inserted in this way, it appears in green - just like the surrounding text - rather than in purple as used when inserted via VuGen’s Insert Parameter feature.
Verifying Correct Execution
Figure A-22 Replay Log
To verify correct execution, ensure that EXTENDED LOG, PARAMETER SUBSTITUTION,
and DATA RETURNED BY SERVER are checked in the RUN-TIME SETTINGS.
During playback, when VuGen executes the web_reg_save_param
statement, three things occur (using the example in the above figure):
1. VuGen creates the parameter "SessionValue" specified in the first argument of the
web_reg_save_param function.
2. When the next step is executed, VuGen searches the HTML source of that page for
the text specified by the left and right boundary arguments in the statement.
3. When the value is found, VuGen places it into the defined parameter
{SessionValue}.
Thereafter, whenever VuGen encounters a reference to {SessionValue} in the script, it
will replace the value with the parameter’s value.
Summary
How to:
• Correlate a script by manually using WDiff.
• Manually insert the web_reg_save_param correlation function.
• Parameterize the dynamic value in a script.
The best thing you can do is to record a macro when you import one txt file manual.
Then look at the recorded code and add the code lines to Workbooks.OpenText .
If you want to format or skip a columns then you see you can add FieldInfo in OpenText
FieldInfo:=Array(Array(1, 2), Array(3, 4))
This example change the format of column 1 and 3 (column number, format number)
This are the format numbers
xlGeneralFormat General 1
xlTextFormat Text 2
xlMDYFormat Month-Day-Year 3
xlDMYFormat Day-Month-Year 4
xlYMDFormat Year-Month-Day 5
xlMYDFormat Month-Year-Day 6
xlDYMFormat Day-Year-Month 7
xlYDMFormat Year-Day-Month 8
xlSkipColumn Skip 9
Merge txt files
Replace
Print #1, "Copy " & Chr(34) & foldername & "*.csv" _
With
Print #1, "Copy " & Chr(34) & foldername & "*.txt" _
If you use it for txt files then you can change the delimiter or maybe you want to use FixedWidth.
The best thing you can do is to record a macro when you import one txt file manual.
Then look at the recorded code and add the code lines to Workbooks.OpenText .
More information
Copy every TXT or CSV file that you select in a new worksheet of a newly created workbook
http://www.rondebruin.nl/txtcsv.htm
For more information about importing txt files visit Chip Pearson's site.
http://www.cpearson.com/excel/imptext.htm
Saving XL files as Text/CSV (J.E McGimpsey)
http://www.mcgimpsey.com/excel/textfiles.html
Manual Correlation
Objectives
After completing this you should be able to:
• Determine when manual correlation is required.
• Correlate dynamic values using the create parameter option.
Why Perform Manual Correlation?
Sometimes "Scan for Correlation" fails to find values that must be correlated for proper playback.
Example:
The server returns to the browser a time stamp, formatted as 12:13:14. JScript
in the browser reformats and sends it to the server on the next request as 121314.
Scan for correlation will never find this. The string from the server must exactly match the string to the server.
In such a case, manual correlation is the only solution.
Manual Correlation - Procedure
To perform manual correlation, there are six steps. Each step will be discussed in detail.
1. Play back the script with the ‘Data returned by server’ setting and determine
whether the error is due to correlation.
2. Identify the first step that gets the dynamic value.
3. Determine the value to correlate.
4. Create a parameter for the dynamic value by adding a web_reg_save_param
function to the script.
5. Parameterize the dynamic value in the script every time it occurs.
6. Verify correct execution.
Set Run-time Settings
Figure 11-1 Enable Data Returned by Server in RTS
Correlation issues are best understood by choosing ‘Data returned by server’ within RUN-TIME SETTINGS and playing back the script. This allows you to see the dynamic value in the REPLAY LOG sent out by the server. Viewing the source code in the REPLAY LOG also helps in drilling down to the issue.
If it was not selected before playback, select the script and play back again.
Examine Replay Log
Figure 11-2 Investigate the Replay Log
Play back the script at least once. If there is an error, troubleshoot to confirm that the error is not due to buggy code or another application error. Investigate the REPLAY LOG.
Make a note of the step name that failed.
In the example above, the checkpoint failed, indicating that the text we were looking for could NOT be found on the replay. The next step is to investigate the TEST RESULTS.
1.b Test Results Reveals the Problem
Figure 11-3 Test Result Reveals the Problem
In the example above, the TEST RESULTS reveal that the Checkpoint failed the page was reached incorrectly (probably a bad user session value).
This indicates that the recorded script contains hard-coded data that is dynamic. The solution will be to capture the server-generated number every time the script is run and input it where needed. Correlating the script will allow us to accomplish this.
Determining the Step
Figure 11-4 First Step that Retrieves the Server-Generated Value
Once it is established that an error requires correlation, the next step is to find the step that calls for the server-generated value.
1. Switch to TREE VIEW if in WORKFLOW or SCRIPT VIEW.
2. Double-click on the failed step in the REPLAY LOG. This will take you to the step that has failed in TREE VIEW.
3. Make sure you can see the snapshots, by enabling Snapshot view with VIEW ?
Snapshot ? VIEW SNAPSHOT. Snapshot will appear in the right pane.
4. Click on the VIEW REPLAY SNAPSHOT button , and click the SERVER RESPONSE
tab. Click on the BODY link.
5. The current step shows the snapshot of the login.pl page. Is this the page that gets the session value? Review the message in the snapshot view. The message indicates that you reached the page incorrectly (probably a bad user session value). Therefore, this indicates this is not the step that first retrieves the server-generated number.
6. The previous step - Url: WebTours, is the page that is requesting the session value.
The dynamic value returned by the server should be captured here in a parameter in order to supply the dynamic value to the failed step, “login.pl.“
Determining the Value to Correlate
Figure 11-5 Value to Correlate
1. Display both the Recording and Replay Snapshots for step that first gets the servergenerated data. This allows you to see the different between the record and
playback values.
2. Review the snapshots. In our example, the only difference is the userSession value.
Copying the Dynamic Value
Figure 11-6 Switch to Recording Snapshot
1. Make sure that you are on the step that first gets the server-generated data.
In our example, Url: WebTours step.
2. Switch to SCRIPT VIEW.
3. Locate and copy the dynamic value.
Searching For the Dynamic Value
Figure 11-7 Search for the Dynamic Value
1. Return to TREE VIEW.
2. Select the step where the dynamic value is called from.
3. Switch to the SERVER RESPONSE tab.
4. Click BODY under the SERVER RESPONSE tab.
5. Expand the steps inside of the BODY.
6. Select the step that contains the dynamic value.
7. Press CTRL + F and paste the value into the FIND WHAT box.
8. Click FIND.
9. Keep searching by pressing F3 until you find the number.
Creating a Parameter
Figure 11-8 Create a Parameter
1. Select the entire dynamic value to be correlated.
2. Right-click on the number, then select CREATE PARAMETER from the pop-up
menu.
Parameterize Each Occurrence of Dynamic Value
Figure 11-9 Parameter the Dynamic Value in the Script
1. Click YES on the confirmation message to replace the 1576849332
the hard-coded value with a parameter.
Parameterized Dynamic Value - Script View
Figure 11-10 Parameter Added in Script View
SCRIPT VIEW shows more detail compared to the TREE VIEW. The function
web_reg_save_param adds the parameter to the failed step Submit Data: login.pl.
The parameter “WSCParam_Text1” will capture the dynamic value from the WebTours
step and supply the dynamic value to the failed step.
How does the web_reg_save_param work? When you run the script, the
web_reg_save_param function scans the subsequent HTML page that is accessed. It
searches for an occurrence of the left boundary followed by any string and then followed by the right boundary. When such an occurrence is found, VuGen assigns the string between the left and right boundaries to the parameter named in the function's argument.
After finding the specified number of occurrences, web_reg_save_param does not
search any more HTML pages and continues with the next step in the script.
Reviewing the web_reg_save_param Function
Figure 11-11 Function Arguments
This is the function that is used for correlation (to capture system-generated data and supply it as input data to the required step).
The web_reg_save_param looks for the characters between (but not including) the
specified boundaries and saves the information beginning one byte after the left
boundary and ending one byte before the right boundary.
Where Was the web_reg_save_param Added?
Figure 11-12 Parameter Added in Script View
The web_reg_save_param function is added before the step that first gets the dynamic value.
web_reg_save_param is a registration type function. It registers a request to find and save a text string in a parameter within the web page that was retrieved.
The operation is performed only after executing the next action function. This parameter then supplies the dynamic value to the required step.
Note: When a parameter has been inserted in this way, it appears in green, just like the surrounding text, rather than in purple, as is found when inserted using VuGen’s Insert Parameter feature.
Verifying Correct Execution
Figure 11-13 Replay Log
To verify correct execution, ensure that EXTENDED LOG, PARAMETER SUBSTITUTION
and DATA RETURNED BY SERVER are checked in the RUN-TIME SETTINGS.
During playback, when VuGen executes the web_reg_save_param
statement, three things occur (using the example in the above figure):
1. VuGen creates the parameter "WSCParam_Text1" specified in the first
argument (1).
2. When the next step is executed, VuGen searches the HTML source of that page for the text specified by the left and right boundary arguments in the statement.
3. When the value is found, VuGen places it into the defined parameter
{WSCParam_Text1}.
Thereafter, whenever VuGen encounters a reference to {WSCParam_Text1} in the
script, it will plug in the value stored in the parameter.
Summary
how to:
• Determine when manual correlation is required.
• Correlate dynamic values using the create parameter option.
Auto Correlation During Recording
Objectives
After completing this you should be able to:
• Create correlation rules to auto correlate during recording.
• Import and export correlation rules.
When to Correlate During Recording
Figure 12-1 Existing Correlation Rules
Correlate during recording when:
• The web application server is on the RECORDING OPTIONS list of known server
types (to handle session data).
• You can determine rules for correlation because context is known in advance.
About Automatic Correlation During Recording
• VuGen can correlate dynamic data based on predefined rules in the Recording
Options.
• Define correlation options before you record a script.
• If server-generated data gets re-used by the client, VuGen automatically correlates it (or prompts the user to choose between correlating while recording or later).
Determining Which Correlation Method to Use
• After every recording, you find the script requires correlation. You may continue to correlate using the after recording correlation method.
or
• You may create a custom correlation rule to correlate during recording if the
context is known in advance. This will be a one-time task. After setup, all future recordings will add the correlation in the script during recording.
Note: Correlating during or after recording results in the same script. It is just a matter of which method you prefer.
Correlating During Recording – Procedure
To define a new rule and set the recording options to correlate during recording:
1. ENABLE CORRELATION DURING RECORDING in Recording Options.
2. Create a new application.
3. Create a new rule for the newly created application. Define properties for the new rule.
4. Record the script.
5. Play back the script to verify correct execution.
To instruct VuGen to correlate your statements during recording, use one of the
following methods:
1. Built-in Correlation
2. User-Defined Rule Correlation (the focus of this lesson)
The above steps are for creating a user-defined correlation rule. Define the rule before you begin the recording session.
If the application has unique rules and you are able to determine them, you can define correlation rules using the Recording Options. User-defined rules must be created before you record a session. Create the rules in the Recording Options dialog box. The rules include information, such as the boundaries of the dynamic data you want to correlate and specifications about the match, such as binary, case matching, and the instance number.
Another time to define an auto-correlation rule is when the same correlated values are seen multiple times in the script or across different recordings. Once the rules are determined through auto-correlation after recording or manual correlation, they can be added to the correlation rules. This avoids having to manually correlate or scan for correlations after each recording.
Enabling Correlation During Recording
Figure 12-2 Enable Correlation Rules
Before recording the script, perform the following steps:
1. Open the RECORDING OPTIONS dialog by selecting TOOLS ? RECORDING
OPTIONS
2. Select the CORRELATION node.
3. Check ENABLE CORRELATION DURING RECORDING. If the application server
exists in the list, indicate the servers to which the correlation rules apply.
Select the checkboxes next to the server names to enable rules for that server. If the server name is not in the list, continue with the steps to create correlation rules for your application.
Creating a New Application
Figure 12-3 Create New Application WebTours
1. Select an application from the list or click NEW APPLICATION and enter a
meaningful name.
Creating a New Rule
Figure 12-4 Create New Rule
2. Click the NEW RULE button. A new rule is added under the newly created
application.
Defining Properties for the New Rule
Figure 12-5 Define Properties for the New Rule
In the Actions option, instruct VuGen where to search for the criteria. Select an ACTION from the list.
Parameter Prefix: Uses a prefix in all automatically generated parameters based on this rule. Prefixes prevent you from overwriting existing user parameters. In addition, prefixes allow you to recognize the parameter in your script more easily.
For example, in Siebel-Web, one of the built-in rules searches for Siebel_row_id prefix.
Match Case: Matches the case when looking for boundaries.
Use "#" for any digit: Replaces all digits with a hash sign. This will allow you to find text strings that match everything except for numerical digits. For example, if the left boundary is HP193, it will be matched with HP284. In the left boundary box, specify HP###.
Regenerating the Script
Figure 12-6 Regenerate the Script
If you have already recorded the script, then created the rules, simply regenerate the script to apply the newly created correlation rule to the script.
Note: This will overwrite ANY custom changes that have been made. It is
recommended to save the script as a different name before regenerating the script.
1. Select TOOLS ? REGENERATE SCRIPT and click OK on the pop-up message.
2. The rule will automatically add the correlation to the script.
Recording a New Script
Figure 12-7 Correlation Rule Auto Applies to the New Script
After creating the rule when you record a new script, the rule is automatically applied and correlates the script.
Note: Make sure to check ENABLE CORRELATION DURING RECORDING in the
RECORDING OPTIONS.
Creating Rules after Correlation Scan
Figure 12-8 Another Approach to Creating Correlation Rules
The second method of creating a rule allows you to create a rule from one of the detected correlation results. You can create a rule directly from the CORRELATED RESULTS tab.
1. Play back the script at least once.
2. Once the script fails, determine if the error needs to be correlated.
3. Scan the script for dynamic values.
4. Select the correlation result and click CREATE RULE. This is also available from the right-click menu. VuGen displays the properties based on which rule will be created. VuGen adds this rule to the list of Correlation Studio rules. You can view this rule in the RECORDING OPTIONS - CORRELATION node.
Adding the rule will not correlate the current script. You will still have to correlate the script by clicking on the correlate button. The rule will be applied the next time you record a script.
Exporting and Importing Rules
Figure 12-9 Export Then Import Correlation Rules
Once custom rules are created, they can be exported from the machine where the rules were created and imported onto the machine that needs the custom rules.
As a best practice, make sure that one person creates the custom correlation rule and that other script writers import the rule to their machine.
Exporting Rules
Figure 12-10 Select the Rule to Export
To export a set of correlation rules, or just one rule, do the following:
1. Select TOOLS ? RECORDING OPTIONS and select the INTERNET PROTOCOL:
CORRELATION node in the Recording Options tree.
2. Select the ENABLE CORRELATION DURING RECORDING option.
3. Click the EXPORT button. The CHOOSE APPLICATION TO EXPORT window opens.
4. Select the rules to export.
5. Click EXPORT on the CHOOSE APPLICATION TO EXPORT window.
6. Choose a desired location and file name. The file will be saved with the .cor
extension.
Importing Rules
Figure 12-11 Import Rule
To import a set of correlation rules:
1. Click the IMPORT button. The IMPORT CORRELATION SETTINGS FROM A FILE
window opens.
2. Select the file and click on the OPEN button. This will import the custom correlation rules to the new machine.
Summary
how to:
• Create correlation rules to auto correlate during recording.
• Import and export correlation rules.
Advanced Manual Correlation
Objectives
After completing this you should be able to:
• Correlate a script by manually using WDiff.
• Manually insert the web_reg_save_param correlation function.
• Parameterize the dynamic value in a script.
Manual Correlation – Procedure
To perform manual correlation, there are six steps. Each step will be discussed in detail.
1. Play back the script with ‘Data returned by server’ and determine if error is due to correlation.
2. Determine which dynamic values to correlate using WDiff.
3. Find the left boundary, right boundary and occurrence of the dynamic value.
4. Add web_reg_save_param function to the script.
5. Parameterize the dynamic value in the script every time it occurs.
6. Verify correct execution.
Playing Back the Script with ‘Data returned by server’
Figure A-12 Enable Data Returned by Server in RTS
Correlation issues are best understood by choosing ‘Data returned by server’ within Run-time Settings and playing back the script. This allows you to see the dynamic value in the REPLAY LOG sent out by the server. Viewing the source code in the REPLAY LOG also helps in drilling down to the issue.
If the ‘Data returned by server’ was not selected before playback, select the option and replay the script again.
Investigating Errors in the Replay Log
Figure A-13 Investigate the Error
Play back the script at least once with ‘Data returned by server’ RUN-TIME SETTINGS. If there is an error, troubleshoot to confirm that the error is not due to buggy code or another application error. Investigate the REPLAY LOG - make a note of the step name that failed.
In the example, the checkpoint failed, indicating that the text you were looking for could NOT be found on the replay. So the next step is to investigate the TEST RESULTS.
Investigating the Test Results
Figure A-14 Test Results Reveal the Problem
In the example above, the TEST RESULTS reveal the Checkpoint failed because the page was reached incorrectly (probably a bad user session value).
This indicates that the recorded script contains hard-coded data that is dynamic. The solution will be to capture the server-generated number every time the script is run and input it where needed. You can accomplish this by correlating the script.
Comparing two Scripts Using WDiff
Figure A-15 Wdiff Highlights the Differences
Once it is established that the error requires correlation, the next step is to find the dynamic values to be correlated.
This lesson will show you how to use the WDiff utility to find the values. To determine which values are dynamic in the application but hard-coded in the script, complete the following steps:
1. Create two scripts with the same user steps. The idea is to compare the contents of two nearly identical scripts to see which recorded values are different.
2. Select TOOLS ? COMPARE WITH VUSER. This opens the OPEN VUSER USER
dialog. Select the twin script from the dialog. VuGen compares the script currently visible with the script you selected. All the differences are highlighted in yellow.
Identifying Values for Correlation
Figure A-16 Values to Correlate
Wdiff highlighted differences between the two scripts.
If you see many lines highlighted in yellow, correlate only the values to be reused. At this point, help from developer, DBA, or functional expert may be useful to identify which values are reused by the business process.
Copying Dynamic Value
Figure A-17 Copy the Value into Notepad
Copy the dynamic value from WDiff original script to Notepad. This value can then be used to search in the GENERATION LOG to find the left and right boundaries.
Crtl+C does not work in WDiff, so highlight the line you want copied, then select
EDIT ? COPY. Paste the line in Notepad and make sure to copy only the dynamic value from Notepad.
In this example, the dynamic value is 96447.9789388416tQzVAtcpQVzzzzzHcQHzzpcfHf.
Identifying Left and Right Boundaries
Figure A-18 Search for the Dynamic String in Generation Log
1. Click the GENERATION LOG.
2. Open the FIND dialog (Ctrl+F).
3. Paste the copied value 96447.9789388416tQzVAtcpQVzzzzzHcQHzzpcfHf into
the FIND WHAT box.
4. Click the FIND button.
Once the value is found, note the right and left boundaries. Include the use space as part of the boundaries, if necessary.
Try to keep one of the boundaries long enough to be uniquely identified. The longer one of the boundaries, the less likely that you will have to use the ORD (occurrence) argument.
Note: In SCRIPT VIEW, certain characters (such as the double quotation marks) have special functions. To include such a character as part of boundary text, precede that character with a backslash. In script functions, the backslash indicates that the character which follows is meant to be processed as text.
Determining Location of Correlation Function
Figure A-19 Determine the Step
1. Double-click on the error in the REPLAY LOG. This will take you to the failed step.
2. The snapshot for the failed step: Submit Data: login.pl. This shows the action
that happened after the value was entered. This proves it is not the step that needs correlation.
3. Click on the previous step: Url: WebTours. This step retrieves the dynamic value.
This is the step that needs to be correlated so that the dynamic value returned by the server can be captured in a parameter and supply the dynamic value to the failed step.
Adding the web_reg_save_param Function
Figure A-20 Parameter Added in Script View
To add the function to the script:
1. First, position the cursor above the step that retrieves the dynamic data. In our
example, Url: WebTours.
2. Select INSERT ? NEW STEP. Enter web_reg_save_param in the FIND FUNCTION
field. Complete the PARAMETER NAME, LEFT BOUNDARY, and RIGHT BOUNDARY
fields. Click the OK button.
Note: Provide a meaningful name to the PARAMETER NAME value.
Parameterizing the Dynamic Value in the Script
Figure A-21 Parameter Added
Replace the hard-coded value of the parameter name you created in the
web_reg_save_param.
web_reg_save_param is a registration function. It registers a request to find and save a text string in a parameter within the web page that retrieves the value.
The operation is performed only after executing the next action function. This parameter then supplies the dynamic value to the required step.
Note: When a parameter has been inserted in this way, it appears in green - just like the surrounding text - rather than in purple as used when inserted via VuGen’s Insert Parameter feature.
Verifying Correct Execution
Figure A-22 Replay Log
To verify correct execution, ensure that EXTENDED LOG, PARAMETER SUBSTITUTION,
and DATA RETURNED BY SERVER are checked in the RUN-TIME SETTINGS.
During playback, when VuGen executes the web_reg_save_param
statement, three things occur (using the example in the above figure):
1. VuGen creates the parameter "SessionValue" specified in the first argument of the
web_reg_save_param function.
2. When the next step is executed, VuGen searches the HTML source of that page for
the text specified by the left and right boundary arguments in the statement.
3. When the value is found, VuGen places it into the defined parameter
{SessionValue}.
Thereafter, whenever VuGen encounters a reference to {SessionValue} in the script, it
will replace the value with the parameter’s value.
Summary
How to:
• Correlate a script by manually using WDiff.
• Manually insert the web_reg_save_param correlation function.
• Parameterize the dynamic value in a script.
Subscribe to:
Posts (Atom)