Graphische Testfallmodellierung mit UML Expertenwissen in Bildern? Dipl.-Ing. Volker Knollmann Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie
Motivation Verbesserungspotential bei Testfallbeschreibungen Beispiel: Betrieb des Eisenbahnsimulationslabors RailSiTe interne Tests: notwendig bei Updates / Laborvalidierung externe Tests: Überprüfung von Kundengeräten Beispiel: Tests für das European Train Control System (ETCS) Testsequenzbeschreibung als Worddatei veröffentlicht Geschwindigkeitsprofil als Bitmap verfügbar Beispiel: Simulation bahnbetrieblicher Szenarien Betriebsregeln nur in Prosa definiert Validierung neuer Eisenbahnleit- und -sicherungssysteme aufwändig Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 2
Gliederung des Vortrags Anforderungen / Komponenten von Testfallbeschreibungen Das UML 2 Testing Profile (U2TP) Anwendung des U2TP im Rahmen einer Fallstudie Ausblick auf weitere Arbeiten Fazit Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 3
Abgrenzung des Kontextes Hier nur Betrachtung von Black-Box-Tests Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 4
Anforderungen an Testfallbeschreibungen Editierbar, automatisierbar, archivierbar, rückverfolgbar Verwendung von UML (Unified Modeling Language) Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 5
Komponenten einer Testbeschreibung Struktur, Verhalten, Daten und zeitliche Bedingungen Statische Anteile (Struktur): Aufbau und Konfiguration der Testumgebung Verwendete Schnittstellen Dynamische Anteile (Verhalten): Testschritte Sollergebnisse, Reaktion bei Abweichung vom Sollverhalten Ableitung der Testbewertung (bestanden / nicht bestanden) Daten und zeitliche Randbedingungen: Stimuli, Telegramme, Datenpakete Timer, Timeouts Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 6
Das UML 2 Testing Profile (U2TP) OMG -Standard seit Juli 2005 Definiert Symbole, Stereotypen und Tags für Testfallbeschr. Baut auf UML 2 auf Schafft semantische Eindeutigkeit der Beschreibung Deckt die vorgenannten Modellaspekte ab Anwendbar auf allen Testebenen (z. B. Modultest, Systemtest, ) Werkzeug- und plattformneutral Nicht domänenspezifisch Object Management Group Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 7
Komponenten des Moduls Test Architecture Testaufbau als Klassen- und Strukturdiagramm Prüfling ( System under Test, SUT) Testkomponenten: Sind Teil der Testumgebung Interagieren mit dem SUT (Stimuli / Reaktionen) Arbiter: Empfängt und bewertet Rückmeldungen der Testkomponenten Fällt Gesamturteil über Testergebnis Scheduler: Steuerung des zeitlichen Testablaufs Starten / Stoppen einzelner Testkomponenten Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 8
Zusammenspiel der Architektur-Komponenten Der Testkontext integriert Komponenten zum Testaufbau «SUT» System Under Test «Interface» General Arbiter «Interface» General Scheduler * sut «implement» «implement» «TestComponent» Test Component «TestComponent» Test Component n Specific Arbiter Specific Scheduler * component_ * component_n arbiter * scheduler «TestContext» Specific Test Context «TestCase» tc_ () «TestCase» tc_2 () «TestCase» tc_n () Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 9
Daten- und Steuersignalfluss in der Testumgebung Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 0
Beschreibung des Testverhaltens Nutzung von Sequenz-, Aktivitäts- und Zustandsdiagr. Nutzung der gängigen UML-Verhaltensdiagramme Testablauf beispielsweise als Sequenzdiagramm Einführung sogenannter defaults : Definieren Reaktion bei Abweichung vom Sollverhalten Entspricht dem Aufruf einer Fehlerbehandlungsroutine Fehlerbehandlung wird separat modelliert ( Übersichtlichkeit!) Mögliche Reaktionen: Wiederholung, Ignorieren, Abbruch Verhaltensdefinition von Scheduler und Arbiter Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie
Beispiel einer einfachen Arbiter-Implementierung Hier: fällt eine Worst-Case-Entscheidung / setverdict[v == fail]/ Overall result is "pass" setverdict[v == inconc]/ setverdict[v == error]/ Overall result is "fail" Overall result is "inconclusive" setverdict[v == error]/ Overall result is "error" setverdict[v == error]/ setverdict[v == fail]/ Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 2
Beispiel einer Testablaufbeschreibung Austausch synchroner und asynchroner Nachrichten «TestComponent» :Test Component «TestComponent» :Test Component n «SUT» :System Under Test Stimulus Stimulus : <Return Value> Message default HandleResponse Message 2 «validationaction» pass «validationaction» pass Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 3
Gegenstand der Fallstudie System zur Erzeugung von Transpondersignalen Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 4
Gegenstand der Fallstudie Eigenschaften des untersuchten RS232-Protokolls Transportierte Inhalte: Die per Transpondersignal zu übertragenden Daten Zeitprofil für die Datenübertragung Steuerkommandos (Reset, Statusabfragen, etc) Protokoll: Paketorientiertes Protokoll Zweischichtig: Link-Layer- und Applikationsebene Aufgaben des Link-Layers: Verwaltung von Sequenznummern Vollständigkeitsprüfung der Pakete (Längeninformation) Prüfsummenkontrolle Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 5
Vorgehen im Rahmen der Fallstudie Testfallableitung, Testdatenerzeugung, Modellierung Methodische Ableitung von Testfällen mit Klassifikationsbäumen Erzeugung zugehöriger Datenpakete (Testdaten) Modellierung der sog. Datenpools und der Testumgebung in UML (Prüflingsmodell lag bereits in UML vor) Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 6
Testfallableitung mit Klassifikationsbäumen Basiert auf Partitionierung des Zustandsraumes Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 7
Anordnen der Testdaten in einem Datenpool Insgesamt wurden 4 Testfälle erzeugt Smallest Valid Frame haslengthfield hasseqnumber haschksum payloadsize = 0x00 Invalid Checksum haslengthfield hasseqnumber haschksum payloadsize = 0x02 Oversized Length Indicator haslengthfield hasseqnumber haschksum payloadsize = 0x02 data = [00 00 00 0 00 08 00 09] data = [00 00 00 0 00 0A FF... «DataPool» Link Layer Test Frames data = [00 00 00 0 FF FF 42 4... Undersized Length Indicator haslengthfield hasseqnumber haschksum payloadsize = 0x02 data = [00 00 00 0 00 00 42 4... Single Byte payloadsize = 0x00 data = [00] Missing Checksum haslengthfield hasseqnumber payloadsize = 0x02 data = [00 00 00 0 00 08 FF FF] Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 8
Integration aller Komponenten zum Testkontext Hier nur oberste Ebene dargestellt; Details sind hinterlegt Link Layer Test «TestContext» LinkLayer Context «TestCase» shortestvalidframe () : Verdict «TestCase» invalidchecksum () : Verdict «TestCase» missingchecksum () : Verdict «TestCase» oversizedlengthindicator () : Verdict «TestCase» undersizedlengthindicator () : Verdict «TestCase» singlebyte () : Verdict sut pc «SUT» Balise Simulation System «TestComponent» Stimulation PC Data Pools «import» «DataPool» Link Layer Test Frames Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 9
Beispiel einer Testsequenz Wiederverwendung anderer Sequenzen ist möglich «TestComponent» Instance /pc:stimulation PC ref ref short telegram storage long telegram storage «SUT» Instance /sut:balise Simulation System DefAndRunSeq «validationaction» pass Acknowledge( TRANSMISSION OK, 0x0000 ) Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 20
Ergebnisse und Bewertung der Fallstudie Die Vorteile überwiegen Vorteile: Modularer Aufbau, Wiederverwendung von Komponenten Übersichtliche, formale Darstellung; gute Editier- und Wartbarkeit Erfassung des Testaufbaus (wird häufig vergessen) Nahtlose Integration mit Systemmodell möglich Nachteile: Einarbeitung in UML und U2TP erforderlich Viele Diagramme, daher saubere Strukturierung notwendig Für komfortables Arbeiten ist gutes UML-Tool unerlässlich Initial höherer Aufwand als bei traditionellen Methoden Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 2
Ausblick: Übergang zur Testautomatisierung Verschiedene Ansätze sind denkbar Konvertierung UML XMI Testskript: Übersetzung in ein ausführbares Skript (z. B. Python oder Ruby) Ausführen des Skriptes in der Testumgebung Direktes Ausführen von XMI in der Testumgebung: Erstellung eines entsprechenden XMI-Interpreters Positiv: Erstellung eines ausführbaren Skriptes entfällt Konvertierung in alternative Datenformate: Nutzung von XSLT 2 zur Konvertierung in andere XML 3 -Formate Alternativ: Übergang auf TTCN-3 4 Mapping U2TP TTCN-3 existiert bereits XML Metadata Interchange; 2 extensible Stylesheet Language Transformation; 3 extensible Markup Language; 4 Testing and Test Control Notation, Version 3 Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 22
Fazit Expertenwissen in Bildern? U2TP-Darstellung von Testfällen ist übersichtlich, einheitlich, formal Nur für Black-Box-Tests vorgesehen Geeignete Grundlage für Testautomatisierung Aufbau von Bibliotheken möglich Konservierung, nicht Ersatz des Expertenwissens durch Bilder Entlastung des Testern von Routineaufgaben Kein Ersatz für die Kreativität des Testers Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 23