Transcript Product Development

QTP Automation Framework
September 2009
Objective
 Introduction to Automation
 Benefits of Automated Testing
 Automated Testing Process
 Introduction to QTP Framework
 Framework Structure
 Environment Supported
Introduction to Automation
Drawbacks of Manual testing
- Manual testing is time-consuming and tedious.
- Requiring a heavy investment in human resources.
- Time constraints often make it impossible to manually
test every feature thoroughly before the application is
released.
Manual Testing
- Low reliability.
Benefits of Automation Testing
Why Automation
- Fast
- Reliable
- Repeatable
- Programmable
- Comprehensive
- Reusable
Automated Testing
Automation Testing Process
Automated testing involves three main steps
Creating Script(s)
Executing Script(s)
Analyzing Result(s)
The QTP testing process consists of 7 main phases:







Preparing to record
Recording a session on your application
Enhancing your test
Debugging your test
Running your test
Analyzing the test results
Reporting defects
Introduction to QTP Framework What and Why
What is an Automation Framework:
A test automation framework is a set of assumptions, concepts, and
practices that provide support for automated software testing.
A comprehensive architecture to drive the complete test automation
process.
What is the need of having a Test Automation Framework:
Pitfalls of available standard Test Automation tools.
Testers are testers not programmers.
Complexity and Maintenance.
Test tool Costs.
Test Automation is seldom a full time effort.
Automation Frameworks: Advantages
Framework Advantages:
Scalability
Maintainability
Removes most testers from automation complexities
Can make automation efforts more holistic: Application independent
Minimize Automation Risks
Ensure Automation ROI
Type of Automation Frameworks
Data Driven Framework
Modularity Framework
Keyword Driven Framework
Hybrid Framework
Type of Automation Frameworks Contd.
Data Driven Framework
Data-driven framework is one where test input and output values are
read from data files (ODBC sources, Text files, Excel files, DAO
objects, ADO objects, and such) and are loaded into variables that are
coded in scripts
Data Driven testing is implemented for applications whose behavior
is data dependent- Test Scenarios are to be run one or more set of
data values which vary for each execution cycle
Data Driven Framework can be combined with Modular or Keyword
Driven Framework to create a Hybrid Framework
Type of Automation Frameworks Contd.
Modular Framework
Requires creation of small, independent scripts that represents
modules/sections/functions of the application under test.
The modules are then used in a hierarchical or logical fashion to
construct larger test realizing an actual test case.
Features in QTP to support Modularity Framework:
Reusable Actions
Functional Libraries
Type of Automation Frameworks Contd.
Keyword Driven Framework
Keyword-driven testing framework refer to an application-independent
automation framework.
This framework requires the development of data tables and
keywords, independent of the test automation tool used to execute
them.
The driver code "drives" the application-under-test, keyword driven
test and the data.
Keyword-driven tests look very similar to manual test cases.
In a keyword-driven test, the functionality of the application-under-test
is documented in a table like structure for e.g. Excel Sheet (similar to
keyword view in QTP).
Hybrid Framework
Hybrid Framework
The most successful automation frameworks generally
accommodate both keyword driven testing as well as data driven
scripts.
Hybrid is a combination of Functional Decomposition and Data
Driven Framework.
 Modularity can be achieved by nesting the test scripts and using
library files to implement reusable components (Reusable Actions
and Functions).
Hybrid = Keyword Driven + Data Driven
Hybrid = Modularity + Data Driven
Automation Framework- Typical Elements.
Startup Script
Driver Script
Test Scheduler
Object Repository
Functional Library/Action Library
Test Cases
Test Data Files
 Environment Files
Reporting Mechanism
Exception Handling: Recover Scenarios
Startup Script
Instead we have Initialization Script where you have to write
your own VB Script to make QTP to run this script before
executing each test.
We can put start applications URL/Address/Exe file path in the
default record or run settings for Windows/WEB applications.
QTP opens immediately that particular application or URL will
open.
Startup Script - Code
Driver Script
Driver script is the single main script of the Driver Engine.
It iteratively traverses through the data of business scenario flow
and calls the respective reusable scripts sequentially.
It also enables us to execute a reusable script any number of
times in a particular data row of the variable test data sheet.
It also updates the database for execution results of a particular
script run
Driver Script - Code
Test Schedulers
There can be situations when you need to schedule your
QTP scripts so that they can run when you are not
present in front of your PC.
Object Repository
Object Repository acts as a translator between QTP script
and the Operating System.
QTP stores information it learns about a window or an object in
object repository.
When QTP runs a test, it uses the object repository to locate
objects.
QTP reads an object description in the repository and then
looks for an object with the same properties in the application
under test.
How QTP Stores Test Objects
Add objects using
object Identification
settings
Generates Script
QTP
TEST SCRIPT
Object
Repository
Manager
Object Repository Contd.
Types of Object Repositories:
Per Action Object Repository
Shared Object Repository
Object Repository Contd.
Per Action Object Repository
TEST 1
ACTION 1
ACTION 2
.
.
ACTION - N
TEST 1
ACTION 1
ACTION 2
.
.
ACTION - N
Object
Object
Object
Object
Repository
Repository
Repository
Repository
Object Repository Contd.
Shared Object Repository
TEST 1
TEST 2
ACTION 1
ACTION 2
ACTION 1
ACTION 2
Shared Object
Repository
Functional Library/Action Library
Test Cases
Test Data
As per the scenarios which are in regression test suite, enter all the required
test data into the excel file and save it in the test data folder which is specified
in the framework.
Reporting Mechanism
When executing the scripts through QTP, we can get the HTML
reports which is user friendly, where as running them through
QC then auto generic reports.
Automation Framework Structure
AUT
Feasibility
Report on Test
Scenarios
Manual Test
Cases
Automation
Scripts
Test Data
Environment
Data
Test Report
Object
Repository
Library
Recovery
Scenario
Automation Work Flow
Refactoring
Manual Test
Cases
Feasibility
Analysis
Create Shared
Object Repository
Create
Automation
Scripts
Create Reusable
Actions or User
Defined Functions
Debug
Automation
Scripts
Create Test Data
Upload Scripts &
Mapped To QC
Identification of
Reusable
Components
Create Recovery
Scenarios
Level1
Level2
Run The
Automation
Scripts from QC
Level3
Test Report
Analysis
Feasibility Analysis
Formal selection of manual test cases for automation:
Decision will be been taken on what can be automated and what cannot be
automated.
Selection of the test cases to be automated will be based on the business
risk attached to each test
Tests that need to run once and those that need frequent human
intervention are usually not worth the investment to automate and need not
be considered for automation
Avoiding business scenarios where complex hardware is involved
Sample feasibility analysis report.
Feasibility Analysis
Sample_Feasibility_Report.xls
Feasibility
Report for a Test
Case
Folder Structure
Object Identification Tool
Following is the list of mandatory properties that will be used for UI elements:
UI Element
Mandatory Properties
Ordinal Identifier
Smart Identification
Browser
name
creation Time
No
Page
title
index
No
Frame
name, title
WebEdit
html id, name, type
index
No
WebButton
html id, name, value
index
No
WebCheckBox
html id, name, type
index
No
WebRadioButtonGroup
html id, name, type
index
No
WebTable
html id, name
index
No
Link
text
index
No
WebList
html id, name, html tag
index
No
No
Note : The list of mandatory properties for GUI elements may change if required.
Test Data Maintainance
Sheet Name
Test Data
Accessing Test Data
Test Data is defined in separate excel files for each application in Move
Test Scripts written in QTP will access the Test Data using QTP’s Data Table
feature.
Test data defined in separate excel files will be imported into QTP’s Data Table.
Importing Test Data from external excel files will be done using an import
statement.
Following syntax used to import a sheet from test data.xls file to a sheet in data
table
Syntax : Datatable.ImportSheet “Location of TestData.xls file”, “sheet ID in
Testdata.xls file” , “Sheet id/sheet name in data table"
Example: Datatable.ImportSheet “C:\Testdata.xls”,3, “Login"
Reusable Components
There are two types of Reusable Components
 Reusable Action
 User Defined Functions
 Generic Functions
 Business Functions
Reusable Actions and User Defined Functions are maintained in separate folders for
entire application.
The advantage of using Reusable Actions is that it can be easily debugged and can
use the intelligence feature of QTP IDE.
All common scenarios will be captured using Reusable actions.
Functions will be used for performing generic tasks e.g. like splitting a string, etc.
These tasks are application independent.
Environment File
Environment files are also called as initialization files or configuration files.
Environment files are created in external files with .xml format
Create Environment variables to access information like Server Name, Application URL,
username, password, library files and Test Data.
This file can be used across all the called Actions and in all the Test Scripts.
Throughout the test the value of an Environment Variable remains the same.
Environment File Contd.
Main Test Runner Structure
Main Test Runner
Environment File /
Initialization file
Test Suite1
(Ex. FH)
Reusable Actions
Object Repository
User defined functions
Test Scripts
Generic Functions
Test Data
Test Components
of each Module
Generic Functions
Test Results
Test Execution
New Change Request
Test Data for the
CR
Update Test
Cases as per CR
Quality Center
New / Modify Master
Scripts
Object Repository
Reusable Actions
Test Results
New / Modify
QTP Test
Scripts
User defined Functions
Recovery Scenarios
Exception Handling: Recovery Scenario
Exceptions are conditions which stops test script execution
 Exceptions might occur at any time during script execution
 Exceptions in QTP can be handled by using any one of the following two methods
i) Recovery Scenarios
ii) On Error Resume Next statement

Recover Scenarios will be implemented on all the modules.
 Recovery Scenarios can be defined using Recovery Scenario Manager in QTP.
 Application specific Recovery Scenarios like recovery from security warning, unknown
pop-ups etc will be defined using Recovery Scenario Manager.
Reporting Test Result
Results of the Automation Scripts will be reported using Reporter Utility object
Results are reported at test case level and at every important state of the application.
Syntax: Reporter.ReportEvent <status>,"Scenario/Case Name“ ,“Scenario/Case
description”
Status can be either micpass or micfail or micdone or micwarning
Example: Reporter.ReportEvent micPass,"Login Scenario","Auditee Logged In
Successfully”
Sample results snapshot that is reported using Reporter.ReportEvent statement is
shown
Sample Test Report
Test Case Step
Level Reporting
Results Report
Traceability between Manual Test Cases and Automation Scripts
 Traceability is maintained between Manual Test Case and Automation Test Script.
 There will be one to one mapping between Test case and Test script.
Manual Test Case Name
Test Script Name
Scripts / Reusable Actions /
Library Function
FH_Zip_Search
Traceability between Manual Test Cases and Automation Scripts
Traceability matrix maps:
 Manual Test Case to Test Script
 Test Script to Reusable components used in that script
Test scripts affected by change in application functionality can be easily traced out
since reusable components used for a Test script is maintained.
When test script fails, the traceability matrix can be used to locate manual test case
that needs to be failed.
Questions?
Suresh Kumar C
Designation and Address
E-Mail: [email protected]
46