Replay-basiertes Testen verteilter Anwendungen - Allgemeines

Labor für Verteilte SystemeFH-Wiesbadenhttp://wwwvs.cs.hs-rm.de/projekte/replaytest.pdfReplay-basiertes Testen verteilterAnwendungenBeteiligte an der Hochschule• Prof. Dr. Reinhold Kröger• Dipl.-Inform. (FH) Holger MachensKooperationspartner• Siemens AG CT, MünchenLaufzeitBeginn: 01.12.2004Ende: 30.10.2009Finanzierung• 100% Siemens AG CTVeröffentlichungen• Kröger, Reinhold; Machens, Holger: "Replay von nebenläufigenAnwendungen", Technischer Bericht, Fachhochschule Wiesbaden,Fachbereich Informatik, Januar 2006• Kröger, Reinhold; Machens, Holger: "MOST Log Parser fürEclipse/TPTP", Technischer Bericht, Fachhochschule Wiesbaden,Fachbereich Design Informatik Medien (DCSM), Oktober 2006• Machens, Holger; Kröger, Reinhold: "MOST QA Tools - QualityAssurance für MOST-Bus-Applikationen im TPTP Test Framework aufEclipse", Labor für Verteilte Systeme, Fachhochschule Wiesbaden, Juli2007• H. Machens; R. Kröger; S. Jell; K. Grabenweger: "Replay-basiertesTesten von MOST-Bus-Anwendungen im Automotive-Umfeld",Gesellschaft für Informatik, Lecture Notes in Informatics, Bonn,Software Engineering 2008, Seite 85, Vol. 91, Lecture Notes inInformatics, ISBN: 978-3-88579-215-4, Februar 2008KurzbeschreibungDas Testen ist seit jeher ein fester Bestandteil der Softwareentwicklung.Seite: 1

Labor für Verteilte SystemeFH-Wiesbadenhttp://wwwvs.cs.hs-rm.de/projekte/replaytest.pdfZu den Testzyklen, die der Entwickler heute meist unmittelbar nachFertigstellung einzelner Code-Fragmente manuell oder automatischdurchführt, wurden insbesondere für komplexere Anwendungenentsprechend aufwendige Testverfahren entwickelt, um dasZusammenspiel der verschiedenen Softwarekomponenten besserbeurteilen zu können. Hauptsächliches Merkmal von Testkomponenten imAllgemeinen ist das Erzeugen von Stimuli am zu testenden System(System Under Test, SUT), wie z.B. das Drücken einer Schaltfläche aufeiner grafischen Oberfläche oder Methodenaufrufe an Komponenten derAnwendung. Durch das automatisierte Erzeugen einer Folge von Stimuliwill man das SUT dazu bringen, bestimmte Testfälle zu durchlaufen unddas Verhalten in den verschiedenen Testfällen ebenso automatisiertprüfen zu können.Unterstützt wird dieses Verfahren durch Aufnahme-Werkzeuge (Captureoder Recording Tools), die zur Aufnahme der Stimuli während der Eingabedurch den Tester dienen. Die Aufnahme dient dann als Vorlage für dieTestkomponenten, von denen sie wieder abgespielt werden. Solche Toolssind z.B. aus dem Bereich GUI Testing (z.B. Abbot) und Web-Testingbekannt.Das Replay von Aufnahmen aus nebenläufigen Anwendungen wirft eineReihe spezifischer Probleme auf, die in dieser Arbeit eine besondereBeachtung finden. Für sequenzielle Anwendungen bestehen dieseProbleme nicht bzw. sie bilden in Bezug auf die Replay-Fähigkeit nur eineUntergruppe der nebenläufigen Anwendungen und werden hier nichtweiter betrachtet.In dem Projekt wurde ein Konzept für ein Testsystem erarbeitet, das einReplay in verteilten, nebenläufigen Anwendungen erlaubt. Das erarbeiteteKonzept wurde bereits für CORBA-Anwendungen realisiert, wobei auchdie Integration in die Entwicklungsumgebunghttp://www.eclipse.org/berücksichtigt wurde, basierend auf der Testing and Profiling ToolsPlatform (http://www.eclipse.org/tptp, ehemals bekannt unter dem Namen Hyades) als Automated SoftwareQuality Framework (ASQ).Das Vorgehen des Testers orientiert sich an dem Prinzip des ASQ, wie esauch von TPTP vorgestellt wird:• Aufnahme: Das Durchführen eines exemplarischen Laufs zurErfassung des Verhaltens der Anwendung bildet die Vorbereitungeines Tests. Das Ergebnis dieses Schritts ist die Aufnahme (auchRecord oder Trace), die die Basis für ein späteres Abspielen (Replay)darstellt.• Import: Das Einlesen der Aufnahme dient zum einen zur Überführungin ein editierbares Format, und zum anderen kann in diesem Schrittdas im Trace meist unvollständige Wissen über das Verhalten derAnwendung manuell ergänzt werden. Hier könnte alternativ auch einUML-Modell oder ähnliches als Quelle für den Import dienen.Seite: 2

Labor für Verteilte SystemeFH-Wiesbadenhttp://wwwvs.cs.hs-rm.de/projekte/replaytest.pdf• Editieren: Die importierten Stimuli können nachträglich verändertwerden, um Spezialfälle herbeizuführen. Editieren kann aber auch alsAlternative für das Recording dienen, wenn der Tester den Testfallmanuell eingeben will.• Testgenerierung: Das Replay wird von einem Testsystem durchgeführt.Dieses Testsystem kann entweder die Aufnahme als Input bekommenund wie ein Skript dynamisch interpretieren oder die Aufnahme hartkodiert enthalten. Für die letztere Variante wird im allgemeinen einGenerator eingesetzt, der die Testkomponenten des Testsystemsgeneriert.• Replay: Durch das Replay wird die Folge der im Test enthaltenenStimuli wieder abgespielt. Während des Replays werden dieReaktionen des SUT beobachtet und verifiziert. Das Ergebnis desTestlaufs ist ein Testurteil.In der Abbildung ist schematisch die Architektur für ein Replay Systemdargestellt. Darin sind symbolisch die folgenden Komponenten enthalten:• Die Testkomponenten, die ein oder mehrere Komponenten derAnwendung simulieren.• Das System under Test (SUT), das sich aus einer oder mehreren zutestenden Komponenten der Anwendungen zusammensetzt.• Ein Synchronizer als zentrale Komponente, die zur Synchronisationdes Auftretens der Ereignisse im gesamten System (bestehend ausSUT und Testkomponenten) entsprechend dem konserviertenVerhalten aus der Aufnahme, das in gefilterter und aufbereiteter Formals Ereignisplan bereitgestellt wird.SUT und Testkomponenten werden für das Replay-basierte Testen umzwei Funktionalitäten ergänzt. Die auftretenden Ereignisse werden auchwährend des Testlaufs, also während des Replays, protokolliert.Desweiteren werden die auftretenden Ereignisse synchronisiert mit demgeplanten Ablauf im Ereignisplan, was durch synchrone Methodenaufrufenam Synchronizer realisiert ist.Basierend auf einer eingehenden Analyse des Themas unterEinbeziehung vorhandener Arbeiten aus den Bereichen Replay undSeite: 3

Labor für Verteilte SystemeFH-Wiesbadenhttp://wwwvs.cs.hs-rm.de/projekte/replaytest.pdfTesting im Sinne von Automated Software Quality wurde ein allgemeinesKonzept für ein entsprechendes Rahmenwerk erstellt, das beideThemengebiete umfasst. Hierbei wurde auch der gängige StandardUML2TP für die Modellierung von Tests und Testumgebungenberücksichtigt. Wichtiges Ergebnis der Analyse war u.a. die Sammlungvon Anwendungsfällen für das Replay-basierte, automatisierte Testen inverteilten Anwendungen.Besonderheit des Konzepts ist die ausführliche Betrachtung vonEreignisplänen für das Replay und deren verschiedene Ausprägungen inrealen Anwendungen. Hier wurden maßgebliche Klassifizierungenvorgenommen, die dem Kommunizieren und Entwickeln vonReplay-basierten Systemen eine professionelle Grundlage verleihen.Der "Proof of Concept" wurde durch die Realisierung des Frameworks ineiner CORBA-Umgebung auf Basis des Open Source Testing und TracingFrameworks TPTP durchgeführt. Hier wurde in einer 1. Version ein globallineare Ordnung der Ereignisse während des Replays erzwungen, wasbedeutet, dass alle Ereignisse nach ihrem Zeitstempel geordnet wiederauftreten.In einem anschließenden Projekt wurde in Zusammenarbeit mit der VDOAutomative AG als assoziierten Partner an einer Verwendung derentwickelten Konzepte für das Testen von MOST-Bus-Anwendungen(Media Oriented Systems Transport, siehehttp://www.mostcooperation.com/) in der Automotive Domäne gearbeitet.Der MOST-Bus ist ein Infotainment-Bus, der hohe Datenraten für denTransport von Multimedia-Daten im Fahrzeug bereitstellt, alsobeispielsweise für die Übertragung des Bildes einer Heckkamera auf einDisplay im Fahrzeug. Die Kommunikation in einer MOST-Applikation weisteinen hohen Anteil an zyklisch gesendeten Statusmeldungen auf, wie esbeispielsweise auch in Feldbussystemen der Automatisierungstechnik derFall ist. Dieser zyklische Nachrichtenverkehr ist auch im ``Ruhezustand''des Systems als ständiges Hintergrundrauschen vorhanden undüberlagert auch den eigentlichen Kontrollfluss der Anwendung, alsosolche Nachrichten, die einem bestimmten Use Case zuzuordnen wären.Das Konzept für das Replay von klassischen, RPC-basiertenAnwendungen, wie es für CORBA realisiert wurde, war wegen desnebenläufigen Hintergrundrauschens in MOST-Applikationen nichtausreichend. Eine Berücksichtigung des Hintergrundrauschens alsnebenläufiges Kommmunikationsverhalten war allerdings inakzeptabel, daes zu komplizierten Testbeschreibungen führen würde, die vom Benutzernur noch sehr schwer zu handhaben wären. Die Anzahl der Nachrichten,die einem zu untersuchenden Anwendungsfall zuzuordnen sind, ist gegendas Hintergrundrauschen sehr gering und damit für den Benutzer leichthandhabbar.Das Replay-Verfahren wurde daher durch zwei entscheidendeKomponenten ergänzt.Seite: 4

Labor für Verteilte SystemeFH-Wiesbadenhttp://wwwvs.cs.hs-rm.de/projekte/replaytest.pdf• Die für den Anwendungsfall relevante Sequenz von Nachrichten wirdhändisch selektiert und in ein "Validierungsmuster" übernommen.Dieses Validierungsmuster dient während des Replays zurÜberprüfung der Reaktionen des SUTs (Antwortnachrichten aufStimuli).• Das Hintergrundrauschen wird durch einen Rauschfilter ausgeblendet.Er wird gewöhnlich mit den Nachrichten gefüllt, die in der Aufnahme alsHintergrundrauschen enthalten sind und nicht dem Validierungsmusterzuzuordnen sind.Zur Evaluierung wurde das gesamte Verfahren als Plugin-Sammlung aufEclipse/TPTP realisiert und in einer Experimentalumgebung bei VDOeingesetzt.Bei dem aktuellen Vorhaben im Rahmen des fortgesetztenKooperationsprojektes steht nun die UntersuchungPerformance-orientierter Test- und Analyse-Techniken basierend auf demReplay von Kommunikations-Traces im Vordergrund. AlsAnwendungsdomäne wurden hierfür moderne Service-OrientierteArchitekturen auf Web-Services-Technologien gewählt. Im ersten Schrittwurde hier auf Basis von Eclipse/TPTP eine einfache Testumgebung fürWeb Services realisiert, die eine modellgetriebene Testentwicklunghalbautomatisch unterstützt. Im weiteren Verlauf wird der Fokus stärkerauf Workflow-orientierte Anwendung verlagert. Ziel ist hierbei diebestehenden Forschungsansätz zur automatischen modellgetriebenenTestentwicklung für Workflows mit dem Replay-basiertenRegressionstesten zu verschmelzen und eine Bewertungen hinsichtlichverschiedenere Testabdeckungsgrade zu ermöglichen.Seite: 5