automated test suite architecture guide

8/2/2019 Automated Test Suite Architecture Guide

1/14

Last Revised: 1/16/08 Automated Test Suite Setup and Execution Guide.doc Page 1 of 14

Proprietary and Confidential OfficeMax

Business Framework

Automated Test Suite

Architecture Guide

Effective Date:

Authorized By :

Responsible Parties

Process Owner Title/Role/Functional Organization

Contributors Title/Role/Functional Organization

Stakeholder

Name Title/Role/Functional Organization


2/14

Business Framework Automated Test Suite Architecture Guide.doc

Last Revised: 11/01/08 Automated Test Suite Architecture Guide.doc Page 2 of 14


Contents

Purpose......................................................................................................................................................... 3Definitions .....................................................................................................................................................3Automated Testing Framework Overview.....................................................................................................4Test Suite Directory Structure.......................................................................................................................6QTP Configurations....................................................................................................................................... 7Automated Test Suite Standards .................................................................................................................. 9

Coding Style Best Practices ................................................................................................................... 9Documentation & Standards ...................................................................................................................11

Revision History ..........................................................................................................................................14


3/14




Purpose

This guide provides instructions for installing, preparing for and executing the automated regression testfor Policy Center.

Definitions

Term Definition

Automated Test Framework (ATF) All test automation entities required to execute automatedtest cases including all QTP entities (scripts, functions,

object repository, etc.) and associated data input files.

AUT Application Under Test the application being testedduring an execution of the automated test suite.

Initial State The AUT state that each test case expects to find thewhen it begins to execute.

End State The state that each automated test case will leave theAUT in when execution is complete.

Test Entity Any QTP script, action or function that executes testcases / business processes.

Automated Test Case (Test Case) A single set of instructions (steps and data) that executeactions and verifications necessary for performing a

single test case.Automated Test Scenario (Test Scenario) A set of Automated Test Cases grouped together for a

single Test Run.

Test Run A single execution of the automated test suite.

Test Set A series of test scenarios run sequentially as part of atest cycle.

Unexpected Event Any event encountered by a Test Entity that, if notdetected and addressed, would cause execution to bestopped.

Business Process Function (BPF) A QTP test entity that executes a specific businessprocess (or part of a business process) of the applicationunder test.

Verification Function (VF) A QTP test entity that executes a specific verificationaction on the AUT required by test cases.

Keyword Function (KF) A QTP test entity that executes a specific low-level action typically a single user action on a user interface object.


4/14


Automated Testing Framework Overview

The automated testing framework (ATF) provides a foundation for efficiently implementing an effectivetest automation solution. The framework, shown in Figure 1, consists of an automated test engine (builton HPs QuickTest Professional solution) and driven by external data files. The external data files containinstructions that govern the execution of test cases and scenarios. Each component of the ATF isdescribed below.



Figure 1. Automated Testing Framework

ATF Component Description

Driver A QTP script that reads Driver Data Files to determine the set of AutomatedTest Case Files included in the test scenario to be executed.

Test Case Interpreter A QTP action that reads the instructions contained the Automated Test Case

Files and calls the appropriate Business Process, Keyword or Verificationfunctions.

QuickTest Professional EnvironmentFile

(QTP)

Automated

Test Case

Files

Test

Results

Driver

Data

DriverFiles

Test Case Interpreter

Utility Functions

Business Process / Key Word/ Verification

Functions

Application Specific | General Web

Object Repository


5/14




ATF Component Description

Business Process,Keyword and VerificationFunctions

Business Process Function: A QTP function that performs a series of stepsspecific to an applications business process (e.g. Login).

Keyword Function: A QTP function that performs a generic step for aparticular application type (e.g. click_link).

Verification Function: A QTP function that performs validation (e.g. comparevalues).

Functions are divided into three groups:

1. Application Specific - functions that perform business processes,keyword actions and verifications that are specific to the AUT. Theygenerally are not reusable across automated test suites

2. General Web functions that perform keyword actions andverifications that are general to most browser-based applications.

3. General Terminal Emulator (TE) functions that perform keywordactions and verifications that are general to most TE-based (i.e. greenscreen) applications.

Utility Functions QTP functions that perform general framework operations such as errorhandling, results reporting, data handling, etc.

Object Repository A QTP entity that maps GUI object local names to their physical descriptionsto enable object identification during execution.

Driver Data Files Files that contain the set of Automated Test Case Files that are executed aspart of a test scenario. In addition to the path and name of the AutomatedTest Case Files the Driver Data Files contain the Environment File that isassociated with each Automated Test Case File.

Automated Test CaseFiles

A worksheet within an Excel workbook containing the instructions forexecuting an automated test case.

Environment File An XML file containing the environment settings required by a specificAutomated Test Case File.


6/14


Test Suite Directory Structure

The figure below depicts the file structure that houses all of the necessary components of the test suite:

Figure 2. Automated Test Suite Directory Structure

Directory Description

AutoResults This directory contains all execution results.

Data The data directory contains all necessary data files for the Driverand PolicyCenterAction scripts to execute the business processtests.

Documents This folder contains the documentation files for the ATF.

Environment This folder contains the xml files for each environment that will betested. The XML files contain all static environment variablesrequired by the ATF.

Lib This folder contains the library files that house the reusablefunctions and subroutines.

Obj Repository The Obj Repository directory houses the shared objectrepositories used by all automated tests. Currently, thearchitecture contains two (2) repository files, SP2.tsr andTERep.tsr. SP2.tst contains object definitions for accessing thePolicy Center application, and TERep.tsr contains the objectdefinitions for accessing the terminal emulator for the WC Pledge

application.

RecoveryScenarios This directory contains error handlers to supplement the Driverand PolicyCenterAction scripts in an event of an unexpectedoccurrence during a test run (e.g. a pop-up dialog box or a Pagenot found error). Currently, there are no recovery scenarios thathave been defined for this implementation.

ScreenMap The ScreenMap folder contains the database that stores themapping locations of the terminal emulator (TE) screen fields.




7/14




Directory Description

Scripts The Scripts folder contains the QTP scripts necessary for theautomation: Driver and PolicyCenterAction.

QTP Configurations

The following table describes the required QTP configurations:

Area Description

Folders QTP can set the root directory path for the test suite. This setting

must be set in the Driver file under Tools>Options>Folders. An

example of the path that would be set is C:\Work\SP2. The

directory structure listed inside of this directory would be the folder

structure pictured in Section 2.

Calls to External Actions When the test suite is moved to another computer or another

directory, it is necessary to confirm that the binding to external

actions that occurs within the Driver script still exists. To do this,

open the Driver script in QTP. The following datatables should

exist as tabs across the bottom: Global, Driver, and

PolicyCenterAction [PolicyCenterAction].

If either of the last two tables does not exist, go to the very top line

in the script. From the toolbar select Insert>Call to Existing

Action. In the From test drop-down, select eitherPolicyCenterAction from the directory where it resides. If it is not

found in the drop-down, browse for the script. Change the path to

a relative directory (e.g. ..\..\Scripts\PolicyCenter\Action1). Press

the OK button and when you return to the script there should be a

new line of code that starts with the statement RunAction.

IMPORTANT: Delete this line of code and save the Driver

script.


8/14




Area Description

Resources Shared Object Repositories

The path to the shared object repository must be correct in

both QTP scripts (Driver and PolicyCenterAction). First open

PolicyCenterAction to verify that the shared object repository

is found. If it cannot be found a message should pop-up upon

opening the test and you can browse to the new location of the

repository. Then open the Driver script to do the same.

There is another place to specify where the shared object

repository is located as well. In Resources>Associate

Repositories there is a section called Repositories. The

directory to the repository should be specified as ..\..\Obj

Repository\SP2.tsr and ..\..\Obj\Repository\TERep.tsr.

Function Libraries

In Test>Settings>Resources there is a section calledAssociated library files. There should be three entries in thislocation for the libraries. This includes:

..\..\Lib\Web_lib.txt ..\..\Lib\PolicyCenter_lib.txt ..\..\TE_lib.txt

Handling GuidewireApplications

The PolicyCenter application is built using a third party packagefrom Guidewire. Since Guidware code is automatically generated,some of the objects can be difficult to identify. One particularchallenge is working with tables, which are used extensively in thePolicyCenter application. There are a set of AFT functionsspecifically developed to work with tables. Column name is used

as the primary means to identify tables. The column name ispassed as a parameter and the functions search for that label tolocate the table. If more than one table with the same label ispresent, an instance parameter is required to determine whichinstance of the object to use. Please refer to the Quick ReferenceGuide for detailed explanations of the table functions.

Most of the Guideware objects have an additional attribute calledSmokeId. In some instances, the SmokeId can be used to identifythe object. The SelectTopNav function takes advantage of theSmokeId to select the correct top navigation button.


9/14




Automated Test Suite Standards

Coding Style Best Practices

When developing QTP scripts it is important to follow the naming conventions. This will allow codereviews and maintenance more efficient and effective.

We shall follow CamelCase and a modified form of the Hungarian Notation.

CamelCase, camel case is the practice of writing compound words or phrases where the words arejoined without spaces, and each word is capitalized within the compound (e.g. SelectPolicy, StartState,etc.).

Use the following standard prefixes to denote data type.o Object obj objRecordseto String str strFirstNameo Integer int intLoopCountero Array arr arrRowHeadero Date dte dteBrithdayo Boolean bln blnLoggedIno Global (public) g_ g_SavePath

Assign meaningful names that will be easy to remember as you code.


10/14




Coding Style Best Practices

Code Area Description

Coding Layout Use a single statement per lineAll statements should be clearly arranged on a separate line.

Concatenation of multiple statements per line using the ":" separatormust be avoided.

Use line continuation characters to break long linesTo aid readability, an individual source line must not exceed 85characters in width without the use of the line continuation character("_").

Statements must use indentationIndentation is another technique that improves readability of code.Indentation is especially helpful in areas such as if statements andfor/do loops.

Single line "If...Then" statement must not be used

In the interest of making source code more readable, single lineIf...Then statements are to be avoided (i.e. the 'End If' keyword must beused for all 'If' statements).

Location of variable declarationsTo aid code readability, all local variables must be declared at the headof a procedure.

Location of constant declarationsAll constant declarations must appear before variable declarationswithin the declarations section of a source file.

Location of "public" and " constant declarationsAll Public constant declarations must appear before private constant

declarations within the declarations section of a source file.

CodingComplexity

Nested If...Then statementsTo ensure that procedures are easy to understand, test and maintain,'If...Then' statements must not be nested beyond four (4) levels deep.

Excessive variable declarationTo keep procedures simple to read and understand, try to avoiddeclaring excessive numbers of local variables within a procedure.

Nested select statementsTo reduce code complexity and improve code readability avoid nestingSelect...Case statements within other Case statement blocks. If theCase statement needs to perform conditional or complex logic, consider

rewriting the code as another separate function.


11/14




Code Area Description

Comments Constant declarations must include a comment headerAll public and module-level constant declarations must include astandard comment header describing what the constant value

represents and how it is to be used.

Comments within procedure code blocksCode statements within procedures should be interspersed withcomments to describe the logical operations being performed by thestatement blocks. Comments should not merely echo the physical code.

Procedure comment headerAll procedures must include a standard comment header describingwhat the procedure does as well as details of any arguments used andreturn values.

Format of procedure header commentsProcedure header comments must take the following form: opening

comment separator line, procedure name, created by, date created, oneor more lines describing the procedure followed by individual argumentnames and descriptions, one or more lines of describing return values(including any errors raised by the procedure) and ending with a closingcomment separator line.

Use reminder commentsWhenever an issue within source code is identified which cannotimmediately be resolved, a reminder comment may be inserted into thesource to ensure the issue is not forgotten. Comments beginning'TODO: will be treated as reminder comments and should describe theissue appropriately including the name of the developer responsible forthe comment and the date the issue was identified.

User-defined type definitions must include a comment header

All user-defined type definitions must include a standard commentheader describing what the type represents and how it is to be used.

Variable declarations commentsAll public and module-level variable declarations must include a standardcomment header describing what the variable represents and how it is tobe used.

Documentation & Standards

The following tables describe coding documentation and standards:

Naming Conventions

Area Description

Application ObjectNames

Object names should capitalize the first letter and follow the CamelCaseconvention. (e.g. objBrowser)


12/14




Area Description

Variable When naming a variable, capitalize the first letter and follow theCamelCase convention. (e.g. strFirstName)

Constants All letter of a constants shall all be CAPITALIZED.

Functions When naming a function, capitalize the first letter and follow theCamelCase convention. All functions shall have proper function headers.

Documentation & Standards

Area Description

Test Case Input Use Excel Files as the data source for all use cases. The templatewill be the same across all Streams.

Test Case Output Use Excel Files as the data source for reporting results forindividual test cases. QTP results should also be stored andsaved.

Error Handling Each test script must handle any exceptions that can occur duringthe test run.

Documentation PolicyCenter Actions

The PolicyCenter test script header shall contain:

Name Type Main Reusable Action Description

Author Create Date

Sample********************************************************************

Name:

Type:

Description:

Author:

Create Date:

********************************************************************


13/14




Area Description

Documentation - Functions The functions shall be written using VBScript. The function headershould contain:

Name Parameters Specify the parameters used by the reusable

action. Indicate any optional parameterso IN Describe any input parameterso OUT Describe any output parameterso RETURN Describe any return parameter

Description Created By Create Date

Sample

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

'Name : WriteExcelReport(ScriptName,TestResults, Remarks)

'Parameters: IN Script Name - This is the name of the Script that is calling this function IN TestResults - This takes "Fail" as the results parameter for only the failed Transactions.' IN Remarks - This takes the Remarks Field of the Failed Transactions as to why the Transaction failed.Returns: N/ADesc: Writes the Failed Transactions Test Results into an Excel Report.

'Created by: Utopia Solutions'Created on: 11/15/2007

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


14/14




Revision History

Content Revision History - PAL ID:

This log stays with the completed document to track published revisions to the content.

Version Date Revision Description Revision Author