For...Each Statement in HP QTP

For...Each Statement
A For...Each loop instructs QuickTest to perform one or more statements for each element in an array or an object collection. It has the following syntax:

For Each item In array
    statement
Next
Item  Description
item  A variable representing the element in the array. 
array  The name of the array. 

statement  A statement, or series of statements, to be performed during the loop. 
The following example uses a For...Each loop to display each of the values in an array:

MyArray = Array("one","two","three","four","five")
For Each element In MyArray
    msgbox element
Next

Note: During a run session, if a For Each statement iterates on the Parameter Definitions collection, the run may fail if the collection was retrieved directly before using the For Each statement. To prevent this, use other VBScript loop statements, such as For or While.

Do...Loop Statement in VB Script

Do...Loop Statement
The Do...Loop statement instructs QuickTest to perform a statement or series of statements while a condition is true or until a condition becomes true. It has the following syntax:

Do [{while} {until} condition]
    statement
Loop

Item           Description  

Condition     A condition to be fulfilled.  

Statement     A statement or series of statements to be performed during the loop. 

In the following example, QuickTest calculates the factorial value of the number of passengers using the Do...Loop:

passengers = Browser("Mercury Tours").Page("Find Flights").WebEdit("numPassengers").GetROProperty("value")

total = 1
i = 1
Do while i <= passengers
     total = total * i
     i = i + 1
Loop
MsgBox "!" & passengers & "=" & total  

Variables in VBScript

Variables in VBScript

You can specify variables to store test objects or simple values in your test or function library. When using a variable for a test object, you can use the variable instead of the entire object hierarchy in other statements. Using variables in this way makes your statements easier to read and to maintain.

To specify a variable to store an object, use the Set statement, with the following syntax:

Set ObjectVar = ObjectHierarchy

In the example below, the Set statement specifies the variable UserEditBox to store the full Browser.Page.WebEdit object hierarchy for the username edit box. The Set method then enters the value John into the username edit box, using the UserEditBox variable:

Set UserEditBox = Browser("Mercury Tours").Page("Mercury Tours").WebEdit("username")

UserEditBox.Set "John"

Note: Do not use the Set statement to specify a variable containing a simple value (such as a string or a number). The example below shows how to define a variable for a simple value:

MyVar = Browser("Mercury Tours").Page("Mercury Tours").WebEdit("username").GetTOProperty("type")

You can also use the Dim statement to declare variables of other types, including strings, integers, and arrays. This statement is not mandatory, but you can use it to improve the structure of your test or function library. In the following example, the Dim statement is used to declare the passengers variable, which can then be used in different statements within the current action or function library:

Dim passengers

passengers = Browser("Mercury Tours").Page("Find Flights").WebEdit("numpassengers").GetROProperty("value")

How to Opening and Closing Applications Programmatically in QTP

Opening and Closing Applications Programmatically
In addition to using the Record and Run Settings dialog box to instruct QuickTest to open a new application when a test run begins, or manually opening the application you want to test, you can insert statements into your test that open and close the applications you want to test.

You can run any application from a specified location using a SystemUtil.Run statement. This is especially useful if your test includes more than one application, and you selected the Record and run test on any application check box in the Record and Run Settings dialog box. You can specify an application and pass any supported parameters, or you can specify a file name and the associated application starts with the specified file open.

You can close most applications using the Close method. You can also use SystemUtil statements to close applications.

For example, you could use the following statements to open a file named type.txt in the default text application (Notepad), type happy days, save the file using shortcut keys, and then close the application:

SystemUtil.Run "C:\type.txt", "","",""
Window("Text:=type.txt - Notepad").Type "happy days"
Window("Text:=type.txt - Notepad").Type micAltDwn & "F" & micAltUp
Window("Text:=type.txt - Notepad").Type micLShiftDwn & "S" & micLShiftUp
Window("Text:=type.txt - Notepad").Close

Note:
When you specify an application to open using the Record and Run Settings dialog box, QuickTest does not add a SystemUtil.Run statement to your test.
The InvokeApplication method can open only executable files and is used primarily for backward compatibility.

Expert View and Keyword View - A Comparison

If you prefer to work with VBScript statements, you can choose to work with your tests in the Expert View, as an alternative to using the Keyword View. You can move between the two views as you wish, by selecting the Expert View or Keyword View tab at the bottom of the Test pane in the QuickTest window.

The Expert View displays the same steps and objects as the Keyword View, but in a different format:

In the Keyword View, QuickTest displays information about each step and shows the object hierarchy in an icon-based table. For more information, see Keyword View.
In the Expert View, QuickTest displays each step as a VBScript line or statement. In object-based steps, the VBScript statement defines the object hierarchy.

The following diagram shows how the same object hierarchy is displayed in the Expert View and in the Keyword View:

The Expert View and Function Library Windows Overview in HP QTP 11

In QuickTest, tests are composed of statements coded in the Microsoft VBScript programming language. The Expert View provides an alternative to the Keyword View for testers who are familiar with VBScript. You can also create function libraries in QuickTest using VBScript.

This section explains how to work in the Expert View, provides a brief introduction to VBScript, and shows you how to enhance your tests and function libraries using a few simple programming techniques.

In the Expert View, you can view an action in VBScript. If you are familiar with VBScript, you can add and update statements and enhance your tests and function libraries with programming. This enables you to increase a test's power and flexibility. You can also create and work with function libraries using the Function Library window.

To learn about working with VBScript, you can view the VBScript documentation directly from the QuickTest Help menu (Help > QuickTest Professional Help > VBScript Reference).

You can add statements that perform operations on objects or retrieve information from your application. For example, you can add a step that checks that an object exists, or you can retrieve the return value of an operation.

You can add steps to your test or function library either manually or using the Step Generator.

Understanding Absolute and Relative Paths in QTP 11.5

Understanding Absolute and Relative Paths

You can save QuickTest resources, such as shared object repositories, function libraries, recovery scenarios or environments, using absolute or relative paths.

Absolute Paths
An absolute path describes the full path to a specific file starting from a fixed location such as the root directory, or the drive on which the file is located, and contains all the other sub-directories in the path. An absolute path always points to the specified file, regardless of the current directory.
If you are working with the Resources and Dependencies model with Quality Center 10.00 or HP ALM, you must specify an absolute Quality Center path to enable your tests to access your resource files.

Relative Paths
A relative path describes the path to a specific file starting from a given directory, and is generally only a portion of the absolute path. A relative path therefore specifies the location of the file relative to the given location in the file system.
Using relative paths means that the paths remain valid when files or folders containing files are moved or copied to other locations or computers, provided that they are moved within the same folder structure. If you are not working with the Resources and Dependencies model with Quality Center 10.00 or HP ALM, we recommend that you use relative paths when saving resources in QuickTest.

Example 


Consider a QuickTest resource file named FunctionLibrary1.qfl located in C:\Current_Version\Libraries. The absolute path to the file is

C:\Current_Version\Libraries\FunctionLibrary1.qfl. 

The relative path to the file from within the folder named Libraries is specified using only the name of the file, FunctionLibrary1.qfl. Alternatively, the relative path to the file from within another folder, such as C:\Current_Version\Libraries\MyFiles, would be Libraries\FunctionLibrary1.qfl.

Using a relative path, you could copy the FunctionLibrary1.qfl file from C:\Current_Version\Libraries to an updated version in C:\New_Version\Libraries, and the path used by QuickTest would remain valid.

Checkpoint Types in QTP 11.5

You can insert the following checkpoint types to check objects in an application:

Standard Checkpoint     Checks property values of an object in your application. For example, you can check that a radio button is activated after it is selected or you can check the value of an edit box.

Standard checkpoints are supported for all add-in environments   .

Image Checkpoint     Checks the value of an image in your application. For example, you can check that a selected image's source file is correct.
You create an image checkpoint by inserting a standard checkpoint on an image object.
Image checkpoints are supported for the Web add-in environment   .

Bitmap Checkpoint     Checks an area of your application as a bitmap. For example, suppose you have a Web site that can display a map of a city the user specifies. The map has control keys for zooming. Using the bitmap checkpoint, you can check that the map zooms in correctly.
You can create a bitmap checkpoint for any area in your application.
Bitmap checkpoints are supported for all add-in environments   .

Table Checkpoint     Checks information within a table. For example, suppose your application contains a table listing all available flights from New York to San Francisco. You can add a table checkpoint to check that the time of the first flight in the table is correct.
You create a table checkpoint by inserting a standard checkpoint on a table object. For more information on table checkpoints.

Table checkpoints are supported for all add-in environments that have a *Table test object. Table checkpoints are also supported for some list view objects, such as WinListView and VbListView, as well as other list view objects in add-in environments. For more information,

Text Checkpoint     Checks that a text string is displayed in the appropriate place in an application. For example, suppose a Web page displays the sentence Flight departing from New York to San Francisco. You can create a text checkpoint that checks that the words "New York" are displayed between "Flight departing from" and "to San Francisco".

Text checkpoints are supported for most add-in environments   .

Text Area Checkpoint     Checks that a text string is displayed within a defined area in a Windows-based application, according to specified criteria. For example, suppose your Visual Basic application has a button that says View Doc <Num>, where <Num> is replaced by the four digit code entered in a form elsewhere in the application. You can create a text area checkpoint to confirm that the number displayed on the button is the same as the number entered in the form.

Text area checkpoints are supported for all Windows-based environments, such as Standard Windows, Visual Basic, and ActiveX add-in environments   . Text area checkpoints are also supported for some other add-in environments, such as Java.

Accessibility Checkpoint     Identifies areas of your Web site that may not conform to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines. For example, guideline 1.1 of the W3C Web Content Accessibility Guidelines requires you to provide a text equivalent for every non-text element. You can add an Alt property check to check whether objects that require the Alt property under this guideline, do in fact have this tag.
Accessibility checkpoints are supported for the Web add-in environment   .

Page Checkpoint     Checks the characteristics of a Web page. For example, you can check how long a Web page takes to load or whether a Web page contains broken links.
You create a page checkpoint by inserting a standard checkpoint on a page object.
Page checkpoints are supported for the Web add-in environment   .

Database Checkpoint     Checks the contents of a database accessed by your application. For example, you can use a database checkpoint to check the contents of a database containing flight information for your Web site.

Database checkpoints are supported for all add-in environments   .

XML Checkpoint     Checks the data content of XML documents in XML files or XML documents in Web pages and frames. For more information on XML checkpoints, The XML Checkpoint (Web Page/Frame) option is supported for the Web add-in environment. The XML Checkpoint option is supported for all add-in environments  

How to Add checkpoints in your tests

QuickTest enables you to reuse existing checkpoints. When you create checkpoints, consider which checkpoints can be reused in multiple locations in your test or in multiple tests. For example:

Checkpoints that check generic content or the state of your application may be useful in multiple locations.
Checkpoints that check the content of a specific area of your application are generally useful in only one particular place in your test.
The following examples illustrate situations in which inserting an existing checkpoint may be useful:

If each page of your application contains your organization's logo, you can reuse a bitmap checkpoint to verify each occurrence in the application.
If your application contains multiple edit boxes, you can reuse a checkpoint to confirm the enabled status of these edit boxes throughout your test.

What is Checkpoints in QTP

Checkpoints Overview

QuickTest enables you to add checks to your test. A checkpoint is a verification that compares the current value for specified properties or current state of other characteristics of an object with the expected value or characteristics. This helps you to identify whether your application is functioning correctly.
When you add a checkpoint, QuickTest inserts a checkpoint step to the current row in the Keyword View and adds a Check CheckPoint statement in the Expert View. By default, QuickTest names the checkpoint using the name of the test object on which the checkpoint was created. You can choose to specify a different name for the checkpoint or accept the default name.
When you run the test, QuickTest compares the expected results of the checkpoint to the current results. If the results do not match, the checkpoint fails. You can view the results of the checkpoint in the Run Results Viewer.

Creating Tests Using the Keyword-Driven Methodology

Creating Tests Using the Keyword-Driven Methodology
This methodology requires an infrastructure for all of the required resources. Resources include shared object repositories, function libraries, and recovery scenarios. Setting up the infrastructure requires in-depth knowledge of your application and a high level of QuickTest expertise.

Although setting up the infrastructure may initially require a longer time-investment in comparison to recording tests, using the keyword-driven methodology enables you to create tests at a more application-specific level and with a more structured design. This enables you to maintain your tests more efficiently and provides you with more flexibility than a recorded test.

When to Use Keyword-Driven Testing 

Keyword-driven testing enables you to design your tests at a business level rather than at the object level. For example, QuickTest may recognize a single option selection in your application as several steps: a click on a button object, a mouse operation on a list object, and then a keyboard operation on a list sub-item. You can create an appropriately-named function to represent all of these lower-level operations in a single, business-level keyword.
By incorporating technical operations, such as a synchronization statement that waits for client-server communications to finish, into higher level keywords, tests are easier to read and easier for less technical application testers to maintain when the application changes.
Keyword-driven testing naturally leads to a more efficient separation between resource maintenance and test maintenance. This enables the automation experts to focus on maintaining objects and functions while application testers focus on maintaining the test structure and design.
When you record tests, you may not notice that new objects are being added to the local object repository. This may result in many testers maintaining local object repositories with copies of the same objects. When using a keyword-driven methodology, you select the objects for your steps from the existing object repository. When you need a new object, you can add it to your local object repository temporarily, but you are also aware that you need to add it to the shared object repository for future use.
When you record a test, QuickTest enters the correct objects, methods, and argument values for you. Therefore, it is possible to create a test with little preparation or planning. Although this makes it easier to create tests quickly, such tests are harder to maintain when the application changes and often require re-recording large parts of the test.
When you use a keyword-driven methodology, you select from existing objects and operation keywords. Therefore, you must be familiar with both the object repositories and the function libraries that are available. You must also have a good idea of what you want your test to look like before you begin inserting steps. This usually results in well-planned and better-structured tests, which also results in easier long-term maintenance.

Automation experts can add objects and functions based on detailed product specifications even before a feature has been added to a product. Using keyword-driven testing, you can begin to develop tests for a new product or feature earlier in the development cycle.

How to export data from database table to Excel sheet and Datatable

How to export data from database table to Excel sheet and Datatable

‘  Adding NewDataSheet in Run Time
DataTable.AddSheet “MySheet”

‘ ‘  Adding Column name in Run time
DataTable.GetSheet(“MySheet”).AddParameter “bname”,” “
‘ Create DataBase Connection
Set objCon = CreateObject(“ADODB.Connection”)
objCon.Open”Provider=SqlOledb.1;Server=sys;uid=sa;pwd=;database=db1″
‘ (OR)  Open DataBase Connection

objCon.Open”Provider=Microsoft.Jet.Oledb.4.0;Data Source=D:\NewDB.mdb”

‘  Creating Record set for DataSet
Set objRs=CreateObject(“adodb.recordset”)

‘ Opening RecodSet form DataBase( storing the values in recordsetb )
objRs.open”select * from Emp”,objCon

‘ Loop for Getting DataBase Column name
For intCount = 1 to objRs.Fields.Count-1
i = 1

‘ column name in run time data sheet using add parameter method
DataTable.GetSheet(“MySheet”).AddParameter objRs.Fields(intCount).Name,” “
‘ Loop for Checking end of the Recod
While objRs.eof<>true
‘  Seting the current row
DataTable.SetCurrentRow(i)
‘   inc’ents for data table row
i=i+1
‘  Assigning the DataBase Values into DataTable
DataTable.Value(objRs.Fields(intCount).Name,”MySheet”) = objRs.Fields(intCount).Value
‘’ ——->  moving the record  pointed to next record
objRs.MoveNext
Wend
‘  moving the record  pointed to First record
objRs.MoveFirst
Next
‘ Exporting the results in local
DataTable.ExportSheet”D:\HPQTPForum.xls”,3