Testkonzept - Teststufe Schnittstellentest

Die Ergebnisse des Schnittstellentest sind zu dokumentieren.

Ein Schnittstellentest verfolgt das Ziel einer sukzessiven Integration von elementaren Testobjekten über Sub-Systeme bis zum kompletten System. Neben der Verarbeitung von einzelnen Modulen erfolgt primär eine Überprüfung von Programm zu Programm Schnittstellen der jeweils im Testobjekt betroffenen Module.

Der Schnittstellentest wird durch die Entwicklung vorbereitet und durchgeführt. Hierbei wird ein in der Hierarchie weiter oben stehendes Modul ausgeführt, welches wiederum ein anderes Modul aufruft. Diese Programmschnittstellen werden – im Gegensatz zum Modultest nicht simuliert – sondern real ausgeführt.

Auf Grund eines hohen Risikos sind alle Schnittstellen zu anderen Systemen zu ermitteln. Speziell die Schnittstellen eines Buchführungssystems bergen Ordnungsmäßigkeitsrisiken, die einer besonderen Beachtung bedürfen.

Ziele der Teststufe

Der Schnittstellentest befasst sich neben der Verarbeitung der einzelnen Module primär mit der Überprüfung der Programm-Programm-Schnittstellen der Module, die im jeweiligen Test-Objekt mitlaufen.

Hierzu wird ein Modul ausgeführt, das wiederum andere Module aufruft. Die korrekte Verarbeitung der Daten innerhalb des Moduls ist nicht Bestandteil des Schnittstellentests, hierfür zeichnet der vorgelagerte Modultest verantwortlich.

Diese Programmschnittstellen werden real ausgeführt und nicht mehr, wie im Modultest, simuliert. Studien haben gezeigt, dass ca. 40 % der Programmfehler Schnittstellenfehler sind.

Im Schnittstellentest wird einerseits überprüft, ob die Eingabedaten hinsichtlich ihrer Gültigkeit (syntaktisch, regelkonform) und Korrektheit (semantisch, gültige Werte) überprüft werden (Error-Handling). Hierbei sollten auch Grenzwerte verwendet werden, da diese häufig nicht korrekt verarbeitet werden.

Andererseits wird überprüft, ob die Ausgabedaten dem erwarteten Ergebnis für die übergebenen Eingabedaten entsprechen. Schnittstellen bieten immer eine Antwort, diese kann synchron erfolgen (sofortige Antwort mit allen Daten) oder asynchron (zuerst nur die Rückmeldung der Annahme der Anfrage, später dann die separate Zustellung der Daten).

Die Prüfungen sollten in der Regel durch entsprechend programmierte Testprogramme (Testklassen, Skripte) ausgeführt werden.

In Abgrenzung zum Modultest kann ein Schnittstellentest prinzipiell nur nach einer vorherigen Absprache mit den Entwickler(n) für mehrerer interagierender Module in der Entwicklungsumgebung durchgeführt werden, da alle notwendigen Module rechtzeitig vorhanden, integriert und konfiguriert sein müssen.

Testobjektabgrenzung

Der Schnittstellentest ist kein Test zur Sicherstellung der Funktionalität der hinter der Schnittstelle aufgerufenen Module. Eine Ausweitung des Schnittstellentests durch eine große Kombinatorik an übergebenen Daten, um alle möglichen Konstellationen zu testen, darf nicht durchgeführt werden.

Für den Bereich des Schnittstellentests gibt es zwei wesentliche Vorgehensweisen um Testobjekte abzugrenzen, die Top-Down- und die Bottom-Up-Methode.

In beiden Fällen werden ausgehend von einem ersten Test-Objekt sukzessive weitere Module entsprechend des zugrunde liegenden Modulbaumes hinzugefügt.

Es kann sich dabei handeln um:

» Batchketten

» Maskenfolgen

» Aufrufe von Modulen der Datenhaltung von Maskenmodulen via Verarbeitungsebene

Neben den neuen oder geänderten Schnittstellen des Projekts sind auch die geschäftskritischen Schnittstellen generell regressiv zu überprüfen, um mögliche Nebenwirkungen durch das Projekt frühzeitig festzustellen.

Risikoanalyse

Das Risiko kann generell methodisch, aber auch über Erfahrungswerte ermittelt werden.

Das Gesamtrisiko setzt sich aus der Risikoklasse (fachlich) und der Komplexität (technisch) zusammen. Auch im Schnittstellentest muss wie im Modultest mindestens die Komplexität ermittelt werden; optional auch die Risikoklasse.

Es werden die Komplexität und die Anzahl der Beziehungen der Schnittstelle zu anderen Objekten sowie optional auch das Risikopotential der Schnittstelle bewertet. Je komplexer ein Testobjekt ist, desto höher sind die Aufwände für die Durchführung der Testaktivitäten.

Schaubild: Kriterien für die Risikobewertung im Schnittstellentest

Kriterium	Ausprägung
Kriterium	hoch	mittel	gering
Anzahl der verknüpften Module	> 5	2 bis 5	< 2
Anzahl der Schnittstellenparameter	> 7	4 bis 7	< 4
Anzahl der Aufruf-Varianten	> 5	3 bis 5	< 3
Anzahl möglicher Fehlermeldungen	> 12	5 bis 11	< 5

Die hier angegebenen Kriterien sind lediglich Beispiele, die angepasst und ergänzt werden müssen. Die Auswertung der Beurteilung der Kriterien erfolgt z.B. nach folgenden Entscheidungsregeln:

Komplexität	Bewertungsregel
1	Mindestens 2 Kriterien mit hoher Komplexität führen zu dieser Gesamtkomplexität
2	Ein Kriterium mit hoher und mindestens ein Kriterium mit mittlerer oder mindestens zwei mit mittlerer Bedeutung führen zu dieser Gesamtkomplexität
3	Sonstige Kombinationen führen zu dieser Gesamtkomplexität

Testmethoden

Beim Schnittstellentest wird das inkrementelle Testen vom Big-Bang-Testen unterschieden:

Big-Bang-Testen	Das System wird nach seiner Fertigstellung in seiner Gesamtheit getestet.
Inkrementelles Testen	Das inkrementelle Testen folgt in der Regel der Integrationsstrategie der Systementwicklung durch das schrittweise Zusammenführen der Einzelmodule entstehenden Subsysteme bzw. des Gesamtsystems.

Je nach Risiko sind verschiedene Testmethoden einsetzbar. Statische Tests sind beim Schnittstelletest kaum noch sinnvoll. Von daher sollten überwiegend dynamische Tests durchgeführt werden.

Folgende Testmethoden lassen sich für den Schnittstellentest sinnvoll verwenden:

» Entscheidungstabellentest

» Äquivalenzklassenanalyse

» Grenzwertanalyse

» Klassifikationsbaum-Methode

» Error-Guessing

Testfallermittlung

Bei der Testfallermittlung durch die IT sind andere Schwerpunkte zu betrachten als in der Fachabteilung. Grundlage für die Ermittlung von Testfällen sind das DV Umsetzungskonzept und die dort definierten Spezifikationen der Schnittstellen.

Die Schnittstellen können hierbei für interne Services, Datenzugriffe, komplexe Berechnungen, Prozess-Schritte, Dialog-Funktionen oder weitere Anwendungen definiert sein. Aus diesen werden die Testkriterien (zu testende Funktion, Transaktion etc..) abgeleitet, die durch die Testfälle verifiziert werden sollen.

Zusätzlich sollten die Testfälle aus dem Modultest und aus dem Fachbereich analysiert werden und aus diesem Wissen evtl. weitere relevante Testfälle entwickelt werden. Eine weitere Quelle für die Testfallermittlung stellen die Konzept-Dokumente dar. Hier sind speziell die Architekturdiagramme, das DV-Konzept und das Schnittstellenkonzept relevant.

Es ist mindestens ein Testfall pro spezifizierte Anforderung der Schnittstelle mit positivem und negativem Testausgang (Fehlerfall) zu testen. Hierbei sind typische Fehlervarianten (technische und fachliche Abweichungen) zu betrachten.

Im Testkonzept ist festzulegen, welche Testmethoden genutzt werden. Dabei wird eine risikoadäquate Festlegung vorgenommen, d.h. für die verschiedenen Risikoklassen werden geeignete Methoden festgelegt.

Testdatendefinition

Bei der Testdatendefinition ist nach Möglichkeit auf vorhandene Testdaten aus den IT- oder Fachbereich-Tests zurück zu greifen. Für eigene zusätzliche Tests sind Standardwerte, Grenzwerte und Critical-Dates in der Testmethodik zu berücksichtigen.

Die Überprüfung des Verhaltens bei der Übergabe falscher Eingabedaten ist ein sehr wichtiger Testbereich, der häufig in der Entwicklung und beim Modultest vernachlässigt wird, da die korrekte Funktion mit richtigen Eingabedaten stärker im Fokus des Entwicklers liegt.

Die Testdaten zu den einzelnen Testfällen ergeben sich aus der aufgerufenen Schnittstelle.

Grundlage ist immer die Beschreibung der Schnittstelle, aus der die jeweiligen Datensätze als Standardwerte abgeleitet werden. Hier gilt der Grundsatz, dass möglichst wenig, ausgehend vom technisch und fachlich korrekten Datensatz, verändert werden soll, um den gewünschten Effekt zu erreichen.

Der technisch und fachlich korrekte Datensatz ist Gegenstand des ersten Testfalls. Die hier verwendeten Daten sollen einem durchschnittlichen Aufruf des Moduls entsprechen, Sonderfälle sind hier nicht Gegenstand der Betrachtung (sie werden im Modultest bearbeitet). Im Testfall sind das verwendete Szenario sowie die erwartete Antwort zu dokumentieren.

Bei der Erstellung des technisch unkorrekten Datensatzes soll nach Möglichkeit nur eine einzige definierte Veränderung eingefügt werden. Diese Veränderung ist in der Testfallbeschreibung zu dokumentieren. Parallel dazu ist in der Testfallbeschreibung zu dokumentieren, warum diese Veränderung den Datensatz in validiert und welche Fehlermeldung erwartet wird. Dieser Test ist nur dann durchzuführen, wenn es überhaupt möglich ist, einen technisch unkorrekten Datensatz zu übergeben.

Beim fachlich invaliden Datensatz darf jeweils nur eine Änderung durchgeführt werden, es sei denn, in der Antwort erfolgt eine auf das einzelne Attribut bezogene Auswertung der Fehler. Nur so ist eine korrekte Zuordnung der verschiedenen Fehlermeldungen möglich. Auch hier sollte in der Testfallbeschreibung dokumentiert werden, warum die jeweilige Veränderung den Datensatz fachlich in validiert und welche Fehlermeldungen erwartet werden.

Testausführung und -auswertung

Die Testausführung erfolgt sowohl manuell als auch automatisch. Der Schnittstelltest sollte nachvollziehbar und Re-Test fähig sein. Auf Grund der Komplexität, die sich bei integrativen Tests häufig ergibt, ist eine Automatisierung der Testausführung evtl. komplexer.

Mögliche Unterstützung durch zur Verfügung stehende Prozeduren
»	für Bereitstellung von Testdaten in der Testumgebung
»	bei Sicherung von Testergebnissen
»	bei Aufbereitung von Testergebnissen für die Auswertung
»	beim Vergleich von Soll und Ist Ergebnissen

Um das Testvorgehen und die erreichten Ergebnisse nachprüfbar machen zu können, ist die Ausführung der Tests grundsätzlich durch Testnachweise zu protokollieren.

Testeingangskriterien

Für die zu testenden Module muss der Modultest erfolgreich abgeschlossen sein, d.h. die Testendekriterien der vorgelagerten Teststufe sind erfüllt worden.

Testendekriterien

Die Testendekriterien sind projektspezifisch im Testkonzept festzulegen. Generell sind die Testendekriterien so auszulegen, dass im Anschluss der technische Integrationstest laufen kann.

Testende Kriterien für den Schnittstellentest können sein:

» Mindestens einmaliges Testen aller Schnittstellen

» Mindestens einmaliges Testen aller geänderten / neu implementierten Funktionen

» Mindestens einmaliges Abarbeiten aller Ein-/ Ausgabe Testfälle

» Mindestens einmalige Überprüfung aller implementierten Benutzerschnittstellen auf formale

Korrektheit

Regressionstest

Im Regressionstest sind die Schnittstellentests zumindest für die möglicherweise von Änderungen primär oder sekundär betroffenen Schnittstellen zu wiederholen, um sicherzustellen, dass die Kompatibilität der Schnittstellenkomponenten nicht durch Änderungen beeinträchtigt wurden.

Eine Automatisierung der Regressionstests ist bei häufiger Ausführung in der Regel sinnvoll. Es sind bevorzugt die Schnittstellen zu testen, die die wichtigsten und kritischsten Verarbeitungsprozesse betreffen.

Die Auswahl der Regressionstests ist von Release zu Release kritisch zu hinterfragen und bei Notwendigkeit anzupassen.