Open2Test E-Tester UserGuide

Open2Test Web Test Automation framework for Oracles e-Tester
- User Guide
Version 1.00
October 22, 2009
STATEMENT OF CONFIDENTIALITY / DISCLAIMER This document is the property of Keane and is produced in response to your request. No part of this document shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, to parties outside of your organization without prior written permission from Keane.
www.open2test.org
Page 1
Open2Test Web Test Automation framework for Oracles e-Tester - User Guide
Table of Contents
1 2 3 Acronyms ............................................................................................................................................. 4 Preface .................................................................................................................................................. 5 Framework Overview ........................................................................................................................... 6
3.1 3.2 Introduction to the Framework ................................................................................................................... 6 Framework Features .................................................................................................................................. 7
Framework Architecture...................................................................................................................... 8
4.1 Framework Architecture ............................................................................................................................. 8 4.1.1 Oracles e-Tester .........................................................................................................................11 4.1.2 VBA References ..........................................................................................................................11 4.1.3 Driver Script .................................................................................................................................11 4.1.4 Keyword Function Library ............................................................................................................12 4.1.5 Global Object Repository .............................................................................................................12 4.1.6 Keyword Test Case......................................................................................................................16 4.1.7 External Test Data .......................................................................................................................17 4.1.8 Test Results .................................................................................................................................18
Generating Test Scripts Using Keyword-Driven Framework ......................................................... 22

5.1 Keyword Reference Document ................................................................................................................ 22 5.1.1 Columns Details in Keyword Reference Document (KRD) ..........................................................23 5.1.2 Delimiters .....................................................................................................................................30 Web Objects ............................................................................................................................................ 32
5.2
6 7
Benefits............................................................................................................................................... 36 Current Limitations ............................................................................................................................ 38
Appendix A.............................................................................................................................................. 39 Appendix B.............................................................................................................................................. 45 Appendix C.............................................................................................................................................. 46

www.open2test.org Page 2
Appendix D.............................................................................................................................................. 47
www.open2test.org
Page 3
1 Acronyms
FL DS AUT Function Library Driver Script Application Under Test
HTML Hyper Text Markup Language DOM ORN KRD KDF Document Object Model Object Reference Name Keyword Reference Document Keyword-Driven Framework
www.open2test.org
Page 4
2 Preface
Automation testing is an emerging field that defines the approach to be followed in order to draw maximum benefits with minimum effort. The purpose of automated testing is to increase the flexibility of time and resources, avoid redundancy of test execution, and increase test coverage, thus improving the quality and reliability of the software. Automation testing requires expertise and experience with respect to the tool and the associated scripting language in order to prepare a complete, flexible, and effective test script. The maintenance effort required to maintain the artifacts is also quite high. Understanding and addressing the limitations of the existing methodologies, an emerging approach called keyword-driven framework, is being developed for different automation tools. The keyword-driven testing framework (also known as table-driven testing or action-driven testing) is a technologydependent, application-independent approach, which defines the various business events that make up an application using discrete keywords. The major positive aspects of this approach would include reusability, optimum utilization of the tool, minimum effort, less maintenance, and more productivity. This methodology requires extensive planning, greater tool expertise, and a longer initial time investment when compared to other approaches. But ROI would become multifold when this approach is designed effectively. This document explains the keyword-driven framework approach developed for Oracles functional testing tool (earlier known as Empirixs e-Tester), which can be used for Web application testing.
www.open2test.org
Page 5
3 Framework Overview
3.1 Introduction to the Framework
Automation testing is a kind of testing, in which a software tool is used to control the execution of tests, the comparision of actual outcomes with predicted outcomes, in setting up of test preconditions and other test control and test reporting functions. Automation Testing can be broadly classified into two categories: 1. Functional testing tools Used for functional and regression testing purposes. 2. Performance testing tools Used for performance and load testing purposes Automation testing requires a well-defined approach in order to reap maximum benefits. Several types of approaches and frameworks are being developed to increase the efficiency and effectiveness of functional testing. A test automation framework is a set of assumptions, concepts, and practices that provide support for automated software testing. Various automation frameworks include: Test Script Modularity Framework (TSMF) Test Library Architecture Framework (TLAF) Data-Driven Automation Framework (DDAF) Keyword-Driven Automation Framework (KDAF) Hybrid Automation Framework (HAF) Keyword-based test design and test automation is formed on the premise that the discrete functional business events that make up any application can be described using short text description (keywords). By designing keywords to describe discrete functional business events, the testers begin to build a common library of keywords that can be used to create test scripts.
www.open2test.org
Page 6
The framework provided in this document is a keyword-driven test framework that works with Oracles e-Tester product. This framework allows testers to develop test cases using Microsoft Excel and a list of keywords. When the test is executed, the framework processes the Excel workbook and calls functions associated with the keywords entered in the Excel spreadsheet. These keyword functions in turn perform specific actions against the Application Under Test (AUT).
3.2 Framework Features

Along with such standard features as performing operations and verifications on the objects, a number of other sophisticated features are also included:
Usage of Variables: Variables can be defined, manipulated, and used across the generated test
script.
Conditional Checking: Conditional constructs like if can be implemented using keywords to handle
different flows based on conditions.
Data-Driven Testing: This framework supports data-driven testing by importing data from external
data sheets and can be used in various fields over iterations.
Reports: A customized report, generated both in e-Tester and MS Excel, helps perform effective
analysis on execution reports.
User-Defined Functions: User-defined functions can be included in the framework to automate the
application-specific functions.
Looping: Required test steps can be run for the required number of times using the looping construct. Iteration: Test scripts can be iterated for the required number of times.
Exception Handling: Run-time errors are effectively handled and reported using this framework.
www.open2test.org
Page 7
4
4.1
Framework Architecture
Framework Architecture
Architecture forms the foundation of any software application. It should be robust enough to handle the desired functions efficiently and effectively. In order to make all the components of the system work in synchronization with each other, it is important to define the components and functionalities, as well as the binding relationship between them. The automation framework architecture comprises the following components:
Framework
The framework consists of the following sub-components, namely: Keyword Functions (KF)
Abstract Layer
The abstract layer consists of the following sub-components, namely: Driver Script Keyword TC Global Object Repository Test Results (in e-Tester and MS Excel)
External Data
The external data consists of the following sub-component, namely: Data Sheet
www.open2test.org
Page 8
Framework
Abstract Layer
Keyword Function Library
Keyword Test Case & Global Object Repository
e-Tester Driver Test Script Script (Driver Script)
Test Results
External Test Data
AUT
Figure 1 Framework Architecture
www.open2test.org
Page 10
4.1.1 Oracles e-Tester

Oracles e-Tester is a flexible, easy-to-use solution for automated functional and regression testing of Web applications and Web services. It provides testing flexibility and extensibility through the e-Test Programming Interface (e-PI). The e-PI can be used with standard programming languages, such as Visual Basic, VBScript, JavaScript, Java, and C++ to extend the capabilities of Visual Scripts. e-Tester has been rebranded as Oracles functional testing tool after the acquistion of Empirix e-Tester. Functional test scripts generated in e-Tester can be used in Job Scheduler for scheduling job runs and in Oracles load testing tool (earlier Empirix e-Load) for load/performance testing purposes. This framework has been written in e-PI using the scripting language VBA (Visual Basic for Application).
4.1.2 VBA References

The following general references need to be added in e-Tester VBA to use this framework: Microsoft Excel 11.0 Library This reference is required to make use of MS Excel VBA features in e-PI VBA.
Shared Module This reference is required to access the functions and variables across modules.
4.1.3 Driver Script

Driver Script (DS) is the Visual Script recorded in e-Tester. It calls the CallKeyword function, which calls various functions based on the keywords from the keyword test scripts. DS consists of a single page, and it has been recorded by launching any Web page URL in e-Tester. e-Tester has two default event-driven sub-routines in VBA: 1. BeforePlay Event Procedure 2. AfterPlay Event Procedure
www.open2test.org
Page 11
BeforePlay Event Procedure is used to launch the required Web application in the browser pane of e-Tester. AfterPlay Event Procedure is used to perform various actions/functions on the Web page elements. These procedures accomplish these functions by calling the CallKeyword function of the framework placed in the Shared Module.
4.1.4 Keyword Function Library

The keyword function (KF) Library forms the backbone of the automation framework. Various keyword functions have been defined in this library and used to perform a range of actions on the AUT, based on the keyword test scripts. BeforePlay Event and AfterPlay Event sub-routines of the driver script call the routines defined in the KF Library through the CallKeyword function of KF Library.
4.1.5 Global Object Repository

As e-Tester doesnt have a built-in Object Repository kind of feature, the Object Repository of the AUT needs to be defined in a separate xls file. Later in keyword TC, the user needs to reference the Object References defined in the Object Repository file. To perform any operations on the Web page elements, those elements need to be identified by the framework. Keyword functions require inputs in the form of corresponding element parameters to identify them. This framework supports two kinds of element parameters as inputs: 1. HTML parameters of the element 2. DOM path of the element 4.1.5.1 HTML Parameters
HTML parameters of the object can be passed as an input to the keyword functions to identify and to perform the required operations on them. Tag HTML:: should precede the inputs under the Parameters column of the keyword TC if HTML parameters are provided as inputs. The format in which HTML parameter inputs need to be provided is:
HTML::Value;Tag;Property Where Value corresponds to the value of the required objects HTML property, this can be a wildchar character, Tag corresponds to the tag name in which the corresponding HTML property has been enclosed, Property corresponds to the corresponding HTML property name. HTML properties of the required Web page can be found by either: Right Click View Source Source
View from the Menu Bar Examples: HTML::*username*;input;name HTML::*1*;a;id
HTML::*/OneSalesView/images/search*;input;src 4.1.5.2 DOM Path
Definition: The Document Object Model (DOM) is a cross-platform and language-independent convention for representing and interacting with objects in HTML, XML, and XHTML documents. Objects under the DOM (also called Elements) may be specified and addressed according to the syntax and rules of the programming language used to manipulate them. The DOM path of the Web page elements can be provided as input to keyword functions to identify and perform required operations on them. Tag DOM:: should precede the inputs under the Parameters column of Keyword TC if the DOM path of the element is provided as input.
The format in which the DOM path needs to be provided is:
www.open2test.org
Page 13
DOM::ElementPath The DOM path of the required element can be found using the Get Path to Element feature of e-Tester and it can be found by following these five steps: 1. Load the required Web page in the e-Tester browser pane. (The user can paste the required Web URL in the address bar of e-Testser in non-recording mode and navigate to the required page). 2. Click on the Get Path to Element icon on the tool bar.
3. Click on the required Web Page element; e-Tester will capture the DOM path of the corresponding element.
www.open2test.org
Page 14
4. Click on the OK button in the Select Element window. The DOM path of the chosen element will be copied to the Windows Clip board. 5. Open the e-Testers VBA e-PI and press CTRL+v on the keyboard. The copied DOM path will be pasted in VBA e-PI. Note: The user can paste the copied DOM path only in e-Tester VBA e-PI. The user can copy the DOM path from VBA e-PI and use it as required. Examples: DOM::window(index=0).form(name=""orgSearchForm"" | id=""orgSearchForm"" index=1).formelement[INPUT](name=""orgSearchForm:checkBox1"" id=""orgSearchForm:checkBox1"" | index=5 | type=""checkbox"") | |
DOM::window(index=0).form( index=0).formelement[INPUT](name=""password"" | id=""password"" | index=1 | type=""password"") DOM::window(index=0).frame(name=""mainfrm"" | index=1).link(text=""Logout"" href=""https://qavcpc.lifelinesys.com/CpcWeb/setup/site/logoutAction.do"" | index=1) |
The Object Repository Workbook acts as a repository of the required AUT objects. The user needs to provide the required Object Reference Name (ORN) for the Object References and name the cell of the Object Reference with the corresponding ORN. This can be referenced as mentioned in the three steps below: 1. In the Object Repository sheet of Keyword TC, under the Object Reference column, define the required objects of the AUT as either HTML or DOM parameter (as defined in the Object Parameters column of the KRD document; refer to Appendix C). 2. Enter the required name for the Object Reference under the Object Reference Name column.
www.open2test.org
Page 15
3. Name the Object Reference cell with the corresponding Object Reference Name using the MS Excel Define Name feature. Please refer to the sample Object Repository sheet available in Appendix C.
4.1.6 Keyword Test Case

The keyword test case written in MS Excel defines the various actions to be performed on the AUT. It triggers the specific functions in the framework in order to perform the specified operation on the desired object of the application. The path of the keyword TC sheet needs to be stored in an e-Tester Internal Variable and should be passed as a parameter to the framework. The name of the internal variable should be KwordTC. Refer to Appendix B for the steps to create the internal variable. The keyword test case sheet should be placed as first sheet in the keyword TC workbook. The keyword TC contains the following five columns, which define the test actions to be performed on AUT: 1. To be Automated Denotes whether the particular test step needs to be automated or not. Label r needs to be mentioned if the corresponding test step is to be automated. 2. Action Contains the keyword, which denotes the type of action to be performed. 3. Object Parameters Contains the ORN (as defined in Global Object Repository sheet), which denotes the object on which the action needs to be performed.
4. Action Value Contains the sub-action and test data to be used in the execution. 5. Manual Test Step Descripes the test action performed on the corresponding test step. The keyword TC should contain the path where the Global Object Repository of the corresponding application resides. Refer to Appendix C for the sample keyword test case.
4.1.7 External Test Data

External test data are given as inputs to the test scripts to execute the TC with different sets of data for the required number of iterations. The external test data need to be defined in the DataBank sheet of the Keyword Test Case Workbook, and they should be defined in the following format:
Name of the Variable
Test Data
Figure 2 External Test Data Format

Note: The DataBank sheet should be placed as the second sheet in the keyword TC workbook. The first row of the DataBank sheet corresponds to the variable name, and the system would iterate through the values placed under the <VariableName> for the test run if the corresponding variable is used in iterations. To use the DataBank feature in any required text field, the user needs to use the keyword DBank and the required variable name in the keyword test case. The format would be:
www.open2test.org
Page 17
Dbank
Appln_UName
<DataBank VariableName>
In the above case, the system would use the values of the DataBank variable in the username text field for each iteration in the test run.
4.1.8 Test Results

Users can generate two kinds of test result reports using this framework: 1. e-Tester Test Reports 2. MS Excel Test Reports The e-Tester framework has been designed in such a way that each of the keyword functions would return the result as either Pass or Fail. Under the Test Step column of the keyword test case sheet, the user needs to specify the test step description of the corresponding keyword function. For example:
Perform
Appln_UName
Set;keane
Enter Username
In the above test step, column five corresponds to the action that has been performed in the other four columns. Here, Keyword Test step has been written to set the value keane in the UserName text field and the corresponding Test Step Description is mentioned as Enter Username. 4.1.8.1 e-Tester Test Reports:
As mentioned in the above example, the e-Tester rest report would make use of the Test Step Description mentioned for each step in the keyword test case, and t would return the result as either Pass or Fail, depending on the execution.
The user can generate the test report in e-Tester by selecting View Test Reports from the menu bar. The generated test report would contain the test result (either Passed/Failed) for each of executable test step of the keyword test case. The system would return the following information in e-Tester reports for each of the test steps that are passed: Test step description from the keyword TC. Test result as Passed. If any of the Test Step has failed, the system would return the following information in e-Tester Reports: Mention the keyword function at which the error occurred, with the corresponding row number of the test step in the keyword TC. Error description. Test result as Failed. For example:
Figure 3 e-Tester Report

4.1.8.2 MS Excel Report
For each test run, the system would append the test results (either Passed or Failed) column in the results sheet of the Keyword Test Case Workbook with a mention about the timestamp of the run.
The results sheet will contain the Manual Test Step description mentioned in the keyword test case sheet. For example:
Figure 4 MS Excel Report
www.open2test.org
Page 20
Flow Diagram
Figure 5 Flow Diagram
www.open2test.org
Page 21
5 Generating Test Scripts Using Keyword-Driven Framework

5.1 Keyword Reference Document
Keyword Reference Document (KRD) is the main document that guides the tester to perform all the keyword-driven operations for various objects in the browser pane of e-Tester. The Keyword Reference Document (KRD) is prepared in such a way that it has better readability and is user-friendly. The KRD basically contains the keywords for all the actions and verifications identified for every object. This document will be the main source of input for building the framework code, and also for the tester to automate using this framework. As this document is the reference for generating the scripts, it is precise and has discrete keywords. A Keyword Reference Document (KRD) generally consists of five major columns, each giving the syntax and descriptions for performing actions and verifications on various objects.
Figure 6 A Typical Keyword TC
www.open2test.org
Page 22
5.1.1 Columns Details in Keyword Reference Document (KRD)

The following section explains in detail the four columns and their presence in the KRD.
5.1.1.1 To be Automated
The data in the To Be Automated column decides whether the current step in the test case is to be run (automated) or not. This column has the letter r, which denotes that the current step should be run. If any step in the test case is not being run, then the corresponding row in the first column is to be left blank. The steps will run based only on the data in this column.
5.1.1.2 Action
The Action column is dedicated to different types of actions that are to be performed on a particular object. It can contain any of the following keywords: a. LaunchApp LaunchApp is used to launch the Application Under Test (AUT). This keyword triggers the BeforePlay Event Procedure of the driver script to launch the Web application. The URL of the Web application should be passed as a parameter. b. Perform The Perform keyword is used to perform various operations on the required object. Either HTML parameters/DOM path of the object can be passed as a parameter. c. Check The Check keyword is used to check the various properties of the required obect. Either HTML parameters/DOM path of the object can be passed as a parameter. d. Store Value
www.open2test.org
Page 23
Store Value is used to capture the value of the required object and store it in the specified variable. Either HTML parameters/DOM path of the object can be passed as a parameter. e. Wait
Wait is used to halt the test run for a specified time or until a specified element has been loaded in the application. HTML parameters of the element should be passed as a parameter for the Wait function. The default timeout value is 10 seconds. The system would show a TimedOut error message if a specified element is not found within 10 seconds. The user can change the timeout value to a required number of seconds and the format should be 0:00:xx. By providing <TimeOut> seconds without element parameters, the user can make the test run halt for the mentioned number of seconds. f. Verify Verify is used to verify the presence/absence of the expected text on the Web application. The DOM path of the expected text should be passed as an input. The user can also store the result of the Verify function in the specified variable if required. g. VerifyVar VerifyVar is used to verify the value of the required variable. h. CmprVar CmprVar is used to compare the value of the variable with the required variable. i. end
The end keyword mentions the end of the test case in the keyword TC sheet. Note: Every TC in the keyword TC sheet should end with the keyword end. j. VarCnt
By default, the user can have 100 different variables per test run. VarCnt reinitializes the variable count to the required value.
www.open2test.org
Page 24
Note: Care should be taken while decreasing the count of variables. k. SetVariable SetVariable is used to create a new variable with the required value. l. IfBegin
IfBegin compares the value of the specified variable with the entered variable and executes the preceding set of test steps until the IfEnd keyword row, based on the result of the comparision. m. IfVar IfVar compares the value of the specified variable with another variable and executes the preceding set of test steps until the IfEnd keyword row, based on the result of the comparision. n. IfEnd IfEnd is used to mention the end of the If Condition Construct. Note: Nested If loop is not supported. o. MsgBox MsgBox is used for debugging. It is used to display the contents of a variable. p. Iterate Iterate is used to iterate the execution of the required test case for the specified number of times. Note: Iterate should be placed after the end row of the keyword TC, if that corresponding TC needs to be iterated. q. DBank The keyword DBank is used to bind the required text field with the set of external data. Object parameters of the text field and name of the Data Bank variable must be passed as an input to the DBank keyword. The corresponding DBank variable needs to be defined in the DataBank sheet of the keyword TC Workbook. Please refer to the External Data section for more information. r. DVarCnt
www.open2test.org
Page 25
By default, the user can have 25 different databank variables per test run. DVarCnt reinitializes the DataBank variable count to the required value. s. SqlOpen SqlOpen opens the db connection, and the ConnectionString of the required DB should be passed as a parameter. Refer to the Web sources mentioned in Appendix D for information about Connection Strings for various data sources. Examples: Connection String for SQL Server Provider=sqloledb;" & "Data Source=myServerName;" & "Initial Catalog=myDatabaseName;" & "User Id=myUsername;" & "Password=myPassword Connection String for Oracle (with Microsoft Provider) Provider=msdaora;" &"Data Source=MyOracleDB;" & "User Id=myUsername;" & "Password=myPassword
Note: Test runs can have only one active db connection per run. To open a new db connection, close the existing connection and then open the new connection. t. SqlExecute
SqlExecute executes an SQL query passed as a parameter in the db connection, opened using SqlOpen keyword. u. SqlClose SqlClose closes the existing open db connection. v. String Functions Using the string functions StrLen, StrReplace, and StrSearch, various string operations can be performed on the variables. w. Call Function Using this keyword, we can call the required User Defined Function and pass the parameters to the function as required.
x. Loop Using this keyword, required test steps can be run for the specified number of times. y. EndLoop This keyword specifies the end of the Loop Construct. z. Split Using this keyword, the specified string can be split into sub-strings based on the provided delimiter, and the substrings can be stored in the specified variables. aa. Random Generates the random number and stores it in the specified variable.
5.1.1.3 Object Parameters

The Object Parameters column specifies the properties of the object in which various operations needs to be performed. The Object Reference Names defined in the Global Object Repository sheet needs to be used in the Object Parameters column as required. Refer to the Global Object Repository section for detailed information about Object Parameters.
5.1.1.4 Operations
The Operations column contains the details of all the operations and verifications that can be performed on the objects listed in the Objects column. For example, of the actions that can be performed on a Button would be Click. So in column four, the above operation is put in the keyword form as click. Example 1: The keyword click on the button is as follows:
Object
www.open2test.org
Operation ACTION
Page 27
Login_Btn
click
If the user wants to check if the Button is enabled before clicking and save the result in the variable <VarName>, the syntax would be:
Object Login_Btn
Operation enabled;<VarName>
CHECKING
If the user wants to check whether the object is disabled, the syntax would be:
Object Uname_Txt
Operation disabled;<VarName>
CHECKING
Some of the keywords that are used in the Operations column (column four) are explained below: Set;<Value>: Sets the value of the required text field with the specified value. enabled;<VarName>: Verifies whether the required object is enabled or not. Stores the value True in the specified variable if it is enabled; otherwise, it stores the value False. disabled;<VarName>: Verifies whether the required object is disabled or not. Stores the value True in the specified variable if it is disabled; otherwise, it stores the value False. exists;<VarName>: Verifies whether the required object exists or not. Stores the value True in the specified variable if it exists; otherwise, it stores the value False. <VarName>: Stores the value of the text field/HTML text in the specified variable. click: Clicks on the specified element. check: Checks the required check box.
Page 28
www.open2test.org
uncheck: Unchecks the required check box. checked;<VarName>: Verifies whether the required checkbox/radio button has been checked. Stores the value True in the specified variable if it is checked; otherwise, it stores the value False. unchecked;<VarName>: Verifies whether the required checkbox/radio button has been unchecked. Stores the value True in the specified variable if it is unchecked; otherwise, it stores the value False. setlist;<n1>,<n2>,<n3>: Selects the specified indexes from the required Listbox. <tsec>: Test Run halts for the specified time interval. present: Verifies whether the specified text is present or not. present;<VarName>: Verifies whether the specified text is present or not. Stores the value True if it is present; otherwise, it stores the value False in the specified variable. absent: Verifies whether the specified text is absent or not. absent;<VarName>: Verifies whether the specified text is absent or not. Stores the value True if it is absent; otherwise,it stores the value False in the specified variable. like: Verifies or compares two variable values as to whether they are alike. equals: Verifies or compares the values of two variables as to whether they are equal. notequals: Verifies or compares the values of two variables as to whether they are not equal. lessthan: Verifies or compares the values of two variables as to whether the value of variable1 is less than the value of variable 2. greaterthan: Verifies or compares the values of two variables as to whether the value of variable1 is greater than the value of variable 2.
5.1.1.5 Manual Test Step

In the keyword TC sheet, column five corresponds to the test step description of the operation/action performed in the corresponding row. The test description entered is being used in e-Tester reports and MS Excel test reports. Refer to the test results section for detailed information.
5.1.2 Delimiters
Delimiters are any string characters used to identify the sub-string limits. Delimiters are generally used with the Split function, which is used to split the input into different sub-strings. 5.1.2.1 Purpose of using Delimiters
The main purpose of using delimiters in this framework is that it breaks down the input values to different strings and takes it as a keyword to perform any operation concerned with that object. 5.1.2.2 Delimiters Used in this Framework
The most important thing that is to be kept in mind while scripting using the keyword-driven approach is to place the Separators or Delimiters appropriately between two keywords. Delimiters that are used in the framework are: <> (Not Equals) ; (semi colon) :: (double colon) , (comma)
Understanding the usage of Delimiters There are four columns involved in the keyword-driven approach. The role of delimiters comes in the Objects column (column three) and Operations column (column four). 5.1.2.3 Object Parameters column (column three):
This column is used to define the object/element in which the specified action/operation is about to perform. Two different delimiters are used in this column, and its purposes are: < > (Not Equals) Used to denote the object used in Perform, Check, or StoreValue keyword functions. Button<>HTML:: *value*;tag;property
www.open2test.org
Page 30
:: (double colon) Used to classify whether the inputs are provided as HTML parameters or DOM path. Example: HTML:: *value*;tag;property
; (semi colon) Used to classify Value, Tag, and Property name of HTML parameters for various objects. Example: HTML:: *value*;tag;property 5.1.2.4 Operations column (column four):
This column usually gives the details of the operations that need to be performed on the object. Two different delimiters are used under this column and its purposes are: ;( semi colon) Used to separate the action from the Variable Name or the Operation name. Example: set;<Value> , (comma) Used to separate the index values of the ListBox. Example: setlist;<n1>,<n2>,<n3>
www.open2test.org
Page 31
5.2 Web Objects

1. Button Operation Click Submit Enabled Disabled Exist Description Click the Button Submits the enabled button Check if the object is enabled or not Check if the object is disabled or not Check if the object exists or not
The table above describes the main functions that can be performed on the WebButton. The major operation that is normally performed on a button is Click. Various checking operations include checking if the button exists, is enabled, or is disabled.
2. Textbox
Operation Set: text Enabled Disabled Exist Read;<Vname> Description Set the edit field to the given text Check if the object is enabled or not Check if the object is disabled or not Check if the object exists or not Read the text of the text box and store it in the variable. Frmvar;<Vname> Set the edit field with the value of the given variable The table above describes the actions that can be performed on Web Edit (textbox). The operations include checking if the Editbox exists, whether it is enabled or disabled, reading the value from text box, and setting the text box with the value of the variable.
3. Dropdown
Operation Description Click Click the Button Submit Submits the enabled button
Enabled Disabled Exist
Check if the object is enabled or not Check if the object is disabled or not Check if the object exists or not
The table above describes the various ways to perform actions and verifications on a Web dropdown. Main actions include selecting one of the options from the drop down, which is performed using the operation Select. Verifications include checking if the dropdown exists, is enabled, or is disabled. Using the GetDdownValue keyword, the user can store the chosen value of the dropdown in the required variable. Note: The index of the dropdown value to be selected should be passed as an input. Index values of the dropdown options can be found in e-Tester while finding the DOM path of the dropdown.
4. ListBox
Operation Click Submit Enabled Disabled Exist Description Click the Button Submits the enabled button Check if the object is enabled or not Check if the object is disabled or not Check if the object exists or not
The table above describes the various ways to perform actions and verifications on a Web ListBox. Main actions include selecting one of the options from the list box, which is performed using the operation Select. Verifications include checking if the ListBox exists, is enabled, or is disabled. 5. RadioButton Operation Click Enabled Disabled Exist Checked
www.open2test.org
Description To Click the RadioButton Check if the object is enabled or not Check if the object is disabled or not Check if the object exists or not To check whether the checkbox is checked or not
Page 33
Unchecked
To check whether the checkbox is unchecked or not
The table gives the details of performing various operations and verifications on a Web RadioButton. The actions include mainly selecting a particular RadioButton. The verification part consists of checking if a RadioButton is enabled, exists, or is checked. 6. Checkbox Operation Check Uncheck Checked Unchecked Enabled Disabled Exist Description To check the Checkbox To uncheck the Checkbox To verify whether the Checkbox is checked or not To verify whether the Checkbox is unchecked or not Verifies whether the object is enabled or not Verifies whether the object is disabled or not Check if the object exists or not
The above table describes the actions and verifications performed on a Web Checkbox. The major action that can be performed on a checkbox is Select. Verifications include checking if the checkbox exists, whether it is enabled. and whether it is checked or not. 7. Image Operation Exist Description To check whether the image exists or not
The above table gives the details of the operations, which can be performed on a Web Image. The major operation on an image is Click. It can also be checked whether it is visible or whether the image exists or not. 8. Link Operation Click Visible
www.open2test.org
Description To click on the link Check if the link is visible or not

Page 34
Exist Text
Check if the link exists or not Check for the text in the link
The table above describes the various ways to perform actions and have verifications on a Weblink. The main action is to click on the link and proceed further in the application. As far as verifications are concerned, they include checking if the link exists or is visible, and also the comparison of the text of the link.
www.open2test.org
Page 35
6 Benefits
Reusability The keyword-driven framework is an application-independent framework that deals with all possible actions and verifications that can be performed on an object. Hence, the code for the same object can be used across different applications. Duplication of work is minimized on every level. For instance, a user might have to perform a certain action on an object of similar class (e.g., clicking a button) repeatedly. This can be in the same test case or in a different application altogether. In both cases, the same code can be reused. Optimum utilization of the tool The framework has the advantage of using keywords as the input for triggering an action. A well-built framework uses the features of the tool effectively. Less effort The effort involved in coding and reviewing is minimal when compared to other frameworks, since a good percentage of coding is done in the framework. The tester has to simply enter the keywords, and this reduces the time required for coding. Recording is also not required as the global repository is used. The amount of rework while migrating from one application to the other on the same platform is reduced as the code remains the same and, therefore, reduces the coding time. Increased quality The scripts will be of uniform quality as they make use of the same code. More productivity The keyword-driven framework is both a qualitative and quantitative approach for automation, and is highly productive when compared to any other framework. This framework also addresses the ongoing maintenance of the test scripts in a cost-effective manner.
www.open2test.org
Page 36
Maintenance Simple modifications to the application can be easily handled in the code. The changes will be done only in the external file containing the code, and scripts need not be changed. Hence, it is easy to maintain the scripts and provide cost-effective solutions for the test automation. No scripting skills required by the end user No coding skills are required to automate and review the scripts. The scripts are user-friendly with good readability. Scripts can be interpreted easily by a person who does not have complete knowledge of the tool. The time necessary to be briefed about the tool is reduced, as there is no need for coding. And minimum training is needed for executing the code in the tool. Return on investment is high Although the initial effort for building the framework is high, in the long run, the return on investment will also be high because of the reusability and optimum utilization of the tool. Independent of environment Keyword test scripts are independent of environment. The same keyword test script can be used across multiple environments with minimal changes, whereas modular test scripts are environment-dependent. No Requirement of functioning application As the keyword framework requires input in the form of element parameters, the keyword TC can be prepared even in a non-functioning application. The same can be used once the application is ready, thereby eliminating the need of proper Functioning Application for Test Script preparation. Separates test scripts from the tool As the functional testing tool and keyword TC are two different entities, updates made to the tool dont affect the test script. The keyword TC can be prepared even when the underlying tool has technical problems. Also the keyword TC can be easily transferred across systems, thereby eliminating the need for executing the test script in the same machine in which it is prepared, which involves global variables or functions.
www.open2test.org
Page 37
7 Current Limitations
Following are the current limitations of this framework, which are being sorted out: a) As e-Tester 8.5 does not include VBA scripting language feature, this framework can be only used with eTester 8.4 and lesser versions. Framework in Java needs to be developed to support OATS version 9.0.
Note: OATS (Oracle Application Testing Suite) version 9.0 will have a new functional testing tool called OpenScript, with the scripting language as Java. b) The framework needs to be tweaked for the applications involving multiple dialog boxes. Applications involving minimal dialog boxes can be used with this framework with the help of eTesters Dialog Manager feature.
c) Current keyword test scripts cannot be used in e-Load for load/performance testing.
www.open2test.org
Page 38
Appendix A
Steps to Implement Keyword Test Framework in e-Tester
Note: All the test steps mentioned here are explained for e-Tester 8.2
Driver Script Preparation

Driver Script needs to be prepared in e-Tester using the following steps: 1. Launch e-Tester. 2. Click on the New Script Icon in the tool bar.
3. Enter the required URL on the address bar of the e-Tester. Example: www.google.com, www.yahoo.com
www.open2test.org
Page 39
4. Click on the Record button on the tool bar.
5. Click on the Stop button on the tool bar to stop the recording.
www.open2test.org
Page 40
6. Expand the + icon displayed beside the first page of the driver script.
www.open2test.org
Page 41
7. Right click on Custom Page Programmability, select Edit VBA Code option, and launch VBA editor of eTester.
8. Paste the DS-Page_Level code of the framework in Page_001 of the driver script.
www.open2test.org
Page 42
9. Paste the DS-Script_Level code of the framework in ThisScript of the driver script.
10. Save the script as Driver Script.mom.
Importing Framework into e-Tester

1. Launch the VBA editor of e-Tester. 2. Select File Import File from the menu bar.
www.open2test.org
Page 43
3. Import the eTesterWebFramework.bas file into e-Tester VBA.
4. Rename the imported file as Tester.
www.open2test.org
Page 44
Appendix B
Steps to create the internal variable in e-Tester 1. 2. 3. 4. 5. Select Edit Data Bank Wizard from the e-Tester menu bar.
In the Data Bank Wizard, click on the Add Variable button. In the Add Variable window, enter the name of the variable as KwordTC. Choose the Type as Internal Specify Expression Mention the path of the Keyword TC Workbook in the expression field, enclosed within double quotes. Ex: C:\eTest.xls
6.
Click on the Evaluate button to verify the value of the variable.
7.
Click on the OK button.
www.open2test.org
Page 45
Appendix C
Keyword Reference Document (KRD) of e-Tester
eTester keyword_Web(KRD).xls
Sample Keyword Test Script
Kword_TScript.xls
Sample Global Object Repository
CPC_Obj_Reps.xls
www.open2test.org
Page 46
Appendix D
Web Sources for Connection String Reference: http://www.carlprothman.net http://www.connectionstrings.com
COPYRIGHT This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details.
www.open2test.org
Page 47

Open2Test E-Tester UserGuide

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Open2Test E-Tester UserGuide

Transféré par

Droits d'auteur :

Formats disponibles

Open2Test Web Test Automation framework for Oracles e-Tester

Generating Test Scripts Using Keyword-Driven Framework ......................................................... 22

3.2 Framework Features

Keyword Function Library

Keyword Test Case & Global Object Repository

e-Tester Driver Test Script Script (Driver Script)

External Test Data

Figure 1 Framework Architecture

4.1.1 Oracles e-Tester

4.1.2 VBA References

4.1.3 Driver Script

4.1.4 Keyword Function Library

4.1.5 Global Object Repository

View from the Menu Bar Examples: HTML::*username*;input;name HTML::*1*;a;id

HTML::*/OneSalesView/images/search*;input;src 4.1.5.2 DOM Path

The format in which the DOM path needs to be provided is:

DOM::window(index=0).form( index=0).formelement[INPUT](name=""password"" | id=""password"" | index=1 | type=""password"") DOM::window(index=0).frame(name=""mainfrm"" | index=1).link(text=""Logout"" href=""https://qavcpc.lifelinesys.com/CpcWeb/setup/site/logoutAction.do"" | index=1) |

4.1.6 Keyword Test Case

4.1.7 External Test Data

Name of the Variable

Figure 2 External Test Data Format

4.1.8 Test Results

Figure 3 e-Tester Report

Figure 4 MS Excel Report

Figure 5 Flow Diagram

5 Generating Test Scripts Using Keyword-Driven Framework

Figure 6 A Typical Keyword TC

5.1.1 Columns Details in Keyword Reference Document (KRD)

5.1.1.3 Object Parameters

5.1.1.5 Manual Test Step

5.2 Web Objects

Enabled Disabled Exist

To check whether the checkbox is unchecked or not

Description To click on the link Check if the link is visible or not

Driver Script Preparation

4. Click on the Record button on the tool bar.

10. Save the script as Driver Script.mom.

Importing Framework into e-Tester

3. Import the eTesterWebFramework.bas file into e-Tester VBA.

4. Rename the imported file as Tester.

Click on the Evaluate button to verify the value of the variable.

Click on the OK button.

Sample Keyword Test Script

Sample Global Object Repository

Vous aimerez peut-être aussi

View from the Menu Bar Examples: HTML::username;input;name HTML::1;a;id

HTML::/OneSalesView/images/search;input;src 4.1.5.2 DOM Path