Integrationstest

Der Integrationstest wird in zwei unterschiedliche Strategien unterschieden: Die testzielorientierte Strategie benötigt nur die zum Testen notwendigen System-Komponenten. Dort werden die Testfälle entsprechend definierter Testziele erstellt und ausgeführt. Die vorgehensorientierte Strategie ist abhängig von der Integrationsreihenfolge aus der Systemarchitektur.^[1]

Eine weitere Unterscheidung ist die Art, wie die Komponenten integriert werden: Die inkrementelle Integration fügt die Module schrittweise zusammen. Hierzu müssen fehlende Module simuliert werden. Die nicht-inkrementelle Integration fügt alle Komponenten gleichzeitig zusammen und integriert sie in das [zu testende] System. Dazu müssen alle Module bereits vor dem Integrationstest vorhanden sein.^[1] Diese Variante hat sich in der Praxis als nicht tauglich erwiesen.^[2]

Zusammengefasst stellt der Integrationstest sicher, dass die unterschiedlichen Module, welche zusammen arrangiert wurden, auch wie ein funktionsfähiges System agieren.^[3] Er untersucht also die Kooperation von selbstständigen Programmbestandteilen.^[4]

Für jede Abhängigkeit zwischen zwei Komponenten eines Systems wird ein Testszenario definiert, welches in der Lage ist nachzuweisen, dass nach der Zusammenführung sowohl beide Komponenten für sich wie auch der Datenaustausch über die gemeinsame(n) Schnittstelle(n) spezifikationsgemäß funktionieren. Als Methoden werden sowohl Funktionstests als auch Schnittstellentests angewendet. Da die Funktionstests meistens im Rahmen der Komponententests bereits durchgeführt wurden, dienen sie an dieser Stelle dazu festzustellen, ob die richtige Komponente verwendet wird. Die Schnittstellentests dienen zur Überprüfung der Daten, die zwischen den Komponenten ausgetauscht werden.

Der Umfang von Integrationstests ist nicht auf ein Gesamtsystem festgelegt. Da der zeitliche Aufwand für Integrationstests mit wachsender Komponentenanzahl überproportional ansteigt, ist es üblich, Integrationstests für einzelne, abgegrenzte Subsysteme durchzuführen und diese dann im weiteren Verlauf als eine Komponente zu betrachten (Bottom-Up-Methode). Bei dieser Methode enden die Integrationstests erst mit den erfolgreichen Testläufen in einer mit dem späteren Produktivsystem identischen Testumgebung.

In kleineren Softwareprojekten finden Integrationstests häufig während der Programmierung durch den oder die Programmierer statt. Unmittelbar im Anschluss an die Programmierung eines Moduls wird das Modul selbst und das Zusammenspiel mit dem bisher erstellten Programmcode getestet. Bei großen, umfangreichen Software-Entwicklungen, die meist im Rahmen eines Projekts durchgeführt werden, erhöht sich der Aufwand für Tests generell so stark, dass diese zur Steigerung der Effizienz automatisiert durchgeführt werden.

• Outside-In-Integrationstest

• Ian Sommerville: Software Engineering. 6. Auflage. Addison-Wesley, 2001, ISBN 3-8273-7001-9. 
• IEEE: IEEE Standard Glossary of Software Engineering Terminology; IEEE, 1991, ISBN 1-55937-067-X
• British Computer Society: Glossary of terms used in software testing, Version 6.3; http://www.testingstandards.co.uk/bs_7925-1_online.htm
• Article Managing Your Way through the Integration and Test Black Hole from Methods & Tools
• Mario Winter, Mohsen Ekssir-Monfared, Harry Sneed, Richard Seidl, Lars Borner: Der Integrationstest – Von Entwurf und Architektur zur Komponenten- und Systemintegration. 1. Auflage. Carl Hanser Verlag, 2012, ISBN 978-3-446-42564-4. 

1. ↑ ^{a b} Dirk Zander, Toolgestützte Verifikation verteilter technischer Steuerungssysteme auf der Basis von Aktivitätsdiagrammen, Ruhr-Universität Bochum; Dissertation, Bochum 2009 S. 72–74
2. ↑ Peter Liggesmeyer; Software-Qualität Testen, Analysieren & Verifizieren von Software; Spektrum akademischer Verlag, Heidelberg 2009; 2. Auflage; S. 370/371
3. ↑ Dirk. W. Hoffmann; Software Qualität; ISBN 978-3-642-35699-5; Springer Vieweg; 2. Auflage; 2013; S. 163–166
4. ↑ ^{a b} qz-online.de [1]