Dabei geht es hauptsächlich um die Integration einzelner Softwaresysteme, die im Stand-alone-Betrieb lebensfähig sind und als einzelne Systeme verkauft und eingesetzt werden können. Im Digitalisierungszeitalter werden die Systeme, die bereits als Stand-alone-Lösungen getestet und eingesetzt worden sind, nach Bedarf, auf unterschiedliche Arten (System-Interaktion, Frontend-, Backend- und Webservice-Integration) [Win12] miteinander integriert, um den Stakeholdern und Endbenutzern neue Services anzubieten. Dabei reicht das Spektrum der Heterogenität der verwendeten Technologien meistens von unterschiedlichen Betriebssystemen, Datenbanken bis hin zu verschiedenen Programmiersprachen und Webbrowsern.
Das V-Modell++
Um den Bedürfnissen der QS für ein Multisystem oder einen Systemverbund besser gerecht zu werden, hat der Autor die ersten Ideen bezüglich des V-Modells++ im Jahre 2012 vorgeschlagen. Dieses Modell versucht als Entwicklungsmodell sowohl die Entwicklung als auch die QS der zu integrierenden Systeme in einem Verbund, vorausschauend und planbar zu gestalten und damit die Komplexität besser beherrschen zu können und die Übersichtlichkeit zu erhöhen.
Wenn das V-Modell ein Modell für die Entwicklung und den Test der Systeme bis zur Freigabe und zum Einsatz ist, ist das V-Modell++ ein Modell, um die bereits freigegebenen Systeme, die im Produktivbetrieb sind, zu integrieren und als einen Verbund in Betrieb zu nehmen. Das V-Modell++ beginnt erst, nachdem das V-Modell bereits erfolgreich umgesetzt worden ist.
Das V-Modell++ erweitert das V-Modell ([Spi05], Seiten 39, 40) um drei weitere Entwicklungsschritte auf dem linken und drei entsprechende Teststufen auf dem rechten Ast des Vs:
- Anforderungsdefinition für Verbund – Multi-Abnahmetest,
- funktionaler Systementwurf für Verbund – Multi-Systemtest,
- technischer Systementwurf – Multi-Integrationstest.
Abbildung 1 zeigt das V-Modell++-Vorgehensmodell. Die drei neuen spezifizierenden Entwicklungsschritte und die drei korrespondierten Teststufen für einen Verbund von mehreren Systemen sind farbig hervorgehoben.
Abb. 1: V-Modell++, das erweiterte V-Modell für Multisysteme
Aus Testsicht verkörpern die hellblauen Bereiche in der Grafik die sogenannte Teststufe Unittest für einen Verbund von integrierten Systemen. Es geht hier ausschließlich um den Test einzelner Applikationen. Der eigentliche Test von integrierten Systemen beginnt erst nach der Freigabe oder nach dem Abnahmetest der einzelnen Systeme.
Die neuen Teststufen und deren Aktivitäten sollen für den Test eines Multisystems nach dem vorgeschlagenen V-Modell++ eingeplant und durchgeführt werden. Dem Heftschwerpunkt entsprechend wird hier nur auf den Multi-Integrationstest näher eingegangen. Tiefere Einblicke in die Entwicklungsschritte sowie die Teststufen Multi-Systemtest und Multi-Abnahmetest sind dem Buch „Der Integrationstest“ [Win12] zu entnehmen.
Teststufe Multi-Integrationstest
Die Qualität der Integration und Kommunikation zwischen unterschiedlich voneinander entwickelten Systemen mit einer Vielzahl gemeinsamer Schnittstellen im Verbund zu sichern, ist die Aufgabe des Multi-Integrationstests. Bei diesem Test wird systematisch die Kommunikation zwischen den Systemen auf Protokollebene untereinander und im Verbund über ihre gemeinsamen spezifizierten Schnittstellen erprobt und getestet. Die Teststufe Multi-Integrationstest soll dazu dienen, Inkonsistenzen, wie falsche oder fehlerhafte Parameter- oder Werteübertragung, sowie Timing-Fehler zwischen den verbundenen Systemen aufzudecken. Diese Stufe spielt eine enorm wichtige Rolle in der gesamten Kette der QS insbesondere für Qualitätsmerkmale wie funktionale Eignung, Sicherheit, Benutzbarkeit, Zuverlässigkeit, Kompatibilität und Effizienz der zusammengesetzten Funktionalitäten und Geschäftsprozesse.
Das Ziel des Multi-Integrationstests ist es, die Abweichungen in den gemeinsamen Schnittstellen und im Zusammenspiel der integrierten Systeme zu finden. Die Abweichungen können durch den manuellen oder automatischen Abgleich der Soll- und Istwerte sowie durch die visuelle Überprüfung der Schnittstellenzustände gefunden werden. In dieser Teststufe werden die integrierten Systeme gegen den detaillierten spezifizierten technischen Systementwurf, meistens die Schnittstellendefinitionen für das Multisystem, validiert.
Es ist oft durch den Test ersichtlich, dass gewisse Neuentwicklungen oder Anpassungen der Schnittstellen bei den integrierten einzelnen Systemen erforderlich sind. Es ist aber oft nicht sehr einfach, diese Anpassungen bei den Systemen, die möglicherweise von unterschiedlichen Herstellerfirmen geliefert werden, durchzuführen. Diese stellen sowohl organisatorisch als auch technisch eine große Herausforderung dar, weil oft bei solchen Integrationsprojekten konkurrierende Firmen in die Implementierung von Multisystemen involviert sind und dabei nicht selten gewisse politische und wirtschaftliche Aspekte sowie Geheimhaltung der technischen Details eine wichtige Rolle spielen.
Die Errichtung der erforderlichen Testumgebung für die Durchführung des Multi-Integrationstests ist eine weitere Herausforderung bei dem Test von Multisystemen. Die Anforderungen an die notwendige Testumgebung sind oft sehr speziell und dies kann den Aufbau der Testumgebung erschweren. Um die Integrationstests trotz unterschiedlicher Herausforderungen effizient durchführen zu können, werden üblicherweise Mock-Objekte und/oder Testtreiber definiert, implementiert und eingesetzt.
Teilintegrationstests
Die zentrale Frage bei der Planung und dem Design des Multi-Integrationstests ist zu klären, welche Systeme und deren Schnittstellen als Erste getestet werden müssen. Dabei können verschiedene Faktoren, wie die internen Abhängigkeiten und die zeitliche Verfügbarkeit der Systeme, eine wesentliche Rolle spielen. Es müssen die Systeme zum Test genommen werden, die soweit wie möglich unabhängig von den anderen Systemen getriggert und getestet werden können.
Diese Teilintegrationen werden, nach dem Zwiebelschalenprinzip, sukzessive um weitere Systeme bis zu ihrem Vollumfang erweitert und iterativ getestet. Ein großer Vorteil bei Anwendung dieses Ansatzes ist es, dass durch die Iterationen die gefundenen Abweichungen besser zu lokalisieren und somit zu beheben sind. Für die Teilintegrationstests müssen sowohl funktionale als auch nicht-funktionale Testfälle spezifiziert und durchgeführt werden. Dabei dürfen besonders die Performanztests nicht außer Acht gelassen werden, um die Engpässe in der Kette der zusammengeschalteten Systeme zu finden. Hier gilt, dass „ein Multisystem nur so stark ist wie das schwächste System“.
Gesamtintegrationstest
Nach erfolgreichem Abschluss der Teilintegrationstests beginnt der Gesamtintegrationstest. Dieser ist komplexer als die Teilintegrationstests und muss für den Systemverbund in seiner Gesamtheit geplant und durchgeführt werden. Es muss sichergestellt werden, dass die übergreifenden Transaktionen über mehreren Systemen spezifikationskonform ablaufen.
Um die notwenige „Testtiefe“ in der Kette der zusammengeschalteten Softwaresysteme zu erreichen, müssen geeignete Testdaten bereitgestellt werden. Die Spezifikation und Erstellung der relevanten Testdaten sind wichtige Aufgaben, die aber oft unterschätzt werden.
Mehr als nur die Summe aller Teilsysteme
Ein wichtiges Phänomen, das bei der Integration von mehreren Systemen vorkommen kann, ist das Auftreten von ungünstigen und unvorhergesehenen Nebeneffekten. Ein Multisystem ist mehr als nur die Summe aller konstituierenden Systeme. Es ist die Summe aller einzelnen Systeme, plus die Summe aller Beziehungen zwischen diesen Systemen, plus alle Zustände, die durch die Beziehung und Zusammenwirkung dieser einzelnen Systeme entstehen. Das heißt:
Multisystem = ∑ aller Systeme + ∑ aller Beziehungen + ∑ aller Zustände
Der Multi-Integrationstest soll auch dazu dienen, diese Nebeneffekte soweit wie möglich zu finden und dazu beizutragen, diese möglichst einzugrenzen.
Fazit
Der Multi-Integrationstest führt, wenn er richtig durchgeführt wird, zu einer Komposition von mehreren unterschiedlichen Systemen, sozusagen einem „Vertumnus“ (siehe Abbildung 2), anderenfalls – wenn der Multi-Integrationstest unterschätzt und nicht systematisch durchgeführt wird – kann das Ergebnis zu einem Desaster führen.
Abb. 2: Vertumnus von Arcimboldo (Porträt von Kaiser Rudolf II), Quelle: Wikimedia
Referenzen
[Spi05] A. Spillner, T. Linz, Basiswissen Softwaretest, dpunkt.verlag, 3. Auflage, 2005
[Win12] M. Winter, M. Ekssir-Monfared, H. M. Sneed, R. Seidl, L. Borner, Der Integrationstest – Von Entwurf und Architektur zur Komponenten- und Systemintegration, Hanser-Verlag, 2012
