Prüftechnik
TTCN-3 - komplexe Systeme optimal testen
Testing and Test Control Notation (TTCN) ist eine von der ETSI entwickelte und international standardisierte Sprache, die zum Testen von Kommunikationsprotokollen dient. Wegen der leichten Erlernbarkeit, der Modularität und Erweiterbarkeit findet sie Anwendung in der Kommunikationstechnik, in der Automobilindustrie, bei der Eisenbahn und sogar im Finanzbereich.
Schon bei der Betrachtung kleiner, alltäglicher Dinge stellt man fest, dass die Komplexität der am Markt befindlichen Produkte zunimmt. Sei es die Kaffeemaschine, die vorprogrammiert den Kaffee nach Wunsch bereitet, oder das Handy, das sich inzwischen zum vollwertigen Computer mit Sprachfunktion mauserte. Die Palette der Beispiele ist unerschöpflich. Aus der wachsenden Komplexität der Produkte ergibt sich für die Hersteller automatisch die Anforderung, Tests auszuführen, die mit überschaubarem Aufwand flexibel an wachsende Anforderungen angepasst werden können - Tests, die gut dokumentiert sind und ohne zusätzlichen Aufwand verständliche Testreports liefern.
Was TTCN-3 kann - die Architektur
An dieser Stelle kommt die Testsprache TTCN-3 ins Spiel, die durch die ETSI international standardisiert sowie leicht zu erlernen ist und die Unabhängigkeit von Technologie und Betriebssystemen bietet. Durch die Erweiterbarkeit sorgt TTCN-3 für Flexibilität beim Testen. Die standardisierten Schnittstellen TRI (TTCN-3 Runtime Interface) und TCI (TTCN-3 Control Interface) ermöglichen die Anpassung und Ausführung der Tests auf verschiedenen Plattformen, Umgebungen und Betriebssystemen.
Jobangebote+ passend zum Thema
Zum Testen des DUT (Device Under Test) verbindet der Systemadapter das DUT mit dem TTCN-3-Testsystem (Bild 1). Der Systemadapter ist für den Austausch aller Messages zwischen Testsystem und DUT verantwortlich. Der Plattformadapter dient der Ausführung externer Funktionen auf dem Testsystem. Ein Beispiel ist die Bereitstellung von Timern. Timer sind im Testsystem notwendig, um Situationen zu beherrschen, bei denen Messages gewollt oder ungewollt verworfen werden. Der Block „Generierter Code“ repräsentiert das Verhalten der Testcases in ausführbarer Form. Das Runtime-System repräsentiert die Semantik von TTCN-3. Generierter Code und Runtime System werden oft zusammen als TTCN-3 Executable (TE) bezeichnet, siehe Bild 1.
Der Codec übersetzt die in TTCN-3 definierten Messages in ein Format, das vom Device Under Test verstanden wird. Vom DUT empfangene Messages werden vom Codec zu einem TTCN-3-verständlichen Format decodiert. Codecs können nach Bedarf selbst entwickelt und in das Testsystem integriert werden. Das Component Handling erlaubt dem Testentwickler zu bestimmen, wie die Komponenten während der Laufzeit der Tests erzeugt, gestartet oder gestoppt werden.
Mit dem Testmanagement (TM), das im User Interface von TTCN-3 angesiedelt ist, werden die Testcases verwaltet. Im TM werden zum Beispiel die Reihenfolge der Tests, die Anzahl der Testläufe oder das Verhalten im Fehlerfall eingestellt. Und schließlich gibt es ein Test-Logging-System (TL), das den Verlauf und die Ergebnisse der Testläufe aufzeichnet.
TTCN-3 - ein Beispiel
Mit Hilfe von TTCN-3 können beliebige Systeme adaptiert und beliebige Interaktionen definiert werden. Man kann beispielsweise ein komplettes Telekommunikationssystem oder Teile davon nachbilden. Im folgenden Beispiel wird ein Router getestet. Für einen einfachen Funktionstest sollen von PC-A zu PC-B Daten per UDP übertragen werden. PC-C ist als Kontrollterminal über TCP mit dem Router verbunden (Bild 2).
Hier zeigt sich bereits ein großer Vorteil von TTCN-3. Für die PCs, die an das DUT angeschlossen werden, wird keine zusätzliche Hardware benötigt. Die Testkomponenten werden einfach in TTCN-3 beschrieben. Alles, was zum Test benötigt wird, ist ein PC mit einer Netzwerkkarte und einer TTCN-3-Installation.
Der Testaufbau
Als echte Hardware wird das DUT benötigt. Die PCs werden in TTCN-3 als parallele Testkomponenten (ptc) definiert. Damit die PCs mit dem DUT kommunizieren können, werden mit -TTCN-3 noch die Ports definiert, die in die PCs eingebaut werden. Die Verbindungen zwischen den Komponenten und dem DUT werden über den Befehl „map“ hergestellt.
Die Ports: Modul udpTestPorts
Zunächst die Definition der Ports: Man benötigt je einen Typ von Port für die Übertragung der Daten und einen Typ für das Kontroll-Interface. Im Modul „udpTestPorts“ ist ein Port für die Datenübertragung (IPPort) und ein Port für das Kontroll-Interface (controlPort) definiert. Wenn die Ports vorhanden sind, werden diese in die Testkomponenten eingebaut (Listing 1). Zur Verbesserung der Übersichtlichkeit wird der TTCN-3-Code in Modulen strukturiert, die in eigenen Dateien organisiert sind.
Die Komponenten: Modul udpTestComponents
Im Modul „udpTestComponents“ sind die Testkomponenten definiert. Dabei repräsentiert ptcControl das Kontrollterminal. Im Kontrollterminal (ptcControl) sind ein Kontrollport (localControl) und ein Timer definiert (Listing 2).
Zur Beschreibung der beiden PCs für die Datenübertragung wird der ptcType definiert. Im ptcType befindet sich der IPPort ptcPort1 und ein Timer (Listing 3).
Die Komponente „systemType“ beschreibt das DUT. Um das DUT zu testen, werden ein Kontrollport und mindestens zwei IPPorts zur Datenübertragung benötigt (Listing 4).
Der mtcType stellt die zentrale Testkomponente dar. Diese Komponente steuert den Testablauf und enthält am Ende des Tests das Testergebnis (Listing 5). Damit die Komponenten senden bzw. empfangen können, wird noch eine Message gebraucht.
Und damit die Veranschaulichung von -TTCN-3 überschaubar bleibt, soll eine UDP-Message verschickt werden. In den Zeilen 29 bis 33 sind die Felder des UDP-Header definiert, wie sie in RFC768 festgelegt sind (Listing 6).
Im nächsten Schritt (Zeilen 34 bis 40) wird der Typ UDP-Message als Record definiert. Damit sinnvoll getestet werden kann, muss die Message noch mit Parametern besetzt werden. Dies geschieht mit Hilfe von Templates.
- TTCN-3 - komplexe Systeme optimal testen
- Die Message Templates: udpTempl
Lesen Sie mehr zum Thema
