Handbuch
Handbuch
 |  |  |  |  |  |  |  |
| Version 7.1.2 |
Falls die Entwickler für eine Komponente einen Komponentenbezeichner vergeben haben, erkennt QF-Test dies und verwendet diesen, wenn geeignet, für das Attribut 'Name'.
Wenn ein Wert für 'Name' gefunden wurde, wird dieser auch für die Generierung der 'QF-Test ID' der Komponente verwendet. Weitere Informationen finden Sie in Abschnitt 46.2, Beispiele hierzu in Wie erreicht man eine robuste Komponentenerkennung?.
Auch bei der Aufnahme von SmartIDs ist der 'Name' im Standard die erste Wahl.
Der Grund für den gewaltigen Einfluss eines guten Komponentenbezeichners ist die Tatsache, dass dieser die Wiedererkennung von Komponenten über lange Zeit und viele Änderungen hinweg zuverlässig ermöglicht. Eine Komponente zu finden, die einen eindeutigen Bezeichner besitzt, ist offensichtlich trivial. Ohne diese Hilfe verwendet QF-Test viele verschiedene Arten von Informationen, um eine Komponente zu lokalisieren. Der Algorithmus ist fehlertolerant und wurde fein abgestimmt, so dass er ausgezeichnete Ergebnisse erzielt. Und dennoch: Mit Ausnahme des Bezeichners kann sich jede Information zu einer Komponente ändern, wenn sich das SUT weiterentwickelt. Irgendwann, wenn größere Änderungen vorgenommen wurden oder sich mehrere kleinere Änderungen summiert haben, wird eine Komponente nicht mehr erkannt werden und ein manueller Eingriff vonnöten sein, um die Testsuite anzupassen.
Ein weiterer wichtiger Aspekt von Bezeichnern ist, dass sie das Testen von Applikationen, deren Oberfläche in verschiedene Sprachen übersetzt wird, von der aktuell eingestellten Sprache unabhängig macht, da der Bezeichner nur intern vergeben wird und nie übersetzt werden muss.
Die Automatisierung von Tests kann deutlich verbessert werden, wenn die Entwickler des SUT vorausgeplant haben oder bereit sind, durch Vergabe von Bezeichnern für zumindest einen Teil der Komponenten des SUT mitzuhelfen. Außerdem haben Bezeichner in der Testsuite eine sehr hohe Sichtbarkeit, da sie als Basis für die 'QF-Test ID' Attribute der 'Komponenten' dienen. Letzteres sollte nicht unterschätzt werden, speziell für Komponenten ohne besondere Merkmale. Knoten, die Text in Felder namens "textName", "textAddress" oder "textAccount" einfügen, sind wesentlich leichter zu verstehen und zu warten als solche für die Felder "text", "text2" oder "text3". Der koordinierte Einsatz von Bezeichnern ist einer der entscheidenden Faktoren für die Effizienz der Automatisierung und für die mit QF-Test erzielbaren Einsparungen. Sollte sich die Entwicklungsabteilung oder die Projektleitung trotz des minimalen Aufwands nicht mit der Vergabe von Bezeichnern anfreunden können, geben Sie ihnen einfach dieses Kapitel des Handbuchs zu lesen.
Falls Entwickler ein anderes, konsistentes Schema zur Vergabe von Bezeichnern eingesetzt haben, das QF-Test jedoch standardmäßig nicht erkennt, werfen Sie bitte einen Blick in Beeinflussen des 'Name' Attributs mittels NameResolver.
Wenn eindeutige 'Namen' ermittelt werden, können die Optionen Gewichtung von Namen (Wiedergabe) und Gewichtung von Namen (Aufnahme) auf "Name übertrifft alles" gesetzt werden, wodurch die Komponentenerkennung von der Komponentenhierarchie unabhängig und auf Grund des Name-Cachings maximale Performanz erreicht wird.
Um die Vergabe von Bezeichnern zu vereinfachen, bietet QF-Test eine Funktion, um Bezeichner für die Komponenten vorzuschlagen, für die ein Bezeichner das Testen verbessert. Näheres dazu finden Sie bei der Option Hotkey für Komponenten.
Hinweis
Änderungen von Bezeichnern in der zu testenden Applikation sollten
möglichst vermieden werden, da dies die Komponentenerkennung aushebelt
und eine Menge Nacharbeit in den Tests bedeuten kann. Bitte beachten
Sie, wenn dennoch Änderungen vorkommen werden, dass diese im
'Name' Attribut der Komponente nachgezogen werden und
nicht im 'QF-Test ID' Attribut, das nur der Referenzierung
der Komponente in den Tests dient! Eine weitere mögliche Schwierigkeit
kann sein, dass die Namensänderung direkt im Test in der Referenz
auf die Komponente erfolgt, zum Beispiel bei einem Mausklick im
Attribut 'QF-Test ID der Komponente'. Der Test schlägt dann mit einer
UnresolvedComponentIdException fehl.
Komponentenbezeichner werden in den unterschiedlichen UI-Technologien unterschiedlich genannt. Im Handbuch wird für sie auch der Begriff 'Name' verwendet. Außerdem sind die Kriterien, ob und wie die Bezeichner in das Attribut 'Name' übernommen werden, je nach Technologie leicht unterschiedlich.
Die folgenden Ausführungen gelten für die Standardeinstellungen der Optionen, insbesondere von Gewichtung von Namen (Wiedergabe) und Gewichtung von Namen (Aufnahme) (Standardwert: "Hierarchie von Namen"). Auch die Nutzung von Resolvern kann das beschriebene Verhalten verändern.
Der Komponentenbezeichner heißt hier ebenfalls 'Name'. Falls er gesetzt wurde, wird er
in das Attribut 'Name' übernommen. Wenn innerhalb eines Containers Komponenten
gleiche Bezeichner haben, legt QF-Test das 'Weiteres Merkmal'qfs:matchindex
mit einem entsprechenden Index für die Duplikate an.
Alle AWT und Swing Komponenten sind von der AWT Klasse
Component abgeleitet. Deren setName Methode ist daher der
Standard für Swing SUTs. Dank dieses Standards machen viele Entwickler auch unabhängig von
Plänen für eine Testautomatisierung davon Gebrauch, was eine große Hilfe ist.
Der Komponentenbezeichner heißt hier 'ID'. Falls er gesetzt wurde, wird er in das
'Name' Attribut übernommen. Wenn innerhalb eines Containers Komponenten
gleiche IDs haben, legt QF-Test das 'Weiteres Merkmal'qfs:matchindex mit einem entsprechenden Index für die Duplikate an.
Für JavaFx wird setId verwendet, um Namen für Komponenten (hier "Node" genannt) zu vergeben.
Alternativ können IDs mittels FXML über
das Attribut fx:id gesetzt werden. Obwohl
IDs von Knoten eindeutig sein sollen, wird dies nicht erzwungen.
Der Komponentenbezeichner heißt hier ebenfalls 'Name'. Falls er gesetzt wurde, wird er
in das 'Name' Attribut übernommen. Wenn innerhalb eines
Containers Komponenten gleiche Bezeichner haben, legt QF-Test das
'Weiteres Merkmal'qfs:matchindex mit einem
entsprechenden Index für die Duplikate an.
Leider hat SWT kein eigenes Konzept für die Vergabe von Namen. Eine
akzeptierte Konvention ist der Gebrauch der Methode setData(String key, Object
value) mit dem String "name" als Schlüssel und dem gewünschten Namen
als Wert. QF-Test wertet diese Daten - falls vorhanden - aus und verwendet sie als Namen für
die Komponenten. Mangels eines echten Standards für die Vergabe von Namen kommen diese in
SWT-Anwendungen inklusive Eclipse nur in Ausnahmefällen zum Einsatz.
Glücklicherweise kann QF-Test Namen für die Hauptkomponenten von Eclipse/RCP-Anwendungen aus
den zugrunde liegenden Modellen ableiten, was zu guten Ergebnissen führt, vorausgesetzt es
wurden IDs für diese Modelle vergeben. Weitere Details finden Sie bei der Beschreibung der
Option
Automatische Namen für Komponenten in Eclipse/RCP-Anwendungen.
Der naheliegende Kandidat für den Bezeichner eines DOM-Knotens ist sein 'id' Attribut, nicht zu verwechseln mit dem 'QF-Test ID' Attribut von QF-Test's 'Komponente' Knoten. Leider erzwingt der HTML-Standard keine Eindeutigkeit von IDs. Außerdem sind 'id' Attribute ein zweischneidiges Schwert, da sie eine wichtige Rolle bei den internen JavaScript Operationen einer Web-Anwendung spielen können. Daher ist es zwar nicht unwahrscheinlich, dass 'id'-Attribute vergeben wurden, sie können aber nicht so frei definiert werden wie Bezeichner in anderen Technologien. Zu allem Übel müssen viele DHTML und Ajax Frameworks IDs automatisch generieren, was diese als Namen ungeeignet macht.
Glücklicherweise können Komponentenbezeichner über unterschiedliche Attribute des GUI-Elements realisiert werden. Meist ist es das Attribut 'id', manchmal auch 'name' - aber auch andere Attribute können genutzt werden.
Die Option Attribut 'ID' als Name verwenden falls "eindeutig genug" bestimmt, ob QF-Test 'id'-Attribute als Namen verwendet oder nicht. Bitte beachten Sie, dass die Option Alle Ziffern aus 'ID'-Attributen eliminieren bewirken kann, dass ursprünglich eindeutige Bezeichner nach Löschung der Ziffern nicht mehr eindeutig sind. Bei der Prüfung, ob der ermittelte 'Name' eindeutig genug ist, wird die Hierarchie, in der die Komponente liegt, für die Bestimmung der Eindeutigkeit mit herangezogen, wenn für die Optionen Gewichtung von Namen (Wiedergabe) und Gewichtung von Namen (Aufnahme) der Standardwert "Hierarchie von Namen" gesetzt.
Die automatisch generierten 'id'-Attribute enthalten
manchmal einen statischen Teil, der als Bezeichner genutzt werden kann. Dies kann
über die Konfigurationskategorie autoIdPatterns, siehe
Der 'CustomWebResolver installieren' Knoten, konfiguriert werden.
Außerdem kann in dieser Prozedur über die Kategorie customIdAttributes auch
jedes andere HTML-Attribut als Komponentenbezeichner genutzt werden.
Im Falle einer Webapplikation, welche ein von QF-Test unterstütztes Komponentenbibliothek verwendet, können Sie einen Blick in Abschnitt 49.2.2 werfen, um mehr über das Setzen eindeutiger Bezeichner für das jeweilige Toolkit zu erfahren.
Der Komponentenbezeichner heißt hier 'AutomationId'. Falls er gesetzt wurde, wird er
in das 'Name' Attribut übernommen. Wenn innerhalb eines Containers
Komponenten gleiche Bezeichner haben, legt QF-Test ein 'Weiteres Merkmal' mit dem Namen
qfs:matchindex und einem entsprechenden Index für die Duplikate an.
qfs:matchindex und einem entsprechenden Wert für die Duplikate an.
Es gibt eine kritische Anforderung für Bezeichner: Sie dürfen sich nicht im Lauf der Zeit
ändern, nicht von einer Version der SUT zur nächsten, nicht von einem Aufruf zum anderen
und nicht während der Ausführung des SUT, z.B. wenn eine Komponente zerstört und später
neu erstellt wird. Ist ein Bezeichner einmal vergeben, muss er Bestand haben. Leider gibt es
kein automatisches Schema zur Vergabe von Bezeichnern, das diese Anforderungen erfüllt. Solche
Systeme erstellen Bezeichnern meist aus dem Bezeichner der jeweiligen Klasse und einem laufenden
Index, was unweigerlich fehlschlägt, da der Bezeichner dann von der Reihenfolge der Erstellung
der Komponenten abhängt. Da Bezeichner eine so zentrale Rolle bei der Erkennung von Komponenten
spielen, können unzuverlässige Bezeichner, insbesondere automatisch generierte, sehr negative
Effekte haben. Falls die Entwickler nicht überzeugt werden können, derartige Bezeichner durch
eindeutige, stabile zu ersetzen, oder sie zumindest wegzulassen, können solche Bezeichner mit Hilfe
eines NameResolver unterdrückt werden. Weitere Informationen hierzu finden
Sie in Abschnitt 52.1.7.
Es ist für die Arbeit mit QF-Test nicht nötig, Bezeichner flächendeckend zu vergeben. Allzu ausgiebiger Gebrauch kann sogar kontraproduktiv sein, da QF-Test ein eigenes Konzept dafür hat, ob eine Komponente "interessant" ist oder nicht. Uninteressante Komponenten werden wegabstrahiert und können so bei einer Änderung keine Probleme verursachen. Typische Beispiele für solche Komponenten sind Panels, die nur für Layout-Zwecke eingebaut werden. Eine Komponente mit nicht trivialem Bezeichner gilt für QF-Test immer als interessant, so dass die Benamung von unwichtigen Komponenten zu Problemen führen kann, wenn diese in einer späteren Version aus der Hierarchie entfernt werden.
Auch müssen Bezeichner nicht global eindeutig vergeben werden. Jede Klasse von Komponenten bildet einen eigenen Namensraum, so dass es keinen Konflikt gibt, wenn ein Textfeld und ein Button den selben Bezeichner haben. Außerdem genügt es, wenn die Bezeichner innerhalb einer Anzeige eindeutig sein - sie brauchen also nicht applikationsweit eindeutig zu sein (außer bei Web-Applikationen). Andererseits ist der Optimalfall hinsichtlich stabiler Komponentenerkennung in den Regressionstests, wenn die Bezeichner applikationsweit eindeutig sind. Dann können Sie die Optionen Gewichtung von Namen (Wiedergabe) und Gewichtung von Namen (Aufnahme) auf "Name übertrifft alles" setzen, die flexibelste Einstellung zur Wiedererkennung von Komponenten.
Zwei Fragen sind noch offen: Welche Komponenten sollten Bezeichner erhalten
und was sind eigentlich gute Bezeichner? Eine gute Daumenregel ist es,
allen Komponenten, mit denen ein Anwender direkt interagieren kann,
einen Bezeichner zu geben, also Knöpfen, Textfeldern, etc. Komponenten, die
nicht direkt erzeugt werden, sondern automatisch als Elemente von
komplexen Komponenten, brauchen keinen Bezeichner. Dies sind z.B. die
Listenelemente einer ComboBox. Die komplexe Komponente selbst (im Beispiel
also die ComboBox) sollte
dagegen sehr wohl einen Bezeichner haben.
Falls Bezeichner für Komponenten nicht von Anfang an vergeben wurden und die Entwickler nur den
geringstmöglichen Aufwand spendieren wollen, diese zur Verbesserung der
Testautomatisierung nachzuziehen, hat sich folgende Strategie als guter Kompromiss
erwiesen: Fenster, komplexe Komponenten wie Bäume und Tabellen, sowie Panels, die eine
Anzahl von Komponenten zu einer Art Formular zusammenfassen, sollten einen Bezeichner erhalten.
So lange Struktur und Geometrie der Komponenten in solchen Formularen einigermaßen
konstant sind, führt dies zu einer guten Wiedererkennung und brauchbaren 'QF-Test ID'
Attributen. Probleme durch individuelle Komponenten mit wechselnden Eigenschaften können
von Fall zu Fall behandelt werden, entweder indem entwicklungsseitig nachträglich ein Bezeichner
vergeben wird, oder mit Hilfe eines NameResolver.
In unterschiedlichen Applikationen kommen unterschiedlichste Namenskonzepte für Komponenten zum Einsatz. Nicht in allen Fällen liefern sie stabile Bezeichner, die für Regressionstests sinnvoll genutzt werden können: beispielsweise, wenn die Komponenten keine Bezeichner haben oder Bezeichner existieren, die sich aber von Zeit zu Zeit ändern, z.B. zeichnen Sie einen 'button1' beim ersten Mal auf und beim nächsten Mal heißt dieser Button plötzlich 'button2'. Eine andere Variante könnte sein, dass die aktuelle Versionsnummer des SUT im Bezeichner des Hauptfensters steckt.
Manchmal kennen die Tester jedoch einen Algorithmus, um
eindeutige Namen zu setzen.
In solchen Fällen sollten Sie sich
Das NameResolver Interface
im Kapitel Das resolvers Modul genauer anschauen.
Ein NameResolver kann verwendet werden, um Bezeichner aus der QF-Test Sicht zu ändern oder zu löschen. Diese Änderungen treffen dann nur für die QF-Test Sicht zu und ändern nichts am aktuellen Sourcecode.
Sie sollten über den Einsatz von NameResolver nachdenken, wenn:
Wenn Sie eine Eindeutigkeit pro Fenster erreichen (bei Web für alle Seiten), können Sie darüber nachdenken die Optionen Gewichtung von Namen (Wiedergabe) und Gewichtung von Namen (Aufnahme) auf "Name übertrifft alles" zu setzen.
Hinweis Wenn es möglich ist, dass die Entwickler eindeutige und stabile Bezeichner direkt vergeben, dann sollten es diese im Quellcode tun, da die Entwickler am besten wissen, welche Komponenten angelegt werden. Das Implementieren eines NameResolvers kann eine sehr aufwendige und mühsame Aufgabe sein, besonders wenn sich das GUI stark ändert.
NameResolver sind in Abschnitt 52.1.7 beschrieben.
| | | | | | | Letzte Änderung: 13.3.2024 Copyright © 1999-2024 Quality First Software GmbH |
