|
|
|
|
|
System architecture |
|
Test structure |
|
Test organisation |
|
Test development (exercise) |
|
|
|
|
Test suite |
|
Test set |
|
Test case |
|
Test block |
|
Test primitive |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Name |
|
mandatory |
|
unique |
|
short (recommended) |
|
Description |
|
optional but recommended |
|
Testsequence |
|
mandatory |
|
entries separated by Alt-Return |
|
IDX |
|
all rows with direct access must be indexed |
|
|
|
|
|
The test mode is the mean of instructing the
test scripts what actions to perform with the given data. |
|
|
|
SET |
|
instruction to set (enter) the content of an
object |
|
CHK |
|
instructs framework to verify the content of an
object |
|
ATR |
|
instructs framework to verify the attributes of
an object |
|
GEN |
|
instructs framework to generate the test data
from the content of an object |
|
|
|
|
The scope of a test mode is a block |
|
SET is the default mode
(i.e. assumed if undefined) |
|
must be defined for each test case in the row
that defines the block name |
|
|
|
|
|
It is possible to instruct the Framework to
temporarily “leave” the current sequence, execute something else and resume
the sequence. |
|
|
|
LINK |
|
instruction to execute an arbitrary test case
(Framework) |
|
CALL |
|
instruction to execute an arbitrary WinRunner
main test |
|
EVAL |
|
instruction to execute an arbitrary WinRunner
function |
|
|
|
Branching is one of the most important concepts
of EMOS Framework. |
|
|
|
|
|
|
|
|
|
LINK |
|
|
|
LINK~<test driver>~[<data
table>]~<test name> |
|
|
|
CALL |
|
|
|
CALL~<test path>[~<test
parameter>]... |
|
|
|
EVAL |
|
|
|
EVAL~<function>[;<function>]... |
|
where |
|
<function> = <function name>([<arg>][,<arg>]...) |
|
|
|
|
|
|
System architecture |
|
Test structure |
|
Test organisation |
|
Test development (exercise) |
|
|
|
|
Building test suites |
|
Building test sets |
|
Bundling suites |
|
Analysing test results |
|
Integration with TestDirector |
|
|
|
|
|
Use test suites to group tests for some purpose |
|
regression suite |
|
smoke test |
|
thorough module test |
|
etc. |
|
|
|
|
Use other columns to define additional
information |
|
|
|
|
Keep test suites stable! |
|
Do not change them often during development |
|
Keep them read-only (i.e. version control) |
|
Use temporary suites during development |
|
re-direct kickoff to your suite by setting an
environment variable (see kickoff script) |
|
|
|
|
Test set is technically a single line in test
suite |
|
A technical necessity to simplify the suite
tables |
|
Use hyphen for numeric ranges (e.g. 1-5 ) |
|
Use comma for discontinuous ranges (e.g.
1,5-9,abc,xxx) |
|
Non-numeric names are OK (e.g. xxx) |
|
You can build ranges within a name space (xxx1-2
= xxx1,xxx2) |
|
|
|
|
Test suites can be easily bundled into huge test
systems |
|
A simple way to do this is to call them from a
batch test |
|
|
|
|
The test results are associated with the kickoff
script |
|
Test results are detailed and designed to
simplify debugging/evaluation |
|
Designed to look the same in interactive and in
batch mode |
|
Level of detail can be tuned: set_debug()
(see
startup test) |
|
|
|
|
The best overview of what has been tested, what
tests passed, what test failed can be found in the report associated with
the test emos_testsuite_
driver |
|
|
|
|
Use filters to customise the report |
|
|
|
|
Set “Mismatches only” to quickly locate errors |
|
|
|
|
System architecture |
|
Test structure |
|
Test organisation |
|
Test development (exercise) |
|
|
|
Notizen