Verteilte Testautomatisierung mit STAF/STAX

Transkript

1 Verteilte Testautomatisierung mit STAF/STAX Markus Rentschler, Jens Zobel, Embedded Software Engineering Kongress, Sindelfingen, Das Software Testing Automation Framework (STAF) ermöglicht die einfache Realisierung von großen verteilten Testautomatisierungssystemen in einer Peer-to-Peer- Architektur. STAX ist eine Ausführungsumgebung zur komfortablen Benutzung von STAF. Es stellt eine mächtige XML-basierte Skriptsprache zur Verfügung und bietet eine GUI zur übersichtlichen Darstellung der Testdurchläufe und Testresultate. 1. Einleitung Unter Software-Testautomatisierung wird allgemein die werkzeugunterstützte Prüfung von Software oder mit Software betriebenen Systemen verstanden. Der englische Begriff hierfür lautet Computer Aided Software Testing (CAST). Im IT-Umfeld also beim Test von Anwendungssoftware- wird die Testautomatisierung oft auf demselben System ausgeführt wie die zu testende Software. Dieser Ansatz wird auch Software-In-The-Loop (SIL) genannt. Im Fall von Embedded Systemen müssen die Hardware-Schnittstellen des Device under Test (DUT) programmgesteuert bedient werden können. Diesen Ansatz nennt man Hardware-In-the-Loop (HIL), in diesem Fall findet die Testdurchführung auf einem separaten System statt. Arten von Testautomatisierung

2 2. Elemente eines Testvorgangs Testen allgemein umfasst im Wesentlichen die folgenden Schritte: 1. Testfälle definieren und erstellen, jeweils bestehend aus Testschritten, Eingabedaten und erwartetem Resultat. 2. Testfall auswählen aus einer Anzahl von vorhandenen Testfällen. 3. Testfall ausführen (Execution) 4. Testausführung überwachen (Monitoring) 5. Testergebnis prüfen (Evaluation) 6. Testergebnis protokollieren (Documentation, Reporting) Wenn während der Testdurchführung -also vom Ausführungsstart bis zur Ergebnismeldungkeine manuellen Eingriffe benötigt werden, wird ein Testfall als automatisiert angesehen. Die Motivation einer Testautomatisierung liegt meist in der Einsparung von Zeit und Kosten sowie der sicheren Reproduzierbarkeit der Testfälle. 3. Regressionstest Bei einer inkrementellen Software-Entwicklung also wenn von Version zu Version der Funktionsumfang der zu testenden Software erweitert wird- müssen immer wieder dieselben Tests wiederholt werden. Denn jede Softwareversion muss vor ihrer Freigabe immer zwingend vollständig getestet werden, also nicht nur die neu hinzugekommene, sondern auch die schon in der Vorgängerversion enthaltene Funktionalität. Testautomatisierung ist zur Durchführung von solchen Regressionstests ökonomisch sinnvoll und weit verbreitet. 4. Variantentest Wenn eine Software eine größere Anzahl von Produktvarianten unterstützt, ist die Rechtfertigung für Testautomatisierung ebenfalls meist sehr schnell gegeben, da in diesem Fall dieselben funktionalen Tests auf multiplen Systemvarianten durchgeführt werden müssen. Hierzu ist der Einsatz eines verteilten Testautomatisierungssystems naheliegend, um diese Vorgänge parallelisieren zu können. Ein konkretes Beispiel ist in [1] dargestellt. Verteilte Testautomatisierung

3 Die Effizienz von Testautomatisierung ist vor allem dann sehr hoch, wenn Variantentests und Regressionstests in Kombination durchgeführt werden. 5. Verteilte Testautomatisierung Sobald mehrere PCs zur Durchführung einer Testautomatisierung verwendet werden, müssen die Aktivitäten dieser Testknoten von einem zentralen Test-Management-Rechner koordiniert und gesteuert werden. Im Einzelnen entstehen dabei folgende Anforderungen an das Testautomatiserungssystem: Zentrale Verwaltung von Testskripten, Testprogrammen und zu testende Softwareversionen Verteilung der Testskripte und Programme auf die Testknoten Ausbringung der zu testenden Software auf die DUTs Starten des Testablaufs auf den Testknoten Koordination bzw. Synchronisation der Abläufe auf den Testknoten Asynchrone Rückmeldung der Ergebnisse von den Testknoten an die Teststeuerung Darstellung der Testergebnisse auf der Teststeuerung Zugriffsschutzmechanismen bei weit verteilten Systemen über ein offenes Netzwerk Diese Anforderungen können mittels des Open-Source-Framework STAF/STAX abgedeckt werden, welches die notwendigen Funktionalitäten zur Steuerung solcher verteilten Anwendungen bietet [2]. 6. STAF Das Software Test Automation Framework (STAF) wurde von IBM entwickelt und als Open Source freigegeben. Es wird von einer aktiven Community kontinuierlich weiterentwickelt. Die grundlegende Idee von STAF ist, dass auf jedem beteiligten Rechner eine Art Remote Procedure Call (RPC)-Agent läuft. STAFProc wird dieser STAF-Agent genannt, der an einem TCP-Port (default ist 6500) auf STAF-spezifische Kommandos wartet. Die von STAF bereitgestellten Services sind sehr umfangreich und bilden sogar teilweise die Mechanismen von Echtzeitbetriebssystemen nach. So kann man bspw. rechnerübergreifend Semaphoren, Events und Variablen definieren oder Dateisystemoperationen durchführen. Da alle STAF- Knoten denselben Funktionsumfang bereitstellen, spricht man auch von einer Peer-to-Peer- Architektur. Von STAF bereitgestellte interne Services Delay Service: verzögert die Ausführung von Befehlen File System (FS) Service: Ermöglicht Dateioperationen Handle Service: Erlaubt Zugriff auf STAF-Handles Help Service: Übersicht über Parameter aller Services und deren Returncodes LifeCycle Service: Service zum Behandeln von STAF Requests Log Service: Zugriff auf die STAF Logfiles Misc Service: Verschiedene hilfreiche Funktionen (WHOAMI, VERSION usw.) Monitor Service: Verwaltet Statusmeldungen von Testfällen Ping Service: Prüft Erreichbarkeit von Knoten im Netzwerk Process Service: Erlaubt konsolenbasierte Programmaufrufe

4 Queue Service: Zugriff auf die Queues von STAF-Handles Resource Pool (ResPool) Service: Verwaltet verteilte Ressourcen Semaphore (SEM) Service: Erlaubt knotenübergreifende Semaphoren (z.b. Event-, Mutual Exclusion) Service Service: Erlaubt Zugriff auf STAF-Services Shutdown Service: Beendet STAF Trust Service: Zugriffsrechte für die einzelnen Knoten verwalten Variable (VAR) Service: Erlaubt globale Variablen im STAF-Verbund Zip Service: integrierter Packer/Entpacker Zusätzlich installierbare externe Services: Cron, , Event, EventManager, FSExt (File System Extension), FTP, HTTP, NamedCounter, Namespace, SXE (Staf execution Engine), Timer, STAX 7. STAX STAX (STAf execution engine) ist ein javabasiertes Testautomatisierungssystem, das aus einer XML-basierten Jobbeschreibungssprache und zugehöriger Execution Engine besteht. STAX wird als externer Service in STAF eingebunden und kann somit die von STAF zur Verfügung gestellten Services nutzen. STAX-Jobs sind XML Skriptdateien, mit denen durch eingebetteten PYTHON Code auch komplexere Aufgaben durchgeführt werden können. Durch Verwendung des Process Service können aus diesen Jobs heraus beliebige Anwendungen gestartet werden, z.b. Testskripte in anderen Sprachen. Über seine GUI-Elemente ermöglicht STAX die komfortable Ausführung und Kontrolle von solchen Jobs. Der sog. Job Monitor zeigt die aktiven Prozesse für jeden Job an und auch die Testfallinformationen (Testfallname, PASS/FAIL-Status, Dauer) für jeden Test in der Testsuite, bietet also die notwendige Funktionalität für das Testausführungsmanagement inklusive einer leistungsfähigen Logging-Funktionalität und Debugmöglichkeiten. STAX Job Script und Job Monitor

5 STAX bietet eine leistungsfähige Umgebung für Automatisierungsskripte, da sämtliche wichtigen Kontrollstrukturen unterstützt werden, wie z.b. IF/THEN/ELSE Konstrukte, Schleifen und Variablen. Besonders hervorzuheben sind folgende Elemente: <process>: Führt beliebige konsolenbasierte Anwendungen aus <command>: Führt ein STAF - Kommando aus <script>: Führt PYTHON - Code aus <sequence>: Arbeitet Kommandos der Reihe nach ab <parallel>: Arbeitet Funktionen parallel ab <paralleliterate>: Parallelverarbeitung über die Elemente eine Liste <message>: Ausgabe von benutzerdefinierten Nachrichten in die STAX Oberfläche oder das STAX-Logfile 8. Einbindung anderer Testtools Die Verwendung von STAF mit seinem Process -Service erlaubt sehr einfach die Einbindung vorhandener anderer Testtools. Diese entweder kommerziellen oder selbstgeschriebenen Anwendungen müssen als einzige Voraussetzung über die Kommandozeile bedienbar sein. Ihr Rückgabewert muss entweder direkt an den aufrufenden Prozess zurückgegeben werden oder es muss ein Logfile generiert werden, welches das aufrufende Skript parsen und auswerten kann. 9. Zusammenfassung Nach mehr als drei Jahren intensiver Erfahrung mit STAF/STAX konnten keine gravierenden Einschränkungen festgestellt werden. Durch den Einsatz von eingebetteten Skripten lassen sich flexible Lösungen mit geringem Aufwand realisieren, wobei sowohl PYTHON- als auch JAVA-Bibliotheken in vollem Umfang genutzt werden können. STAF/STAX kann daher als ausgereiftes Automatisierungsframework empfohlen werden, welches jederzeit die schnelle Realisierung einer flexiblen Testautomatisierung ermöglicht. Folgende Einschränkungen wurden im Beobachtungszeitraum festgestellt: <parallel> Anwendbar nur mit Funktionen und Prozessen. Das bedeutet, man muss parallel auszuführende Codeteile in eigene Funktionen implementieren. Das bläht vor allem durch die dann notwendige Parameterübergabe den Code auf. <sem> Das Triggern von Event-Semaphoren kann fehlschlagen, wenn der zu triggernde PC überlastet ist. Dann geht der Event einfach verloren. Empfehlenswert wäre, hier ein Event- System mit Acknowledgement einzusetzen. <process> Wird ein TCL - Script mit spawn/expect von STAX aufgerufen und dort der Parameter <returnstdout> genutzt, entzieht STAX dem TCL - Script einfach den STDOUT, und die Scriptausführung schlägt fehl.

6 Literatur [1] Rentschler, Pflieger, Gölz: "Software-Tests mit STAF/STAX: Qualität und Produktivität der Prozesse durch Automatisierung steigern", ELEKTRONIK 24/2007, WEKA-Verlag. [2] STAF/STAX im Web: Autoren: Markus Rentschler studierte bis 1993 Nachrichtentechnik an der Fachhochschule Konstanz und Digital Systems Engineering an der Heriot-Watt-University in Edinburgh. Er verfügt über mehr als 15 Jahre Erfahrung in der Embedded Software Entwicklung und -Qualitätssicherung. Seit 2007 leitet er bei Hirschmann Automation and Control das neuaufgebaute Systemtestteam. Jens Zobel absolvierte bei Hirschmann eine gewerblich-technische Ausbildung zum Mechatroniker und war seit der Endphase seiner Ausbildung in 2006 bei der Aufstellung der neuen Systemtestabteilung dabei. Er ist zuständig für die Instandhaltung und Weiterentwicklung der Testautomatisierungslösungen.