Graphische Testfallmodellierung mit UML – …...Verwendung von UML (Unified Modeling Language)...

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


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


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


Abgrenzung des KontextesHier nur Betrachtung von Black-Box-Tests


Anforderungen an TestfallbeschreibungenEditierbar, automatisierbar, archivierbar, rückverfolgbar

Verwendung von UML(Unified Modeling Language)


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


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


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


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»


Daten- und Steuersignalfluss in der Testumgebung


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


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]/


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



Gegenstand der FallstudieSystem zur Erzeugung von Transpondersignalen


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


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)


Testfallableitung mit KlassifikationsbäumenBasiert auf Partitionierung des Zustandsraumes


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»


Invalid Checksum

data = [00 00 00 01 00 0A FF ...

«Frame»


Oversized Length Indicator

data = [00 00 00 01 FF FF 42 4 ...

«DataPool»Link Layer Test Frames

«Frame»


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


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



1

1

sut

11

pc

«import»


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 )



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


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


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

Graphische Testfallmodellierung mit UML – …...Verwendung von UML (Unified Modeling Language)...

Documents

Transcript of Graphische Testfallmodellierung mit UML – …...Verwendung von UML (Unified Modeling Language)...