Successfully reported this slideshow.
Your SlideShare is downloading. ×

Mercurry WinRunner for Beginners - Kamran Khan []

Upcoming SlideShare
Load runner & win runner
Load runner & win runner
Loading in …3

Check these out next

1 of 60 Ad

More Related Content

Slideshows for you (20)

Viewers also liked (20)


Similar to Mercurry WinRunner for Beginners - Kamran Khan [] (20)

Recently uploaded (20)


Mercurry WinRunner for Beginners - Kamran Khan []

  1. 1. Mercury WinRunner 9.2 (Final Release) Presented by: Kamran Shaukat Ali Khan Last Updated: 20090224
  2. 2. Download latest version of this File !  This file was downloaded from:  Download latest version of the slides from above URL.  Feel free to distribute the file and share knowledge  The file is available as Read-Only and does not require password to open.  View in Presentation Mode – the slides animation is designed purposely to nurture audience understanding  Direct your feedback to above URL or to author at 2
  3. 3. Audience  Beginners who have just entered the realms of software testing  Methodology: For every topic we’ll have:  Overview  Exercises  Questions & Answers. Mercury WinRunner - Kamran Khan – 3
  4. 4. The Road Ahead !  Introduction to Automated Testing  Merits/Demerits of Automated Testing  Limitations of A.T  5 Ws of Automated Testing (What, Why, When, Where, Who)  Why automate at all? What scope to automate?  Other automated testing tools…  What is WR?  How does WR do it?  GUI map  What is it? Why do we need it?  Checking GUI Objects  What’s the spy?  GUI map file mode  How do I create GUI Maps using WR? 4Mercury WinRunner - Kamran Khan –
  5. 5. The Road Ahead !  WinRunner Testing Process  WinRunner Recording/Playing Modes  Rapid Test Scripting  How do we write script?  TSL  Recording modes  Why do I need parameterization?  How do i perform parameterization?  Checkpoints  What are they?  Various checkpoints  How do i add them?  GUI and DB Checklist (and DB Objects)  Synchronization Points & capturing screen values  Maintaining tests  TD connection  Batch mode  Practical ! 5Mercury WinRunner - Kamran Khan –
  6. 6. Introduction to Automated Testing  Software systems are critical to the survival of today's businesses. Inadequate performance and poor quality of these systems can jeopardize the very existence of an organization. Testing on all environments and complex integrated infrastructure under increasing numbers of business users is now integral constituent of testing and software development thereof.  Manual testing is time-consuming and tedious, requiring a heavy investment in human resources. Worst of all, time constraints often make it impossible to manually test every feature thoroughly before the software is released. This leaves you with doubts of serious bugs – latent.  Automated testing answers these problems. It dramatically speeds up the testing process. You can create test scripts that check all aspects of your application, and then run these tests on each new build. 6Mercury WinRunner - Kamran Khan –
  7. 7. Merits of Automated Testing  Fast: Automated Testing Tool runs tests significantly faster than human users.  Reliable: Tests perform precisely the same operations each time they are run, thereby eliminating human error.  Repeatable: You can test how the software reacts under repeated execution of the same operations.  Programmable: You can program sophisticated tests that bring out hidden information from the application.  Reusability: You can reuse the Automated Test scripts, user defined functions etc. 7Mercury WinRunner - Kamran Khan –
  8. 8. Demerits of Automated Testing  Usability Testing: Automated tools cannot rate the usability of an application.  Cost: Automated tools are quite expensive  Programming knowledge required: To customize test scripts according to test requirement.  Test maintenance is costly: Even though a minor change occurs in the GUI, the test script has to be rerecorded or replaced by a new test script. 8Mercury WinRunner - Kamran Khan –
  9. 9. Automated Testing Limitations  Automated testing can only identify regression testing problem.  For large scale test automation, ample number of tool licenses and human resources are required (time/resources constraint)  Automated testing can help manual testing but can’t replace it. Why?  Heuristics – intelligence  Business domain 9Mercury WinRunner - Kamran Khan –
  10. 10. Which Test Cases to automate?  Test cases need to be run for every build of the application  Sanity Testing)  Tests that use multiple data values for the same actions  Data Driven Testing  Critical Application functionality  req. precision & accuracy  Business functionality which won’t be changed in short time period  under maintenance 10Mercury WinRunner - Kamran Khan –
  11. 11. Which Test Cases not to automate?  One Time testing  Non Repeatable  Ad-hoc Testing  ASAP testing  Usability Testing  Heuristics  Load testing  Performance & Stress testing  Covered in Automated Performance Testing tools 11Mercury WinRunner - Kamran Khan –
  12. 12. A.T approach at NetSol  Modular  Automated test scripts are developed module wise or business process wise on AUT  Scenario based:  Manual testing team provide test cases that are used as an input for automated test scripts  Once test scripts are developed, manual testing team performs the peer review of automated test scripts  Manual testing team executes the automated test scripts on new build of the application 12Mercury WinRunner - Kamran Khan –
  13. 13.  Automation cannot be done just for the sake of automation. Not everything can be automated – similarly, not everything should be automated.  Proper analysis is required before affirming automation for a module  critical areas  under maintenance areas  cost / benefit analysis  Change requests by client & specific scenarios should not be automated – rather complete functionality should be automated  Test cases serve as input to automated scripts – these must be developed before automation commencement.  Performance of automated testing should be reviewed on periodic and event driven bases to identify particular benefits it is giving. 13Mercury WinRunner - Kamran Khan –
  14. 14. Automated Testing Tools  Regression Testing:  Mercury WinRunner  HP Quick Test Professional  XRunner for Linux  Load Testing:  HP LoadRunner  IBM Rational performance tester  JMeter  Webload  Silk performer  Bugs Repository:  Test Director / Quality Center  BugNet, BugZilla, BugTracker (Open Source) 14Mercury WinRunner - Kamran Khan –
  15. 15. Commonly used terms  WR – Win runner  AUT – Application under test  GUI – Graphical User Interface  TSL – Test Script Language  RTS – Rapid Test Scripts  FRT – Functional Regression Testing  MCS – Menu-items Checklist Script  TD/QC – Test Director / Quality Center 15Mercury WinRunner - Kamran Khan –
  16. 16.  RTS  Walkthroughs whole application  Learns every object on every window  Used to check application crash / exception  Can be executed on different releases  FTS  Depends on business process  Depends on test cases to be automated  Verifies business logic / db / data  Reduces manual test case execution time  MCS  Walkthroughs all of the menu items  Used to check differences in menu items between different releases  Is cross executed on two releases  BTS  Multiple test scripts execution in just one click  Used for RTS and FTS execution  No monitoring required  Combined results 16Mercury WinRunner - Kamran Khan –
  17. 17. Work done by SQA-AT  RTS  CMS  TLT  SNG  NissanAu  MAU  FIAT  DCLT  DCFST  CNH  AMF  Alamthal  WFS  YMFA – 2 companies  TMFCN  TLT – 2 companies  NissanAu  MBFJ – 2 companies  FIATChina  DCST  DCSK  DCLT  DCAFC  BMWChina  MCS  CMS  NissanAu  DCLT  CNH  WFS  NissanAu 17Mercury WinRunner - Kamran Khan –
  18. 18. Work done by SQA-AT  CMS  SNG  Balloon  BPIS  CTA  CTC  CTM  Business Partner  NissanAu  ARM Receipts  DD  CTA  ETM  Fiat  AMS  FPP  BPIS  CTA  ETM  CNH  FPP  CTA  DCLT  CTA  WFS  YMFA  Payment Advice  Final Settlement  Receipt Voucher  MBFJ1 (MBFJ)  DAS Settlement Acknowledgement  Distributor Interface  Loan Approval  Payment Advice  Receipt Voucher  MBFJ2 (PJ)  DAS Settlement Acknowledgement  Distributor Interface  Loan Approval  Payment Advice  Receipt Voucher  DCLT  Final Settlement  FTS 18Mercury WinRunner - Kamran Khan –
  19. 19. What is WR?  WinRunner is automation tool, specifically a regression test tool.  Used to automate the execution of test cases through scripts in TSL  WinRunner is an integrated, functional testing tool for the entire enterprise; by capturing, verifying and replaying user interactions automatically.  WinRunner dramatically speeds up the testing process. You can create test scripts that check all aspects of your application, and then run these tests on each new build.  As WinRunner runs tests, it simulates a human user by moving the mouse cursor over the application, clicking Graphical User Interface (GUI) objects, and entering keyboard input—but WinRunner does this faster than any human user.  Capable of testing navigation (RTS), Business Logic & Database verification (FRT), MCS, Batch (BTS), Integration with LR and TD 19Mercury WinRunner - Kamran Khan –
  20. 20. Why automate at all?  Few reasons  Running test manually is boring!  Running test manually again and again is frustrating!  Running test manually is prone to making mistakes.  Write once, run as many times as needed!  I have more time now (Time saving!) 20Mercury WinRunner - Kamran Khan –
  21. 21. How does WR do it ?  Record objects (GUI Map)  Create scripts/tests  Debug scripts/tests  Run the scripts/tests  Displays/Analyze results Attention: Please Remind me to show the WR tool as the presentation proceeds 21Mercury WinRunner - Kamran Khan –
  22. 22. GUI Map – what is it?  What is it?  AUT is made of UI controls as lists, button controls, edit controls etc.  GUI Map Files contains the Physical Description of GUI objects  GUI Map files are managed ,edited and modifies in GUI Map Editor  GUI Map is a flat file that stores object description and serves as an interpreter between WinRunner and AUT  Why do we need it?  WR needs a mechanism to identify the screen objects of AUT.  WR identify screen objects using GUI Map.  WR records objects using physical description; uses only those that uniquely identifies the object (an not others as height etc –Why?) 22Mercury WinRunner - Kamran Khan –
  23. 23. GUI Map – Spy  What’s the spy?  Spy is a utility to confirm that WR is recording the objects right.  A tool used to look for the object description.  Using the GUI Spy, you can view the properties of any GUI object on your desktop. You use the Spy pointer to point to an object, and the GUI Spy displays the properties and their values in the GUI Spy dialog box.  How do I use SPY? Launch it from the WR.  Choose Tools > GUI Spy to open the GUI Spy dialog box. 23Mercury WinRunner - Kamran Khan –
  24. 24. GUI Map – Insight  GUI map file mode  WR has two modes to record the GUI Map file  Global GUI Map file  GUI Map file per test  Global GUI Map file  This mode enables you to create a GUI map file for your entire application, or for each window in your application. Multiple tests can reference a common GUI map file  Recommended for advanced users. (There are other reasons too) 24Mercury WinRunner - Kamran Khan –
  25. 25. How WinRunner Creates GUI Map 25 Mercury WinRunner - Kamran Khan –
  26. 26. GUI Map – usage  GUI Map file per test  This mode enables WR to automatically create a GUI map file for each test you create. You do not need to worry about creating, saving, and loading GUI map files  Recommended for beginners. (There are other reasons too)  How do I create GUI Maps using WR?  By using Rapid Test Script Wizard  By recording the script directly, this records the objects as they are encountered in AUT  GUI Map Editor – Learn button  Object Definition  Add/ Delete/ Modify objects 26Mercury WinRunner - Kamran Khan –
  27. 27. WinRunner Testing Process  Testing with WinRunner involves six main stages: 27Mercury WinRunner - Kamran Khan –
  28. 28. WinRunner Testing Process  Create the GUI Map The first stage is to create the GUI map so WinRunner can recognize the GUI objects in your application being tested. Use the Rapid Test Script wizard to review the user interface of your application and systematically add descriptions of every GUI object to the GUI map. Alternatively, you can add descriptions of individual objects to the GUI map by clicking objects while recording a test.  Create Tests Next, you create test scripts by recording, programming, or a combination of both. While recording tests, insert checkpoints where you want to check the response of the application being tested. You can insert checkpoints that check GUI objects, bitmaps, and databases. During this process, WinRunner captures data and saves it as expected results—the expected response of the application being tested.  Debug Tests You run tests in Debug mode to make sure they run smoothly. You can set breakpoints, monitor `variables, and control how tests are run to identify and isolate defects. Test results are saved in the debug folder, which you can discard once you finished debugging the test. 28Mercury WinRunner - Kamran Khan –
  29. 29.  Run Tests You run tests in Verify mode to test your application. Each time WinRunner encounters a checkpoint in the test script, it compares the current data of the application being tested to the expected data captured earlier. If any mismatches are found, WinRunner captures them as actual results.  View Results You determine the success or failure of the tests. Following each test run, WinRunner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at checkpoints during the test run, you can view the expected results and the actual results from the Test Results window. In cases of bitmap mismatches, you can also view a bitmap that displays only the difference between the expected and actual results.  Report Defects If a test run fails due to a defect in the application being tested, you can report information about the defect directly from the Test Results window. This information is sent via e-mail to the quality assurance manager, who tracks the defect until it is fixed. 29Mercury WinRunner - Kamran Khan –
  30. 30. Getting Started  To start WinRunner: Click Start > Programs > WinRunner > WinRunner. After several seconds, the WinRunner window opens. Note that the WinRunner Record/Run Engine icon appears in the status area of the Windows taskbar. This engine establishes and maintains the connection between WinRunner and the application being tested. 30Mercury WinRunner - Kamran Khan –
  31. 31.  You create and run WinRunner tests in the test window. It contains the following key elements:  Test window title bar, with the name of the open test  Test script, with statements generated by recording and/or programming in TSL, Mercury Interactive’s Test Script Language  Execution arrow, which indicates the line of the test script being executed (to move the marker to any line in the script, click the mouse in the left window margin next to the line)  Insertion point, which indicates where you can insert or edit text 31Mercury WinRunner - Kamran Khan –
  32. 32. The buttons appear by default on the User toolbar: 32Mercury WinRunner - Kamran Khan –
  33. 33. WinRunner Recording Modes  The recording process enables anyone to create and automate tests, so that even users with limited technical background can produce tests.  WinRunner includes two modes for Recording tests:  Context Sensitive Mode  Analog Mode 33Mercury WinRunner - Kamran Khan –
  34. 34.  CONTEXT SENSITIVE MODE Context Sensitive mode records your actions on the application being tested in terms of the GUI objects you select (such as windows, lists, and buttons), while ignoring the physical location of the object on the screen. Every time you perform an operation on the application being tested, a TSL statement describing the object selected and the action performed is generated in the test script. 34Mercury WinRunner - Kamran Khan –
  35. 35.  ANALOG MODE Analog mode records mouse clicks, keyboard input, and the exact x- and y- coordinates traveled by the mouse. When the test is run, WinRunner retraces the mouse tracks. Use Analog mode when exact mouse coordinates are important to your test, such as when testing a drawing application. 35Mercury WinRunner - Kamran Khan –
  36. 36. If you are testing an application that contains both GUI objects and bitmap areas, you can switch between modes as you record. 36Mercury WinRunner - Kamran Khan –
  37. 37. Rapid Test Scripting – Wizard  The RapidTest Script wizard performs two important tasks:  It systematically opens the windows in your application and learns the description of every GUI object. The wizard stores this information in a GUI map file.  It automatically generates tests based on the information it learned as it navigated through the application.  RTS Types:  GUI Regression Test  Bitmap Regression Test  User Interface Test  Test Template 37Mercury WinRunner - Kamran Khan –
  38. 38. User Interface Test  The User Interface test determines whether the application complies with the Microsoft user interface standards. It checks that:  GUI objects do not overlap  GUI objects are aligned in windows  Text labels on GUI objects begin with capital letters  Text labels on GUI objects are clearly visible  OK and Cancel buttons appear in every window  A system menu is available in every window 38Mercury WinRunner - Kamran Khan –
  39. 39. Starting RTS Wizard: To start the RapidTest Script wizard, either: • Click RapidTest Script Wizard in the WinRunner Welcome screen when you start WinRunner • Choose Insert > RapidTest Script Wizard at any time. • Click Next in the wizard’s Welcome screen to advance to the next screen • Point to the application you want to test. • Click the button and then click anywhere in the application. The application’s window name appears in the wizard’s Window Name box. Click Next. • Select the User Interface test. • The wizard can automatically generate tests. Confirm that the User Interface Test check box is selected and that the GUI Regression Test check box is cleared. The User Interface test will check that the application complies with Microsoft user interface standards. Click Next. • Accept the default navigation controls • Accept the default Navigation Controls if you do not need to define additional controls. Click Next 39Mercury WinRunner - Kamran Khan –
  40. 40. • Learning flow • The learning flow determines how WinRunner walks through your application. Two modes are available: Express and Comprehensive. Comprehensive mode lets you customize how the wizard learns GUI object descriptions. First-time WinRunner users should use Express mode. • Click the Learn button. The wizard begins walking through the application, pulling down menus, opening windows, and learning object descriptions. This process takes a few minutes. • Save the GUI information and a startup script • The wizard saves the GUI information in a GUI map file. The wizard also creates a startup script. This script runs automatically each time you start WinRunner. It contains a command that loads the GUI map file so that WinRunner will be ready to test your application. • Save the User Interface test. • Click OK in the Congratulations screen 40Mercury WinRunner - Kamran Khan –
  41. 41. WinRunner Play Back Modes  WinRunner provides three modes for running tests. You select a mode from the toolbar.  Use Verify mode when running a test to check the behavior of your application, and when you want to save the test results.  Use Debug mode when you want to check that the test script runs smoothly without errors in syntax.  Use Update mode when you want to create new expected results for a GUI checkpoint or bitmap checkpoint.  Running WinRunner test  Check that WinRunner and the application are still open on your desktop There are two options for running the User Interface Test  Run from Top (it runs the complete test)  Run from arrow (it starts running the test after the cursor/arrow location)  Check Run > Run from Top/Run from Arrow or press the button located on Standard Toolbar run the test.  Choose a Test Run name  Define the name of the directory in which WinRunner will store the results of the test. Accept the default name e.g., “res1.”  Run the UI test  Click OK in the Run Test dialog box. WinRunner immediately begins running the UI test. Watch how WinRunner opens each window in the application. 41Mercury WinRunner - Kamran Khan –
  42. 42. How do we write script?  TSL Acronym for Test Script Language Similar to Basic Easy to use and comprehend Each statement of the script is a function call Like any other function, it needs error handling You can record or write TSL code manually 42Mercury WinRunner - Kamran Khan –
  43. 43. TSL Script Sample  # launch the new browser instance  web_browser_invoke(IE," 80/oms/ActionServlet? userId=U1&handleId=MolsonLogin");  wait(10);  seconds = get_time();  new_time = time_str(seconds);  report_msg("Test run on : "&new_time); 43Mercury WinRunner - Kamran Khan –
  44. 44. How do we write script?  Recording modes  Context Sensitive  Operations recorded in terms of GUI objects.  WR identifies each object you click (button etc) and each operation you perform (button click etc).  E.g. button_press(“Ok”);  Analog  WR records exact co-ordinates moved by mouse and keyboard inputs.  E.g. move_locator_track (1); mtype ( “<kLeft+>” ); 44Mercury WinRunner - Kamran Khan –
  45. 45. How do we write script?  Recording modes Which one do I use? Normally we use Context Sensitive Mode but if the application requires some special actions as signature of user on a sign-pad then user Analog mode. 45Mercury WinRunner - Kamran Khan –
  46. 46. How do we write script?  Why do I need parameterization? There might be a test case that needs to be run for different data sets E.g. A login script that is recorded for a AUT may need to be run again with different role login id and password. 46Mercury WinRunner - Kamran Khan –
  47. 47. How do we write script?  Record  Replay  How do i perform parameterization?  Manually write the TSL code (err…..), or  Use Data Driver Wizard  Verify  To check AUT  Debug  To debug test  Update  To updated expected values  Enhance script by adding functions  Adding checkpoints and putting custom messages on report 47Mercury WinRunner - Kamran Khan –
  48. 48. Checkpoints  What are they?  To verify the test actual results we use check points  They compare the actual results with expected results  Set the test case status to ‘pass’ or ‘fail’ based on checkpoint  A script is useless without checkpoint  How do i add them?  WR has menu-items for the same. They are single click away while recording scripts.  Color coded test results  Passed  Failed 48Mercury WinRunner - Kamran Khan –
  49. 49. Checkpoints  Various checkpoints - By adding GUI checkpoints to your test scripts, you can compare the behavior of GUI objects in different versions of your application.  GUI Checkpoints  GUI Checkpoint for Single property Create->GUI Checkpoint->For Single Property  GUI Checkpoint for Object/Window Create->GUI Checkpoint ->For Object/Window  GUI Checkpoint for Multiple Objects Create->GUI Checkpoint->For Multiple Objects - To check the status of GUI objects. - e.g. check if a button is enabled/disabled.  Bitmap Checkpoints - To check for bitmaps and graphics. - Not recommended to have them in script.  Database Checkpoints - To check if a transaction stores proper data in database. 49Mercury WinRunner - Kamran Khan –
  50. 50. Checking a Single Property Value in WR  You can check a single property of a GUI object. For example, you can check whether a button is enabled or disabled or whether an item in a list is selected.  Choose Create > GUI Checkpoint > For Single Property. If you are recording in Analog mode, press the CHECK GUI FOR SINGLE PROPERTY soft key in order to avoid extraneous mouse movements.  Click an object. The Check Property dialog box opens and shows the default function for the selected object. WinRunner automatically assigns argument values to the function.  You can modify the arguments for the property check. To modify assigned argument values, choose a value from the Attribute list. The expected value is updated in the Expected text box.  Click Paste to paste the statement into your test script.The function is pasted into the script at the insertion point. The Check Property dialog box closes. 50Mercury WinRunner - Kamran Khan –
  51. 51. GUI checkpoint using Default Checks  You can create a GUI checkpoint that performs a default check on the property recommended by WinRunner. For example, if you create a GUI checkpoint that checks a push button, the default check verifies that the push button is enabled.  To create a GUI checkpoint using default checks: Choose Create > GUI Checkpoint > For Object/Window, or click the GUI Checkpoint for Object/Window button on the User toolbar.  If you are recording in Analog mode, press the CHECK GUI FOR OBJECT/WINDOW softkey in order to avoid extraneous mouse movements. Note that you can press the CHECK GUI FOR OBJECT/WINDOW softkey in Context Sensitive mode as well.  The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a help window opens on the screen.  Click an object.  WinRunner captures the current value of the property of the GUI object being checked and stores it in the test’s expected results folder. The WinRunner window is restored and a GUI checkpoint is inserted in the test script as an obj_check_gui statement. 51Mercury WinRunner - Kamran Khan –
  52. 52. GUI Checkpoint by Specifying the Properties to Check  You can specify which properties to check for an object. For example, if you create a checkpoint that checks a push button, you can choose to verify that it is in focus, instead of enabled.  To create a GUI checkpoint by specifying which properties to check:  Choose Create > GUI Checkpoint > For Object/Window, or click theGUI Checkpoint for Object/Window button on the User toolbar.  If you are recording in Analog mode, press the CHECK GUI FOR OBJECT/WINDOW softkey in order to avoid extraneous mouse movements. Note that you can press the CHECK GUI FOR OBJECT/WINDOW softkey in Context Sensitive mode as well. The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a help window opens on the screen. Double-click the object or window. The Check GUI dialog box opens 52Mercury WinRunner - Kamran Khan –
  53. 53. Checking Bitmaps:  By adding Bitmap checkpoints to your test scripts, you can compare the Bitmap in different versions of your application.  Win Runner Provides Two Types of Bitmap Checkpoints  Bitmap checkpoint of Screen Area  Bitmap Checkpoint for Object/window  GUI Checkpoint can be inserted in WinRunner’s Test Script as:  Create  Bitmap Checkpoint  For Screen Are  Create  Bitmap Checkpoint  For Object/Windwow 53Mercury WinRunner - Kamran Khan –
  54. 54. Synchronization Points There are three kinds of synchronization points:  Object/window synchronization points When you want WinRunner to wait for an object or a window to appear, you create an object/window synchronization point.  Property value synchronization points When you want WinRunner to wait for an object or a window to have a specified property, you create a property value synchronization point.  Bitmap synchronization points. When you want WinRunner to wait for a visual cue to be displayed, you create a bitmap synchronization point. In a bitmap synchronization point, WinRunner waits for the bitmap of an object, a window, or an area of the screen to appear. Caputuring text from AUT Screen  By Using WinRunner User can capture the text displayed on the screen.  By Capturing the text from screen area. Use:  Create->get text ->From Screen Area  Create->Get Text->From Object/Window 54Mercury WinRunner - Kamran Khan –
  55. 55. Maintaining Tests  Debugging tools  Step by step  Breakpoints  Watch list  GUI Map Editor  Add objects and write custom code  Modify existing objects’ definition  Function Generator  Documentation  Supported Environments  Documentation and Other Resources 55Mercury WinRunner - Kamran Khan –
  56. 56. TD connection  What is TD?  WR can connect to TD.  TD can launch WR and hence execute scheduled tests.  User menu-item “ Tools->TD Connection”.  TD can save results of test if WR is launched from TD. 56Mercury WinRunner - Kamran Khan –
  57. 57. Batch mode  Batch mode runs scripts in batch mode.  WR breaks the test/script execution when a mismatch or error is detected.  Batch mode causes WR to suppress this message.  Excellent option for overnight runs (unattended execution) ! 57Mercury WinRunner - Kamran Khan –
  58. 58. Practical !  Install WR, if not installed already!  Use Rapid Test script Wizard to record the GUI Map for the application “flight2a.exe” located in dir “WR-install- dirMercury InteractiveWinRunnersamplesflightapp”. Password is “mercury”, login can be any.  Record a login script for “flight2a.exe” and parameterize the script for the various login names  Use WR to record a script to visit yahoo page, perform a search, add a object checkpoint and check results. 58Mercury WinRunner - Kamran Khan –
  59. 59. Q & A 59Mercury WinRunner - Kamran Khan –
  60. 60. 60Mercury WinRunner - Kamran Khan –

Editor's Notes

  • Target Audience: Test Developers who wish to automate their UI test cases
    Last Updated: 20090224
    © Copy Rights Reserved
    Author: Kamran Shaukat Ali Khan
    E-mail: [you can add this on GTalk/Google Hangout as long as you don’t expect me to reply  ]
  • This file was downloaded from:
    For more training material, visit
  • TD is a tool for test case management and also a bug database management tool