
fa006d85c7aa081ed528c63ecfcba9fa.ppt
- Количество слайдов: 46
QTP Automation Framework September 2009
Objective v Introduction to Automation v Benefits of Automated Testing v Automated Testing Process v Introduction to QTP Framework v Framework Structure v 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 Testing
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: v v v v 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: v. A test automation framework is a set of assumptions, concepts, and practices that provide support for automated software testing. v. A comprehensive architecture to drive the complete test automation process. What is the need of having a Test Automation Framework: v. Pitfalls of available standard Test Automation tools. v. Testers are testers not programmers. v. Complexity and Maintenance. v. Test tool Costs. v. Test Automation is seldom a full time effort.
Automation Frameworks: Advantages Framework Advantages: v. Scalability v. Maintainability v. Removes most testers from automation complexities v. Can make automation efforts more holistic: Application independent v. Minimize Automation Risks v. Ensure Automation ROI
Type of Automation Frameworks v. Data Driven Framework v. Modularity Framework v. Keyword Driven Framework v. Hybrid Framework
Type of Automation Frameworks Contd. Data Driven Framework v. 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 v. 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 v. Data Driven Framework can be combined with Modular or Keyword Driven Framework to create a Hybrid Framework
Type of Automation Frameworks Contd. Modular Framework v. Requires creation of small, independent scripts that represents modules/sections/functions of the application under test. v. The modules are then used in a hierarchical or logical fashion to construct larger test realizing an actual test case. v. Features in QTP to support Modularity Framework: ØReusable Actions ØFunctional Libraries
Type of Automation Frameworks Contd. Keyword Driven Framework v. Keyword-driven testing framework refer to an application-independent automation framework. v. This framework requires the development of data tables and keywords, independent of the test automation tool used to execute them. v. The driver code "drives" the application-under-test, keyword driven test and the data. v. Keyword-driven tests look very similar to manual test cases. v. 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 v. The most successful automation frameworks generally accommodate both keyword driven testing as well as data driven scripts. v. Hybrid is a combination of Functional Decomposition and Data Driven Framework. v 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. v. Startup Script v. Driver Script v. Test Scheduler v. Object Repository v. Functional Library/Action Library v. Test Cases v. Test Data Files v Environment Files v. Reporting Mechanism v. Exception Handling: Recover Scenarios
Startup Script v. 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. v. We can put start applications URL/Address/Exe file path in the default record or run settings for Windows/WEB applications. v. 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 v. Object Repository acts as a translator between QTP script and the Operating System. v. QTP stores information it learns about a window or an object in object repository. v. When QTP runs a test, it uses the object repository to locate objects. v. 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: v. Per Action Object Repository v. Shared Object Repository
Object Repository Contd. Per Action Object Repository TEST 1 ACTION 2. . ACTION - N Object Repository
Object Repository Contd. Shared Object Repository TEST 1 TEST 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 Feasibility Analysis Identification of Reusable Components Create Shared Object Repository Create Reusable Actions or User Defined Functions Debug Automation Scripts Create Test Data Refactoring Manual Test Cases Create Automation Scripts Upload Scripts & Mapped To QC Create Recovery Scenarios Level 1 Level 2 Run The Automation Scripts from QC Level 3 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 Web. Edit html id, name, type index No Web. Button html id, name, value index No Web. Check. Box html id, name, type index No Web. Radio. Button. Group html id, name, type index No Web. Table html id, name index No Link text index No Web. List html id, name, html tag index No No Note : The list of mandatory properties for GUI elements may change if required.
Test Data Maintainance Test Data Sheet Name
Accessing 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. Import. Sheet “Location of Test. Data. xls file”, “sheet ID in Testdata. xls file” , “Sheet id/sheet name in data table" Example: Datatable. Import. Sheet “C: Testdata. xls”, 3, “Login"
Reusable Components There are two types of Reusable Components v Reusable Action v User Defined Functions v Generic Functions v 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 v. Environment files are also called as initialization files or configuration files. v. Environment files are created in external files with. xml format v. Create Environment variables to access information like Server Name, Application URL, username, password, library files and Test Data. v. This file can be used across all the called Actions and in all the Test Scripts. v. 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 Suite 1 (Ex. FH) Object Repository Reusable Actions 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 v Exceptions might occur at any time during script execution v Exceptions in QTP can be handled by using any one of the following two methods i) Recovery Scenarios ii) On Error Resume Next statement v Recover Scenarios will be implemented on all the modules. v Recovery Scenarios can be defined using Recovery Scenario Manager in QTP. v Application specific Recovery Scenarios like recovery from security warning, unknown pop-ups etc will be defined using Recovery Scenario Manager.
Reporting Test 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. Report. Event <status>, "Scenario/Case Name“ , “Scenario/Case description” Status can be either micpass or micfail or micdone or micwarning Example: Reporter. Report. Event mic. Pass, "Login Scenario", "Auditee Logged In Successfully” Sample results snapshot that is reported using Reporter. Report. Event statement is shown
Sample Test Report Test Case Step Level Reporting Results Report
Traceability between Manual Test Cases and Automation Scripts v Traceability is maintained between Manual Test Case and Automation Test Script. v 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: v Manual Test Case to Test Script v 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: Suresh. kumar@move. com 46
fa006d85c7aa081ed528c63ecfcba9fa.ppt