Automation Architecture

8/2/2019 Automation Architecture

1/17

AUTOMATION ARCHITECTURE

TABLE OF CONTENTS

1 INTRODUCTION ............................................................................................... 3

2 TEST AUTOMATION ARCHITECTURE ........................................................... 4

2.1 QTP TEST SCRIPTS.......................................................................................... 52.2 ACCESS DATABASE............................................................................................. 52.3 OBJECT REPOSITORY.......................................................................................... 52.4 LIBRARY........................................................................................................... 52.5 TEST DIRECTOR................................................................................................. 62.6 REPORTS......................................................................................................... 6

3 QUALITY FACTORS ........................................................................................ 6

3.1 MAINTAINABILITY................................................................................................ 6

3.1.1 Data Sensitive .........................................................................................63.1.2 Behavior Sensitive ...................................................................................7

3.1.3 User Interface Sensitive ..........................................................................7

3.2 REUSABILITY..................................................................................................... 73.3 SIMPLICITY........................................................................................................ 73.4 PORTABILITY..................................................................................................... 83.5 RELIABILITY....................................................................................................... 83.6 USABILITY......................................................................................................... 83.7 PERFORMANCE.................................................................................................. 8

4 DESIGN TIME ENVIRONMENT ........................................................................ 9

4.1 FOLDERSTRUCTURE ......................................................................................... 105 RUNTIME ENVIRONMENT ............................................................................. 11

6 TEST SCRIPT LOGICAL FLOW ..................................................................... 11

7 CODING CONVENTIONS ............................................................................... 12

7.1 VARIABLE NAMING CONVENTIONS......................................................................... 127.2 CONSTANT NAMING CONVENTIONS....................................................................... 127.3 AVOIDUSAGEOFEXCESSIVEWAITSTATEMENTS........................................................ 127.4 USE WITHAND ENDWITH STATEMENT................................................................. 137.5 USE OPTION EXPLICITATTHEBEGINNINGOFTHETESTSCRIPT. .................................. 13

7.6 USE

REGULAR

EXPRESSIONS

WHENEVER

APPROPRIATE

............................................. 137.7 EXCEPTIONAND ERRORHANDLING........................................................................ 137.8 INDENTBLOCKSOFCODEFORREADABILITY............................................................. 147.9 AVOIDHARDCODINGTESTINGENVIRONMENTDEPENDENCIES........................................ 147.10 AVOIDMSGBOXWHILEPRINTINGTHE RESULTS....................................................... 147.11 USE CLOSEALLBROWSERSFUNCTION. ............................................................... 147.12 SCRIPT HEADER............................................................................................ 157.13 FUNCTIONOR REUSABLESCRIPTHEADER............................................................. 15


2/17

7.14 DIVIDETHESCRIPTINTOBLOCKS........................................................................ 167.15 COMMENTYOURCODETOMAKEITMOREREADABLE................................................ 167.16 VERIFYEACHPAGEINTHEFLOW........................................................................ 16

8 SCRIPTING CONVENTIONS .......................................................................... 16

8.1 TEST

SCRIPTS

................................................................................................. 168.2 FUNCTIONS..................................................................................................... 168.3 REUSABLE SCRIPTS.......................................................................................... 168.4 REPOSITORY FILES........................................................................................... 17

9 BEST PRACTICES ......................................................................................... 17

Document Revisions

Date Version Description Author


3/17

1Introduction

The intent of this document is to capture, information about the technicalintricacies in building the test automation framework. This can be viewedas a reference guide for those who are involved in test suite maintenanceand engineers who require technical know how about the test automation

framework. It also provides coding conventions and scripting conventionsto standardize coding style across in all the scripts.

This document discusses about the following aspects

Test Automation Architecture

Quality Factors

Design Time Environment

Runtime Environment

Test Script Logical Flow

Coding Conventions

Scripting Conventions

Best Practices

Sample Templates


4/17

2 Test Automation Architecture

The below block diagram shows the architecture at a high level.The Architecture framework consists of the following key items

1) QTP Test Scripts

2) Access Database3) Object Repository4) Library

a. Businessb. Generic

5) Test Director6) Reports


5/17

2.1 QTP Test Scripts

All the test scripts are replacing manual test cases which already written inTest Director. The steps in the manual test cases areeliminated/added/modified to suit it to automation. These Scripts are usingreusable components from the library (Generic, Business) and reading

current object information from the Object Repository. These scripts aretaking the data from the access Database sheets.

2.2 Access Database

For all test scripts the test data is maintained in centralized area in theform of MS-Access Database. This architecture relies on data drivenapproach to get the data into the scripts. This approach requires test datato be maintained outside the test logic. Based on query given in the testscript, the data is to be retrieved from database. Identify require test databased on the functionality and put it in separate sheets of the database.

Data is retrieved in each script by firing appropriate sql using the ADODBinfrastructure.

2.3 Object Repository

It is acting as an interface between QTP script and the application objects.All scripts in framework are interacting to the Object Repository. ThisObject Repository is shared across the test suite. Shared ObjectRepository is to be used in the current Architecture. The object repositorymaintained in centralized area. All add, delete, append and modify can bedone in single place. This updating object repository should get effect to

all the scripts in test suite.

2.4 Library

It helps to avoid the code duplication across the test suite and also helpsto reuse the functions/tasks across the test suite. Library is divided intoGeneric and Business.

a) Generic: Generic library incorporates canonicalfunctions and procedures of the each framework thatwould be reused by all the test scripts in architecture.

These generic functions are also able to contact ObjectRepository and Database sheets.

b) Business: Business library pertains functions andprocedures related to business tasks/functions of theapplication. These business functions are also able tocontact Object Repository and Database sheets.


6/17

2.5 Test Director

It is central repository to maintain and execute all the test scripts, objectrepository files, library (generic, business), database sheets and reports. It

is used to drive automation scripts and generate reports. This ismanagement test tool to maintain all the scripts in structured way.

2.6 Reports

This Architecture utilizes API provided by the test execution tool to reporttest status information. Framework enables, configurable test logging todatabase, utilizing the environment management abstraction.

3 Quality Factors

The overall design is done to meet the following Quality factors

1) Maintainability2) Reusability3) Simplicity4) Portability5) Reliability6) Usability7) Performance

3.1 Maintainability

Maintainability is the ease with which a script can be corrected if an erroris encountered, adapted if its environment changes, or enhanced if thereis a requirement change. The design is done in such a way that it meetsthese criteria. Maintainability can be discussed with respect to thefollowing sensitivities experienced by the Architecture.

3.1.1 Data Sensitive

Sensitivity with respect to test data is plausible from the below followingaspects

Database Design

A two-layer indirection is maintained in the framework in order to insulatethe changes in the database design from the test script logic. Thedatabase access from the test script is wrapped by database query. The

Architecture utilizes Microsoft ADO infrastructure to interact with relationaldatabase, this enables framework to easily interact with variousdatabases, independent of vendor.

Test Data


7/17

Test Data maintenance is managed utilizing the export and import utilitiesprovided by the database.

Pre requisite DataCurrent Architecture handles pre requisite data by assuming that data

would be present before running the test suite. This is managed by testdocumentation provided in the test management tool. Only in fewinstances prerequisite data is calculated/computed either from theapplication under test or using system APIs.

3.1.2 Behavior Sensitive

Any change in common functionality of the system affects the test suite.The Architecture common library concept shields the impact of rework tominimum of maintaining at one place.

3.1.3 User Interface Sensitive

The User interface sensitivity is taken care by the test execution toolfeatures. All user interface objects information is wrapped in the objectrepository. The object repository concept shields the underlying changesin physical description from the test script logic in turn minimizing theimpact of change.

To handle client side error and warning messages, a separate messagetable is constructed to minimize the impact of change in error messagedescriptions. This helps in shielding the test script changes due tominimal change in user error or warning descriptions.

3.2 Reusability

The design of the script is done in such a way that already existing codesegments can be reused in some other section of the test suite withouthaving to rewrite the same code segment again. Constant effort is spentwhile creating the test suite to identify reusable chunks of code. Thereusable code is classified into two categories. Canonical componentsare placed under generic library and businesses oriented are placedunder business library in current architecture.

3.3 SimplicityThe script execution is not very complex so that a moderately efficientuser can use the script to execute the automated test. Complex loops andlogic is always suffixed/prefixed with comments necessary to make thecode segment easier to follow. To make script simplicity follows codingconventions.


8/17

3.4 Portability

Current Architecture easily integrates with test management and testharness tool (Test Director). User can execute automation test scriptseasily from the Test Director. This architecture is designed in such waythat packaging all test suite contents in a single folder and implement any

ware in the Test Director folders. The standard way of folder structure isdefined in section 4.1.

3.5 Reliability

Reliability can be discussed under the following sub topics

Recovery from failuresThe framework currently handles predictable failures the correctiveaction undertaken is to stop test execution.

Exception HandlingArchitecture utilizes exception-handling mechanism provided by the

test execution tool to handled exceptions (for e.g. security window,security alert, incorrect data entered etc)

Application ChangesChanges in application, for e.g. if an expected web table or edit field isunavailable then framework utilizes the help of runtime exceptionthrown by test tool to exit from the test.

3.6 Usability

Usability can be discussed under the following sub topics

Test Reporting

Crisp test status reporting is implemented through out the frameworkfor ease of test analysis utilizing the infrastructure built in theframework.Query Based test reporting is also feasible if database is queried fortest status

DocumentationDocumentation is provided both for end users who would want toexecute the test suite (users guide) and users who want to maintainthe test suite for future enhancements, bug fixes.

3.7 Performance

The script should be written in such a way that it takes minimum amountof time and system resources for the test execution. Some factors to becautiously borne in mind are:

Usage of synchronization points

Using wait statements


9/17

Loading a large amount of data into memory

Proper checklists. Checking only the most necessary properties.

The following events implemented in current architecture to improve theperformance of the Test suite.

Avoid too may wait statements in test scripts.

Set global default wait time for all test scripts.

Identify reusable components and use them efficiently.

Get required test data for the current script in a single query.

4 Design Time Environment

Block diagram summarizing the design time environment

Test Script is uploaded into test plan tab of Test Director.

Test Data is maintained in MS-Access Database.

Get required test data for the current script by using database query.


10/17

Test Configuration Settings are maintained in the test setting optionsprovided in the Tool

Library, Object Repository files are under source control.

4.1 Folder structureFor the current architecture is using the following folder structure.

Folder Description/Comments

Data It consists all test data in the form access data base tables.Which is accessible for all scripts and libraries in the suite.

Lib Contains generic library and business library functions usedacross the test scripts. This Library functions are able toaccess Repository and Data Sheets.

Log It is used to store the log files information of the all testscripts.

Repository Contains complete application objects (buttons, windows, listboxes) information with logical names. All test scripts andlibrary files are accessing this Repository.

Test Scripts Here all automated test scripts are stored. These scripts areable to access Repository, Lib and Data.


11/17

5 Runtime Environment

Test Script is executed from the test lab of Test Director

Test Data is retrieved from MS Access Database

For each row in the table, the test script instance is executed

Test status is recorded in the test director repository and to the

database based on the option selected in the configuration settings.

6 Test Script Logical Flow

A typical test script flow is illustrated below

Script header with all required data.

Initialize Variables

Get current location of the script.Depending on testing environment get the current location of the

script and locate the Database, Object Repository, Library files.

Invoke browser if needed, maximize the browser and login toApplication, initialize connection with test director, get test run

information from test director.

Fetch test dataRetrieve test script related test data by using query and cache the

information in the record set object.

Assign record set data to the script variables and clean up record set.

Execute test logic & test conditions


12/17

For each row in the table for the test cases the test script isexecuted.

Report observationsAt each functional checkpoint, the Application under test currentinformation is retrieved and recorded in the log

Cleanup Logout & minimize the browser

7 Coding Conventions

Coding conventions are help to design code in a structured way. The mainreason for using these coding conventions is to standardize coding styleacross in all the scripts.Coding conventions can include the following:

Naming conventions for objects, variables, and procedures.

Commenting conventions.

Text formatting and indenting guidelines

7.1 Variable Naming Conventions

To enhance readability and consistency, use the following prefixes withdescriptive names for variables in code.

Data Type Prefix Example

Boolean bln blnFound

Byte byt bytRasterData

Date (Time) dtm dtmStart

Double dbl dblTolerance

Error err errOrderNumInteger int intQuantity

Long lng lngDistance

Object obj objCurrent

Single sng sngAverage

String str strFirstName

7.2 Constant Naming Conventions

Constant variables are separated using the underscore (_) character.For example: CON_USER_LIST_MAX, CON_NEW_LINE

7.3 Avoid usage of excessive wait statements.

Try to use sync, WaitProperty or Exist functions when waiting is requiredin a script.

For example: Browser(Bank One).page(wires).syncBrowser(Bank One).page(wires).WebObject(OK).Exist


13/17

7.4 Use With and End with Statement

With statement allow you to perform a series of statements on a specifiedobject without re-qualifying the name of the object. For example, to

change a number of different properties on a single object, place theproperty assignment statements within the with control structure, referringto the object once instead of referring to it with each property assignment.The following example illustrates use of the with statement to assignvalues to several properties of the same object.

With Browser(Bank One).page(wires)WebList(From Account).Select AS2000002WebButton(OK).Click

End With

7.5 Use Option Explicit at the beginning of the test script.When you use the Option Explicit statement, you must explicitly declare allvariables using the Dim, Private, Public, or ReDim statements. If youattempt to use an undeclared variable name, an error occurs.

Tip Use Option Explicit to avoid incorrectly typing the name of an existingvariable or to avoid confusion in code where the scope of the variable isnot clear.

The following example illustrates use of the Option Explicit statement.Option Explicit ' Force explicit variable declaration.

Dim MyVar ' Declare variable.MyInt = 10 ' Undeclared variable generates error.MyVar = 10 ' Declared variable does not generate error.

7.6 Use Regular Expressions whenever appropriate

Use regular expressions to avoid multiple Object instances in the objectrepository.For Example:

Actual Date format:05/19/2004 (mm/dd/yyyy)

After Regular Expression:[0-1][0-9]/ [0-3] [0-9]/200[0-9]

7.7 Exception and Error handling

Using Exception handling, exceptions can be defined for situations wherescript execution maybe halted. Here the user can create a function toaccept the error code or perform an action and if possible restart the test


14/17

execution (E.g.: Pressing enter key to close a popped up window) andproceed with the script execution if possible/necessary.

7.8 Indent blocks of code for readability

It makes easy to understand the code in a single glance.

For Example:

DoWhile intCount 0Then

FindItems = strItem

If strPageRT="BUSINESS SUMMARY"Then

Reporter.ReporEvent micPass,"Step1", Pass

Else

Reporter.ReporEvent micFail,"Step1", Fail

End If

End If

Loop

7.9 Avoid hard coding testing environment dependencies

Do not hardcode information which my change depending on testingenvironment. These include installation directories, DSN names, andnames of database servers, database usernames, database passwordsand database tables. It's better to define these in variables at thebeginning of the test, so you do not have to make multiple changes

throughout the script to implement an environmental change.

For Example:

Set oWshell = Createobject("WScript.shell")

strCurrentTestPath = oWshell.CurrentDirectory

strRoot =Mid(strCurrentTestPath,1,8)

strLibName = strRoot & "Lib\CommonLib.vbs"

strDataSheetName= strRoot & "Data\Login.xls"

7.10 Avoid msgbox while printing the Results.

Write results in the test results or output file in the script. Message boxesare stopping the script while it is running.

7.11 Use Close all browsers function.

Use this function at the end of each script. Because it helps us to continuenext test script smoothly with out confusion


15/17

7.12 Script Header

Script header includes the following attributes. Name, Author, Date,Description, Modified Date, Information about the Data tables,Parameters, reusable functions.

'**********************************************************************

'Script Name:

'Author:

'Date of Design:

'Date of last Revision:

'Data Sheets:

'Functions Called:

'Description:

'**********************************************************************

7.13 Function or Reusable script header

Function header consists the following attributes.

'*********************************************************************

'Function or Reusable script:

'Author:

'Date of Design:

'Date of last Revision:

'Purpose:

'Input Parameters:

'Output Parameters:

'*********************************************************************


16/17

7.14 Divide the script into blocks.

Functionality wise divide the script into various blocks and give propercomments. It makes the script more reusable, easy to enhance in future.

7.15 Comment your code to make it more readable

Please use comments

7.16 Verify each page in the flow.

Verify each page by using Reporter object and display the result messagein the Test Result.

8 Scripting Conventions

8.1 Test Scripts

The test script name Must consist of alphabets, numbers and _. Must start with an Upper Case letter. If more than one word is used, the starting of every word must be in

Upper case. Name of a script must be in the format:

Project_Module_Function_SubFunction orProject_Actor_Function_SubFuntion.

Name of a scenario must be in the format:

Project_SCN_Module_Function or Project_SCN_Actor_Function

8.2 Functions

Must consist of alphabets. Must start with Upper Case letter. Name must stand for the functionality of the function. If more than one word is used, the starting of every word should be in

capitals. Numerical are not allowed in the names.

8.3 Reusable Scripts Reusable Script name must consist of alphabets and start with Upper

Case letter. Name should preferably be in the format Project_Module_Function or

Project_Actor_Function.


17/17

8.4 Repository Files

The Repository File name Must consist of alphabets Name must be of the format Project_Module_Function.tsr or

Project_Actor_Function.tsr.

If the name of an object or window in the Object Repository isambiguous, then it must be renamed in the formatObjectType_Label.

9 Best Practices

Indent the code to make it readable and understandable for others. Avoid hard coding system specific values like folder locations, instead

set it relatively with respect to the all scripts. Use synchronization functions instead of wait () function. Use Manual Test Case steps to drive scripting and report all pass and

failure results with the Test Case numbers. Use Standard checkpoints for all static links, buttons and edit fields in

every page. Use parameterization instead of using hard coded data to populate the

AUT.

Documents

Automation Architecture