Handbuch
Handbuch
 |  |  |  |  |  |  |  |
| Version 6.0.5 |
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.
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.
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
| ||||
| Beispiel 5.1: Ändern der Aufnahmereihenfolge von Wiedererkennungskriterien bei SmartIDs | ||||
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.)
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.
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.
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.
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.
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:
#tooltip=Bitte ergänzen referenziert
eine Komponente mit einem weiteren Merkmal mit dem Namen
tooltip und dem Wert Bitte ergänzen.
#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.
qfs:labelqfs: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.
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
qfs:typeqfs: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.
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>
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.
Die Komponentenhierarchie kann auch mit
SmartIDs für die Wiedererkennung genutzt werden.
Als Trennzeichen zwischen den Hierarchieebenen dient @.
Beispiele:
#Kundeninformationen@#Name referenziert eine
Komponente mit der SmartID #Name in einer übergeordneten
Komponente (zum Beispiel einem TitledPanel) mit der SmartID
#Kundeninformationen.
#ComboBoxSmartID@#Button:#ListenSmartID&22@#Link:<1>#Link:<1> adressiert den zweiten Link darin.
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.
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.
| | | | | | | Letzte Änderung: 15.3.2023 Copyright © 1999-2022 Quality First Software GmbH |
