TTCN-3

Andreas SchlegelHochschule Offenburg

schlegel.andreas@googlemail.com

19.12 .2010

Abstract: Das Testen komplexer Systeme,besonders im Bereich verteilter Systeme, ge-staltet sich oft sehr schwierig. Dies ist be-dingt durch das Zusammenwirken verschie-dener Komponenten mit unterschiedlicherHardware und Plattformen. Für diese Kom-ponenten werden die selben Testfälle ent-wickelt, jedoch aufgrund der Unterschiedemeistens für jede Komponente einzeln imple-mentiert. Dies verursacht einen erheblichenMehraufwand, der besonders auch beim Än-dern von Testfällen sehr hoch ist. Um diesenAufwand zu minimieren ist eine gemeinsameTestsprache notwendig, in der alle Testfälleerstellt werden können.

Dieses Paper stellt die Testsprache TTCN-3vor. TTCN-3 ist eine einheitliche technologie-unabhängige Testsprache für kommunika-tionsbasierte, verteilte Systeme und bietetdadurch eine Lösung für diese Probleme.

1 Einleitung

Die rasante Weiterentwicklung im IT-Bereich,besonders im Bereich der Hardware- und Platt-formentwicklung, führt immer mehr zu Schwie-rigkeiten beim Testen verteilter Systeme. Hier-durch kommt es immer häufiger zum Einsatzvon verteilten Systemen mit Komponenten, diesich in Hardware oder Plattform unterscheiden.Auch der Austausch bestehender Komponentenverursacht zusätzlichen Testaufwand, weil meis-tens aufgrund der schnellen Entwicklung nichtunbedingt die gleichen Komponenten beschafftwerden können. Besonders das Testen von Pro-tokollen ist für Gerätehersteller aufgrund der

schnell wechselnden Hardware- und Software-Landschaft oft sehr zeitaufwändig, da Tests fürjedes neu entwickelte Gerät neu implementiertwerden müssen.

TTCN-3 bietet eine einheitliche, technologieun-abhängige Testsprache, wodurch die Testfällenicht bei Hardware- oder Plattformänderungenangepasst werden müssen. Das Framework istModular aufgebaut, wodurch nur noch gering-fügige Änderungen in sogenannten Adapterndurchgeführt werden müssen, welche jedochunabhängig von den Testfällen implementiertwerden. Zuletzt muss die Testsuite lediglich fürdas Zielsystem erstellt werden. Dadurch lassensich Testfälle einmalig definieren und bei Wech-sel von Komponenten müssen nicht die Testfäl-le, sondern lediglich die Module, die von derPlattform oder Hardware abhängen, angepasstwerden. Sind diese Module einmal implemen-tiert, können sie für gleiche Komponenten ohneÄnderungen übernommen werden.

Durch Verwenden von TTCN-3 können Fehlervermieden werden, da bestehende Testfälle nichtneu implementiert werden müssen, sondern wei-ter verwendet werden können. Besonders beimÄndern vorhandener Testfälle ist es lediglichnotwendig, die Änderungen einmal in einer ge-meinsamen Testsuite vorzunehmen und nichtdie Testfälle in allen hardwarespezifischen Pro-jekten einzeln zu ändern.

In den folgenden Kapiteln wird auf die Entwick-lung von TTCN-3, seine Struktur, die Darstel-lungsformen der Core Language und Einsatz-bereiche eingegangen und zuletzt Trends aufge-zeigt.

1

2 Historie und Entwicklung

Die Entwicklung von TTCN-3 begann 1984, wo-bei lediglich eine Testsprache für Konformitäts-tests für OSI-Protokollimplementierungen vor-gesehen war (TTCN). Erst mit der Standardisie-rung von TTCN-3 entstand daraus eine techno-logieunabhängige Sprache, die für das Testenjeglicher Art reaktiver, verteilter Systeme ge-eignet und nicht auf Kommunikationssystemebeschränkt war.

2.1 TTCN

TTCN wurde 1992 als ”Tree and Tabular Com-bined Notation” ursprünglich als Teil des ISO-Standards 9646 Open Systems Interconnection(OSI) – Conformance Testing Methodology andFramework speziell für die Spezifikation vonTestfällen für das Konformitätstesten von OSI-Protokollimplementierungen standardisiert [8].TTCN wurde nur für das Testen von Kommu-nikationssystemen, vor allem zum Testen vonGSM (Global System for Mobile Communicati-ons), dem weltweit populärsten Mobilfunkstan-dard verwendet.

2.2 TTCN-2

TTCN-2 wurde im Jahr 1997 durch die ETSI(European Telecommunication Standards Insti-tute) zertifiziert und von der International Te-lecommunication Union (ITU-T) angenommen.Die wichtigsten Neuerungen in dieser Versionwaren:

• Modularisierung• Parallele Tests• Teilweise Unterstützung von ASN.1 (Ab-

stract Syntax Notation One) als Schnittstel-le

TTCN-2 wurde für die Unterstützung weite-rer Kommunikationsprotokolle erweitert. AußerGSM konnten auch die Protokolle ISDN, DECTund INAP mit TTCN-2 getestet werden.

2.3 TTCN-3

Im Jahr 2000 folgte TTCN-3, welches auf Nach-frage führender Hersteller der Telekommunika-tionsindustrie von der ETSI und der Internatio-nal Telecommunication Union (ITU-T) entwi-ckelt und von der ETSI zertifiziert wurde. DerName wurde von ”Tree and Tabular CombinedNotation” in ”Testing and Test Control Notati-on” geändert, da ab dieser Version nicht mehrnur eine tabellarische Darstellung der Spracheermöglicht wurde, sondern auch eine grafische.Die Abkürzung blieb erhalten. Diese Versionbrachte gravierende Änderungen mit sich.

Die größte Änderung in dieser Version war,dass diese nicht mehr nur speziell auf das Tes-ten von Telekommunikationssystemen ausge-legt war. TTCN-3 ermöglicht das Testen jeg-licher Art von reaktiven, verteilten Systemenmit wohldefinierten Schnittstellen [13]. Hier-durch wurden neue Testarten, wie funktiona-le Tests, Leistungstests, Skalierungstests, Inte-roperabilitätstests und inzwischen auch Last-tests, Performance Tests und Real-Time Testsermöglicht. [12]. Ab dieser Version wurde außer-dem nicht nur nachrichten-orientierte, sondernauch prozedurale Kommunikation unterstützt,wodurch TTCN-3 noch universeller einsetzbarwurde.

Weitere Änderungen sind:

• Änderungen an Syntax und Semantik(skriptähnlich)

• Synchrone und asynchrone Kommunika-tion möglich

• Unterstützung von ASN.1 und IDL (Inter-face Definition Language) als Schnittstel-len

• XML und WSDL zum Testen von Webser-vices

• Testdefinition über skriptähnliche Spracheoder grafisch möglich

• Definierte Schnittstellen und Module

Die Hauptkomponenten von TTCN-3 sind ineinzelnen ”Parts” in separaten Dokumenten spe-zifiziert und versioniert. Außerdem sind Erwei-terungen vorhanden, welche auch in separatenDokumenten spezifiziert wurden.

2

Nachfolgend sind die Hauptkomponenten vonTTCN-3 aufgeführt:

• Part1 Core Language• Part2 Tabular presentation Format (TFT)• Part3 Graphical presentation Format (GFT)• Part4 Operational Semantics• Part5 Runtime Interface (TRI)• Part6 Control Interface (TCI)• Part7 Using ASN.1 with TTCN-3• Part8 The IDL to TTCN-3 Mapping• Part9 Using XML schema with TTCN-3• Part10 Documentation Comment Specifi-

cation

Zuletzt wurde die Version 4.2.1 des Standardsim Juli 2010 aktualisiert. Alle Hauptkomponen-ten der Spezifikation befinden sich auf diesemStand, außer Part2 und Part3, welche sich nochauf Version 3.2.1 (Stand 2007) befinden.

3 Struktur von TTCN-3

TTCN-3 ist in verschiedene Module geglie-dert, bei denen einige vom zu testenden Sys-tem (SUT) oder von der verwendeten Plattform,auf der das TTCN-3 Executable ausgeführt wird,abhängen. Diese müssen beim Wechsel der Platt-form oder des zu testenden Systems angepasstwerden. Die Kommunikation zwischen den ein-zelnen Modulen ist über definierte Schnittstellenfestgelegt.

Abb. 1: Modulübersicht TTCN-3[6][13]

Abbildung 1 zeigt einen Überblick über dieStruktur von TTCN-3 mit allen Modulen undden dazwischen liegenden Schnittstellen.

3.1 Module

TE (TTCN-3 Executable)Das TE ist für die Ausführung des TTCN-3-Code verantwortlich. Das TE kann ein ausführ-bares Programm sein oder über eine Laufzeitum-gebung realisiert werden, da dies im Standardnicht festgelegt ist. Dieses Modul ist die zentra-le Instanz von TTCN-3, die über spezifizierteSchnittstellen mit allen anderen Modulen ver-bunden ist.

TM (TTCN-3 Management)Im TM werden sämtliche Tests, die ausgeführtwerden sollen registriert, gestartet und zuletztderen Ergebnis gespeichert.

TL (TTCN-3 Logging)Das TL ist für die Anpassung der Logausgabenzuständig. In diesem Modul können alle Ereig-nisse der Laufzeitumgebung festgelegt werden,für die ein Logeintrag erstellt werden soll. Au-ßerdem ist es in diesem Modul möglich die For-matierung der Ausgabe der Logdaten zu beein-flussen.

CH (Component Handling)Das CH ist für die Kommunikation der einzel-nen Testkomponenten untereinander zuständig.Da diese auch auf verschiedenen Testgerätenverteilt sein können, muss mit dem CH die Kom-munikation zwischen den einzelnen Komponen-ten gesteuert werden.

CD (Coding and Decoding)Das CD ist verantwortlich für das Decodie-ren und Encodieren von Daten bei nachrichten-oder prozedurbasierter Kommunikation mit demSUT. Diese ”externen Codecs” sind optional.Bei Verwendung können diese parallel oder an-statt der im TE vorhandenen Codecs verwendetwerden. Der Vorteil der externen Codecs ist diePortabilität zwischen verschiedenen TTCN-3-Systemen und -Tools aufgrund der Verwendungdes standardisierten TTCN-3-Control Interface[7].

3

PA (Plattform Adapter)Der PA ist für die Anpassung verwendeter Sys-temfunktionen, wie z.B. Timer, an die verwen-dete Plattform zuständig. Er muss beim Wechselder Plattform angepasst werden.

SA (SUT-Adapter)Das SA ist für die Kommunikation mit demSUT zuständig. Es implementiert Funktionendes TRI (TTCN-3 Runtime Interfaces) für dienachrichten- und prozedurbasierte Kommuni-kation mit dem SUT. Dieses Modul muss beiÄnderungen am SUT angepasst werden.

3.2 Schnittstellen

TTCN-3 Runtime Interface (TRI)Das TTCN-3 Runtime Interface bietet Funktio-nen um ein Test System an die verwendete Platt-form und das SUT anzupassen. Hierzu werdenverschiedene Funktionen zur Kommunikationmit dem SUT und zum Anpassen plattformspe-zifischer Komponenten, wie z.B. Timern, zurVerfügung gestellt. [6]

TTCN-3 Control Interface (TCI)Das TTCN-3 Control Interface bietet Funktio-nen zur Anpassung des Test Management, Com-ponent Handling und Encoding and Decodingan eine bestimmte Test-Plattform an. [7]

3.3 Vorteile der Struktur

Durch die Spezifikation der Module und Schnitt-stellen wird die Implementierung und der Ein-satz von TTCN-3-basierten Tools erleichtert.Dies ermöglicht es den Toolherstellern TTCN-3flexibler zu implementieren. Für Programmierer,welche die Tools einsetzen, ermöglicht es einengrößeren Freiraum durch Implementierung eige-ner Codecs und Möglichkeiten für spezifischeAnpassungen der Adapter.

Beim Wechsel von Plattform oder SUT müs-sen lediglich die ”Adapter” angepasst werden.Sind Module für bestimmte Plattformen oderSUT vorhanden, können diese bei Verwendunggleicher SUT oder Plattformen wiederverwen-det werden. Falls für die Kommunikation mitdem SUT spezielle externe Codecs verwendet

werden, muss zusätzlich das Modul Coding andDecoding implementiert werden.

Durch die Schnittstellen-Spezifikation ist esmöglich, dem Kunden die Implementierung derAdapter-Module sowie des Moduls für die ex-ternen Codecs selbst zu überlassen. Dies ermög-licht SUT- und plattformunabhängige Testsui-ten, da die Anpassung auf die Bedürfnisse desKunden beim Kunden selbst stattfindet. Es be-steht jedoch auch die Möglichkeit für bestimmteCodecs, Plattformen und SUT fertige Implemen-tierungen anzubieten.

Ein Toolhersteller, der keine spezifischen Mo-dule bereitstellt, muss lediglich die ModuleTTCN-3 Executable, TTCN-3 Management,TTCN-3 Logging und Component Handlingvollständig implementieren. Für die Module Co-ding and Decoding, Plattform Adapter und SUT-Adapter muss dem Kunden ein einfaches Inter-face bereitgestellt werden.

Die Modularisierung ermöglicht die Ausführungder Tests für unterschiedliche SUT und Plattfor-men in einer gemeinsamen Testsuite. Bei Wech-sel der Plattform oder des SUT müssen dadurchlediglich die Adapter angepasst werden. Ein An-passen oder erneutes Implementieren der Test-fälle ist dadurch nicht mehr notwendig. [6]

4 Core Language

Die Sprache TTCN-3 ist eine reine Testspracheund eignet sich besonders zum Testen von re-aktiven Systemen, wie eingebetteten Systemen,Echtzeitsystemen, sowie Kommunikationsproto-kollen. Sie bietet verschiedene definierte Schnitt-stellen, wie ASN.1, IDL, XML und WSDL fürdas Einbinden externer Datendefinitionen undverschiedene Darstellungen mit denen ein Be-nutzer Testfälle erstellen kann (Abbildung 2).

Es gibt drei vordefinierte, standardisierte Dar-stellungen, die TTCN-3 dem Benutzer zur Er-stellung von Tests zur Verfügung stellt.

• Text-Format (Core Notation)• Tabellarisches Format• Grafisches Format

4

Abb. 2: Übersicht Core Language[4]

Zusätzlich zu den im Standard spezifizierten For-maten, können Hersteller weitere Darstellungs-formate bereitstellen. Diese müssen sich ledig-lich in das Text-Format konvertieren lassen.

Nachfolgend werden die einzelnen Formate er-läutert und anhand des ”altstep”-Konstrukts vonTTCN-3 beispielhaft die Umsetzung in die ver-schiedenen Formate aufgezeigt.

4.1 Text-Format (Core Notation)

Das Text-Format, die sogenannten Core Notati-on, ist die Basissprache von TTCN-3 und wirdvon den drei Darstellungsformaten am häufigs-ten eingesetzt. Die Core Notation unterstütztalle Konstrukte der Core Language. Alle Dar-stellungsformate müssen zunächst in die CoreNotation überführt werden, da diese vom Com-piler bzw. Interpreter als Eingabesprache verar-beitet wird.

Das Beispiel in Listing 1 zeigt ein altstep-Konstrukt von TTCN-3. Bei Aufruf dieses Kon-strukts wird auf das Eintreffen eines der dreierwarteten Ereignisse gewartet und darauf rea-giert:

• Ereignis1: Eintreffen einer Nachricht vomTyp ”MyMessageOne” von PC1 mit derBedingung ”x < 5”Aktion : Testergebnis auf ”bestanden” set-zen, Neuberechnung von x

• Ereignis2: Eintreffen einer beliebigenNachricht von PC2Aktion : Wiederholen des altstep

• Ereignis3: Ablaufen des Timers T1Aktion : Testergebnis auf ”fehlgeschlagen”setzen

Listing 1: altstep Text-Format1 altstep MyAltstep() runs on

MyComponentType2 {3 [x<5] PC1Port.receive(MyMessageOne}4 {5 setverdict(pass);6 x := 7 + 5;7 }8 [] PC2Port.receive()9 {10 repeat;11 }12 [] T1.timeout13 {14 setverdict(fail);15 }16 }

4.2 Tabellarische Darstellung

Die tabellarische Darstellung ist das älteste Dar-stellungsformat von TTCN-3. Es wurde haupt-sächlich aus Kompatibilitätsgründen zur Vor-gängerversion, für die einfachere Migration vonTTCN-2 zu TTCN-3 spezifiziert und hat kei-ne praktische Relevanz mehr [12][13]. DiesesDarstellungsformat prägte auch den Namen vonTTCN ”Tree and Tabular Combined Notation”.Jedoch ist die Verwendung im Gegensatz zurCore Notation sehr aufwändig.

AltstepName MyAltstepGroupRuns On MyComponentTypePurposeCommentLocal Def Name Type Initial Value Comment

Behaviour[x<5] PC1Port.receive(MyMessageOne) {setverdict(pass);x := 7 + 5;}[] PC2Port.receive() {repeat;}[] T1.timeout {setverdict(fail);}Detailed Comments

Abb. 3: Tabellarische Darstellung [2]

Abbildung 3 zeigt die tabellarische Darstellungdes altstep-Beispiels von Listing 1 (Abschnitt4.1).

5

4.3 Grafische Darstellung

Die Grafische Darstellung basiert auf Messa-ge Sequence Charts (MSC), ähnlich zu UML-Sequenzdiagrammen.

Abb. 4: Grafische Darstellung [3]

Abbildung 4 zeigt die grafische Darstellung desaltstep-Beispiels von Listing 1 (Abschnitt 4.1).

Abb. 5: Von GFT unterstützte Konstrukte [11]

Mit der grafischen Darstellung sind jedoch nichtalle Konstrukte der Core Language darstellbar.Diese müssen in der Core Notation erstellt wer-den. Abbildung 5 veranschaulicht, welche Kon-strukte nicht unterstützt werden. In der grafi-schen Darstellung lassen sich lediglich Kon-strukte visualisieren, die mit dem Testablaufverknüpft sind. Dies sind die Module Execu-tion Control, Testcase, Function und Altstep.

Daten-Konstrukte, wie Deklarationen, Defini-tionen und Parameter, werden somit nicht unter-stützt.

Durch zusätzliche Elemente in TTCN-3-Testsuiten kann dies jedoch ermöglicht werden.Hierfür müssen jedoch zusätzliche grafische Ele-mente zum Erstellen von Datentypen bereitge-stellt werden. Dadurch kann ein Benutzer derTestsuite ohne Kenntnisse der Core Notationauch alle notwendigen nicht unterstützten Kon-strukte erstellen.

5 Einsatzbereiche

Seit der Veröffentlichung von TTCN-3 habensich auch dessen mögliche Einsatzbereiche ver-größert. Einige der Einsatzbereiche sind Auto-motive, Grid Computing, IEEE Protokolle, Me-dical Systems, Real-Time Testing, HiL-Testing,MBT, Safety Critical Systems, Telekommunika-tionsprotokolle und Web Services. Im Anschlusswird auf die Themen Automotive, HiL-Testingund MBT eingegangen.

5.1 Automotive

Die Qualitätssicherung von softwareintensivenSystemen in der Automobilindustrie hatte bishereinen geringen Anteil automatischer Tests undeine Vielzahl an oft proprietären Testsystemenund -plattformen.

Im Gegensatz dazu steht das Automotive OpenSystems Architecture (AUTOSAR) Konsorti-um. AUTOSAR strebt die Standardisierung ei-ner Softwarearchitektur und -plattform für dieAutomobilindustrie an und hat sich dort inzwi-schen etabliert. Bei einem größeren Pilotpro-jekt entschied AUTOSAR sich für die funktio-nalen Tests seiner BasissoftwarekomponentenTTCN-3 zu verwenden. Seit Release 4 2009werden zudem Echtzeit-Anforderungen sowieTiming unterstützt. [9]

AUTOSAR verwendet die Mappingschnittstel-le der TTCN-3 Core Language (Abbildung 6),um eigene Datentypen, Werte und Schnittstelleneinzubinden.

6

Abb. 6: TTCN-3 AUTOSAR Mapping [10]

Für die Spezifikation der Komponenten wer-den im Automotive-Bereich verbreitet Messa-ge Sequence Charts, teilweise sogar TTCN-3-GFT verwendet. Da TTCN-3 in der grafischenDarstellung Message Sequence Charts anzeigt,kann ein theoretischer Entwurf einer Testse-quenz schnell in die Praxis umgesetzt und gegenein Steuergerät oder eine Simulation getestetwerden. Die Erkenntnisse aus der Praxis kön-nen dann sofort wieder in die Spezifikations-phase mit einfließen, wodurch die Entwicklungbeschleunigt wird.

Einzelheiten zur Verwendung von TTCN-3 beiAUTOSAR können dem Abschnitt 5.2 in denTeilabschnitten ”Testen von Einzelkomponen-ten” und ”Integrationstests für Komponenten”entnommen werden.

5.2 HiL-Testing

Beim Hardware in the Loop-Testing wird dasSystem, in dem die zu entwickelnde Kompo-nente arbeitet, komplett oder teilweise simuliert.Dadurch lassen sich Tests an realen Systemenstark verringern, da diese zunächst in der simu-lierten Umgebung ablaufen. Dies hat auch eineVerringerung der Entwicklungszeit und damitder Entwicklungskosten zur Folge.

TTCN-3 ist für Hardware in the Loop-Testingsehr gut geeignet, da durch das komponenten-basierte Konzept lediglich reale Komponentendurch TTCN-3-Testkomponenten ersetzt wer-den müssen. Für die Testkomponente muss hier-bei nur das Kommunikationsverhalten der realenKomponente, die ersetzt werden soll, implemen-tiert werden.

Ein Beispiel für Hardware in the Loop-Testingwird nachfolgend, anhand der AUTOSARSoftwareplattform im Automotive Bereicherläutert. AUTOSAR verwendet TTCN-3-Testkomponenten, um die Gesamtfunktionalitätvon Einzelkomponenten oder deren Integrationin das System zu testen.

Testen von EinzelkomponentenUm individuelle Komponenten zu Testen, müs-sen diese vom System vollständig separiert wer-den. Dies geschieht bei AUTOSAR durch Ver-wenden eines sogenannten Virtual FunctionalBus, welcher selbst durch eine Testkomponentevon TTCN-3 ersetzt werden kann (Abbildung7). Durch diese Maßnahme können alle Funktio-nen der Komponente über die Testkomponentegetestet werden.

Abbildung 7 zeigt einen Controller (C1), des-sen Virtual Functional Bus durch eine speziellauf den Controller angepasste Testkomponen-te ersetzt wurde. Die Testkomponente kann da-durch sämtliche Funktionen des Controllers tes-ten. Außerdem ist für diese Testart kein Testsys-tem mehr notwendig, da nur der Controller unddie Testkomponente benötigt werden.

Abb. 7: Testen einer Einzelkomponente [10]

Integrationstests für KomponentenEin System kann aus einer Vielzahl andererKomponenten bestehen. Um individuelle Kom-ponenten, die innerhalb eines Systems integriertwerden müssen, zu testen, wird entweder jedeKomponente oder nur einzelne Komponentendes Systems durch TTCN-3-Testkomponentenersetzt. Durch diese Vorgehensweise kann diezu testende Komponente über die TTCN-3-Testkomponenten getestet werden. Jede Test-komponente kann nach Ausführen der Tests ei-ne Aussage darüber Treffen, ob die Integrationmit dieser Komponente funktioniert hat oder einFehler aufgetreten ist.

7

Abbildung 8 zeigt ein Testsystem mit einem zutestenden Controller (C1), einem weiteren Con-troller (C2) und einer Testkomponente (TesterC1), um die Zusammenarbeit mit dem Control-ler C1 zu testen.

Abb. 8: Integrationstest [10]

5.3 Model Based Testing (MBT)

Testerzeugung aus MSC oder GFTWie in Abschnitt 5.1 schon erklärt, werdenim Automotive-Bereich verbreitet Message Se-quence Charts (MSC), teilweise sogar TTCN-3-GFT zur Spezifikation der Komponenten einge-setzt, welche auch zur Erstellung von Testfällenfür TTCN-3 verwendet werden können. Diesermöglicht direkt das Testen des in der Spezifi-kation erstellten Modells in den Testfällen. Wei-terhin ermöglicht es ein einfaches Vergleichender Testergebnisse mit der Spezifikation.

U2TP Mapping zu TTCN-3Für das Testen von Modellen in Form vonUML-Diagrammen ist UML 2.0 Testing Pro-file (U2TP) vorhanden, mit dem direkt überUML-Modelle Testfälle erzeugt werden kön-nen. Wie [15] aufzeigt ist es möglich U2TPauf TTCN-3 zu mappen, wodurch das Testenvon UML-Modellen über TTCN-3 ermöglichwird. Das Mapping wird anhand des grafischenFormats, sowie der Mappingschnittstelle vonTTCN-3 vorgenommen.

U2TP setzt jedoch auf einem höheren Abstrak-tionslevel wie TTCN-3 an. TTCN-3 bietet ge-genüber U2TP den Vorteil, Testfälle im grafi-schen Format detaillierter darzustellen. Jedochist es in TTCN-3 nicht möglich auf die abstrak-tere Sicht, wie sie U2TP bietet, umzuschalten.

Die Software ”TTmodeler” von TestingTech,ein Plugin für die ”TTworkbench” von Testing-Tech, ermöglicht es aus UML-2-Diagrammen

im XMI-Format TTCN-3-Code zu erzeugen undin der TTworkbench weiter zu verarbeiten.

Motorola verwendet wie TestingTech U2TP umaus UML-2-Diagrammen TTCN-3-Code zu er-zeugen und diesen in ihrer eigenen Umgebungweiter zu verwenden [1].

6 Trends

Seit der Standardisierung von TTCN-3 wird dieTestsprache immer häufiger in großen Projektenin verschiedenen Industriebereichen als offiziel-le Testsprache eingesetzt. Einige dieser Bereichesind Mobile Kommunikation, Breitbandtechno-logien, Internet Protokolle und Automotive.

Zu den größten Projekten in diesen Bereichen,bei denen TTCN-3 verwendet wurde zählen:

• WIMAX (802.16)• UMTS (Universal Mobile Telecommunica-

tions System)• LTE (3GPP Long Term Evolution)• IPv6 (Internet Protokoll v6)• SIP (Voice Over IP with the Session Initia-

tion Protocol)• IMS (IP Multimedia Subsystem)• MOST (Media Oriented Systems

Transport-Bus)• AUTOSAR

Es soll versucht werden die Anwendungsberei-che von TTCN-3 noch zu vergrößern, um zu-sätzliche Industriebereiche anzusprechen. Alsneue Bereiche sollen Interoperabilitätstests fürBetriebssysteme, das Testen großer Webanwen-dungen und Bank Systeme, intelligente Trans-portsysteme, Medical Systems, eHealth sowieder Echtzeitbereich für Aviation und Automoti-ve erschlossen werden.

Die größten Themen aktuell sind TTCN-3 fürembedded Systems und Model Based Testingmit TTCN-3:

Für den embedded Systems Bereich geht es vorallem um die Entwicklung einer Echtzeiterwei-tung ”RT TTCN-3 Concepts” und einer Erweite-rung zur Unterstützung kontinuierlicher Signale”Continuous TTCN-3 Concepts”. Diese sollen

8

Konstrukte für das Testen dieser Systeme bereit-stellen. Die Erweiterung ”Continuous TTCN-3Concepts” soll z.B. Konstrukte zum Program-mieren von Zustandsautomaten, wie onentryund onexit, zur Verfügung stellen.

Für Model Based Testing mit TTCN-3 sind in-zwischen einige kommerzielle Tools oder Plug-ins, wie ”Conformiq OY” von Conformiq Qtro-nic und das in Abschnitt 5.3 erwähnte Plugin”TTmodeler” von TestingTech vorhanden, dieTTCN-3-Code aus UML-Diagrammen generie-ren.Außerdem gibt es Überlegungen die Module TE,SA und CD vollständig oder teilweise automa-tisch aus einem Modell generieren zu lassen.Dies würde die Handhabung von TTCN-3 deut-lich vereinfachen.

7 Fazit

TTCN-3 wird inzwischen seit seiner Standardi-sierung in vielen Industriebereichen verwendetund hat sich in einigen als Standardtestspracheetabliert. Aufgrund der schnellen Weiterentwick-lung und der Einsatzfähigkeit in immer mehrIndustriebereichen wird sich diese Entwicklungnoch ausweiten.

Literatur

[1] BAKER, P. ; JERVIS, C.: Early UML Mo-del Testing using TTCN-3 and the UMLTesting Profile. In: Testing: Academicand Industrial Conference Practice andResearch Techniques - MUTATION, 2007.TAICPART-MUTATION 2007, 2007, S. 47–54

[2] ETSI: Methods for Testing and Specifica-tion (MTS); The Testing and Test ControlNotation version 3; Part 02: TTCN-3 Ta-bular presentation Format (TFT). 3.2.1,2007. – URL http://www.ttcn3.org/StandardSuite.htm

[3] ETSI: Methods for Testing and Specifica-tion (MTS); The Testing and Test Control

Notation version 3; Part 03: TTCN-3 Gra-phical presentation Format (GFT). 3.2.1,2007. – URL http://www.ttcn3.org/StandardSuite.htm

[4] ETSI: Methods for Testing and Spe-cification (MTS); The Testing and TestControl Notation version 3; Part 01:TTCN-3 Core Language. 4.2.1, 2010.– URL http://www.ttcn3.org/StandardSuite.htm

[5] ETSI: Methods for Testing and Specifi-cation (MTS); The Testing and Test Con-trol Notation version 3; Part 04: TTCN-3 Operational Semantics. 4.2.1, 2010.– URL http://www.ttcn3.org/StandardSuite.htm

[6] ETSI: Methods for Testing and Specifi-cation (MTS); The Testing and Test Con-trol Notation version 3; Part 05: TTCN-3 Runtime Interface (TRI). 4.2.1, 2010.– URL http://www.ttcn3.org/StandardSuite.htm

[7] ETSI: Methods for Testing and Specifi-cation (MTS); The Testing and Test Con-trol Notation version 3; Part 06: TTCN-3 Control Interface (TCI). 4.2.1, 2010.– URL http://www.ttcn3.org/StandardSuite.htm

[8] GRABOWSKI, Jens ; SCHMITT, Michael:TTCN-3 - A Language for the Specifica-tion and Implementation of Test Cases.(03.2002)

[9] GROSSMANN, J. ; SERBANESCU, D. ;SCHIEFERDECKER, I.: Testing EmbeddedReal Time Systems with TTCN-3. In: Soft-ware Testing Verification and Validation,2009. ICST ’09. International Conferenceon, 2009, S. 81 –90

[10] GROSSMANN, Jürgen ; SCHIEFERDE-CKER, Ina: TTCN-3 User ConferenceFrance: Mapping AUTOSAR Interfacesto TTCN-3, 06.2009

[11] KUMAR, B. ; JAEGER, M. ; JASPERNEI-TE, J.: A proposal for graphical extension

9

of TTCN-3 Graphical presentation Format(GFT). In: Factory Communication Sys-tems (WFCS), 2010 8th IEEE Internatio-nal Workshop on, Mai 2010, S. 177 –180

[12] VASSILIOU-GIOLES, Theofanis ; PROF.DR.-ING. SCHIEFERDECKER, Ina: Tes-ten mit TTCN-3: Vorteile und Nutzen ei-ner mächtigen und zudem standardisiertenTesttechnologie, 2007

[13] WEHRSPANN, Thomas: Konzeption undImplementierung einer automatisierten Te-stumgebung, Technische Universität Claus-thal, Diplomarbeit, 2003

[14] WILLCOCK, Colin ; DEISS, Thomas ;TOBIES, Stephan ; SCHULZ, Stephan ;KEIL, Stefan ; ENGLER, Federico: AnIntroduction to TTCN-3. 1. Wiley & Sons,2005. – URL http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470012242.html. –ISBN ISBN-10: 0470012242

[15] XI, Liang ; XINXIN, Sun: Research onthe Mapping of UML2.0 Testing Profile toTTCN-3. In: Information and Computing(ICIC), 2010 Third International Confe-rence on Bd. 4, 2010, S. 280 –283

10