Stefan Schmerler - Softwaretest in der Praxis

Für den Integrationstest wurden eine Reihe verschiedener Vorgehensweisen und Ausprägungen entwickelt, die im Folgenden kurz skizziert werden.

Hardware-in-the-Loop-Simulatoren

Beim Test automobiler Steuergeräteverbünde versteht man unter Integrationstest den gemeinsamen Test von Steuergeräten im Verbund. Häufig kommen Hardware-in-the-Loop-Simulatoren zum Einsatz, mit deren Hilfe die Umgebung der zu testenden Steuergeräte in Echtzeit simuliert wird. Dies betrifft also die gesamte Aktorik, Sensorik und das Umgebungsverhalten, quasi das »Restfahrzeug« aus Sicht der zu testenden Steuergeräte. Auf diese Technologie wird in einem eigenen Kapital noch explizit eingegangen.

Abb. 3-6: Steckbrief Integrationstest in der klassischen SW-Entwicklung

Hilfsmittel des Integrationstests sind

Testtreiber und Stubs (Platzhalter).

Da Systeme komponentenweise entwickelt werden, muss zwingend eine Integration erfolgen. Diese Integration kann nach unterschiedlichen Strategien abgesichert werden. Allen Ansätzen gemeinsam ist, dass Komponenten beim Test durch Treiber gesteuert werden, die es ermöglichen, ein Testobjekt ablaufen zu lassen, zu stimulieren und dessen Ausgaben zu erfassen. Zum anderen kommen beim Integrationstest Stubs zum Einsatz, also interfacekonforme, aber leere Hüllen ohne Funktion, die für den Test anderer Komponenten benötigt werden, z. B. um eine Kompilierung zu ermöglichen.

Abb. 3-7: Abhängigkeitsgraph mit Baumstruktur

Zur Darstellung der Prinzipien des Integrationstests werden Abhängigkeitsgraphen mit Baumstruktur genutzt (Abb. 3-7). Diese Graphen sind zyklenfrei, ihre Knoten sind Komponenten des SUT.

3.4.3.1 Big-Bang-Strategie

von Anfang an »das volle Programm«

Unter Big-Bang-Integrationsteststrategie versteht man den gleichzeitigen Test aller Komponenten im Gesamtsystem, also keine stufenweise, sukzessive Vergrößerung des Testgegenstands, sondern sofort das »volle Programm«.

Diese Strategie findet Anwendung bei kleinen Änderungen eines bereits ausgiebig getesteten Systems oder bei kleinen, sehr überschaubaren Systemen. Der Vorteil dieser Strategie liegt im geringen Aufwand, da keine Treiber zu erstellen sind.

Man lernt sofort das Gesamt-

system kennen, Fehler sind

aber schlecht lokalisierbar.

Als Nachteil ist die schwierige Lokalisierung von Fehlern zu sehen, sollten diese aufgetreten sein. Wir alle kennen das Phänomen der nicht wirklich hilfreichen Meldung »Es ist ein unbekannter Fehler aufgetreten«. Wir haben es beim Big-Bang-Test quasi mit einem Schnellschuss zu tun, der uns selbst im erfolgreichen Fall nicht viel weiterhilft, denn Schnittstellenfehler oder kompensierte/überdeckte Fehler müssen im Gegensatz zu einem Test auf Modulebene nicht zu Tage treten. Darüber hinaus kann die Wartezeit, bis ein Big-Bang-Test möglich ist, als verlorene Testdurchführungszeit angesehen werden, denn für die Durchführung dieser Tests muss das Gesamtsystem implementiert und testbar sein. Kann der Test dann durchgeführt werden, werden die Tester damit konfrontiert, dass alle Fehlerwirkungen geballt und gleichzeitig auftreten und nicht sukzessive beseitigt werden konnten. Es ist oft sehr schwierig, das System überhaupt zum Laufen zu bringen.

Nichtinkrementelle Integration nach dem Big-Bang-Prinzip sollte außer unter den oben genannten Bedingungen vermieden werden. Andererseits kommt die inkrementelle Systementwicklung für die Anwendung des Big-Bang-Integrationstests durchaus in Frage. In vielen iterativen Zyklen reift und wächst ein Gesamtsystem bei häufiger Validierung gegen die Anforderungen. Dies erfordert implizit immer den Gesamtkontext, d. h. den Test des Gesamtsystems. Da die Entwicklungsinkremente von Zyklus zu Zyklus immer überschaubar bleiben, entsteht bei regelmäßiger, hochfrequenter Anwendung dieser Teststrategie nicht die oben geschilderte, unkontrollierbare Fehlerhäufung, die letztlich keine konkreten Erkenntnisse mehr bringt als die Tatsache, dass das System fehlerhaft ist.

Abb. 3-8: Big-Bang-Integrationsteststrategie

3.4.3.2 Bottom-up-Strategie

Wir benötigen viele Treiber.

Bei der Bottom-up-Integrationsteststrategie wird ein Test von den Blättern des Abhängigkeitsgraphen aus in Richtung Wurzel durchlaufen. Die jeweils darüber liegende Ebene wird mit Treibern umgesetzt. Danach folgen Implementierung und Test der Ebene, in der sich die Treiber befanden (einschließlich deren Blätter).

sukzessive, kontrollierte

Erweiterung des Scopes

Der Vorteil dieses Verfahrens ist die kontrollierte und systematische Ausweitung des Testgegenstands. Zudem besteht die Möglichkeit, die Komponenten des SUT parallel zu entwickeln. Die Möglichkeit, mittels frühzeitiger Simulation ein Gesamtsystem das erste Mal »zu erfahren«, ist allerdings nicht gegeben. Treten während der Integration der Komponenten Fehler auf, ist das Ergründen der Ursachen schwieriger als bei der gleich folgenden Top-down-Strategie.

erhöhter Aufwand

Als Nachteil ist sicher der Aufwand zu sehen, der aufgrund der Treiberentwicklung deutlich höher sein kann als bei der Entwicklung des SUT. Bei geschicktem Vorgehen lässt sich der Aufwand durch Wiederverwendung der Treiber allerdings in Grenzen halten.

Für komplexe, verteilt entwickelte Systeme kommt man häufig an der Bottom-up-Strategie nicht vorbei. Sie ermöglicht die parallele, unabhängige Entwicklung verschiedener Systemkomponenten durch mehrere Teams oder Entwickler, die dann auf kleinstmöglicher Integrationsebene mit- und gegeneinander getestet werden. Eventuelle Schnittstellen- oder logische Fehler können auf diese Weise sofort erkannt werden.

Abb. 3-9: Bottom-up-Integrationsteststrategie

3.4.3.3 Top-down-Strategie

Beim Integrationstest nach der Top-down-Strategie beginnt die Absicherung beim Kontrollobjekt des SUT, also der Wurzel des Baums, mithilfe eines Treibers. Die Erweiterung des Testgegenstands erfolgt von oben nach unten in Richtung der Blätter des Abhängigkeitsgraphen (Abb. 3-10), wobei die getestete höhere Schicht jeweils als Testtreiber dient.

Abb. 3-10: Top-down-Integrationsteststrategie

stets das Gesamtsystem im Blick

Dies unterstützt eine iterative Entwicklungsweise. Zu jedem Zeitpunkt hat man das Gesamtsystem im Blick, dessen Funktionalität sukzessive erweitert und verfeinert wird. Man erhält schnell einen ersten Gesamteindruck und kann die Entwicklung der fehlenden Komponenten schrittweise vorantreiben. Ein weiterer Vorteil dieses Verfahrens ist die Tatsache, dass nur ein Treiber implementiert werden muss. Nachteil der Top-down-Strategie ist allerdings die Implementierung vieler Stubs. Da diese aber in der Regel leere Funktionen sind, bleibt der Aufwand dafür überschaubar.

3.4.3.4 Collaboration-Strategie

Die Collaboration-Strategie orientiert sich an der Funktion des zu entwickelnden Systems. Bei jedem Testdurchlauf wird der Teil des SUT betrachtet, der für eine bestimmte Funktionalität zuständig ist. Alle hierbei beteiligten Softwarekomponenten – aber nur diese – werden ausgeführt und erprobt.