TTCN-3 Testing and Test Control Notation

Transkript

1 TTCN-3 Testing and Test Control Notation Jens Zech Matrikel Nr.:

2 Inhaltsverzeichnis: Inhaltsverzeichnis... 2 Einführung in TTCN Hintergrund... 3 Der Standard... 3 Testen mit TTCN Blackbox Test... 4 Testdurchführung... 5 Bewertung der Tests... 5 Aufbau der Notation... 5 Formate... 6 Text Format... 6 Grafisches Format... 7 Tabellen Format... 7 Datentypen... 7 Struktur der Notation... 8 Das Modul... 8 Programme & Tools für TTCN Telelogic Tau Test Testing Tech TTtree Beispiel Fazit & Ausblick Quellen Seite 2 von 13

3 Einführung in TTCN-3 Hintergrund TTCN-3 steht für Testing and Test Control Notation und soll in seiner 3. Version bei einem der größten Probleme bei der Neuentwicklung von Hardware und Software weiterhelfen. Dem Systematischen Testen der neuen Produkte. Damit nicht die Benutzer zu Betatestern werden, soll TTCN-3 hier helfen die Systeme auf wichtige und kritische Abläufe in variierenden Systemumgebungen hin zu untersuchen. Da das Testen nur ein endlicher, an ökonomische Randbedingungen geknüpfter Prozess ist, sei hier erwähnt, dass damit nicht endgültig alle Fehler ausgeschlossen werden können. Aber ihre Wahrscheinlichkeit kann drastisch reduziert werden. Und mittels Systemüberdeckung während des Testens, lassen sich dann auch qualifizierte Aussagen über das System machen. TTCN-3 selbst kommt dabei aus dem Umfeld der Telekommunikationsbranche und hat hier schon beinahe 20 Jahre Erfahrung sammeln können. Im TK Umfeld ist man dabei in Punkto Ausfallsicherheit der IT Welt weit voraus. Wenn man allerdings berücksichtigt, dass in der TK Branche oft mehr als 40% des Systementwicklungsaufwandes zum Testen benötigt werden, erkennt man wie wichtig hier unterstützende Tools sind. Systematisches Testen verkürzt dabei die Zeit bis zur Markteinführung und trägt zur hohen Leistungsfähigkeit des Systems bei. Durch Widerverwendbarkeit der Testmethoden für neue Systeme wird nicht nur die Kompatibilität sichergestellt sondern auch die Kosten für den Testaufwand drastisch reduziert. Das Testsystem muss dabei wie jedes andere System auch eine Entwurfs-, Entwicklungs-, Integrations-, und Testphase durchlaufen und muss direkt auf das zu testende System abgestimmt werden. Es sollte daher von Anfang an mit entwickelt werden und oft ist es sogar sinnvoll die Anforderungen in ein Testsystem zu gießen, bevor mit der eigentlichen Entwicklung begonnen wird. Dadurch kann von Anfang an sichergestellt werden, dass die Anforderungen erfüllt werden. Der Standard TTCN-3 ist durch das ETSI (European Telecommunication Standards Institute) als neue Spezifikations- und Implementierungssprache für Softwaretests entwickelt worden. Es wurde dann als Z.140 Standard vom ITU (International Telecommunication Union) angenommen. TTCN-3 wurde dabei, aufgrund der jahrzehntelangen Erfahrung mit Telekommunikationssystem, mit dem Anspruch entwickelt, das systematische Testen für verschiedene Systeme und Arten von Tests zu unterstützen. Daher ist TTCN-3 für eine Vielzahl von Tests einsetzbar, so zum Beispiel für funktionale, Integrations-, System-, Interoperabilitäts-, Konformitäts-, Skalierungs- und Lasttests. Dabei handelt es sich nicht nur um Methoden für Abnahme Tests sondern ist vielmehr während des gesamten Systementwurfs einsetzbar. Entwickelt wurden dabei die ersten beiden Versionen als Testbeschreibungssprache durch die ISO zwischen 1984 und TTCN stand damals allerdings noch für Tree and Tabular Combined Notation. Die ITU übernahm dann diese Sprachversion als X.292 Standard. Aufgrund der Vielzahl unterschiedlicher Bedürfnisse der ETSI Mitglieder entstand dann der TTCN-2++ Standard. Zwischen 1998 und 2001 wurde durch mehrere Spezialist Task Forces die neue Edition von TTCN ausgearbeitet und spezifiziert. Seite 3 von 13

4 Mittlerweile wurde TTCN-3 erfolgreich bei einigen großen System getestet. Wie zum Beispiel in folgenden Bereichen: Telekommunikationssysteme (ISDN), mobile Geräte (GSM, GPRS, WAP, UMTS), VOIP, IPv6. Testen mit TTCN-3 TTCN-3 wurde speziell für reaktive, verteilte Systeme entwickelt, deren Dienste über wohl definierte Schnittstellen nutzbar sind, wie z.b. ISDN oder VoIP. Es wird hierbei nicht nur der Entwurf eines einfachen Tests unterstützt sondern komplette abstrakte Testfälle sowie deren automatisierte Überführung in ausführbare Testfälle und die Generierung der Ergebnisse. Blackbox Test Das zu testende System wird dabei als Blackbox betrachtet, das nur über wohl definierte Schnittstellen ansprechbar ist. Der Test erfolgt dann durch Stimulation dieser Schnittstellen und der Bewertung der daraufhin beobachteten Reaktionen. Dabei kann der Fortlauf des weiteren Testverfahrens abhängig von den Reaktionen sein. Je nach zu testendem System kann es notwendig sein, dass sowohl auf Seite des Systems als auch auf Testseite diverse Anpassungen nur für die Tests notwendig sind. Dafür sind in der Spezifikation Interfaceklassen vorgesehen, die aber im Einzelfall auch weggelassen werden können. TTCN-3 Test Case Port.send(Stimulus) Port.recieve(Response) Abstract Test System Interface Port Real Test System Interface System Under Test (Black Box) Die einzelnen Testfälle sind dabei direkt einem Testzweck zugeordnet, der die in der Spezifikation beschriebene Systemeigenschaft nachweisen soll. Diese Testfälle sollen laut Standard bewusst abstrakt gehalten werden, so dass sie unabhängig von der Plattform und dem Gerät sind. Es ist dann Aufgabe der Werkzeuge (Compiler, Ausführungsumgebung) die abstrakten Testfälle in, für das entsprechende System, ausführbare Test zu verwandeln und deren Ergebnisse auszuwerten. Seite 4 von 13

5 Testdurchführung Jeder Start eines Testfalls erzeugt eine Master Testkomponente, die das für den jeweiligen Fall definierte Verhalten realisiert. Jede Testkomponente kann auch weitere parallele Testkomponenten erzeugen und starten. So sind also verteilte Tests mit beliebig vielen Komponenten möglich. Über die verbundenen Schnittstellen (Ports) können die Testkomponenten untereinander und mit dem zu testenden System kommunizieren und interagieren. Sobald die Master Komponente terminiert, werden auch alle von ihr gestarteten Komponenten beendet Die Masterkomponente kann die Testkonfiguration (Menge aller Testkomponenten und deren Verbindungen) während ihrer Laufzeit dynamisch ändern und anpassen. Bewertung der Tests TTCN-3 bewertet während des Systemtests jeden Testfall einzeln. Dabei erzielt jeder dieser Einzeltests, ganz unabhängig von seinem Umfeld, sein persönliches lokales Ergebnis. Das Gesamtergebnis bildet sich dabei aus der Summe der Einzelergebnisse. Dabei gilt allerdings das Prinzip: Es kann nur schlechter werden. Das heißt, wenn der erste Test fehlschlägt und 999 weitere gut gehen, ist das Gesamtergebnis trotzdem fehlgeschlagen. none < pass < inconic < fail < error Pass Fehlerfrei Inconc Inconclusive, der Test lieferte weder pass, noch fail. Meist sollte hier der Test näher spezifiziert werden Fail Der Test bewertete das Ergebnis als fehlerhaft Error Ein Fehler passierte während des Tests. P F I Test 1 P Test 2 I Test 3 P Test 4 F set.verdict(pass) set.verdict(inconc ) set.verdict(pass) set.verdict(fail) Aufbau der Notation Für die Definition der Testfälle stellt TTCN-3 gleich eine ganze Palette von möglichen Definitionsformaten zur Verfügung und auch bei den zu verwendenden Datentypen hat man eine ganze Reihe an Möglichkeiten. Seite 5 von 13

6 ASN.1 Types & Values Other types & Values 2 TTCN-3 Core Language Text format Tabular Format Graphical Format Presentation Format 3 Other types & Values n Presentation Format n Formate Für die Definition der Testfälle kann die Notation wahlweise per Text, grafisch oder tabellarisch erfolgen. Dadurch soll gewährleistet sein, dass vom Testentwickler bis zum Projektleiter und Manager für jeden das Richtige dabei ist. Dies wird noch zusätzlich dadurch gefördert, dass nicht nur die Umsetzung mit einer dieser Varianten erfolgen kann, sondern auch jederzeit für einen Testfall zwischen allen möglichen Darstellungen gewechselt werden kann (entsprechende Tools vorausgesetzt). Text Format Das Textformat ist wohl am Ehesten für Programmierer und dient des Weiteren als Grundlage für die Kompilierung des Testfalls. Es wird daher auch Core Notation genannt. Die Tests lassen sich unter Benutzung der TTCN-3 Notation mittels gängiger Editoren bearbeiten (z.b.: Emacs verfügt über TTCN-3 Syntax Highlighting). Die Notation ist dabei ähnlich einer Programmiersprache mit Modulen, Deklarationen, Statements etc. aufgebaut. testcase MyTestcase() runs on MyTestComponent system SystemComponent { MyPort.call(myMethod:{MY_ID, 3.0); alt { [] MyPort.getreply(myMethod:{MY_ID value "Hello World!") { verdict.set(pass); [] MyPort.getreply { verdict.set(fail); [] MyPort.catch(timeout) { verdict.set(fail); Seite 6 von 13

7 Grafisches Format Das grafische Format hingegen dient der Konzeption und Dokumentation sowie der Analyse von Testresultaten. Es soll die Testabläufe in Form von Sequenzdiagrammen visualisieren. Hierfür werden die im Systementwurf weit verbreiteten Sequenz Charts benutzt. Auch hier gibt es für Message Sequenz Charts entsprechende Erweiterungen, die es erlauben die Konzepte von TTCN-3 adäquat darzustellen. Die Instanz mit der durchgezogenen Linie steht für die Master Komponente, während die gestrichelte Linie die Ports darstellt. Pfeile zwischen den Linien symbolisieren einen Nachrichten Austausch. Tabellen Format Das Tabellen Format ist vor allem ein Relikt aus der Edition 2 von TTCN und wird heute an vielen Stellen vernachlässigt. Dennoch hat auch die tabellarische Darstellung ihre Vorteile. Einer der Vorteile der Tabellenform liegt darin, dass die Funktionen, ähnlich der Textform, detailliert ausgedruckt sind und anhand der Tabelle die Parameter und Funktionswerte schnell abrufbar und mit anderen Stellen und Aufrufen vergleichbar sind. Damit können Zusammenhänge überblickt oder fehlerhafte Aufrufe, auch ohne detailliertes Studium des Source Codes, schnell erkannt werden. Test Case Definition Name : MyTestcase Group : Purpose : Example Testcase System I/f : MTC Type : MyComponentType Comments : Name Type Initial Value Comments MyVar INTEGER 0 Behaviour Definition alt { [ ] MyPort.receive(Msg); [ ] : DetailedComments: Comments Datentypen TTCN-3 besitzt ein eigenes, vollständiges Datenkonzept mit den allgemein bekannten Datentypen wie zum Beispiel integer, boolean oder record. Da es aber häufig notwendig ist die Datenbeschreibung des SUT (System under Test) zu benutzen, unterstützt TTCN-3 auch Seite 7 von 13

8 eine Reihe anderer Datentypen. Neben den typischen Datentypen von Java und C wird vor allem auch die im Telekommunikationsbereich weit verbreitete Datenbeschreibungssprache ASN.1 unterstützt. Es ist aber bereits im Standard vorgesehen, dass TTCN-3 um andere / eigene Datentypen erweiterbar ist. Struktur der Notation Wie bereits erwähnt ist die letztendliche Basis für die Kompilierung des Testfalls die Core Notation. Daher soll hier ihr Aufbau noch einmal etwas näher betrachtet werden. Modul Modul Definition Modul Control Das Modul Die oberste Strukturierungseinheit von TTCN-3 bildet das Modul. Es fasst den kompletten Testfall zu einer Einheit zusammen und ist vergleichbar mit einer Unit oder Klasse wie man sie aus anderen Programmiersprachen her kennt. Das Modul kann parametrisiert werden, um es in verschiedenen Umgebungen einsetzen zu können. Inhaltlich wird das Modul noch einmal untergliedert in einen Definitions- und einen Kontrollteil. Der Definitionsteil beinhaltet dabei alle für eine Testreihe notwendigen Definitionen, wie z.b. Datentypen, Ports, Testkomponenten oder Testfälle. Dabei können die Definitionen auch aus anderen Modulen importiert werden. Der Kontrollteil stellt dann das Hauptprogramm eines TTCN-3 Moduls dar. In ihm sind die Reihenfolge und Bedingungen für die Ausführung der im Definitionsteil definierten oder importierten Testfälle verankert. Des Weiteren stellt TTCN-3 aber auch noch Schablonen zur Verfügung. Hierbei handelt es sich um eine Art Regular Expressions mit deren Hilfe zum Beispiel zu erwartenden Ergebnisse / Antworten beschrieben werden können, um sie dann vergleichen und bewerten zu können. Mit Ihrer Hilfe lassen sich Wertebereiche, beliebige Mengen von Werten, Komplemente von Wertemengen, optionale Werte, sowie Längenbeschränkungen für Zeichenketten und Felder spezifizieren. Während der Testausführung kann dann geprüft werden, ob die empfangenen Daten mit der zugehörigen Schablone konform sind. control{ var integer count := 0; var verdicttype myverdict; If ( execute ( InitialTestCase() ) == pass) { while( count < 10 ) { myverdict := execute(example1()); count := count + 1; Beispiel eines Kontrollteils Seite 8 von 13

9 Inhaltlich wird in TTCN-3 dann noch einmal unterschieden zwischen Testkonfiguration, Testfall, Testkomponenten und Testergebnissen Die einzelnen Testfälle (also die Fälle die man gerne testen möchte) werden dabei von parallel arbeitenden Testkomponenten (also ein Testprogramm, das genau diesen Fall testet) ausgeführt. Dabei kann natürlich im einfachsten Fall der komplette Test aus einer Komponente bestehen. Aber gerade bei SUT mit räumlich verteilten Schnittstellen wird meist ein verteilter Testfall benötigt, der von mehreren Testkomponenten ausgeführt wird. Jede Testkomponente bildet dabei eines der Module und hat im Definitionsteil die von im benutzten Ports, Timer, Konstanten und Variablen definiert. Jeder Testfall definiert eine Haupttestkomponente (Master Test Component) (s. Testdurchführung) welche zur Durchführung des Tests gestartet wird. Diese Hauptkomponente kann dann weitere Komponenten starten. Die Gesamtmenge dieser einzelnen Komponenten und ihrer Verbindungen wird dann Testkonfiguration genannt. Dabei ist es bei TTCN-3 vorgesehen, dass sowohl eine einzelne Komponente die komplette Konfiguration bildet aber auch komplexe verteilte System oder dynamische Testkonfigurationen sind möglich. testcase MyTestcase() runs on MyTestComponent system SystemComponent { MyPort.call(myMethod:{MY_ID, 3.0); alt { [] MyPort.getreply(myMethod:{MY_ID value "Hello World!") { verdict.set(pass); [] MyPort.getreply { verdict.set(fail); [] MyPort.catch(timeout) { verdict.set(fail); Einfaches Beispiel einer Testkonfiguration und der dazugehörigen Testkomponente. Seite 9 von 13

10 Programme & Tools für TTCN-3 Als Programme seinen hier nur einmal kurz zwei verschiedene erwähnt, nämlich Telelogic Tau Tester und Testing Tech TTree. Telelogic Tau Test Telelogic bietet eine komplette Testsuite an. Bei dieser ist der Telelogic Tau Tester nur eines von vielen Produkten, die zwar einzeln lizenziert werden müssen aber zu einem Gesamtprodukt gehören. Zu den wesentlichen Funktionen gehört hier sicherlich: Verwalten der kompletten Testsuit. Integrierter Debugger zum Debuggen der Testfälle Automatisierte Erstellung der Tests aus vorgegeben Spezifikationen (SDL, MSC) Erstellung sowohl per grafischer Modellierung als auch per Core Notation TTCN nach Ansi C Compiler Aufgrund ihrer komplexen Suite und den recht hohen Lizenzgebühren ist der Tau Tester aber eher für größere Projekte geeignet. Viele der vorhanden Vereinfachungen greifen nur, wenn man an einem Projekt arbeitet, das auch alle klassischen Stadien (Spezifikation, Entwurf, etc.) sauber ausgearbeitet hat und standardisiert durchläuft. Wie anhand der Funktionsliste auch schon ersichtlich ist, übersetzt der Tau Tester die Testkonfiguration nach Ansi C und kann dann mit jedem gängigen Compiler kompiliert und als fertiges Programm ausgeführt werden. Die komplette Durchführung nimmt einem der Tau Tester auch ab und wickelt dann den kompletten Test von der Kompilierung und Durchführung bis hin zur Auswertung ab. Testing Tech TTtree Testing Tech bietet anders als Telelogic eher Einzellösungen an, die aber weitestgehend kombiniert werden können und somit ebenfalls eine vollständige Testsuite bilden. Vorteil dieser Einzellösungen ist, dass sie sich unauffällig in bereits vorhandene Entwicklungswerkzeuge integrieren lassen (z.b.: Emacs Erweiterungen). Für TTCN-3 Tests ist TTtree vorgesehen. Mit diesem recht schlicht wirkenden Programm lassen sich Testfälle von der Core Notation in Java übersetzen, kompilieren und auswerten. Die Auswertung besteht dabei vor allem aus Laufzeiten und Zähler der erfolgreichen / fehlerhaften Durchläufe. Neben der hohen Integrationsfähigkeit ist hier aber auch das Lizenzmodell besonders hervorzuheben, welches sowohl Studenten- als auch kostenlose Entwicklerlizenzen vorsieht und damit jedem die Möglichkeit gibt, sich selbst einen Überblick über TTCN-3 zu verschaffen. Zu den wesentlichen Funktionen gehört hier: Plattformunabhängige Kompilation und Ausführung durch Java Emacs Integration Gute Integrationsmöglichkeit durch kleine Tools Seite 10 von 13

11 Beispiel module MyModule { modulepar { integer MY_ID := 2; ; type port MyPortType procedure { inout all type component MyTestComponent { port MyPortType MyPort type component SystemComponent { port MyPortType SystemPort // Module Parameter // Port Deklaration // Test System Komponenten // Test System Komponenten // Signature Deklaration signature mymethod(in integer MyId) return charstring; // Testfall Definition testcase MyTestcase() runs on MyTestComponent system SystemComponent { map(mtc:myport, system:systemport); // Definiert den Typ // macht die Ports nach außen sichtbar // Map Operation log("start test case execution for Hello World example"); MyPort.call(myMethod:{MY_ID, 3.0); // Call Operation alt { // Erwartete Antwort [] MyPort.getreply(myMethod:{MY_ID value "Hello World!") { setverdict(pass); // Erwartet: Test erfolgreich [] MyPort.getreply { // Andere Antwort setverdict(fail); // Nicht Erwartet: Test fehlgeschlagen [] MyPort.catch(timeout) { // Timeout exception setverdict(fail); // Fehlverhalten: Test fehlgeschlagen unmap(mtc:myport, system:systemport); // Unmap Operation with { extension "Purpose: My Hello World! example" Seite 11 von 13

12 Dieses kurze Beispiel zeigt einen einfachen Testfall. Als Erstes wird hier ein Modulparameter definiert, der später beim Ausführen des Tests auch beliebig geändert werden kann. Danach wird ein Port deklariert, der anschließend sowohl für die Testkomponente als auch für die Kommunikation mit dem Testsystem definiert wird. Des Weiteren folgt dann die Deklaration der zu testenden Funktion. In diesem Fall handelt es sich um eine Funktion, die einen Integerwert übergeben bekommt und einen entsprechenden String zurück liefert. Es soll eigentlich immer Hello World! zurückkommen. Der eigentliche Testfall startet dann mit einem Log Eintrag und ruft danach über den deklarierten Port die Funktion auf und übergibt ihr den Modulparameter als Eingabewert. Als zusätzlicher Parameter wird der call Funktion noch ein Timeout von drei Sekunden mitgegeben. Danach sehen wir eine der Spezialitäten von TTCN-3, nämlich die alt { Anweisung. Mit ihr können mehrere Alternativen verarbeitet werden. Die Abarbeitung ist dabei einer Switch Anweisung sehr ähnlich. Der erste zutreffende Block wird ausgeführt. In unserem Fall sind es drei verschiedene Möglichkeiten. 1. MyPort.getreply(myMethod:{MY_ID value "Hello World!") Die aufgerufene Funktion liefert den String Hello World! zurück. In diesem Fall wird diese Alternative ausgeführt und setzt mittels setverdict(pass) diesen Test auf erfolgreich. 2. MyPort.getreply Wenn diese Alternative ausgeführt wird heißt das, dass es eine Antwort auf unseren Funktionsaufruf gab, der aber nicht auf die erste Alternative passte. Also nicht Hello World! zurücklieferte, sondern irgendetwas Anderes. Daher wird mittels setverdict(fail) der Test auf fehlgeschlagen gesetzt. 3. MyPort.catch(timeout) Die dritte Alternative bedeutet, dass drei Sekunden lang gar keine Antwort kam und daher der Timeout ausgelöst wurde. Auch in diesem Fall wird der Test als fehlgeschlagen bewertet. Das war auch schon der gesamte Test. Anmerkend ist zu erwähnen, dass dieser Testfall bei TestingTech als Example vorliegt und dort jederzeit ausprobiert werden kann. Dort ist die zu testende Funktion allerdings bewusst fehlerhaft implementiert, so das der Parameter 1 das korrekte Ergebnis liefert, 2 einen falschen String zurückgibt und bei allen anderen ein Timeout ausgelöst wird. Seite 12 von 13

13 Fazit & Ausblick TTCN-3 wird aufgrund der firmenunabhängigen Standardisierung durch eine breite Palette von Tools und Entwicklungssuiten unterstützt. Dadurch lässt es sich für fast jeden erdenklichen Testzweck gebrauchen und nutzen. Es ist durch seine genaue Spezifikation der Testdurchführung bei gleichzeitiger Berücksichtigung der Möglichkeit, die Testsprache zu erweitern, aber auch für zukünftige Dinge offen. Insgesamt fällt aber auch auf, dass viele der Realisierungen schwer telekommunikationslastig sind und oft nur für diesen Bereich durchdacht worden zu sein scheinen. Aber auch TTCN-3 soll sich weiterentwickeln und noch allgemeiner werden. Daher sind bereits viele Erweiterungen in der Entwicklung. Hier nur einige Stichpunkte zum Überblick: XML - mapping nach TTCN-3 TimedTTCN-3 als Echtzeiterweiterung UML Test Profile Umfangreicheres Lehrmaterial soll für breitere Akzeptanz und Nutzung führen. Es bleibt also auch weiterhin spannend, was TTCN noch alles bringen wird. Quellen: TTCN-3 und danach?, Jens Grabowski, Januar Artikel über Teleogic Tau Evaluation ETSI ES V2.2.1 ( ): The Testing and Test Control Notation, Version 3, Part 1: TTCN-3 Core Language Telelogic Testing Tech: TTreeTech Seite 13 von 13