Prüftechnik
TTCN-3 - komplexe Systeme optimal testen
Fortsetzung des Artikels von Teil 1
Die Message Templates: udpTempl
In diesem Modul sind die Message Templates definiert. Die Parameter können fest eingestellt oder an das Template übergeben werden. Im Beispiel sind die Felder für Source Port, Destination Port, Message- Länge und Prüfsumme fest eingestellt (Zeilen 45 bis 48, Listing 7). Das Feld, das die Daten enthält, wird durch die Funktion data-string ausgefüllt. Das Template „UDP_send_msg“ wird durch die Funktion send an das DUT verschickt. Das geschieht im eigentlichen Testcase, der später erläutert wird. Das Template „UDP_rcv_msg“ dient der Funktion receive als Decoding-Hypothese.
Jobangebote+ passend zum Thema
Je nach Testanforderung können auf diese Weise beliebige Templates zur Stimulierung des DUT und/oder als Beschreibung des erwarteten Verhaltens erzeugt werden. Im vorliegenden Beispiel sollen die erwartete Message und die versendete Message identisch sein.
Der Test: Modul udpTestCases
Die eigentlichen Tests werden im Modul „udpTestCases“ ausgeführt. Zuerst werden die zuvor beschriebenen Komponenten und die erforderlichen Funktionen importiert.
Das Schlüsselwort testcase (Zeile 65, Listing 8) markiert den Beginn eines Testcase. Die parallelen Testkomponenten werden mit der Methode create erzeugt (Zeilen 67 und 68). Als nächstes werden die Ports der Komponenten durch die Methode map (Zeilen 69 bis 71) miteinander verbunden. Hierbei werden die zu verbindenden Ports in Klammern angegeben. Durch die Methode start werden die Funktionen gestartet, die das Verhalten der parallelen Testkomponenten beschreiben (Zeilen 74 und 75). Durch unmap werden die Verbindungen zum Schluss des Test-case wieder getrennt (Zeilen 77 bis 79). In Zeile 81 bis 84 wird festgelegt, welcher Codec verwendet werden soll.
Im Modul „udpTestFunc“ ist das Verhalten der parallelen Testkomponenten festgelegt. Zunächst werden die zuvor geschriebenen Module importiert (Zeilen 86 bis 90, Listing 9) .
Die Funktion receiver_on wird auf der parallelen Testkomponente „PC-SRC2“ ausgeführt und sorgt dafür, dass der Rechner „PC-B“ etwas empfangen kann (Zeile 90). Falls PC-B nichts empfängt, darf die Funktion nicht ewig warten. Deshalb wird der Timer localTimer gestartet (Zeile 91). Im Statement alt{ …} steckt eine weitere Stärke von TTCN-3 (Zeilen 92 bis 104): Innerhalb der geschweiften Klammern werden die Alternativen für die Testerwartungen angegeben.
In der ersten Alternative wird der Methode receive das Template einer UDP-Message der Länge 128 Bytes als Decoding-Hypothese übergeben. Durchläuft genau diese Message den Decoder, werden die Befehle in den geschweiften Klammern ausgeführt (Zeilen 93 bis 96). Der Timer wird gestoppt und das Testresultat auf pass gesetzt. Gleichzeitig wird der Empfang der Message mit einem Zeitstempel versehen und geloggt.
Die Anweisungen der zweiten Alternative (Zeilen 97..100) werden ausgeführt, falls etwas empfangen wurde, das nicht der erwarteten Message entsprach. Wurde nichts empfangen, prüft die letzte Alternative, ob der Timer abgelaufen ist, und die Funktion wird beendet. Die Funktion transmit_on wird im Beispiel auf PC-A ausgeführt. Ihre einzige Aufgabe besteht darin, eine UDP-Message zu verschicken (Listing 10).
Die Funktion data-string (Zeile 111, Listing 11) erzeugt einen Octet String, der auf die gewünschte MTU-Größe angepasst ist. Im Beispiel wird ein Octet String mit dem Wert 5F gefüllt, bis dataSize erreicht ist.
Das Ergebnis der Tests wird in Text- form und grafisch geloggt. In Bild 3 ist der Test als Ablaufdiagramm dargestellt. MTC, der main testcase, enthält das Gesamturteil (pass).
Vom Terminal aus wird erfolgreich eine Login-Prozedur ausgeführt. PC-A sendet eine Message an das DUT und PC-B empfängt die Message wie erwartet.
Die Entwicklungsumgebung
Zur TTCN-3 Entwicklung stehen verschiedene Entwicklungsumgebungen zur Verfügung. TTCN-3 wurde in erster Linie für den Test verschiedener Kommunikationsprotokolle entwickelt. Dabei werden Programmerweiterungen oft in anderen Sprachen geschrieben. Aus diesem Grund liegt es nahe, Eclipse mit zusätzlichen Plugins für TTCN-3 zu verwenden.
Letztlich ist TTCN-3 im Standard viel zu offen und flexibel, um es auf spezielle Anwendungen bzw. Anwendungsgruppen eingrenzen zu können. TTCN-3 ist zudem in rasanter Weiterentwicklung begriffen, so dass die Einsatzmöglichkeiten noch weiter wachsen.
Literatur
[1] www.ttcn-3.org
[2] www.testingtech.com
[3] www.openttcn.com
[4] http://www.etsi.org/technologies-clusters/technologies/testing
Der Autor
| Mario Feifarek |
|---|
| ist System- und Testingenieur bei Mixed Mode und befasst sich mit dem Test komplexer Embedded-Systeme. |
- TTCN-3 - komplexe Systeme optimal testen
- Die Message Templates: udpTempl
Lesen Sie mehr zum Thema
