Die Bereitstellung von Kommunikationsprotokollen entsprechend dem 7-Schichten-Modell der ISO verpflichtet die Deutsche Bundespost, neuartige Testverfahren zur Überprüfung der Endgeräte- beziehungsweise Netz-Endgerätekompatibilität zu entwickeln. Die Komplexität und die Vielfalt der Variationen dieser Kommunikationsprotokolle macht die Einführung automatischer Testverfahren unumgänglich. Derartige Testverfahren sind erforderlich für Protokollentwicklungen, Implementationsunterstützungen, Anschließung bei Endeinrichtungen, Abnahmen und Fehlereingrenzungen. Im folgenden wird ein Testverfahren für Endeinrichtungen am Datex-Netz mit Paketvermittlung vorgestellt (X.25).

In einer ersten Phase, die augenblicklich noch läuft, werden für Datendiagnosen geeignete Testgeräte eingesetzt, die sich später in ein größeres Konzept als Vorrechner ein betten lassen könnten. Diese Testgeräte erlauben erste Erfahrungen mit automatischen Protokolltests für X.25-fähige Endgeräte zu gewinnen.

Das Prüfverfahren für diese Endeinrichtungen stützt sich auf das sogenannte Prüfnormal Datex-P, einen "Vorschlag für die Zulassungsprüfung, Abnahme und Fehlereingrenzung von X.25-fähigen DEE", ausgearbeitet von der Ad-hoc-Gruppe 4 des Teilnehmerarbeitskreises Datex-P.

Die Ad-hoc-Gruppe 4 schlägt für den Prüffall vor, oberhalb der X.25 eine Software aufzusetzen (Software-Prüfstecker). Die Aufgaben des Prüfsteckers sind die Abkopplung der Anwendersoftware (Anwendung) und die Kommunikationssoftware (X.25) testbar zu machen.

Ziel ist, die X.25 unabhängig von der Anwendung zu testen. Nur die Protokollschichten der X.25 steuern die Datenübermittlung. Die höheren Schichten des Kommunikationsprotokolls steuern die Anwendung und sind im Datex-P-Netz transparent.

Internationale Testaktivitäten (zum Beispiel in Frankreich) zeigen einen Synchronismus der Ideen.

Der Vorschlag der Ad-hoc-Gruppe 4 des Teilnehmerarbeitskreises Datex-P wurde aufgrund der gegebenen Randbedingungen in drei Programmen realisiert:

- Prüfprogramm Ebene 2 (HDLC),

- Prüfprogramm Ebene 3 (Packet Level) und

- Spiegelungsprogramm Ebene 3.

Die Prüfprogramme sind im Prüfnormal detailliert beschrieben. Das Spiegelungsprogramm erzeugt eine große Datenmenge, die von der Endeinrichtung korrekt gespiegelt werden soll.

Die Tests können entweder vor Ort durchgeführt werden, am Standort des Testrechners (im FTZ, Anmerkung d. Redaktion) oder des zu prüfenden Geräts (Bild 2a) oder "remote" über Datex-L (Bild 2b) oder bei geeigneter Modemstrecke auch über das Fernsprechnetz (Bild 2c).

Es können grundsätzlich alle synchronen, duplexfähigen Verbindungen mit transparenten Übertragungswegen benutzt werden. Die Deutschen Bundespost bietet dafür das Datex-Netz mit Leitungsvermittlung, Benutzerklassen Datex-L2400, Datex-L4800 und Datex-L9600 sowie das Fernsprechnetz mit der Übertragungsgeschwindigkeit 1200 Bit pro Sekunde an.

Nach Aufbau der physikalischen Verbindung erfolgt der Test der Ebene 2. Es wird bei diesem Test davon ausgegangen, daß eine vollständige Ebene 2 implementiert ist und nicht eine Teilmenge. Als Systemparameter werden die Werte gefordert, die im Datex-P-Handbuch vorgegeben sind.

Anders als bei der Ebene 2 sind bei der Ebene 3 Implementationen in Teilmengen möglich (zum Beispiel nur gewählte virtuelle Verbindungen).

Damit die Tests der Ebene 3 effizient eingesetzt werden können, wurden die wichtigsten Parameter im Dialog einstellbar gemacht:

- Anzahl logischer Kanäle,

- Anzahl fester und gewählter virtueller Verbindungen,

- Kanalnummernraum,

- Adressen,

- Informationen im Benutzerdatenfeld des Anrufpakets,

- Angaben zum Prüfstecker (nicht vorhanden/passiv/aktiv),

- Fenstergrößen Paketebene.

Zur Durchführung eines Tests müssen diese Parameter bekannt sein.

Die Ergebnisse der Teilschritte der Prüfprogramme werden protokolliert und nach Testende das Gesamtergebnis festgehalten. Eine integrierte Statistik erlaubt die Durchführung weitergehender Analysen.

Wo liegen die Grenzen?

Ein Test, der dem Prüfnormal entspricht, erfaßt die Funktionen entsprechend X.25. Da ein Satz von kritischen Fehlerfällen erzeugt wird, erhält man die Gewähr, daß ein Endgerät hinreichend gut arbeitet, wenn es das Prüfverfahren erfolgreich durchlaufen kann. Falls Probleme auftreten, muß analysiert werden, ob echtes Fehlverhalten vorliegt oder ein Fall aufgetreten ist, der nicht durch das Prüfnormal abgedeckt wird. Es muß dann gegebenenfalls ein weiter er Test in das Programm eingearbeitet werden. Performancetests können mit diesem Verfahren nicht verwirklicht werden.

Das Prüfprogramm Ebene 2 befindet sich seit Ende '81 im Einsatz, die Programme zum Testen der Ebene 3 sind seit April dieses Jahres verfügbar.

Schwierigkeiten bei der Entwicklung ergaben sich insbesondere durch die Auslegungsspielräume der X.25-Empfehlung. Dabei zeigte es sich, daß die Mehrzahl der Fragen auf der HDLC-Ebene auftauchten. Die während der Testphase erhaltenen Anregungen und Verbesserungsvorschläge wurden in die Programme eingearbeitet, so daß die Freiräume in der Empfehlung größtenteils abgedeckt werden.

Die wirtschaftlichen Vorteile des Verfahrens sind offensichtlich: Die Tests benötigen wenig Zeitaufwand und sind wiederholbar. Beispielsweise dauert ein erfolgreicher Durchlauf des HDLC-Prüfprogramms weniger als eine Minute, während ein solcher Test mit einem manuellen Testgerät (SNAP-Tester; Anmerkung der Redaktion) von einem Experten durchgeführt drei Tage in Anspruch genommen hat. Zur Durchführung eines vollständigen Ebene-3-Tests dürfte eine Stunde genügen. Je nach Ausstattung des Prüflings sind bis zu sechs Testläufe erforderlich, wobei die meiste Zeit für die Einstellung der Parameter benötigt wird.

Die Tests auf der Paketebene haben in erster Linie die Frage nach Rechtfertigung des "Prüfsteckers" aufgeworfen. In der Tat kann der Aufwand für die Implementierung einer solchen Software erheblich sein nämlich dann, wenn die unteren Ebenen in der Firmware oder Hardware verschwinden. Aus diesem Grund besteht die Post nicht auf dem Vorhandensein des Prüfsteckers. Es liegt jedoch auf der Hand, daß ohne diese aufgesetzte Software die Tests länger dauern und damit kostspieliger werden.

Die erste Phase der Automatisierung der Testaktivitäten hat nach Ansicht der Post gezeigt, daß ein erfolgreicher Weg eingeschlagen wurde. Belegt werde dieser Eindruck auch durch das Interesse anderer Postverwaltungen. Der Bedarf an halbautomatischen Testprogrammen sei steigend; daher erscheine der bisher betriebene Aufwand gerechtfertigt.

*Doris Hillier und Erich Weber, Danet Gesellschaft für Beratung und Software-Entwicklung mbH, Darmstadt