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.