UserInteraction
Aus ExpeccoWiki
Inhaltsverzeichnis |
Motivation
Often, interaction with the user who runs the test is required via a GUI. Even in an automated test setup, such interaction may be useful, for example to tell an operator to pull a plug, to enter a parameter or simply to look at the screen and perform some check, which is hard to be done by a program (for example, see if the layout "looks" OK, or similar "intelligent choices").
Existing Blocks for Simple Interaction
For very simple interaction, the standard library provides some blocks in the "GUI-Dialogs" folder:
The "Confirm", "Information" and "Warning" blocks will open a dialog box and
simply wait for the user to press a button to proceed.
The "Confirm" block provides a true/false information and shows both "OK" and "Cancel" buttons. The others only show a single "OK" button.
Here is a code fragment, to ask the operator to turn off the power of some device in order for a fail-safe recovery test:
The others are obvious: they allow for a string, password or filename to be entered. The password block will not show the entered text.
Make your own GUI Blocks (PRO version only)
The expeccoPRO version includes a powerful GUI-construction tool. This enables you to define your own arbitrarily complex GUIs. The current version (1.6.0) supports modal GUI blocks, which pop up a dialog-interface when the activity is triggered, and close the window, when either an external close event arrives (at the close input pin) or via user interaction. These are called "Elementary GUI Blocks". Starting with version 1.8, another form of GUI called "Compound GUI Blocks" will be released. These are completely controlled by an activity diagram, and can even show animations or real-time data.
The following example demonstrates how a form-dialog using an elementary GUI block can be constructed. The goal is to present a textual list of choices, a radio-button list and a few other checkbox-choices in a modal box, for a user to make a choice and confirm.
First, create a new GUI block (press: 
) and define its external interface as:
Notice, that some of the input and output pins share a common name. This is only allowed for elementary UI blocks, and specifies that a pin value is used both to fill a value into a UI-component AND to be eventually read out of the UI component and sent to the blocks output pin (for example, to provide an initial value for an input field).
Next, navigate to the UI-tab, and click on the UI-editor icon. A standard UI-Painter will appear. Drag and drop the components as required into the UI canvas window, to get a look similar to:
Then, for each UI-widget component, select it, navigate to the "Basics" section, and change the name of the pin which provides/receives the widget's value. This can be done by typing the pin name into the input field named "model" or simply by pulling its menu, which shows a list of all pin names.
At the end, all model and list values have been specified, and the completed GUI looks like:
Notice that the listView component has two model aspect values: one which is to provide the list contents (the "list" aspect) and another, which holds the selected element (the "model" aspect).
Now, we are ready to place this block into an activity diagram:
Because these blocks are handled just like any other activity, you can of course provide input values from any other data source (freeze, environment, or another block). Also, the outputs (which provide the values of the fields, when the user clicks on "OK") are usually fed forward to other blocks for further processing. When executed, you get the following dialog to appear,
and the execution monitor shows the pin data as:
Where do I use this ?
These Dialog-like elementary GUI blocks are very useful if the test suite needs additional parameters or values from an operator. For example, if there are some measurement values to be entered manually (because you do not have an interface, but need a human to read it). Such user interaction is especially useful in semi-automatic testing, where some manual testing/validation is to be integrated into an otherwise automatic test. A concrete example of our own past is a web-site checker, which asked the test-operator questions like "Please rate the overall design of the page" or similar.
[more to be added soon]
Back to Examples.
