EMOS Framework
Table Patterns
|
|
This paper discusses approaches for interfacing GUI table objects from within EMOS Framework.
The startegies dor data modelling have been presented in the familiar design pattern format.
Context
A test needs to manipilate (enter/check) GUI table objects. This test is to be designed with
EMOS Framework technique. The table objects are accessible form WinRunner either via
tbl_get/set functions or via direct cell manipulation such as edit_set, list_select_item,
etc.
Problem
How to model test blocks in data tables so that testing of such objects with EMOS
Framework is possible and appealing. Following the EMOS Framework philosophy of
test primitives it seem that table objects correspond to a single cell in a data table.
This makes modelling of such objects difficult because a single Excel cell does not
provide a feasible interface to all operations that are eventually necessary to test the
table content.
Forces
- The solution should result in a layout of test data that follows the look & feel of
EMOS Framework style.
- For the above reason the solutions via CALL and EVAL instructions are generally
seen as inattractive.
- The solution should consider the fact that the number and type of operations on
the same table object might signifficantly vary from test to test.
Solution
In fact there are two solutions. One is more suitable for testing tables in their entirety
and/or for testing (bigger) contiguous parts of such tables. The other solution is more
suitable for situations where small(er) number of possibly discontiguous table cells need
to be tested in each test case.
a) Testing entire tables
Testing entire tables can be achived by combyning two (or more) EMOS Framework data tables.
First data table is the "standard", vertically oriented, data table that defines the test
sequence by executing test blocks one after the other in the usual manner. In this table
special test blocs are created in which links to the other data table can be specified.
For example in the following table test "1" enters the data in some table and test "2"
checks the enterred data.
firstTable.xls
| IDX |
NAME |
1 |
2 |
| x |
Testsequence |
standard block
special block |
standard block
special block |
| x |
standard block |
|
CHK |
| |
prim1 |
some data |
some data |
| x |
special block |
|
CHK |
| |
secondTable.xls |
test1 |
test1 |
| |
<<END>> |
|
|
Note the "<<END>>" in the last row. This indicates that the function responsible for
processing "special block" is capable of processing more than one instruction (i.e. row). One could,
for example, enter a new line between "secondTable.xls" and "<<END>>" which refers to
some third table. This change would not require any change in test code.
thirdTable.xls
| IDX |
NAME |
1 |
2 |
3 |
| x |
test1 |
~E~editCol |
~R~rButtonCol |
~L~listCol |
| |
#1 |
some data |
ON |
some item |
| |
#2 |
some data2 |
OFF |
some item2 |
| |
#3 |
some data3 |
ON |
some item3 |
| |
#3 |
<<clear>> |
OFF |
<<clear>> |
| |
<<END>> |
|
|
|
Note how columns and rows are identified. This feature depends on the possibilities
that are available to WinRunner for accessing each individual table. In the above
example we are obviously dealing with table that contains different types of cells
(in fact this was taken from an application created with Oracle Designer).
The solution depends on how the underlying function is implemented. In our case "E"
means "edit field", "R" means "radio button" and "L" means drop down list.
Rows are in this case indentified via index (e.g. "#1").
Note again how "<<END>>" has been used to dynamically define end of the
test block. Note also that EMOS libraries (not part of the standard distribution)
support other methods of accessing table cells which are not demonstrated here.
"secondTable.xls" is not an "ordinary" data table (e.g. no "Testsequence" row is present).
Note however that the same mechanisms (IDX, Name) are used to implement this new strategy.
In fact EMOS Framework does not force "ordinary" data tables at all. With a bit of skill
EMOS Framework can be "degenerated" to work on ordinary ddt-tables or databases
(i.e. row-oriented).
b) Testing individual table cells
Some tests require only manipulation of a small part of GUI tables. In this case the
aforementioned solution proves cumbersome and havy-weighted. In this case we need the
solution that can be implanted straight into the data table (i.e. firstTable.xls).
The solution must also be felxible enough so that the same test block can be used to
specify different actions for different tests (i.e. columns).
The solution is to "invent" the language for actions on single table cells. This language
must be powerful enough to execute most of the required operations on different cell
types (e.g. edit cels, display cells, button cells, list cells, etc.) while at the
same time "slim" enough to fit into a single Excel cell (i.e. test primitive).
Additionally, a mechanism for dynamic extension of the test block must be implemented.
This mechanism must guarantee that insertion/deletion of rows within the test block
do not require code modification. We will again use the "<<END>>" mechanism
introduced above.
Imagine the following data table:
firstTable.xls
| IDX |
NAME |
1 |
2 |
| x |
Testsequence |
standard block
special block |
standard block
special block |
| x |
standard block |
|
CHK |
| |
prim1 |
some data |
some data |
| x |
special block |
|
CHK |
| |
|
~S~col1=abc~col1 |
~D~col1=abc~col2~222~~EXACT |
| |
|
~D~<LAST>~col2~222 |
~:E~#3~#5~xxx~{class:edit,location:1} |
| |
|
+D+<LAST>+col3+333 |
~:P~#3~#6~item1 |
| |
|
~DCHK~<LAST>~<LAST>~[0-9]* |
|
| |
<<END>> |
|
|
The test "1" will do the following on the table which has been associated
with "special block" function:
- (~S~col1=abc~col1) selects the cell identified with the (first) row that contains
"abc" in column "col1" and column named "col1" via tbl_set_selected_cell
- (~D~<LAST>~col2~222) enters "222" in the cell identified by the
last row used and column "col2" via tbl_set_cell_data
- (+D+<LAST>+col3+333) enters "333" in the cell identified by the
last row used and column "col3" via tbl_set_cell_data; note the different separator
- (~DCHK~<LAST>~<LAST>~[0-9]*) forces checking (note that we are
in SET mode) for numeric content of the last cell enterred
Test "2" does the following:
- (~D~col1=abc~col2~222~~EXACT) checks for the exact match on "222"
via tbl_get_cell_data() + match()
- (~:E~#3~#5~xxx~{class:edit,location:1}) checks the content (via edit_check_text)
of the second edit field which pop up dynamically after double-clicking
(i.e. tbl_activate_cell) on row #3 col #5
- (~:P~#3~#6~item1) checks that item "item1" is selected (via list_check_selected)
in a cell that contains a drop-down list cell that is created dynamically after
activating the cell in row 3 column 6
- empty cell demonstrates that amount of actions on the table objects may
vary from test to test
Example
The following Excel tables show some realistic examples of table testing with EMOS Framework.
The GUI of the applications that these examples have been taken from are very table-oriented
(i.e. way above 50% of information is shown with table objects).
a) Testing entire tables
An Oracle Developer example.
b) Testing individual table cells
A Java (Swing) example.
Known Uses
The shown tests are just a few examples of what can/must be done with individual
table cells. EMOS has several low-level libraries tuned vor different environments
such as Java, Oracle, StingRay, Visual Basic, SAG Natural. The following link
shows the API interface of one such library AUT_TBL_lib.
Pay the special attention to function AUT_tbl_cell_action() which describes the
syntax of the "EMOS Framework table language". Note as well that this is an excerpt
from the coplete project documentation so some links will not work.
| WinRunner is registered trademark of Mercury Interactive Corporation |
© 2003, EMOS Computer Consulting GmbH |
| |
www.emos.de |