Showing posts with label winrunner faqs. Show all posts
Showing posts with label winrunner faqs. Show all posts

Winrunner interview Questions and answers

  1. How you used WinRunner in your project? - Yes, I have been using WinRunner for creating automated scripts for GUI, functional and regression testing of the AUT.
  2. Explain WinRunner testing process? - WinRunner testing process involves six main stages
    • Create GUI Map File so that WinRunner can recognize the GUI objects in the application being tested
    • 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.
    • Debug Test: run tests in Debug mode to make sure they run smoothly
    • Run Tests: run tests in Verify mode to test your application.
    • View Results: determines the success or failure of the tests.
    • 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.
  3. What is contained in the GUI map?  - WinRunner stores information it learns about a window or object in a GUI Map. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object.s description in the GUI map and then looks for an object with the same properties in the application being tested. Each of these objects in the GUI Map file will be having a logical name and a physical description. There are 2 types of GUI Map files. Global GUI Map file: a single GUI Map file for the entire application. GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.
  4. How does WinRunner recognize objects on the application? - WinRunner uses the GUI Map file to recognize objects on the application. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object.s description in the GUI map and then looks for an object with the same properties in the application being tested.
  5. Have you created test scripts and what is contained in the test scripts?  - Yes I have created test scripts. It contains the statement in Mercury Interactive.s Test Script Language (TSL). These statements appear as a test script in a test window. You can then enhance your recorded test script, either by typing in additional TSL functions and programming elements or by using WinRunner.s visual programming tool, the Function Generator.
  6. How does WinRunner evaluate test results? - 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.
  7. Have you performed debugging of the scripts? - Yes, I have performed debugging of scripts. We can debug the script by executing the script in the debug mode. We can also debug script using the Step, Step Into, Step out functionalities provided by the WinRunner.
  8. How do you run your test scripts? - We 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.
  9. How do you analyze results and report the defects? - 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. 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.
  10. What is the use of Test Director software? - TestDirector is Mercury Interactive.s software test management tool. It helps quality assurance personnel plan and organize the testing process. With TestDirector you can create a database of manual and automated tests, build test cycles, run tests, and report and track defects. You can also create reports and graphs to help review the progress of planning tests, running tests, and tracking defects before a software release.
  11. Have you integrated your automated scripts from TestDirector? - When you work with WinRunner, you can choose to save your tests directly to your TestDirector database or while creating a test case in the TestDirector we can specify whether the script in automated or manual. And if it is automated script then TestDirector will build a skeleton for the script that can be later modified into one which could be used to test the AUT.
  12. What are the different modes of recording? - There are two type of recording in WinRunner.  Context Sensitive recording records the operations you perform on your application by identifying Graphical User Interface (GUI) objects. Analog recording records keyboard input, mouse clicks, and the precise x- and y-coordinates traveled by the mouse pointer across the screen.
  13. What is the purpose of loading WinRunner Add-Ins?  - Add-Ins are used in WinRunner to load functions specific to the particular add-in to the memory. While creating a script only those functions in the add-in selected will be listed in the function generator and while executing the script only those functions in the loaded add-in will be executed else WinRunner will give an error message saying it does not recognize the function.
  14. What are the reasons that WinRunner fails to identify an object on the GUI?  - WinRunner fails to identify an object in a GUI due to various reasons.  The object is not a standard windows object. If the browser used is not compatible with the WinRunner version, GUI Map Editor will not be able to learn any of the objects displayed in the browser window.
  15. What is meant by the logical name of the object? - An object.s logical name is determined by its class. In most cases, the logical name is the label that appears on an object.
  16. If the object does not have a name then what will be the logical name?  - If the object does not have a name then the logical name could be the attached text.
  17. What is the different between GUI map and GUI map files? - The GUI map is actually the sum of one or more GUI map files. There are two modes for organizing GUI map files. Global GUI Map file: a single GUI Map file for the entire application. GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.
  18. GUI Map file is a file which contains the windows and the objects learned by the WinRunner with its logical name and their physical description.
  19. How do you view the contents of the GUI map? - GUI Map editor displays the content of a GUI Map. We can invoke GUI Map Editor from the Tools Menu in WinRunner. The GUI Map Editor displays the various GUI Map files created and the windows and objects learned in to them with their logical name and physical description.
  20. When you create GUI map do you record all the objects of specific objects?  - If we are learning a window then WinRunner automatically learns all the objects in the window else we will we identifying those object, which are to be learned in a window, since we will be working with only those objects while creating scripts.

WinRunner Interview Questions,faqs

 WinRunner Interview Questions
1. Give one line answer about WinRunner?
2. How do you define WinRunner on your own?
3. WinRunner is suitable for which type of applications?
4. What are all the types of applications WinRunner can use?
5. What’s the WinRunner version number you used for your applications?
6. What are all the different types of recordings available in WinRunner?
7. When do you go for Context Sensitive and Analog recordings? What’s the difference between them?
8. What are all the Limitations & Advantages of WinRunner?
9. Where you find that you can’t use WinRunner for automation?
10. What’s the types application you working on using WinRunner?
11. What’s your comfort level in using WinRunner?
12. What is meant by Synchronization? How do you implement it in WinRunner?
13. What is meant by Check points? Types of Check points? In what situation will you use it?
14. What are all the different platforms that WinRunner can be used?
15. Any knowledge of Test Director?
16. Difference between WinRunner and Test Director?
17. What databases can Test Director reside on?
18. Explain the project tree in Test Director.
19. Advantages of WinRunner over other market tools silk, robot etc.?
20. How does Winrunner identify GUI Objects?
21. What’s the use of GUI Map Editor?
22. Winrunner GUI map modes?
23. What are the two GUI Map modes available in WinRunner?
24. What is the use of rapid test script wizard?
25. How will you synchronize tests using WinRunner? When should you synchronize? Synchronize settings?
26. How do you check GUI objects?
27. How do you check a bitmap?
28. What is meant by GUI Spy?
29. Besides Record and Replay what else can be done using WinRunner?
30. What are different types of running a test?
31. When do you use Verify/Debug/Update Modes?
32 When do you use Break Points?
33. What is Toggle Break Points? How it differ from Break points?
34. What’s Step and Step into?
35. What’s the role of GUI Map Editor? (Its connects logical name in the script to the physical attributes of the object in the GUI Map Editor).
36. What is meant by Function Generator? (F7).
37. How do you load GUI Map Editor?
38. What is injector in load runner?
39. What is TSL? What 4GL is it similar too?
40. How do you program tests with TSL?
41. How do you invoke an application using TSL?
42. What is Module? What’s Compiled Module?
43. Explain data parameterization in WinRunner.
44. What is User Define Functions? What are all the different types of User
45. What is Function? Types of Functions?
46. Defined Functions available in WinRunner?
47. Name a couple of standard web function found in the function generator? And explain their purpose.
48. Where do you use Private/Public function in your script?
49. How do you forcibly capture an Object using WinRunner (when WinRunner not able identify it)?
50. Can you test DB using WinRunner?
51. What are all the different DB that WinRunner can support?
52. How do you set a Query to get/fetch data from the DB?
53. How TSL looks like?
54. What are all the default codes WinRunner will generates when you start an application?
55. What are the other codes you can write/call with in TSL? 56. What are all the different languages can be called using TSL in between the scripts?
57. How do you handle an Exception in WinRunner?
58. Types of Exception available in WinRunner?
59. How do you define an Exception for complete application or for a particular function?
60. How do you run tests on a new version of WinRunner?
61. What are data driven tests & How Do you create it in WinRunner?
62. What’s the File Format used in Data Table?
63. How do you link a Data Table in your script?
64. How do you read text from an application?
65. What is a batch test? How do you program a batch test?
66. What happens when user interface changes?
67. Does load testing possible using WinRunner?
68. Does WinRunner help you in web testing?
69. How do you manage test data, test result?
70. Questions on TSL: How to generate Functions?
71. Running tests from the command line?
72. Explain WinRunner Testing Modes?
73. Have you completed the CPS exam? Which one?
74. Write a short compiled module which selects random numbers; and what function is used to call your customized compiled module?
75. What’s the purpose of the wrun.ini file?

Winrunner Testing Interview

  1. What is the use of function generator? - a) The Function Generator provides a quick, error-free way to program scripts. You can:
    i. Add Context Sensitive functions that perform operations on a GUI object or get information from the application being tested.
    ii. Add Standard and Analog functions that perform non-Context Sensitive tasks such as synchronizing test execution or sending user-defined messages to a report.
    iii. Add Customization functions that enable you to modify WinRunner to suit your testing environment.
  2. What is the use of putting call and call_close statements in the test script? - a) You can use two types of call statements to invoke one test from another:
    i. A call statement invokes a test from within another test.
    ii. A call_close statement invokes a test from within a script and closes the test when the test is completed.
    iii. The call statement has the following syntax:
  3. call test_name ( [ parameter1, parameter2, ...parametern ] ); - iv. The call_close statement has the following syntax:
  4. call_close test_name ( [ parameter1, parameter2, ... parametern ] ); - v. The test_name is the name of the test to invoke. The parameters are the parameters defined for the called test.
    vi. The parameters are optional. However, when one test calls another, the call statement should designate a value for each parameter defined for the called test. If no parameters are defined for the called test, the call statement must contain an empty set of parentheses.
  5. What is the use of treturn and texit statements in the test script? - a) The treturn and texit statements are used to stop execution of called tests.
    i. The treturn statement stops the current test and returns control to the calling test.
    ii. The texit statement stops test execution entirely, unless tests are being called from a batch test. In this case, control is returned to the main batch test.
    b) Both functions provide a return value for the called test. If treturn or texit is not used, or if no value is specified, then the return value of the call statement is 0.
    treturn
    c) The treturn statement terminates execution of the called test and returns control to the calling test.
    The syntax is:
    treturn [( expression )];
    d) The optional expression is the value returned to the call statement used to invoke the test.
    texit
    e) When tests are run interactively, the texit statement discontinues test execution. However, when tests are called from a batch test, texit ends execution of the current test only; control is then returned to the calling batch test.
    The syntax is:
    texit [( expression )];
  6. Where do you set up the search path for a called test. - a) The search path determines the directories that WinRunner will search for a called test.
    b) To set the search path, choose Settings > General Options. The General Options dialog box opens. Click the Folders tab and choose a search path in the Search Path for Called Tests box. WinRunner searches the directories in the order in which they are listed in the box. Note that the search paths you define remain active in future testing sessions.
  7. How you create user-defined functions and explain the syntax? - a) A user-defined function has the following structure:
    [class] function name ([mode] parameter…)
    {
    declarations;
    statements;
    }
    b) The class of a function can be either static or public. A static function is available only to the test or module within which the function was defined.
    c) Parameters need not be explicitly declared. They can be of mode in, out, or inout. For all non-array parameters, the default mode is in. For array parameters, the default is inout. The significance of each of these parameter types is as follows:
    in: A parameter that is assigned a value from outside the function.
    out: A parameter that is assigned a value from inside the function.
    inout: A parameter that can be assigned a value from outside or inside the function.
  8. What does static and public class of a function means? - a) The class of a function can be either static or public.
    b) A static function is available only to the test or module within which the function was defined.
    c) Once you execute a public function, it is available to all tests, for as long as the test containing the function remains open. This is convenient when you want the function to be accessible from called tests. However, if you want to create a function that will be available to many tests, you should place it in a compiled module. The functions in a compiled module are available for the duration of the testing session.
    d) If no class is explicitly declared, the function is assigned the default class, public.
  9. What does in, out and input parameters means? - a) in: A parameter that is assigned a value from outside the function.
    b) out: A parameter that is assigned a value from inside the function.
    c) inout: A parameter that can be assigned a value from outside or inside the function.
  10. What is the purpose of return statement? - a) This statement passes control back to the calling function or test. It also returns the value of the evaluated expression to the calling function or test. If no expression is assigned to the return statement, an empty string is returned.
    Syntax: return [( expression )];
  11. What does auto, static, public and extern variables means? - a) auto: An auto variable can be declared only within a function and is local to that function. It exists only for as long as the function is running. A new copy of the variable is created each time the function is called.
    b) static: A static variable is local to the function, test, or compiled module in which it is declared. The variable retains its value until the test is terminated by an Abort command. This variable is initialized each time the definition of the function is executed.
    c) public: A public variable can be declared only within a test or module, and is available for all functions, tests, and compiled modules.
    d) extern: An extern declaration indicates a reference to a public variable declared outside of the current test or module.
  12. How do you declare constants? - a) The const specifier indicates that the declared value cannot be modified. The class of a constant may be either public or static. If no class is explicitly declared, the constant is assigned the default class public. Once a constant is defined, it remains in existence until you exit WinRunner.
    b) The syntax of this declaration is:
    [class] const name [= expression];
  13. How do you declare arrays? - a) The following syntax is used to define the class and the initial expression of an array. Array size need not be defined in TSL.
    b) class array_name [ ] [=init_expression]
    c) The array class may be any of the classes used for variable declarations (auto, static, public, extern).
  14. How do you load and unload a compile module? - a) In order to access the functions in a compiled module you need to load the module. You can load it from within any test script using the load command; all tests will then be able to access the function until you quit WinRunner or unload the compiled module.
    b) You can load a module either as a system module or as a user module. A system module is generally a closed module that is “invisible” to the tester. It is not displayed when it is loaded, cannot be stepped into, and is not stopped by a pause command. A system module is not unloaded when you execute an unload statement with no parameters (global unload).
    load (module_name [,1|0] [,1|0] );
    The module_name is the name of an existing compiled module. Two additional, optional parameters indicate the type of module. The first parameter indicates whether the function module is a system module or a user module: 1 indicates a system module; 0 indicates a user module.
    (Default = 0)
    The second optional parameter indicates whether a user module will remain open in the WinRunner window or will close automatically after it is loaded: 1 indicates that the module will close automatically; 0 indicates that the module will remain open.
    (Default = 0)
    c) The unload function removes a loaded module or selected functions from memory.
    d) It has the following syntax:
    unload ( [ module_name | test_name [ , "function_name" ] ] );
  15. How do you update your expected results? -
  16. How do you run your script with multiple sets of expected results? -
  17. How do you view and evaluate test results for various check points? -
  18. How do you view the results of file comparison? -
  19. What is the purpose of Wdiff utility? -
  20. What are batch tests and how do you create and run batch tests ? -
  21. How do you store and view batch test results? -
  22. How do you execute your tests from windows run command? -
  23. Explain different command line options? -
  24. What TSL function you will use to pause your script? -
  25. What is the purpose of setting a break point? -
  26. What is a watch list? -
  27. During debugging how do you monitor the value of the variables? -
  28. What are the reasons that WinRunner fails to identify an object on the GUI? - a) WinRunner fails to identify an object in a GUI due to various reasons.
    i. The object is not a standard windows object.
    ii. If the browser used is not compatible with the WinRunner version, GUI Map Editor will not be able to learn any of the objects displayed in the browser window.
  29. What do you mean by the logical name of the object. - a) An object’s logical name is determined by its class. In most cases, the logical name is the label that appears on an object.
  30. If the object does not have a name then what will be the logical name? - If the object does not have a name then the logical name could be the attached text.
  31. What is the different between GUI map and GUI map files? - a) The GUI map is actually the sum of one or more GUI map files. There are two modes for organizing GUI map files.
    i. Global GUI Map file: a single GUI Map file for the entire application
    ii. GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.
    b) GUI Map file is a file which contains the windows and the objects learned by the WinRunner with its logical name and their physical description.
  32. How do you view the contents of the GUI map? - a) GUI Map editor displays the content of a GUI Map. We can invoke GUI Map Editor from the Tools Menu in WinRunner. The GUI Map Editor displays the various GUI Map files created and the windows and objects learned in to them with their logical name and physical description.
  33. What is startup script in WinRunner? - It is writing a script and when WinRunner starts it automatically runs the script. If you write script like invoking some application as soon as the script is run the application will be invoked for the purpose of testing
  34. What is the purpose of loading WinRunner add-ins? - Add-ins are used in WinRunner to load functions specific to the particular add-in to the memory. While creating a script only those functions in the add-in selected will be listed in the function generator,and while executing the script only those functions in the loaded add-in will be executed,else WinRunner will give an error message saying it does not recognize the function
  35. What is the purpose of GUI spy? - Using the GUI spy you can view the properties of any GUI object and 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. You can choose to view all properties of an object, or only the selected set of properties that WinRunner learns.
  36. When you create GUI map do you record all the objects of specific objects? - a) If we are learning a window then WinRunner automatically learns all the objects in the window else we will we identifying those object, which are to be learned in a window, since we will be working with only those objects while creating scripts.
  37. What is the purpose of set_window command? - b) Set_Window command sets the focus to the specified window. We use this command to set the focus to the required window before executing tests on a particular window. Syntax: set_window(, time); The logical name is the logical name of the window and time is the time the execution has to wait till it gets the given window into focus.
  38. How do you load GUI map? - c) We can load a GUI Map by using the GUI_load command. Syntax: GUI_load();
  39. What is the disadvantage of loading the GUI maps through start up scripts? - d) If we are using a single GUI Map file for the entire AUT then the memory used by the GUI Map may be much high. e) If there is any change in the object being learned then WinRunner will not be able to recognize the object, as it is not in the GUI Map file loaded in the memory. So we will have to learn the object again and update the GUI File and reload it.
  40. How do you unload the GUI map? - f) We can use GUI_close to unload a specific GUI Map file or else we call use GUI_close_all command to unload all the GUI Map files loaded in the memory. Syntax: GUI_close(); or GUI_close_all;

Winrunner QA Interview Question and answers

  1. Explain the following commands: - a) db_connect
    to connect to a database
    db_connect(, );
    b) db_execute_query
    to execute a query
    db_execute_query ( session_name, SQL, record_number );
    record_number is the out value.
    c) db_get_field_value
    returns the value of a single field in the specified row_index and column in the session_name database session.
    db_get_field_value ( session_name, row_index, column );
    d) db_get_headers
    returns the number of column headers in a query and the content of the column headers, concatenated and delimited by tabs.
    db_get_headers ( session_name, header_count, header_content );
    e) db_get_row
    returns the content of the row, concatenated and delimited by tabs.
    db_get_row ( session_name, row_index, row_content );
    f) db_write_records
    writes the record set into a text file delimited by tabs.
    db_write_records ( session_name, output_file [ , headers [ , record_limit ] ] );
    g) db_get_last_error
    returns the last error message of the last ODBC or Data Junction operation in the session_name database session.
    db_get_last_error ( session_name, error );
    h) db_disconnect
    disconnects from the database and ends the database session.
    db_disconnect ( session_name );
    i) db_dj_convert
    runs the djs_file Data Junction export file. When you run this file, the Data Junction Engine converts data from one spoke (source) to another (target). The optional parameters enable you to override the settings in the Data Junction export file.
    db_dj_convert ( djs_file [ , output_file [ , headers [ , record_limit ] ] ] );
  2. What check points you will use to read and check text on the GUI and explain its syntax? - a) You can use text checkpoints in your test scripts to read and check text in GUI objects and in areas of the screen. While creating a test you point to an object or a window containing text. WinRunner reads the text and writes a TSL statement to the test script. You may then add simple programming elements to your test scripts to verify the contents of the text.
    b) You can use a text checkpoint to:
    i.Read text from a GUI object or window in your application, using obj_get_text and win_get_text
    ii.Search for text in an object or window, using win_find_text and obj_find_text
    iii. Move the mouse pointer to text in an object or window, using obj_move_locator_text and win_move_locator_text
    iv. Click on text in an object or window, using obj_click_on_text and win_click_on_text
  3. Explain Get Text checkpoint from object/window with syntax? - a) We use obj_get_text (, ) function to get the text from an object
    b) We use win_get_text (window, out_text [, x1, y1, x2, y2]) function to get the text from a window.
  4. Explain Get Text checkpoint from screen area with syntax? - a) We use win_get_text (window, out_text [, x1, y1, x2, y2]) function to get the text from a window.
  5. Explain Get Text checkpoint from selection (web only) with syntax? - a) Returns a text string from an object.
    web_obj_get_text (object, table_row, table_column, out_text [, text_before, text_after, index]);
    i. object The logical name of the object.
    ii. table_row If the object is a table, it specifies the location of the row within a table. The string is preceded by the # character.
    iii. table_column If the object is a table, it specifies the location of the column within a table. The string is preceded by the # character.
    iv. out_text The output variable that stores the text string.
    v. text_before Defines the start of the search area for a particular text string.
    vi. text_after Defines the end of the search area for a particular text string.
    vii. index The occurrence number to locate. (The default parameter number is numbered 1).
  6. Explain Get Text checkpoint web text checkpoint with syntax? - a) We use web_obj_text_exists function for web text checkpoints.
    web_obj_text_exists ( object, table_row, table_column, text_to_find [, text_before, text_after] );
    a. object The logical name of the object to search.
    b. table_row If the object is a table, it specifies the location of the row within a table. The string is preceded by the character #.
    c. table_column If the object is a table, it specifies the location of the column within a table. The string is preceded by the character #.
    d. text_to_find The string that is searched for.
    e. text_before Defines the start of the search area for a particular text string.
    f. text_after Defines the end of the search area for a particular text string.
  7. Which TSL functions you will use for - a) Searching text on the window
    i. find_text ( string, out_coord_array, search_area [, string_def ] );
    string The string that is searched for. The string must be complete, contain no spaces, and it must be preceded and followed by a space outside the quotation marks. To specify a literal, case-sensitive string, enclose the string in quotation marks. Alternatively, you can specify the name of a string variable. In this case, the string variable can include a regular expression.
    out_coord_array The name of the array that stores the screen coordinates of the text (see explanation below).
    search_area The area to search, specified as coordinates x1,y1,x2,y2. These define any two diagonal corners of a rectangle. The interpreter searches for the text in the area defined by the rectangle.
    string_def Defines the type of search to perform. If no value is specified, (0 or FALSE, the default), the search is for a single complete word only. When 1, or TRUE, is specified, the search is not restricted to a single, complete word.
    b) getting the location of the text string
    i. win_find_text ( window, string, result_array [, search_area [, string_def ] ] );
    window The logical name of the window to search.
    string The text to locate. To specify a literal, case sensitive string, enclose the string in quotation marks. Alternatively, you can specify the name of a string variable. The value of the string variable can include a regular expression. The regular expression should not include an exclamation mark (!), however, which is treated as a literal character. For more information regarding Regular Expressions, refer to the “Using Regular Expressions” chapter in your User’s Guide.
    result_array The name of the output variable that stores the location of the string as a four-element array.
    search_area The region of the object to search, relative to the window. This area is defined as a pair of coordinates, with x1,y1,x2,y2 specifying any two diagonally opposite corners of the rectangular search region. If this parameter is not defined, then the entire window is considered the search area.
    string_def Defines how the text search is performed. If no string_def is specified, (0 or FALSE, the default parameter), the interpreter searches for a complete word only. If 1, or TRUE, is specified, the search is not restricted to a single, complete word.
    c) Moving the pointer to that text string
    i. win_move_locator_text (window, string [ ,search_area [ ,string_def ] ] );
    window The logical name of the window.
    string The text to locate. To specify a literal, case sensitive string, enclose the string in quotation marks. Alternatively, you can specify the name of a string variable. The value of the string variable can include a regular expression (the regular expression need not begin with an exclamation mark).
    search_area The region of the object to search, relative to the window. This area is defined as a pair of coordinates, with x1, y1, x2, y2 specifying any two diagonally opposite corners of the rectangular search region. If this parameter is not defined, then the entire window specified is considered the search area.
    string_def Defines how the text search is performed. If no string_def is specified, (0 or FALSE, the default parameter), the interpreter searches for a complete word only. If 1, or TRUE, is specified, the search is not restricted to a single, complete word.
    d) Comparing the text
    i. compare_text (str1, str2 [, chars1, chars2]);
    str1, str2 The two strings to be compared.
    chars1 One or more characters in the first string.
    chars2 One or more characters in the second string. These characters are substituted for those in chars1.
  8. What are the steps of creating a data driven test? - a) The steps involved in data driven testing are:
    i. Creating a test
    ii. Converting to a data-driven test and preparing a database
    iii. Running the test
    iv. Analyzing the test results.
  9. Record a data driven test script using data driver wizard? - a) You can use the DataDriver Wizard to convert your entire script or a part of your script into a data-driven test. For example, your test script may include recorded operations, checkpoints, and other statements that do not need to be repeated for multiple sets of data. You need to parameterize only the portion of your test script that you want to run in a loop with multiple sets of data.
    To create a data-driven test:
    i. If you want to turn only part of your test script into a data-driven test, first select those lines in the test script.
    ii. Choose Tools > DataDriver Wizard.
    iii. If you want to turn only part of the test into a data-driven test, click Cancel. Select those lines in the test script and reopen the DataDriver Wizard. If you want to turn the entire test into a data-driven test, click Next.
    iv. The Use a new or existing Excel table box displays the name of the Excel file that WinRunner creates, which stores the data for the data-driven test. Accept the default data table for this test, enter a different name for the data table, or use
    v. The browse button to locate the path of an existing data table. By default, the data table is stored in the test folder.
    vi. In the Assign a name to the variable box, enter a variable name with which to refer to the data table, or accept the default name, “table.” vii. At the beginning of a data-driven test, the Excel data table you selected is assigned as the value of the table variable. Throughout the script, only the table variable name is used. This makes it easy for you to assign a different data table
    viii. To the script at a later time without making changes throughout the script.
    ix. Choose from among the following options:
  10. Add statements to create a data-driven test: Automatically adds statements to run your test in a loop: sets a variable name by which to refer to the data table; adds braces ({and}), a for statement, and a ddt_get_row_count statement to your test script selection to run it in a loop while it reads from the data table; adds ddt_open and ddt_close statements -
  11. To your test script to open and close the data table, which are necessary in order to iterate rows in the table. Note that you can also add these statements to your test script manually. -
  12. If you do not choose this option, you will receive a warning that your data-driven test must contain a loop and statements to open and close your datatable. -
  13. Import data from a database: Imports data from a database. This option adds ddt_update_from_db, and ddt_save statements to your test script after the ddt_open statement. -
  14. Note that in order to import data from a database, either Microsoft Query or Data Junction must be installed on your machine. You can install Microsoft Query from the custom installation of Microsoft Office. Note that Data Junction is not automatically included in your WinRunner package. To purchase Data Junction, contact your Mercury Interactive representative. For detailed information on working with Data Junction, refer to the documentation in the Data Junction package. -
  15. Parameterize the test: Replaces fixed values in selected checkpoints and in recorded statements with parameters, using the ddt_val function, and in the data table, adds columns with variable values for the parameters. Line by line: Opens a wizard screen for each line of the selected test script, which enables you to decide whether to parameterize a particular line, and if so, whether to add a new column to the data table or use an existing column when parameterizing data. -
  16. Automatically: Replaces all data with ddt_val statements and adds new columns to the data table. The first argument of the function is the name of the column in the data table. The replaced data is inserted into the table. - x. The Test script line to parameterize box displays the line of the test script to parameterize. The highlighted value can be replaced by a parameter. The Argument to be replaced box displays the argument (value) that you can replace with a parameter. You can use the arrows to select a different argument to replace.
    Choose whether and how to replace the selected data:
  17. Do not replace this data: Does not parameterize this data. -
  18. An existing column: If parameters already exist in the data table for this test, select an existing parameter from the list. -
  19. A new column: Creates a new column for this parameter in the data table for this test. Adds the selected data to this column of the data table. The default name for the new parameter is the logical name of the object in the selected. TSL statement above. Accept this name or assign a new name. - xi. The final screen of the wizard opens.
  20. If you want the data table to open after you close the wizard, select Show data table now. -
  21. To perform the tasks specified in previous screens and close the wizard, click Finish. -
  22. To close the wizard without making any changes to the test script, click Cancel. -
  23. What are the three modes of running the scripts? - a) WinRunner provides three modes in which to run tests—Verify, Debug, and Update. You use each mode during a different phase of the testing process.
    i. Verify
  24. Use the Verify mode to check your application. - ii. Debug
  25. Use the Debug mode to help you identify bugs in a test script. - iii. Update
  26. Use the Update mode to update the expected results of a test or to create a new expected results folder. -
  27. Explain the following TSL functions: - a) Ddt_open
    Creates or opens a datatable file so that WinRunner can access it.
    Syntax: ddt_open ( data_table_name, mode );
    data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.
    mode The mode for opening the data table: DDT_MODE_READ (read-only) or DDT_MODE_READWRITE (read or write).
    b) Ddt_save
    Saves the information into a data file.
    Syntax: dt_save (data_table_name);
    data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table.
    c) Ddt_close
    Closes a data table file
    Syntax: ddt_close ( data_table_name );
    data_table_name The name of the data table. The data table is a Microsoft Excel file or a tabbed text file. The first row in the file contains the names of the parameters.
    d) Ddt_export
    Exports the information of one data table file into a different data table file.
    Syntax: ddt_export (data_table_namename1, data_table_namename2);
    data_table_namename1 The source data table filename.
    data_table_namename2 The destination data table filename.
    e) Ddt_show
    Shows or hides the table editor of a specified data table.
    Syntax: ddt_show (data_table_name [, show_flag]);
    data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table.
    show_flag The value indicating whether the editor should be shown (default=1) or hidden (0).
    f) Ddt_get_row_count
    Retrieves the no. of rows in a data tables
    Syntax: ddt_get_row_count (data_table_name, out_rows_count);
    data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters.
    out_rows_count The output variable that stores the total number of rows in the data table.
    g) ddt_next_row
    Changes the active row in a database to the next row
    Syntax: ddt_next_row (data_table_name);
    data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters.
    h) ddt_set_row
    Sets the active row in a data table.
    Syntax: ddt_set_row (data_table_name, row);
    data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.
    row The new active row in the data table.
    i) ddt_set_val
    Sets a value in the current row of the data table
    Syntax: ddt_set_val (data_table_name, parameter, value);
    data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.
    parameter The name of the column into which the value will be inserted.
    value The value to be written into the table.
    j) ddt_set_val_by_row
    Sets a value in a specified row of the data table.
    Syntax: ddt_set_val_by_row (data_table_name, row, parameter, value);
    data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.
    row The row number in the table. It can be any existing row or the current row number plus 1, which will add a new row to the data table.
    parameter The name of the column into which the value will be inserted.
    value The value to be written into the table.
    k) ddt_get_current_row
    Retrieves the active row of a data table.
    Syntax: ddt_get_current_row ( data_table_name, out_row );
    data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.
    out_row The output variable that stores the active row in the data table.
    l) ddt_is_parameter
    Returns whether a parameter in a datatable is valid
    Syntax: ddt_is_parameter (data_table_name, parameter);
    data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters.
    parameter The parameter name to check in the data table.
    m) ddt_get_parameters
    Returns a list of all parameters in a data table.
    Syntax: ddt_get_parameters ( table, params_list, params_num );
    table The pathname of the data table.
    params_list This out parameter returns the list of all parameters in the data table, separated by tabs.
    params_num This out parameter returns the number of parameters in params_list.
    n) ddt_val
    Returns the value of a parameter in the active roe in a data table.
    Syntax: ddt_val (data_table_name, parameter);
    data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters.
    parameter The name of the parameter in the data table.
    o) ddt_val_by_row
    Returns the value of a parameter in the specified row in a data table.
    Syntax: ddt_val_by_row ( data_table_name, row_number, parameter );
    data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.
    row_number The number of the row in the data table.
    parameter The name of the parameter in the data table.
    p) ddt_report_row
    Reports the active row in a data table to the test results
    Syntax: ddt_report_row (data_table_name);
    data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.
    q) ddt_update_from_db
    imports data from a database into a data table. It is inserted into your test script when you select the Import data from a database option in the DataDriver Wizard. When you run your test, this function updates the data table with data from the database.
  28. How do you handle unexpected events and errors? - a) WinRunner uses exception handling to detect an unexpected event when it occurs and act to recover the test run.
    Define Exception Handling
    Define Exception
    Define Handler Function
    WinRunner enables you to handle the following types of exceptions:
    Pop-up exceptions: Instruct WinRunner to detect and handle the appearance of a specific window.
    TSL exceptions: Instruct WinRunner to detect and handle TSL functions that return a specific error code.
    Object exceptions: Instruct WinRunner to detect and handle a change in a property for a specific GUI object.
    Web exceptions: When the WebTest add-in is loaded, you can instruct WinRunner to handle unexpected events and errors that occur in your Web site during a test run.
  29. How do you handle pop-up exceptions? - a) A pop-up exception Handler handles the pop-up messages that come up during the execution of the script in the AUT. TO handle this type of exception we make WinRunner learn the window and also specify a handler to the exception. It could be
    i. Default actions: WinRunner clicks the OK or Cancel button in the pop-up window, or presses Enter on the keyboard. To select a default handler, click the appropriate button in the dialog box.
    ii. User-defined handler: If you prefer, specify the name of your own handler. Click User Defined Function Name and type in a name in the User Defined Function Name box.
  30. How do you handle TSL exceptions? - a) A TSL exception enables you to detect and respond to a specific error code returned during test execution.
    b) Suppose you are running a batch test on an unstable version of your application. If your application crashes, you want WinRunner to recover test execution. A TSL exception can instruct WinRunner to recover test execution by exiting the current test, restarting the application, and continuing with the next test in the batch.
    c) The handler function is responsible for recovering test execution. When WinRunner detects a specific error code, it calls the handler function. You implement this function to respond to the unexpected error in the way that meets your specific testing needs.
    d) Once you have defined the exception, WinRunner activates handling and adds the exception to the list of default TSL exceptions in the Exceptions dialog box. Default TSL exceptions are defined by the XR_EXCP_TSL configuration parameter in the wrun.ini configuration file.
  31. How do you handle object exceptions? - a) During testing, unexpected changes can occur to GUI objects in the application you are testing. These changes are often subtle but they can disrupt the test run and distort results.
    b) You could use exception handling to detect a change in property of the GUI object during the test run, and to recover test execution by calling a handler function and continue with the test execution
  32. How do you comment your script? - a) We comment a script or line of script by inserting a ‘#’ at the beginning of the line.
  33. What is a compile module? - a) A compiled module is a script containing a library of user-defined functions that you want to call frequently from other tests. When you load a compiled module, its functions are automatically compiled and remain in memory. You can call them directly from within any test.
    b) Compiled modules can improve the organization and performance of your tests. Since you debug compiled modules before using them, your tests will require less error-checking. In addition, calling a function that is already compiled is significantly faster than interpreting a function in a test script.
  34. What is the difference between script and compile module? - a) Test script contains the executable file in WinRunner while Compiled Module is used to store reusable functions. Complied modules are not executable.
    b) WinRunner performs a pre-compilation automatically when it saves a module assigned a property value of “Compiled Module”.
    c) By default, modules containing TSL code have a property value of “main”. Main modules are called for execution from within other modules. Main modules are dynamically compiled into machine code only when WinRunner recognizes a “call” statement. Example of a call for the “app_init” script:
    call cso_init();
    call( “C:\\MyAppFolder\\” & “app_init” );
    d) Compiled modules are loaded into memory to be referenced from TSL code in any module. Example of a load statement:
    reload (“C:\\MyAppFolder\\” & “flt_lib”);
    or
    load (”C:\\MyAppFolder\\” & “flt_lib”);
  35. Write and explain various loop command? - a) A for loop instructs WinRunner to execute one or more statements a specified number of times.
    It has the following syntax:
    for ( [ expression1 ]; [ expression2 ]; [ expression3 ] )statement
    i. First, expression1 is executed. Next, expression2 is evaluated. If expression2 is true, statement is executed and expression3 is executed. The cycle is repeated as long as expression2 remains true. If expression2 is false, the for statement terminates and execution passes to the first statement immediately following.
    ii. For example, the for loop below selects the file UI_TEST from the File Name list
    iii. in the Open window. It selects this file five times and then stops.
    set_window (”Open”)
    for (i=0; i<5;>
    list_select_item(”File_Name:_1?,”UI_TEST”); #Item Number2
    b) A while loop executes a block of statements for as long as a specified condition is true.
    It has the following syntax:
    while ( expression )
    statement ;
    i. While expression is true, the statement is executed. The loop ends when the expression is false. For example, the while statement below performs the same function as the for loop above.
    set_window (”Open”);
    i=0;
    while (i<5){
    i++;
    list_select_item (”File Name:_1?, “UI_TEST”); # Item Number 2
    }
    c) A do/while loop executes a block of statements for as long as a specified condition is true. Unlike the for loop and while loop, a do/while loop tests the conditions at the end of the loop, not at the beginning.
    A do/while loop has the following syntax:
    do
    statement
    while (expression);
    i. The statement is executed and then the expression is evaluated. If the expression is true, then the cycle is repeated. If the expression is false, the cycle is not repeated.
    ii. For example, the do/while statement below opens and closes the Order dialog box of Flight Reservation five times.
    set_window (”Flight Reservation”);
    i=0;
    do
    {
    menu_select_item (”File;Open Order…”);
    set_window (”Open Order”);
    button_press (”Cancel”);
    i++;
    }
    while (i<5);
  36. Write and explain decision making command? - a) You can incorporate decision-making into your test scripts using if/else or switch statements.
    i. An if/else statement executes a statement if a condition is true; otherwise, it executes another statement.
    It has the following syntax:
    if ( expression )
    statement1;
    [ else
    statement2; ] expression is evaluated. If expression is true, statement1 is executed. If expression1 is false, statement2 is executed.
    b) A switch statement enables WinRunner to make a decision based on an expression that can have more than two values.
    It has the following syntax:
    switch (expression )
    {
    case case_1: statements
    case case_2: statements
    case case_n: statements
    default: statement(s)
    }
    The switch statement consecutively evaluates each case expression until one is found that equals the initial expression. If no case is equal to the expression, then the default statements are executed. The default statements are optional.
  37. Write and explain switch command? - a) A switch statement enables WinRunner to make a decision based on an expression that can have more than two values.
    It has the following syntax:
    switch (expression )
    {
    case case_1: statements
    case case_2: statements
    case case_n: statements
    default: statement(s)
    }
    b) The switch statement consecutively evaluates each case expression until one is found that equals the initial expression. If no case is equal to the expression, then the default statements are executed. The default statements are optional.
  38. How do you write messages to the report? - a) To write message to a report we use the report_msg statement
    Syntax: report_msg (message);
  39. What is a command to invoke application? - a) Invoke_application is the function used to invoke an application.
    Syntax: invoke_application(file, command_option, working_dir, SHOW);
  40. What is the purpose of tl_step command? - a) Used to determine whether sections of a test pass or fail.
    Syntax: tl_step(step_name, status, description);
  41. Which TSL function you will use to compare two files? - a) We can compare 2 files in WinRunner using the file_compare function.
    Syntax: file_compare (file1, file2 [, save file]);

Winrunner interview

  1. What are the virtual objects and how do you learn them? - a) Applications may contain bitmaps that look and behave like GUI objects. WinRunner records operations on these bitmaps using win_mouse_click statements. By defining a bitmap as a virtual object, you can instruct WinRunner to treat it like a GUI object such as a push button, when you record and run tests.
    b) Using the Virtual Object wizard, you can assign a bitmap to a standard object class, define the coordinates of that object, and assign it a logical name.
    To define a virtual object using the Virtual Object wizard:
    i. Choose Tools > Virtual Object Wizard. The Virtual Object wizard opens. Click Next.
    ii. In the Class list, select a class for the new virtual object. If rows that are displayed in the window. For a table class, select the number of visible rows and columns. Click Next.
    iii. Click Mark Object. Use the crosshairs pointer to select the area of the virtual object. You can use the arrow keys to make precise adjustments to the area you define with the crosshairs. Press Enter or click the right mouse button to display the virtual object’s coordinates in the wizard. If the object marked is visible on the screen, you can click the Highlight button to view it. Click Next.
    iv.Assign a logical name to the virtual object. This is the name that appears in the test script when you record on the virtual object. If the object contains text that WinRunner can read, the wizard suggests using this text for the logical name. Otherwise, WinRunner suggests virtual_object, virtual_push_button, virtual_list, etc.
    v. You can accept the wizard’s suggestion or type in a different name. WinRunner checks that there are no other objects in the GUI map with the same name before confirming your choice. Click Next.
  2. H ow you created you test scripts 1) by recording or 2) programming? - a) Programming. I have done complete programming only, absolutely no recording.
  3. What are the two modes of recording? - a) There are 2 modes of recording in WinRunner
    i.Context Sensitive recording records the operations you perform on your application by identifying Graphical User Interface (GUI) objects.
    ii.Analog recording records keyboard input, mouse clicks, and the precise x- and y-coordinates traveled by the mouse pointer across the screen.
  4. What is a checkpoint and what are different types of checkpoints? - a) Checkpoints allow you to compare the current behavior of the application being tested to its behavior in an earlier version.
    You can add four types of checkpoints to your test scripts:
    i. GUI checkpoints verify information about GUI objects. For example, you can check that a button is enabled or see which item is selected in a list.
    ii. Bitmap checkpoints take a “snapshot” of a window or area of your application and compare this to an image captured in an earlier version.
    iii. Text checkpoints read text in GUI objects and in bitmaps and enable you to verify their contents.
    iv. Database checkpoints check the contents and the number of rows and columns of a result set, which is based on a query you create on your database.
  5. What is parameterizing? - a) In order for WinRunner to use data to drive the test, you must link the data to the test script which it drives. This is called parameterizing your test. The data is stored in a data table.
  6. How do you maintain the document information of the test scripts? - a) Before creating a test, you can document information about the test in the General and Description tabs of the Test Properties dialog box. You can enter the name of the test author, the type of functionality tested, a detailed description of the test, and a reference to the relevant functional specifications document.
  7. What do you verify with the GUI checkpoint for single property and what command it generates, explain syntax? - a) 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. To create a GUI checkpoint for a property value, use the Check Property dialog box to add one of the following functions to the test script:
    i. button_check_info
    ii. scroll_check_info
    iii. edit_check_info
    iv. static_check_info
    v. list_check_info
    vi. win_check_info
    vii. obj_check_info
    Syntax: button_check_info (button, property, property_value );
    edit_check_info ( edit, property, property_value );
  8. What do you verify with the GUI checkpoint for object/window and what command it generates, explain syntax? - a) You can create a GUI checkpoint to check a single object in the application being tested. You can either check the object with its default properties or you can specify which properties to check.
    b) Creating a GUI Checkpoint using the Default Checks
    i. 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.
    ii. To create a GUI checkpoint using default checks:
  9. 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. -
  10. Click an object. -
  11. 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 - Syntax: win_check_gui ( window, checklist, expected_results_file, time );
    c) Creating a GUI Checkpoint by Specifying which Properties to Check
    d) 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.
    e) To create a GUI checkpoint by specifying which properties to check:
    i. 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.
    ii. Double-click the object or window. The Check GUI dialog box opens.
    iii. Click an object name in the Objects pane. The Properties pane lists all the properties for the selected object.
    iv. Select the properties you want to check.
  12. To edit the expected value of a property, first select it. Next, either click the Edit Expected Value button, or double-click the value in the Expected Value column to edit it. -
  13. To add a check in which you specify arguments, first select the property for which you want to specify arguments. Next, either click the Specify Arguments button, or double-click in the Arguments column. Note that if an ellipsis (three dots) appears in the Arguments column, then you must specify arguments for a check on this property. (You do not need to specify arguments if a default argument is specified.) When checking standard objects, you only specify arguments for certain properties of edit and static text objects. You also specify arguments for checks on certain properties of nonstandard objects. -
  14. To change the viewing options for the properties of an object, use the Show Properties buttons. -
  15. Click OK to close the Check GUI dialog box. WinRunner captures the GUI information 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 or a win_check_gui statement. - Syntax: win_check_gui ( window, checklist, expected_results_file, time );
    obj_check_gui ( object, checklist, expected results file, time );

How to run Winrunner test scripts?

How to run Winrunner test scripts?
a) We 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.

Debugging winrunner Script?

Debugging winrunner Script?
We can debug the script by executing the script in the debug mode. We can also debug script using the Step, Step Into, Step out functionalities provided by the WinRunner.

How does WinRunner evaluates test results?

How does WinRunner evaluates test results?
a) 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. 

what is contained in the test scripts? ----Winrunner

what is contained in the test scripts? ----Winrunner Interview Questions
It contains the statement in Mercury Interactive’s Test Script Language (TSL). These statements appear as a test script in a test window. You can then enhance your recorded test script, either by typing in additional TSL functions and programming elements or by using WinRunner’s visual programming tool, the Function Generator.

How does WinRunner recognize objects on the application?

How does WinRunner recognize objects on the application?--Winrunner interview
a) WinRunner uses the GUI Map file to recognize objects on the application. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same properties in the application being tested. 


What is contained in the GUI map?--Winrunner

What is contained in the GUI map?--Winrunner interview question
a) WinRunner stores information it learns about a window or object in a GUI Map. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same properties in the application being tested. Each of these objects in the GUI Map file will be having a logical name and a physical description.
b) There are 2 types of GUI Map files.
i.Global GUI Map file: a single GUI Map file for the entire application
ii.GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.

WinRunner testing process?

WinRunner testing process? (Winrunner interview question and answers)
a) WinRunner testing process involves six main stages
i.Create GUI Map File so that WinRunner can recognize the GUI objects in the application being tested
ii.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.
iii.Debug Test: run tests in Debug mode to make sure they run smoothly
iv.Run Tests: run tests in Verify mode to test your application.
v.View Results: determines the success or failure of the tests.
vi.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.