1 / 46

September 2009

September 2009. QTP Automation Framework. Objective. Introduction to Automation Benefits of Automated Testing Automated Testing Process Introduction to QTP Framework Framework Structure Environment Supported. Manual Testing. Introduction to Automation. Drawbacks of Manual testing

stian
Télécharger la présentation

September 2009

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. September 2009 QTP Automation Framework

  2. Objective • Introduction to Automation • Benefits of Automated Testing • Automated Testing Process • Introduction to QTP Framework • Framework Structure • Environment Supported

  3. Manual Testing 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.

  4. Automated Testing Benefits of Automation Testing • Why Automation - Fast - Reliable - Repeatable - Programmable - Comprehensive - Reusable

  5. Automation Testing Process Automated testing involves three main steps • 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 Creating Script(s) Executing Script(s) Analyzing Result(s)

  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.

  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

  8. Type of Automation Frameworks • Data Driven Framework • Modularity Framework • Keyword Driven Framework • Hybrid Framework

  9. 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

  10. 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

  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).

  12. HybridFramework HybridFramework • 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

  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

  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.

  15. Startup Script - Code

  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

  17. Driver Script - Code

  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.

  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.

  20. Add objects using object Identification settings Generates Script QTP TEST SCRIPT Object Repository Manager How QTP Stores Test Objects

  21. Object Repository Contd. • Types of Object Repositories: • Per Action Object Repository • Shared Object Repository

  22. TEST 1 ACTION 1 ACTION 2 . . ACTION - N TEST 1 ACTION 1 ACTION 2 . . ACTION - N Object Repository Object Repository Object Repository Object Repository Object Repository Contd. Per Action Object Repository

  23. TEST 1 ACTION 1 ACTION 2 TEST 2 ACTION 1 ACTION 2 Shared Object Repository Object Repository Contd. Shared Object Repository

  24. Functional Library/Action Library

  25. Test Cases

  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.

  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.

  28. AUT Feasibility Report on Test Scenarios Manual Test Cases Automation Scripts Data Object Repository Library Recovery Scenario Test Data Environment Test Report Automation Framework Structure

  29. Create Shared Object Repository Create Automation Scripts Refactoring Manual Test Cases Create Reusable Actions or User Defined Functions Debug Automation Scripts Test Report Analysis Feasibility Analysis Create Test Data Upload Scripts & Mapped To QC Identification of Reusable Components Create Recovery Scenarios Run The Automation Scripts from QC Automation Work Flow Level1 Level2 Level3

  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.

  31. Feasibility Analysis • Sample_Feasibility_Report.xls Feasibility Report for a Test Case

  32. Folder Structure

  33. Object Identification Tool Following is the list of mandatory properties that will be used for UI elements: Note : The list of mandatory properties for GUI elements may change if required.

  34. Test Data Maintainance Sheet Name Test Data

  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 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"

  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.

  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.

  38. Environment File Contd.

  39. Test Suite1 (Ex. FH) Object Repository Test Scripts Test Data Main Test Runner Structure Main Test Runner Environment File / Initialization file Reusable Actions User defined functions Generic Functions Generic Functions Test Components of each Module Test Results

  40. New Change Request Test Execution Test Data for the CR Update Test Cases as per CR Quality Center New / Modify Master Scripts Object Repository Reusable Actions User defined Functions New / Modify QTP Test Scripts Test Results Recovery Scenarios

  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.

  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 <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

  43. Sample Test Report Test Case Step Level Reporting Results Report

  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.

  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.

  46. Questions? Suresh Kumar C Designation and Address E-Mail: Suresh.kumar@move.com

More Related