Unter einem Regressionstest verstehen Softwaretester in der Regel die Wiederholung eines bestehenden Tests. Sie möchten prüfen, ob dieser Test nach einer Softwareänderung noch erfolgreich verläuft.
1. Ziele des Regressionstests
Ziel 1: „Alter Code funktioniert noch“
Standards wie IEC 62304 erfordern Regressionstests, um festzustellen, ob eine Änderung an einer SYSTEM-Komponente deren Funktionalität, Zuverlässigkeit oder Leistung nicht beeinträchtigt und keine zusätzlichen Fehler verursacht hat.
Damit wird das Ziel eines Regressionstests aus Sicht der IEC 62304 deutlich: Fehler zu finden, die durch eine Softwareänderung in bereits getestetem Code verursacht werden.
Die FDA formuliert dies im Software Validation Guide nahezu identisch:
Unter Regressionstests versteht man die Wiederholung von Testfällen, die ein Programm zuvor korrekt ausgeführt hat, und den Vergleich des aktuellen Ergebnisses mit dem vorherigen Ergebnis, um unbeabsichtigte Auswirkungen einer Softwareänderung zu erkennen.
Quelle: FDA Software-Validation Guidance
Ziel 2: „Code funktioniert zuverlässig“
Ein zweites Ziel nennt die IEC 62304 nicht: Ein Regressionstest kann auch prüfen, ob sich Software langfristig gleich verhält, ohne sie zu verändern. Solche Tests werden empfohlen, wenn sich die Software nicht streng deterministisch verhält, z
- bei Race-Conditions
- wenn es Änderungen an der Laufzeitumgebung, etwa der Hardware oder dem Betriebssystem, gibt
- oder wenn es von (sich ändernden) Daten abhängt.
2. Regressionstest: Regulatorische Anforderungen
a) Anforderungen der IEC 62304
Regressionstests während des Integrationstests
Die IEC 62304 fordert Regressionstests/Regressionstests als Teil des Integrationstests/Integrationstests. Dadurch soll sichergestellt werden, dass bei der Integration von Komponenten in einen bereits integrierten Teil von Komponenten keine Fehler entstehen. Um welche Fehler es sich dabei handeln könnte, beschreibt die Norm nicht.
Regressionstests für Änderungen am Softwaresystem
Wie erwartet verlangt der Standard Regressionstests für Änderungen am Softwaresystem. Auch bei kleinen Veränderungen, wie sie betont.
Hersteller müssen außerdem begründen, wenn sie nach einer Änderung nicht alle Regressionstests erneut durchführen. Lesen Sie weiter unten mehr zu diesem Punkt.
b) FDA-Anforderungen
Regressionstests für Änderungen an der Software
Die FDA betont, dass 79 % aller Softwarefehler durch die Änderung bereits veröffentlichter Software entstehen. Dementsprechend betont sie im Software Validation Guide die Notwendigkeit von Regressionstests:
Bei jeder Änderung einer Software sollte eine Validierungsanalyse nicht nur zur Validierung der einzelnen Änderung, sondern auch zur Bestimmung des Ausmaßes und der Auswirkungen dieser Änderung auf das gesamte Softwaresystem durchgeführt werden. Basierend auf dieser Analyse sollte der Softwareentwickler dann Software-Regressionstests auf angemessenem Niveau durchführen, um zu zeigen, dass unveränderte, aber anfällige Teile des Systems nicht beeinträchtigt wurden. Designkontrollen und entsprechende Regressionstests geben die Gewissheit, dass die Software nach einer Softwareänderung validiert ist.
FDA-Leitfaden zur Softwarevalidierung
Ähnlich wie IEC 62304 verlangt die FDA Regressionstests und eine Analyse, welche Teile der Software erneut getestet werden müssen.
Regressionstests während des Integrationstests
Analog zur IEC 62304 gibt es auch eine Anforderung bezüglich der Integration:
Bei der Verwendung von Integrationsmethoden zum Erstellen eines Softwareprodukts sollten auch Regressionsanalysen und Regressionstests eingesetzt werden, um sicherzustellen, dass neu integrierte Module den Betrieb zuvor integrierter Module nicht beeinträchtigen.
Welche: IEC 62304
Führen Sie nach Möglichkeit jeden Test als Regressionstest durch
Besonderes Augenmerk legt die FDA auf das Konfigurationsmanagement und die Wiederholbarkeit (aller) Tests im Rahmen von Regressionstests:
Testverfahren, Testdaten und Testergebnisse sollten in einer Weise dokumentiert werden, die es ermöglicht, objektive Bestehen-/Nichtbestehen-Entscheidungen zu treffen. Sie sollten auch für die Überprüfung und objektive Entscheidungsfindung im Anschluss an die Durchführung des Tests geeignet sein und für die Verwendung in späteren Regressionstests geeignet sein.
Quelle: FDA
3. Welcher Teil der Software muss einem Regressionstest unterzogen werden?
Die kurze Antwort auf diese Frage lautet: das gesamte Softwaresystem mit allen Tests, es sei denn, Sie können einen kleineren Testumfang rechtfertigen.
Es gibt also zwei Stellschrauben, mit denen Sie den Prüfumfang reduzieren können:
- Die Größe des Testobjekts (z. B. gesamtes Softwaresystem oder nur Teile)
- Die Testziele, also auf welche Qualitätsmerkmale Sie die Software prüfen. Die ISO 25010 gibt Ihnen einen Überblick über mögliche Qualitätsmerkmale.
Zu 1. Begrenzung der Größe des Testobjekts
Wenn Sie an einem Teil eines Softwaresystems eine Änderung vornehmen und nur diesen Teil einem Regressionstest unterziehen möchten, müssen Sie erklären, warum sich diese Änderung nicht auf andere Teile des Softwaresystems auswirken kann.
Der beste Weg, dies zu rechtfertigen, ist die Verwendung einer dokumentierten Softwarearchitektur. Dies sollte Folgendes zeigen:
- die Abhängigkeiten anderer Komponenten von der geänderten Komponente
- die Schnittstellen, über die diese Abhängigkeiten implementiert werden
Ad 2. Einschränkung der Testziele
Gerade wenn es um „nicht-funktionale Anforderungen“ wie Performance oder Portabilität geht, ist eine ausschließliche Argumentation auf Basis der (statischen) Software-Architektur oft nicht erfolgreich. Die Gründe liegen jedoch auf der Hand. Beispiele:
- Es ist unwahrscheinlich, dass die Änderung eines Algorithmus die Portabilität der Software beeinträchtigt.
- Wenn ein Unit-Test nachweisen kann, dass die Leistung einer Komponente unverändert bleibt, ist eine Änderung der Leistung des gesamten Systems unwahrscheinlich.
Diese Möglichkeit, Regressionstests anhand der Art des Testziels auszuwählen, erfordert jedoch, dass die Tests auch entsprechend klassifiziert und unterteilt werden.
4. Regressionstest: Best Practices
a) Allgemeine Tipps
Regressionstests sind ein Markenzeichen professioneller Softwareentwicklung. Sie sind Ihre „Versicherung“, Ihre Leitplanken, insbesondere wenn es um Softwareänderungen geht.
Wenn Sie noch keine umfassenden Regressionstests durchführen, wären dies meine Tipps:
- Automatisierendie automatisiert werden können.
Dies ist eine Anfangsinvestition, die sich auszahlt. Wenn Sie Kapazitätsprobleme haben, ziehen Sie einen Bachelor- oder Masterstudenten in Betracht, der im Rahmen seiner Arbeit eine Testinfrastruktur aufbaut. Wer nicht in einen Regressionstest investiert, ist wie jemand, der sagt, er habe keine Zeit, seine Säge zu schärfen, weil er mühsam so viel Holz sägen muss. - Erhöhen Sie den Anteil der Regressionstests
Die meisten Leute werden Tests für vorhandenen Code nicht mehr „neu schreiben“ wollen. Anschließend geben Sie an, dass alle geänderten und neuen Codeteile in eine Regressionssuite aufgenommen werden müssen. Auf diese Weise können Sie den Anteil des automatisch getesteten Codes im Laufe der Zeit kontinuierlich steigern (siehe Abb. 1). - Verbessern Sie Ihre Softwarearchitektur
Die Aussage, dass ein Code schwer zu testen ist (z. B. nur mit Hardware), ist ein klarer Hinweis darauf, dass der Code nicht optimal strukturiert ist. Eine Hardware-Abstraktionsschicht, eine Umgestaltung der Architektur und mehr Schulungen zum Softwaretest können Wunder bewirken. - Führen Sie die Tests so oft wie möglich durch
Ein automatisierter Build mit einem Tool wie Hudson oder Maven hilft Ihnen, Fehler frühzeitig zu finden und zu beheben und so eine unerwartete Projektverzögerung kurz vor der Veröffentlichung zu vermeiden.
b) Testen eingebetteter Software
Manche Kunden vermuten, dass wir nicht automatisch testen können, weil wir sehr nah an der Hardware programmieren. Darüber hinaus würde die IEC 62304 dies auch nicht erfordern.
Sicherlich ist es richtig, dass IEC 62304 keine Automatisierung erfordert. Es gilt auch, dass bei eingebetteter Software, die sehr hardwarebezogen ist, die Hardware vorhanden sein muss, um diese Software testen zu können. Dennoch:
- Einerseits sind automatisierte Prüfstände, die diese Hardware enthalten, keine neue Erfindung.
- Andererseits muss die Entscheidung für oder gegen automatisiertes Testen nicht pauschal für die gesamte Software getroffen werden.
Wenn eingebettete Software automatisch getestet werden kann und sollte
Eine einfache Regel zum Beispiel für einen SOP-Softwareentwicklung könnte bedeuten, dass alle Komponenten, die keinen Hardwarezugriff enthalten, automatisch getestet werden müssen. Die Feststellung, ob ein Hardwarezugriff erfolgt, muss auf jeder Hierarchieebene erfolgen.
Abbildung 2 zeigt, dass das System als Ganzes (0. Blockebene) über Hardwarezugriff verfügt, also rot ist und nicht vollständig automatisch getestet werden muss.
Auf Blockebene 1 hat nur eine der vier Komponenten Hardwarezugriff, die anderen nicht (grün). Und von dieser einen Komponente mit Hardwarezugriff (rot) gibt es nur eine Komponente auf Ebene 2 (rot).
Wenn jedoch nahezu alle Komponenten Hardware-Zugriff hätten, stellt sich die Frage nach der Qualität der Architektur. Haben Sie eine Hardware-Abstraktionsschicht HAL vergessen? Sind Funktionalitäten überhaupt redundant implementiert? Ein Komponentendiagramm bietet genau diesen Überblick und dieses Verständnis.
Infrastruktur zum Testen eingebetteter Software
Manchmal ist es schwierig, die externe Hardwareschnittstelle direkt zu testen, da keine entsprechende Testinfrastruktur vorhanden ist und/oder das Protokoll sehr komplex ist. Daher könnte eine andere Regelung sein, dass in diesen Fällen das extern anzuschließende System (hier in Hellblau) als Testtreiber verwendet werden kann. Es handelt sich zwar nicht mehr um einen echten Komponententest im Sinne der IEC 62304, aber es ist immerhin besser, als ganz auf diesen Test zu verzichten.
Für eingebettete Software wäre es besser, eine Testinfrastruktur zu schaffen, die die Protokolle aller internen und externen Schnittstellen beherrscht. Dieser anfängliche Aufwand lohnt sich jedoch, wenn mehrere Versionen eines Produkts (Komponente) entwickelt werden sollen und daher Regressionstests (auch im Sinne der IEC 62304) erforderlich.
c) Testen von KI-basierter Software
Die Aussage, dass KI-basierte Software, insbesondere Software, die neuronale Netze wie Large Language Models verwendet, aufgrund ihrer „probabilistischen Natur“ schwer mit Regressionstests zu testen ist, sollte auf verschiedene Weise in Frage gestellt werden:
- Die Wahl des nächsten Tokens basiert auf der Wahrscheinlichkeit. Dies bedeutet jedoch nicht unbedingt, dass sich die Ausgaben entsprechend einer Wahrscheinlichkeitsverteilung bei gleichen Eingaben ändern. Schließlich ändern sich die „Gewichte und Vorurteile“ der neuronalen Netze nicht.
- Sind die Leistungen so unvorhersehbar, dass sie einer Spezifikation nicht entsprechen, muss geprüft werden, ob das Medizinprodukt überhaupt „zugelassen“ werden kann. Wenn die Leistungen jedoch den Anforderungen einer Spezifikation entsprechen, muss dies auch langfristig gewährleistet sein. Genau das sollen und können Regressionstests testen.
- Hersteller müssen in der Lage sein, eine solche Spezifikation zu erstellen. Diese Spezifikationen müssen möglicherweise auch die Wahrscheinlichkeit bestimmen (möglicherweise abhängig von den Eingaben/Funktionen), mit der die Modelle korrekte Vorhersagen treffen. Regressionstests müssen daher auch diese Wahrscheinlichkeiten prüfen, was wiederum eine mehrfache Durchführung dieser Tests erforderlich machen kann.
Für KI-basierte Modelle sind insbesondere bei Software-/Modellaktualisierungen Regressionstests notwendig, da bereits kleine Änderungen am Modell (z. B. nach weiterem Training) große Auswirkungen haben können.
Diese Regressionstests von Produkten oder Modellen zur Bildanalyse können mit Phantomen (z. B. den Röntgenphantomen von PhantomX) reproduzierbar durchgeführt werden.
Geschichte verändern
- 09.07.2024: Abschnitt 4.c) hinzugefügt. Redaktionelle Änderungen
- 31.01.2019: Erste Version des Artikels veröffentlicht
Der Beitrag Regressionstests: Ihre Softwareversicherung erschien zuerst auf Wissen über medizinische Software.