KeywordBlock Element/en
A keyword driven test is defined by a sequence of test steps, each of which consists of a keyword (the test action, such as "click" or "input"), a number of optional input parameters ("what to input"), possible validations ("what should be shown") and possibly forwarding information for any values ("remember field contents in $foo"). In being a subset of the full activity diagram (with a different presentation), such a sequence can of course also be represented as a sequential list of steps (only connected by enable-output/enable-input connections).
The keyword driven test action description can be used to define simple sequential test or test step sequences. The sequence is defined in tabular format, which some users prefer over full blown activity diagrams.
Inhaltsverzeichnis
Rules[Bearbeiten]
All actions within the test suite can be used as "keyword" actions if they match the following rules:
- They either have no input/output pins or only input/output pins with one of the following data types: String, Number or Boolean.
Keyword driven test action descriptions can be mixed up in a compound action description with all other action descriptions without any limitation.
Virtual vs. Concrete Keywords[Bearbeiten]
Many keyword driven test frameworks allow for the keywords to be used as symbolic references, where the actual action can be specified/changed for a concrete run. For example, a specification for a dialog interface or filling of a forms dialog may want to only name "click", "field check" etc. and leave the concrete implementation open. Thus allowing for the same spec to be used for multiple UI technologies (Swing, SWT or even Web interface).
In expecco, this is done by placing Virtual Actions as the steps of a keyword action. Such virtual actions only describe the interface (pins and their datatype) but leave the implementation open. A concrete action implementing that interface will be chosen and executed at test time.
Execution and Logging[Bearbeiten]
During execution each action is executed one after the other. Be careful with blocks which produce more than one datum at a single output pin. In that case the data stored in a connected variable is the last value written to the output pin. Also any defined assertion will be executed only for the last written value.
The log and report format is equal to compound blocks.
Converting[Bearbeiten]
Keyword driven test action descriptions can be converted to compound action descriptions. Compound action descriptions can be converted to keyword driven test actions only if they have no parallel steps, loops or branches. Connections between steps are converted to environment variables as data holders.
Recording[Bearbeiten]
When recording GUI interactions, you have the option of either importing them as keyword actions or as regular compound actions. You should probably go directly for compound actions, if you plan to modify the recorded sequence in order to:
- parametrize recorded values to be read from a pin or environment variable
- add additional value checks (input field must show particular value from a database or similar)
- add partial automation (automate the login sequence, but still manually run through the rest of the interactive session)
- add parallel action
- add branches or loops
