Mercury WinRunner FAQ

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39   40  41  42  43  44  45 

Q: Online Vs Batch Execution - Functions & Compiled Modules-Data Fetch
Should we open and read from data table in driver scripts? Why or why not?

The purpose of the driver script is to setup the application and then calls each individual scripts. To open, read and close the data-file should happen at the individual test script level.

Q: Online Vs Batch Execution - Functions & Compiled Modules - User Defined Functions
Creating user-defined libraries and functions: How to access if a script should be made a function - What are the pros and cons of making a script a function versus just using it as a script and calling it from the driver file?

You have to load the function library first before you are able to make a call out to any of the functions defined in a function library. Using User-defined function is more efficient in the sense that they are compiled and loaded into memory before a function is being called and a function can be used over and again without having to recompile the function library.

WinRunner: Test Director

• Test Director is a one-stop solution for organizing the entire test cycle.
• It has four main tabs(categories) corresponding to the various phases in the testing cycle namely Requirements, Test Plan, Test Lab and Defects.
• Requirements can be entered and organized into various categories like login operations, database operations and so on.
• After setting up requirements, test cases corresponding(covering) these requirements can be defined and associated with the requirements. A requirement can be covered by multiple test cases and a test case can cover multiple requirements.
• The test plan can be defined with test cases each with test steps and can be manual or automated.
• Test sets are created to group similar test cases and then the test sets can be run.
• If a particular test set fails the run, after examination, the tester/QA can enter a defect in the associated defect tracking system. Attributes such as severity can be assigned.
• Test Director allows two modes of operation - user and administrator. Administrator can create and update user and group accounts, configure mail, customize project lists, custom project entities and setup wokflow whereas the user doesn't have these privileges.
• The six project entities are Requirement, Test, Test Step, Test Set(Execution), Run and Defect.
• Test Director allows attachments(file, URL, snapshot) with requirements, test step, test case, test run or defect.
• Test Director is flexible and can be customized within certain limits. Additional fields can be added in requirements, test case, test step, test plan and defects.
• Test Director has what is known as favorite views wherein any view or report or graph can be made to look as the user wants it to. The user can make only certain columns viewable and make it a favorite view.
• Test Director also has filters to filter test cases, requirements, defects by any of the various attributes like severity, assigned to etc.
• Test Director also has an Exection Flow option which is used to schedule automated test cases.
• Work flow is setup by the administrator which includes creating Visual Basic modules to save data before entering a bug in a defect tracking system, to perform operations before opening a bug form, after a bug field is changed and so on.
• Test Director also a comprehensive document generator utility to develop professional reports for the testing process.
• Also reports and graphs corresponding to requirements, test plan, test lab and defects can be created.
• The host machine can also be configured while running the test sets.

WinRunner: Test Director - Test Repositories

. A separate test repository will be created for each groups project. The test repositories will be created as Common Directories and will be located on a network server (this area should be a shared area where the group stores the rest of their files and documents).
. Initially all test repositories will be created using a Microsoft Access Database. In the future we may change this to SQL Server.
. The path to the network area can not be more than 47 characters (A Test Director restriction).
. The path can not contain any special characters such as $,& -, or %.
. All folders that contain the test repositories should start with TD_ .
. All test repositories should start with TD_ .

TD_NameofProject
Reports - Created automatically by Test Director, this is where it stores results of tests etc.
Tests - This is where the test scripts will reside if use WinRunner also.
GUImap - This is where the GUI map files will reside
Datafile - This is where all data flat files and excel spreadsheets will reside
Docs - This is where copies of documents that pertain to this project will reside Fonts
- This is where a copy of the font groups will reside
Functions - This is where the function library for the project will reside.
. Within Test Director various folders can be created as a way to organize your project and tests. These folders are stored in the database and may or may not be apparent on the file system.
TD_NameofProject
FolderName - Folder for functional regression tests
SubFolder - Sub folder for Specific Window
FolderName - Folder for SC functional regression tests
. It is not recommended to nest the folders more than 3 levels deep.

WinRunner: Test Director - Steps to take before creating Test Projects:

. Before starting Test Director, you should close all applications that are not required for testing. (Mail, Explorer, Screen Savers, CD Player etc).
. After installing a new version of Test Director and WinRunner, it is a good idea to make a back up copy of the following ini files to another location(testers choice of location). This is recommended to allow the tester to easily reset their WinRunner/TestDirector environment in the event of system corruption.
c:\windows\wrun.ini
c:\windows\mercury.ini
c:\~\TestDirector\bin\td.ini
c:\~\TestDirector\bin\filters.ini
c:\~\TestDirector\bin\forms.ini
c:\~\TestDirector\bin\grids.ini

. Your Test Director Application comes with a full set of on-line manuals. The manuals can be accessed using the Help Menu in the Test Director application. The on-line manuals can be viewed using Adobe Acrobat Reader 4.0.

WinRunner: Test Director - Set Up Recommendations:

Before a tester starts creating folders and test scripts, they should configure their Test project using the Administration menu.
1. Create various Users and User Groups for your project through the Administration -> Setup Users… menu item. Test Director comes with the following Pre-defined users and groups. We recommend that you create a user id that is similar to your Network login. You also have the option to create a password or leave it blank. The default is blank. You can also create your own groups or use the default groups provided by Test Director.
Default Users and Groups:
Users:
. Admin
. Guest
Groups:
. TDAdmin Has full privileges in a TestDirector project. This is the only type of user which can make changes to the information in the Setup Users dialog box. It is recommended to assign this user type to one person per group who will serve as the TestDirector Administrator.
. QATester Can create and modify tests in Plan Tests mode, and create test sets, run tests, delete test runs, and report defects in Run Tests mode. This user type is recommended for a quality assurance tester.
. Project Manager Can report new defects, delete defects, and modify a defect's status. This user type is recommended for a project manager or quality assurance manager.
. Developer Can report new defects, and change a defect's status to Fixed. This user type is recommended for a software developer.
. Viewer Has read-only privileges in a project.
2. Test Director also give you the option to customize your projects by creating user-defined fields for the dialog boxes and grids, creating categories and modifying drop down lists. These options enable you to add information that is relevant to your project. Modification to your projects are done using the Administration -> Customize Project Menu item. For more details on how to customize your project please see Chapter 3 in the Test Director's Administrators Guide.
3. Decide on Script Naming Convention and consistently use the naming convention for all tests created within the project. Please reference the Naming Conventions section for more information.
4. Create Test Folders to organize your tests into various sections. Examples of possible folder(s) names could be the types of testing you are doing ie: (functional, negative, integration ) or you could base your folder names on the specific modules or windows you are testing.

5. Create test scripts on the Plan tests folder using the New button in the test frame or menu item Plan -> New Test. The Test window has four tabs, Details, Design Steps, Test script and attach.
The Details tab, should be used to list all the information regarding the test. Test Director defaults to displaying the Status: Design; Created: date and time; Designer: your id.
. The Design Steps Tab, should be used to list detail instructions on how to execute your test.
. The Test Script tab, is used for tests that are turned into automated tests, on this page the automated WinRunner code will appear.
. The Attach Tab, can be used to attach bitmaps or other files required for testing to the script.
6. When creating folders, tests and test sets in Test Director make sure every item has a description.
7. Create a "Documentation" test to document how to set up your testing environment and run your tests.
8. It is recommended that you write your test scripts as detailed as possible and not assume that the executor of your test "knows how to use your module". By making your scripts as detailed as possible, this will allow others from outside your project to understand how to execute your tests, in the event that they have to run the tests.
9. Create Test Sets to group like test together, or to specify the order in which your tests should run. Test director has a limit of 99 test scripts per test set.
10. Export the test scripts into word via the Document Generator, Menu item Report -> Document Generator.

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39   40  41  42  43  44  45