Case Study Mit Last- und Performance-Tests („LuP-Tests“) soll das Verhalten von IT-Systemen bei realitätsnaher Belastung untersucht werden, um etwaige Designschwächen oder Ressourcenengpässe möglichst frühzeitig zu erkennen. Eine Automatisierung solcher Tests unterstützt die zielgerichtete Entwicklung und Optimierung maßgeblich, wodurch letztlich trotz des zusätzlichen Aufwands Kosten eingespart werden können. Um aussagekräftige Ergebnisse zu erhalten, müssen die Tests die gesamte Verarbeitungskette des Systems umfassen, es müssen also End-to-End-Tests („E2E-Tests“) durchgeführt werden, was je nach Applikationsstruktur unterschiedlich komplex werden kann. Unser Kunde, eine Behörde in München, wollte eine Test-Infrastruktur für eine komplexe Client/Server-Applikation (klassische Architektur mit Rich Client und Backend) aufbauen und beauftragte uns mit der Erarbeitung und praktischen Bestätigung eines Konzepts für UI-basierte Last- und Performance-Tests. Kunde: Staatliche Behörde in München Projekt: Konzeption von LuP-Tests für eine hochkomplexe Client/Server-Applikation zur Akten- und Vorgangsverwaltung Teamgröße: 3 Eingesetzte Tools: Silk Performer von Microfocus
Herausforderung Architektur für aussagefähige, automatisierte LuP-Tests einer komplexen Client/Server-Applikation Der Kunde betreibt eine komplexe Client/Server-Applikation mit einem Java-Client, der mehrere andere, eigenständige Applikationen integriert und dadurch aus User-Sicht als ein einziger sogenannter Rich Client erscheint. Dementsprechend besteht das zugehörige Backend eigentlich aus mehreren, eigenständigen Backends und Datenbanken. Die Performance des Gesamtsystems ist generell nicht besonders hoch, wobei die individuelle Performance der einzelnen integrierten Applikationen stark differiert. Für eine dieser Applikationen wurde bereits eine API für die Durchführung von LuP-Tests implementiert, diese erlaubt aber weder vollständige E2E-Tests, noch kann damit eine Aussage über die anderen Applikationsbestandteile getroffen werden. Dementsprechend beschränkten sich die Möglichkeiten zur Bewertung der Systemperformance auf subjektive Benutzerrückmeldungen und einzelne, handgestoppte Zykluszeiten für typische Arbeitsabläufe. Eine belastbare Einschätzung der Veränderung der Performance durch Optimierungen oder sonstige Software-Updates war damit nicht möglich. Ebenso wenig konnten Aussagen über die Skalierungsfähigkeit des Systems und das zu erwartende Verhalten bei steigenden Nutzerzahlen getroffen werden. Um genau solche Aussagen und Abschätzungen zukünftig besser und objektiver treffen zu können, soll eine geeignete Test-Infrastruktur aufgebaut werden. Doch wie soll diese Lösung genau aussehen? Obwohl der Wunsch nach einer solchen Test-Infrastruktur in vielen Projekten in gleicher oder ähnlicher Form existiert, gibt es keine Standardlösung, die für alle Einsatzbereiche gleichermaßen gut funktioniert. Für die Konzeption einer geeigneten Lösung sollte daher zunächst der konkrete Anwendungsfall analysiert und das Ergebnis der Konzeptionsarbeit in der Praxis bestätigt werden, bevor die Entscheidung zum weiteren Vorgehen getroffen wird. Lösung Performance-Messung mit Silk-Performer durch Steuerung des Clients per Citrix Player Der Einstieg in das Thema erfolgte in Form eines Workshops zur Bestandsaufnahme mit allen relevanten Fachbereichen (Key-User, Rechenzentrum, Testmanagement, Releasemanagement, etc.). Dabei wurde neben der Beschreibung der technischen Struktur und Arbeitsweise des Gesamtsystems auch beleuchtet, wie generell das Testing im Projekt organisiert ist und welche möglichen Optionen für die LuP-Tests der Kunde bereits in Betracht gezogen hat. Dabei rückten sehr schnell die Produkte Silk Test und Silk Performer von Microfocus in den Fokus, da diese im Hause bereits an anderer Stelle eingesetzt werden. Der Silk Performer erlaubt das Messen von Prozesszeiten und Systemlast beim Durchlauf vordefinierter Programmabläufe, während Silk Test für die UI-zentrierte Testautomatisierung eingesetzt wird. Da der Silk Performer damit praktisch gesetzt war, konzentrierte sich die weitere Arbeit auf die Frage, über welche Schnittstelle bzw. auf welchem Weg der Zugriff auf die Ziel-Applikation erfolgen soll. Zunächst wurde ein protokoll-basierter Ansatz in Erwägung gezogen. Dabei müsste der Silk Performer den Rich Client der Applikation teilweise emulieren und direkt die entsprechenden Client-Interfaces der verschiedenen Backends ansprechen. Schnell zeigte sich, dass ein solches Vorgehen schon aufgrund der Vielzahl an unterschiedlichen Backends und Protokolle sehr komplex geworden wäre. Zudem wären das Verhalten und der Einfluss des Clients völlig unbeachtet geblieben. Die naheliegende Alternative war, zusätzlich Silk Test zu nutzen, um den vorhandenen Client fernzusteuern und dabei Laufzeiten und Systemlast mit Silk Performer zu messen. Da dabei insbesondere auch das User Interface und der Client-Code in vollem Umfang und realitätsnah mitberücksichtigt wird, ist dieser Weg gut dazu geeignet, die E2E-Performance des Systems in einer Einzelplatzinstallation detailliert und bequem zu vermessen. Um jedoch eine Last von mehreren hundert Benutzern simulieren zu können, müsste man ebenso viele Client-Systeme aufsetzen und dort jeweils den sogenannten Silk Test Agent installieren. Um die Anzahl an physischen Client-Systemen zu begrenzen, gingen die Überlegungen schnell in Richtung Virtualisierung und Terminalserver-Strukturen. Leider limitiert der Speicherhunger der Client-Applikation (4 GB bereits unmittelbar nach dem Start) die Anzahl der virtuellen Clients pro physischem System sehr stark. Ein etwas besseren Verhältnis als die Installation und Nutzung des Silk Test Agents im virtuellen Client-System versprach die nativ im Silk Performer mögliche Fernsteuerung von Citrix-Systemen. Nachteil der Citrix-Fernsteuerung war wiederum die Abstraktionsebene für die Implementierung der Fernsteuerung: Bei der Nutzung von Silk Test ist der Kontext der Applikation zugänglich, d.h. die Fernsteuerung kann Steuerelemente (Buttons, Menüs, etc.) direkt adressieren. Die Steuerung über den Citrix-Client hingegen erlaubt lediglich eine Navigation über Pixel-Positionen und die Erkennung von Text unter Nutzung von OCR. Diese und weitere Vor- und Nachteile der verschiedenen, möglichen Optionen wurden herausgearbeitet, dokumentiert, mit dem Kunden besprochen und sorgfältig abgewogen. Schließlich fiel die Entscheidung, die Variante mit der Nutzung des Citrix Players weiterzuverfolgen und im Rahmen eines Proof of concept (PoC) die Eignung für das Projekt nachzuweisen und ein erstes Framework für die Umsetzung der Tests zu entwerfen. Nachdem die Citrix-Infrastruktur vom Rechenzentrum zur Verfügung gestellt wurde, konnte sofort mit der Umsetzung einfacher Testfälle begonnen werden. Bereits in dieser Phase zeigten sich die erwarteten Auswirkungen der pixel-basierten Adressierung der Steuerelemente. Insgesamt erwies sich die Lösung aber als ausreichend tragfähig, um in einem Folgeprojekt mit der Umsetzung der konkreten Testfälle beginnen zu können. Mehrwert Fundierte Erkenntnisse als Basis für die Entscheidung zum weiteren Vorgehen Die sorgfältige Prüfung und transparente Darstellung verschiedener Alternativen bei bestmöglicher Berücksichtigung der kundenspezifischen Rahmenbedingung erlaubte eine bewusste Gestaltung der Test-Infrastruktur. Zusammen mit den Erkenntnissen aus dem PoC und den Ergebnissen der dabei implementierten Testfälle bestätigte sich bereits im Rahmen der Konzeptphase, dass die Zielsetzung der geplanten Last- und Performance-Tests mit der gewählten Konfiguration erreicht werden kann: Vergleich der Performance verschiedener Software-Versionen (Client und Backend) Aussagen über das Client- und Backend-Verhalten unter Last Reproduzierbares Nachstellen von performancebezogenen Benutzermeldungen zur zielorientierten Optimierung und Verifikation der getroffenen Maßnahmen Auf dieser Basis konnte die Ausschreibung für ein Folgeprojekt zur Umsetzung weiterer Testfälle und dem Aufbau eines vollständigen Test-Ökosystems inklusive Testdatenmanagement formuliert werden. Das im Rahmen des PoC erstellte Basis-Framework kann wiederverwendet und erweitert werden. Aufgrund des generischen Ansatzes ist es gutmütig gegenüber der Integration weiterer Teil-Applikationen und deren Technologien. Die Herausforderung, eine geeignete Infrastruktur für automatisierte UI-basierte Last- und Performance-Tests auszuwählen und deren Leistungsfähigkeit im Rahmen eines Proof of concept zu bestätigen, konnte erfolgreich gemeistert werden. Die Entscheidung, den Silk Performer von Microfocus zusammen mit dem Citrix Player zu nutzen, um den komplexen Rich Client zu steuern und zu vermessen, ist tragfähig und kann als Grundlage für ein Folgeprojekt zur Erstellung realitätsnaher Testfälle verwendet werden. Die gewonnen Erkenntnisse über Möglichkeiten und Grenzen der verschiedenen Ansätze lassen sich sicher auch auf andere, ähnlich gelagerte Projekte übertragen. Wir freuen uns darauf, Sie in Ihrem Projekt zur Testautomatisierung zu unterstützen.