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: Test Recorder about Control Points - Check Points

1. Any checkpoints should not be a component of X & Y Co-ordinate dependant. In practical terms if there is a Check point that is defined on X,Y Parameters then the usability of the control point wouldn't make any sense for the application to test. The following are some of the criteria which denotes the do's and don't's of checkpoints.

2. As a case study, the WinRunner automation tool is mentioned here as examples for creating check points. Usage of OBJ_CHECK_INFO or WIN_CHECK_INFO can be avoided and inculcate the idea of creating always the GUI Check point with Multiple Property. The advantages are to identify every small object with its clause, properties and its relativity with the previous versions. This not only enables the Regression comparisons but also it gives you the flexibility of defining the GUI Checks in all Physical state of the Object.

Q: Test Recorder about Data Handlers

Test Data can be accessed by built-in data functions. Some of the common practices that would help a automation tester to use the data-tables in a proper fashion.
1. SINGLE DATA TABLE: By default every automation tool gives the data-table as an input file can be created using a tool wizard or sometimes potentially creating using a character-separated file. This wizard would help us in creating a Data sheet with its column names from the objects used in the test objects. With this concept, we can evolve a technique to load any File or manipulate the AUT by predefined set of cases.
2. Multiple Data Table: It's a common practice to use the single default data file for many test scripts. Often the usage of data tables is restricted to one file at a moment. Handling multiple data tables is not advisable and incur a lot of redundant code to handle the table manipulations. As a general practice the data file is mapped to every script. This mean every Test Script will have a unique data table for easier data access and also the data operation will become easy to maintain.
In Compuware's QARun following is the code used.

// Run a test script
TestData ("CreditLogon.csv")
Call TestFunc1

For e.g in Mercury Interactive's WinRunner,
call_close "Test_Script1" (dTable1.xls) ;
#
call_close "Test_Script2" (dTable2.xls);

3. Data files should be initialized before starting by way of simple tool commands by transferring a standard template data table to the actual template. By this practice the need of deleting data after every run in the data table can be avoided.
In Mercury Interactive's WinRunner the piece of code below explains the data table Initialization.
#/***************Data Table Initialization*****************
ddt_open(Template, DDT_MODE_READ);
ddt_open(dTable, DDT_MODE_READWRITE);
ddt_export(Template,dTable);
ddt_save(dTable);
ddt_close(dTable);
ddt_close(Template);
ddt_close_all_tables();
#/***************Data Table Initialization*****************

4. Dynamic loading of data from the Data base operation is the most advisable practice to be followed, but yet handling the db operations with some meticulous programming would always benefit the tester avoiding a variety of operational hazard and reducing the data access time for remote server database to the local data table.
Some of the tips, which need to be followed in the WinRunner TSL handling when we use the db commands.
Set the row before writing the data values in to the data-table.
i.e., Use the following TSL Command
public count;
count = 1;
ddt_set_row (dTable, count);
Now we use the set value by row command for writing the values in it
ddt_set_val_by_row (dTable, count, "CTS_EMP_NAME", value);
Need less to mention here, but to avoid confusion it is better to use the same column names as found in the Data Base table. And never insert any columns before or after or in between the column names in the WinRunner data table. It is a better practice to load the data table with the data as found in the Backend database.
Fig 1. shows the Automation Test Plan, its pre-requisites, Initial Conditions and the Test repository. This figure also gives the idea of building any Automation Test plan.

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