WinRunner Overview

1
WinRunner Overview

• Dorit Leon
• Software Testing Course
• June, 2002

2
WinRunner Introduction

• Mercury Interactives enterprise functional
  testing tool for Microsoft windows applications

• The goal - to automate the testing process, from
  test development to execution

• Prior to software release, the tester run these
  tests in a single overnight run - enabling to
  detect and ensure superior software quality

3
Automated Functional Regression Testing Saves
Time and Money

• Provides increased testing coverage
• Allows testers to focus on verifying new rather
  than existing functionality
• Creates tests that can be maintained and reused
  throughout the application life cycle
• Eliminates human error

4
Testing Process
1. Test Plan Documenting System Test Plan
Design Test Case Design Test Script
Creation - Manual Automated 2. Test Execution
Management Scenario Creation Test Runs 3.
Analysis of Results Reports Graphs 4. Defect
Tracking System
5
Test Automation is an InvestmentSample
Calculation
It pays to automate. You save time and resources
and get results faster
6
Types Of Tests
There are 3 types of testing 1. Record - Replay
in a context sensitive mode
2. Writing scripts in TSL (Test Script Language)
3. Analog mode - records mouse clicks, keyboard
input, and the exact x- and y-coordinates
traveled by the mouse
7
Context-Sensitive Recording

• Object-based
• Script is
• readable
• maintainable
• Script not affected by user interface changes
• if object moves within GUI, script still replays
  correctly
• Portable script
• context sensitive scripts are portable to other
  platforms with different configurations

8
What Happens During Recording?
Depart Date ___/___/___ From City. .
________________ To City. . . . .
________________ Flight. . . . . . _______
12/12/03
Thomas Paine
BMW
1973
2002tii
234 Willow Drive
Automobile Purchase Form
set_window("Automobile Purchase Form", 10)
edit_set ("Customer Name", "Thomas Paine")
Order Number. . . . __________ Customer. . . . .
. . . ___________________ Billing Date. . . .
. .
edit_set ("Address","234 Willow Drive")
edit_set ("Date", "12/12/03")
list_select_item ("Make", "BMW")
edit_set ("Year", "1973")
edit_set ("Model", "2002tii")
button_press ("Insert Sale")
9
What Happens During Playback?
Purchase Completed...
Depart Date ___/___/___ From City. .
________________ To City. . . . .
________________ Flight. . . . . . _______
12/12/03
Thomas Paine
BMW
1973
2002tii
234 Willow Drive
Automobile Purchase Form
set_window("Automobile Purchase Form", 10)
edit_set ("Customer Name", "Thomas Paine")
Order Number. . . . __________ Customer. . . . .
. . . ___________________ Billing Date. . . .
. .
edit_set ("Address","234 Willow Drive")
edit_set ("Date", "12/12/03")
list_select_item ("Make", "BMW")
edit_set (Year", 1973")
edit_set (Model", 2002tii")
button_press ("Insert Sale")
10
A Closer Look at GUI Objects
11
User Actions in the Test Script
Specify window for input
set_window ("Login", 10)
Type input into an edit field
edit_set ("Username", "thomas")
password_edit_set ("Password", "kzptnzet")
Type encrypted input into password field
button_press ("OK")
Press a button to submit "OK"
set_window ("Automobile Purchase Form", 10)
Specify a list box selection
list_select_item ("Make", "BMW")
12
Automated Checkpoints Improve Accuracy, Increase
Coverage, Reduce Testing Time
13
Programming Procedure

• Programming in Mercury WinRunner (TSL language)
  is similar to programming in any other known
  programming language (C, Pascal, etc.)

• Using WinRunner in a professional way requires a
  common set of standards and conventions, in order
  to enable a legible and clear code for easily
  maintainable programs

14
WinRunner - Testing Process
1. Create GUI map Teaching winrunner the
physical description of every GUI object the
application contains
2. Creating additional tests scripts that test
your applications
functionality Winrunner writes scripts
automatically when you record actions on your
script, or you can program directly in TSL
3. Debugging the tests To check that the tests
operate smoothly and without interruption
15
WinRunner - Testing Process
4. Running the tests on a new version of the
application To verify the applications behavior
5. Examining the test results To pinpoint
defects in the application
6. Reporting defects
16
Test Organization

• A test is composed of several parts
• documentation
• header declarations
• functions
• initialization
• implementation sections

17
Documentation Example

SUMMARY The test checks login
procedure DESCRIPTION The test checks that
login is performed when
correct parameters are used RELATED TEST
234 , cases 1-6 LAST UPDATED Brain Tester
29/02/97 DESIGNER Black Jack
01/01/96 EXPECTED RESULTS See a report
NOTES

18
Header Declarations Example
Public const TestForm ???? ????? Public const
Type ?????
19
Functions Example
Public function check_value (in field,in
expected_value) auto real_value edit_get_inf
o(field,Text,real_value) if(real_value!expect
ed_value) tl_step(check_value ,1,The real
value is real_value The expected is
expected_value)
20
Implementation Example
Set_window(Main_Screen,3) check_value(Name,S
oftware Testing) wait(2) edit_set(Name,Algor
ithms) check_value(Name,Algorithms)
21
WinRunner Workspace
22
Example - Form of an application
23
GUI MAP of that form
24
Physical Description of an Object
25
Analog Recording
mouse track move_locator_track(1) left
mouse button press mtype(ltT110gtltkLeftgt-)
mouse track move_locator_track(2) left mouse
button release mtype(ltkLeftgt)
26
WinRunner - Time Consuming
1. Teaching TSL - easier when the tester has a
software background
2. Writing the scripts - may require more time
than writing non-automated test
3. Executing Time - irrelevant when running in a
single overnight run
4. Updating Time - depends on the scripts, may
require more time than updating non-automated
test
27
Things are not as perfect as they seem...
1. The recorded input can be incorrect either due
to tester error during the recording session, or
the test script can be incorrect in the first
place. A reliance on recording alone would then
require the entire input to be re-recorded
2. The resulting script contains multiple
commands and statements for every action taken,
is extremely lengthy and difficult to interpret
and maintain
28
Things are not as perfect as they seem...
3. Recording of test scripts requires that the
application be fully developed, and error-free
4. If errors occur, such as unexpected screens,
the recorded test script will fail, and therefore
requires someone to constantly monitor the test
run in order to keep it going