Name

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 44.2, Beispiele hierzu in Wie erreicht man eine robuste Komponentenerkennung?.

Auch bei der Aufnahme von SmartID (Preview)s 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

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 'Name' Attribut ü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.

Java Swing/AWT

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.

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.

Java FX

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.

Java SWT

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.

Web

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 Webanwendung 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 'ID' Attribut 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 den Parameter autoIdPatterns, siehe installCustomWebResolver - Parameter, konfiguriert werden. Außerdem kann in dieser Prozedur über den Parameter customIdAttributes auch jedes andere HTML-Attribut als Komponentenbezeichner genutzt werden.

Im Falle einer Webapplikation, welche ein von QF-Test unterstütztes AJAX Toolkit verwendet, können Sie einen Blick in Abschnitt 47.2.2 werfen, um mehr über das Setzen eindeutiger Bezeichner für das jeweilige Toolkit zu erfahren.

Win

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.

Android
Der Komponentenbezeichner heißt hier 'ID'. Er wird nur dann in das 'Name' Attribut übernommen, wenn es sich nicht um einen trivialen Klassennamen (vgl. Android - Liste der trivialen Komponentenbezeichner) handelt. Wenn innerhalb eines Containers Komponenten gleiche Bezeichner haben, legt QF-Test ein 'Weiteres Merkmal' mit dem Namen qfs:matchindex und einem entsprechenden Wert für die Duplikate an.
Über die Vergabe von Bezeichnern

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 50.1.6.

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.

Beeinflussen des 'Name' Attributs mittels 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:

  • das SUT dynamische Bezeichner besitzt.
  • Sie einen Algorithmus kennen, um eindeutige Bezeichner zu vergeben.
  • Sie entwicklungsseitige Änderungen von Bezeichnern "neutralisieren" wollen, z.B. bei einer neuen Version.
  • Sie die Namensgebung der Komponenten optimieren wollen, z.B. einige Teile ausschneiden, um lesbarere 'QF-Test IDs' für Komponenten in QF-Test zu erhalten.

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 50.1.6 beschrieben.