Outside-In-Integrationstest

Der Outside-In-Integrationstest ist eine Strategie zur Durchführung eines Integrationstests. Dabei können die äußeren Softwareteile (i. d. R. mit der Systemumgebung interagierend, „Outside“) und die inneren, aufzurufenden Einheiten („In“) durch Verwendung von Hilfsroutinen unabhängig voneinander getestet werden.

Testen nach dem Outside-In-Ansatz

Grundsätzlich besteht der Integrationstest aus einer Reihe von Einzeltests, durch die das Zusammenspiel unabhängig voneinander entwickelter Komponenten einer Software getestet wird.[1] Dafür wird eine Integrationsstrategie benötigt, die festlegt, in welcher Reihenfolge die Tests stattfinden.[2] Ziel ist es, eine fehlerfreie Interaktion zwischen allen beteiligten Modulen des Softwaresystems zu prüfen und sicherzustellen. Je nach angewendetem Vorgehensmodell kann dem Integrationstest das Testen isolierter Softwarebausteine als eigene Teststufe ‚Modultest‘ vorausgehen.

Nach dem Outside-In-Ansatz benötigt der Integrationstest ersatzweise Treiber anstelle von fehlenden (noch ungetesteten) aufrufenden Komponenten und Dummies (Stubs) anstelle von noch fehlenden ‚unterlagerten‘ Modulen.[3] Erfolgreich getestete Komponenten ersetzen in nachfolgenden Tests sukzessive ihre Stellvertreter, sodass zuletzt das vollständige System abschließenden Einzeltests unterworfen werden kann. Die Reihenfolge im Integrationstest wird also durch die Aufrufstruktur der zu testenden Komponenten (Testobjekte) bestimmt.

Outside-In- und auch Inside-Out-Softwaretests gehören zu den verfahrensorientierten inkrementellen Strategien für Integrationstests. Sie sind Varianten der Sandwich-Strategie, die eine Mischung aus der Bottom-Up- und der Top-Down-Strategie ist[4] und die Vorteile der Top-Down- und der Bottom-Up-Strategie vereint.[5]

Funktionsweise der Outside-In-Strategie

Bei der Outside-In-Strategie arbeiten sich zwei Teams unabhängig voneinander bis zur Mitte vor. Das erste Team beginnt bei der untersten Hierarchieebene, welche die dienstanbietenden Module beinhaltet und geht weiter zu den dienstnutzenden, welche die obersten Module sind. Sie verwenden also die Bottom-Up Methode. Das zweite Team arbeitet genau umgekehrt, sie beginnen bei den dienstnutzenden Modulen, gehen nach unten zu den dienstanbietenden Modulen. Dieses Vorgehen ist die Top-Down-Methode. So treffen sich beide Teams dann in der Mitte der Hierarchie und setzten so das Gesamtsystem zusammen.[4] Das heißt die Outside-In-Methode modelliert [testet] zuerst die Umwelt eines Systems, bevor sie sich mit dem Systeminneren befasst.[6] Dieser Integrationstest ist, neben dem Inside-out-Test, die einzige Strategie, die den Einsatz mehrerer [getrennt voneinander arbeitender] Testteams unterstützt.[4]

Vor- und Nachteile

Vorteile

Die Vorteile der Outside-In-Methode sind:

  • Das Äußere einer Software ist im Prinzip alles was mit Menschen oder mit anderen Systemen (der Umwelt) in Kontakt steht. Durch die Fokussierung auf die äußeren Komponenten wird sichergestellt, dass das System mit seiner Umwelt harmoniert.[6]
  • Zu Beginn wird ein Produkt entwickelt, welches die groben Abläufe des Systems erkennen lässt.
  • Um ein funktionsfähiges System zu entwickeln, wird schon von Anfang an das System immer wieder geprüft.
  • Dummies welche in unterlagerte Module eingebaut werden, ermöglichen eine präzise Prüfung der Fehlerbehandlung, indem sie die Manipulation von Rückgabewerten ermöglichen.
  • Falls es zu Schnittstellenproblemen kommen sollte, wird die Zusammenarbeit der Hardware, Software und der Systemsoftware so früh wie möglich überprüft, um genug Zeit für die Fehlerbehebung zu haben.
  • In den Schichten, die nach dem Bottom-Up Verfahren eingefügt werden, ist es möglich absichtliche Fehleingaben zur Überprüfung von Fehlerbehandlungen einzusetzen.
  • Dazu kommt, dass der Outside-In-Test eine kürzere Zeitspanne in Anspruch nimmt und auch weniger Personalbedarf hat.[7][8]

Nachteile

Die Nachteile des Outside-In-Tests sind:

  • Es werden Treiber und Dummies benötigt.[7][8]
  • Es ist schwerer einen Fehler in den inneren Komponenten zu finden, wenn diese von außen aufgerufen werden. Das liegt daran, dass zu viele Schichten dazwischen liegen, die den Aufruf bestimmen.[6]
  • Bei der Outside-In-Methode werden nur die Einflüsse des vorhandenen Kontexts betrachtet, verändert sich jedoch der Kontext ist es möglich, dass das System unbrauchbar wird. Die Wiederverwendbarkeit ist dadurch nicht gesichert.[6]
  • Die Tests sind teuer, da mehrere Teile des Systems benötigt werden, um den Test auszuführen.[9]

Inside-Out-Integrationstest

Im Gegensatz zur Outside-In Methode wird bei der Inside-Out-Methode zuerst das Systeminnere modelliert, bevor sie sich mit der Umwelt des Systems befasst. Bei der Inside-Out-Methode stehen die Strukturüberlegungen im Mittelpunkt. Das birgt die Gefahr, dass Notwendigkeiten der Umwelt übersehen oder zu spät entdeckt werden.[6] Die Inside-Out-Integration wird sehr selten eingesetzt, da sie nicht die Vorteile von Top-Down und Bottom-Up vereint, sondern eher ihre Nachteile.[5]

Methode der Inside-Out-Integration

Begonnen wird in der Mitte der Hierarchie und von dort aus werden sowohl nach oben als auch nach unten Komponenten integriert, bis das System vollständig integriert wurde.[10][11]

Literatur

  • Walter Masing, Tilo Pfeifer; Masing Handbuch Qualitätsmanagement; ISBN 978-3-446-43431-8; Carl Hanser Verlag GmbH & Co. KG; 6. Auflage; 2014
  • Mario Winter, Mohsen Ekssir-Monfared, Harry Sneed, Richard Seidl, Lars Borner: Der Integrationstest – Von Entwurf und Architektur zur Komponenten- und Systemintegration. ISBN 978-3-446-42564-4; Carl Hanser Verlag; 1. Auflage; 2012
  • Torsten Cleff; Basiswissen Testen von Software; ISBN 978-3-86834-012-9; W3L GmbH, 1. Auflage; 2010
  • Dietmar Abts, Wilhelm Mülder; Grundkurs Wirtschaftsinformatik eine kompakte & praxisorientierte Einführung, ISBN 978-3-658-16378-5; Springer Vieweg; 9. Auflage; Wiesbaden 2017
  • Jürgen Moormann, Günter Schmidt; IT in der Finanzbranche: Management und Methode; ISBN 978-3-540-34511-4; Springer; 2007
  • Dirk. W. Hoffmann; Software-Qualität; ISBN 978-3-642-35699-5; Springer Vieweg; 2. Auflage; 2013
  • Dirk Zander, Toolgestützte Verifikation verteilter technischer Steuerungssysteme auf der Basis von Aktivitätsdiagrammen, Ruhr-Universität Bochum; Dissertation, Bochum 2009
  • Florin-Avram Pinte; Automatische Optimierung und Evaluierung modellbasierter Testfälle für den Komponenten- und Integrationstest, Dissertation, Erlangen, 2012
  • Helmut Balzert; Lehrbuch der Softwaretechnik, Basiskonzepte und Requirements Engineering; ISBN 978-3-8274-1705-3; Spektrum akademischer Verlag; 3. Auflage; 2009
  • Peter Liggesmeyer; Software-Qualität Testen, Analysieren & Verifizieren von Software; ISBN 978-3-8274-2056-5; Spektrum akademischer Verlag; 2. Auflage; Heidelberg 2009

Einzelnachweise

  1. ↑ [1] Abgerufen am 17. Juni 2018.
  2. ↑ Dirk Zander, Toolgestützte Verifikation verteilter technischer Steuerungssysteme auf der Basis von Aktivitätsdiagrammen, Ruhr-Universität Bochum; Dissertation, Bochum 2009, S. 72–74.
  3. ↑ Peter Liggesmeyer; Software-Qualität Testen, Analysieren & Verifizieren von Software; Spektrum akademischer Verlag, Heidelberg 2009; 2. Auflage; S. 372.
  4. ↑ a b c Mario Winter, Mohsen Ekssir-Monfared, Harry Sneed, Richard Seidl, Lars Borner: Der Integrationstest – Von Entwurf und Architektur zur Komponenten- und Systemintegration. Carl Hanser Verlag; 2012; 1. Auflage; S. 163f.
  5. ↑ a b Florin-Avram Pinte; Automatische Optimierung und Evaluierung modellbasierter Testfälle für den Komponenten- und Integrationstest, Dissertation, Erlangen, 2012; S. 26.
  6. ↑ a b c d e Helmut Balzert; Lehrbuch der Softwaretechnik, Basiskonzepte und Requirements Engineering; Spektrum akademischer Verlag; 2009; 3. Auflage; S. 54–56.
  7. ↑ a b Peter Liggesmeyer; Software-Qualität Testen, Analysieren & Verifizieren von Software; Spektrum akademischer Verlag, Heidelberg 2009; 2. Auflage; S. 375/376.
  8. ↑ a b Walter Masing, Tilo Pfeifer; Masing Handbuch Qualitätsmanagement; München, Wien: Carl Hanser Verlag GmbH & Co. KG; 2014; 6. Auflage; S. 910f.
  9. ↑ [2]@1@2Vorlage:Toter Link/www.atlassian.com (Seite nicht mehr abrufbar, festgestellt im Mai 2019. Suche in Webarchiven)  Info: Der Link wurde automatisch als defekt markiert. Bitte prüfe den Link gemäß Anleitung und entferne dann diesen Hinweis. Abgerufen am 17. Juli 2018.
  10. ↑ Jürgen Moormann, Günter Schmidt; IT in der Finanzbranche: Management und Methode; ISBN 978-3-540-34511-4; Springer; 2007; S. 144f.
  11. ↑ Torsten Cleff; Basiswissen Testen von Software; ISBN 978-3-86834-012-9; W3L GmbH, 1. Auflage; 2010; S. 29.