Open2Test E-Tester UserGuide

www.open2test.org Page 1

Open2Test Web Test Automation framework for Oracle’s 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.

Open2Test Web Test Automation framework for Oracle’s e-Tester - User Guide


Table of Contents

1 Acronyms ............................................................................................................................................. 4

2 Preface .................................................................................................................................................. 5

3 Framework Overview ........................................................................................................................... 6

3.1 Introduction to the Framework ................................................................................................................... 6

3.2 Framework Features .................................................................................................................................. 7

4 Framework Architecture ...................................................................................................................... 8

4.1 Framework Architecture ............................................................................................................................. 8

4.1.1 Oracle’s 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

5 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

5.2 Web Objects ............................................................................................................................................ 32

6 Benefits............................................................................................................................................... 36

7 Current Limitations ............................................................................................................................ 38

Appendix – A .............................................................................................................................................. 39

Appendix – B .............................................................................................................................................. 45

Appendix – C .............................................................................................................................................. 46



Appendix – D .............................................................................................................................................. 47



1 Acronyms

FL Function Library

DS Driver Script

AUT Application Under Test

HTML Hyper Text Markup Language

DOM Document Object Model

ORN Object Reference Name

KRD Keyword Reference Document

KDF Keyword-Driven Framework



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

dependent, 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 Oracle’s functional testing tool

(earlier known as Empirix’s e-Tester), which can be used for Web application testing.



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.



The framework provided in this document is a keyword-driven test framework that works with Oracle’s 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.



4 Framework Architecture

4.1 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



Test Script

(Driver Script)

Abstract Layer

AUT

e-Tester Driver

Script

Keyword Test Case &

Global Object

Repository

Test Results

External Test Data

Framework

Keyword Function

Library



Figure 1 – Framework Architecture



4.1.1 Oracle’s e-Tester

Oracle’s 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 “Oracle’s 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 Oracle’s

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



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 doesn’t 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

� View from the Menu Bar � Source

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:



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.



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-Tester’s 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.



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:

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:

Name of the Variable

Test Data



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:

R 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



Flow Diagram

Figure 5 – Flow Diagram



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



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



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.



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



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

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

ACTION



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 Operation

Login_Btn enabled;<VarName>

If the user wants to check whether the object is disabled, the syntax would be:

Object Operation

Uname_Txt disabled;<VarName>

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.

CHECKING

CHECKING



- 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



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



5.2 Web Objects

1. Button

Operation Description

Click Click the Button

Submit Submits the enabled button

Enabled Check if the object is enabled or not

Disabled Check if the object is disabled or not

Exist 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 Description Set: text Set the edit field to the given text




Read;<Vname> 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









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







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


Click To Click the RadioButton




Checked To check whether the checkbox is checked or not



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


Check To check the Checkbox

Uncheck To uncheck the Checkbox

Checked To verify whether the Checkbox is checked or not

Unchecked To verify whether the Checkbox is unchecked or not

Enabled Verifies whether the object is enabled or not

Disabled Verifies whether the object is disabled 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


Exist 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


Click To click on the link

Visible Check if the link is visible or not



Exist Check if the link exists or not

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



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.



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 don’t 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.



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

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

Tester’s Dialog Manager feature.

c) Current keyword test scripts cannot be used in e-Load for load/performance testing.



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



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

5. Click on the Stop button on the tool bar to stop the recording.



6. Expand the ‘+’ icon displayed beside the first page of the driver script.



7. Right click on Custom Page Programmability, select Edit VBA Code option, and launch VBA editor of e-

Tester.

8. Paste the DS-Page_Level code of the framework in Page_001 of the driver script.



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.



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

4. Rename the imported file as “Tester.”



Appendix – B

Steps to create the internal variable in e-Tester

1. Select Edit �Data Bank Wizard from the e-Tester menu bar.

2. In the Data Bank Wizard, click on the Add Variable button.

3. In the Add Variable window, enter the name of the variable as KwordTC.

4. Choose the Type as Internal Specify Expression

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



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



Appendix – D

Web Sources for Connection String Reference:

http://www.carlprothman.net

http://www.connectionstrings.com

C O P Y R I G H T

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.

Documents

Open2Test E-Tester UserGuide