SmartID (Preview)

6.0+Preview "Preview" bedeutet, dass das Feature in einer zukünftigen Version offiziell freigegeben wird. Aktuell ist das Feature noch nicht vollständig umgesetzt, aber bereits so weit ausgereift, dass es großen Mehrwert bringt und die freigegebenen Funktionen ohne Sorge um Rückwärtskompatibilität genutzt werden können.

SmartIDs ermöglichen eine flexible, einfache Wiedererkennung von Komponenten, ohne dass die Wiedererkennungskriterien abgespeichert werden. Dies verschlankt den aufgenommenen Komponentenbaum in "Fenster und Komponenten" deutlich. Bei ausschließlicher Verwendung von SmartIDs wird der Komponentenbaum überhaupt nicht mehr benötigt. Es ist allerdings zu berücksichtigen, dass diese Flexibilität und Vereinfachung ihren Preis hat und - je nach Situation - die Performanz und Wartbarkeit beeinträchtigen kann.

SmartIDs verwenden die gleichen Wiedererkennungsmerkmale, die bei der klassischen Komponentenerkennung in den 'Komponente' Knoten abgespeichert werden. Der Unterschied ist, dass aus den möglichen Wiedererkennungsmerkmalen eines oder mehrere explizit ausgewählt und an Stelle der Referenz zur aufgenommenen 'Komponente' eingetragen werden. Zum Beispiel direkt im Attribut 'QF-Test ID der Komponente' eines Mausklick-Knotens.

Die SmartID wird durch ein führendes # gekennzeichnet. Die einfachste Version der SmartID ist entweder der Name oder die Beschriftung der Komponente mit einem vorangestellten #. Zum Beispiel #username, um eine Komponente mit dem Namen username anzusprechen oder #Anwendername, wenn Anwendername die Beschriftung des Feldes ist.

Ziel der SmartIDs ist eine Verschlankung des Komponentenbaums - so weit sinnvoll, aber nicht um jeden Preis. Einfaches soll möglichst einfach genutzt werden können, aber wenn es schwierig ist, eine Komponente anzusprechen, sind 'Komponente' Knoten besser geeignet. Die Themen "Eindeutigkeit" und "Performanz" können alternativ über das Scope-Konzept adressiert werden, siehe Geltungsbereich(Scope) (Preview).

Die SmartID wird im Attribut 'QF-Test ID der Komponente' eingetragen, zum Beispiel im Attribut 'QF-Test ID der Komponente' von Event- oder Check-Knoten. Sie kann genauso wie die 'QF-Test ID der Komponente' in Variablen gespeichert, in Parametern übergeben oder in Skripten genutzt werden. Bei komplexen Komponenten wie Tabellen, Listen oder Bäumen kann die SmartID ebenfalls die 'QF-Test ID der Komponente' ersetzen. Der Index, der das Unterelement bezeichnet, bleibt unverändert. Im Anschluss an eine SmartID kann eine darin enthaltene Komponente entweder über eine weitere SmartID oder mittels XPath (Adressierung mit XPath und/oder CSS-Selektoren) adressiert werden.

SmartIDs können für alle Client-Technologien genutzt werden.

Wie bei generischen Komponenten ist zu berücksichtigen, dass die Aktualisierung nicht so komfortabel ist wie bei 'Komponente' Knoten Knoten. Allerdings steht in QF-Test eine mächtige "Suchen und Ersetzen" Funktionalität zur Verfügung, um SmartIDs suiteübergreifend anzupassen.

Anwendungsbereiche für SmartIDs

Die Anwendungsbereiche sind die gleichen, in denen bisher Generische Komponenten zum Einsatz kamen. SmartIDs ersetzen generische Komponenten weitgehend und sind einfacher zu nutzen als diese.

Lesbarkeit

Bei der direkten Aufnahme von Testfällen kann der Einsatz von SmartIDs die aufgenommenen Event- und Checkknoten lesbarer machen. Insbesondere, wenn die aufgenommenen Namen der Komponenten kryptisch sind und stabile Beschriftungen vorhanden sind. In diesem Fall macht es Sinn, die Reihenfolge für die Aufnahme der Wiedererkennungskriterien auf "zuerst Beschriftung, dann Name" zu ändern, zum Beispiel in einem Server Skript mittels

rc.setOption(Options.OPT_RECORD_SMARTID_PRIORITIES, "label,name")
Beispiel 5.1:   Ändern der Aufnahmereihenfolge von Wiedererkennungskriterien bei SmartIDs

Ignorieren der Komponentenhierarchie

Manche Anwendungen haben tief verschachtelte Komponentenhierarchien. SmartIDs machen es einfach, den Komponentenbaum zu reduzieren, was insbesondere dann hilfreich ist, wenn die Komponentenhierarchie über die Versionen hinweg nicht stabil bleibt. (Bisher wurden zu diesem Zweck Generische Komponenten eingesetzt. Dies ist auch weiterhin möglich, auch parallel zu SmartIDs.)

Testgetriebene Entwicklung

Bei testgesteuerter Entwicklung bieten SmartIDs den großen Vorteil, dass keine 'Komponente' Knoten Knoten angelegt werden müssen. Außerdem werden bei testgesteuerter Entwicklung häufig die Komponentenbezeichner im technischen Design festgelegt, die dann für die Testerstellung genutzt werden können.

Schlüsselwort-basierende Tests
Schlüsselwort-basierende Tests werden technisch über Prozeduraufrufe und Parameter implementiert. Der Testersteller nimmt somit keine Komponenten auf und ist für die Identifikation der Komponenten auf visuelle Informationen aus dem GUI angewiesen. Dies kann die Beschriftung der Komponente oder deren Funktion (Klasse) sein. Weitere Informationen finden Sie in Schlüsselwortgetriebenes bzw. Keyword-Driven Testing mit QF-Test.
Integration mit anderen Test-Tools
Bei der Steuerung der Testausführung seitens QF-Test über andere Test-Tools wie Robot Framework können die Wiedererkennungskriterien direkt über SmartIDs spezifiziert werden.

SmartID-Syntax für 'Klasse'

Die Klasse wird in der SmartID direkt nach dem # angegeben und mit einem : abgeschlossen, zum Beispiel #Button:.

Für Komponentenklassen, mit denen der Anwender typischerweise interagiert, muss die Klasse nicht explizit in der SmartID angegeben werden. Eine Liste dieser Klassen finden Sie in Abschnitt 45.5.1. Bei diesen Klassen kann die SmartID auch einfach nur den Komponentenbezeichner oder die Komponentenbeschriftung (entweder das Merkmal oder das weitere Merkmal qfs:label) umfassen, zum Beispiel #btnOK, wenn der Name des Buttons "btnOK" ist, oder #Speichern, wenn die Beschriftung des Buttons "Speichern" lautet. Dies macht eine SmartID einfacher in der Handhabung, allerdings in gewissem Maß auf Kosten der Performance, da ohne Angabe der Klasse mehr Kandidaten auf Übereinstimmung mit der SmartID geprüft werden müssen. Für nicht in der Liste enthaltene Klassen muss diese in der SmartID explizit enthalten sein, zum Beispiel #Panel:addresses, wobei "addresses" hier der Name des Panels ist.

Panels sind insofern ein Sonderfall, da sich Panels mit Beschriftung für geschachtelte SmartIDs (siehe Abschnitt 5.6.7) oder Scopes (siehe Abschnitt 5.7) anbieten. Daher gehört der Klassentyp Panel:TitledPanel zu den SmartID-Klassen und muss nicht separat angegeben werden.

Wenn Sie zusätzlich zur generischen Klasse einen vordefinierten Klassentyp verwenden, können Sie diese Kombination wie gewohnt schreiben, zum Beispiel #Button:ComboBoxButton:. Die vordefinierten Klassentypen finden Sie in Eigenschaften von generischen Klassen. Bei eigenen Klassentypen muss der innere Doppelpunkt mittels \ geschützt werden, zum Beispiel #Panel\:myPanel:.

Informationen zu Kombinationsmöglichkeiten finden Sie in Abschnitt 45.3.

SmartID-Syntax für 'Name'

Ein Name kann in der SmartID direkt nach dem # angegeben werden, z.B. #txtUsername. Wenn die Klasse der Komponente zu den Generische Klassen gehört, reicht die einfache Angabe des Namens. Ansonsten muss die Klasse vorangestellt werden, zum Beispiel #DIV:txtUsername.

Der verwendete Name kann SmartID-spezifische Sonderzeichen enthalten, diese müssen jedoch mit einem vorangestellten \ geschützt werden.

Um zu erzwingen, dass der Name für die Komponentenerkennung verwendet wird, kann in der SmartID Name= vorangestellt werden, zum Beispiel #Name=txtUsername. Die Groß-/Kleinschreibung muss beim Präfix Name= nicht beachtet werden.

Weitere Informationen zu Kombinationsmöglichkeiten finden Sie in Abschnitt 45.3.

SmartID-Syntax für 'Merkmal'

Das Wiedererkennungskriterium Merkmal kann in der SmartID direkt nach dem # angegeben werden, zum Beispiel #Anwendername. Wenn die Klasse der Komponente zu den Generische Klassen gehört, reicht die einfache Angabe des Merkmals. Ansonsten muss die Klasse vorangestellt werden, zum Beispiel #DIV:Anwendername.

Das verwendete Merkmal kann SmartID-spezifische Sonderzeichen enthalten, diese müssen jedoch mit einem vorangestellten \ geschützt werden.

Um zu erzwingen, dass das Merkmal für die Komponentenerkennung verwendet wird, kann dem Merkmal Feature= vorangestellt werden, zum Beispiel #Feature=Anwendername. Wenn es unwichtig ist, ob das Merkmal oder das weitere Merkmal qfs:label verwendet wird, kann Label= vorangestellt werden, zum Beispiel #Label=Anwendername. Die Groß-/Kleinschreibung muss bei den Präfixen Feature= und Label= nicht beachtet werden.

Weitere Informationen zu Kombinationsmöglichkeiten finden Sie in Abschnitt 45.3.

SmartID-Syntax für 'Weitere Merkmale'

Wiedererkennungskriterien aus der Gruppe der Weitere Merkmale stehen ebenfalls für die SmartID zur Verfügung.

Auch hier müssen SmartID-spezifische Sonderzeichen mit einem vorangestellten \ geschützt werden.

Eine herausragende Stellung hat das weitere Merkmal qfs:label, das die ermittelte Beschriftung der Komponente enthält. Es kann in der SmartID direkt nach dem # angegeben werden, zum Beispiel #Anwendername. Wenn die Klasse der Komponente zu den Generische Klassen gehört, reicht die einfache Angabe der Beschriftung. Ansonsten muss die Klasse vorangestellt werden, zum Beispiel #DIV:Anwendername.

Bei allen anderen weiteren Merkmalen muss der Name des weiteren Merkmals, gefolgt von = und dem Wert des weiteren Merkmals angegeben werden. Die Groß- und Kleinschreibung muss für die Namen des weiteren Merkmals berücksichtigt werden.

Beispiele:

  • Die SmartID #tooltip=Bitte ergänzen referenziert eine Komponente mit einem weiteren Merkmal mit dem Namen tooltip und dem Wert Bitte ergänzen.
  • Die SmartID #my\:foo=Irgend\&etwas referenziert eine Komponente mit einem weiteren Merkmal mit dem Namen my:foo und dem Wert Irgend&etwas.

Informationen zu Kombinationsmöglichkeiten finden Sie in Abschnitt 45.3.

Weiteres Merkmal qfs:label
Um zu erzwingen, dass qfs:label für die Komponentenerkennung verwendet wird, kann in der SmartID qlabel= vorgestellt werden, zum Beispiel #qlabel=Anwendername. (qlabel= wurde eingeführt, damit wegen des Doppelpunkts nicht die umständlichere Schreibung #qfs\:label verwendet werden muss.) Wenn es unwichtig ist, ob das Merkmal oder das weitere Merkmal qfs:label verwendet wird, kann Label= vorangestellt werden, zum Beispiel #Label=Anwendername. Die Groß- und Kleinschreibung muss bei den Präfixen Label= und qlabel= nicht beachtet werden.
Weitere Merkmale qfs:text und text

Auch die weiteren Merkmale qfs:text und text haben eine Sonderstellung. Beide können über den Präfix text= vor dem eigentlichen Wert angesprochen werden. Wenn dediziert qfs:text verwendet werden soll, können Sie qtext= verwenden.

Beispiele: #text=Anna, #qtext=Benno

Weiteres Merkmal qfs:type
Das weitere Merkmal qfs:type gibt den Typ einer Klasse an. Wenn nicht einer der von QF-Test vordefinierten Typen (siehe Eigenschaften von generischen Klassen) verwendet wird, müssen die darin enthaltenen Doppelpunkte mit \ geschützt werden.

SmartID mit Index

Alle SmartIDs können mit einem Index versehen werden, wenn mehrere Komponenten für die gleiche SmartID in Frage kommen. Dabei zählt die technische Reihenfolge der Komponenten in der Hierarchie. Diese muss nicht der visuellen Reihenfolge entsprechen. Die Zählung des Index beginnt bei 0. Der Index wird in spitzen Klammern angegeben. Wird kein Index angegeben, wird implizit der Index 0 verwendet.

Beispiele: #Name<2>, #TextField:<2>

Sonderfälle

Bei Komponenten der Klasse Label gilt diese Reihenfolge nicht. Da sie in den meisten Fällen als Beschriftung anderer Komponentenklassen genutzt werden und dort im Merkmal oder als weiteres Merkmal "qfs:label" abgespeichert werden, werden die Komponenten der Klasse Label nachrangig behandelt. Label Komponenten müssen daher explizit mit vorangestellter Klasse Label: angesprochen, zum Beispiel #Label:Vorname werden.

Informationen zur allgemeinen SmartID-Syntax finden Sie in Abschnitt 45.3.

SmartID-Syntax für Komponentenhierarchien

Die Komponentenhierarchie kann auch mit SmartIDs für die Wiedererkennung genutzt werden. Als Trennzeichen zwischen den Hierarchieebenen dient @.

Beispiele:

Komponente in Container
Die SmartID #Kundeninformationen@#Name referenziert eine Komponente mit der SmartID #Name in einer übergeordneten Komponente (zum Beispiel einem TitledPanel) mit der SmartID #Kundeninformationen.
Komponente in "normaler" Komponente
Manchmal werden Komponenten wie zum Beispiel ein Button keine guten eigenen Wiedererkennungsmerkmale besitzen, über die Komponente, in der sie liegen, sehr gut angesprochen werden können.
Ein typisches Beispiel ist hier der Button zum Aufklappen der Liste in einer ComboBox:
#ComboBoxSmartID@#Button:
Komponente in Unterelement
Links oder Buttons in Listen- oder Tabellenelementen können mit verschachtelten SmartIDs adressiert werden:
#ListenSmartID&22@#Link:<1>
Hierbei adressiert der Teil vor "@" ein Listenelement, #Link:<1> adressiert den zweiten Link darin.

Aufnehmen und Abspielen von SmartIDs

Wenn Sie SmartIDs aufnehmen wollen, haken Sie den Menüpunkt »Aufnahme«-»SmartIDs aufnehmen« oder die Option 'SmartIDs aufnehmen' in der Rubrik »Aufnahme«-»Komponenten« an.

Preview Für QF-Test ist die Aufnahme von SmartIDs technisch sehr anspruchsvoll. Seitens QFS bedarf es noch einiger Erfahrung aus der Praxis mit konkreten Anwendungen, um sie mit geeigneten Optionen zur Feinjustierung zu versehen. Aktuell können eventuell keine oder nicht optimale SmartIDs aufgenommen werden.

Bei der Aufnahme von SmartIDs prüft QF-Test zunächst, ob ein Name vorhanden ist. Falls ja, wird dieser für die SmartID verwendet. Wenn nicht, wird nach einer Beschriftung gesucht (Merkmal oder Weitere Merkmale.) Wenn die ermittelte SmartID für mehrere Komponenten gültig ist, wird ein Index angefügt.

Wenn bei der Aufnahme im SmartID-Modus erkannt wird, dass sich das GUI-Element nicht für SmartIDs eignet, wird ganz klassisch ein 'Komponente' Knoten Knoten aufgenommen. Dies ist zum Beispiel der Fall, wenn dem GUI-Element keine generische Klasse zugewiesen werden kann oder wenn QF-Test für das GUI-Element weder Name, noch Merkmal noch das weitere Merkmal qfs:label ermitteln kann.

Wird eine Komponente der Klasse 'Label' aufgenommen, wird immer zusätzlich die Klasse in die SmartID eingefügt, da sonst die Komponente, für die diese 'Label' Komponente als Beschriftung dient, referenziert würde, zum Beispiel #Label:Straße.

Das Abspielen von Knoten mit SmartIDs unterscheidet sich nicht von dem mit aufgenommenen Komponenten. Es können beide Varianten innerhalb eines Testfalls verwendet werden. SmartIDs können auch bei aufgenommenen Komponenten zur Adressierung untergeordneter Komponenten verwendet werden. Das Beispiel aufgenommeneListe&10@#Button: zeigt Kombination der 'QF-Test ID' einer aufgenommenen Liste mit Index und der SmartID des in dem Listenelement liegenden Buttons.

'QF-Test ID' der Komponente als SmartID

Es ist möglich, die 'QF-Test ID' einer aufgenommenen 'Komponente' auf eine SmartID inklusive vorangestelltem # Kennzeichen zu setzen. Dies kann genutzt werden, um die SmartID quasi umzuleiten und die Komponentenerkennung klassisch über die Wiedererkennungsmerkmale der aufgenommenen Komponente durchzuführen. Einzelne Komponenten aufzunehmen macht insbesondere dann Sinn, wenn die SmartID lang und umständlich wird, schlechte Performance hat oder schwer eindeutig zu machen ist. Das SmartID-Kennzeichen # kann dann der Einheitlichkeit halber genutzt werden, muss aber nicht.