Upload
barbara-king
View
217
Download
0
Embed Size (px)
Citation preview
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