Was ist der Integrationstest?
Das ISTQB definiert den Integrationstest als “eine Teststufe mit dem Schwerpunkt auf dem Zusammenwirken zwischen Komponenten oder Systemen” und unterscheidet dabei zwischen dem Komponenten-Integrationstest und dem System-Integrationstest. In der Praxis ist der Begriff noch weiter gefasst: Integriert werden Module und Klassen ebenso wie Services, Schichten, Subsysteme oder ganze Systeme unterschiedlicher Hersteller.
Schnittstellen sind in verteilten und serviceorientierten Systemen die häufigste Quelle von Defekten. Komponenten, die isoliert einwandfrei funktionieren, versagen genau an ihren Grenzen, weil dort Annahmen aufeinandertreffen, die nie gemeinsam geprüft wurden. Der Integrationstest macht diese Schwachstellen sichtbar, bevor sie sich auf Systemebene zu schwer lokalisierbaren Fehlern auswachsen.
Einordnung in die Teststufen
In der klassischen Teststufenstruktur steht der Integrationstest zwischen dem Komponenten- und dem Systemtest. Er setzt voraus, dass mindestens zwei Teile des Systems existieren und sich verbinden lassen, und er schließt genau dort an, wo der Komponententest endet: Nicht mehr die einzelne Einheit steht im Fokus, sondern ihre Wechselwirkung mit den anderen Teilen.
Diese Abgrenzung ist in der Praxis nicht immer trennscharf, weshalb die Unterscheidung zwischen zwei Varianten hilft. Der Komponenten-Integrationstest prüft das Zusammenspiel von Modulen, Klassen oder Schichten innerhalb desselben Systems. Der System-Integrationstest prüft die Zusammenarbeit mehrerer eigenständiger Systeme über Schnittstellen und Datenaustausch. Beide unterscheiden sich erheblich in Testumgebung, Testdaten und Verantwortlichkeiten. Wer diese Unterschiede ignoriert, produziert Reibung im Projekt.
Ziele und Qualitätsmerkmale
Ziel des Integrationstests ist es, das korrekte Zusammenspiel der Teile über Schnittstellen und Workflows nachzuweisen. Die Kernfragen sind einfach zu stellen und oft schwer zu beantworten: Sind die ausgetauschten Daten korrekt? Stimmen ihre Strukturen? Werden Fehler korrekt behandelt und weitergegeben?
Zum Integrationstest gehören auch die nicht-funktionalen Aspekte. Wie schnell läuft der Datenaustausch, wie viel Last verträgt die Kopplung, wie robust bleibt die Verbindung bei Kommunikationsfehlern oder Timeouts? Diese Fragen werden auf der Integrationsebene häufig ausgelassen. Später tauchen sie als schwer diagnostizierbare Probleme auf Systemebene wieder auf, und dann muss ihre Ursache mühsam zurückverfolgt werden.
Integrationsstrategien
Die Wahl der Integrationsstrategie entscheidet unmittelbar darüber, wie schnell Fehler gefunden werden und wie aufwändig ihre Lokalisation wird.
Der Big-Bang-Ansatz integriert alle Komponenten gleichzeitig und prüft anschließend das Gesamtgefüge. Er ist einfach zu planen, aber schwer zu debuggen: Schlägt ein Test fehl, lässt sich die Ursache im komplett verschalteten System nur mühsam eingrenzen.
Inkrementelle Strategien sind ihm daher in aller Regel vorzuziehen. Beim Top-Down-Ansatz beginnt die Integration bei der obersten Schicht und arbeitet sich nach unten vor; noch fehlende Unterkomponenten werden durch Stubs ersetzt. Beim Bottom-Up-Ansatz startet man bei den niedrigsten Komponenten und baut nach oben auf; fehlende aufrufende Komponenten simulieren Treiber. Beide Varianten erleichtern die Fehlerlokalisation erheblich, denn die Ursache eines neuen Fehlers ist immer zuerst in der zuletzt integrierten Komponente zu suchen.
Gerade in modernen Microservice-Architekturen ist eine klare Integrationsstrategie oft unverzichtbar. Die Dienste kommunizieren über Netzwerkgrenzen hinweg, und schon der Ausfall oder die Verzögerung eines einzelnen Dienstes kann das Verhalten des Gesamtsystems verändern.
Testbasis
Als Testbasis für den Integrationstest dienen alle Informationen, die das Zusammenspiel der Einzelteile beschreiben: Schnittstellenspezifikationen, Sequenzdiagramme, Anwendungsfälle und API-Dokumentationen, ergänzt um die relevanten Architekturentwürfe und Entwurfsmuster.
Auch die nicht-funktionalen Anforderungen an die Schnittstellen gehören zur Testbasis. Reaktionszeiten, Durchsatz und Fehlertoleranz bei Verbindungsabbrüchen müssen explizit spezifiziert und ebenso explizit getestet werden. Offene oder vage Schnittstellenspezifikationen sind hier ein häufiger Risikofaktor: Auf ihrer Grundlage werden Fehler unbemerkt von Komponente zu Komponente weitergereicht, und die spätere Fehlersuche fällt entsprechend aufwändig aus.
Testfallableitung
Für die Testfallerstellung eignen sich die bewährten strukturierten Entwurfsverfahren: Äquivalenzklassenbildung und Grenzwertanalyse auf Basis der Schnittstellenspezifikationen, Entscheidungstabellen für komplexe Kombinationen von Aufrufparametern, der zustandsbasierte Test für zustandsbehaftete Protokolle und Sessions.
Besondere Aufmerksamkeit verdienen die Negativtests: Testfälle mit ungültigen Datenformaten, fehlenden Pflichtfeldern, falsch codierten Zeichensätzen, leeren Antworten oder Verbindungsfehlern. Genau diese Fälle bringen Schnittstellen und Workflows regelmäßig zu Fall. Ein robustes Fehlerhandling an den Grenzen entsteht nicht von selbst, es muss explizit getestet werden.
Bei der Testfallerstellung werden zwangsläufig Lücken in der Schnittstellenspezifikation sichtbar. Diese gehören zeitnah mit Architekten, Entwicklern oder den fachlichen Bereichen geklärt, bevor auf Basis falscher Annahmen Tests entstehen, die anschließend das Falsche prüfen.
Test-Doubles
Bei inkrementellen Integrationsstrategien sind noch nicht alle Komponenten verfügbar, und genau diese Lücken füllen Test-Doubles. Stubs simulieren aufgerufene Komponenten mit definierten Antworten und erlauben so das Testen von der Aufruferseite, ohne dass die echte Komponente schon existiert. Treiber simulieren umgekehrt die aufrufenden Komponenten und stoßen den zu testenden Ablauf an. Mocks gehen einen Schritt weiter: Sie prüfen zusätzlich, ob die Interaktionen korrekt stattgefunden haben, ob also die richtige Methode mit den richtigen Parametern aufgerufen wurde.
Test-Doubles ermöglichen unabhängiges Testen, ohne auf die vollständige Entwicklung aller Beteiligten warten zu müssen. Sie wollen allerdings gepflegt werden. Ein Stub, dessen Verhalten von der echten Komponente abweicht, verfälscht die Testergebnisse und wiegt das Team in falscher Sicherheit. Contract Testing ist eine Methode, die genau das verhindern soll.
Testumgebung
Die Testumgebung für Integrationstests ist aufwändiger aufzubauen als für Komponententests. Für Komponenten-Integrationstests reicht oft noch die Entwicklungsumgebung. Für System-Integrationstests wird dagegen eine dedizierte Testumgebung notwendig, die alle beteiligten Systeme umfasst.
Ein wichtiger Aspekt dabei ist das Monitoring. Wer die Kommunikation zwischen den Teilen analysieren will, braucht Werkzeuge, die den Datenfluss sichtbar machen: Logging, verteiltes Tracing, API-Monitoring. Zu beachten ist allerdings, dass Monitoring-Werkzeuge selbst die Laufzeit beeinflussen können. Bei Performanzmessungen an Schnittstellen wird das relevant.
Testdaten
Das Testdatenmanagement orientiert sich an der jeweiligen Integrationsebene. Für Komponenten-Integrationstests lassen sich die Testdaten ähnlich wie bei Unit-Tests lokal definieren. Für System-Integrationstests gelten dieselben Anforderungen wie für den Systemtest: realistische, vollständige Datenkonstellationen, die den tatsächlichen Datenaustausch zwischen den Systemen abbilden.
Entscheidend ist, dass die Testdaten die Schnittstellen in allen Varianten abdecken: gültige Daten, ungültige Daten, Grenzwerte, Sonderfälle. Und sie müssen gezielt jene Daten enthalten, die Fehler provozieren. Nur so lässt sich die Fehlerbehandlung überhaupt auf die Probe stellen.
API-Testing als Kernwerkzeug
REST- und GraphQL-APIs sind heute die verbreitetste Form von Schnittstellen, und Werkzeuge wie Postman, REST-assured oder Karate ermöglichen automatisierte Tests direkt auf dieser Ebene. Sie prüfen Datenformate, HTTP-Statuscodes, Fehlerverhalten und Antwortzeiten unmittelbar an der Schnittstelle, ohne den Umweg über eine Benutzeroberfläche.
API-Tests sind wartungsärmer als GUI-Tests, liefern schnelle Rückmeldung und lassen sich sauber in CI/CD-Pipelines integrieren. Für serviceorientierte und Microservice-Architekturen sind sie deshalb der primäre Ansatz für den Integrationstest.
Das Contract Testing erweitert diesen Ansatz um einen entscheidenden Gedanken. Werkzeuge wie Pact definieren Verträge zwischen dem Consumer und dem Provider einer Schnittstelle, und diese Verträge lassen sich unabhängig von der Gegenseite prüfen, ohne dass beide Systeme ständig echt integriert vorliegen müssen. Das ist besonders wertvoll, wenn mehrere Teams unabhängig voneinander entwickeln und trotzdem sicherstellen müssen, dass ihre Schnittstellen kompatibel bleiben.
Testautomatisierung im Integrationstest
Bei entwicklungsnahen Integrationstests ist die Automatisierung ein Selbstläufer. Für Komponenten-Integrationstests steht eine Fülle an Frameworks bereit, die sich direkt in den Build-Prozess integrieren lassen, von JUnit über TestNG und pytest bis Jest. Die Tests laufen bei jedem Commit und geben sofortige Rückmeldung.
Aufwändiger wird es auf den höheren Integrationsebenen. Sollen zwei eigenständige Systeme automatisiert zusammen getestet werden und unterscheiden sie sich technologisch, steigt der Implementierungsaufwand erheblich. Hier lohnt eine klare Priorisierung: Welche Schnittstellen sind kritisch, welche Fehlerklassen haben die größten Auswirkungen? Genau diese sind die ersten Kandidaten für die Automatisierung.
Integrationstest in agilen Projekten
Integrationstests sind in agilen Projekten besonders wichtig und werden trotzdem oft vernachlässigt. Die Testpyramide weist ihnen einen eigenen Bereich zu, zwischen den Unit-Tests an der Basis und den System- oder UI-Tests an der Spitze. Schnelle, stabile Integrationstests auf API-Ebene sind der effektivste Weg, um Robustheit im Kleinen wie im Großen sicherzustellen.
In den Microservice-Architekturen, die in agilen Teams häufig entstehen, stellt sich die Frage nach dem Integrationstest besonders dringend. Weil die Dienste über Netzwerkgrenzen kommunizieren, kann jede Änderung an einem Dienst Abhängigkeiten in anderen Diensten brechen. Automatisierte Integrations- und Contract-Tests sind hier neben dem Deployment-Prozess selbst die wichtigste Sicherheitslinie.
Typische Fehlerklassen und Risiken
Bestimmte Defekte werden typischerweise erst im Integrationstest sichtbar:
- Falsche oder inkompatible Datenformate an Schnittstellen, etwa unterschiedliche Datumsformate, fehlende Pflichtfelder oder falsche Zeichenkodierung.
- Fehlende oder fehlerhafte Fehlerbehandlung bei Kommunikationsfehlern, Timeouts oder unerwarteten HTTP-Statuscodes.
- Race Conditions bei asynchroner Kommunikation, die nur unter Last oder bei bestimmten Timings auftreten.
- Datenkonsistenzprobleme zwischen Subsystemen nach Teilausfällen oder fehlgeschlagenen Transaktionen.
- Sicherheitslücken an Schnittstellen, etwa fehlende Authentifizierung, fehlende Autorisierungsprüfungen oder die unverschlüsselte Übertragung sensitiver Daten.
Das größte Risiko ist allerdings ein organisatorisches: dass es gar keine Integrationstests gibt. In vielen Projekten existieren Unit- und Systemtests, während die Integrationsebene schlicht fehlt. Und wo Integration doch getestet wird, ist häufig unklar, wer die Verantwortung trägt: dieses System, jenes System oder das Team, das die Schnittstelle definiert hat. Ohne klare Ownership passiert erfahrungsgemäß genau eins: nichts.
Grenzen des Ansatzes
Integrationstests prüfen, ob die Teile korrekt zusammenspielen. Die fachliche Korrektheit des Gesamtsystems gegen die Anforderungen weisen sie nicht nach, das ist Aufgabe des Systemtests. Ebenso wenig ersetzen sie die soliden Komponententests unter sich oder den Systemtest über sich. Sie ergänzen beide, ohne eines von beiden überflüssig zu machen.
In hochverteilten Systemen mit vielen asynchronen Kommunikationswegen stoßen die klassischen Integrationstests zudem an ihre Grenzen. Hier ergänzt das Chaos Engineering, also das gezielte Einschleusen von Fehlern in laufende Systeme, den klassischen Ansatz um eine Perspektive, die sich vorab kaum vollständig durchspezifizieren lässt.
Aus der Praxis
Integrationstests werden in der Praxis häufig zu lange aufgeschoben oder ganz weggelassen. Die Ursache ist meist eine Mischung aus unklaren Verantwortlichkeiten und dem spürbaren Aufwand für die Testumgebung. Tritt dann ein Problem an einer Schnittstelle auf, beginnt eine aufwändige Fehlersuche über System- und Teamgrenzen hinweg. Am Ende wird sie deutlich teurer als der Integrationstest, den man sich vorher gespart hat.