-
Die
Erfindung betrifft ein Verfahren zum Testen von Softwaremodulen
und/oder Hardwarekomponenten eines zu testenden Systems über software- und/oder
hardwarespezifische Schnittstellen mittels Testablaufinformationen
zur Stimulierung des zu testenden Systems und/oder Erfassung von
Reaktionen des zu testenden Systems, wobei eine Steuerung des Testablaufs
mit einer übergeordneten
Testablaufsteuerung erfolgt.
-
Die
Erfindung betrifft weiterhin ein Computerprogramm zur Ausführung eines
solchen Verfahrens, wenn das Computerprogramm auf mindestens einem Rechner
ausgeführt
wird.
-
Die
zunehmende Komplexität
technischer Systeme, insbesondere von mikroprozessorgesteuerten
elektronischen Geräten
und Anlagen erfordert die Durchführung
aufwendiger Tests zur Überprüfung der
Funktionsfähigkeit
bei unterschiedlichen Randbedingungen. Der Aufwand zur Definition
der auszuführenden
Testsequenzen und Implementierung für eine spezifische Systemumgebung
ist erheblich, insbesondere, wenn das System Software- und Hardwareschnittstellen
besitzt und es sich um ein System mit verteilten Softwaremodulen
und/oder Hardwarekomponenten handelt, die auf speziellen technologischen
Plattformen basieren.
-
Vor
allem bei sicherheitskritischen, komplexen technischen Systemen,
wie beispielsweise Steuerungskomponenten von Flugzeugen, Eisenbahnen und
Kraftfahrzeugen, ist vor der Freigabe der Komponenten und Module
unbedingt die Durchführung
einer Vielzahl von zuverlässig
definierten und ausgeführten
Test erforderlich. Hierzu ist beispielsweise in dem europäischen Standard
ETSI ES 201 873-1, V2.2.1 (2003-02) „Methods for Testing and Specification
(MTS) the Testing and Control Notation Version 3, Part 1: TTCN-3
Call Language" eine
Programmiersprache zur Spezifizierung aller Arten von Tests an reaktiven
Systemen über
eine Vielzahl von Kommunikationsschnittstellen definiert. Es handelt
sich um eine textbasierte Testablaufbeschreibungssprache in einem
standardisierten Austauschformat, das nur in einer geeigneten, TTCN-3-spezifischen
Systemumgebung automatisch zur Ausführung der Testroutinen verwendet
werden kann.
-
Es
sind vielfältige
Testumgebungen für
den Test von Softwaremodulen und unabhängig hiervon Testumgebungen
für den
Test von Hardwarekomponenten verfügbar. Die zu testenden Softwaremodule und
Hardwarekomponenten werden über
mit der Testumgebung unzertrennliche, programmiersprachenspezifische
und lokale Softwareschnittstellen angesteuert. Die hierzu genutzten
Testumgebungen sind oftmals plattformabhängig und die hardware- und/oder
softwarespezifischen Anbindungen des zu testenden Systems befinden
sich dabei oftmals auf demselben Rechner, wie die Testumgebung.
Beim Testen von Softwaremodulen werden Testroutinen zum Aufruf von
Schnittstellenfunktionen und zur Überprüfung der Ergebnisse ausgeführt. Es
sind auch Verfahren bekannt, bei denen Softwaremodule über mehrere
Rechner verteilt ausgeführt
und über ihre
Schnittstellenmethoden getestet werden können. Hierzu wird die so genannte
Common Object Request Broker Architecture CORBA einer Object Management
Group OMG genutzt. Bei der Common Object Request Broker Architecture
CORBA handelt es sich um eine Softwareschnittstelle, die zum Test des
zu testenden Softwaremoduls nachgebildet werden muss, um Schnittstellenfunktionen
der zu testenden Softwaremodule ansprechen zu können.
-
Neben
den softwareorientierten Testumgebungen gibt es auch hardwareorientierte
Testumgebungen, die meist für
eingebettete Systeme, wie beispielsweise elektrische Schaltungen
und Regelungen mit FPGAs (Field Programmable Gate Arrays) oder integrierten
Schaltungen verwendet werden. Die eingebetteten Systeme werden über physikalische
Hardwareschnittstellen, wie beispielsweise eine serielle Schnittstelle
RS232/RS485, Profibus, analoge Signale usw. getestet. Hierzu werden
Schnittstellenereignisse stimuliert und Reaktionen an den Schnittstellen
analysiert. Zum einen werden die Softwareteile innerhalb einer bestimmten
Entwicklungsumgebung getestet, wie zum Beispiel mit Hilfe einer modellbasierten
Entwicklung, und die Kombination aus Softwaremodulen und Hardwarekomponenten werden
dann über
die entsprechenden physikalischen Schnittstellen auf einer Zielplattform,
wie beispielsweise FPGA, Mikrocontroller, digitaler Signalprozessor
DSP oder Industrie PC getestet.
-
Die
vorhandenen Testumgebungen und Testprogramme unterstützen von
sich aus entweder nur software- oder hardwarespezifische (physikalische)
Kommunikationsarten für
die Stimulation und Analyse von Softwaremodulen und Hardwarekomponenten.
Sie sind also entweder für
den Test von Softwaremodulen oder für den Test von Hardwarekomponenten
ausgerichtet. Die Testprogramme für den Test von Softwaremodulen
stehen für
die Softwareentwicklung und die Testprogramme für das Testen der Hardwarekomponenten
für die
Hardwareentwicklung zur Verfügung,
die bislang unabhängig
voneinander gesehen wurden.
-
Ein
System mit Softwaremodulen und Hardwarekomponenten und/oder software- und/oder hardwarespezifischen
Schnittstellen kann nicht ohne zusätzliche Aufwände durch
Anpassung bzw. Erweiterung der Testumgebungen getestet werden.
-
DE 101 25 382 A1 beschreibt
ein Verfahren und eine Vorrichtung zum Prüfen von Verbindungen in einem
Netzwerk, wie beispielsweise einen Telekommunikationsnetzwerk, um
eine effektive Fehlersuche und Fehlerortung durchführen zu
können. Hierzu
sind an verschiedenen voneinander entfernten Orten Prüfeinrichtungen
vorgesehen, die in Abhängigkeit
von einer konkreten Prüfungsaufgabe
flexibel zum Erfassen und Sammeln der zur Lösung der Prüfaufgabe notwendigen Prüfungssignale genutzt werden
können.
Für eine
Prüfaufgabe
werden Prüfeinrichtungen
in Abhängigkeit
von dem Testfall gewählt
und so miteinander verbunden, dass sie zeitlich synchronisiert zusammenarbeiten.
-
J.
Grabowski, D. Hohgreve, G. Rethy, I. Schieferdecker, A. Wieles,
C. Wilkock: An Introduction to the Testing and Test Control Notation
(TTCN-3), in: Computer Networks 42 (2003, Seiten 375-403) beschreibt
die generelle Struktur verteilter TTCN 3 Testsysteme. Die Gesamtsteuerung
des Testes wird über
eine Testmanagementplattform durchgeführt, die über mehrere verteilte Testablaufroutinen
(Executables) in den Programmablauf der Testmanagementroutine einbindet.
Eine Komponentenhandhabungsroutine sorgt für eine Synchronisation der
verschiedenen Einheiten des Testsystems. Eine Kodier- und Dekodierhandhabungsroutine
dient zur Codierung und Dekodierung von Testinformationen in Datenwörter, die über System-adaptoren
an das zu testende System geschickt werden können. Die Testablauflaufroutinen
sprechen die Systemadaptoren an, um Schnittstellenereignisse an
den zu testenden Hard- und Softwarekomponenten auszulösen. Weiterhin
sind Plattform-adaptoren zur Realisierung von Zeitsignalen vorgesehen,
um eine Synchronisation zu erlauben.
-
Das
TTCN-3-System ist ein integrales System, bei dem durch das Einladen
bzw. Ausführen
der Testablaufroutinen bei Initialisierung der Testmanagementroutine
die Testmanagementroutine untrennbar mit der Testausführung verbunden
wird. Die Testablaufroutinen sind nur auf TTCN-3-spezifischen Testumgebungen
ausführbar
und nicht in anderen Testumgebungen für die Verteilung von Schnittstellen an
Steuerungen nutzbar.
-
Ausgehend
hiervon ist es Aufgabe der vorliegenden Erfindung, ein verbessertes
Verfahren zum Testen von Hardwarekomponenten- und/oder Softwaremodulen
eines zu testenden Systems zu schaffen, das die gleichzeitige Verwendung
von Software- und Hardwareschnittstellen erlaubt und mit dem einzelne
Modulkomponenten verteilter Systeme mit lokalen und plattformabhängigen Softwareschnittstellen
getestet werden können.
Das Verfahren soll geeignet sein, um in verschiedenen Plattformen
eingesetzt zu werden.
-
Die
Aufgabe wird mit dem Verfahren der eingangs genannten Art gelöst durch:
- – Übertragung
von Testablaufinformationen zwischen der übergeordneten Testablaufsteuerung und
verteilten, untergeordneten software- und/oder hardwarespezifischen
Schnittstellenanpassungsroutinen, und
- – Steuerung
der Kommunikation zwischen der Testablaufsteuerung und Schnittstellenanpassungsroutinen
mittels mindestens einer Netzwerkverteilungsroutine,
- – wobei
die Schnittstellenanpassungsroutinen eine Schnittstellenanpassung
zugeordneter Schnittstellen des zu testenden Systems durchführen und
als separater Algorithmus zur Testablaufsteuerung hardware- und/oder
softwarespezifische Schnittstellenereignisse generieren, um die software-
und/oder hardwarespezifischen Schnittstellen des zu testenden Systems
in Abhängigkeit von
den übertragenen
Testablaufinformationen zu stimulieren oder Reaktionen der software- und/oder
hardwarespezifischen Schnittstellen des zu testenden Systems zur
Auswertung zu nutzen.
-
Mit
Hilfe der Netzwerkverteilungsroutine wird eine Trennung der Gesamttestablaufsteuerung
und der Testbeschreibung von der verteilten Schnittstellenanpassung
der zu testenden Softwaremodule und Hardwarekomponenten des zu testenden
Systems erreicht. Hierdurch können
programmablauftechnisch losgelöst
von der Testablaufsteuerung, d.h. nicht mit dieser in einen einheitlichen
Algorithmus kompiliert, beliebige Schnittstellen sowohl softwarespezifische
als auch hardwarespezifische Schnittstellen verwendet und miteinander
kombiniert werden. Somit ist es möglich, die Testablaufsteuerung unter
einer anderen Systemumgebung ablaufen zu lassen, als die Schnittstellenanpassung.
Durch die verteilten Schnittstellenanpassungsroutinen kann zudem
auf einfache Weise mit einer zentralen Testablaufsteuerung das zu
testende System über
ein komplexes Netzwerk von Schnittstellenanpassung getestet werden,
wobei die Schnittstellenanpassungsroutinen zudem wieder verwendbar
sein können.
Die Wiederverwendungsmöglichkeit
bei der Anpassung und Ansteuerung von Software- und Hardwareschnittstellen
zu testender Softwaremodule und Hardwarekomponenten wird damit wesentlich
vereinfacht und flexibler bzw. variabler.
-
Im
Unterschied zu den herkömmlichen
TTCN-3-Testprozeduren werden bei dem erfindungsgemäßen Verfahren
die Testablaufroutinen (Executables) in eine Testroutine mit abstrakter
Ablaufbeschreibungssprache und einen Interpreter zur Ausführung der
konkreten Testprozeduren in den Schnittstellenanpassungsroutinen
aufgeteilt, so dass keine Testablaufroutinen erzeugt werden müssen. Zwischen Testroutine
und Interpreter ist ein Netzwerk vorgesehen und Testablaufinformationen
werden plattformunabhängig
zur Ansteuerung separater Schnittstellenanpassungsroutinen mit Hilfe
der Netzwerkverteilungsroutine verteilt und übertragen, so dass mit dem erfindungsgemäßen Verfahren
eine TTCN-3 Testbeschreibung oder eine andere beliebige Testablaufsteuerung
auch für
andere Plattformen verwendet werden kann.
-
Auf
diese Weise wird eine mehrschichtige Testarchitektur geschaffen,
bei der die Gesamttestablaufsteuerung in einer übergeordneten ersten Ebene
erfolgt. Eine darunter angeordnete Ebene zur Verteilung und Vermittlung
von Schnittstellenereignissen und Schnittstellennachrichten in Form
von Testablaufinformationen stellt die spezifische Kommunikation
der übergeordneten
Testroutine mit ausgewählten untergeordneten
Schnittstellenanpassungsroutinen und daran angeschlossenen zu testender
Softwaremodule und Hardwarekomponenten sicher. In der so genannten
Netzwerkverteilungs- und vermittlungsebene werden mit der Netzwerkverteilungsroutine
die Testablaufinformationen auf verschiedene über ein Netzwerk verbundene
Schnittstellenanpassungsroutinen und ggf. vorgelagerte Schnittstellenverteilungsroutinen
verteilt. In der Schnittstellenverteilungsroutine der Verteilungs-
und Vermittlungsebene erfolgt dann die Verteilung der Schnittstellenereignisse
auf die einzelnen Schnittstellenanpassungsroutinen einer dritten
Ebene, der Schnittstellenanpassungs- und Schnittstellenansteuerungsebene.
In dieser dritten Ebene sind die Schnittstellenanpassungsroutinen angeordnet,
die mit der vierten Ebene, der Testmodulebene kommunizieren und über die
Schnittstellen die zu testenden Softwaremodule und Hardwarekomponenten
ansprechen.
-
Die
Steuerung der Kommunikation zwischen Testablaufsteuerung und Schnittstellenanpassungsroutinen
erfolgt dann vorzugsweise mittels mindestens einer Netzwerkverteilungs-
und Schnittstellenverteilungsroutine, die Schnittstellenereignisse
auf entsprechende lokale und dezentrale Schnittstellenanpassungsroutinen
verteilt.
-
Die Übertragung
von Testablaufinformationen zwischen übergeordneter Testablaufsteuerung und
untergeordneten Schnittstellenanpassungsroutinen über die
Netzwerk- und Schnittstellenverteilungsebene erfolgt vorzugsweise
bidirektional. Damit können
Testinformationen von der Testablaufsteuerung an die Schnittstellenanpassungsroutinen übertragen
werden, um Stimuli für
das zu testende System in Form von Schnittstellenereignissen zu
erzeugen. Weiterhin können
Reaktionen des zu testenden Systems von den Schnittstellenanpassungsroutinen als
Schnittstellenereignisse erfasst und ggf. in umgewandelter oder
ausgewerteter Form als Testablaufinformation an die Testablaufsteuerung
zurück übertragen
werden.
-
Der
Testablauf kann von den Testablaufinformationen direkt gesteuert
werden, indem zu Zeitpunkten und/oder Bedingungen, die durch die
Testablaufsteuerung vorgegeben sind, Stimulierungen des System durch
die Testablaufsteuerung ausgelöst und
Reaktionen des Systems ausgewertet werden. Hierzu werden die Testablaufinformationen
zur direkten Ansteuerung von ausgewählten Schnittstellenanpassungsroutinen
und zur unmittelbaren Erzeugung von Schnittstellenereignissen von
der Testablaufsteuerung an die ausgewählten Schnittstellenanpassungsroutinen
durch die Netzwerkverteilungsebene und Schnittstellenverteilungsebene
durchgereicht. Reaktionen des zu testenden Systems werden zudem
als Testablaufinformation in Abhängigkeit
von Schnittstellenereignissen von den Schnittstellenanpassungsroutinen
durch die Schnittstellenverteilungsebene und Netzwerkverteilungsebene
ohne Vorauswertung und wesentliche Verzögerung an die Testablaufsteuerung
zurück übertragen.
-
Alternativ
oder ergänzend
hierzu kann auch eine indirekte Steuerung des Testablaufs durch Übertragung
von Testablaufinformationen an ausgewählte Schnittstellenanpassungsroutinen
und Zwischenspeicherung einer Abfolge von Testablaufinforma tionen
durch die Schnittstellenanpassungsroutinen erfolgen. Das Erzeugen
und Auswerten von Schnittstellenereignissen erfolgt dann losgelöst von dem Zeitverhalten
der aktuellen Testablaufsteuerung durch die Schnittstellenanpassungsroutine
autark in Abhängigkeit
von der zwischengespeicherten Abfolge von Testablaufinformationen.
Ergebnisse der Auswertung können
dann mit den Schnittstellenereignissen zu geeigneten Zeiten an die
Testablaufsteuerung zurückgegeben
werden.
-
Die
dezentralen Schnittstellenanpassungsroutinen haben insbesondere
für komplexe
verteilte Systeme erhebliche Vorteile, da die Schnittstellenbehandlung
entsprechend leichter skaliert werden kann. Außerdem kann die Verteilungs-
und Vermittlungsebene bei verschiedenen Testumgebungen eingesetzt
werden, so dass die Testbeschreibung/Testablaufinformationen unabhängig von
der Testausführung
und Vermittlung ist.
-
Bei
der indirekten Steuerung ist es vorteilhaft, wenn Schnittstellenereignisse
in Abhängigkeit von
durch zwischengespeicherte Testablaufinformationen vorgegebene Zeiten
und/oder Bedingungen erzeugt und/oder ausgewertet werden. Damit
wird die Durchführung
des Testablaufs weiter dezentralisiert und es können Ablaufverzögerungen
verringert werden, da die Übertragung
und Generierung von Ereignissen, Nachrichten und Funktionsaufrufen
dem Auslösezeitpunkt
zeitlich entsprechend vorgezogen werden kann.
-
Die
von den Schnittstellenanpassungsroutinen erzeugten oder erfassten
Schnittstellenereignisse der zu testenden Softwaremodule und/oder
Hardwarekomponenten können
zur Übertragung
von Nachrichten und Funktionsaufrufen vorgesehen sein. Die Schnittstellenanpassungsroutinen übertragen dann
die Nachrichten oder Funktionsaufrufe unidirektional oder bidirektional
als Testablaufinformation an die übergeordnete Testablaufsteuerung.
-
Die
Erfindung wird nachfolgend anhand eines Ausführungsbeispiels mit den beigefügten Zeichnungen
näher erläutert. Es
zeigen:
-
1 Blockdiagramm
eines zu testenden Systems mit Schnittstellen zu einer Testumgebung;
-
2 Blockdiagramm
einer vierschichtigen Testarchitektur zur Vermittlung und Verteilung
von Teststimuli und Testreaktion;
-
3 Blockdiagramm
einer Architektur zur Vermittlung und Verteilung von Teststimuli
und Testreaktionen mit einheitlicher Netzwerkverteilungs- und Schnittstellenverteilungsebene;
-
4 Skizze
der Funktionskomponenten von Schnittstellenanpassungsroutinen.
-
Die 1 lässt eine
Skizze eines zu testenden Systems SUT (System under Test) erkennen, das
mit einer Anzahl von Schnittstellen IF1,
IF2, ..., IFi, ...,
IFk mit einer Testumgebung 1 verbunden
ist. Die Schnittstellen IFi mit i = 1...k
werden über
software- und/oder hardwarespezifische Protokolle und Schnittstellenkanäle angesprochen. Über die
Schnittellen IFi erfolgt eine Stimulierung
der zu testenden Komponenten des zu testenden Systems SUT. Derartige
zu testende Komponenten können
Softwaremodule sowie Hardwarekomponenten sein.
-
Weiterhin
kann die Testumgebung 1 Reaktionen der zu testenden Komponenten
des zu testenden Systems SUT über
die Schnittstellen IFi empfangen und auswerten.
-
Die 2 lässt ein
Blockdiagramm einer Architektur zur Vermittlung und Verteilung von
Stimuli und Reaktionen von einer ersten oder alternativen zweiten übergeordneten
Testablaufsteuerung TR_a, TR_b an das zu testende System SUT erkennen.
Die übergeordneten
Testablaufsteuerungen TR_a, TR_b sind hierbei auf einer ersten Plattform
PF1 bzw. auf einer zweiten Plattform PF2 ablaufende Testroutinen. Die
jeweilige Testroutine TR führt
in der ersten gesamten Testablauf-Steuerungsebene die generelle Testablaufsteuerung
durch. Die Test-Stimuli und Reaktionen werden gemäß einer
Testbeschreibung verwaltet und der Gesamttestablauf gesteuert.
-
Eine
zweite Ebene E2a, E2b dient zur Verteilung von Testablaufinformationen
und zugeordneter Schnittstellenereignisse bzw. Schnittstellennachrichten.
In dieser zweiten Ebene E2 werden die einzelnen Stimuli und Reaktionen
auf verschiedene über ein
Netzwerk 2 verbundene Plattformen PF3, PF4, PF5 verteilt.
In einer Netzwerkverteilungsebene E2a erfolgt mit einer Netzwerkverteilungsroutine
die Steuerung der Kommunikation zwischen den Testablaufsteuerungen
TR_a, TR_b und den untergeordneten Schnittstellenverteilungsroutinen
SV1, SV2, SV3 der einzelnen Plattformen PF3, PF4, PF5 der an das Netzwerk 2 angeschlossenen
Anzahl m Plattformen PFI mit I = 1, 2, ...,
m. Die separate Netzverteilungsebene E2a mit den Netzwerkverteilungsroutinen
NV hat den Vorteil, dass die Art und die verwendete Technologie
der Netzwerkkommunikation einfach an die vorliegenden Systembedingungen
angepasst werden kann.
-
Eine
Schnittstellenverteilungsebene E2b dient zur Verteilung der Schnittstellenereignisse
auf die einzelnen Schnittstellenkanäle IFi mit
zugeordneten Schnittstellenanpassungsroutinen SRj mit
j = 1, 2, ..., k einer dritten Ebene, der so genannten Schnittstellenanpassungsebene.
Hierdurch wird die Netzwerkkommunikation und die Verteilung der
Schnittstellenereignisse bzw. Schnittstellennachrichten gebündelt und
gekapselt.
-
Optional
kann die Netzwerkverteilungsebene E2a auch mit der Schnittstellenverteilungsebene
E2b zusammengefasst werden, so dass die Testablaufinformationen
(Schnittstellenereignisse und Schnittstellennachrichten) über das
Netzwerk zu den jeweiligen Schnittstellenanpassungsroutinen SR vermittelt werden.
-
In
der dritten Ebene E3 erfolgt die Anpassung und Ansteuerung der software-
und hardwarespezifischen Schnittstellen der Softwaremodule und/oder
Hardwarekomponenten des zu testenden Systems SUT.
-
Eine
vierte Ebene E4, Testmodulebene genannt, beinhaltet die ausführbaren
zu testenden Softwaremodule und/oder Hardwarekomponenten des zu
testenden Systems SUT, die über
entsprechende Schnittstellenkanäle
IFi stimuliert und analysiert werden.
-
Der
Testablauf kann direkt durch Auslösen und Auswerten der Stimuli
und Reaktionen mit der Testablaufsteuerung oder indirekt von der
ersten Gesamttestablauf-Steuerungsebene
E1 vorgenommen werden. Bei einer direkten Steuerung des Testablaufs
werden die jeweiligen Stimuli zu den in der Testbeschreibung vorgegebenen
Zeitpunkten und Bedingungen von der ersten Ebene E1 ausgelöst und die erhaltenen
Reaktionen entsprechend ausgewertet. Das Passieren der untergeordneten
Ebenen E2a, E2b und E3 bis zur Testmodulebene E4 erfolgen direkt
und so schnell wie möglich.
-
Im
Gegensatz dazu werden bei einer indirekten Testablaufsteuerung die
Stimuli und Reaktionen zeitlich und testablauftechnisch im Vorhinein
abschnittsweise gruppiert bis zur dritten Ebene, der Schnittstellenanpassungsebene
vermittelt. Damit wird die Schnittstellenanpassungsebene E3 mit
den Teststimuli und Testreaktionen vorgeladen. Die Schnittstellenereignisse,
Schnittstellennachrichten und Schnittstellenfunktionsaufrufe werden
erzeugt und zwischengespeichert und von der dritten Ebene E3 aus
zu den vorgegebenen Zeitpunkten und Bedingungen ausgelöst und ausgewertet,
um die Übertragungs-
und Berechnungszeit der zweiten und dritten Ebene E2 und E3 vorzuziehen.
-
Das
direkte und indirekte Steuern der Stimuli und Reaktionen kann auch
kombiniert werden. So kann beispielsweise ein Testablauf mit Stimuli
und Reaktionen zuvor („offline") definiert werden
und indirekt von der dritten Ebene aus gesteuert werden. Während des
Testablaufs können
Stimuli (online) von der ersten Ebene aus in den Testablauf eingebracht werden.
-
Durch
die Trennung der Testablaufsteuerung von den Schnittstellenanpassungsroutinen
SR ist es möglich,
verschiedenste software- und hardwarespezifische Schnittstellen
zu verwenden und zu kombinieren. Die Testablaufsteuerung TR kann
zudem unter einer anderen Systemumgebung, wie beispielsweise einem
anderen Betriebssystem oder Rechner ablaufen, als die Schnittstellenanpassung.
-
Durch
die in mehrere Ebenen aufgeteilte Architektur ist eine gleichzeitige
Ansteuerung und Einbeziehung von Software- und Hardware-Schnittstellen
für Softwaremodultests
und Hardwarekomponententests möglich.
-
In
dem in 3 dargestellten Beispiel kann das zu testende
System SUT beispielsweise ein Modul eines verteilten Systems mit
einer seriellen RS232-Schnittstelle,
einem gemeinsam genutzten Speicher (Shared Memory) und einer CORBA-Schnittstelle
sein. Die Schnittstellenansteuerung erfolgt dann für die Shared-Memory-Schnittstelle
auf dem Rechner der Plattform PF8, auf dem das zu testende System
SUT ausgeführt
wird. Die Ansteuerung der seriellen Schnittstelle RS232 sowie der
CORBA-Schnittstelle erfolgt von zwei anderen Computern aus, den
Plattformen PF7 und PF9.
-
Auf
der ersten Ebene E1 wird zu Beginn von der Testablaufsteuerung (Testsoftware)
ein Testablauf eingelesen. Über
eine Bibliothek wird die Netz- und Schnittstellenverteilungsschicht
E2 in die Testablaufsteuerung eingebunden. Die Netz- und Verteilungsschichten
E2a, E2b sind in dem in der 3 dargestellten
Beispiel zusammengefasst und werden auf demselben Computer ausgeführt. Mittels
ein Bibliotheksfunktion der Netz- und Schnittstellenverteilungsschicht
E2 (z. B. distribut_event()) werden nach und nach kurz vor dem Start
der Testdurchführung sowie
fortlaufend während
der Testdurchführung
die Stimuli und Reaktionen zeitlich gruppiert von der Testapplikation
an die Verteilungsebene E2 übergeben und
von dort anhand der entsprechend der vorgegebenen Konfigurationsparameter
für die
Schnittstellenverteilung an die jeweiligen Schnittstellenanpassungen
bzw. Schnittstellentreiber SRj über das
Netzwerk 2 verteilt. Der Start der Testdurchführung ist zweigeteilt
und beinhaltet eine Initialisierungsphase und den eigentlichen Start
der Testdurchführung.
In der Initialisierungsphase werden die Schnittstellenanpassungen
und alle Schnittstellenkanäle
IFi und Kommunikationsverbindungen zu dem
zu testenden System SUT aufgebaut und vorbereitet und die gesamte
Testumgebung in der ersten bis dritten Ebene E1 bis E3 für die Testdurchführung aktiviert,
so dass im Anschluss beim eigentli chen Start des Testdurchlaufs
keine Verzögerungen
durch die Testumgebung und die Ebenen E1 bis E3 verursacht werden.
Anhand der Zuordnung eines Ereignisses zu einem Schnittstellenkanal
IFi in der Testbeschreibung erfolgt die
Adressierung und Auflösung
des Netzwerkrechners, auf dem sich der entsprechende Schnittstellentreiber
der Schnittstellenanpassungsroutine SR (dritte Ebene E3) befindet.
-
In
der dritten Ebene E3 erfolgt nach abgeschlossener Initialisierung
und Aktivierung des Schnittstellentreibers die Behandlung der Schnittstellenereignisse,
Schnittstellennachrichten und Funktionsaufrufe (Stimuli und Reaktion).
Dabei werden die von der zweiten Ebene E2 in Form von Testablaufinformationen
erhaltenen Schnittstellenereignisse zunächst von der abstrakten Beschreibung,
wie beispielsweise Schnittstellenereignisname, Schnittstellenfunktionsname,
Variablenname und Variablenwerte, in die konkrete Form entsprechend
des Protokolls des zu testenden Systems SUT gebracht. Dies geschieht
mit Hilfe einer einmalig zu programmierenden anwendungsspezifischen
Bibliothek, die von der Hard- und Softwareplattform des zu testenden
Systems SUT abhängig
ist. Für
die RS232-Schnittstelle würde
das bedeuten, dass die serielle RS232-Verbindung zunächst initialisiert
wird, indem die Länge
der Datenbits, die Anzahl der Stoppbits, die Parität, die Flusskontrolle
etc. gesetzt wird. Anschließend
kann eine bestimmte Nachricht an das zu testende System SUT gesendet
oder von dem zu testenden System SUT empfangen werden.
-
Die über die
Schnittstellen IF übertragenden Zeichenketten
werden in die geforderte Form umgewandelt (z. B. Binär in Hexadezimal).
Insofern weitere Verarbeitungsschritte oder Anpassungen für anwendungsunabhängige schnittstellenspezifische Hard-
oder Software-Schnittstellen erforderlich sind, werden diese vom
Schnittstellentreiber vorgenommen. Anschließend wird die Nachricht entweder
sofort an das zu testende System SUT versendet oder zwischengespeichert
und zu entsprechenden Triggerbedingungen an das zu testende System
SUT gesendet. Für
die Shared-Memory-Schnittstelle
wird in ähnlicher
Weise verfahren. Bei der CORBA-Schnittstelle muss der anwendungsabhängige Servant
der Plattform PF9 zunächst
einmal programmiert und dann in den Schnittstellentreiber eingebunden
werden. Nach der Initialisierung des Servant werden dann über die
Schnittstellenfunktionsaufrufe des zu testenden Systems SUT Daten
entgegengenommen und an das zu testende System SUT übergeben.
-
Die 4 lässt eine
Skizze der Funktionselemente einer Schnittstellenanpassungsroutine
SR erkennen. Mit einer Nachrichtenbehandlung MH wird die Entgegennahme
der Testablaufinformationen und die Generierung und Auslösung, sowie
der Empfang und die Auswertung von Schnittstellenereignissen übergeordnet
vorgenommen. Eine Funktion zur anwendungsprotokollspezifischen Nachrichtenerzeugung
MG dient dazu, Nachrichten zu erzeugen und bei Reaktionen Schnittstellenereignisse
anwendungsspezifisch auszuwerten.
-
Eine
hardware-/softwareschnittstellenspezifische Nachrichtencodier-/decodier-Funktion MC dient
dazu, die Schnittstellenereignisse schnittstellenspezifisch umzuwandeln.
-
Eine
Nachrichtenaustauschfunktion MX dient zur Steuerung des Nachrichtenaustauschs
und Überwachung
der Signalisierungszustände
der von der Schnittstellenanpassungsroutine angesteuerten Schnittstelle
IF.