Die Standardisierung im Rahmen der OSI-Kommunikation bringt zunehmend stabilere Normen hervor. Zugleich sind erste entsprechende Produkte verfügbar. Vernachlässigt wurden allerdings bisher Konzepte und Methoden, die den Testvorgang in Multi-Vendor-Umgebungen "handhabbar" und damit auch weniger kostenaufwendig machen.
Bisherige Erfahrungen haben gezeigt, daß das Testen von Realisierungen international standardisierter Protokolle äußerst komplex, zeit- und damit auch kostenintensiv ist.
Diese Problematik führte dazu, daß der Test- und Validierungsvorgang in den Normungsgremien eine verstärkte Aufmerksamkeit fand, und mittlerweile die ersten Vorschläge zu diesem Themenbereich erarbeitet worden sind. Von der internationalen Standardisierungsorganisation ISO liegt hierzu inzwischen ein fünfteiliges Konzeptpapier in Form des ISO Draft Proposals 9646 (Conformance Testing Methodology and Framework) vor.
Die Notwendigkeit eines systematischen und umfassenden Testens ergibt sich aufgrund zahlreicher konkreter OSI-Projekte, in denen international standardisierte Protokolle die Basis für die Vernetzung von Arbeitsplatzrechnern im Bürobereich sind. Es ist dabei auch notwendig, daß der Testvorgang, die dazugehörigen Testbeschreibungs-Sprachen und die Testfälle einheitlich definiert werden, damit sie zwischen den einzelnen Prüfsystemen ausgetauscht werden können. Bislang hat jedes einschlägige System eigene Sprachen für OSI-Protokolle erarbeitet, so daß - im internationalen Rahmen gesehen - ein erheblicher Overhead in Form von mehrteiligen Testspezifikationen für ISO-Normen besteht.
Da die an verschiedenen Stellen definierten Testfälle zwischen den unterschiedlichen Systemen nicht austauschbar sind, wird der notwendige internationale Harmonisierungsprozeß wesentlich verzögert. Bei der Implementierung eines Testfalls für die X.400-Protokolle rechnet man beispielsweise mit einem Aufwand von mehreren Tagen, für eine umfangreiche Prüfung müssen jedoch mehrere hundert oder tausend Exempel statuiert werden. Aus diesem Grunde ist eine internationale Standardisierung vonnöten.
Im Teil "Requirements on Test Laboratories and Clients" des ISO-Konzepts "OSI Conformence Testing Methodology and Framework" wird die grundsätzliche Organisation und die Regelung der Beziehung zwischen einem Labor und dessen Kunden beschrieben. Dieses Konzept mit dem Status eines Draft Proposals ist aus unserer Sicht durchaus positiv zu bewerten, wirft allerdings Probleme bei der Umsetzung auf. Der Grund dafür: Die Praxis hinkt hier weit hinterher.
Bevor auf diese Situation eingegangen wird, erfolgt zunächst eine Beschreibung des Modells (siehe dazu auch die Abbildung). Ausgangspunkt eines Tests sind:
- das PICS (Protocol Implementation Conformance Statement),
- das PIXIT (Protocol extra Information for Testing) und
- die AtS (Abstract Testsuite).
Als Ergebnis des entsprechenden Verfahrens entsteht ein detaillierter Bericht. Die von ISO standardisierten Protokolle lassen einen gewissen Spielraum bei der konkreten Realisierung von Kommunikationsinstanzen zu. Parameter, wie beispielsweise Reaktionszeiten auf einen Verbindungswunsch oder die Größe von gesendeten Datenpaketen, können in gewissen Grenzen frei gewählt werden. Der Standard legt lediglich das Intervall fest. Außerdem gibt es optionale Funktionen, bei denen keine verbindlichen Festlegungen vorliegen, ob diese zu implementieren sind oder nicht. Im PICS wird beschrieben, welche Parameter eines Protokolls bei dem zu testenden System gewählt wurden und welche Funktionen des Protokolls realisiert sind.
Im Pixit sind zusätzlich für das Prüfverfahren relevante Informationen beschrieben, die aber keine Bestandteile des Pics sind; beispielsweise darüber, an welchen Stellen das Verhalten des zu testenden Systems beobachtet werden kann und in welcher Form. Pixit bietet auch die Grundlage für die jeweilige Konfiguration. Diese ist abhängig von den Schnittstellen, an denen beobachtet und kontrolliert werden soll.
Durch den Spielraum bei der Implementierung einer Anlage muß für jedes zur Disposition stehende System eine individuelle "Suite" erstellt werden. Zur Rationalisierung dient ein generatives Verfahren, mit Ats als Ausgangspunkt. Es gliedert sich in die beiden Schritte Static Conformance Review und Test Campain. Im Rahmen von Static Conformance wird überprüft, ob die Informationen in Pics und Pixit konsistent sind und der Norm entsprechen, ob die gewählten Parameter vom Standard vorgesehen und alle obligaten Funktionen realisiert sind. Danach kommt dann die Ausführung der eigentlichen Testsuites an die Reihe.
Für HMS nach X.400 mehrere Wochen
Im Falle komplexer Protokolle ist dieser Vorgang sehr aufwendig. Beispielsweise rechnen herstellerunabhängige Testinstitute bei der Validierung von Message Handling Systemen nach dem CCITT-Standard X.400 mit mehreren Wochen. Um also etwaige Mehrarbeit aufzufangen, wenn Ergebnisse auf deutliche Mängel des Systems hinweisen, gliedert sich der Vorgang in unterbrechbare Schritte:
1. Mit den Basic-Interconnection-Tests wird überprüft, ob grundlegende Eigenschaften des Protokolls erfüllt sind.
2. Die Capability-Tests setzen sich mit den funktionalen Funktionen auseinander.
3. Die Behaviour-Tests widmen sich den obligaten Funktionen.
Nach jeder Stufe existiert ein "Negotiated Exit" (in der Abbildung mit NE markiert). Dort kann ein Abbruch des Tests zwischen dem Labor and dem Kunden vereinbart werden wenn eine Fortführung keine weiteren Erkenntnisse über das zu testende System erwarten läßt. Eine solche Möglichkeit besteht schon nach dem Static Conformance Review.
In der Praxis, beispielsweise bei den Message Handling Systemen, befinden sich die meisten Pics und Pixits noch in der Entwicklung. Dies bedeutet, daß die Grundlage für eine praktische Umsetzung der ISO-Konzepte noch nicht vorhanden ist und weiter forciert werden muß. Derartige Pics und Pixits sind erst erste Schritte hin zu einer einheitlichen Teststrategie auf internationaler Ebene. Auf der Grundlage dieser Definitionen muß man Testsuites realisieren, mit denen ein echter Validierungsvorgang unterstützt werden kann. Diese Suites können als Programme verstanden werden, die mit einer Testspezifikationssprache geschrieben sind und von einem Testsystem ausgeführt werden können. Deren Realisierung ist wesentlich aufwendiger als die Formulierung von "Pics" und "Pixits".
Aus der Programmierung ist bekannt, wieviel Zeit von der ersten Version zum stabilen Produkt erforderlich ist. Erschwerend kommt im Kommunikationsbereich hinzu, daß Testsuites keine gewöhnlichen sequentiellen Programme sind, sondern solche, die in einer verteilten Umgebung ablaufen. Ein Grund, war um von der ISO bislang noch keine einheitliche Spezifikationssprache definiert worden ist, liegt sicherlich auch darin, daß erst wenige Erfahrungen auf diesem Gebiet vorliegen. Der Nachteil dieser zögerlichen Haltung besteht darin, daß jede Gruppe die Testsuites formuliert, hierzu eine eigene Sprache verwendet.
Aufgrund der Erfahrungen in OSI-Projekten, die auf dem offenen Philips-Konzept Sophomation (Synergetic Open Philips Office Automation) basieren, sieht man bei PKI den gesamten Testprozeß nicht nur auf Überprüfung der Konformität zu den bestehenden Standards und der Interoperabilität zwischen verschiedenen Implementierungen beschränkt. Neben diesen grundlegenden Anforderungen an OSI-Implementierungen müssen beim Testen auch weitergehende Teilgebiete berücksichtigt werden. So ist es beispielsweise notwendig, daß die Implementierung auch hinsichtlich von Leistungsparametern validiert wird ( Performance Testing).
Implementierungen, die ein bestimmtes Antwortzeit-Verhalten nicht einhalten können, ergeben Engpässe im praktischen Betrieb. Diese lassen sich jedoch nicht auf Konformität und Interoperabilität testen, da hier keine anwendungs- oder benutzerbezogenen Leistungsmerkmale mit einfließen. Weiterhin ist es notwendig, daß die Implementierungen auch auf Robustheit gegenüber unterschiedlichen Anforderungen und Lastbedingungen überprüft werden.