September 2009 QTP Automation Framework. Objective  Introduction to Automation  Benefits of Automated Testing  Automated Testing Process  Introduction

  • Published on
    23-Dec-2015

  • View
    213

  • Download
    0

Embed Size (px)

Transcript

  • Slide 1
  • September 2009 QTP Automation Framework
  • Slide 2
  • Objective Introduction to Automation Benefits of Automated Testing Automated Testing Process Introduction to QTP Framework Framework Structure Environment Supported
  • Slide 3
  • 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 Testing
  • Slide 4
  • Benefits of Automation Testing Why Automation - Fast - Reliable - Repeatable - Programmable - Comprehensive - Reusable Automated Testing
  • Slide 5
  • 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
  • Slide 6
  • 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.
  • Slide 7
  • 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
  • Slide 8
  • Type of Automation Frameworks Data Driven Framework Modularity Framework Keyword Driven Framework Hybrid Framework
  • Slide 9
  • 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.
  • Slide 10
  • 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
  • Slide 11
  • 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).
  • Slide 12
  • 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
  • Slide 13
  • 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
  • Slide 14
  • 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.
  • Slide 15
  • Startup Script - Code
  • Slide 16
  • 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
  • Slide 17
  • Driver Script - Code
  • Slide 18
  • 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.
  • Slide 19
  • 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.
  • Slide 20
  • How QTP Stores Test Objects Object Repository Manager QTP TEST SCRIPT Generates Script Add objects using object Identification settings
  • Slide 21
  • Object Repository Contd. Types of Object Repositories: Per Action Object Repository Shared Object Repository
  • Slide 22
  • Object Repository Contd. Per Action Object Repository Object Repository TEST 1 ACTION 1 ACTION 2. ACTION - N TEST 1 ACTION 1 ACTION 2. ACTION - N Object Repository Object Repository Object Repository
  • Slide 23
  • Object Repository Contd. Shared Object Repository TEST 1 ACTION 1 ACTION 2 TEST 2 ACTION 1 ACTION 2 Shared Object Repository
  • Slide 24
  • Functional Library/Action Library
  • Slide 25
  • Test Cases
  • Slide 26
  • 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.
  • Slide 27
  • 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.
  • Slide 28
  • Automation Framework Structure Manual Test Cases Manual Test Cases Feasibility Report on Test Scenarios Feasibility Report on Test Scenarios AUT Automation Scripts Automation Scripts Data Test Data Test Report Environment Library Object Repository Object Repository Recovery Scenario Recovery Scenario
  • Slide 29
  • Automation Work Flow Refactoring Manual Test Cases Feasibility Analysis Identification of Reusable Components Run The Automation Scripts from QC Create Automation Scripts Debug Automation Scripts Upload Scripts & Mapped To QC Test Report Analysis Create Reusable Actions or User Defined Functions Create Recovery Scenarios Create Test Data Create Shared Object Repository Level1 Level2 Level3
  • Slide 30
  • 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.
  • Slide 31
  • Feasibility Analysis Sample_Feasibility_Report.xls Feasibility Report for a Test Case
  • Slide 32
  • Folder Structure
  • Slide 33
  • Object Identification Tool Following is the list of mandatory properties that will be used for UI elements: UI ElementMandatory PropertiesOrdinal IdentifierSmart Identification Browsernamecreation TimeNo PagetitleindexNo Framename, titleNo WebEdithtml id, name, typeindexNo WebButtonhtml id, name, valueindexNo WebCheckBoxhtml id, name, typeindexNo WebRadioButtonGrouphtml id, name, typeindexNo WebTablehtml id, nameindexNo LinktextindexNo WebListhtml id, name, html tagindexNo Note : The list of mandatory properties for GUI elements may change if required.
  • Slide 34
  • Test Data Maintainance Test Data Sheet Name
  • Slide 35
  • 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 QTPs Data Table feature. Test data defined in separate excel files will be imported into QTPs 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"
  • Slide 36
  • 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.
  • Slide 37
  • 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.
  • Slide 38
  • Environment File Contd.
  • Slide 39
  • Main Test Runner Structure Test Components of each Module Test Results Main Test Runner Environment File / Initialization file Test Scripts Object Repository Test Data Reusable Actions User defined functions Generic Functions Test Suite1 (Ex. FH)
  • Slide 40
  • Test Execution New Change Request Update Test Cases as per CR Quality Center New / Modify QTP Test Scripts New / Modify Master Scripts Test Results Test Data for the CR Object Repository Reusable Actions User defined Functions Recovery Scenarios
  • Slide 41
  • 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.
  • Slide 42
  • 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,"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
  • Slide 43
  • Sample Test Report Test Case Step Level Reporting Results Report
  • Slide 44
  • 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 NameTest Script Name Scripts / Reusable Actions / Library Function FH_Zip_Search
  • Slide 45
  • 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.
  • Slide 46
  • 46 Questions? Suresh Kumar C Designation and Address E-Mail: Suresh.kumar@move.com