Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE
Highlighted
Absent Member.. MisterT1968 Absent Member..
Absent Member..
372 views

QTP/(U)FT Support Tip: How to avoid Virtual Memory errors occur during long test runs?

Hello all,

 

How are you? I hope you are fine

 

QuickTest Professional and (Unified) Functional Testing are known to generate Virtual Memory errors. However, it has shown, that most of these errors could be easily avoided. In the situation, where these errors occur, a long test run has several iterations, or runs for several hours, or both. Each Add-In may impact differently the amount of iterations and time before the memory conflicts appear.

 

The following can contribute to the Virtual Memory errors:

 

- Variables and functions/subs are defined within Actions used in the script. These Actions can be reusable or local.
- QuickTest Professional's memory is not released during the test run.
- The application under testing (AUT) memory is not released during the test run.

 

1. Variables and functions/subs are defined within Actions used in the script

 

If you define variables, functions, or subs within Actions, move them into a .vbs library file, and associate that file with the test script.

 

Every time (iteration) the Action is executed, memory is allocated for the variables, functions, and subs that are defined within it. It appears that this memory is not released until QuickTest Professional closes.

 

Example scenario 1:


The test has one Action, Action1, that iterates through 2000 iterations. Within Action1, 10 variables are declared. After the 2000 iterations, memory will have been allocated for 20000 variables.

 

Example scenario 2:

Action1 (main "driver" action)
|______ Action2 (action local to test)
            |______ Reusable Action3 (called reusable action)
                        |______ Reusable Action4 (called reusable action)
|______ Action5 (action local to test)

 

Assume Action3 iterates through 2000 iterations. Assume Action4, which is called by Action3, only iterates once each time it is called. Both Actions declare 10 variables. When only those two Actions are executed, memory will have been allocated for 40000 variables:

 

- From Action3: 2000 iterations * 10 variables
- From Action4: 2000 iterations (enforced by Action3) * 10 variables
- Combined: 40000 variables

 

Now assume that Action4 iterates 10 times. After running only Action3 and Action4, memory will have been allocated for 220000 variables:

 

- From Action3: 2000 iterations * 10 variables
- From Action4: 2000 iterations (enforced by Action3) * 10 iterations * 10 variables
- Combined: 220000 variables.

 

To help reduce the memory allocation, move variable, constant, and function/sub declarations into a VBScript library file (both .vbs and .txt extensions will work) and load the library file in the test settings. Here are the lines that should be moved from the Actions into the library file:

 

- Constant declarations ("const" statements)
- Variable declarations ("Dim" statements)
- Function and Sub declarations

 

All variables and functions can be placed in the same file. Once the functions and variables are in the library file, you can associate the file with the test. For more information on using function library files, refer to Document ID 26025 - How to create a VBScript library file and Document ID 22314 - How to load a VBScript library file for use with a script. When the script is replayed, the memory for the variables and functions will be allocated once and will be available as needed for the entire test script.

 

Note: Memory usage may still increase during replay, but it should be slower.

 

Using the examples above, memory will be allocated for 10 variables in scenario 1 and for a total of 50 variables in scenario 2 (for all Actions; 20 variables for only Action3 and Action4).

 

You should keep in mind that moving the variable and function/sub declarations into an associated library file will make them global. This means they will be accessible within all Actions in the test and their values will persist between actions and iterations. For more information, refer to:


Document ID 13424 - How to declare a global variable for use with all Actions
Document ID 22216 - How to share data between two Actions

 

2. The application under testing (AUT) memory is not released during the test run


The first two sections help with QuickTest Professional's memory usage. The actual application under test may need to release memory periodically also. Generally minimizing and/or restarting the application will accomplish this.

 

Example:

Internet Explorer's memory usage will increase over time (with or without QuickTest Professional). Minimizing the browser releases some of the memory. For more information, refer to Document ID 33128 - System resources problems and errors occur while testing Web applications.

 

3. QuickTest Professional's memory is not released during the test run

Declaring functions and variables in a library file, will help with memory usage, however you may still see problems with scripts that run over long periods of time (for example, more than 4 hours) and cycle through thousands of iterations. In these situations, it may be beneficial to restart QuickTest Professional periodically. This will free up any memory that QuickTest Professional is still holding.

 

In order to restart QuickTest Professional during replay, you will need to use QuickTest Professional's Automation Object Model (AOM). You can find information and examples on the AOM in the help documentation (Help -> QuickTest Automation Object Model Reference) and in the following Knowledge Base articles to implement the logic your scenario may require:

 

Document ID 27971 - What is the QuickTest Automation Object Model and how is it used
Document ID 28308 - How to run a set of tests using the Automation Object Model
Document ID 32289 - How to display test results when running a test using the Automation Object Model
Document ID 34540 - Does QuickTest Professional have a startup script
Document ID 28306 - How to specify the environment variables to be loaded when QTP is started (Automation Object Model)
Document ID 42947 - How to specify which add-ins to load using AOM
Document ID 33704 - How to set the data table iterations to a value greater than 9999


The following set of instructions is a proposal with a on to generic approach to handle scenarios where QTP needs to be restarted:

 

1. Create a .vbs file (using AOM statements) that can be called from within QuickTest Professional. The .vbs file should check:

 

- If QuickTest Professional is running, modify a couple environment variables (these will control the iterations) and shut down QuickTest Professional.
- If QuickTest Professional is not running, launch it. Set some run-time settings, and start the script execution.

 

Example contents of the .vbs file:

 

Note: The following script is not part of QuickTest Professional. It is not guaranteed to work and is not supported by HP Customer Support. You are responsible for any and all modifications that may be required.

 

' Wait 2 seconds to allow QuickTest Professional to complete replay overhead.

wscript.sleep 2000

 

' Create a QuickTest Professional AOM object

Set qtApp = CreateObject("QuickTest.Application")

 

' Check to see if QuickTest Professional is open (not necessarily running a script)

if qtApp.GetStatus <> "Not launched" then
set qtTest = qtApp.Test ' Get access to the test

' Get the current value of the "it_start" environment variable. This is the iteration start index.

itstart = qtTest.Environment.Value("it_start")

 

 

' Get the current value of the "it_stop" environment variable. This is the iteration stop index.

itstop = qtTest.Environment.Value("it_stop")

 

 

' Set the new values of the it_start and it_stop variables

qtTest.Environment.Value("it_start") = CInt(itstop) + 1

drows = qtTest.DataTable.GetRowCount

if drows > CInt(itstop) + 4 then

stp = CInt(itstop) + 4
else
stp = drows
end if

 

qtTest.Environment.Value("it_stop") = stp

 

' Close QuickTest Professional

qtApp.Quit
end if

 

' Wait 2 seconds to allow QuickTest Professional processes to end

wscript.sleep 2000

 

' Launch QuickTest Professional and make it visible

qtApp.Launch
qtApp.Visible = True

 

' Open the test script. Update to have full path to your test script

qtApp.Open "<path to test>"

 

' Get the current value of the "it_start" environment variable

itstart = qtApp.Test.Environment.Value("it_start")

 

' Get the current value of the "it_stop" environment variable

itstop = qtApp.Test.Environment.Value("it_stop")

 

' Set the Test Iterations for the script

qtApp.Test.Settings.Run.IterationMode = "rngIterations"
qtApp.Test.Settings.Run.StartIteration = itstart
qtApp.Test.Settings.Run.EndIteration = itstop

 

' Run the test

qtApp.Test.Run

 

' Release the QuickTest Professional object

Set qtApp = Nothing

 

Note: Update the .vbs file to specify the full path to the test you wish to restart.

 

2. Open your test script, and go to Test -> Settings.
3. In the Environment tab, select "User-defined" in the Variable type field.
4. Enter two new variables, it_start and it_stop. (You can use other names, if you wish, but you will need to change the vbs file also.)
5. Set the it_start value to 1. Set the it_stop value to the number of iterations you want to complete before restarting QuickTest Professional (for example, 1000).
6. At the end of the script (or in the last action), add code that will call the .vbs file when appropriate.

 

Example:

 

If Environment("TestIteration") = 1000 Then

' 1000 iterations complete. Restart QuickTest Professional

SystemUtil.Run "<full path to the vbs file>closeQTP.vbs"
End If

 

In the above example code, the TestIteration Environment variable is retrieved and checked to see if it has reached the limit set in step 5 (1000 iterations in the example). If the iteration limit has been reached, the .vbs file is launched. The start and stop iterations will be captured and stored and QuickTest Professional is restarted (if needed).

 

Make sure you update the .vbs file reflect the iteration limit you set in your script.

 

You should be able to start your script now and it will shut down and restart QuickTest Professional after x iterations.

 

Notes:

Each time QuickTest Professional relaunches and starts to replay the script, a new test results folder will be created. Using AOM you can have some control over the test results folders, but you should not use the same folder for each launch of the script if you need to save the test results (QuickTest Professional will overwrite the previous results, not append to them).
Some QuickTest Professional test environments, such as Web, require the application to be started after QuickTest Professional. Keep this in mind and structure your test as needed to allow you to restart the application if required.
You should use the VBS file to launch the test script.

 

DISCLAIMER OF WARRANTY

The example software is experimental and is provided as a courtesy, free of charge, "AS-IS" by Hewlett-Packard Development Company, L.P. ("HP"). HP shall have no obligation to maintain or support this software. HP MAKES NO EXPRESS OR IMPLIED WARRANTY OF ANY KIND REGARDING THIS SOFTWARE. HP SHALL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES, WHETHER BASED ON CONTRACT, TORT OR ANY OTHER LEGAL THEORY, IN CONNECTION WITH OR ARISING OUT OF THE FURNISHING, PERFORMANCE OR USE OF THIS SOFTWARE

 

I hope these information helped.

 

Best regards,

Tino Pacholski

Functional Testing Support Engineer

[If this post solves or helps solve your issue, mark the thread as solved and give KUDOS to the author for their assistance.]
Labels (2)
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.