WINRUNNER AUTOMATION

CHAPTER 2

WINRUNNER AUTOMATION FRAMEWORK SUPPORT - WRAFS

The WinRunner Automation Framework Support (WRAFS), which in conversation called as WinRunner Automation Framework, is a tool-dependent, application-independent framework. This is the only available (at present) Hybrid Test Automation Framework for WinRunner. The main components in the WinRunner Automation Framework are as follows,

Ø WRAFS GUI Map

Ø Test Tables

Ø WRAFS Engine and Driver

The following figure represents the WRAFS architecture

2.1 WRAFS GUI MAP

For the WinRunner tool to interact with the Application Under Test, it first learns the application. It does this through the use of its "GUI Map editor”. WinRunner learns each window or screen in the application, and every object within each window or screen. It does this by identifying classes of objects and their attributes. WinRunner identifies the windows, screens, objects, & fields by their physical descriptions (for example, class, attached text, label, x/y coordinates, height, width, location, etc.), and assigns each window/object a logical name. The logical name generated by the WinRunner GUI Map Editor is based on the attached text of the window or the label in the components. The logical name can be changed by the tester.

These logical names are used in test tables, and hence WinRunner identifies the objects using these names. Usually GUI Map is created by the WinRunner automatically when the Application Under Test is just explored when the WinRunner is in the Record Mode.

The logical and the physical description of the Notepad window are listed in the following table.

Logical and Physical Description of Notepad Window

Logical Name	Physical Description
“Untitled - Notepad”	{ class: window, label: "Untitled - Notepad", MSW_class: Notepad }

It is to be noted that the first step in running the test is to load the GUI Map into WinRunner GUI Map editor. This is accomplished by the DriverCommand Function SetApplicationMap which takes the GUI file name and path as input parameters. All available DriverCommands could be found in the link

http://safsdev.sourceforge.net/sqabasic2000/RRAFSReference.htm

The DriverCommand SetApplicationMap unloads all the GUI Maps from the current GUI Map editor; it also unloads the temporary GUI Map, and then loads the GUI Map Specific to the application. In WinRunner the GUI Map is stored with the extension “.GUI”. The GUI Map for the Run Dialog box & Notepad window is shown in following figure.

2.2 TEST TABLES

The test cases that are to be executed are transformed into test tables. In WinRunner Automation Framework, the test tables are organized as three levels. They are as follows,

Ø Cycle Table

Ø Suite Table

Ø Step Table

These tables are formulated in spread sheets with the knowledge of the application under test, the vocabulary followed in the WinRunner Automation Framework (Record Types, Action Command, Arguments to be passed). The most important thing while designing the tables is to design these test tables (Suite Tables and Step Tables) with the capability of reusability. The design of test Tables is to be done in such a manner that Cycle and Suite table define the complete test case and how to do that, but actual implementation and interaction with GUI happens only in Step Tables. The detailed description of the Test Tables are given in the chapter

2.3 WRAFS DRIVER AND ENGINE

The WinRunner Automation Framework has two important components they are as follows,

Ø WRAFS Driver

Ø WRAFS Engine

In reality there is no clear demarcation between these two modules, because these are not easily separated. So such self-contained, full implementations will likely always be casually referred as “engines”. But here, the three scripts namely CycleDriver.CDD, SuiteDriver.CDD, StepDriver.SDD are together referred as the WRAFS Driver. The remaining scripts are considered as the WRAFS Engine. The other modules in the Engine are listed in the following table.

WRAFS ENGINE
WIN32.SBH CycleDriverSTACK SuiteDriverSTACK StepDriverSTACK LogUtilities StringUtilities DDVariableStore GenericFunctions EditBoxFunctions LabelFunctions ApplicationUtilities PushButtonFunctions RadioButtonFunctions ListBoxFunctions ListViewFunctions ComboEditBoxFunctions MenuUtilities	TableViewFunctions TabControlFunctions PopUpMenuFunctions CustomDriverCommands HTMLImageFunctions HTMLLinkFunctions HTMLTableFunctions GenericMasterFunctions GenericObjectFunctions WindowFunctions DDriverCommands DDUtilities DDGUIUtilities TreeViewFunctions CheckBoxFunctions GraphicControlFunctions FileUtilities

These modules in WRAFS are nothing but the wrapper around the WinRunner TSL functions with some additional logic in it. These wrapper functions are called from the Cycle, Suite and Step Tables to perform the desired operations.

WRAFS CONTROL FLOW

The program execution starts with the StartCycleTest script. This test script is to be started from the WinRunner. There are a lot of information to be passed between the scripts while execution, so there are many global variables which are defined in various files. There are three key variables

Ø CycleDriverState

Ø SuiteDriverState

Ø StepDriverState

They are key value pair sort of arrays, which consists of many keys and their corresponding values assigned it. Theses values are extracted and set throughout the execution as and when needed. Two important paths to be set are the path to the Framework Libraries and the path to the Cycle, Suite and Step tables. These are set in two variables named TDPATH and PROJECTDIR inside the StartCycleTest script.

Then DDEngine Script is called which will load all other libraries of the framework. All the libraries are stored as the Compiled modules. If there is any syntax error present in the libraries then it will be detected here and execution will be interrupted. After loading all the libraries then flow returns to StartCycleTest script, it calls CDCycleDriver function in the CycleDriver script. The CDCycleDriver function takes the five parameters, which are listed in the following table,

Arguments to CycleDriver

Arg #	Argument Name	Description of the Argument
1	Separator	The field Separator usually “\t”
2	CycleDriverState	The global array with the details of the Cycle Table
3	SuiteDriverState	The global array with the details of the current Suite Table
4	StepDriverState	The global array with the details of the current Step Table
5	CycleDrivenMode	CDStandAlonemode à Outputs additional information CycleDrivenMode à Output No additional information

In the CDCycleDriver function, the Cycle Table file is opened, its name is fixed in WinRunner Automation Framework as CycleDriver.CDD. The file is read record by record, as it is read the key value pair array is populated with the available values. The variables specified in the test record are replaced by their actual value. This is done by two functions DDVSubstitueVariables and DDVExtractVariables which are defined in DDVariabeStore library. Then the first field of the record is extracted, this is the record type and based upon this the execution flow changes, which is described under the record type section.

If the record Type(in Cycle Table) is “C”, the DDDriverCommand script is called. Inside that function there is a switch case where all the driver commands are defined. If the requested driver command is found it is executed and correspondingly status codes are set. The execution go back to cycleDriver script for CycleDriver.CDD file and read the next record and this process continues till all the records of CycleTable are processed.

If the record type (in Cycle Table) is “T”, the second field is extracted, which gives the name of the Suite Table. This is appended with .STD extension now it become the complete name of the Suite File. A function defined in SuiteDriver script is called for executing Suite Table. It reads the record from the Suite Table, substitute all the variables with their actual values present in the global Store. Then it extracts the second field of the record similarly as it is done for CycleTable.

If the record Type (in Suite Table) is “C”, the DDDriverCommand script is called. Inside that function there is a switch case where all the driver commands are defined. If the requested driver command is found it is executed and correspondingly status codes are set.

The execution go back to SuiteDriver script for the same Suite Table file and read the next record and this process continues till all the records of that Suite Table are processed. After that the control goes back to the CycleTable and its next record is read. The process continues till all the records in Cycle Tables are processed.

If the record type (in Suite Table) is “T”, the second field is extracted, which gives the name of the Step Table. This is appended with .SDD extension now it become the complete name of the Step File. A function defined in StepDriver script is called for executing Step Table. It reads the record from the Step Table, substitute all the variables with their actual values present in the global Store. Then it extracts the second field of the record similarly as it is done for CycleTable and Suite Table.

If the record Type (in Step Table) is “C”, the DDDriverCommand script is called. Inside that function there is a switch case where all the driver commands are defined. If the requested driver command is found it is executed and correspondingly status codes are set. The execution go back to StepDriver script for the same Step Table file and read the next record and this process continues till all the records of that Step Table are processed. After that the control goes back to the Suite Table and next Record is read. The process continues till all the records in that Suite Tables are processed.After that control goes back to CycleTable and its next record is read. The process continues till all the records in Cycle Tables are processed.

If the record type (in Step Table) is “T”, then the window name, component name and action to be performed are extracted from the record of the Step Table. GetObjectType function is called, based upon these information type of the component is obtained. After that there is a switch case in the StepDriver script, where all the component class functions libraries main function are present. Based on the component type the corresponding main function is called.

For example :-

If the component type is a PushButton then the PushButtonMain () defined in PushButtonFunction Script is called. Inside that main function of PushButton class, a switch case is there which contains all the functions for that class that are implemented. The action field of StepTable is compared with these cases and if found any match, the wrapper function is called.

After the execution of the component functions, the Status Code is set to pass or fail based upon the execution results and then the control is passed to the Step Driver. The execution go back to StepDriver script for the same Step Table file and read the next record and this process continues till all the records of that Step Table are processed. After that the control goes back to the Suite Table and next Record is read. The process continues till all the records in that Suite Tables are processed.After that control goes back to CycleTable and its next record is read. The process continues till all the records in Cycle Tables are processed.

After every function the corresponding result is logged using the LogMessage () function which is defined in LogUtilities library. Finally the results of the execution cycle are logged. We can also see the output on WinRunner Test Result Window.