Testautomatisierung verschiedener Systemarten

Verschiedene Systemarten stellen unterschiedliche Ansprüche an eine gelungene Testautomatisierung. Sie bestimmen unter anderem den Automatisierungsansatz und schränken auch die möglichen Tools ein.

Desktop-Applikationen

Reine Desktop-Applikationen waren lange Zeit das Einzige, was zu automatisieren war. Sie bestehen meist nur aus Software und kommunizieren nicht mit anderen Systemen. Daher müssen sie kaum Randbedingungen und Schnittstellen beachten und die Entwickler können sich ganz auf den Zweck der Software selbst konzentrieren. Neben entsprechend auf die eigene Funktionalität fokussierten Entwicklertests auf Komponentenebene ist ein automatisierter Test über die Benutzerschnittstelle sinnvoll. Hierfür können Werkzeuge verwendet werden, die die Technologie der Applikation bzw. deren Benutzerschnittstelle unterstützen. Zusätzlich kann es notwendig sein, über das Dateisystem (und eventuell von der Applikation verwendete Formate) auf Testdaten zuzugreifen oder diese zu erstellen. Weitere Integrationsstufen sind zumindest auf Applikationsebene nicht notwendig. Allerdings werden die internen Komponenten natürlich entsprechend einer Integrationsstrategie miteinander integriert. Manchmal ist es dafür hilfreich, in die Applikation für Testzwecke Hilfsfunktionalitäten einzubauen, die etwa bei der Testvorbereitung oder der Überprüfung der Ergebnisse Unterstützung bieten.

Bei dieser Art des Softwaresystems ist die Automatisierung wesentlich vereinfacht, da die Abhängigkeiten zu anderen Softwaresystemen begrenzt sind – somit kann mit hoher Wahrscheinlichkeit auch ein eingeschränktes Set an Schnittstellen ausreichend sein, um einen funktionalen Test zu automatisieren.

Dass dieser Systemtyp inhärent auf nur einen gleichzeitigen Benutzer ausgelegt ist, vermeidet ebenfalls eine Reihe von Problemen in der Automatisierung – somit kann z.B. auf Tests mit mehreren Benutzern gleichzeitig verzichtet werden. Auf einen Test von mehreren parallelen Instanzen sollte allerdings nicht verzichtet werden.

Client-Server-Systeme

Die erste Komplexitätsstufe für Testautomatisierung stellte das Aufkommen der Client-Server-Systeme dar. Hier werden Daten zentral auf einem Server gehalten, der ebenfalls für wesentliche Teile der Funktionalität des Systems verantwortlich sein kann. Um dies zu differenzieren, wird zwischen “Fat Client” und “Thin Client” unterschieden werden: Wie der Name bereits andeutet, enthält ein “Fat Client” wesentlich mehr Teile der Funktionalität, während ein “Thin Client” eher als Darstellungs- und Eingabemaske gesehen wird und die Funktionalität größtenteils auf dem Server verbleibt.

Eine wichtige Entscheidung für den automatischen Test solcher Systeme ist, ob die Benutzerschnittstelle mitbetrachtet werden soll, oder ob hierfür ein manueller Test effizienter ist. Speziell im Fall von Thin Clients kann es ausreichend sein, die Automatisierung direkt über die Client-Schnittstellen arbeiten zu lassen und somit auf automatisierte GUI-Tests zu verzichten. Einer der Vorteile eines solchen Vorgehens ist die im Allgemeinen stark erhöhte Durchführungsgeschwindigkeit der automatisierten Testfälle. Im Falle von Fat Clients ist ein derartiges Vorgehen üblicherweise nicht angebracht, da ein großer Teil der Funktionalität im Client liegt und damit nicht getestet werden würde.

Ein wichtiger Aspekt bei Client-Server-Systemen ist, dass in den meisten Fällen mehrere User mit dem System parallel arbeiten. Für einen automatisierten Test gibt es mehrere mögliche Szenarien:

• Mehrere Benutzer über denselben Testrechner
• Mehrere Benutzer über unterschiedliche physische Rechner
• Mehrere Benutzer über unterschiedliche virtualisierte Rechner

Im ersten Fall ist die Abarbeitung der automatisierten Testfälle auf einem physischen Rechner zu parallelisieren. Die meisten Testwerkzeuge bieten hierfür jedoch keine explizite Unterstützung, da Automatisierung über das GUI eine gewisse Exklusivität voraussetzt. Die Erstellung einer eigens dafür benötigten Funktionalität kann sehr aufwendig werden.

Die zweite Möglichkeit enthält die Schwierigkeit der Kontrollierbarkeit der Testumgebung. Mehrere physische Rechner für den Zweck der Automatisierung zu konfigurieren und zu warten, bedeutet einen nicht unerheblichen Aufwand, selbst bei identischer Bauart.

Die am meisten genutzte Möglichkeit ist der Test über mehrere virtualisierte Rechner. Diese Methode hat den Vorteil, einfach eine definierte Konfiguration eines Rechners auf mehrere Instanzen multiplizieren zu können.

Die Erfahrung zeigt, dass viele Testteams, die erstmals eine virtualisierte Umgebung nutzen, die dafür notwendigen Administrationstätigkeiten und den damit verbundenen Aufwand stark unterschätzen. Ein effektives Konfigurationsmanagement für die virtualisierten Testrechner ist erfolgskritisch.

Web-Applikationen

Mittlerweile sehr weit verbreitet ist ein Spezialfall von Client-Server-Applikationen: Webapplikationen. Hier gibt es im Allgemeinen keinen spezifischen Client für eine Applikation, sondern einen generischen – den Browser. Durch die starke Standardisierung der übermittelten Daten (HTTP und HTML) können hier spezifische Methoden angewandt werden, die auf diese Protokolle abzielen und sich deren Verwendung zunutze machen (z.B. Capture & Replay auf Protokollebene). Viele Werkzeuge unterstützen Webapplikationen explizit. Auch die Parallelisierung von Testdurchführungen ist in Webapplikationen einfacher umzusetzen, da einige Werkzeuge nicht über das physische GUI, sondern über JavaScript auf die Oberfläche der Applikationen zugreifen oder überhaupt auf der Ebene der darunter liegenden Protokolle und Formate ihre Tests abarbeiten können, was die Testdurchführungszeit im Normalfall wesentlich beschleunigt.

Eine Festlegung, die eine Toolentscheidung deutlich vereinfacht, ist die Beantwortung der Frage, ob automatisierte Tests auf unterschiedlichen Browsern und Browserversionen durchgeführt werden sollen. Dies hängt speziell von den Funktionalitäten ab, die innerhalb des Browsers zur Verfügung gestellt werden, also von JavaScript, Ajax und ähnlichen Techniken.

Ein weiteres Szenario, in dem automatisierte Testabläufe in mehreren Browsern bereitgestellt werden können, sind teilautomatisierte Tests. Beispielsweise können automatisierte funktionale Tests durchlaufen und im Zuge der Durchführung Screenshots erfasst werden, damit nach dem Durchlauf ein Tester diese Screenshots manuell durchsehen und auf korrekte Darstellung überprüfen kann. Diese Methode kann eine gute Balance zwischen manuellem Testaufwand und Aufwand für die Automatisierung darstellen, da die maschinelle Überprüfung der korrekten Darstellung von Webpages mit dynamischem Inhalt zumindest zum aktuellen Zeitpunkt noch nicht stabil gewährleistet werden kann.

Testautomatisierung mobiler Applikationen

Generell kann man die Automatisierung mobiler Applikationen konzeptionell mit dem Test von Client-Server-Systemen vergleichen, mit dem Unterschied, dass statt Desktop Clients mobile Endgeräte die Kommunikation mit dem Server übernehmen. So gesehen stellt sich natürlich die Frage, warum die Automatisierung der Tests von mobilen Applikationen überhaupt gesondert betrachtet werden sollte. Abgesehen von der konzeptionellen Ähnlichkeit dieser Einsatzgebiete zeigt sich jedoch, dass bei diesem Einsatzgebiet einige spezielle Herausforderungen auftreten können, die eine gesonderte Betrachtung rechtfertigen. In diesem Kapitel sollen daher einige dieser speziellen Herausforderungen beim Test von mobilen Applikationen erwähnt und ein mögliches Vorgehen in diesen Testprojekten beschrieben werden.

Große Herausforderungen bei der Automatisierung mobiler Applikationen sind:

Die Auswahl der Testplattformen

Aktuell besteht die Gerätelandschaft aus einer Vielzahl von potentiell relevanten Endgeräten für Testautomatisierungsprojekte und ein großes Problem stellt daher die sinnvolle Auswahl einer Teilmenge von Geräten für die Testdurchführung dar.

Umgang mit Interrupts

Bei mobilen Anwendungen stellen Interrupts (z.B. Eingehende Anrufe, SMS, Push-Notifications, …) die Werkzeughersteller sowie die Testautomatisierer vor große Herausforderungen. Werden für die Testdurchführung Emulatoren oder Simulatoren eingesetzt, so lassen sich die Unterbrechungen relativ einfach simulieren. Auf physischen Endgeräten ist dies jedoch nur schwer möglich.

Unterschiedliche Hardware der Endgeräte

Gerade bei mobilen Endgeräten findet sich eine Vielzahl von Geräten mit unterschiedlichster Hardware wieder. Auch die Diversität in Bildschirmgröße, Auflösung und Punktdichte findet man in dieser Form nur bei mobilen Geräten. Diese Faktoren sind bei der Automatisierung von Desktopapplikationen weniger relevant.

Netzwerkperformanz und unterschiedliche Typen von Netzwerkanbindungen

Da mobile Applikationen oft mit unterschiedlichen und ständig wechselnden Netzwerkanbindungen funktionieren müssen, stellt sich die Frage, wie dieser Aspekt in der Testautomatisierung berücksichtigt werden kann. In der Praxis werden diese Tests entweder manuell in Feldtests oder in einer Testumgebung mit simulierten Netzwerkverbindungen (WAN-Emulatoren) durchgeführt.

Testautomatisierung bei Embedded Systems

Eingebettete Systeme zeichnen sich durch die Einbettung von Software in Hardware aus. Das zu testende System ist also nicht nur die Software, sondern Hardware und Software zusammen. Wenn verschiedene Komponenten mit unterschiedlichen Hardwareabhängigkeiten zusammenwirken, dann kann die Komplexität bei der Entwicklung und beim Test von eingebetteten Systemen beliebig komplex werden. Zusätzlich hinzukommende Faktoren wie z.B. interagierende Fremdsysteme oder Datenabhängigkeit können die Komplexität weiter steigern.

Eingebettete Systeme sind auch oftmals Systeme, die eine gewisse Sicherheitskritikalität besitzen. Das heißt, dass von der Korrektheit ihres Verhaltens hohe Güte wie z.B. hohe materielle Werte oder menschliches Leben abhängen. Dazu gibt es entsprechende Normen wie z.B. die ISO/IEC 25000 oder domänenspezifische Ausprägungen wir die ISO 26262 für den automotive-Bereich oder die EN 50128 für den Bahnbereich.

In solchen Normen gibt es Methodentabellen für die Art des Testansatzes als auch Klassifikationen für die eingesetzten Werkzeuge. Nach dieser Klassifikation unterscheidet man in der EN 50128 z.B. nach T1, T2 und T3, wobei T1 ‘hat keinen Einfluss auf das Testobjekt’ bedeutet, T2 Verifikations- und Testwerkzeuge betrifft, deren Fehler darin resultieren könnten, dass Fehler nicht entdeckt werden könnten und T3 die Arten von Werkzeugen meint, die einen direkten Einfluss auf das Testobjekt haben. Die vorgestellten Werkzeuge für die Testautomatisierung fallen daher unter T2, für die dann separate Qualitätsnachweise notwendig werden.

Data Warehouses

Ein Beispiel komplexer Systeme mit vielen Schnittstellen, Daten und oft wenig intuitiver Struktur sind Data Warehouses. Datenbanken und die darunter liegenden Systeme und Standardprodukte selbst unterscheiden sich prinzipiell im Test nicht wesentlich von anderen Applikationen – sie haben konkrete Anforderungen und Use-Cases. Im Gegensatz dazu stellen Data Warehouses zentrale Datensammlungen aus mehreren Systemen eines Unternehmens dar, deren Struktur und Aufbereitung der Daten eine umfassende Analyse erlaubt, um Management-und Businessentscheidungen zu unterstützen.

Ein Data Warehouse (DWH) erfüllt im Wesentlichen zwei Grundsätze:

• Integration von Daten
• Separation von Daten

Den Betrieb eines DWH, beginnend bei der Datenbeschaffung über die Speicherung der Daten in der DWH-Datenbank bis zur Verwaltung von Datenbeständen für nachfolgende Datenanalysen und -auswertungen, nennt man “Data Warehousing”.

Hier gibt es abseits der organisatorischen Problematik und der Infrastruktur (große Datenmengen, rechtlich sensitive Daten etc.) einige andere Aspekte, die den manuellen Test beinahe unmöglich machen:

• Viele technische Schnittstellen mit vielen Ursprungssystemen für Daten
• Keine grafische Oberfläche
• Aufwendige Kernfunktionalitäten wie z.B. Historisierung von Daten oder Konsistenzprüfungen
• Import, Export und Semantik der Daten sind komplex und in vielen Fällen dem Testteam nicht im Detail bekannt

Für einen umfassenden Test ist in den meisten Fällen eine Kombination von automatisierten Ansätzen notwendig. Für den Kernbereich des Data Warehouse, also die zentrale Datenhaltung und eigentliche Data-Warehouse-Funktionalität, wie z.B. Historisierung, Referenzen oder andere Kernfunktionalitäten, gibt es üblicherweise Konsistenzregeln bzw. Regeln, denen die Daten im Kernsystem genügen müssen. Hier kann ein automatisiertes System überprüfen, ob diese Regeln tatsächlich eingehalten werden, also ob z.B. in der Datenhistorie immer der aktuellste Datensatz die Markierung für den derzeit gültigen Datensatz besitzt.

Weitere Ansätze bei einem DWH-Test sind:

• Plausibilitätschecks: Es werden gültige und ungültige Datensätze importiert. Im Zielsystem müssen nun die gültigen Datensätze akzeptiert sein und die ungültigen Datensätze als “rejected” im Log erscheinen.
• Nachimplementierung: Ein Teil der Funktionalität des Systems wird zu Testzwecken im Automatisierungsframework nachimplementiert.
• Definierte Eingabe-Ausgabe-Paare: Eine bekannte und nach Testentwurfsmethoden aus den Import- und Transformationsregeln abgeleitete Menge an Testdatensätzen wird importiert und das Ergebnis mit bekannten, ebenfalls abgeleiteten Ergebnisdaten verglichen.

Cloud-basierte Systeme

Die wichtigste Eigenschaft von Cloud Computing ist, dass Anwendungen, Werkzeuge, Entwicklungsumgebungen, Managementtools, Speicherkapazität, Netzwerke, Server etc. vom Anwender nicht mehr selbst bereitgestellt oder betrieben, sondern von einem oder mehreren Anbietern “gemietet” werden, die die IT-Infrastruktur über ein Netzwerk als Cloud-Services öffentlich anbieten. Das hat für den Nutzer den Vorteil, dass Anschaffungs- und Wartungskosten für IT-Infrastruktur entfallen. Es werden nur die tatsächlich konsumierten Services für die Dauer der Nutzung bezahlt. Standardisierte und hoch skalierbare Services ermöglichen es vielen Unternehmen, nun Dienstleistungen in Anspruch zu nehmen, die früher kaum zu bezahlen waren.

Ein Problem, mit dem sich der Anwender von Cloud-Services auseinandersetzen muss, ist die Datensicherheit. Es liegt in seiner Verantwortung, welche Daten er in welchem Umfang außerhalb seines Unternehmens geben möchte.

Die Auslagerung der Betriebsumgebungen und die Nutzung von externen Services für Funktionalitäten haben auch auf den Test einen wesentlichen Einfluss. Gerade in solchen mehrschichtigen Szenarien, in denen Verantwortlichkeiten nicht bei einer einzelnen Partei liegen und funktionalitätsrelevante Teile unabhängig voneinander entwickelt und betrieben werden, ist eine kontinuierliche Überprüfung der Funktionalität der Systeme im Sinne eines häufig durchgeführten Regressionstests notwendig.

Wichtig ist hierfür, den Scope für Test und Testautomatisierung klar abzustecken und zu klären: Tests, die ein Cloud-Infrastruktur-Provider durchführen muss, sind in der Regel grundsätzlich anders fokussiert als Tests, die ein Plattform- oder Softwareentwickler oder gar der Kunde selbst durchführt.