Der Integrationstest bezeichnet in der Softwareentwicklung eine aufeinander abgestimmte Reihe von Einzeltests, die dazu dienen, die Kernfunktionalitäten verschiedener voneinander abhängigen Komponenten (Subsysteme) eines komplexen Systems im Zusammenspiel miteinander zu testen.
Unter Integrität wird ein Zustand verstanden, der unbefugte und unzulässige Veränderungen von Informationen und an IT-Systemen oder IT-Komponenten ausschließt.
Der Integrationstest ist Testen mit der Zielverfolgung, die Fehlerzustände in den Schnittstellen und im Zusammenspiel zwischen integrierten Komponenten aufzudecken [= zweite Teststufe des V-Modells nach ISTQB (International Software Testing Qualifications Board)].
Die im gemeinsamen Kontext zu testenden Komponenten sollten jeweils ihren separat durchzuführenden Komponententest erfolgreich bestanden haben und für sich isoliert fehlerfrei funktionsfähig sein.
Wesentliche Testaufgaben |
» Prüfung der integrierten Schnittstellen mit richtigen und falschen Eingabedaten |
» Relevante fachliche Kernfunktionalitäten prüfen |
» Sicherstellen der Voraussetzungen für den Fachbereichstest |
Die Ergebnisse des Integrationstests sind zu dokumentieren.
Einem System Test liegt ein aus mehreren Komponenten zusammengesetztes und vollständiges System zu Grunde. Ziel des System Tests ist es, sicher zu stellen, dass das integrierte System die spezifizierten Anforderungen erfüllt.
Der Systemtest erfolgt in der Regel nach den Integrationstests, mit denen das Zusammenspiel der Komponenten untereinander, verifiziert wurde.
Der Systemtest ist das Testen eines integrierten Systems, um sicherzustellen, dass die spezifizierten Anforderungen erfüllt werden [= dritte Teststufe des V-Modells nach ISTQB (International Software Testing Qualifications Board)].
Beim (technischen) Integrationstest werden die Software-Komponenten in der Testumgebung mit allen beteiligten Subsystemen auf Funktionalität getestet. Ziel dieser Tests ist es, Fehler in Schnittstellen und im Zusammenspiel zwischen zu integrierenden Komponenten zu finden.
Treten Fehler oder Probleme auf, müssen diese analysiert und behoben werden, bevor die folgenden Fachbereichstests starten können. Neben den funktionalen und integrativen Aspekten werden eventuell zeitgleich auch zusätzlich Sondertestarten (z.B. Zeit- und Lastaspekte bei der Anbindung an Fremdsysteme und Datenbank-Systeme) betrachtet.
Für all diese integrativen Aspekte findet der Test in einer Infrastruktur statt, die der Produktionsumgebung maximal ähnlich ist (Kompromisse bezüglich Mengengerüst, Leistung, externe Systeme, etc. sind möglich).
Nur dann kann voraussichtlich das Risiko von Integrationsproblemen in der Fachbereichstestumgebung und der tatsächlichen Produktionsumgebung minimiert werden.
Beim technischen Integrationstest wird die Testumgebung mit der Bottom-Up- Methode aufgebaut. Anschließend kann daraus folgend die Reihenfolge der Test abgeleitet werden. Die Komponenten werden - dem logischen Aufbau entsprechend - stückweise „von unten“ aufgebaut und getestet. In den nächsten Schritten werden die Subsysteme als getestete Komponenten betrachtet und es folgt ein Integrationstest – sofern vorhanden - in der nächst höheren Ebene.
Das Ziel des technischen Integrationstest ist: | |
» | Integration der notwendigen Komponenten und Subsysteme zu einem lauf- und funktionsfähigem Gesamtsystem |
» | Suchen und Finden von Fehlern, die vorher nicht gefunden werden konnten |
» | Überprüfung der funktionalen Korrektheit der Kernprozesse (wesentliche Anforderungen) |
» | Überprüfung von relevanten fachlichen Szenarien (Bedienbarkeit, Zuverlässigkeit) |
» | Übergabe einer funktionsfähigen freigegebenen Software-Version in den Fachbereichstest |
Im Bedarfsfall können alternativ auch Top-Down oder andere Methoden zum Einsatz kommen.
Die Testobjekte für den technischen Integrationstest bilden sich aus den wichtigen Teilkomponenten, die für die Bereitstellung der fachlichen Funktionalität integriert werden sollen.
Die einzelnen Teilkomponenten sollten hierbei als Blackbox behandelt werden, d.h. es werden nur die Aspekte der Interaktion und Integration zwischen diesen betrachtet. Die Korrektheit der genutzten Schnittstellen wird hingegen im Schnittstellentest betrachtet.
Das Risiko kann generell methodisch, aber auch über Erfahrungswerte ermittelt werden. Das Gesamtrisiko setzt sich aus der Risikoklasse (fachlich) und Komplexität (technisch) zusammen.
Die Risikoanalyse identifizierte Risiken nach ihrer Auftrittswahrscheinlichkeit und bewertet deren potenziellen Schadensausmaß.
Neben den Testobjekten aus dem Schnittstellentest sind hier wiederum auch die kritischen Objekte mit ihren Schnittstellen zu berücksichtigen. Es sind die Komplexität (z.B. Anzahl der Beziehungen der Schnittstelle zu anderen Objekten) und die Kritikalität der zu integrierenden Schnittstellen zu bewerten. Es ist empfehlenswert zumindest die Testobjekte aus dem Funktionskettentest mit einer hohen Kritikalität zu berücksichtigen.
Der technische Integrationstest soll den Funktionstest nur vorbereiten und nicht obsolet machen. Deshalb darf die Testmethodik deutlich einfacher ausgelegt werden, muss aber dennoch die Funktionsfähigkeit sicherstellen.
Folgende Testmethoden lassen sich für den Integrationstest sinnvoll verwenden: |
» Ursache-Wirkungs-Analyse |
» Zustandsübergangsanalyse |
» Geschäftsprozesstest |
» Äquivalenzklassenanalyse |
» Grenzwertanalyse |
» Schwachstellenorientiertes Testen |
» Intuitives Testen (aufgrund von Erfahrungen, Error-Guessing) |
Die Testfallermittlung basiert insbesondere auf Designdokumenten wie z.B. DV Konzepte, Kontext-Diagramme sowie Analysen der Kontroll- und Datenflüsse zwischen den Systemen.
Da der technische Integrationstest einen Fachbereichstest ermöglichen soll, sollten die Testobjekte und ihre Testkriterien mit dem Fachbereich abgestimmt und mit Blick auf die Testeingangskriterien des Funktionstests definiert sein.
Es stehen hier also einerseits die integrativen Schnittstellen und deren Subsysteme und andererseits die fachlichen Funktionen im Blickpunkt.
Bei der Testdatendefinition ist nach Möglichkeit auf vorhandene Testdaten aus den IT- oder Fachbereich-Tests zurück zu greifen. Für zusätzliche Tests sind Standardwerte, Grenzwerte und Critical-Dates in der Testmethodik zu berücksichtigen.
Beim Vorgehen ist es in der Regel sinnvoll zuerst logische Testdaten zu definieren, die sich aus den Testfällen ergeben. Diese logischen Testdaten werden dann mit passenden Daten konkretisiert, die im gesamten integrierten System vorhanden und konsistent sein müssen.
Eine Testausführung wird in der Anfangsphase voraussichtlich zuerst manuell stattfinden, es sollte hier aber eine Automatisierung angestrebt werden, welche auch die Bereitstellung von Testdaten umfasst.
Bevor der technische Integrationstest startet, müssen die zu integrierenden Testobjekte erfolgreich den Schnittstellentest durchlaufen haben. Ansonsten gelten die gleichen Kriterien wie für den Schnittstellentest. Entsprechende Testnachweise müssen erstellt und abgelegt werden.
Die exakten Kriterien sind projektspezifisch festzulegen. Hierbei steht die Testfähigkeit für den Fachbereich im Fokus der Betrachtung.
Testende Kriterien für den Integrationstest können sein: |
» Mindestens mehrfaches Testen der integrierten Schnittstellen (Positiv und Negativ) |
» Relevante fachliche Funktionalitäten erfolgreich getestet (nur Kernfunktionen) |
» Alle gefundenen schwerwiegenden und behindernden Fehler sind bereinigt |
Beim Regressionstest sollten bevorzugt jene Anwendungsprozesse getestet werden, die die wichtigsten und kritischsten Verarbeitungen durchführen. Für eine technischen Integrationstest ist es empfehlenswert die Ausführung von Regressionstests soweit wie möglich zu automatisieren.
Die Auswahl der Regressionstests ist von Release zu Release kritisch zu hinterfragen und bei Notwendigkeit anzupassen.