Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 1Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Graphische Testfallmodellierung mit UML –Expertenwissen in Bildern?Dipl.-Ing. Volker Knollmann
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 2Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
MotivationVerbesserungspotential bei Testfallbeschreibungen
Beispiel: Betrieb des Eisenbahnsimulationslabors RailSiTe®
interne Tests: notwendig bei Updates / Laborvalidierungexterne Tests: Überprüfung von Kundengeräten
Beispiel: Tests für das European Train Control System (ETCS)Testsequenzbeschreibung als Worddatei veröffentlichtGeschwindigkeitsprofil als Bitmap verfügbar
Beispiel: Simulation bahnbetrieblicher SzenarienBetriebsregeln nur in “Prosa” definiertValidierung neuer Eisenbahnleit- und -sicherungssysteme aufwändig
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 3Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Anforderungen / Komponenten von Testfallbeschreibungen
Das „UML 2 Testing Profile“ (U2TP)
Anwendung des U2TP im Rahmen einer Fallstudie
Ausblick auf weitere Arbeiten
Fazit
Gliederung des Vortrags
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 4Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Abgrenzung des KontextesHier nur Betrachtung von Black-Box-Tests
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 5Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Anforderungen an TestfallbeschreibungenEditierbar, automatisierbar, archivierbar, rückverfolgbar
Verwendung von UML(Unified Modeling Language)
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 6Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Komponenten einer TestbeschreibungStruktur, Verhalten, Daten und zeitliche Bedingungen
Statische Anteile (Struktur):Aufbau und Konfiguration der TestumgebungVerwendete Schnittstellen
Dynamische Anteile (Verhalten):TestschritteSollergebnisse, Reaktion bei Abweichung vom SollverhaltenAbleitung der Testbewertung (bestanden / nicht bestanden)
Daten und zeitliche Randbedingungen:Stimuli, Telegramme, DatenpaketeTimer, Timeouts
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 7Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Das UML 2 Testing Profile (U2TP)OMG1-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änenspezifisch1 Object Management Group
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 8Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Komponenten des Moduls „Test Architecture“Testaufbau als Klassen- und Strukturdiagramm
Prüfling („System under Test“, SUT)
Testkomponenten:Sind Teil der TestumgebungInteragieren mit dem SUT (Stimuli / Reaktionen)
Arbiter:Empfängt und bewertet Rückmeldungen der TestkomponentenFällt Gesamturteil über Testergebnis
Scheduler:Steuerung des zeitlichen TestablaufsStarten / Stoppen einzelner Testkomponenten
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 9Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Zusammenspiel der Architektur-KomponentenDer Testkontext integriert Komponenten zum Testaufbau
«Interface»General Arbiter
«Interface»General Scheduler
Specific Arbiter Specific Scheduler«TestComponent»Test Component 1
«TestComponent»Test Component n
«TestContext»Specific Test Context
«TestCase» tc_1 ()«TestCase» tc_2 ()«TestCase» tc_n ()
«SUT»System Under Test
*1
component_1 *1
component_n 11
arbiter *1
scheduler
*
1
sut
«implement» «implement»
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 10Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Daten- und Steuersignalfluss in der Testumgebung
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 11Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Beschreibung des TestverhaltensNutzung 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 SollverhaltenEntspricht dem Aufruf einer FehlerbehandlungsroutineFehlerbehandlung wird separat modelliert ( Übersichtlichkeit!)Mögliche Reaktionen: Wiederholung, Ignorieren, Abbruch
Verhaltensdefinition von Scheduler und Arbiter
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 12Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Beispiel einer einfachen Arbiter-ImplementierungHier: fällt eine Worst-Case-Entscheidung
Overall result is "pass"
Overall result is "fail" Overall result is "inconclusive"
Overall result is "error"
/
setVerdic t[v == inconc]/setVerdic t[v == fail]/
setVerdic t[v == error]/
setVerdic t[v == error]/ setVerdic t[v == error]/
setVerdic t[v == fail]/
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 13Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Beispiel einer TestablaufbeschreibungAustausch synchroner und asynchroner Nachrichten
:System Under Test«SUT»
:Test Component 1«TestComponent»
:Test Component n«TestComponent»
Stimulus 1
Stimulus 1 : <Return Value>
Message 1
Message 2defaultHandleResponse
«validationAction»pass
«validationAction»pass
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 14Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Gegenstand der FallstudieSystem zur Erzeugung von Transpondersignalen
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 15Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Gegenstand der FallstudieEigenschaften des untersuchten RS232-Protokolls
Transportierte Inhalte:Die per Transpondersignal zu übertragenden DatenZeitprofil für die DatenübertragungSteuerkommandos (Reset, Statusabfragen, etc)
Protokoll:Paketorientiertes ProtokollZweischichtig: Link-Layer- und Applikationsebene
Aufgaben des Link-Layers:Verwaltung von SequenznummernVollständigkeitsprüfung der Pakete (Längeninformation)Prüfsummenkontrolle
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 16Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Vorgehen im Rahmen der FallstudieTestfallableitung, 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 17Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Testfallableitung mit KlassifikationsbäumenBasiert auf Partitionierung des Zustandsraumes
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 18Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Anordnen der Testdaten in einem DatenpoolInsgesamt wurden 41 Testfälle erzeugt
«Frame»
«Frame»hasLengthFieldhasSeqNumberhasChkSumpayloadSize = 0x00
Smallest Valid Frame
data = [00 00 00 01 00 08 00 09]
«Frame»
«Frame»hasLengthFieldhasSeqNumberhasChkSumpayloadSize = 0x02
Invalid Checksum
data = [00 00 00 01 00 0A FF ...
«Frame»
«Frame»hasLengthFieldhasSeqNumberhasChkSumpayloadSize = 0x02
Oversized Length Indicator
data = [00 00 00 01 FF FF 42 4 ...
«DataPool»Link Layer Test Frames
«Frame»
«Frame»hasLengthFieldhasSeqNumberhasChkSumpayloadSize = 0x02
Undersized Length Indicator
data = [00 00 00 01 00 00 42 4 ...
«Frame»
«Frame»payloadSize = 0x00
Single Byte
data = [00]
«Frame»
«Frame»hasLengthFieldhasSeqNumberpayloadSize = 0x02
Missing Checksum
data = [00 00 00 01 00 08 FF FF]
1
1 1
1
1
1
1
1
1
1
1
1
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 19Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Integration aller Komponenten zum TestkontextHier 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
«TestComponent»Stimulation PC
«SUT»Balise Simulation System
«TestContext»LinkLayer Context
«TestCase» shortestValidFrame () : Verdict«TestCase» invalidChecksum () : Verdict«TestCase» missingChecksum () : Verdict«TestCase» oversizedLengthIndicator () : Verdict«TestCase» undersizedLengthIndicator () : Verdict«TestCase» singleByte () : Verdict
«TestComponent»Stimulation PC
«SUT»Balise Simulation System
Data Pools
«DataPool»Link Layer Test Frames
«DataPool»Link Layer Test Frames
1
1
sut
11
pc
«import»
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 20Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Beispiel einer TestsequenzWiederverwendung anderer Sequenzen ist möglich
Instance/pc:Stimulation PC
«TestComponent»Instance
/sut:Balise Simulation System
«SUT»
ref short telegram storageref short telegram storage
ref long telegram storageref long telegram storage
DefAndRunSeq
Acknowledge( TRANSMISSION OK, 0x0000 )
«validationAction»pass
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 21Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Ergebnisse und Bewertung der FallstudieDie Vorteile überwiegen
Vorteile:Modularer Aufbau, Wiederverwendung von KomponentenÜbersichtliche, formale Darstellung; gute Editier- und WartbarkeitErfassung des Testaufbaus (wird häufig vergessen)Nahtlose Integration mit Systemmodell möglich
Nachteile:Einarbeitung in UML und U2TP erforderlichViele Diagramme, daher saubere Strukturierung notwendigFür komfortables Arbeiten ist gutes UML-Tool unerlässlichInitial höherer Aufwand als bei traditionellen Methoden
Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 22Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
Ausblick: Übergang zur TestautomatisierungVerschiedene Ansätze sind denkbar
Konvertierung UML XMI1 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 XSLT2 zur Konvertierung in andere XML3-FormateAlternativ: Übergang auf TTCN-34
Mapping U2TP TTCN-3 existiert bereits
1 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 23Institut für Verkehrsführung und Fahrzeugsteuerung > Technologien aus Luft- und Raumfahrt für Straße und Schiene
FazitExpertenwissen 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