Handbuch
Handbuch
 |  |  |  |  |  |  |  |
| Version 7.1.3 |
Auch wenn man sie oft gar nicht bemerkt - zumindest bis die
erste ComponentNotFoundException auftritt - sind die
Komponenten das Herz einer Testsuite, denn die stabile Erkennung
von Komponenten ist die zentrale Herausforderung an ein gutes GUI Testtool.
Um das meiste kümmert sich QF-Test automatisch selbst, jedoch erfordern
manche Situationen manuelle Definitionen oder Eingriffe.
Deshalb ist das Verständnis von Komponenten und deren Abbildung und Behandlung
in QF-Test sehr wichtig. Die Grundlagen sollen in diesem Kapitel erläutert werden.
Das Video 'Komponentenerkennung' erläutert
zunächst die Wiedererkennungskriterien für Komponenten. Danach (ab Minute 13:07)
werden generische Komponenten
erläutert, zuerst solche mit regulären Ausdrücken, danach solche mit Variablen für die
Wiedererkennungsmerkmale.
Es gibt zwei Videos, die die Behandlung einer ComponentNotFoundException
ausführlich erklären:
Das Video 'Die Explosion der Komplexität in der Web Testautomatisierung eindämmen' zeigt eindrucksvoll den Umgang von QF-Test mit tief geschachtelten DOM-Strukturen.
Video-Mitschnitt des Spezialwebinars 'Komponentenerkennung'.
Aktionen, die der Anwender auf den Komponenten eines GUI ausführt, werden von QF-Test in Events umgewandelt. Jeder Event hat eine Zielkomponente. Für einen Mausklick ist das die Komponente unter dem Mauszeiger, für einen Tastendruck die Komponente, die den Tastaturfokus (keyboard focus) besitzt. Wenn QF-Test einen Event aufzeichnet, nimmt es zusätzlich Informationen über die Zielkomponente auf, so dass der Event später wieder für die gleiche Komponente abgespielt werden kann.
Die Wiedererkennung von Komponenten ist einer der komplexesten Teile von QF-Test. Der Grund dafür liegt in der Notwendigkeit, mit einem gewissen Grad an Veränderungen zurechtzukommen. QF-Test ist als Werkzeug für die Durchführung von Regressionstests ausgelegt. Wird eine neue Version des SUT getestet, sollten bestehende Tests idealerweise unverändert durchlaufen. Folglich muss sich QF-Test an ein möglicherweise geändertes GUI anpassen können. Würden z.B. die "OK" und "Abbrechen" Knöpfe vom unteren Rand der Detailansicht nach oben verschoben, würde QF-Test Events für diese Knöpfe immer noch korrekt wiedergeben. Das Ausmaß an Änderungen, an die sich QF-Test anpassen kann, hängt von den zur Verfügung stehenden Wiedererkennungskriterien ab. An dieser Stelle kann die Entwicklung häufig mit relativ geringem Aufwand einen großen Beitrag zur Erstellung robuster Regressionstests leisten.
Für die Komponentenerkennung stehen die folgenden Kriterien zur Verfügung:
Die Kriterien fließen mit unterschiedlicher Gewichtung in die Wiedererkennung ein. Herausragende Bedeutung haben die Klasse und der Komponentenbezeichner. Bei letzteren kann die Entwicklung einen großen Beitrag zur Teststabilität beitragen (siehe Wie erreicht man eine robuste Komponentenerkennung?). Weitere Informationen siehe Gewichtung der Wiedererkennungsmerkmale bei aufgenommenen Komponenten.
Die Wiedererkennungsinformationen werden von QF-Test entweder in 'Komponente'-Knoten abgespeichert oder direkt in den Eventknoten als SmartID eingetragen. In 'Komponente'-Knoten versus SmartID erfahren Sie, was für welches Anwendungsgebiet besser geeignet ist.
Standardmäßig zeichnet QF-Test 'Komponente'-Knoten auf.
Es gibt auch Komponenten, die QF-Test relativ zu einer übergeordneten Komponente adressiert. Dazu gehören zum Beispiel Tabellenzellen, Listeneinträge, Baumknoten, Icons in Buttons oder eine Checkbox in einer Tabellenzelle.
Dafür verwendet QF-Test besondere Adressierungsformen. In Unterelemente: Adressierung relativ zur übergeordneten Komponente wird dieses Thema ausführlich behandelt.
Außerdem bietet QF-Test die Möglichkeit Geltungsbereich (Scope) zu definieren, um Aktionen (Mausklick, Eingabe, Check) auf darin enthaltene Komponenten zu beschränken.
| | | | | | | Letzte Änderung: 23.4.2024 Copyright © 1999-2024 Quality First Software GmbH |
