Airbus Defence and Space verwendet das GUI-Testtool QF-Test für tägliche automatisierte Regressionstests. Das „System under Test“ ist eine Anwendungssoftware ("SW"), die zur Verarbeitung von Bild-, Video- und Bewegungsinformationen im militärischen Umfeld genutzt wird. Für dieses Produkt und seine Varianten wird sichergestellt, dass neu implementierte Änderungen keinen Einfluss auf bestehende Funktionalitäten haben. Die Architektur der SW zusammen mit QF-Test erlauben einen betriebssystemübergreifenden Ansatz für „Write once, test anywhere“, um die Qualität sowohl des Standardproduktes als auch seiner Ausprägungen gezielt zu überprüfen.
Die von Airbus Defence and Space entwickelte Anwendungssoftware beruht auf einer Client-Server-Architektur. Der Client ist Eclipse RCP basiert und kann unter RHEL in zwei verschiedenen Modi gestartet werden. Das Backend ist eine OSGi-Server Lösung und wird für zwei Betriebssysteme unterstützt, RHEL Server für das Standardprodukt, Oracle Solaris 11 für eine Produktausprägung, die sich bereits im operationellen Einsatz befindet.
Auf der Basis neuer Kundenanforderungen wird das Standardprodukt weiterentwickelt, in einem täglichen Buildprozess neu erzeugt und auf beide Plattformen verteilt. Im Rahmen dieser Continuous Development Chain laufen automatisierte GUI-Regressionstests auf der Basis von QF-Test, welche die Unversehrtheit der Client-Server-Schnittstellen und deren Grundfunktionalität überprüfen. Damit ist sichergestellt, dass etwaiges Fehlverhalten nach Implementierung von Änderungen frühzeitig entdeckt und schnell behoben werden kann.
Die Continuous Deployment Chain für das SW Produkt und seine Variante ist in obiger Abbildung illustriert. Im Build- und Deployment Prozess werden sowohl die zu testende SW als auch die QF-Test SW zunächst paketiert und in einem Repository abgelegt. Das im NEXUS Repository gespeicherte QF-Test Paket besteht neben der QF-Test SW aus zwei weiteren Teilen, einer Produkt-Bibliothek (Produkt Library.qft) und einer entsprechenden Test-Suite (Smoke-Test-Suite.qft) für jede Plattform. Die Produkt-Bibliothek enthält sämtliche Aufzeichnungen, um auf graphische Elemente des Eclipse-RCP-basierten Clients (Menus, Parts, Tables, Buttons, Sliders etc.) zuzugreifen. Hier ist auch der "Fenster und Komponenten"-Baum abgelegt, der zusammen mit einem eineindeutigen Component Identifier den Zugriff auf die grafischen Elemente des Clients erlaubt. Der dynamische Ablauf der Tests variiert zwischen den beiden Server Lösungen (RHEL, Oracle Solaris) und ist in der jeweiligen Smoke-Test-Suite für jede Plattform entsprechend angepasst. Die hier implementierten Test-Suiten werden nach der Installation täglich gestartet und bedienen sich der in der Produkt-Library gespeicherten Grundfunktionalitäten. Dabei werden zunächst Test-Suiten ausgeführt, die die Konfigurationseinstellungen für die Datenübertragung zwischen Server und Client (Ports, IP-Adressen, Protokolle) vornehmen. Im Anschluss daran wird die Korrektheit der implementierten Schnittstellen zwischen Server und Client für jede Plattform überprüft, in dem ein einfacher Datenaustausch (Bilder, Videos, Bewegungsinformationen) simuliert und automatisch überprüft wird. Die Verwendung von Data Driver/Tables erleichtert das Ausführen derselben Test-Sequenz mit unterschiedlichen Konfigurationen, wobei gleichzeitig die Wartbarkeit des Test-Codes erhalten bleibt. Die einzelnen Prozeduren sind in einfachen Try/Catch-Blöcken gekapselt, so können unvorhergesehene Fehler leicht abgefangen und protokolliert werden.
Das parallele und automatische Ausführen von ca. 100 Tests dauert ungefähr eine Stunde. Ein manuelles Ausführen der Tests beschäftigte bisher eine Person für drei Stunden pro Konfiguration. Für das Standardprodukt und seine Ausprägung (zwei Modi) ergibt sich also eine Ersparnis von derzeit 8 Stunden pro Tag, eine Zeit, für die wir gern in weitere automatisierte Tests oder andere Tätigkeiten investieren.
Durch dieses Vorgehen – „write once, test anywhere“ – haben wir sehr viele Fehler gefunden, die mit der Konfiguration der Anwendung auf dem jeweiligen Betriebssystem zusammenhingen. Die Testautomatisierung wirkt sich insgesamt sehr positiv auf die Beschleunigung des Entwicklungsprozesses aus, da Testergebnisse schnell vorliegen und aufwendige manuelle Tests entfallen können. Des Weiteren gelten erfolgreiche automatisierte Testergebnisse als Übergabekriterium für die Installation und Konfiguration der SW auf der nächstfolgenden Integrationsstufe.
QF-Test als Tool zur GUI Testautomatisierung ist für den plattformübergreifenden Einsatz ausgelegt und eignet sich sehr gut für unseren Anwendungsbereich. QF-Test ist leicht zu erlernen und ließ sich problemlos in unsere Betriebsumgebung integrieren. Besonders hervorzuheben ist die Möglichkeit, die mitgelieferten Algorithmen zum pixelbasierten Bildvergleich für Bilder und Videos in den Testablauf einzufügen. Darüber hinaus haben wir uns das Exception Handling von QF-Test bei der Ablaufsteuerung der einzelnen Test-Suiten zunutze gemacht. Schlussendlich half uns auch die sehr schnelle und zuverlässige deutsche Supportunterstützung durch den Hersteller.
Zur gezielten Überprüfung der bereits im operationellen Betrieb befindlichen Produktvariante sind weitere Regressionstests geplant, die häufig durchzuführende Anwendungsfälle des Systems überprüfen sollen. Hierbei geht es um die Simulation langläufiger und asynchroner Prozesse sowie Untersuchungen des Umgangs mit großen Datenmengen, um Rückschlüsse auf die Leistungsfähigkeit (CPU-Last, Speicherbedarf) des Systems zu ziehen. Auch hier kann die bereits existierende Produktbibliothek Verwendung finden, es muss lediglich eine neue Regressions-Testsuite erzeugt werden, die die neuen Anwendungsfälle enthält. Von dieser geplanten Vorgehensweise erhoffen wir uns eine weitere Qualitätssteigerung der SW und die Minimierung des Risikos, dass Fehler erst zu einem späten Zeitpunkt gefunden werden und somit wesentlich teurer zu beheben sind.
Autor: Thomas Schöning
ISTQB Certified Testmanager
Airbus Defence and Space GmbH
Multi-INT Products & Projects Germany
