Fünf Testdimensionen helfen, Integrationstests zu ordnen und Lücken zu erkennen: Testziele, Testobjekte, Testebene, Testbasis und typische Fehler. Wer die eigenen Tests entlang dieser Dimensionen einordnet, sieht, wo die Integration schon gut abgesichert ist. Und er sieht, wo Fehler bisher unentdeckt bleiben können.
Der Duden definiert Integration als “(Wieder)herstellung einer Einheit (aus Differenziertem); Vervollständigung”. In der Softwareentwicklung könnten die Ausprägungen kaum unterschiedlicher sein: horizontal, vertikal, Microservices, APIs, lose gekoppelt, Schichten, Silos, eng verzahnt, als Integrationsplattform oder dateibasiert, Kapselung usw. Entsprechend viele Ziele hat ihre Integration. Dazu kommen integrationsspezifische Aspekte wie die Integrationsstrategie samt Anforderungen an die Testumgebung. Um hier den Überblick zu behalten, braucht es Struktur.
Dimension: Testziele
Ein typisches Testziel des Integrationstests ist der Nachweis, dass die zu integrierenden Objekte korrekt miteinander kommunizieren. Dabei geht es, wie so oft, vor allem darum, das Risiko unentdeckter Fehler zu senken und Fehlerwirkungen früh zu finden.
Meist stehen die funktionalen Aspekte im Vordergrund. Aber auch nicht-funktionale Aspekte zählen: Zuverlässigkeit, Gebrauchstauglichkeit, Informationssicherheit (Security), Kompatibilität, Übertragbarkeit, Änderbarkeit, Performanz/Effizienz (siehe ISO 25010). Je nach Branche, Anwendungszweck und Kundenwünschen rücken sie stärker in den Fokus. Dann sollten sie auch entsprechend berücksichtigt werden.
Dimension: Testobjekte
Das Testobjekt bestimmt, wie die Tests und die Testumgebung aussehen: Schnittstellen, Services, APIs, Datenbanken, Subsysteme, aber auch Infrastruktur und Hardware.
Die einzelnen Integrationsobjekte sollten schon vorher als Produkt oder Teilsystem getestet sein, unabhängig von der Kommunikation an den Schnittstellen. Sonst lässt sich im Fehlerfall nicht feststellen, ob ein Problem von der Schnittstelle herrührt oder von einem Fehler im Baustein selbst. Das spart viel Zeit bei der Fehlersuche.
Dimension: Testebene
Je nach Testobjekt spielt der Integrationstest auf einer anderen Ebene, auf einem anderen Abstraktionsniveau:
- Units: Hier gibt es meist eine gute Test-Unterstützung durch die Entwicklungsumgebung bzw. durch das Framework.
- Systemkomponenten: Eingebundene Bibliotheken oder Datenbanken unterstützen den Test.
- Systeme: Selbst wenn Schnittstellen von Softwaresystemen gut dokumentiert sind, ist die Integration komplex und fehleranfällig.
- Integration von Software und Hardware: Hier liegt für Tests eine besondere Herausforderung darin, auch nicht-funktionale Aspekte zu berücksichtigen.
- Integration von Software und Daten: Beide beschreiben Informationen, die zusammenpassen müssen. Meist beschreibt die Software einen generischen Teil und die Daten den projektspezifischen Teil. Hier ist der Spagat zwischen allgemeingültiger und projektspezifischer Prüfung wichtig.
Auch ebenenübergreifend kann es komplex werden. Manchmal findet die Integration auf der Systemebene statt (oftmals Black Box), zielt aber auf Eigenschaften, die nur bei einer White-Box-Betrachtung erkennbar sind. Dieser Spagat ist für viele Entwicklungsteams eine besondere Herausforderung.
In jedem Fall müssen bei der Integration verschiedene Teams von verschiedenen Ebenen zusammenspielen, jedes mit seinem eigenen Blickwinkel. Nur so gelingt die Integration effizient.
Dimension: Testbasis
Als Testbasis können zum Beispiel dienen: Schnittstellenspezifikationen, Definitionen von Kommunikationsprotokollen, Sequenzdiagramme, Modelle wie Zustandsdiagramme, Architekturbeschreibungen, Software- und Systementwürfe, Workflows, Anwendungsfälle oder Beschreibungen von Datenstrukturen.
Generell gilt: Je höher der Grad der Formalisierung, desto eher kann man sich auf die Ergebnisse verlassen. Sind die Schnittstellenspezifikationen der kommunizierenden Produkte nachweislich konsistent zueinander, ist bereits viel gewonnen.
Dimension: Typische Fehler
Mit Integrationstests lassen sich viele Arten von Fehlern entdecken. Typisch sind falsche Datenstrukturen, fehlerhafte Schnittstellen, falsche Annahmen zu den übergebenen Daten und fehlende Daten. Dazu kommen Probleme bei der Performanz oder der Sicherheit (Verschlüsselung).
Was die Kombination der Testdimensionen bedeutet
Diese Dimensionen lassen sich in fast beliebiger Kombination betrachten. Damit spannen sie ein großes Feld an möglichen Integrationstests auf. Komponenten- oder Systemtests sind eher homogen. Integrationstests dagegen unterscheiden sich stark in Umsetzung, Technologie und Methodik. Viele Tests, insbesondere nicht-funktionale, sind nur automatisiert sinnvoll testbar. Auch die schiere Zahl an Kombinationen spricht dafür, die Effizienz über Testautomatisierung zu steigern.
Die Testautomatisierung aufzubauen, ist allerdings selbst eine große Herausforderung. Oft braucht es Anpassungen an den Frameworks oder eigene Testwerkzeuge. Diesen Aufwand sollte man nicht unterschätzen.
Klein anfangen: das eigene Testfeld aufspannen
Niemand muss alle Kombinationen auf einmal abdecken. Für den Anfang reicht ein Feld aus den wichtigsten Dimensionen, etwa Testebene und typische Fehler. Darin lässt sich eintragen, welche Integrationstests es schon gibt. Die leeren Felder zeigen, wo Fehler wie falsche Datenstrukturen oder fehlende Daten heute noch durchrutschen können. Dort setzt die nächste Verbesserung an.
Häufig gestellte Fragen
Welches Ziel verfolgt ein Integrationstest?
Ein Integrationstest weist nach, dass die zu integrierenden Objekte korrekt miteinander kommunizieren. Dahinter stehen zwei Absichten: das Risiko unentdeckter Fehler zu minimieren und Fehlerwirkungen früh zu finden. Meist stehen funktionale Aspekte im Vordergrund, doch je nach Branche, Anwendungszweck und Kundenwünschen rücken nicht-funktionale Eigenschaften stärker in den Fokus und sollten dann bewusst berücksichtigt werden.
Welche nicht-funktionalen Eigenschaften sollte man bei der Integration prüfen?
Zuverlässigkeit, Gebrauchstauglichkeit, Informationssicherheit, Kompatibilität, Übertragbarkeit, Änderbarkeit und Performanz beziehungsweise Effizienz. Als Bezugsrahmen nannte der Artikel 2019 die ISO 25010. Wie stark diese Merkmale gewichtet werden, hängt von Branche, Anwendungszweck und Kundenwünschen ab. Typische Fehlerbilder aus diesem Bereich sind Performanzprobleme und Schwächen bei der Verschlüsselung.
Warum sollten die einzelnen Bausteine vor dem Integrationstest bereits getestet sein?
Weil sich sonst im Fehlerfall nicht mehr feststellen lässt, ob ein Problem von der Kommunikation an der Schnittstelle herrührt oder von einem schnittstellenirrelevanten Fehler im Baustein selbst. Sind die Integrationsobjekte vorher als Produkt oder Teilsystem geprüft, spart das später viel Zeit bei der Fehlersuche. Diese Vorbedingung entscheidet wesentlich über den Erfolg der Integrationstests.
Wie unterscheiden sich Integrationstests auf Unit-Ebene von der Integration ganzer Systeme?
Auf Unit-Ebene gibt es meist gute Unterstützung durch Entwicklungsumgebung oder Framework, bei Systemkomponenten helfen eingebundene Bibliotheken und Datenbanken. Bei der Integration ganzer Softwaresysteme bleibt die Aufgabe komplex und fehleranfällig, selbst wenn die Schnittstellen gut dokumentiert sind. Besonders anspruchsvoll wird es bei der Integration von Software mit Hardware oder mit Daten.
Welche Grundlagen dienen als Testbasis für Integrationstests?
Schnittstellenspezifikationen, Definitionen von Kommunikationsprotokollen, Sequenz- und Zustandsdiagramme, Architekturbeschreibungen, Software- und Systementwürfe, Workflows, Anwendungsfälle sowie Beschreibungen von Datenstrukturen. Je höher der Grad der Formalisierung, desto eher lässt sich den Testergebnissen vertrauen. Schon die Sicherheit, dass die Schnittstellenspezifikationen der kommunizierenden Produkte konsistent zueinander sind, bringt einen großen Gewinn.
Welche Fehler findet man typischerweise erst beim Integrationstest?
Falsche Datenstrukturen, fehlerhafte Schnittstellen, falsche Annahmen über die übergebenen Daten und fehlende Daten. Dazu kommen Probleme bei der Performanz und bei der Sicherheit, etwa in der Verschlüsselung. Diese Fehlerarten entstehen aus dem Zusammenspiel und bleiben deshalb bei der isolierten Prüfung einzelner Objekte häufig unentdeckt.
Lassen sich Integrationstests ohne Testautomatisierung sinnvoll durchführen?
Nur eingeschränkt. Viele Tests, insbesondere die nicht-funktionalen, sind ausschließlich automatisiert sinnvoll testbar, und die große Zahl möglicher Kombinationen aus Testziel, Testobjekt und Ebene macht Effizienzsteigerung durch Automatisierung nötig. Der Aufbau der Automatisierung selbst ist allerdings aufwendig: Oft sind Anpassungen an Frameworks oder eigene Testwerkzeuge erforderlich.
