1. You can use the “DataTable.Export” method or “DataTable.ExportSheet” method to literally create a new .xls file of the workbook or specified worksheet, and have this new file saved in your file system (locally or on the network).  With this approach you can then use that datatable/spreadsheet however you want including importing it into the permanent datatable attached to the test script if you want.
   
   
2. Also keep in mind that your Test Results Report will show you the data used and created during the test run.  You can view this in the “Data Table” in the test report itself.
   
   You can then export that data into an external file too, from the report.  The steps are slightly different depending on the version of QTP you are using, but from QTP v11 you would simply select “File > Export to File…” and then select “Data Table” from the “Report type” drop-down list.  When you click the “Export” button you can then specify a new name and location for the data file (.xls).  This will export ALL the data in the datatable (all the worksheets will be exported this way).  Like the previous approach, you now have an external .xls file that you can now do whatever you want with it, including importing it back into the permanent datatable attached to the test script.

Let’s breakdown this simple script, I have three transaction times being recorded – “trans1″, “trans2″ and “trans3″.  “trans1″ encapulates “trans2″, and “trans3″ logs its own time at the end of the script.

The timers and duration times breakdown as follows:

“trans2″ – this transaction actually completes before the “trans1″ because it is contained within the “trans1″ wrapper (nested within the “trans1″ code), so if we look at the results for “trans2″ you will see that it contains a “wait 3″ statement and an “AddWastedTime” of 1000 milliseconds (which is 1 second).  In looking at the test results report you can see that the “Total Duration” time is 3.0300 seconds (the 3 seconds from the “wait” statement and a slight delay for the execution of the statements themselves) and it also logs the “Wasted Time” of 1 second.

“trans1″ – this has a total duration time of approximately 12 seconds.  Simply add up the “wait” statements contained within the “trans1″ transaction wrapper and add a slight delay for the execution of the statements themselves.  As you can see in this image the “Total Duration” time is 12.1080 seconds.  Now the “Wasted Time” is all the “AddWastedTime” statements contained within the “trans1″ wrapper, so this includes the “Services.AddWastedTime MercuryTimers(“timer1″).Stop” statement (which is a dynamic statement based on the “MercuryTimers(timer1)” wrapper around a subset of code (the “wait 4″ statement in this case – however this would normally be a real chunk of code)) and the “Services.AddWastedTime 1000″ which is a hardcoded value where we are saying that “we want to reduce the time by 1 second”.  Added together this is 5 seconds with a slight delay for the execution of the statements themselves – which as you can see in the test results report is 5.0190 seconds of “Wasted Time”.

“trans3″ – Finally we have the last transaction time being recorded and notice it is outside of the “trans1″ wrapper.  So this is self-contained code at the end of the script and logs its own time which in this case is a hardcoded 1 second using the “Services.AddWastedTime 1000″ statement.  Notice the timers from above do not affect this timer.

As you can see the “Wasted Time” is logged in the Test Results for a normal QTP test process, and realize it is also integrated with LoadRunner and the Business Process Monitor.

Be aware that there are Pros and Cons to using this function in a QuickTest Pro automation script.

Pro: Using this function you can define an Edit box to appear that you can prompt for a value from the user that you can then use in your test script.  The function has several parameters but the most common parameters used are the “prompt” (which is the only required parameter), title and default (which is the default value to automatically pre-populate if you want).  The other parameters are used less often.  The value that is entered is then passed back to the script as a return value and can be captured in a variable to be used within your test script.  Here is an example of using it to retrieve a security code during test execution.

Notice in this image how the statement generates this edit box.  You can then enter a value in the edit field to be passed back to the script like in this image.  Notice the value entered into the edit field, it will be passed back as the return value and in this example it will get stored in the variable “vReturnValue” based off the example in this image.

Notice in this final image, the InputBox statement has been executed and we are now paused on the wait statement so that we can examine the variables.  In looking at the variable in the Debug Viewer, notice how the variable has the value that was entered in the edit box.

Con: The con to using this function in a QuickTest Pro automation script is that it requires interaction from a user.  The biggest goal that you are always trying to achieve with test automation is to get “long term unattended testing” which means your script needs to be able to execute without any user interaction.  This function requires a response from a user and will just sit there forever until it gets a response.  So be careful on using this.  If you really want to use this function then I would recommend putting it at the very beginning of any automated process so that you could enter in all the values immediately and then be able to walk away from the process and let it run independently from you.  However my recommendation on better options for getting a value for your automation is to have this value retrieved from one of these options, retrieve it from:
- a variable or constant from within your test script
- from a text file that the script opens and reads from
- from an environment variable
- or from a parameter passed in from another script

These statements will log the duration time to the Test Results Report, which will tell you how long the “process” that resides between the two statements took to execute.  Typically what you would do is wrap a submission or transaction process to see how long it is taking; like submitting an order or new user profile.  In using the QTP training application we will time the submission of the order, so find the “Insert Order” button statement and your synchronization statement to know when the insert process has completed. 

So just before the “Insert Order” button you would put a Services.StartTransaction “InsertOrder” statement and once you are synchronized on the success of the submission of the order you will have an Services.EndTransaction “InsertOrder” statement (placed right after the sychronization statement).

This will tell you how long it took to insert a new order and you can pass or fail this test step based on your functional requirements as to how long is an acceptable timeframe.  These statements will log the results to the Test Results Report directly and appear like this:

The disadvantage of this statement is that it only logs the results to the Test Results Report, so you don’t have the actual time within the test script in order to code your own logic on passing or failing the statement.  People complained about this for many years and finally they came out with a new function prior to the sale of “Mercury Interactive” to “HP”, so the function name actually has the old company name contained in it.  The functions are “MercuryTimers(“<timer name>”).Start” and “MercuryTimers(“<timer name>”).Stop”.  The Stop function returns the duration time as a return code so you can use it within your test script.  You would use this function the same as the StartTransaction statements; identify were in the test script you want the statements and then type these statements in (note that using the Step Generator will produce the wrong syntax so it is best to just manually type the statement in your test script in the Expert View.

Notice that I added a “msgbox” statement to display the duration time so that you can see how it is returned as a return value into a variable and can be used in the test script.  Notice that the time is returned in milliseconds.

The odd thing is that when Mercury added this function to QTP in order to provide you with the duration time as a return code within the script, they didn’t keep the feature of also logging it to the Test Results Report.  Notice in this image that there is no reference to the fact that the “MercuryTimers” function was executed. 

So if you want to log the time to the Test Results Report (which I highly recommend so that you have a log of the duration time) then you will want to add your own “Reporter.ReportEvent” statement.

And then the report will have entries for each timing and because I used a conditional statement to verify the duration time against the functional requirement of taking less than 6 seconds, I can then pass and fail the statement automatically.

Changing Object Synchronization Timeout from within a QTP script:

To figure out the setting name of other items that you can change, simply open the Test > Settings window and click the Generate script button. This will produce a text file that can be used to launch your QTP instance from a script (basically using the QTP API). We are not going to execute the script but use it to get the proper setting names for the various settings that we can change from within our test script. Open the file in notepad and look at the names. The file should look similar to this:

Other examples of changing settings include:

Changing Object Sync Timeout:

Changing the Test Iteration Mode:

If you are using QuickTest Pro, then QTP uses VBScript as the programming language and there are basically two types of procedures in VBScript - Functions and Subroutines.  The main difference between them is  that a Function performs some actions and returns a value while a subroutine is used to perform some actions but does not return a value. 

There is also a concept of private versus public.  If you create a Function or Subroutine at the top of your test script in QTP, then it is private and only that script can call the procedure(s) and use it.  If you add it to a Function Library and add the Function Library reference to the Resources tab in the Test Settings window in QTP, then all the scripts/actions in the test suite (including all called action & reusable actions) can call all the procedures stored in that Function Library (thus it is considered public).

  Online training is great because you can work at your own pace, whenever it is convenient for you.  You can do this work during down-time at work, over your lunch break, at home, or even at your kids sports practice if a wireless connection is available (we’ve had parents tell us how their kids hockey rink has wireless and so they would bring their laptop to the practice and go over some of the lessons during the practice). 

  We have customers from around the world to include the entire United States, Canada, Europe, New Zealand and Australia.  What makes my training so popular is that I have 17 years of experience implementing the product line in real-world scenarios.  So I’m not some tech writer or an instructor who has never actually used the tool.  I have implemented solutions for some of the biggest corporations with incredible success. Click here for PDF file of Company Reference List

Course Details: This lesson includes over 12 lessons consisting of 179 online training pages of material for only $50.  The Lessons covered in this class are:

1. Introduction
2. Record & Playback
3. Object Repository
4. Standard Checkpoints
5. Regular Expressions
6. Bitmap Checkpoints
7. Text Checkpoints
8. Database Checkpoints
9. Parameterization
10. Data Driven Testing
11. Output Values
12. Actions

Read more about this class on our “Products” page.

Ever get an “Overflow error” when using the CInt function?  You might encounter this error when you are doing some programming in your test script and doing some data manipulations or calculations.  Let’s review an example of a situation that could cause this to happen – a classic example would be if you were processing a file where a number could be rather large.   Here is a code snippet where the batch size of a data extract was retrieved and generated the Overflow error:

First thing is that in VBScript it only has one data type called Variant.  This can contain either a numeric or string in it and by default it will be a string if there are any other characters in the original value (which is very common).  There are sub-types available to use that you can convert a string or Variant to; they can be one of these:

Typically what you want to do in order to either add numbers together or compare two numbers in a conditional statement is to convert the variable to a numeric integer.  The way to do that is using the CInt() function.  However if you notice in the table above, an Integer is in the range of -32,768 to 32,767.  The problem is if you are working with an integer that is larger than 32,767.  Like in this example, if you look at the bottom in the Debug Viewer you will see that the Batch Size is actually 56,989 (which is not a surprise when dealing with data extracts).  So this is what is throwing the error because if you look above the error at the test script, you will see on line 103 that CInt is being used.  But if you know that a data element could be large, then use CLng() instead.  This will convert it to a Long which then accepts a range of -2,147,483,648 to 2,147,483,647 and works fine for our situation.

Now if you look at this second image, notice how line 103 now uses CLng and how we have paused on the next line, there is no error and the batch size is correct at 56,989 and notice the type is now “Long” to the right of the value.

FormatDateTime (date[,format])

Parameter Description 
      date          Required.  Any valid date expression (like Date() or Now()) 
      format    Optional.   A value that specifies the date/time format to use.  The values are numerics and they have the following definitions:

0 = vbGeneralDate – Default (or just don’t put anything in). Returns the date in the format: mm/dd/yy and time if specified in the format: hh:mm:ss PM/AM.
1 = vbLongDate – Returns the date in the format: weekday, month day, year
2 = vbShortDate – Returns the date in the format: mm/dd/yy
3 = vbLongTime – Returns the time in the format: hh:mm:ss PM/AM
4 = vbShortTime – Return the time in the format: hh:mm
 

Here is an example using the function in QuickTest Pro, assigning each format to a separate variable and displaying the values in the Debug Viewer for you to see.

This is a really useful function and can save you a ton of time from having to write your own function.  Notice that using the “Date” function within this function, I can easily grab a date in the past (like yesterday by specifying “Date()-1″ and return it in a specific format for use in my script.  This is great for when you need to perform date verifications in your test script.  Notice in this image that yesterday was returned in three different formats.

But this doesn’t work if you are populating an array on the fly with data. In this example the data is the rows and this is what you would want to grow; but you can’t resize the row element. So what you really want to do is reverse your layout to make the rows be the fields you are tracking and make the columns your “individual records of data” like in this image (ignore the first column in the image as this is just a label so you know what I’m talking about; it’s not really part of the actual array):

Now keep in mind that this is only an issue when you have to redim an existing multi-dimensional array. However if you know the size of a multi-dimensional array then I would stick to the normal array layout where the rows are data records and the columns are the field elements.

The code that controls this would look similar to something like this:

**Note this doesn’t apply to a single-dimensional array. That you can redim any time since it is dealing with only one element.