Software und Performance Testing lizenzkostenfrei mit Open-Source-Mitteln durchzuführen klingt verlockend.
Doch funktioniert das Ganze auch unter Bedingungen von Hochskalierbarkeit? Ist es auf agile Arbeitsmethoden anwendbar?
Und können SAP GUI- und Fiori Interaktionen abgebildet werden?
Richtiggehende Zweifel hatte das Test-Team der FIS-ASP nicht, als es sich diese Fragen stellte. Der besonderen Anforderungen an die Software jedoch war man sich durchaus bewusst. Um es vorwegzunehmen:
Zur Enttäuschung wurde der Versuch nicht, im Gegenteil.
Die Aufgabenstellung: Software und Performance-Tests von SAP-Systemen sollten mit Open-Source-Mitteln durchgeführt werden.
Das hierfür auserkorene Projekt OpenQa war ursprünglich von SUSE entwickelt worden 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 Quellcodeverwaltung. 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 Soundsamples analysieren kann, stand schnell fest: Die Aufgaben würden nicht unlösbar sein. 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 Testteam der FIS-ASP 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: Ein ursprünglich sehr hoch geschätzter Aufwand für ein solches Projekt verringert sich enorm, 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 entwickelte FIS-ASP verschiedene Szenarien: 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.
Danach startete parallel eine Reihe weiterer „Tests“, die jeweils einen Benutzer darstellen.
Diese können in verschiedene Benutzergruppen unterteilt werden (Standard-User, Power-User, Controller, Management etc.).
Hierbei galt es lediglich die unternehmensspezifischen Use Cases zu berücksichtigen, um zuverlässig das zu testende SAP-System unter Lastsituationen zu vermessen und Performancedaten gezielt zu erfassen.
Steuerung des Testmanagements
Die unterschiedlichen Tests werden in einfach zu bearbeitenden JSON-Dateien definiert und können so auch scriptgesteuert angepasst werden. Nachdem alle Tests gelaufen sind, lassen sich mit einem weiteren alle zuvor angelegten Benutzer in SAP wieder entfernen.
Tests von browserbasierten Oberflächen wie etwa Fiori Apps sind ebenso handzuhaben wie Tests durch das SAP GUI.
Die Tester bei FIS-ASP nutzten hier sowohl Chrome als auch Firefox als von der SAP unterstützte Browser.
Skalierung bei adäquatem Hardware-Aufwand
Was die Skalierbarkeit angeht, galt die Anforderung, im Bereich von mehr als 10.000 Benutzern Performancetests mit angemessenem Hardwareaufwand durchführen zu können. Skalierbarkeit in 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, untersuchte FIS-ASP hier einige Optionen im Linux-Speicher-Management. 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 Speichertricks wie eine Arbeitsspeicherkomprimierung 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 nach Systemkopien , oder 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.
Autor: Manuel Sammeth, Teamleiter für Platform Services bei FIS-ASP