Winrunner Usage - Best Practices S.A.Christopher

Winrunner Usage- Best Practices

S.A.Christopher

Origin of the Document

VRZIVS team, a part of IVS is using

a framework that makes the

Automation Testing for Web

applications easier using Winrunner.

This presentation briefly explains the

usage, Pros & cons of the architecture

Contents

Need and Criteria for Automation

Brief Introduction of the Architecture

Software Requirements

Components of the Architecture and their responsibility

Table Structure Details

Comparison of the architecture with the General Scripting adopted

Pros & Cons of the Architecture

Test Automation gives improvement in test cycles. Automation is the

only long- term solution for reduced costs in software testing and better

quality Products. But these aims are achieved only when certain best

practices are followed before and while developing the automation

suite

Howard Fear has aptly stated, "Take care with test automation. When

done well, it can bring many benefits. When not, it can be a very

expensive exercise, resulting in frustration”.

Need For Automation

Which Test Cases to Automate?

Tests that need to be run for every build of the application

(sanity check, regression test)

Tests that use multiple data values for the same actions

(data–driven tests)

Tests that require detailed information from application internals (e.g., SQL, GUI attributes)

Stress/load testing

More repetitive

execution?

Better candidate for automation

Which Test Cases Should Not be Automated?

One-time testing

Usability testing

“How easy is the application to use?”

“ASAP” testing

“We need to test NOW!”

Ad hoc/random testing

based on intuition and knowledge of

application

Tests without predictable results

Improvisation required?

Poor candidate for automation

Brief Introduction about the methodology adopted

This is purely a Data Driven Type of testing.

All the test data required to perform the automation testing are

entered in the Microsoft access tables.

The Winrunner scripts establishes a database connection, retrieve the

test data and perform the automation run.

The only modification to be done is the changes in the GUI Map

File (due to any change in the GUI) and the corresponding

entries in the tables.

Software Requirements

Automation Tool Used :

WinRunner 7.5 ( No Add-ins required)

Data Base Used:

Microsoft Access

Automation Architecture

Winrunner Configuration

Files

Winrunner Driver Scripts

Microsoft Access

Database

Application UnderTestInitialize and Run

Establish DB connectionand Query

Return the result for the Query

Run Test

Components of the Architecture

Configuration Files ( .ini files and Winrunner scripts)

Microsoft Access Tables

WinRunner Driver Scripts

Application under Test ( Web application )

1. Configuration Files

This is the starting point of the whole automation process. The

different tasks these Configuration files perform include:

Initialization of Variables.

Creation of reusable User Defined functions.

Loading the User Defined functions to Win Runner’s Function Generator.

Passing the control to the Driver Scripts after the initiation process.

……..Configuration Files

The Winrunner scripts used for initializing should be called from

the :\ProgramFiles\MercuryInteractive\WinRunner\dat\tslinit”

file. As this is the first file called whenever the Winrunner tool

is invoked, calling the configuration/initialization scripts in this

file will initialize the parameters whenever the tool is started.

The “wrun.ini” file should be placed under “C:\Windows”. This

should contain the environment which should be considered,

the DSN name and the location of the Driver scripts.

2. Microsoft Access Tables

The three tables used in the architecture are :

APPLOGIN

WIN_SEQ

SCRIPTDATA

a. APPLOGIN – Table Structure

APPLOGIN – Contents

The computer name in which the script should run.

The Script name

The sequence in which each scripts should be executed.

Flag to turn ON/OFF any of the scripts.

b. WIN_SEQ – Table Structure

WIN_SEQ - Contents

The Script Name

Window names that each Script should invoke.

The sequence in which the windows would be accessed.

Flag to turn ON/OFF any of the sequence.

c. SCRIPTDATA - Table

SCRIPTDATA - Contents

The Script Name and the Window name

The GUI Window name and the GUI Object name that is in the GUI Map file.

The Test Data to be supplied (if any)

The Actions to be performed over each Html Object.

The sequence in which each operation should be performed.

Flag to turn ON/OFF the steps.

Note : This table is the backbone of the whole architecture. All the parameters

required for the execution of Winrunner scripts should be passed from

this table.

C. Winrunner Driver Script

These is the script that drivers the whole architecture.

Following are the list of tasks these scripts perform.

Establishing Database Connection.

Executes the Database queries and retrieves the records from the tables.

Performs required operations on the objects of the application

depending upon the records fetched from the database.

Checks for the desired outputs in each step.

Generates the Final Report based upon the results.

Sub sections of the Driver script

genericAction

- To perform link clicks, List Select and others….

setData

- For passing any value as the input….

getData

- To retrieve the state of any Html Object…..

verifyData

- To verify the Expected (vs.) Actual Results…..

……Driver Scripts

These sub-sections will in turn call the Winrunner functions.

Appropriate arguments are passed to the relevant Winrunner

functions from the database tables.

A snapshot of the Driver Script

Switch ( Arg1 )

case "genericAction":

                              Switch (Type)                             {                            case "Link Click": rc = web_link_click(Data); if (rc != 0)

msg = “Data Execution Success..”

else

msg = “Data could not be executed”

In a Nut Shell ( About Driver Scripts)

Get the Machine and Script Names

Retrieve the Window names in Sequence

Get all GUI Objects in the Window under Consideration

Retrieve the Test Data and the Action to be performed on the GUI Objects (in sequence)

Perform the action, check the Actual Result with the Expected and generate Report

Comparison of the architecture with General Scripting

Usage of Architecture Usage of General Scripting

Less number of scripts used More number of scripts used

Reusability of code is maximum Reusability of Code is minimum

Frequency of Modification of script is minimum

Frequency of modification of script is high

Same set of scripts can be used for testing any web application.

Too many changes required to use the same set scripts to test other applications.

Debugging during test run is easy Debugging is complex.

Selective scripts can be run in different

Machines.

This scenario is difficult to achieve.

Advantages

Minimum amount of scripting is required.

Changes need not be made to the scripts in the intermediate

process

Scripts can be run across different machines.

Debugging a single scenario is simple as the rows associated with

the other scenario’s can be turned OFF.

Modifications needs to be made only for selected columns in the

table whenever there is a change in the GUI of the application.

Separate GUI Map Files can be used for each module.

Disadvantages

The Bulk size of the table.

Much involvement of Microsoft access tables.

Creation of Dynamic Inputs is difficult.

Run-time change in the GUI Map file is not possible.

Thank You