Richtiggehende Zweifel hatte das Test-Team der FIS-ASP nicht, als es sich diese Fragen stellte. Den besonderen Anforderungen an die Software war man sich jedoch durchaus bewusst. Um es vorwegzunehmen: Zur Enttäuschung wurde der Versuch nicht, im Gegenteil.
Die Aufgabenstellung lautete, Software- und Performance-Tests von SAP-Systemen mit Open-Source-Ansätzen durchzuführen. Das hierfür auserkorene Projekt openQA wurde ursprünglich von SUSE entwickelt und ist heute ein unabhängig entwickeltes Open-Source-Projekt unter GPLv2.
Viele namhafte Unternehmen in diesem Bereich setzen openQA für automatisierte Tests von Software ein und integrieren diese in die Continous-Integration-Prozesse der Quellcode-Verwaltung. Vollautomatisiert werden auf diese Weise ganze Linux-Distributionen getestet.
Vertraute Technologien reduzieren den Aufwand erheblich
Da openQA sowohl GUI-Eingaben mittels Bilderkennung durchführen und überprüfen als auch abgespielte Sound-Samples analysieren kann, stand schnell fest, die Aufgaben lassen sich lösen. Die Tests selbst spielen sich hierbei in vorbereiteten Images ab, die eine komplette virtuelle Maschine darstellen. Erstellt werden die virtuellen Maschinen mit QEMU. In seiner Erweiterung KVM für das Test-Team kein fremdes Produkt, da es ebenfalls für die Virtualisierung von SAP-Systemen zugelassen ist und auch in der OpenStack Cloud angewendet wird.
So lässt sich feststellen, dass sich ein ursprünglich sehr hoch geschätzter Aufwand für ein solches Projekt enorm verringern kann, wenn die dabei verwendeten Technologien bereits bekannt sind.
Software- und Performance-Tests anhand von definierten Anwendungsfällen
Bei den ersten Tests fiel auf, dass mit openQA nicht nur Software, sondern auch die Performance automatisiert getestet werden kann. Dazu wurden verschiedene Szenarien entwickelt.
Zunächst wurde ein Test durchgeführt, der eine vordefinierte Anzahl von Benutzern im SAP-System anlegt. Alle Interaktionen mit SAP fanden dabei durch das SAP GUI for Java statt, welches auf einer kleinen Linux VM läuft. Parallel starte eine Reihe weiterer Abläufe, die jeweils einen Benutzer darstellen. Diese können in verschiedene Benutzergruppen unterteilt werden (Controller, Management, Power- oder Standard-User etc.).
Hierbei galt es lediglich die spezifischen Use Cases zu berücksichtigen, um das zu testende SAP-System zuverlässig unter Last-Situationen zu vermessen und Performance-Daten gezielt zu erfassen.
Steuerung des Testmanagements
Die unterschiedlichen Tests werden in einfach zu bearbeitenden JSON-Dateien definiert und können so auch per Script gesteuert angepasst werden. Nachdem alle Tests durchlaufen sind, lassen sich mit einem weiteren alle zuvor angelegten Benutzer wieder entfernen. Tests von browserbasierten Oberflächen wie etwa Fiori-Apps sind ebenso wie Tests durch das SAP GUI zu handhaben. Die Tester nutzten die von SAP unterstützen Browser Chrome und Firefox.
Skalierung bei adäquatem Hardware-Aufwand
Was die Skalierbarkeit angeht, galt die Anforderung, Performance-Tests mit angemessenem Hardware-Aufwand im Bereich von mehr als 10.000 Benutzern durchführen zu können. Skalierbarkeit in der Hardware war bereits durch openQA gegeben, Multinode konnte dort problemlos in der Oberfläche konfiguriert werden.
Da allerdings jeder Test eine virtuelle Maschine auf dem openQA-Server darstellt, wurden einige Optionen im Linux-Speicher-Management untersucht. Die besten Ergebnisse erzielte dabei der Einsatz von KSM (Kernel Samepage Merging). Hierbei werden Speicherseiten, die sich nicht unterscheiden, nur einmal im Arbeitsspeicher abgelegt und allen Prozessen präsentiert, die sie benötigen.
Weitere Speicher-Tricks wie eine Arbeitsspeicher-Komprimierung mit ZRAM (Virtual Swap Compressed in RAM, auch zSwap; früher als „compcache“ bekannt) wurden wieder verworfen, da sie sich vergleichsweise aufwändig für die CPU gestaltet hätten. Was die CPUs angeht: Für die Arbeitslast im Testumfeld empfiehlt sich eine große Anzahl an Kernen, etwas anderes war angesichts des hohen Grades der Parallelisierung auch nicht zu erwarten.
Eine umfangreiche Testumgebung kann viele einzelne ersetzen
Die Quintessenz: Durch die Vielzahl an verschiedenen Aufgaben, die man mit openQA lösen kann, reduziert sich die Menge der unterschiedlichen Tools, die sonst eingesetzt werden müssten, erheblich. Man kann mit der Lösung sinnvolle Ergänzungen von SAP und umgebenden Systemen schaffen und gleichzeitig den Arbeitsaufwand durch den hohen Grad der Automatisierung niedrig halten.
Beim Arbeiten mit openQA finden sich ferner immer wieder neue Ansätze zur Verwendung. Sei es das Durchführen standardisierter Nacharbeiten an System-Kopien, aber auch einfache Tätigkeiten wie Passwort-Änderungen. Durch die integrierte Kontrolle aller durchgeführten Schritte in den jeweiligen Tests kann der Erfolg der Tätigkeiten kontrolliert und auch dokumentiert werden.
Dieser Beitrag erschien zuerst im E-3 Magazin.
