Please find the sample test-suites in the subdirectories
demo/carconfigForms of the QF-Test
|Starting the application|
The sample test-suites use the dependency
in the package
qfs.autowin.dependencies of the standard library
to start the demo application.
actually starts the demo. The
waits for the demo application to appear before passing on control to the test-case itself.
The demo test-suite makes use of the dependency functionality which enables you to manage the set up and clean up requirements of your tests very efficiently. In short, in a test-case the dependency functionality runs the setup node before passing control to the test-case, thus making sure that the requirements implemented in the setup node are met before running the test-case. At the end of the test-case, the cleanup node is not executed by default. Only in the next test-case it may be executed if required by the dependency of that test-case, either because it calls a different dependency or the characteristic variables of the dependency have changed. For more information about dependencies please refer to the tutorial or the manual, chapter Dependency nodes.
For general information on the start of a native windows application please refer to subsection 28.1.1.
|GUI element information|
The next step after starting the SUT is to get an overview of the GUI elements
of the application. In this example we will use the procedure
qfs.autowin.helpers.dumpComponents. The output
will be written to the QF-Test terminal.
In the following we will have a look at the output of dumpComponents() for some of the GUI elements of the WPF demo application.
||Figure 28.2: The WPF demo application|
This shows a typical set of identifiers for the window itself. You can address it via its name, which seems to be unique.
This GUI element has an AutomationId. Use this to identify the GUI element unambiguously. Of course, you may also use its name 'Help' or the ControlType (or ClassName) 'MenuItem' along with the index '4'.
The table cell can either be addressed by its name or by the ControlType along with the name. If you want to address the table cell via an index it would make sense to use the ClassName and not the ControlType as the same ControlType 'Custom' is used for non table cells as well. An AutomationId has not been implemented.
The input field can be addressed via the AutomationId or the ControlType or ClassName along with the index 0.
Use the AutomationId to identify the GUI element as the name varies according to the text displayed.
Please find general information in subsection 28.1.2.
|Performing actions on the GUI elements|
In the demo test-suites you will find numerous examples for mouse clicks, checks of texts, values (e.g. in the test-set 'Model prices'), wait for window, text input (e.g. in the test-set 'Options') and the selection of table and list items via index (test-set 'Calculations'). In the following we explain the check of the status of a GUI element as this is somewhat more complex than the actions mentioned before.
Sometimes you cannot determine the properties of a GUI Element by program. In the following we will show you how to check the activation state of the menu item 'Buggy' in the menu 'Help' in a different way.
The job is to check whether the menu item 'Buggy' in the 'Help' menu is ticked.
||Figure 28.3: Help menu|
Please have a look at the procedure
setBuggy in the package
mainwindow.menu of one of the demo test-suites
In order to find out whether
the tick mark is set for the menu item or not we resort to an image check.
First we need to determine the area on the screen for which to execute the
image check. To this end we use the procedure
which returns a string containing
the values for the x and y coordinates of the top left corner as well as the
width and the height of the menu item. We use a script to separate the
values and assign them to variables.
The actual check whether the menu item 'Buggy' has
a tick mark is done via the procedure
We are not interested in the
position of the tick mark within the GUI element. However, we are interested
in whether it finds it at all. So, depending on whether the procedure finds
the tick mark (it throws an exception when the image of the tick mark is not found)
and the given state the menu item then is either clicked or left
as it is.
We need a file with a reference image of the tick mark for the procedure
One way to create the file with the image of the tick mark as a reference is
to take a screenshot, cut out the tick mark and saved it to file.
Alternatively you could execute the procedure
qfs.autoscreen.screen.getPositionOfImage with an
arbitrary image file as input and then navigate to the failed check in the
QF-Test run-log. There change to the view 'Got image'
and save the image. The advantage is that the image will be cut to the correct
||Figure 28.4: Failed Image check in the run-log|
You may have noticed that the procedure getPositionOfImage() is run with a parameter algorithm=similarity;expected=0.95. The reason for this is that images tend to differ slighlty on different windows versions. And therefore a check for 100 % identity of the tick mark might fail even though the tick mark showed.
|Last update: 03/19/2019
Copyright © 1999-2019 Quality First Software GmbH