KeywordBlock Element/en
Inhaltsverzeichnis
Introduction[Bearbeiten]
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").
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.
Rules[Bearbeiten]
All actions within the test suite can be used as keyword actions if they match the following criteria:
- 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 steps of a keyword action. Such virtual actions only describe the interface (pins and their datatypes) but leave the concrete 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, with input values being either constants, or been read from a variable. Output values being either ignored or written into a variable to be picked up by followup steps.
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 that generated by 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 can choose them to be either recorded as keyword actions or as regular compound actions. You should probably go directly for compound actions, if you plan to later 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 execution
- add branches or loops
