Free QTP Framework

Above are the sixth components in my framework..

Now with the help of driver script you can complete your Test Automation..



'Adding sheets to Run-time data table
DataTable.AddSheet "Module"
DataTable.AddSheet "TestCase"
DataTable.AddSheet "TestStep"
DataTable.AddSheet "Login"

'Importing data from External File
DataTable.ImportSheet "C:\Documents and Settings\ShahadatK\Desktop\Proj_Automation\Orginizer\Organizer.xls",1,3
DataTable.ImportSheet "C:\Documents and Settings\ShahadatK\Desktop\Proj_Automation\Orginizer\Organizer.xls",2,4
DataTable.ImportSheet "C:\Documents and Settings\ShahadatK\Desktop\Proj_Automation\Orginizer\Organizer.xls",3,5
DataTable.ImportSheet "C:\Documents and Settings\ShahadatK\Desktop\Proj_Automation\TestData\data.xls",1,6

'Capturing Executable Modules from Module Sheet
MRowCount=DataTable.GetSheet("Module").GetRowCount
For i=1 to MRowCount Step 1
DataTable.SetCurrentRow(i)
ModuleExe=DataTable(3,"Module")
If UCase(ModuleExe)="Y" Then
ModuleId=DataTable(1,"Module")
'Msgbox "ModuleId: " & ModuleId

' Capturing executable test cases under executable modules
TCRowCount=DataTable.GetSheet("TestCase").GetRowCount
For j=1 to TCRowCount Step 1
DataTable.SetCurrentRow(j)
TCCaseExe=DataTable(3,"TestCase")
ModuleId2=DataTable(4,"TestCase")
If UCase(TCCaseExe)="Y" and ModuleId=ModuleId2 Then
TestCaseId=DataTable(1,"TestCase")
'Msgbox TestCaseId
'Capturing keywords for executable steps
TSRowCount=DataTable.GetSheet("TestStep").GetRowCount
For k=1 to TSRowCount Step 1
DataTable.SetCurrentRow(k)
TestCaseId2 = DataTable(5,"TestStep")
If TestCaseId=TestCaseId2 Then
keyword=DataTable(4,"TestStep")
'msgbox keyword


Select Case keyword
Case "ln"
Result=Login("abcd","mercury")
DataTable(7,"TestStep")=Result
Msgbox Result
Case "oo"
Result=Open_Order(5)
DataTable(7,"TestStep")=Result
Case "uo"
Result=Update_Order(5)
DataTable(7,"TestStep")=Result
Case "ca"
Close_App()

Case "lnd"
Rows=DataTable.GetSheet("Login").GetRowCount
For m=1 to Rows Step 1
DataTable.SetCurrentRow(m)
Result=Login2(DataTable(1,"Login"),DataTable(2,"Login"))
DataTable(3,"Login")=Result
Next
Case "ood"
Rows=DataTable.GetSheet("Login").GetRowCount
For n=1 to Rows Step 1
DataTable.SetCurrentRow(n)
Result=Open_Order2(DataTable(4,"Login"))
DataTable(5,"Login")=Result
Next

Case "uod"
Rows=DataTable.GetSheet("Login").GetRowCount
For p=1 to Rows Step 1
DataTable.SetCurrentRow(p)
Result=Update_Order2(DataTable(6,"Login"))
DataTable(7,"Login")=Result
Next
End Select
End If

Next
End If


Next

End If

Next

DataTable.ExportSheet "C:\Documents and Settings\ShahadatK\Desktop\Proj_Automation\TestResult\Result1.xls","TestStep"
DataTable.ExportSheet "C:\Documents and Settings\ShahadatK\Desktop\Proj_Automation\TestResult\Result1.xls","Login"

Data Dictionary Object

Class clsTestData
Private mDict
Public sWorkBook
Public vSheet
Public iRow


Public Default Function Load(sWorkBook, vSheet, iRow)
With Me
.sWorkBook = sWorkBook
.vSheet = vSheet
.iRow = iRow
End With

BuildContext : Set Load = oDict
End Function


Private Function BuildContext
Dim oConn, oRS, arrData, x
CONST adOpenStatic = 3
CONST adLockOptimistic = 3
CONST adCmdText = "&H0001"

Set oConn = CreateObject("ADODB.Connection")
Set oRS = CreateObject("ADODB.RecordSet")


oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" &_
"Data Source=" & Me.sWorkBook & ";" & _
"Extended Properties=""Excel 8.0;HDR=Yes;"";"


sQuery = "Select * From [" & Me.vSheet & "$]"


oRS.Open sQuery, oConn, 3, 3, 1


For x = 2 to iRow - 1 : oRS.MoveNext : Next

oDict = CreateObject("Scripting.Dictionary")


For x = 0 to oRS.Fields.Count - 1
With oDict
.Add "" & oRS(x).Name, "" & oRS.Fields(x)
End With
Next
End Function

Private Property Let oDict(ByVal Val)
Set mDict = Val
End Property
Private Property Get oDict()
Set oDict = mDict
End Property
End Class
Set mDataContext = New clsTestData


sWorkBook = "C:\Test.xls"
vSheet = "Sheet1"
iRow = 2

Set mDict = mDataContext.Load(sWorkBook, vSheet, iRow)

MsgBox mDict("Execute_Test")
MsgBox mDict("Scenario Name")
MsgBox mDict("Username")
MsgBox mDict("Password")



SystemUtil.Run "C:\Program Files\Mercury Interactive\QuickTest Professional\samples\flight\app\flight4a.exe","","C:\Program Files\Mercury Interactive\QuickTest Professional\samples\flight\app\","open"


Dialog("Login").Activate
Dialog("Login").WinEdit("Agent Name:").Set mDict ("Username")
Dialog("Login").WinEdit("Password:").Set mDict ("Password")
Dialog("Login").WinButton("OK").Click

KeyWord Driven Testing

for Technical interviews:

http://no1tutorial.com/

learn step by step technologies:


http://no1tutorial.com/
Keyword-driven testing is a Software testing technique that separates much of the programming work from the actual test steps so that the test steps can be developed earlier and can often be maintained with only minor updates, even when the application or testing needs change significantly.

In case of keyword driven testing, we need to do proper planning and initial huge effort. Anyway it will give benefit of easy maintenance and easily adding more test cases/scenarios.

As we see the keyword view in QTP IDE, the keyword driven testing involves specifying the test steps in below format

Object Action parameter

e.g
Browser("FireFox").Page("QualityPointHome").webEdit("username").Set "QualityPoint"

Here,

->Browser("FireFox").Page("QualityPointHome").webEdit("username") is the Object.
->"Set" is the Action.
->"QualityPoint" is the parameter.

Here we can change any of the three things to create test steps.

The Keyword Driven framework consists of the basic components given below

1. Control File
2. Test Case File
3. Startup Script
4. Driver Script
5. Utility Script

1. Control File


a) Consists details of all the Test scenarios to be automated.
b) User will be able to select a specific scenario to execute based on
turning on or off a flag in the Control File.
c) Control File is in the form of an excel worksheet and contains columns
for Scenario ID, Execute (Y/N), Object Repository Path, Test Case File
Path.

2. Test Case File
a) Contains the detailed steps to be carried out for the execution of a test
case
b) It is also in the form of an excel sheet and contains columns for
Keyword, Object Name, Parameter

3. Startup Script
a) The Startup script is utilised for the initialization and reads the control files.
b) It then calls the driver script to execute all the scenarios marked for execution in the control file.

4. Driver Script

a) It Reads the Test Case files. Checks the keywords and calls the appropriate utility script functions based on specific keyword
b) Error Handling is taken care of in the driver script.

5. Utility Scripts

a) Perform generic tasks that can be used across applications.


Advantage of keyword Driven Framework.

• The main advantage of this framework is the low cost for maintenance. If there is change to any test case then only the Test Case File needs to be updated and the Driver Script and Startup script will remain the same.
• No need to update the scripts in case of changes to the application.



The framework design will be purely based on your requirements and your way of thinking. There is no Solid rule to follow.

Personally, I would like to have my own framework (hybrid framework) designed according to my own requirements.

Anyway, the best practice is, we should create below sub folders in your root folder.

ObjectRepository-> To keep your shared object repositories.
Datatables->To keep QTP data tables and external Excel sheets.
Config-> To keep environment variable xml file
RecoveryScenario ->To keep your recovery scenario files.
Tests-> You can keep your QTP Tests here. You may include Test containing Reusable Actions here. And a Test which is getting used as driver script can also be stored here.
library->you can keep your vbs file which contains vbscript functions.
Results-> You can store Result files (Either QTP result file or customized result file) here.
Actually there won't be any solid rules/approach for creating QTP framework.
for Technical interviews:

http://no1tutorial.com/

learn step by step technologies:


http://no1tutorial.com/

Structure for Keyword Framework

Structure for Keyword Driven Framework:


·Test case (Excel OR XML OR ELSE)
·Driver script
·Data script ( To collect & Validate the test data & Keyword from test case excel )
·Common Functional Library (Common for all the test)
·Business function & procedure (Can be specific to test)
·Supportive library (Application Independent)
· Scripts ( Specific to test - only if required)
· Test result



Configuration files which contain following thing:


1. File 1: Contain the variable to make debug mode enable/disable.
a. Can also include flag to install\Uninstall application.
b. Point to re-configure the test environment.
c. Flag to make different level of validation\Check point before executing test.
2. File 2 : Which contain all the required path of files. (Application, result, etc)
3. File 3 : which contain global variable & QTP environment variable used as reference for validation, to invoke QTP & set the test environment.

Optional Feature:


1. Maintaining result history separately, which can be maintain in such way that we can extract history detail of each test/module.
2. Generating mail at completion of each scheduled run with result & important messages of failure.

Download free QTP Framwork: How to Implement framework in QTP

How To Make Career In QTP: Download free QTP Framwork

for Technical interviews:

http://no1tutorial.com/

learn step by step technologies:


http://no1tutorial.com/
Framework Implementation in QTP

The Keyword-driven Framework is an application independent framework

that performs all possible actions and verifications on an object.
Hence, the code for the same object can be used across different
applications.
2.1. Test Settings for Keyword-driven Scripting
In the keyword-driven approach the entire script is developed with
keywords. The script is developed in a spreadsheet that is
interpreted by the main driver script, which then uses the function
library to execute the complete script.
The QTP Settings.vbs file can be used to easily perform the test
settings that are needed before proceeding with the Keyword-driven
Scripting. This file associates the Function libraries, recovery
scenarios, Environment Variables and the Object Repository files that
are needed for a script.
The QTP Settings file needs to be customized before usage. Edit the
.vbs file in notepad and make the necessary changes (mentioned below)
in the ‘Input Data’ section of the file.
1. Function Libraries – Specify the path where the Framework
Files, Common Functions and the User Defined Functions are
stored.
2. Recovery Scenario File - Specify the path of the file where the
Recovery scenarios are placed.
3. Recovery Scenarios Name - Specify the names of the Recovery
scenarios that need to be associated to the test script.
4. Environment File - Specify the path of the xml file for the
Global Environment Variables.
5. Object Repository files - Specify the path of the Object
Repository.
Open the test script in QTP for which the settings are needed and
double click on the QTP Settings.vbs file. This file will perform the
preferred settings automatically.

If there are multiple items of libraries, object repositories or global variables file,
they can be specified as an array separated by ‘,’

Set the Flag envi_flag, recover_flag, repos_flag, library_flag to "Yes" if the
corresponding files need to be associated to test, Else set it to "no"


given below is a sample “QTP Settings”.
libraries= array ("C:\WebFramework.vbs","C:\common functions.vbs")
recovery_file= "C:\recover.qrs"
recovery_name=array("Scenario1","Scenario2")
environment_file= "C:\Environment.xml"
repository_name= array ("C:\repository1.tsr","C:\repository2.tsr")
'NOTE: Please set the Flag to "Yes" if the files are to be associated to
test, otherwise set it to "no"
envi_flag="yes"
recover_flag=" yes"
repos_flag=" yes"
library_flag=" yes"
There should be just one Recovery file which holds all the Recovery scenarios. Multiple
Recovery files cannot be used.
There should be no unsaved tests currently open in QTP. The test script for which the test
settings need to be done should be open in QTP.

2.1.1. Run Settings

In the Run tab of the Test Settings dialog,
1. The Run one iteration only radio button will be selected.
2. The Disable Smart Identification during the run session check box
will be checked.
3. The Object Synchronization timeout value will be set as 20
seconds.

2.1.2. Resources Settings

After the run settings are completed, the QTP Settings file
associates the framework with the test script. Here, the path and the
names of the framework files need to be specified in the QTP Settings
file. The framework will be taken from the location specified and
associated with the test as shown below.

Associating Framework File

NOTE: The Common functions file and the User defined functions file should be
associated with the test only if needed by the test script.

2.1.3. Environment Tab Settings
QTP can insert a value from the environment variable list, which is a
list of variables and corresponding values that can be accessed from
the test. Throughout the test run, the value of an environment
variable remains the same, regardless of the number of iterations,
unless the value of the variable is changed programmatically in the
script.
Associating the user-defined Environment Variables file with the test
is also handled by the QTP Settings file. The Environment Variables
file with an .xml file type will be taken from the path specified in
the QTP Settings file and associated with the test.

Loading Environment Variables from xml File

2.2. Managing Object Repository

After the test settings are completed, the QTP Settings file
continues to associate the specified shared object repositories with
the test. The objects from the shared repository will be uploaded and
made available for the tests.

Associate Repositories Dialog


Call to Framework

The call to Keyword_Driver() needs to be specified in the Expert View
as shown below. This will call the Framework file associated with the
test and perform the actions by interpreting the keywords specified
in the data table.

2.4. Usage of Keywords

The keywords should be entered in the global sheet of the data table
of the test according to the syntax. To access the data table, choose
View > Data Table or click on the toolbar button. Below is an
example of Keyword-driven Scripting.

Using the keyword in a Data Table


2.5. Test Results for a Keyword-driven Script
Test execution results can be viewed and analyzed as soon as the run
session ends. To access the test results, choose Automation > Results
or click on the toolbar button. The results window will be
displayed.

Results in QTP

How to Modular Automation Framework Checklist for the Smoke Testing

Re-usability – Develop a robust function library to be used across the projects and within the application.

Robustness – Develop a robust test suite that can be easily used for testing the application in different environments e.g. development, testing and production.

Portability – To ensure easy installation of the suite in different environments.

Modularity – Develop modular scripts to ensure maintainability, scalability and readability of the scripts.

Scalability - Scalable scripts which can be upgraded/ enhanced.

Maintainability – The approach should be such where in major effort goes in to the planning and developing the scripts where as least possible effort is required to maintain the same.

Data Driven Testing – To perform positive and negative tests using data driven scripts. To achieve this, we need to a checklist for Automation Framework Planning:

Identify the Scenarios / Test Cases for Smoke – 6 Identified Done
Execute the Scenarios / Test Cases Manually at least 5 times - Done
Get the Scenarios approved from QA Manager / Product Manager / Client - Done

Create the Folder Structure – Done, C:\AST
Create the shared object repository - Done
Identify the Actions for the approved scenarios – Done with 8 Actions
Create test data (take inputs from the manual testing team / SME’s) - Done
Generate the Actions / Action library by hard coding the data – 8 reusable created, 0-pending
Separate the data from the Actions / Reusable – Done
Integrate / call the Actions in the main test - Done
Execute & debug the Actions / Reusable - Done
Get the Actions reviewed by the lead / manager / client - Done
Create the AOM - Done
Use Environment Variables - Done –Build in, user defined Functions
Schedule the Smoke Test - Done