Mit Einführung der Dienste Teletex und Bildschirmtext (Rechnerverbund) kam auf das Fernmeldetechnische Zentralamt in Darmstadt, FTZ, die Notwendigkeit zu, Testmöglichkeiten für die höheren Kommunikationsprotokolle bereitzustellen. Die Erfahrungen aus den Testarbeiten für die X.25-Protokolle bildeten die Basis der Entwicklung des Testzentrums "Petrus".
Hier ein Überblick über den Einsatz von Petrus (Protokoll-Entwicklungs- und Testrechner-Universal-System) im Bereich Btx-Rechnerverbund: Bereits zu Beginn der Entwicklung wurde größter Wert auf Flexibilität und leichte Handhabbarkeit des Systems gelegt. Dies bedeutete insbesondere, daß man in der Lage sein sollte, beide Seiten im Btx-Rechnerverbund protokollgerecht zu simulieren: den Verbundrechner der Btx-Vermittlungsstelle (Btx-VSt) und externe Rechner (ER). Unter Berücksichtigung dieser Forderung fiel sehr früh die Entscheidung, das Testsystem auf der Basis von "Referenzimplementationen" zu realisieren. Referenzimplementation bedeutete, die Protokolle EHKP4 und EHKP6 werden ohne Rücksicht auf Optimierungsaspekte oder Systemspezifika direkt nach den Normen implementiert. Der Anspruch der absoluten Korrektheit, der vielleicht durch den Namen Referenzimplementation assoziiert wird, kann natürlich nicht erhoben werden; höchste Entscheidungsinstanz bleiben im Zweifelsfall natürlich die relevanten Dokumentationen.
Netzanschluß über Standard-lnterface
Da die ER über Datex-P erreicht werden und demzufolge einen zugelassenen X.25-Anschluß haben, erstreckt sich die Testarbeit im Rechnerverbund (RV) auf die Protokolle ab der Schicht 4 (gemäß dem Protokollhandbuch für den Anschluß externer Rechner über Datex-P, Version 1.0 vom 20. 12. 83, herausgegeben vom FTZ Referat T 11 ). Der Netzzugang von Petrus wurde über ein Standard-Interface realisiert.
Für den Test der externen Rechner wurde aus mehreren Gründen das Konzept der Testresponder ausgewählt, das heißt, oberhalb des zu testenden Protokolls wird ein Modul installiert, das einen definierten Benutzer dieses Protokolls darstellt. Der Testresponder für EHKP4 ist so spezifiziert, daß alle relevanten Situationen beim Verbindungsauf- und -abbau und in der Datentransferphase getestet werden können. Die Steuerung erfolgt mittels festgelegter Kommandos, die über das reguläre Protokoll übertragen werden und dann die darunterliegende Protokollschicht in nahezu beliebige Zustände versetzt. Mit diesem Werkzeug lassen sich sehr viele Funktionen auf einfache Weise abtesten, ohne daß der Prüfling selbst aktiv werden muß. Ein besonderer Vorteil dieser Konfiguration (Bild 1) liegt noch darin, daß während der Entwicklung ein Produkt, zum Beispiel EHKP4, ohne darüberliegende Protokollschichten umfassend getestet werden kann.
Dieses schichtenweise Testen hat sich gerade bei der Realisierung der Rechnerverbund-Protokolle bewährt. Da sich wohl jeder Software- Entwickler zum Austesten seiner Programme eine mehr oder weniger aufwendige Testumgebung schaffen muß, ist die Nutzung von vorgegebenen Testmodulen nicht unbedingt als Zusatzaufwand anzusehen. Künftige Entwicklungen laufen sogar dahin, zu jeder Protokollspezifikation einen passenden Testresponder zu definieren, der dann einen hinreichenden Test einer Implementierung erlaubt.
Der Testresponder für den Test von EHKP6 und dem Btx-Dialogprotokoll (Schicht 7) wurde als Btx-Anwendung realisiert. Diese "Referenzanwendung" repräsentiert den vorgeschriebenen Minimalumfang eines externen Rechners und besteht aus fünf Btx-Seiten.
Bei der Spezifikation des Testresponders für den Test von EHKP4 und der Referenzanwendung für den Test von EHKP6 mußten Einfachheit und Effizienz miteinander verbunden werden. Die entsprechenden Beschreibungen (herausgegeben vom FTZ Referat T 12) dürften diese Kriterien erfüllt haben, da bei der Implementierung in den externen Rechnern kaum Probleme auftraten.
Realisiert auf der PDP11/44 unter Unix IS/3
Die Entwicklung der Rechnerverbund-Testprogramme konnte nicht auf der "grünen Wiese" beginnen, vielmehr standen einige Randbedingungen aus dem Projekt Petrus bereits fest: Als Hardware fungierte ein DEC-Rechner PDP11/44 unter dem Betriebssystem Unix IS/3. Diese Anlage diente sowohl als Entwicklungs- als auch als Zielmaschine für die
Testprogramme. Die Programmiersprache C hat sich in diesem Zusammenhang als sehr effektives Werkzeug erwiesen. Neben den erwähnten Referenzimplementationen von EHKP4 und EHKP6 waren weitere Module zur Teststeuerung erforderlich (Bild 2). Der Testdriver bildet das aktive Gegenstück zum Testresponder und steuert den Test der Schicht 4. Bemerkenswert ist, daß der Test nicht wie bei vielen anderen Konfigurationen auf der Ebene des Protokolls (Protocol-Data-Unit-(PDU)Ebene) gesteuert wird (Bild 3), sondern auf der der Service-Schnittstelle (Service-Data-Unit-(SDU)Ebene). Dieses Verfahren ermöglicht einen realitätsnahen Test, ist allerdings für das Testzentrum sehr aufwendig.
Da eine Referenzimplementation per Definition keine Fehler erzeugen kann, mußte EHKP4 um sogenannte Plus-Dienste erweitert werden. Diese zusätzlichen Funktionen der Service-Schnittstelle erlauben kontrolliertes
Fehlverhalten des Protokolls. Die Steuerung des EHKP6-Tests erfolgt nach dem gleichen Prinzip; hier kommunizieren die "Testsequenzen" mit der Referenzanwendung.
Jeder Testlauf führt zu einer Gut/ Schlecht-Aussage, wobei im Schlechtfall der momentane Zustand des Testsystems protokolliert wird. Zusätzlich werden automatisch alle relevanten Schnittstellen aufgezeichnet und in lesbarer Form abgelegt. Mit diesen Informationen kann ein erfahrener Bediener sehr schnell den Fehler lokalisieren. Da einzelne Testläufe (Testprozeduren) zu Testszenarien und diese wiederum zu Testketten flexibel zusammengestellt werden können, ist ein blockweises Analysieren nach Ablauf eines umfassenden Testprogramms möglich. Dadurch läßt sich der Durchsatz des Systems erheblich steigern.
Bei Problemen in einer "Life-Session" zwischen Btx-VSt und ER kann
Petrus als Spion transparent in diese Verbindung eingeschleift werden (Bild 4). Da die Einbindung über eine zweite Datex-P-Verbindung erfolgt, sind keinerlei Ortsveränderungen der beteiligten Komponenten erforderlich, was dem immobilen Charakter der externen Rechner Rechnung trägt. In der Spionfunktion zeichnet Petrus alle Ereignisse mit und gibt sie in aufgearbeiteter Form aus (Interpretation der PDUs der Schichten 4 und 6).
Neben dem normalen Protokoll verhalten Grenzwerte abtasten
Zur Abnahme der Btx-VStn wurden mehrere Testanwendungen geschrieben, die neben dem normalen Protokollverhalten die Grenzwerte des Btx-Systems abtesten. Ein universeller Anwendungsmonitor, der die Reproduktion verschiedenster Fehlerfälle erlaubt, ist zur Zeit in Entwicklung.
Als Rückfallposition oder für besonders ausgefallene Tests steht der "Manual Mode" zur Verfügung. Dieses Formatierungsprogramm erzeugt über eine Pseudosprache EHKP4- und EHKP6-PDUs, die, zusammengefaßt in Kommandodateien, zu selbständig ablaufenden Testsequenzen aufbereitet werden können. Diese sind natürlich sehr starr und beinhalten keinerlei Protokollintelligenz, was den Einsatz beschränkt.
Realisierung im Wettlauf mit Entwicklern
Das Gesamtprojekt wurde über einen Zeitraum von zwei Jahren realisiert: Der Aufwand liegt bei zirka sieben Mannjahren. Dies zeigt deutlich, daß für das Testen komplexer Kommunikationsprotokolle doch enormer Aufwand getrieben werden muß, wenn die kompatible Zusammenarbeit entsprechender Systeme sichergestellt werden soll. Ein Nachteil solch aufwendiger Entwicklungen ist, daß die Testwerkzeuge nicht vor Beginn der allgemeinen Implementationsarbeiten verfügbar sein können. Die Petrus-Realisierung für den Rechnerverbund war von Anfang an ein Wettlauf mit den Software-Entwicklern "der ersten Stunde".
Die externen Rechner werden im Rahmen des Zulassungsverfahrens (Anträge sind beim ZZF Saarbrücken, Tel. 06 81/58 61-0, erhältlich) auf die Einhaltung der Protokollvorschriften überprüft. Diese Prüfungen werden von der Dienststelle Btx in Düsseldorf (Tel. 02 11/ 8 82-77 67) durchgeführt. Um bereits vor der eigentlichen Abnahme Tests zu absolvieren, können externe Rechner direkt bei der oben genannten Stelle Implementationsunterstützung erhalten.
Protokollmäßige Abnahme von zirka 50 externen Rechnern
Mit Stand Dezember '84 wurden mittlerweile zirka 50 externe Rechner protokollmäßig abgenommen. Es hat sich eine durchschnittliche Verweildauer von zehn bis zwölf Stunden ergeben. Diese Stunden verteilen sich auf ungefähr fünf bis sechs Testsitzungen. Hierbei ist zu bemerken, daß es bei den Entwicklern unterschiedlichste Einstiegspunkte gibt: Die Palette reicht von lokal voll ausgetesteten Implementationen, die in ein oder zwei Sitzungen abgenommen werden, bis hin zu "Dauerbrennern", die ihre Software in sehr kleinen Stufen schreiben und jede Stufe einzeln abtesten beziehungsweise prüfen, ob keine neuen Fehler eingebaut wurden.
In Anbetracht dessen, daß es sich im Rechnerverbund fast ausschließlich um Neuentwicklungen handelte, ist der Testdurchsatz, der mit Petrus erzielt werden konnte, beachtlich.
Die Anforderungen an die Protokollkenntnisse der Testmannschaft sind trotz aller Automatismen in der eigentlichen Testdurchführung sehr hoch; die Fehlerlokalisierung anhand einer Vielzahl von Informationen, die das System bietet, bildet immer noch einen großen Zeitfaktor. In diesen Bereich gehören auch zeitraubende Gespräche mit den Entwicklern über die Auslegung der Spezifikationen. Auch die an sich gut beschriebenen Rechnerverbund-Protokolle bilden hier keine Ausnahme.
Abschließend kann gesagt werden, daß solch komplexe Systeme wie der Btx-Rechnerverbund nur durch konsequentes Bereitstellen aller möglichen Testwerkzeuge in vertretbaren Zeitspannen realisiert werden können. Der gesamte Bereich "Testen" gewinnt bei den zuständigen Normungsgremien zunehmende Bedeutung; durch eindeutige und vollständige Spezifikationen mit der entsprechenden Testumgebung läßt sich sowohl die Entwicklungssicherheit für die Hersteller als auch die Betriebssicherheit für die Anwender und Betreiber erheblich steigern.
*Manfred Pospich ist Mitarbeiter des Fernmeldetechnischen Zentralamtes der Deutschen Bundespost in Darmstadt.