DB - Check ("List1.cdl", "DBVFL") : "Default - XLS"

1.
Data Base Checkpoints:

Checks the contents of the data bases in different versions of the
application.
Compares current data base data to expected data base data.
Ways to create to query:
a. Microsoft Query
b. ODBC Query (manual)
c. Data Junction
2. Types of Standard Data Base Checkpoints

a. Default (checks the entire contents of the result set)
b. Custom(checks the partial contents, no of rows, no of columns of result set)
Db_check(“list1.cdl”, “dbvfl”);
list1.cdl – checklist containing information about the database and properties to
check.
Dbvfl – results file
c. Runtime Record Check
db_record_check ( ChecklistFileName , SuccessConditions, RecordNumber );
ChecklistFileName: The file contains information about the data to be captured
During the test run and its corresponding field in the database.
(Have .cvr extension)
SuccessConditions: Contains one of the following values:
DVR_ONE_OR_MORE_MATCH: The checkpoint passes if one or more
matching
database records are found.
DVR_ONE_MATCH: The checkpoint passes if exactly one matching
database record is found.
DVR_NO_MATCH: The checkpoint passes if no matching
database
records are found.
RecordNumber: An out parameter returning the number of
records in the database.
Note: Checklist can be edited in (Create > Edit Data Base Checklist). After editing, the
test should be executed in ‘Update’ mode before running in the ‘Verify’ mode.
3. Steps to convert a test to a Data Driven Test:

a. Creating a data table containing values for the parameters
b. Adding statements to read the data from the data table
c. Adding statements to open and close the data table
d. Assigning a variable name to the data table
4. Statements created using Data Driver Wizard:

table = "default.xls";
rc = ddt_open(table, DDT_MODE_READ);
if (rc!= E_OK && rc != E_FILE_OPEN)
pause("Cannot open table.");
ddt_get_row_count(table,table_RowCount);
for(table_Row = 1; table_Row <= table_RowCount; table_Row ++)
{
ddt_set_row(table,table_Row);
}
ddt_close(table);
5. Statements created using Data Driver Wizard on importing data from the data base:
rc = ddt_open(table, DDT_MODE_READWRITE);
ddt_update_from_db(table, "msqr1.sql", out_rows_count);
ddt_save(table);
{
}
ddt_close(table);
6. Example for creating Data Driver Wizard:

Statements selected to create a data table:
set_window ("ThunderRT6FormDC_1", 2);
list_select_item ("ThunderRT6ComboBox_13", "KGH -173");
password_edit_set("ThunderRT6TextBox_2", "gz");
button_press ("OK_1");
The below screen is displayed.
Statements created after creating Data Driver Wizard:
{
}
ddt_close(table);
Statements created on selecting the option ‘An existing column’:

{
list_select_item ("ThunderRT6ComboBox_13",
ddt_val(table,"ThunderRT6ComboBox_1"));
password_edit_set("ThunderRT6TextBox_2", ddt_val(table,"ThunderRT6ComboBox_1"));
}
ddt_close(table);
Statements created on selecting the option ‘A new column’:

{
ddt_val(table,"ThunderRT6ComboBox_11
password_edit_set("ThunderRT6TextBox_2",
ddt_val(table,"ThunderRT6TextBox_12"));
}
ddt_close(table);
Statements created on selecting the option ‘Automatically’ in ‘Parameterise the test’:

{

ddt_val(table,"ThunderRT6ComboBox_131"));
password_edit_set("ThunderRT6TextBox_2",
ddt_val(table,"ThunderRT6TextBox_21"));
}
ddt_close(table);
Statements created on selecting the option ‘Import data from data base’:
rc = ddt_open(table, DDT_MODE_READWRITE);
ddt_update_from_db(table, "msqr1.sql", out_rows_count);
ddt_save(table);
{
}
ddt_close(table);
Parameterize the test:

a. Line by line:
Opens the wizard screen for each line of the selected test script, which enables to decide
whether to parameterize line, and if so, whether to add a new column to the data table or
use an existing column when parameterizing data.
b. Automatically:
Replaces all the data with ddt_val statements and adds new columns to the data table.
7. Synchronizing the Test Run:

Application do not respond to the user input with the same speed from one test run to
another. A synchronization point instructs Winrunner to suspend running the test until the
application being tested is ready, and then to continue the test.
8. Types of Synchronization:
a. Object/Window Synchronization: When want Winrunner to wait for an object/window to
appear.
b. Property value Synchronization: When want Winrunner to wait for an object/window to
have a specific property. (wait_info such as button_wait_info, list_wait_info,
edit_wait_info)
c. Bitmap Synchronization: When want Winrunner to wait for a bitmap of an
object/window or an area of a screen. (Win_wait_bitmap, obj_wait_bitmap)
9. GUI map Mode:

a. GUI map file per test mode: Winrunner automatically creates a new GUI map file for
every new test created and automatically saves and open the GUI map file corresponding
to the test.
b. Global GUI map file mode: Single GUI map can be used for a group of test. Need to
save the information Winrunner learns about the properties in a GUI map file and must
load the appropriate GUI map file.
10. Recording Modes:

a. Context Sensitive Mode: Records the operations in terms of the GUI objects in the
applications. Identifies each object clicked and the type of operations performed on it.
Used when the application contains GUI objects.
b. Analog Mode: Records the exact coordinates traveled by the mouse, as well as the
mouse clicks and the keyboard input. Used when the application contains bitmap areas.
11. TSl functions related to data base connection and query:

a. db_connect: creates a new database session and establishes a connection to an ODBC
database.
Syntax:
db_connect ( session_name, connection_string );
session_name: The logical name of the database session.
connection_string: The connection parameters to the ODBC database.
b. db_disconnect: disconnects from the database and ends the database session.
Syntax:
db_disconnect ( session_name );
c. db_execute_query: executes the query based on the SQL statement and creates a
record set.
Syntax:
db_execute_query ( session_name, SQL, record_number );
SQL: The SQL statement.
record_number: An out parameter returning the number of records in the result query.
d. db_get_field_value: returns the value of a single field in the database.

Syntax:
db_get_field_value ( session_name, row_index, column );
row_index: The index of the row written as a string: "# followed by the numeric index.
(The first row is always numbered "#0".)
column: Either the name of the field in the column, or the index of the column
within the database written as a string: "# followed by the numeric index.
(The first column is always numbered "#0".)
e. db_get_headers: returns the number of column headers in a query and the content of
the column headers, concatenated and delimited by tabs.
Syntax:
db_get_headers ( session_name, header_count, header_content );
header_count: The number of column headers in the query.
header_content:The column headers concatenated and delimited by tabs. Note that if this
string exceeds 1024 characters, it is truncated.
f. db_get_row: returns the content of the row, concatenated and delimited by tabs.
Syntax:
db_get_row ( session_name, row_index, row_content );
row_index: The numeric index of the row. (The first row is always numbered "0".)
row_content: The row content as a concatenation of the fields values, delimited by
tabs.
g. db_record_check: compares information that appears in the application under test

during a test run with the current values in the corresponding record(s) in your database.
Syntax: above
h. db_write_records: writes the record set into a text file delimited by tabs.
Syntax:
db_write_records ( session_name, output_file [ , headers [ , record_limit ] ] );
output_file: The name of the text file in which the record set is written.
Headers: An optional Boolean parameter that will include or exclude the column
headers from the record set written into the text file.
record_limit: The maximum number of records in the record set to be written into the
text file. A value of NO_LIMIT (the default value) indicates there is no
maximum limit to the number of records in the record set.
12. TSL functions related to Data Table created using Data Driver Wizard:
a. ddt_open: creates or opens a data table 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). When the
mode is not specified, the default mode is DDT_MODE_READ.
b. 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.
c. ddt_get_current_row: retrieves the active row of a data table.
Syntax:
ddt_get_current_row ( data_table_name, out_row );
full path and file name of the table. The first row in the file
out_row: The output variable that stores the active row in the data table.
Note: When the data table is first opened, the active row is row 1.
d. 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.
e. ddt_get_row_count: retrieves the number of rows in a data table.

Syntax:
ddt_get_row_count ( data_table_name, out_rows_count );
contains the names of the parameters.
out_rows_count: The output variable that stores the total number of rows in the
data table.
f. ddt_is_parameter: returns whether a parameter in a data table is valid.

Syntax:
ddt_is_parameter ( data_table_name, parameter );
Parameter: The parameter name to check in the data table.
g. ddt_next_row: changes the active row in a data table to the next row.
Syntax:
ddt_next_row ( data_table_name );
Note: If the active row is the last row in a data table, then the E_OUT_OF_RANGE value
is returned.
h. ddt_report_row: reports the active row in a data table to the test results.
Syntax:
ddt_report_row ( data_table_name );
i. ddt_save: saves the information in a data table.

Syntax:
ddt_save ( data_table_name );
full path and file name of the table.
j. ddt_set_row: sets the active row in a data table.

Syntax:
ddt_set_row ( data_table_name, row );
Row: The new active row in the data table.
Note: When the data table is first opened, the active row is the first row.
k. ddt_set_val: sets a value in the current row of the data table.

Syntax:
ddt_set_val ( data_table_name, parameter, value );
Parameter: The name of the column into which the value will be inserted.
Value: The value to be written into the table.
l. ddt_setval_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 );
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.
m. ddt_show: shows or hides the table editor of a specified data table.

Syntax:
ddt_show ( data_table_name [ , show_flag ] );
show_flag: The value indicating whether the editor should be shown
(default=1) or hidden (0).
n. ddt_update_from_db: imports data from a database into a data table.

Syntax:
ddt_update_from_db ( data_table_name, file, out_row_count [ , max_rows ] );
File: Either an *.sql file containing an ODBC query or a *.djs file
containing a conversion defined by Data Junction.
out_row_count: An out parameter containing the number of rows retrieved from
the database.
max_rows: An in parameter specifying the maximum number of rows to be
retrieved from a database. If no maximum is specified, then by
default the number of rows is not limited.
Note: If the number of rows in the data table exceeds the number of rows in the
database, the extra rows in the data table will be erased.
o. ddt_val: returns the value of a parameter in the active row in a data table.
Syntax:
ddt_val ( data_table_name, parameter );
Parameter: The name of the parameter in the data table.
p. 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 );
row_number: The number of the row in the data table.
Parameter: The name of the parameter in the data table.
q. 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.
r. ddt_close_all_tables: closes all open tables.

Syntax:
ddt_close_all_tables();
13. GUI Checkpoint:

Examines the behaviour of an object’s properties.
a. GUI checkpoint > For Single Property: Checks for a single property of an object
(edit_check_info, button_check_info)
b. GUI checkpoint > For object/window: Checks for multiple properties of an

object/window
Syntax:
obj_check_gui ( object, checklist, expected_results_file, time );
compares current GUI object data to expected data.
object: The logical name of the GUI object. The object may belong to
any class.
Checklist: The name of the checklist defining the GUI checks.(have .ckl
extension)
expected_results_file: The name of the file that stores the expected GUI data.
Time: The interval, which is added to the timeout test option, marking
the maximum delay between the previous input event and the
capture of the current GUI data, in seconds. This interval is
added to the timeout test option during the test run.
c. GUI checkpoint > For Multiple objects: Checks for multiple properties of multiple
Objects
Syntax:
win_check_gui ( window, checklist, expected_results_file, time );
compares current GUI data to expected GUI data for a window.
window: The logical name of the window.
Checklist: The name of the checklist specifying the checks to perform.
expected_results_file:The name of the file storing the expected GUI data.
Time: The time is added to the timeout test option to give the
maximum interval between the previous input even and
the screen capture.
Note: Checklist can be edited in (Create > Edit GUI Checklist). After editing the checklist, the
test should be executed in ‘Update’ mode before running in the ‘Verify’ mode.
14. Bitmap Checkpoint:

Compares captured bitmap images pixel by pixel.
a. Bitmap Checkpoint > For object/window: Checks for the bitmap areas of an
object/window
Syntax:
obj_check_bitmap: compares an object bitmap to an expected bitmap
obj_check_bitmap ( object, bitmap, time);
object: The logical name of the GUI object. The object may belong to any class.
Bitmap: A string expression that identifies the captured bitmap.
Time:The interval, which is added to the timeout_msec testing option, marking
the maximum delay between the previous input event and the capture of
the current bitmap, in seconds during the test run.
b. Bitmap Checkpoint > For Screen Area:

Syntax:
obj_check_bitmap ( object, bitmap, time [, x, y, width, height] );
x, y: For an area bitmap: the coordinates of the upper left corner, relative to
the window in which the area is located.
width, height: For an area bitmap: the size of the area, in pixels.
15. Get Text > From Object/Window, From Screen Area
16. WinRunner Test Run Modes:

a. Verify Mode:
Used when needed to check the behavior of the application and when
needed to save the test results.
WinRunner compares the current response of the application with the
expected response. After running the test, Test Results window is
opened by default.
b. Debug Mode:
Used when needed to check that the test scripts runs smoothly without
errors in syntax.
Same as Verify mode except that the debug results are stored in always
saved in the ‘Debug’ folder. Test Result window does not open
automatically.
c. Update Mode:
Used when we want to create new expected results for a GUI
checkpoint/Bitmap checkpoint/Data Base checkpoint.
17. Which screen will be opened when the WinRunner cannot identify an object during the
test run?
A Run Wizard will be opened with a hand icon to show the corresponding object, and the
test can be continued.
18. Merging of GUI Files:

This is especially useful, if have been working in ‘GUI map file per test mode’ and when
to start working in the ‘Global GUI map file mode’. It is also useful when want to combine GUI
map files while working in ‘Global GUI map file mode’.
The GUI map file merge tool enables to merge multiple GUI map files into a single GUI
map file. Before merging, atleast two source GUI map files to merge should be specified and
atleast one GUI map file as a target file. Target GUI map file can be an existing GUI map file or a
new empty file.
Merging Modes:
a. Auto Merge
The merge tool merges the files automatically. If conflict exists between the
merging files, the conflicts are highlighted and prompted to resolve them.
b. Manual Merge:
GUI objects have to be added to the target file manually. The merge tool does not
highlight conflicts between the files.
In both the modes, the merge tool prevents from creating the conflicts while
merging the files.
19. Steps in changing the ‘GUI map file per test mode’:
a. Merging the GUI files.
b. Modify the test to load the appropriate the GUI files.
c. Click the ‘Global GUI Map File’ in the ‘GUI Map File Mode’ box in the
‘Environment’ tab of the ‘General’ options dialog box.
20. What is a custom object?

A custom object is any object not belonging to one of the standard classes used by
WinRunner.
21. Steps in Configuring the GUI map:

a. Mapping a custom object to a Standard Class.
b. Configuring a Standard or Custom Class.
22. Default properties learned by WinRunner:

a. Obligatory (always learned)
b. Optional (used when the obligatory properties do not provide unique
identification of an object
c. Selector (used when both obligatory and optional do not provide unique
identification of an object)
Types:
i) Locator selector uses spatial position of objects
ii) Index selector uses a unique number to identify objects in a window
23. Recording methods available during Configuration of GUI maps:

a. Record
Instructs WinRunner to record all operations performed on GUI object, which is
the default method.
b. Pass up
Instructs WinRunner to record an operation performed on this class as an
operation performed on the element containing the object.
c. As Object
Instructs WinRunner to record all operations performed on a GUI object as
though its class were ‘object’ class.
d. Ignore
Instruct WinRunner to ignore all operations performed on this class.
1. What is Astra Load Test?

Astra Load Test is Mercury Interactive fast and simple tool for load testing
Web based applications. It allows to test the web site by running multiple
virtual users (VUsers) on a workstation.
2. What is a Scenario?
A scenario defines the events that occur during each Web testing session,
such as the number of users, the pages they visit, and the operations that
you want to measure. A scenario can contain hundreds or thousands of
VUsers in multiple tests.
3. Components of the Astra Load Test System:

Virtual User Recorder, Controller, Analysis, and Remote Command
Launcher.
Virtual User Recorder:
The Virtual User Recorder creates tests by capturing Web traffic
generated when navigating a Web application.
Controller:
The Controller allows hundreds or thousands of virtual users to be directed from a single
machine. When you run a scenario, the Controller distributes the Vusers in the scenario
to a load generator machine. There may be one or more load generators in a single
scenario and multiple Vusers per load generator machine. The load generator is the
machine that executes the test, enabling the Vuser to emulate the steps of a human user.
Analysis:
The Analysis is launched at the conclusion of a load test and contains graphs,
spreadsheets and reports that can be examined to identify performance issues,
benchmark performance and establish baselines for regression comparisons.
4. Validating a Basic Test:

After creating a test, validate it in the Virtual User Recorder. This enables to check it for
errors before incorporating it into a scenario.
Validation Modes:
a. Debug Mode:
Test is run in a browser and full debugging capabilities are provided. At the
conclusion of a test run in Debug mode a report opens detailing the results.
b. Load Mode:
Runs the test as if it were part of a load scenario in the Controller. A test that
passes the Load replay will always run successfully in the Controller. At the
conclusion of a test run in Load mode, details of any error are shown in the Log
Viewer.
5. Mention the Scenario Types:

a. Goal Oriented Scenario
b. Manual Scenario
if((sex=="Female") && (maritalstatus=="Married"))

{
edit_set("ThunderRT6TextBox_19", "2"); #children
edit_set("ThunderRT6TextBox_18", "3.5"); #age of last child
edit_set("ThunderRT6TextBox_17", "2"); #no of pregnancy
list_select_item("ThunderRT6ComboBox_11","Yes"); #Family Planning
}
else if((sex=="Male") && (maritalstatus=="Married"))
{
edit_set("ThunderRT6TextBox_19", "2"); #children
edit_set("ThunderRT6TextBox_18", "3.5"); #age of last child
list_select_item("ThunderRT6ComboBox_11","Yes"); #Family Planning
}
-----------------------------------------------------------------------------------------
if(AvailableDate =="" && FromTime =="" && ToTime =="")
{
set_window ("ThunderRT6FormDC", 5);
obj_get_text("Date Time_0", FromDate, 4, 3, 59, 16);
Day=substr(FromDate,1,2);
Month=substr(FromDate,4,2);
Year=substr(FromDate,7,4);
Date=Day&Month&Year;
obj_type ("FPSpreadADO.fpSpread.2",Date);
obj_mouse_click ("FPSpreadADO.fpSpread.2", 221, 45, LEFT);
obj_type ("FPSpreadADO.fpSpread.2","0");
obj_type ("SPR32A30Time","900am");
obj_mouse_drag ("FPSpreadADO.fpSpread.2", 293, 47, 293, 48, LEFT);
obj_type ("SPR32A30Time","530pm");
button_press ("Save");
# KGH FRONT OFFICE

set_window ("KGH FRONT OFFICE", 3);
button_press ("OK");
# ThunderRT6FormDC
button_set ("Referring", ON);
obj_type ("Referring","<kTab>");
button_press ("...");
# LOOK UP - Front Office

set_window ("LOOK UP - Front Office", 16);
edit_set ("ThunderRT6TextBox_0", ReferringDoctor);
set_window("ThunderRT6FormDC", 1);
obj_get_text("FPSpreadADO.fpSpread.2", RAvailableDate, 42, 26, 160, 47);
obj_get_text("FPSpreadADO.fpSpread.2", RFromTime, 162, 25, 259, 48);
obj_get_text("FPSpreadADO.fpSpread.2", RToTime, 257, 25, 355, 50);
if(RAvailableDate =="" && RFromTime =="" && RToTime =="")
{
# ThunderRT6FormDC
obj_get_text("Date Time_0", RFromDate, 1, 2, 61, 19);
Rday=substr(RFromDate,1,2);
Rmonth=substr(RFromDate,4,2);
Ryear=substr(RFromDate,7,4);
Rdate=Rday&Rmonth&Ryear;
obj_type ("FPSpreadADO.fpSpread.2",Rdate);
# KGH FRONT OFFICE
}
else
{
# ThunderRT6FormDC
}
# ThunderRT6FormDC
button_press ("Cancel");
# Front Office
set_window ("Front Office", 0);
button_press ("Yes");
}
else
{
# ThunderRT6FormDC
# ThunderRT6FormDC
button_set ("Referring", ON);
obj_type ("Referring","<kTab>");
button_press ("...");
# LOOK UP - Front Office

set_window ("LOOK UP - Front Office", 16);
edit_set ("ThunderRT6TextBox_0", ReferringDoctor);
set_window("ThunderRT6FormDC", 1);
obj_get_text("FPSpreadADO.fpSpread.2", RAvailableDate, 42, 26, 160, 47);
obj_get_text("FPSpreadADO.fpSpread.2", RFromTime, 162, 25, 259, 48);
obj_get_text("FPSpreadADO.fpSpread.2", RToTime, 257, 25, 355, 50);
if(RAvailableDate =="" && RFromTime =="" && RToTime =="")
{
# ThunderRT6FormDC
obj_get_text("Date Time_0", RFromDate, 1, 2, 61, 19);
Rday=substr(RFromDate,1,2);
Rmonth=substr(RFromDate,4,2);
Ryear=substr(RFromDate,7,4);
Rdate=Rday&Rmonth&Ryear;
obj_type ("FPSpreadADO.fpSpread.2",Rdate);
# KGH FRONT OFFICE
}
else
{
# ThunderRT6FormDC
}
# ThunderRT6FormDC
# Front Office
}
------------------------------------------------------------------------------------------------
# Checks whether OP New Patients exist
# If OP New Patients does not exist
if(win_exists("Front Office")==E_OK)
{
report_msg("No OP New Patients");
}
# If OP New Patients Exist
else
{
tbl_get_rows_count("MSFlexGridLib.MSFlexGrid.1",New);
start_transaction("OPNew");
button_set ("Review", ON);
end_transaction("OPNew");
{
}
else
{
}
report_msg("Total OP New Patients="&New);
}

button_set("Review",OFF);
button_set ("Review", ON);
# Checks whether OP Review Patients exist
# If OP Review Patients does not exist
{
set_window ("KGH Front Office", 0);
report_msg("No OP Review Patients");
}
# If OP Review Patients Exist
else
{
tbl_get_rows_count("MSFlexGridLib.MSFlexGrid.1",Review);
start_transaction("OPReview");
set_window ("KGH Front Office", 0);
end_transaction("OPReview");
report_msg("Total OP Review Patients="&Review);
}
# Checks whether the OP count is equal in OP View and OP New/Review View

if((Review+New)==OPPatients)
{
report_msg("Total OP Patients="&OPPatients);
report_msg("Total OP Count is Correct which equals New and Review");
}
else
{
report_msg("Total OP Count is not Correct which does not equal New and Review");
}

DB - Check ("List1.cdl", "DBVFL") : "Default - XLS"

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

DB - Check ("List1.cdl", "DBVFL") : "Default - XLS"

Caricato da

Copyright:

Formati disponibili

1.

Data Base Checkpoints:

2. Types of Standard Data Base Checkpoints

3. Steps to convert a test to a Data Driven Test:

4. Statements created using Data Driver Wizard:

6. Example for creating Data Driver Wizard:

Statements created on selecting the option ‘An existing column’:

Statements created on selecting the option ‘A new column’:

Statements created on selecting the option ‘Automatically’ in ‘Parameterise the test’:

set_window ("ThunderRT6FormDC_1", 2);

Parameterize the test:

7. Synchronizing the Test Run:

9. GUI map Mode:

10. Recording Modes:

11. TSl functions related to data base connection and query:

d. db_get_field_value: returns the value of a single field in the database.

g. db_record_check: compares information that appears in the application under test

d. ddt_get_parameters: returns a list of all parameters in a data table.

e. ddt_get_row_count: retrieves the number of rows in a data table.

f. ddt_is_parameter: returns whether a parameter in a data table is valid.

i. ddt_save: saves the information in a data table.

j. ddt_set_row: sets the active row in a data table.

k. ddt_set_val: sets a value in the current row of the data table.

l. ddt_setval_by_row: sets a value in a specified row of the data table.

m. ddt_show: shows or hides the table editor of a specified data table.

n. ddt_update_from_db: imports data from a database into a data table.

q. ddt_close: closes a data table file.

r. ddt_close_all_tables: closes all open tables.

13. GUI Checkpoint:

b. GUI checkpoint > For object/window: Checks for multiple properties of an

14. Bitmap Checkpoint:

b. Bitmap Checkpoint > For Screen Area:

15. Get Text > From Object/Window, From Screen Area

16. WinRunner Test Run Modes:

18. Merging of GUI Files:

20. What is a custom object?

21. Steps in Configuring the GUI map:

22. Default properties learned by WinRunner:

23. Recording methods available during Configuration of GUI maps:

1. What is Astra Load Test?

3. Components of the Astra Load Test System:

4. Validating a Basic Test:

5. Mention the Scenario Types:

if((sex=="Female") && (maritalstatus=="Married"))

# KGH FRONT OFFICE

# LOOK UP - Front Office

# LOOK UP - Front Office

set_window ("ThunderRT6FormDC", 4);

# Checks whether the OP count is equal in OP View and OP New/Review View

Potrebbero piacerti anche