Slideshow Transcript

1. Slide 1: Winrunner Training Objective of the Course •Understand the benefits of automated testing •To get an insight into the working of automated test tools •To use and understand the features of Winrunner •Creation of test scripts using Winrunner
2. Slide 2: Benefits of Automated Testing WinRunner Testing Process WinRunner Recording Mode Working with other Test Suite Tools
3. Slide 3: Manual Vs. Automated Testing Manual Testing:  Is time-consuming and tedious  Requires a heavy investment in human resources  Time constraints often make it impossible to manually test every feature thoroughly before the software is released Automated Testing:  Dramatically speed up the testing process  Creation of test scripts which check all aspects of the application  Execute these tests on each new build
4. Slide 4: Benefits of Automated Testing Fast: Run 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 Comprehensive: You can build a suite of tests that covers every feature in your application Reusable: You can reuse tests on different versions of an application, even if the user interface changes
5. Slide 5: WinRunner Testing Process 1 Create the GUI Map  WinRunner must learn to recognize the objects in an application in order to run tests  The preferred way to teach WinRunner your objects depends on the GUI map mode 2 Create Tests  WinRunner writes scripts automatically when recording actions in applications  One can program directly in Mercury Interactive’s Test Script Language (TSL) 3 Debug Tests  You debug the tests to check that they operate smoothly and without interruption
6. Slide 6: WinRunner Testing Process 4 Run Tests  Run tests in Verify mode to test your application  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 5 View Results  After 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 6 Report Defects  If a test run fails due to a defect in the application being tested it can be reported 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
7. Slide 7: Recording Mode Context Sensitivity Context Sensitivity records operations in terms of GUI objects. For e.g. if you record a mouse click on OK button. WinRunner generates following TSL statements- button_press (“OK”); Analog Mode Analog Mode Records the exact coordinates traveled by the mouse For e.g. if you record a mouse click on OK button. WinRunner generates following TSL statements move_locator_track (1); mtype (\"<T110><kLeft>-\"); mtype (\"<kLeft>+\");
8. Slide 8: Choosing a Recording Mode Choose Context Sensitive if... Choose Analog if... • • The application contains GUI objects The application contains bitmap areas (such as a drawing area) • Exact mouse movements are not • required Exact mouse movements are required • You plan to reuse the test in different versions of the application
9. Slide 9: Recording User Actions • Starting WinRunner – To start WinRunner, click Start > Programs > WinRunner > WinRunner
10. Slide 10: Recording User Actions • Creating a New test – Click on New Test
11. Slide 11: WinRunner Main Window
12. Slide 12: WinRunner Standard Toolbar
13. Slide 13: Recording a Test • To Record a Test in WinRunner, Select the Record Button from the Standard Toolbar
14. Slide 14: Recording a Test Automatic Script Generation Enter Application Data • Open the Application and Enter the Data
15. Slide 15: Benefits of Automated Testing WinRunner Testing Process WinRunner Recording Mode Working with other Test Suite Tools
16. Slide 16: Working with Other Test Suite Tools WinRunner works with other Test Suite tools to provide an integrated solution for all phases of the testing process I.e. Test Planning, Test Development, GUI and Load Testing, Defect Tracking Test Director: Software Test Management Tool • Creation of a database of manual and automated tests, building of test cycles, running tests, and report and track defects • With WinRunner, tests can be directly saved into the Test Director database • Tests can be executed in WinRunner and the overall results can be reviewed in Test Director Load Runner: Testing tool for Client/Server Applications • Using Load Runner, you can emulate an environment in which many users (virtual users) are simultaneously engaged in a single server application • You can test an application’s performance “under load” by simultaneously activating virtual users on multiple host computers.
17. Slide 17: Summary • Advantages of Automated Testing over Manual Testing (Fast, Reliable, Repeatable, Programmable, Comprehensive, Reusable) • The WinRunner Testing Process • Creating the GUI Map,Creating Tests,Debugging Tests,Running Tests,Viewing Results, Reporting Defects • WinRunner Recording Modes (Context Sensitivity,Analog) • Recording a Test • Working with other Test Suite Tools (Test Director, Load Runner)
18. Slide 18: LAB EXERCISE
19. Slide 19:  Record Login Process from Flight Reservation Sample Application in Context Sensitivity Mode  Record Flight Reservation Sample Application for Insert Order,Open Order and Fax Order  Record Burger Application for Order Entry Box
20. Slide 20: Day 2 Topic  Setting up GUI Map  Managing GUI Map  Using the Rapid Test Script Wizard
21. Slide 21: How Does WinRunner Create the Script?
22. Slide 22: How Does WinRunner Create the Script? • WinRunner adds windows and objects to the GUI Map as they are encountered by the user during recording • The GUI Map contains information that allows WinRunner TSL statements to be translated into Windows commands, and vice versa Recording WinRunner AUT set_window(\"Login\", 10); John edit_set (\"Name\", ”John\");
23. Slide 23: How Does WinRunner Run the Script? • When WinRunner executes a TSL statement, it passes through the GUI Map before being sent to Windows • The application’s response must pass through the GUI Map also Playback WinRunner AUT set_window(\"Login\", 10); John edit_set (\"Name\", ”John\");
24. Slide 24: Main Issues in Script Creation • Unique Identification of objects – WinRunner must uniquely identify each object in the Graphical User Interface (GUI) of the application • Naming of objects – How will WinRunner refer to GUI objects in the application? (\"Press the OK button in the Open window\")
25. Slide 25: How Does WinRunner Identify an Object? Displayed label class MSW_class x John y abs_x ******* abs_y maximizable focused width height active WinRunner uses an MSW_id handle object’s physical minimizable attributes to identify nchildren enabled the object TOOLKIT_class
26. Slide 26: How Does WinRunner Uniquely Identify an Object? label class John Class: push_button Label: “OK” ******* WR uses the minimum number of static attributes to achieve unique identification
27. Slide 27: How Does WinRunner Assign Object Names? John Class: push_button Label: “OK” ******* WinRunner assigns a edit_set (“Name”, “John”); short name to each edit_set (“Password”, “mercury”); object called the button_press (“OK”); logical name
28. Slide 28: Into Which Field Will WinRunner Play Back? John set_window(\"Login\", 10); edit_set (\"Name:\", \"John\");
29. Slide 29: Scope of Identification WinRunner identifies an object within the scope of its parent window (not the entire application) set_window (\"Login\", 10); edit_set (\"Name:\", \"John\"); John
30. Slide 30: WinRunner Tracks AUT’s Windows and Objects With the GUI Map File The GUI Map file contains GUI Map File the: WINDOW: Login • Windows of the AUT • Objects within each Name: Physical Description: window Name class: edit • Physical attributes that attached_text: \"Name\" create each object’s unique identification Password class: edit attached_text: \"Password\" OK class: push_button label: \"OK\"
31. Slide 31: GUI Map Editor • Visual tree displays windows and objects contained in the GUI Map File • First level consists of Parent Window all windows in AUT (logical name) • Second level consists of objects uniquely Child Objects identified within each (logical names) parent window Physical Description of window or object highlighted above
32. Slide 32: The GUI Map Characteristics Strengths • Allows separation of physical •Maintainability –If a button label changes in the attributes from test scripts application, update the button • Enables WinRunner to description once in the GUI map uniquely identify objects in rather than in 500 tests the AUT using physical •Readability attributes –button_press(\"Insert\") instead of • Allows WinRunner to refer to button_press(\"{class: objects in the script using an ThunderSSCommand}\"); intuitive logical name •Portability –Use the same script for all platforms, • Provides the connection with a different GUI map for each between logical names and platform physical attributes
33. Slide 33: GUI Map Translates Logical Names Into Physical Descriptions Options Class: Window Label: Window Dealer Name Class: Edit label: DealerName Address Class: Window set_window(\"Automobile Purchase Form\", 10); Label: Address Login edit_set (\"Customer Name\", \"Thomas Paine\"); Class: Window Label: Login edit_set (\"Address\",\"234 Willow Drive\"); Automobile Purchase Form Class: Window Label: APF Customer Name Class: Edit label: CustomerName Make Class: Window Label: Make SCRIPT GUI MAP AUT Logical Physical Name Description
34. Slide 34: Recording Example Application GUI Map Physical Logical { class: window, \"Save As\" Test Script MSW_id: 3277 label: \"Save As\" WinRunner } set_window (\"Save As\", 1); { button_press (\"OK\"); class: push_button, \"OK\" label: \"OK\" }
35. Slide 35: Playback Example Application GUI Map Physical Logical Save As { class: window, \"Save As\" Test Script MSW_id: 3277 label: \"Save As\" WinRunner } set_window (\"Save As\", 1); { button_press (\"OK\"); class: push_button, \"OK\" label: \"OK\" }
36. Slide 36: Summary • WinRunner uniquely identifies every object in the AUT by its physical description • Each object is uniquely identified within the scope of its parent window (not the entire application) • WinRunner references each object in the script using a logical name • Objects and their descriptions are stored in a GUI Map File • The GUI Map File can be viewed in the GUI Map Editor
37. Slide 37: Techniques For Managing GUI Map Files One GUI Map One GUI Map file for many file per test tests
38. Slide 38: Object and Window Properties During Recording WinRunner stores the names and Temporary GUI Map file descriptions for windows and objects in a temporary GUI Map WINDOW: Automobile Purchase Form file Name: Description: Date class: edit attached_text: \"Date\" set_window(\"Automobile Purchase Form\", 10); Make class: list attached_text: \"Make\" edit_set (\"Date\", \"12/12/03\"); Year class: edit list_select_item (\"Make\", \"BMW\"); attached_text: \"Year\" edit_set (\"Year\", \"1973\"); Model class: edit edit_set(\"Model\", \"2002tii\"); attached_text: \"Model\"
39. Slide 39: What Happens to These Properties? Use the GUI Map Editor to save the contents of the Temporary GUI Map file to a permanent GUI Map file Temporary GUI Map file WINDOW: Automobile Purchase Form Name: Description: Date class: edit attached_text: \"Date\" Make class: list attached_text: \"Make\" Year class: edit attached_text: \"Year\" Model class: edit attached_text: \"Model\"
40. Slide 40: Creating a Permanent GUI Map File Testing Project Tests L1 Car_App.gui Test1 Test2 Insert GUI Car_App.gui
41. Slide 41: Adding New Windows and Objects to a GUI Map File 1 Invoke the GUI Map Editor
42. Slide 42: Adding New Windows and Objects to a GUI Map File 1 2 Invoke the Press the Expand Button GUI Map to display Temporary and Editor Permanent GUI Map files
43. Slide 43: Adding New Windows and Objects to a GUI Map File 1 3 2 Move contents of Temp Invoke the Press the Expand Button to Permanent by GUI Map to display Temporary and pressing Move button Editor Permanent GUI Map files
44. Slide 44: Adding New Windows and Objects to a GUI Map File 1 4 3 2 Move contents of Temp Save changes Invoke the Press the Expand Button to permanent by to permanent GUI Map to display Temporary and pressing Move button GUI Map file Editor permanent GUI Map files
45. Slide 45: Save Project GUI Map Files Together Testing Project Tests L1 Insert.gui Test1 Test2 Insert GUI Test1.gui Test2.gui Insert.gui
46. Slide 46: Techniques for Managing GUI Map Files One GUI Map One GUI Map file for many file per test tests
47. Slide 47: Creating a Permanent GUI Map File 1 Invoke the GUI Map Editor
48. Slide 48: Creating a Permanent GUI Map File 1 Invoke the GUI Map Editor 2 Click the Learn Button The cursor changes to a pointing hand
49. Slide 49: Creating a Permanent GUI Map File 1 Invoke the GUI Map Editor 2 Click the Learn Button The cursor changes to a pointing hand Click on the 3 Window to be learned
50. Slide 50: Creating a Permanent GUI Map File 1 Invoke the GUI Map Editor 2 Click the Learn Button The cursor changes to a pointing hand Click on the 3 Window to be learned WinRunner learns all objects in window
51. Slide 51: Creating a Permanent GUI Map File 1 Invoke the GUI Map Editor 2 Click the Learn Button The cursor changes to a pointing hand Click on the 3 Window to be learned WinRunner learns all objects in window 4 Repeat for all windows in the application
52. Slide 52: Modify Names for Script Readability These names are unreadable. To what objects do they refer
53. Slide 53: Modify Names for Script Readability 1 Highlight the object whose name you want to change
54. Slide 54: Modify Names for Script Readability 1 Highlight the object whose name you want to change 2 Click the Modify Button
55. Slide 55: Modify Names for Script Readability 1 Highlight the object whose name you want to change 2 Click the Modify Button 3 Change the Logical Name of the object 4 Click OK
56. Slide 56: Modify Names for Script Readability 1 Highlight the object whose name you want to change 2 Click the ! Modify Button RESULT 3 Change the Logical \"Name:” Name of the object appears in your test script during recording instead of 4 \"ThunderRTTextBox_0\" Click OK
57. Slide 57: Creating a Permanent GUI Map File Testing Project L1 Car_App.gui Tests Test1 Test2 Insert GUI Car_App.gui
58. Slide 58: Which Technique Should You Use? 1. Each test has GUI Map file 1. Object and window names can be independence very readable in the test script 2. There is no need for a GUI Map file 2. If an object or window description administrator changes, you only have to modify one GUI Map file–all tests will play 3. The GUI Map file is very simple to back properly create–record and save Preferred method if the Preferred method if the application is not intended application might change to change during renovation during renovation
59. Slide 59: Importance of the GUI Map File What happens when playback is attempted, and the proper GUI Map file is set_window(\"Automobile Purchase Form\", 10); Automobile Form not loaded? edit_set (\"Date\", \"12/12/03\"); Date list_select_item (\"Make\", \"BMW\"); edit_set (\"Year\", \"1973\"); edit_set(\"Model\", \"2002tii\"); edit_set (\"Purchase Price\", \"20000.00\"); ?
60. Slide 60: Load GUI Map File from Script GUI_load(\"N:\\\\Y2K_Proj\\\\GUI\\\\insert.gui\"); Insert.gui set_window(\"Automobile Purchase Form\", 10); edit_set (\"Date\", \"12/12/03\"); list_select_item (\"Make\", \"BMW\"); edit_set (\"Year\", \"1973\"); edit_set(\"Model\", \"2002tii\"); edit_set (\"Purchase Price\", \"20000.00\"); 12/12/03 BMW 2002tii 1973
61. Slide 61: Unload GUI Map File from Script Insert.gui GUI_close_all( ); GUI_load(\"N:\\\\Y2K_Proj\\\\GUI\\\\insert.gui\"); set_window(\"Automobile Purchase Form\", 10); edit_set (\"Date\", \"12/12/03\"); list_select_item (\"Make\", \"BMW\"); edit_set (\"Year\", \"1973\"); edit_set(\"Model\", \"2002tii\"); edit_set (\"Purchase Price\", \"20000.00\"); 12/12/03 BMW 2002tii 1973
62. Slide 62: Fixing the GUI Map File set_window(\"Automobile Purchase Form\", 10); edit_set (\"Date\", \"12/12/03\"); list_select_item (\"Make\", \"BMW\"); edit_set (\"Year\", \"1973\"); edit_set(\"Model\", \"2002tii\"); edit_set (\"Purchase Price\", \"20000.00\"); GUI Map file Name: Description: Date class: edit MSW_id: 14
63. Slide 63: Fixing the GUI Map File 1 2 set_window(\"Automobile Purchase Form\", 10); edit_set (\"Date\", \"12/12/03\"); list_select_item (\"Make\", \"BMW\"); edit_set (\"Year\", \"1973\"); edit_set(\"Model\", \"2002tii\"); edit_set (\"Purchase Price\", \"20000.00\"); GUI Map file Name: Description: Date class: edit MSW_id: 14
64. Slide 64: Use the GUI Map Editor to Fix File 1 4 Invoke the GUI Map Editor Save the file Highlight field L1 Insert.gui 2 *L1 Insert.gui and press Modify 3 Edit the description Active GUI file: N:\\\\Y2K_Project\\\\GUI\\insert.gui
65. Slide 65: Fixing the GUI Map File ! WinRunner can now set_window(\"Automobile Purchase Form\", 10); successfully edit_set (\"Date\", \"12/12/03\"); playback the script list_select_item (\"Make\", \"BMW\"); edit_set (\"Year\", \"1973\"); edit_set(\"Model\", \"2002tii\"); 12/12 /03 BMW 2002tii 1973
66. Slide 66: Custom User Toolbar The Custom User Toolbar feature allows you to customize WinRunner’s UI to suit your testing needs • Create shortcuts to frequently used WinRunner menu commands • Paste TSL statements into your test scripts • Execute TSL statements
67. Slide 67: Add GUI Map Editor to the Custom User Toolbar 1 Select Settings > Customize User Toolbar 2 In each category, select command(s) to appear in toolbar An icon for each command selected is added to the User Toolbar
68. Slide 68: Summary • Two methods to manage GUI Map files • 1 GUI Map per test • if AUT is not expected to change • easiest way to create a GUI Map file • 1 GUI Map for many tests • if changes to AUT are expected • most easily maintained • Use the GUI Map Editor to fix GUI Map file problems
69. Slide 69: LAB EXERCISE
70. Slide 70:  Use GUI Spy to learn the objects  Record Flight Application Sample and Save the temporary GUI Map file and Load the same GUI Map file (Use function)  Create GUI Map for the same Using Learn option  Merge Login and Flight Application GUI Map file into a single one  Create a GUI Map File for Burger Application using the Learn option
71. Slide 71: Day 3 Topic  Introduction to Verification  GUI Checkpoints  Database Checkpoints  Bitmap Checkpoints  Text Checkpoints
72. Slide 72: Verification GUI Checkpoints Database Checkpoints Bitmap Checkpoints Text Checkpoints
73. Slide 73: Verifying the AUT - Manual Testing SOFTWARE REQUIREMENT SPECIFICATIONS 2.3.2 Creating a New Order Once the end user selects File > New and enters their name, the \"Terms\" button is automatically enabled. Step Step Description Expected Result 1 Select File > New PASS ?
74. Slide 74: Verifying the AUT - Manual Testing SOFTWARE REQUIREMENT SPECIFICATIONS 2.3.2 Creating a New Order Once the end user selects File > New William Frawley and enters their name, the \"Terms\" button is automatically enabled. Step Step Description Expected Result 1 Select File > New 2 Enter your name The Terms button is enabled PASS ?
75. Slide 75: Verifying the AUT - Manual Testing SOFTWARE REQUIREMENT SPECIFICATIONS 2.3.2 Creating a New Order Once the end user selects File > New William Frawley and enters their name, the \"Terms\" button is automatically enabled. Step Step Description Expected Result 1 Select File > New 2 Enter your name The Terms button is enabled PASS ?
76. Slide 76: Verifying the AUT - Automated Testing SOFTWARE REQUIREMENT SPECIFICATIONS 2.3.2 Creating a New Order Once the end user selects File > New William Frawley and enters their name, the \"Terms\" button is automatically enabled.   set_window (\"Automobile Purchase Form\", 8);   menu_select_item (\"File;New Form\");   edit_set (\"Customer Name\", \"William Frawley\"); ?  
77. Slide 77: What Is WinRunner Verification? Verification is the process by which WinRunner reports whether expected results are actualized by the application.
78. Slide 78: How WinRunner Verifies 1 WinRunner or the tester stores an expected result with the recorded test script 2 WinRunner captures an actual result during playback 3 WinRunner compares the actual result to the stored, expected result 4 WinRunner reports the comparison outcome as PASS or FAIL
79. Slide 79: How Does a Checkpoint Work? AUT AUT Expected Actual Test Report ? Pass = Expected Actual X Fail
80. Slide 80: Process to Create Verification 1 Capture or create the expected result within the recorded test script 2 Test the checkpoint to ensure that it works for PASS and FAIL conditions 3 Run the recorded test script to verify correct execution NOTE The tester creates the expected result only for text verification
81. Slide 81: Playback - Run Modes • DEBUG To check for errors in the script (Results folder: debug) • VERIFY To test the application and verify the result (Results folder: res1 (default); user can rename) • UPDATE To overwrite the expected result with a new value (Results folder: exp)
82. Slide 82: GUI Object Verification Check the state or attributes of GUI objects: • Is the window the correct size? • Is the OK button enabled? • What is the content of the Name field?
83. Slide 83: Database Verification • Check the contents and dimensions of a database • Directly verify database- related transactions
84. Slide 84: Bitmap Image Verification • Check non-GUI object areas of the application by capturing a bitmap • Capture bitmap of window, object, or area of screen
85. Slide 85: Text Verification Read and verify text from bitmap areas or non-GUI object based interfaces (e.g., ASCII)
86. Slide 86: Summary • Verification allows WinRunner to check the AUT's behavior • Types of verification checks – GUI objects – databases – bitmap images – text • Use GUI Object verification whenever possible, because it is the most reliable
87. Slide 87: Verification GUI Checkpoints Database Checkpoints Bitmap Checkpoints Text Checkpoints
88. Slide 88: How Does GUI Checkpoints Work ? AUT AUT Expected Actual Test Report ? Pass = Expected Actual X Fail
89. Slide 89: Process for GUI checkpoints 1 Determine the visual cue(s) 2 Create GUI checkpoint 3 Test the Checkpoint to ensure that it works for ‘Pass’ & ‘Fail’ conditions 4 Run the recorded Test Script to verify correct execution
90. Slide 90: Process for GUI checkpoints 1 Determine the visual cue(s)
91. Slide 91: Which visual cues demonstrate that the AUT meets requirements • Flight Reservation Order information form GUI • On click of Insert Order object example • … a visual cue is given by the application Application returns a message Application returns a value Object changes its state
92. Slide 92: Determine which visual cues to verify ? Pushbutton Check Button Edit Field Enabled Enabled Compare Focus Focus Enabled Label Label Focus Width Range Height
93. Slide 93: Checkpoint differs depending on the object to be verified Type of Object Checkpoint function List list_check_info Button(check,radio,push) button_check_info Generic Object Obj_check_info Window Win_check_info
94. Slide 94: Process for GUI checkpoints 1 Determine the visual cue(s) 2 Create GUI checkpoint
95. Slide 95: Create GUI Checkpoints Select Checkpoint to fit the verification Type of GUI Checkpoint Example One property of one object Enabled Multiple properties of one object Enabled, Label Enabled, Focus Multiple properties of multiple objects State, Label
96. Slide 96: Check One property of one Object • Select GUI Checkpoint for single property set_window(“Login\", 2); edit_set (“Agent Name:\", “Test\"); obj_type (“Agent Name:”,”<kTab>”); edit_set (“Password\", “mercury\");
97. Slide 97: Check One property of one Object • Select GUI Checkpoint for single property • Point to the Object • WinRunner inserts button_check_info set_window(“Login\", 2); statement into the edit_set (“Agent Name:\", “Test\"); recorded Test Script obj_type (“Agent Name:”,”<kTab>”); edit_set (“Password\", “mercury\"); button_check_info (“OK”,”enabled”,0);
98. Slide 98: Check Multiple properties of one Object • Select GUI Checkpoint for Object/Window set_window(“Login\", 2); edit_set (“Agent Name:\", “Test\"); obj_type (“Agent Name:”,”<kTab>”); edit_set (“Password\", “mercury\");
99. Slide 99: Check Multiple properties of one Object • Select GUI Checkpoint for Object/Window • Point to the Object • Select Multiple properties for the set_window(“Login\", 2); objects edit_set (“Agent Name:\", “Test\"); obj_type (“Agent Name:”,”<kTab>”); edit_set (“Password\", “mercury\"); obj_check_gui(\"OK\", \"list1.ckl\", \"gui1\", 1);
100. Slide 100: Check Multiple properties of one Object • Select GUI Checkpoint for Object/Window • Point to the Object • Select Multiple properties for the set_window(“Login\", 2); objects edit_set (“Agent Name:\", “Test\"); • WinRunner inserts a obj_type (“Agent Name:”,”<kTab>”); obj_check_gui edit_set (“Password\", “mercury\"); statement obj_check_gui(\"OK\", \"list1.ckl\", \"gui1\", 1);
101. Slide 101: Check Multiple properties of multiple Objects • Select GUI Checkpoint for Multiple Objects set_window(“Login\", 2); edit_set (“Agent Name:\", “Test\"); obj_type (“Agent Name:”,”<kTab>”); edit_set (“Password\", “mercury\");
102. Slide 102: Check Multiple properties of multiple Objects • Select GUI Checkpoint for Multiple Objects • Click Add and point to the object set_window(“Login\", 2); edit_set (“Agent Name:\", “Test\"); obj_type (“Agent Name:”,”<kTab>”); edit_set (“Password\", “mercury\");
103. Slide 103: Check Multiple properties of multiple Objects • Select GUI Checkpoint for Multiple Objects • Click Add and point to the object • Select Multiple set_window(“Login\", 2); properties for multiple edit_set (“Agent Name:\", “Test\"); objects obj_type (“Agent Name:”,”<kTab>”); edit_set (“Password\", “mercury\");
104. Slide 104: Check Multiple properties of multiple Objects • Select GUI Checkpoint for Multiple Objects • Point to the Object • Select Multiple properties for multiple set_window(“Login\", 2); objects edit_set (“Agent Name:\", “Test\"); • WinRunner inserts a obj_type (“Agent Name:”,”<kTab>”); win_check_gui edit_set (“Password\", “mercury\"); statement win_check_gui(\"Login\", \"list2.ckl\", \"gui2\", 1);
105. Slide 105: Process for GUI checkpoints 1 Determine the visual cue(s) 2 Create GUI checkpoint 3 Test the Checkpoint to ensure that it works for ‘Pass’ & ‘Fail’ conditions
106. Slide 106: Test the checkpoint • Checkpoint should work for both ‘Pass’ and ‘Fail’ condition • Set the object to a state that should ‘Pass’ • Step through the checkpoint in Debug mode • Set the object to a state that should ‘Fail’ (Reverse the object state) • Step through the checkpoint again • Verify correct execution
107. Slide 107: Process for GUI checkpoints 1 Determine the visual cue(s) 2 Create GUI checkpoint 3 Test the Checkpoint to ensure that it works for ‘Pass’ & ‘Fail’ conditions 4 Run the recorded Test Script to verify correct execution
108. Slide 108: Verify correct Script Execution • After successfully testing the Checkpoints for ‘Pass’ and ‘Fail’ conditions • We are ready to run the entire Script • Script should run without error • When Script is ok, we are ready to test the application under test (AUT)
109. Slide 1