Integrationstest

R 2.0.0

Was ist ein Integrationstest?

Was ist ein Integrationstest?

Eine Teststufe mit dem Schwerpunkt auf dem Zusammenwirken zwischen Komponenten oder Systemen.

Als nächste Teststufe nach dem Komponententest schließt sich der Integrationstest an. Der Integrationstest setzt voraus, dass die ihm übergebenen Testobjekte (z. B. einzelne Komponenten) bereits getestet sind und Fehlerzustände möglichst bereits korrigiert wurden.

Was Unit Tests für einzelne Komponenten sind, sind Integrationstests für das Gesamtsystem: Ein unverzichtbares Mittel, um Qualität und Funktionalität des Codes jederzeit gewährleisten und im Falle eines Problems sofort reagieren zu können.

Anwendungsbeispiel

Anwendungsbeispiel
ALT MISSING

Eddy ist als Komponentenverantwortlicher für die Wartung und Pflege einer komplexen Softwareanwendung zuständig. In der Vergangenheit musste er häufig Inbetriebnahmen verschieben und auch einmal eine schon auf der Produktionsumgebung installierte Software zurückfahren, weil schwere Fehler auftraten. Das will er in Zukunft verhindern und hat sich deswegen damit beschäftigt mit welchen Mitteln er stetige Verbesserungen seiner Anwendung erreichen kann. Zunächst hat er sich mit der ersten Teststufe, dem Komponententest auseinandergesetzt und eine Reihe von Verbesserungen eingeführt. Die vom Hersteller gelieferten Ausführungsberichte liest er sorgfältig durch und ergänzt sie durch eine qualitative Bewertung, in die Testabdeckungsgrade und Metriken zur Codequalität einfließen. „So wird erst ein brauchbarer Testbericht daraus", findet er.

ALT MISSING

Aber etwas Merkwürdiges muss er feststellen: Während die Anzahl der geschriebenen Komponententests stetig zunimmt und die Kennzahlen zur Codeabdeckung steigen, werden in der Produktion und in den Testumgebungen immer noch Fehler gefunden. Sicher, die Anzahl hat abgenommen, aber nicht in dem Maß, in dem Eddy das erwartet hätte. Er nimmt sich vor die Logdateien, die während der Ausführung der Anwendung geschrieben werden und in denen die Fehler dokumentiert sind, zusammen mit einem erfahrenen Entwickler zu reviewen. Zusammen mit Kurt vereinbart er einen passenden Termin und sie sehen sich die Dateien an.

ALT MISSING

Die Komponenten selbst weisen deutlich weniger Fehler auf, so stellen sie fest, aber dort, wo sie mit anderen Komponenten Zusammenarbeiten, an den Schnittstellen, treten mitzunehmender Entwicklung Fehler auf. „Wie ist denn Deine Teststrategie bei den Integrationstests?" fragt ihn Kurt. Eddy rutscht verlegen auf seinem Stuhl herum. „Nun, die kann sicher noch verbessert werden", druckst er. Tatsächlich hatte er daran noch gar nicht gedacht.

ALT MISSING

Zusammen mit dem Hersteller der Anwendung und Theo, dem Testmanager, wird er in den nächsten Tagen eine geeignete Integrationsstrategie entwickeln und die Schnittstellen durch Testfälle qualitätssichern. Theo beruhigt ihn: „Schau mal, die gute Nachricht ist doch, dass wir so viel Verbesserungen bei den Komponententests eingeführt und umgesetzt haben. Dadurch haben wir nun beste Voraussetzungen für den Integrationstest geschaffen, eine solide Basis." Da fällt Eddy wieder ein, was er in der Schulung zum Testmanager gelernt hat: Die vier Stufen: Komponententest - Integrationstest - Systemtest - Abnahmetest bauen aufeinander auf und Schwächen bei den frühen Teststufen können nicht durch verstärkte Bemühungen im System- oder Abnahmetest „geheilt" werden.

ALT MISSING

Gemeinsam gehen sie die wichtigsten Punkte der Teststrategie durch: Beim Integrationstest steht die Verifikation von Rückgabewerten der Komponentenschnittstellen im Vordergrund. Ist die aufrufende Komponente noch nicht implementiert, kann mithilfe eines Testtreibers gegen die fertiggestellte Komponente getestet werden. Im umgekehrten Fall können die Aufrufe einer Komponente gegen einen Mock geprüft werden. „Jede Schnittstelle sollte mindestens durch einen Testfall überprüft werden", meint Eddy. Die daraus abgeleitete prozentuale Testabdeckung wird im Testbericht diskutiert und bietet eine solide Kennzahl um eine Risikobewertung vornehmen zu können. „Wenn Du das konsequent umsetzt, hast Du eine ausgezeichnete Basis für den Systemtest geschaffen, und das Projektrisiko nachhaltig verringert", bestätigt Theo. „Viele dieser Tests lassen sich automatisieren und so kannst Du Deine Ressourcen zukünftig besser und zielgerichteter einsetzen."

Beschreibung

Das Ziel von Integrationstests besteht darin, Fehler aufzudecken, die ein Unit Test allein nicht finden kann. Das liegt vor allem daran, dass der Unit Test die einzelnen Programmeinheiten eines Softwareprojekts unabhängig von allen anderen betrachtet. Das reicht völlig aus, wenn es nur darum geht zu gewährleisten, dass der Code das tut, was man von ihm erwartet, ist aber unzureichend, wenn man sicherstellen will, dass die Kommunikation mit anderen Modulen reibungslos läuft.

  • Durch die Integrationstests werden frühzeitig Abweichungen bei den Schnittstellen, Komponenten oder Systeme festgestellt

  • Ziel ist die Integration der notwendigen Komponenten und Subsysteme zu einem lauf- und funktionsfähigem Gesamtsystem

  • Sie helfen, die Mängel (Funktionalität bzw. Design-Lücken) frühzeitig zu finden, was wiederum Aufwand und Kosten spart

Es gibt zwei mögliche Integrationsstufen:

  • Komponentenintegrationstest - liegt häufig in der Verantwortung der Entwickler.

  • Systemintegrationstest - wird i.d.R. von Testern und Entwicklern durchgeführt.

ALT MISSING
Abb. 1: Testpyramide Integrationstest

Wie beim Komponententest stärken auf die Integration spezialisierte Regressionstests das Vertrauen, dass bestehende Schnittstellen, Komponenten oder Systeme durch Änderungsanforderungen nicht beschädigt wurden.

Eine frühe Planung der Integrationsstrategien und des Integrationstests ermöglicht eine definierte Reihenfolge der zu entwickelnden Komponenten oder Systeme, die für das effizienteste Testen erforderlich ist.

  • Eine Risikoanalyse der komplexesten Schnittstellen kann dabei helfen, die Integrationstests zielgerichtet einzusetzen.

Je größer der Umfang der Integration, desto wichtiger wird eine eindeutige, leicht lesbare und nachvollziehbare Instrumentierung der Testobjekte und der Testfalltreiber, bzw. Mocks. Dadurch wird eine aufwändige Ursachenforschung vermieden und fehlerhafte Testobjekte können leichter identifiziert werden.

  • Geringeres Risiko und schnellere Fehlerbehebung.

Video: Erläuterung der Ziele und des Vorgehens beim Integrationstest (Länge: 24:58)

Komponentenintegrationstest

Der Komponentenintegrationstest ist der Test der Kommunikation zwischen den Komponenten. Wir gehen bei der Beschreibung sowie Reifegradermittlung von dieser Teststufe aus.

  • prüft Interaktionen und die Schnittstellen zwischen integrierten Komponenten.

  • wird nach dem Komponententest durchgeführt.

  • ist generell automatisiert.

  • bei der iterativen und inkrementellen Entwicklung sind Integrationstests in der Regel Teil des kontinuierlichen Integrationsprozesses (Continuous Integration)

Systemintegrationstest

Darüber hinaus gibt es den Systemintegrationstest, der die Kommunikation zwischen den getesteten Systemen prüft.

  • prüft das Zusammenspiel verschiedener Systeme

  • konzentriert sich auf die Interaktionen und Schnittstellen zwischen Systemen

  • kann nach dem Systemtest ausgeführt werden und betrachtet die Umgebung des entwickelten Systems

  • Herausforderung: Häufig hat das Entwicklungsteam nur eine Seite der Schnittstellen unter Kontrolle

Jede Teststufe hat individuelle Testziele, Testbasis, Testobjekte, Testvorgehensweisen, Verantwortlichkeiten sowie typische Fehlerzustände & -wirkungen.

Unterschied zwischen Komponententest und Integrationstest

Während Komponententests gut gekapselt sind und keine externen Ressourcen verwenden, verwenden Integrationstests zusätzliche Komponenten oder Infrastrukturen wie das Netzwerk, die Datenbank oder das Dateisystem.

Komponententests werden entworfen und ausgeführt, um zu prüfen, ob eine einzelne Softwarekomponente wie gewünscht arbeitet. Der Test zielt auf die Aspekte „interne Funktionalität“ der Komponente und „Robustheit“ gegen Fehlverwendung (z. B. Aufruf mit falschen Parameterwerten).

Integrationstestfälle werden entworfen und ausgeführt, um zu prüfen, ob zwei oder mehrere Softwarekomponenten wie gewünscht zusammenarbeiten. Der Test untersucht und prüft den Datenaustausch zwischen Komponenten.

Komponententest Integrationstest

Beim Komponententest wird jedes Modul der Software separat getestet.

Beim Integrationstest werden mehrere Module der Software kombiniert getestet.

Beim Komponententest kennt der Tester das interne Design der Software.

Beim Integrationstest ist das interne Design der Software nicht bekannt.

Komponententests werden vor allen Testprozessen durchgeführt.

Integrationstests werden nach dem Komponententest und vor dem Systemtest durchgeführt.

Komponententests sind White-Box-Tests.

Integrationstests sind Black-Box-Tests.

Komponententests werden grundsätzlich vom Entwickler durchgeführt.

Der Integrationstest wird vom Tester durchgeführt.

Das Erkennen von Fehlern in Komponententests ist einfach.

Das Erkennen von Fehlern beim Integrationstest ist schwierig.

Er testet Teile des Projekts, ohne auf die Fertigstellung anderer zu warten.

Er testet erst nach Fertigstellung aller Teile.

Komponententests sind weniger kostspielig

Integrationstests sind teurer.

Integrationsteststrategien

Top-down

Der Test beginnt mit einer Komponente des Systems, die eine weitere Komponente aufruft, aber selbst (außer vom Betriebssystem) nicht aufgerufen wird. Die untergeordneten Komponenten werden dabei, wenn sie noch nicht vorhanden sind, durch Platzhalter (Mock- bzw. Dummy-Objekte) ersetzt. Sukzessive werden die Komponenten niedriger Systemschichten hinzuintegriert. Die getestete höhere Schicht dient dabei jeweils als Testreiber.

Bottom-up

Der Test beginnt mit den elementaren Komponenten des Systems, die keine weiteren Komponenten aufrufen (außer Funktionen vom Betriebssystem). Größere Teilsysteme werden sukzessive aus getesteten Komponenten zusammengesetzt, mit anschließendem Test dieser Integration. Auf Platzhalter kann zwar komplett verzichtet werden, das bedeutet aber gleichzeitig, dass man hier in der Regel mit vielen Testtreibern arbeiten muss.

Ad-hoc

Die Komponenten werden in der (zufälligen) Reihenfolge ihrer Fertigstellung integriert.

Backbone

Es wird ein Programmskelett oder „Backbone“ erstellt (das kann zum Beispiel ein Durchstich oder der "kritische Pfad" eines Prozesses sein), in das schrittweise die zu integrierenden Komponenten eingehängt werden.

Big Bang

Es wird gewartet, bis alle Softwarekomponenten entwickelt sind. Dann wird alles auf einmal zusammengeworfen und getestet.

Diese Strategie ist besser zu vermeiden. Alle Fehlerwirkungen treten geballt auf, es wird schwierig bzw. unmöglich sein, das System überhaupt zum Laufen zu bringen. Die Lokalisierung und Behebung von Fehlerzuständen gestalten sich ebenfalls schwierig und zeitraubend.

Der Auswahl einer Teststrategie findet anhand verfügbarer Ressourcen und Zeitfenster statt.

Top-down- und Bottom-Up-Strategien in Reinform setzen eine vollständig baumartige Architektur voraus. Je netzartiger die Architektur ist, umso stärker muss von diesen Basisstrategien abgewichen werden. Hinzu kommt, dass auch in Projekten nach V-Modell selten vorkommt, dass alle Komponente „fertig implementiert und Unit-getestet vorliegen“. Auch hier wird in der Praxis mit der Integration begonnen, obwohl einzelne Komponente noch in der Implementierungsphase stecken. Dies führt dann zwangsläufig zu einer Ad-hoc-Integrationsstrategie.

Über Vorteile und Nachteile von Integrationsteststrategien lesen Sie die Quelle [2].

Randbedingungen für die Integration

Welche Strategie optimal ist, hängt von Randbedingungen ab, die in jedem Projekt analysiert werden müssen:

  • Die Systemarchitektur bestimmt, aus welchen und wie vielen Komponenten das Gesamtsystem besteht und wann diese voreinander abhängen.

  • Der Projektplan legt fest, zu welchem Zeitpunkt im Projekt einzelne Systemteile entwickelt werden und wann diese integrations- und testbereit sein sollen.

  • Das Testkonzept legt fest, welche Systemaspekte wie intensiv getestet werden müssen und auf welcher Teststufe das jeweils geschehen soll.

Continuous Integration

Im agilen Projektvorgehen und damit auch in Scrum entstehen kontinuierlich geänderte oder neue Codebausteine. Während des Sprints werden alle Änderungen aller Programmierer in die Testumgebung überspielt und die Integrationstests durchgeführt.

In der Praxis entsteht häufig ein phasenorientiertes, wasserfallartiges Vorgehen innerhalb der Sprints.

  • Feedback von Integrationstest zurück an den Programmierer wird unnötig verzögert. Im ungünstigsten Fall erhält ein Programmierer, der am ersten Tag des Sprints einen Codebaustein ändert, erst am letzten Tag des Sprints das Integrationstestergebnis zurück.

  • Da die Integrationstests Fehler aufdecken können und auch aufdecken werden, muss Zeit für Fehlerkorrekturen eingeplant werden. Der Sprint wird dadurch zwangsweise serialisiert, in die Phasen Codierung, Unit Test, Integration/Integrationstest und Fehlerkorrektur.

Um Verzögerungen zu vermeiden, benötigt das Team eine gute Integrationsstrategie: "Continuous Integration".

Continuous Integration ist die konsequente Weiterentwicklung inkrementeller Integrationsstrategien. Dabei kommen agile Testmethoden ins Spiel, da der Test im laufenden Sprint stattfinden muss [vgl. Kortendick/Mester "Hermeneutische und situative Wissensvermittlung in der agilen Softwareentwicklung", 2024]. Inkrementelle Integration bedeutet, dass jeder Codebaustein nach seiner Fertigstellung in die Integrationsumgebung überspielt und dort integriert wird. Neue Bausteine werden also nicht mit anderen, ebenfalls neuen noch nicht integrierten Bausteinen zusammengeworfen, sondern jeder geänderte oder neue Baustein wird einzeln gegen einen bereits integrierten Versionsstand (Build) in der zentralen Integrationsumgebung integriert.

ALT MISSING
Abb. 2: Continuous Integration und Continuous Delivery

Reifegradbestimmung & Entscheidungshilfen

Bestimmung des Reifegrades und Entscheidungshilfen sind unter folgenden Seiten zu finden:

Quellen