Sowohl die IEC 62304 als auch die FDA fordern Integrationsprüfungen, typischerweise in Form von Integrationstests.
1. Was sind Integrationstests?
Integrationstests prüfen, ob eine Komponente die Schnittstellen einer anderen Komponente nutzen, d. h. deren Methoden aufrufen und mit deren Rückgaben (Rückgabewerte, Exceptions) umgehen kann.
2. Weshalb sind Integrationstests notwendig?
a) Qualität der Software verbessern
Integrationstests sollen, wie alle Software-Tests, die Qualität der Software verbessern, indem sie Fehler finden. Dazu prüfen sie, ob die Schnittstellen von zwei und mehr Software-Komponenten (auch Module oder Units genannt) zueinander passen.
Diese Integrationstests sind notwendig, obwohl professionelle Software-Entwickler bereits die öffentlichen Methoden aller Komponenten geprüft haben. Denn Komponenten-, Modul- oder Unit-Tests reichen nicht aus, um Fehler im Zusammenspiel dieser Komponenten zu finden. Das zeigt das folgende Beispiel besonders drastisch:
Eine Raumsonde stürzte ab, obwohl alle Module vollständig getestet waren. Allerdings nutze ein Modul (eine Komponente) SI-Einheiten, ein anderes IU-Einheiten (Imperial Units). Dass die beiden Schnittstellen nicht passen, hätten Integrationsprüfungen finden können.
Abb. 2: Integrationstests sind nicht nur in der Software-Entwicklung eine Best-Practice (Quelle: NASA)
b) Regulatorische Anforderungen erfüllen
Viele Normen fordern die Integrationstests und stellen Anforderungen daran. Beispielsweise fordert die IEC 62304 Integrationsprüfung sowie eine Prüfung, ob das gewählte Integrationsprüfverfahren geeignet ist.
Anforderungen der IEC 62304 an die Integrationstests
Die IEC 62304 stellt folgende Anforderungen an das Integrationstesten:
- Das Vorliegen eines Integrationsplans
- Das Integrationstesten gemäß Plan
- Die Dokumentation der Integrationstests
- Das Anstoßen des Problemlösungsprozesses, falls Fehler gefunden werden
Sehr viele Hersteller erfüllen die Forderung nach dem Problemlösungsprozess nicht. Vielmehr ändern sie die Software so lange, bis sie sich spezifikationsgemäß verhält. Das entspricht weder den Vorgaben noch dem Gedanken der IEC 62304.
Anforderungen der IEC 62304 an die Evaluierung des Integrationsprüfverfahrens
Zudem müssen die Hersteller bewerten und sicherstellen, dass das gewählte Integrationsprüfverfahren geeignet ist.
Der Hersteller muss die Angemessenheit des Integrationsprüfverfahrens evaluieren.
IEC 62304, Kapitel 5.6.5
Seit der Version 2015 der IEC 62304 ist der Abschnitt 5.6.5 etwas verständlicher formuliert, da der Begriff „verify“ durch „evalute“ und der Begriff „correctness“ durch „adequacy“ ausgetauscht wurden.
Es geht also nicht um die Überprüfung der korrekten Anwendung des Prüfverfahrens, sondern um die Eignung des Verfahrens.
Was die Autoren der IEC 62304 unter der Evaluierung verstehen, lässt sich auch aus Anhang B.5.6 ableiten:
- Die Integrationsstrategie ist geeignet (siehe unten).
- Der Hersteller hat die richtigen und notwendigen Testziele bestimmt, z. B. die funktionale Korrektheit, Zeitverhalten, die Wartbarkeit (beispielsweise im Sinne eines „weak coupling“).
- Das Testverfahren ist geeignet; dazu zählt auch die Methode, um die Testfälle zu spezifizieren (siehe unten).
- Der Hersteller hat geeignete Werkzeuge ausgewählt, z. B. zum Erstellen von Stubs/Mock-Objekten, mit denen er Hard- und Software-Komponenten ersetzt, die (noch) nicht verfügbar sind bzw. getestet werden sollen.
Diese Bewertung des Prüfverfahrens erfolgt üblicherweise durch ein Review des Integrationsplans.
3. Wie führt man Integrationstests durch?
Schritt 1: Ziele der Integrationstests festlegen
Zuerst gilt es, die Ziele der Integrationstests festzulegen. Eine gute Checkliste für die Vollständigkeit dieser Ziele liefert die Taxonomie der ISO 25010.
Die Auswahl und Priorisierung dieser Ziele sollte risikobasiert erfolgen. Wenn beispielsweise das Zeitverhalten der Software kritisch ist, sollte es beim Integrationstesten überprüft werden.
Schritt 2: Integrationsstrategie festlegen
Die Festlegung der Integrationsstrategie ist Teil des Testplans. Bereits in der Software-Architektur sollten Hersteller die Integrationsstrategie bestimmen. Diese legt fest, in welcher Reihenfolge die Komponenten integriert werden sollen. Typische Vertreter von Integrationsstrategien sind:
- Bottom-up-Strategie, die bei Entwicklern beliebt ist und viele Testtreiber benötigt
- Top-Down-Strategie, die einen frühen Eindruck vom finalen Produkt ermöglicht und viele Mock-Objekte erfordert
- Big-Bang-Strategie, die eigentlich gar keine stückweise Integration, sondern den Test des gesamten Systems bezeichnet
Bei der Bottom-up-Strategie prüfen die Tester zuerst die Hardware- oder Betriebssystem-nahen Schichten und dann die höheren Schichten (z. B. UI). Das heißt, dass sie im Lauf des Integrationstestens jeweils die nächsthöhere Schicht hinzufügen und dabei überprüfen, ob die Testziele erreicht werden.
Im Auditgarant lernen Sie weitere Integrationsstrategien kennen und erfahren, wie Sie die Anforderungen der IEC 62304 (nicht nur) an das Integrationstesten erfüllen.
Schritt 3: Testfälle spezifizieren
Die Spezifikation von Testfällen ist Teil des Testplans. Um die Testfälle und damit die Testdaten festzulegen, sollten die Hersteller Verfahren wie die Blackbox-Verfahren anwenden. Diese helfen dabei, die Testfälle systematisch so zu bestimmen, dass sie Fehler mit einer besonders hohen Wahrscheinlichkeit finden. Das zeichnet gute Tests aus.
Zur Spezifikation der Testfälle zählt auch die Festlegung, wie die Tests durchgeführt, dokumentiert und deren Ergebnisse bewertet werden.
Lesen Sie hier mehr über dieBlackbox-Testverfahren, wie das Äquivalenzklassen-basierte Testen, und über das Software-Testen im Allgemeinen.
Schritt 4: Tests durchführen und Ergebnisse protokollieren
Um die Tests durchführen zu können, müssen die Tester abhängig von der gewählten Teststrategie Mock-Objekte oder/und Testtreiber entwickeln. Damit führen sie die Tests wie im Testplan vorgesehen durch.
Die Dokumentation umfasst auch eine Bewertung des Testergebnisses. Im Fehlerfall dient diese Dokumentation als Input für den Problemlösungsprozess.
4. Worauf sollte man achten?
a) Auswahl der beteiligten Personen
Um Integrationstests spezifizieren und durchführen zu können, ist sowohl Programmiererfahrung gefragt als auch Kompetenz beim Software-Testen.
Diese Kompetenz bringen insbesondere Software-Entwickler mit, die sich zum Software-Tester weitergebildet haben.
b) Richtiger Zeitpunkt
Die Software-Integrationstests sollten Hersteller nicht erst mit Abschluss der Programmierung beginnen. Vielmehr empfiehlt es sich, frühzeitig das Zusammenwirken der verfügbaren Komponenten gemäß des Integrationsplans zu testen. So lassen sich Fehler früher finden und einfacher beseitigen.
Während der Wartungsphase sollten die Hersteller die Integrationstests auch als Regressionstests durchführen. So stellen sie sicher, dass durch die Änderungen keine bereits behobenen Fehler erneut eingeführt werden.
c) Erfüllung der regulatorischen Anforderungen
Die IEC 62304 verlangt von den Herstellern, im Rahmen der Software-Freigabe zu überprüfen, ob die Software-Integrationstests so wie im Entwicklungsplan bzw. Integrationstestplan festgelegt durchgeführt wurden. Das setzt voraus, dass es diese Pläne gibt.
5. Fazit & Zusammenfassung
Die Integrationstests sind ein wichtiges Instrument der Software-Qualitätssicherung.
Das Johner Institut empfiehlt, diese Tests als eigenständigen Schritt und nicht zusammen mit den Software-Systemtests durchzuführen.
Die Integrationstests helfen beim Nachweis, dass sich das System stückweise aus den Komponenten zusammensetzen lässt. Das wiederum ist eine Bestätigung der gewünschten schwachen Kopplung der Komponenten und damit einer guten Architektur.
Eine Architektur, die das Paradigma „weak coupling and strong cohesion“ nicht erfüllt, wird für die Hersteller zu einer architektonischen Schuld, die sich immer schlechter begleichen lässt. Der Aufwand für diesen „Schuldenabtrag“ ist ein Vielfaches höher als der für konsequent durchgeführte Integrationstests.
Lieber Herr Reinsch,
ich verstehe in Ihrem Artikel leider nicht die Abb.3 in Schritt 4. Warum sollte man im Rahmen von Integrationstests Mock-Objekte für die Komponente B entwicklen? In Abb. 1 wird doch gerade als Ziel der Integrationstests das Zusammenspiel von Komponente A und B beschrieben. Wenn Komponente B gemockt wird, ist man doch wieder bei Unittests. Können Sie das näher erläutern?
Vielen Dank und Grüße
Mark Hastenteufel
Lieber Herr Hastenteufel,
vielen Dank für den berechtigten Einwand. Ich habe die Abbildung aktualisiert. Tatsächlich können andere Komponenten um die betrachteten Komponenten A und B ggf. durch Mock-Objekte ersetzt werden. Mockt man Komponente B kann man tatsächlich maximal prüfen, dass die Schnittstelle von Seiten der Komponente A syntaktisch korrekt umgesetzt ist.
Viele Grüße
Daniel Reinsch
Lieber Herr Reinsch,
vielen Dank für das Ersetzen der Grafik. Ich glaube aber, jetzt passt die Beschreibung nicht mehr zum Bild („Mock-Objekte ersetzen bei Integrationstests Komponenten, hier die Komponente B.“). Im aktuellen Bild sind weder Komponente A noch Komponente B ersetzt sondern eine dritte Komponente. Vielleicht sollten Sie im oberen Teil des Bildes eine Komponente C einführen, die dann für diese Tests gemockt wird. Eine Box um Komponenten A und B könnte dann den Testscope aufzeigen.
Viele Grüße,
Christian T.
Vielen Dank noch einmal für das aufmerksame Lesen! Ich habe es sogleich angepasst.