september 2009 qtp automation framework. objective introduction to automation benefits of...
TRANSCRIPT
September 2009
QTP Automation Framework
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.
- Low reliability.
Manual TestingManual Testing
Benefits of Automation Testing
Why Automation
- Fast
- Reliable
- Repeatable
- Programmable
- Comprehensive
- Reusable
Automated TestingAutomated 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
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.
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
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 = Modularity + Data Driven
Hybrid = Keyword Driven + Data Driven
Hybrid Framework
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
ObjectRepository
Manager
QTP TEST SCRIPT
Generates Script Add objects using object Identification settings
Object Repository Contd.
Types of Object Repositories:
Per Action Object Repository
Shared Object Repository
Object Repository Contd.
Per Action Object Repository
ObjectRepository
TEST 1
ACTION 1ACTION 2
.
.ACTION - N
TEST 1
ACTION 1ACTION 2
.
.ACTION - N
ObjectRepository
ObjectRepository
ObjectRepository
Object Repository Contd.
Shared Object RepositoryTEST 1
ACTION 1ACTION 2
TEST 2
ACTION 1ACTION 2
Shared ObjectRepository
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
Manual Test
Cases
Manual Test
CasesFeasibility
Report on Test
Scenarios
Feasibility
Report on Test
Scenarios
AUTAUT
Automation
Scripts
Automation
Scripts
Data
Test DataTest Data Test ReportTest ReportEnvironment
Environment
LibraryLibraryObject
Repository
Object
RepositoryRecovery
Scenario
Recovery
Scenario
Automation Work Flow
Refactoring Manual Test
Cases
Refactoring Manual Test
Cases
Feasibility Analysis
Feasibility Analysis
Identification of Reusable
Components
Identification of Reusable
Components
Run The Automation
Scripts from QC
Run The Automation
Scripts from QC
Create Automation
Scripts
Create Automation
Scripts
Debug Automation
Scripts
Debug Automation
Scripts
Upload Scripts & Mapped To QC
Upload Scripts & Mapped To QC
Test Report Analysis
Test Report Analysis
Create Reusable Actions or User
Defined Functions
Create Reusable Actions or User
Defined Functions
Create Recovery Scenarios
Create Recovery Scenarios
Create Test Data Create Test Data
Create Shared Object Repository
Level1
Level2
Level3
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 No
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
Note : The list of mandatory properties for GUI elements may change if required.Note : The list of mandatory properties for GUI elements may change if required.
Test Data Maintainance
Test DataTest DataSheet Name Sheet Name
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
Test Components of each Module Test ResultsTest Results
Main Test RunnerEnvironment File / Initialization file
Test Scripts
Object Repository
Test Data
Reusable Actions
User defined functions
Generic Functions
Generic Functions
Test Suite1 (Ex. FH)
Test Execution
New Change Request
Update Test Cases as per
CR
Quality Center
New / Modify QTP Test Scripts
New / Modify Master Scripts
Test ResultsTest Results
Test Data for the CR
Object Repository
Reusable ActionsReusable Actions
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 ReportingTest Case Step Level Reporting
Results ReportResults 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 NameScripts / 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.
