Handbuch

Nachdem die theoretische Beschreibung des Vorgehens nicht einfach zu verstehen ist, zeigt dieser Abschnitt eine Beispielimplementierung für das WebCarConfigurator Demo. Sie finden die dazugehörige Testsuite unter qftest-4.2.2/demo/carconfigWeb/carconfigWeb_de.qft.

		Abbildung 42.3:  WebCarConfigurator

Wie im vorigen Abschnitt besprochen, müssen wir zuerst herausfinden, welches Attribut uns die relevanten Informationen liefert, um nachher zu den generischen Klassen von QF-Test zu kommen.

Für den Anfang wollen wir den '-5%' Button in der rechten unteren Ecke auf die generische Klasse 'Button' abbilden. Die aufgeführten Tabelle visualisiert unsere Zielsetzung. Auf der linken Seite finden Sie die aktuelle Aufzeichnung und auf der rechten Seite finden Sie unsere Wunschaufzeichnung.

	Aktuelle Aufzeichnung Verbesserte Aufzeichnung
		Abbildung 42.4:  Verbesserung durch einfache Klassenzuweisung

Zuerst sollten Sie einen Text-Check oder einen Mausklick auf diesen Button aufzeichnen. Danach springen Sie mittels Rechtsklick und Auswahl von »Komponente finden« zur aufgezeichneten Komponente. Hier können wir sehen, dass wir eine Komponente von der Klasse DIV mit einem leeren Namen aufgezeichnet haben. In den weiteren Merkmalen können wir nichts Nützliches finden. Besonders auffallend ist, dass nirgends die Information über den aktuellen Text von '-5%' auffindbar ist. Demzufolge hat QF-Test keine guten Anhaltspunkte um diese Komponente stabil wiederzuerkennen. Es bleiben nur die Geometrie- und Strukturinformationen. Jetzt versuchen wir diese Komponenten zum einen für QF-Test stabiler erkennbar und zum anderen ihre Benennung lesbarer zu machen.

		Abbildung 42.5:  Aufzeichnung des '-5%' Buttons im WebCarConfigurator

Wenn wir uns die Komponente näher anschauen, können wir in den weiteren Merkmalen das Merkmal class mit dem Wert button finden. Wir können also annehmen, dass jeder Button dieses spezielle Attribut besitzt. Insbesondere, wenn wir unsere Annahme an weiteren Buttons der Applikation überprüft haben.

Nun fügen wir einen Prozeduraufruf für qfs.web.ajax.installCustomWebResolver aus der Standardbibliothek qfs.qft unter den Extrasequenzen ein. Nachdem wir vorhin herausgefunden haben, dass das class Attribut die relevanten Informationen beinhaltet, können wir den Parameter genericClasses mit dem Wert button=Button versehen. Der Ausdruck button=Button bedeutet, dass jede Komponente, die den Wert button im Attribut class besitzt, von nun an die QF-Test-generische Klasse Button zugewiesen bekommt. Diese Zuweisung wird bei der nächsten Aufzeichnung QF-Test nun veranlassen, das Standardverhalten für Buttons bei dieser Komponente heranzuziehen. Führen Sie hierzu den Prozeduraufruf von qfs.web.ajax.installCustomWebResolver aus und zeichnen die Komponente nochmals auf. Sie werden jetzt folgende Aufzeichnung erhalten:

		Abbildung 42.6:  Aufzeichnung mit genericClasses im WebCarConfigurator

Bei dieser neuen Aufzeichnung erhalten Sie einen Klick auf eine Komponente mit der QF-Test ID button-5_. Diese Komponente hat nun die Klasse Button und der Text '-5%' wurde als Merkmal und sogar als weiteres Merkmal qfs:label erkannt. Diese Komponente wird von QF-Test ab jetzt als Button behandelt. Natürlich sollten Sie den Entwicklern immer noch vorschlagen, eine vernünftige ID zu vergeben und somit eine Eindeutigkeit bei der Komponentenerkennung zu erreichen, weil die ID von QF-Test als Name der Komponente verwendet wird.

Diese 'einfache' Zuweisung kann in vielen Fällen bereits ausreichend sein, besonders für Buttons, MenuItems oder Checkboxen. Falls in Ihrem Fall das Attribut nicht class sondern z.B. role ist, dann füllen Sie statt dem Parameter genericClasses den Parameter attributesToGenericClasses mit einem Wert wie role=button=Button. In einigen Fällen kann aber die Information über die Klasse nicht in der letzten Komponente im Baum, sondern in einer Komponente weiter oben in der Hierarchie zu finden sein. Wie man so eine Situation auflöst, finden Sie im nächsten Abschnitt.

Nach dem einfachen Beispiel im vorherigen Abschnitt, schauen wir uns jetzt ein komplexeres Szenario an. Hierfür versuchen wir die Textfelder, die die Preisinformationen beinhalten, z.B. das Endpreisfeld, zu analysieren. Wie auch vorher sollten wir nun ein paar Mausklicks bzw. Checks auf diese Felder aufzeichnen und uns im Anschluss die aufgezeichneten Komponenten ansehen. Auch hier finden wir die aktuelle Situation und die Zielsetzung in der unteren Tabelle.

	Aktuelle Aufzeichnung Verbesserte Aufzeichnung
		Abbildung 42.7:  Verbesserung durch fortgeschrittene Klassenzuweisung

Es wurden einige SPAN Knoten aufgezeichnet. Diese Komponenten haben allerdings kein class Attribut. Jedoch sehen wir, dass diese zumindest ein id Attribut zugewiesen bekommen haben. In diesem Fall können wir sagen, dass diese id sehr spezifisch für das jeweilige Textfeld ist. Wenn Sie die Elternkomponente, den TD Knoten, selektieren, finden Sie allerdings wieder das class Attribut mit dem Wert textfield. Wenn diese Komponente selektiert ist, hebt QF-Test auch das gesamte Textfeld auf der Webseite hervor. Wir können also annehmen, dass eine solche Komponente mit dem Wert textfield für das class Attribute für ein echtes Textfeld steht.

		Abbildung 42.8:  Aufzeichnung der SPAN Komponenten

Nun müssen wir wieder die Parameter des Prozeduraufrufes von qfs.web.ajax.installCustomWebResolver anpassen. In diesem Fall müssen wir der Klasse textfield von unserer Webseite die generischen Klasse TextField zuweisen. Hierfür erweitern wir den Parameter genericClasses auf textfield=TextField,button=Button. Wie Sie unschwer erkennen können, kann der Parameter genericClasses eine kommaseparierte Liste von Zuweisungen enthalten.

Jetzt löschen Sie die zuvor aufgezeichneten Komponenten, führen den Prozeduraufruf für qfs.web.ajax.installCustomWebResolver aus und zeichnen die Komponente nochmals auf. Jetzt erhalten Sie folgende Aufzeichnung:

		Abbildung 42.9:  Aufzeichnung der Textfelder des WebCarConfigurator

Es wurden die Textfelder, wie erwartet, aufgezeichnet und es gibt sogar eine Ebene in der Komponentenhierarchie weniger. Zudem haben die Textfelder jetzt die für QF-Test typischen Attribute, wie das weitere Merkmal qfs:label.

Hinweis Wie Sie sehen, wird auch in diesem Beispiel der Parameter genericClasses erweitert. Sie können die Werte dieses Parameters, wie auch die aller anderen, mittels 'Zeile bearbeiten' öffnen und nach den Kommas Zeilenumbrüche einfügen. Dieses Vorgehen verbessert die Lesbarkeit dieser Parameter.

Im nächsten Abschnitt widmen wir uns der Übersetzung von Komponenten, die Daten beinhalten und deren Daten wir gerne direkt ansprechen würden. Solche Komponenten sind typischerweise Tabellen, Bäume oder Listen und werden als komplexe Komponente in QF-Test bezeichnet.

Der Ansatz aus den vorherigen Abschnitten funktioniert sehr gut für jede Art von Standardkomponente, wie Buttons oder Checkboxen. Aber neben diesen Komponenten, gibt es noch komplexe Komponenten in einer GUI. Diese Komponenten beinhalten Datensätze, welche wir meistens direkt ansprechen sollten, z.B. mit der Elementsyntax von QF-Test. Solche Komponenten können Tabellen, Bäume oder Listen sein. Hierfür müssen wir sowohl der Komponente wie auch den Datensätzen selbst generische Klassen zuweisen.

	Aktuelle Aufzeichnung Verbesserte Aufzeichnung
		Abbildung 42.10:  Verbesserung durch Zuweisung komplexer Komponenten

Unser Beispiel bezieht sich auf die Tabelle, die die Fahrzeuge beinhaltet. Anfangs müssen wir wieder einige Mausklicks bzw. Checks auf die angezeigten Fahrzeuge aufzeichnen. Jetzt erhalten wir eine Aufzeichnung wie diese:

		Abbildung 42.11:  Aufzeichnung einer Tabelle im WebCarConfigurator

Es wurde ein Klick auf eine TD Komponente, die unter einer TR Komponente, welche unter einer TABLE Komponente liegt, aufgezeichnet. Die aufgezeichnete TD Komponente beinhaltet auch das weitere Merkmal class mit dem Wert dataCell. Bei der TR Komponente steht dort dataRow, bei der TABLE steht dort dataTable.

Wenn wir nun schrittweise diese Komponenten selektieren und dabei beobachten, welche Komponente im SUT hervorgehoben werden, kommen wir zu folgendem Schluss:

Eine TD Komponente steht hier für eine Tabellenzelle, eine TR Komponente steht für eine Tabellenzeile und die TABLE Komponente steht für die gesamte Tabelle. Genau diese drei Komponenten müssen wir uns jetzt näher anschauen, um diesen eine generische Klassen zuweisen zu können. QF-Test möchte nämlich für Tabellen genau diese drei Klassen auflösen, siehe Mapping von komplexen Komponenten.

Fangen wir mit dem TABLE Knoten an. Hier gibt es wieder ein class Attribut mit dem Wert dataTable. Das ist ein klares Zeichen, dass dieser Wert dataTable eine Tabelle repräsentiert. Nun gehen wir also wieder zum Prozeduraufruf von qfs.web.ajax.installCustomWebResolver und passen den Parameter genericClasses auf dataTable=Table,textfield=TextField,button=Button an.

Nun kommt die Tabellenzeile an die Reihe. Auf der TR Komponente finden wir wieder das class Attribut, diesmal mit dem Wert dataRow. Das ist wiederum ein klares Zeichen. Jetzt müssen wir also wieder den Prozeduraufruf von qfs.web.ajax.installCustomWebResolver anpassen und setzen den Wert für den Parameter von genericClasses auf dataRow=TableRow,dataTable=Table,textfield=TextField, button=Button.

Zu guter Letzt nehmen wir uns die TD Komponente vor. Überraschenderweise finden wir hier wieder das class Attribut, diesmal mit dem Wert dataCell. Also, passen wir wieder den genericClasses Parameter des Prozeduraufrufes an, nun auf dataCell=TableCell,dataRow=TableRow,dataTable=Table, textfield=TextField,button=Button. Bitte beachten Sie, dass Ihnen auch erlaubt ist, nach jedem Komma einen Zeilenumbruch einzufügen.

Der nächste Schritt ist die zuvor aufgezeichneten Komponenten zu löschen, den Prozeduraufruf auf qfs.web.ajax.installCustomWebResolver auszuführen, die Webseite neuzuladen und die Klicks nochmals aufzuzeichnen.

Als Resultat bekommen wir eine für QF-Test typische Aufzeichnung eines Elements, wie VehicleTable@Model&0 (oder jede andere Zeile, je nachdem was Sie angeklickt haben). Die aufgezeichneten Komponenten beinhalten nun nur noch eine Table Komponente ohne weitere Unterkomponenten, denn diese werden ab jetzt als Elemente von QF-Test behandelt.

		Abbildung 42.12:  Aufzeichnung einer aufgelösten Tabelle im WebCarConfigurator

Nachdem wir nun eine derart komplexe Komponente auflösen konnten, finden Sie eine Beschreibung des weiteren Vorgehens im nächsten Abschnitt.

Wie Sie in den vorigen Abschnitten gesehen haben, besteht also die erste Aufgabe eines Webprojektes, daraus, herauszufinden wie QF-Test die Komponenten der Webseite erkennt und entsprechend diese Übersetzungstabelle zu erstellen. Diese Aufgabe sieht auf den ersten Blick schwierig aus, kann Ihnen aber im späteren Verlauf Ihres Projektes viel Wartungsarbeit bei Änderungen in der Komponentenhierarchie ersparen, weil sich QF-Test eben nur mehr auf die wesentlichen Eigenschaften Ihrer HTML Seite konzentiert und nicht mehr alle möglichen Informationen auswertet.

Im Kapitel 50 finden Sie eine vollständige Aufführung aller generischen Klassen für Komponenten oder komplexe Komponenten wie Listen oder Bäume. Hier sollten Sie natürlich nicht alles mögliche versuchen zu mappen, sondern eher bedarfsorientiert vorgehen. Sie sollten also nur Komponenten, die auch wirklich benötigt werden, versuchen für QF-Test zu übersetzen. Eine spätere Erweiterung des Aufrufes ist möglich, falls neue Komponenten dazu gekommen sind.

Im vorherigen Beispiel würde man nun die nächsten Komponenten wie Menüs oder Tabs analysieren. Nachdem dies den Rahmen dieses Handbuchs sprengen würde, finden Sie ein vollständiges Beispiel in unserer Demo Testsuite qftest-4.2.2/demo/carconfigWeb/carconfigWeb_de.qft im Testfall CarConfiguratorWeb Demo.Nutzung eines CustomWebResolver.Fahrzeug anlegen mit CustomWebResolver.

Damit Ihre Übersetzungen zukünftig bei jedem Start der Webanwendung verwendet werden, sollten Sie den Prozeduraufruf von qfs.web.ajax.installCustomWebResolver direkt nachdem der Browser geöffnet wurde ausführen. Wenn Sie den Start Ihrer Browser-Anwendung über den QF-Test Schnellstartassistenen erstellt haben, finden Sie in der erzeugten Vorbereitungssequenz bereits den Prozeduraufruf in der Sequenz CustomWebResolver installieren. Dieser kann dann entsprechend parametrisiert werden.

Neben der reinen Übersetzung der Webseite nach QF-Test ist es auch möglich, bestimmte Komponenten für die Aufzeichnung zu ignorieren. Hierfür sind die Parameter ignoreTags bzw. ignoreByAttributes zuständig. Dieses Ignorieren sollten Sie aber erst einführen, wenn Sie die meisten Komponenten bereits übersetzt haben.

Abschließend möchten wir Ihnen die Unterschiede zwischen der ursprünglichen Aufnahme und so wie der Aufzeichnungen mit CustomWebResolver zeigen. In der nachfolgenden Tabelle finden Sie wieder links die Aufzeichnungen ohne CustomWebResolver und rechts finden Sie die selben Aufzeichnungen mit CustomWebResolver.

	Aktuelle Aufzeichnung Verbesserte Aufzeichnung
		Abbildung 42.13:  Verbesserung durch Zuweisung des Beispiels vom WebCarConfigurator

Letzte Änderung: 08.03.2018 Copyright © 1999-2018 Quality First Software GmbH