TestmanagementChanging the world one bug after amother…
Der Integrationstest hat das Ziel, Fehlerzustände in den Schnittstellen und im Zusammenwirken mit den integrierten Komponenten aufzudecken.
Zu den typischen Integrationsfehlern zählen: Schnittstellenfehler, Timingfehler, Kapazitätsfehler, Performanzfehler und Übertragungsfehler.
Die Gefahr von Integrationsfehlern ist in agilen Projekten besonders hoch. Deshalb müssen auch die Testfälle des Komponententests wiederholt werden für die Komponenten mit betreffenden Codeänderungen.
Die Gefahr von Integrationsfehlern ist in agilen Projekten besonders hoch. Deshalb müssen auch die Testfälle des Komponententests wiederholt werden für die Komponenten mit betreffenden Codeänderungen.
Die benötigten Integrationstestfälle sind systematisch herzuleiten, z.B. durch die Analyse der Wechselwirkungen, Durchführung der Äquivalenzklassenanalyse (inkl. Grenzwertanalyse) und die Ermittlung des Testfallinputs.
Abhängigkeiten zwischen den Komponenten liegen oftmals nicht explizit, sondern implizit vor. Letztere werden häufig leicht übersehen.
Wie viele Testfälle zu erstellen sind, hängt stark von der Architektur des zu testenden Systems ab. Durch eine Optimierung der Systemarchitektur lässt sich der Integrationstestaufwand senken: Klare Abgrenzung der Teilsysteme und Reduktion auf nur wenige Wechselwirkungen zwischen den Schnittstellen.
Abhängigkeiten zwischen den Komponenten liegen oftmals nicht explizit, sondern implizit vor. Letztere werden häufig leicht übersehen.
Wie viele Testfälle zu erstellen sind, hängt stark von der Architektur des zu testenden Systems ab. Durch eine Optimierung der Systemarchitektur lässt sich der Integrationstestaufwand senken: Klare Abgrenzung der Teilsysteme und Reduktion auf nur wenige Wechselwirkungen zwischen den Schnittstellen.
Im Integrationstest spricht man von Integrationsstufen. Auf
Top-down-Integration
Es werden alle Komponenten getestet, die andere Komponenten aufrufen aber selbst nicht durch Komponenten ausgerufen werden. Es wird eine vollständige Baumstruktur vorausgesetzt.
Bottom-up-Integration
Alle Funktionen und Komponenten stehen noch nicht zur Verfügung. Übergeordnete Komponenten und Aufrufe werden simuliert.
Ad-hoc-Integration
Hier werden die Komponenten in der Reihenfolge ihrer Fertigstellung getestet.
Zu der nicht iterativen Integrationsteststrategie zählt:
Big-Bang-Integration
Hier werden alle Teilsysteme am Ende eines Projektes getestet. Diese Methode beinhaltet das größte Risiko.
- der niedrigsten Stufe werden Klassen integriert,
- in der darauffolgenden Stufe werden Klassen zu Packages integriert (horizontal und vertikal).
- Die letzte Stufe ist die Systemintegration. Die Tests werden meist in der nächsten Stufe im Systemtest durchgeführt.
Top-down-Integration
Es werden alle Komponenten getestet, die andere Komponenten aufrufen aber selbst nicht durch Komponenten ausgerufen werden. Es wird eine vollständige Baumstruktur vorausgesetzt.
Bottom-up-Integration
Alle Funktionen und Komponenten stehen noch nicht zur Verfügung. Übergeordnete Komponenten und Aufrufe werden simuliert.
Ad-hoc-Integration
Hier werden die Komponenten in der Reihenfolge ihrer Fertigstellung getestet.
Zu der nicht iterativen Integrationsteststrategie zählt:
Big-Bang-Integration
Hier werden alle Teilsysteme am Ende eines Projektes getestet. Diese Methode beinhaltet das größte Risiko.
Von großem Vorteil haben sich Continousintegration-Systeme (CI) erwiesen. Jede Komponente wird nach ihrer Implementierung gegen einen bereits vorhandenen Build in einer zentralen Umgebung integriert. Meist werden die Überprüfungen nachts im Rahmen des Nightly Build automatisch ausgeführt. Ein Dashboard zeigt die Ergebnisse an.
An optimal Integration Strategy is very important to the timely workflow and cost effectiveness.
The avoidance of integration mistakes and the use of Continous-Integration are secured through the Test Manager.
The avoidance of integration mistakes and the use of Continous-Integration are secured through the Test Manager.
U
© 2018 Holger Mayer Consulting HMC2