Handbuch

46.2
Beispiel

Die Beispieltestsuiten finden Sie in den Unterverzeichnissen demo/carconfigWpf und demo/carconfigForms des QF-Test Installationsverzeichnisses.

46.2.1
Start der Anwendung

Die Beispieltestsuiten verwenden für den Start der Anwendung die in der Standardbibliothek mitgelieferte Abhängigkeit SUT_started (SUT = System Under Test) aus dem Package qfs.autowin.dependencies.

Der Start der Demoapplikation wird über den Knoten

  • Shellkommando ausführen

angestoßen. Anschließend muss auf die Applikation gewartet werden, bevor die Tests abgespielt werden können:

Die Demo-Testsuite verwendet die Funktionalität des Abhängigkeit Knotens, womit sich die Testvor- und -nachbedingungen sehr effizient gestalten lassen. Ganz kurz zusammengefasst besteht die Funktionalität eines Abhängigkeit Knotens darin, dass er den darin enthaltenen Vorbereitung Knoten vor dem Start des Testfalls ausführt, damit die implementierte Vorbedingung hergestellt wird. Nach Ausführung des Testfalls wird der Aufräumen Knoten der Abhängigkeit standardmäßig nicht ausgeführt. Dies geschieht erst bei Bedarf bei der Ausführung des Abhängigkeit Knotens des nachfolgenden Testfalls. Der Bedarf ergibt sich dann, wenn der nachfolgende Testfall eine andere Abhängigkeit ruft oder dieselbe Abhängigkeit mit anderen charakteristischen Variablen. Weitere Informationen zu Abhängigkeiten finden Sie Tutorial sowie im Handbuch im Kapitel Abhängigkeit Knoten.

Weitere Informationen hierzu finden Sie in Abschnitt 46.1.1.

46.2.2
Übersicht über die GUI-Elemente der Anwendung

Wenn das SUT läuft, ist der nächste Schritt, dass man sich dessen GUI-Elemente anzeigen lässt. Im vorliegenden Fall wurde die Prozedur qfs.autowin.helpers.dumpComponents verwendet. Das Ergebnis wird in das QF-Test-Terminal geschrieben.

Wir wollen uns als nächstes für einige GUI-Elemente der WPF Demo-Anwendung die Informationen, die zur Identifikation zur Verfügung stehen, ansehen.

Abbildung 46.2:  Die WPF Demo-Applikation
Fenster (1)
Name: CarConfiguratorNet WPF
ClassName: Window
ControlType: Window (#50032)

Das Fenster kann über seinen Namen angesprochen werden, da kein weiteres GUI-Element diesen Namen verwendet.

Menü (2)
Name: Hilfe
ClassName: MenuItem
ControlType: MenuItem (#50011)
AutomationId: mHelp

Das GUI-Element kann über die eindeutige AutomationId oder seinen Namen angesprochen werden. Noch eine Alternative ist der ControlType oder ClassName "MenuItem" zusammen mit dem Namen oder dem Index "4".

Tabellenzelle (3)
Name: Rolo
ClassName: DataGridCell
ControlType: Custom (#50025)

Die Tabellenzelle kann über den Namen oder den ControlType zusammen mit dem Namen identifiziert werden. Wenn die Tabellenzelle über einen Index angesprochen werden soll, ist es besser, den ClassName anstelle des ControlType zu verwenden, weil der ControlType "Custom" auch für andere GUI-Elemente zum Einsatz kommt. Da bei der Entwicklung keine AutomationId vergeben wurde, steht diese nicht zur Verfügung.

Eingabefeld (4)
ClassName: TextBox
ControlType: Edit (#50004)
AutomationId: textBoxDiscountPrice

Das Eingabefeld kann über die AutomationId oder den ControlType zusammen mit dem Index 0 angesprochen werden.

Anzeigefeld (5)
Name: 12.300,00 €
ClassName: Text
ControlType: Text (#50020)
AutomationId: labelCalculatedPriceOutput

Neben der AutomationId und dem ControlType steht hier zwar auch ein Name zur Verfügung. Dieser eignet sich jedoch nicht zur Identifikation des GUI-Elements, da dieser je nach angezeigtem Text variiert.

46.2.3
Ausführen von Aktionen auf GUI-Elementen

In den Beispiel-Testsuiten finden sich zahlreiche Beispiele für Mausklick, Überprüfung des Textes, Überprüfung des Wertes (z.B. Testfallsatz "Modellpreise"), Warten auf Fenster, Texteingabe (z.B. Testfallsatz "Einstellungen") sowie die Selektion von Tabellen und Listenelementen mittels Index (Testfallsatz "Kalkulationen").

Manchmal lassen sich Eigenschaften von GUI Elementen nicht programmatisch ermitteln. Das folgende Beispiel erläutert, wie man den Aktivierungszustand des Menüeintrags "Fehlerhaft" im Menü "Hilfe" der Demo-Applikation auf andere Art prüfen kann.

Abbildung 46.3:  Hilfemenü

Bitte sehen Sie sich die Prozedur setzeFehlerhaft() im Package hauptfenster.menü in einer der beiden Beispieltestsuiten autowinDemoForms_de.qft oder autowinDemoWpf_de.qft an.

Um den Aktivierungszustand des Menüeintrags zu bestimmen verwendet die Prozedur setzeFehlerhaft() im Package hauptfenster.menü einen Abbild-Check.

Der eigentliche Check, ob "Fehlerhaft" angehakt ist, erfolgt in der Prozedur qfs.autoscreen.screen.getPositionOfImage. Wir interessieren uns zwar nicht für die Position des Häkchen, sehr wohl aber dafür, ob es überhaupt gefunden wird. Je nach dem wird entsprechend des Sollstatus der Menüpunkt angeklickt oder gelassen wie er ist.

Für den Bildvergleich benötigen wir eine Datei mit dem Abbild des Häkchens. Diese kann über ein zugeschnittes Bildschirmabbild erstellt werden. Alternativ können Sie die Prüfprozedur qfs.autoscreen.screen.getPositionOfImage zunächst mit einer beliebigen Bilddatei ausgeführen. Anschließend navigieren Sie im Protokoll zum fehlgeschlagenen Check, wechseln in die Ansicht "Erhaltenes Abbild" und speichern dieses dann ab. Dies hat den Vorteil, dass das Bild bereits auf den gewünschten Bildschirmausschnitt zugeschnitten ist.

Abbildung 46.4:  Fehlgeschlagener Image check im Protokoll

Die Prozedur getPositionOfImage() verwendet den Parameter "algorithm" mit "algorithm=similarity;expected=0.95". Dies hat den Hintergrund, dass sich Bilder auf unterschiedlichen Windows-Versionen leicht unterscheiden können, wodurch bei einem 100%-Vergleich das Häkchen nicht erkannt und die Prozedur falsch arbeiten würde.