Handbuch
Version 8.0.1 |
Webswing und JPro sind zwei hochinteressante Lösungen, die Swing und JavaFX Desktop-Anwendungen in den Browser bringen. Die zu Grunde liegenden Technologien, Konzepte und Ziele unterscheiden sich deutlich, doch die Herausforderung für QF-Test ist bei beiden die gleiche: Es gilt zwei SUT-Clients gemeinsam in einer koordinierten Weise anzusteuern.
Die Migration von bestehenden Anwendungen ist hier eines der häufigsten Szenarios, so dass die
Wiederverwendbarkeit von bestehenden QF-Test Testsuiten für die Java Desktop-Anwendungen äußerst wichtig ist. Dies
ist einer der Gründe dafür, warum Testen alleine über den Browser nicht ausreichend ist. Der andere Grund ist,
dass QF-Test im Browser nur einen CANVAS
mit bunten Pixeln sieht (Webswing), bzw. eine Hierarchie von
zueinander sehr ähnlichen DIV
Knoten. Auch wenn letzteres für Tests zumindest halbwegs brauchbar
ist und für spezielle Themen wie Lasttests noch interessant werden kann, ist es im Vergleich zum tief
reichenden Durchgriff, den QF-Test bei Java-Anwendungen hat, doch sehr eingeschränkt.
Hier betritt "JiB" die Bühne - QF-Test's Lösung für "Java im Browser".
Hinweis Für JiB werden neben Swing und/oder JavaFX Engine-Lizenzen auch QF-Test Lizenzen für die Web-Engine benötigt.
QF-Test kommt mit einer Demo-Testsuite für Webswing, die zum besseren Verständnis des folgenden Abschnitts beiträgt. Sie finden diese über den Menüeintrag »Hilfe«-»Beispiel-Testsuiten erkunden...«, Eintrag "Webswing SwingSet Suite".
Beim JiB Ansatz betrachtet QF-Test die Swing oder JavaFX-Anwendung als das primäre SUT. Fast die gesamte Interaktion wird über die jeweilige Swing oder JavaFX SUT Engine gesteuert. QF-Test öffnet zusätzlich ein Browserfenster und nutzt seine Web-Engine, um dieses Frontend anzusteuern, durch das die Anwendung dargestellt wird und über das der Anwender mit ihr interagiert.
Es gibt zwei Formen der Interaktion von QF-Test mit der Anwendung:
QF-Test kann die Event-Steuerung komplett innerhalb der Swing oder JavaFX-Anwendung halten. In diesem Modus dient der Browser nur zum Start der Anwendung, als Referenz für den Anwender und für Sonderfälle, bei denen der Workflow der Anwendung in eine Web-Schnittstelle verlagert wurde, vor allem der Up- und Download von Dateien.
Dieser Modus ist sehr ähnlich zum normalen Test einer Swing oder JavaFX-Anwendung. Die Wiedergabe von Events passiert identisch dazu. Die Bilder für Abbild-Checks werden von Swing bzw. JavaFX per Off-Screen-Rendering in einen Speicherbereich gezeichnet, ebenfalls identisch zur Desktop-Version.
Was der obige Fall nicht abdeckt, ist die Verifikation, dass die Webswing bzw. JPro Integration tatsächlich wie erwartet Ende-zu-Ende funktioniert, also dass der Anwender die Benutzerschnittstelle wirklich wie gewünscht zu sehen bekommt und mit der Anwendung mittels Maus und Tastatur über den Browser interagieren kann. Auch wenn man diskutieren kann, bis zu welchem Grad man zu Grunde liegenden Technologien einfach vertrauen oder diese selbst mit testen sollte, ist die Möglichkeit, echte Ende-zu-Ende Tests über den Browser durchzuführen für dieses Szenario ein sehr wichtiger Aspekt.
QF-Test kann die Wiedergabe der Events über einige Optionen zum Browser umleiten. Tests werden dabei immer noch über die Java-Anwendung ausgeführt, die Komponentenerkennung funktioniert unverändert und QF-Test kümmert sich um die Synchronisation und führt alle vorbereitenden Schritte aus, wie das sichtbar Scrollen von Elementen oder das implizite öffnen von Baumknoten. Im letzten Schritt führt die Swing bzw. JavaFX Engine den Event nicht selbst aus, sondern nutzt eine spezielle Verbindung, um die Event-Information an die QF-Test Web-Engine im Browser weiterzuleiten und dann darauf zu warten, dass der Event dort ausgeführt und über Webswing bzw. JPro zurück an die Java-Anwendung gelangt.
Der letzte Baustein für Ende-zu-Ende Tests ist die Verifikation der Darstellung im Browser, wie sie der Anwender zu sehen bekommt. Anstelle des Off-Screen-Renderings kann QF-Test die Bilderstellung an die Web-Engine delegieren, die ein Bildschirmabbild der entsprechenden Region im Browserfenster aufnimmt. Diese Bilder können in Details von den Java Off-Screen-Varianten abweichen, speziell bei der Textdarstellung und beim Antialiasing. Dies kann mit Hilfe der Algorithmen für Abbild-Checks in QF-Test kompensiert werden. Näheres hierzu finden Sie in Kapitel 58.
Tests im Java-Modus sind sehr robust und effizienter. Wir empfehlen, diesen für die Migration bestehender Tests und für den Großteil der funktionalen Tests zu nutzen. Diese sollten durch verschiedene Tests im Web-Modus ergänzt werden, um Ende-zu-Ende-Zuverlässigkeit zu gewährleisten. Als Daumenregel sollten wiederholte Tests für dieselbe Schnittstelle mit verschiedenen Werten und dem Fokus auf Funktionalität primär im Java-Modus durchgeführt werden. Tests für unterschiedliche Komponenten mit dem Fokus auf Interaktion sollten den Web-Modus nutzen.
Prozeduren zum Umschalten der verschiedenen Optionen werden im Package qfs.jib
in der
Standardbibliothek qfs.qft
bereitgestellt.
Letzte Änderung: 10.9.2024 Copyright © 1999-2024 Quality First Software GmbH |