Unter einem Regressionstest verstehen die meisten Software-Tester die Wiederholung eines bestehenden Tests. Damit möchten sie prüfen, ob dieser Test nach einer Software-Änderung noch immer erfolgreich durchläuft.
1. Ziele von Regressionstests
Ziel 1: „Alter Code funktioniert noch“
Normen wie die IEC 62304 fordern eine Regressionsprüfung, um festzustellen, dass die Änderung einer SYSTEM-Komponente deren Funktionalität, Zuverlässigkeit und Leistungsfähigkeit nicht beeinträchtigt und keine zusätzlichen Defekte verursacht hat.
Damit wird das Ziel eines Regressionstests aus Sicht der IEC 62304 klar: Durch eine Software-Änderung verursachte Fehler in bereits getestetem Code finden.
Die FDA formuliert das in ihrem Software Validation Guide fast identisch:
Regression testing is the rerunning of test cases that a program has previously executed correctly and comparing the current result to the previous result in order to detect unintended effects of a software change.
Quelle: FDA Software-Validation Guidance
Ziel 2: „Code funktioniert zuverlässig“
Ein zweites Ziel erwähnt die IEC 62304 nicht: Ein Regressionstest kann auch prüfen, ob sich eine Software dauerhaft gleich verhält, ohne dass man sie ändert. Solche Prüfungen empfehlen sich, wenn sich die Software nicht streng deterministisch verhält, z. B.
- bei Race-Conditions,
- bei Änderungen an der Laufzeitumgebung, beispielsweise der Hardware oder dem Betriebssystem
- oder bei der Abhängigkeit von (sich ändernden) Daten.
2. Regressionstest: Regulatorische Anforderungen
a) Anforderungen der IEC 62304
Regressionstest während der Integrationsprüfung
Die IEC 62304 fordert, Regressionsprüfungen/Regressionstests im Rahmen der Integrationsprüfung/Integrationstests. Damit soll sichergestellt werden, dass bei der Integration neuer Komponenten in einen bereits integrierten Teil von Komponenten keine Fehler eingeführt werden. Welche Fehler das sein könnten, beschreibt die Norm nicht.
Regressionstest bei Änderungen am Software-System
Erwartungsgemäß fordert die Norm eine Regressionsprüfung bei Änderungen am Software-System. Auch bei kleinen Änderungen, wie sie betont.
Die Hersteller müssen zudem begründen, wenn sie nach einer Änderung nicht alle Regressionstests erneut durchführen. Lesen Sie weiter unten mehr zu diesem Punkt.
b) Anforderungen der FDA
Regressionstest bei Änderungen an der Software
Die FDA betont, dass 79 % aller Software-Fehler bei der Änderung einer bereits freigegebenen Software eingeführt werden. Entsprechend betont sie die Notwendigkeit von Regressionstests:
Whenever software is changed, a validation analysis should be conducted not just for validation of the individual change, but also to determine the extent and impact of that change on the entire software system. Based on this analysis, the software developer should then conduct an appropriate level of software regression testing to show that unchanged but vulnerable portions of the system have not been adversely affected. Design controls and appropriate regression testing provide the confidence that the software is validated after a software change.
FDA Software Validation Guidance
Ähnlich wie die IEC 62304 verlangt die FDA die Regressionstests sowie eine Analyse, welche Teile der Software nochmals zu prüfen sind.
Regressionstest während der Integrationsprüfung
Analog zur IEC 62304 findet sich auch eine Forderung bezüglich der Integration:
Regression analysis and regression testing should also be employed when using integration methods to build a software product to ensure that newly integrated modules do not adversely impact the operation of previously integrated modules.
Quelle: IEC 62304
Möglichst jeden Test als Regressionstest durchführen
Ein besonderes Augenmerk legt die FDA auf das Konfigurationsmanagement und die Fähigkeit von (allen) Tests, im Rahmen des Regressions-Testings wiederholt werden zu können:
Test procedures, test data, and test results should be documented in a manner permitting objective pass/fail decisions to be reached. They should also be suitable for review and objective decision making subsequent to running the test, and they should be suitable for use in any subsequent regression testing.
Quelle: FDA
3. Welcher Teil der Software muss Regressions-getestet werden?
Die kurze Antwort auf diese Frage lautet: Das gesamte Software-System mit allen Tests, es sei denn, Sie können einen kleineren Testumfang begründen.
Es gibt somit zwei Stellschrauben, über die Sie den Testumfang reduzieren können:
- Die Größe des Testobjekts (sprich ganzes Software-System oder nur Teile)
- Die Testziele, also auf welche Qualitätseigenschaften Sie die Software hin überprüfen. Einen Überblick über mögliche Qualitätseigenschaften verschafft Ihnen die ISO 25010.
Ad 1. Beschränkung der Größe des Testobjekts
Wenn Sie bei einer Änderung an einem Teil eines Software-Systems nur eben diesen Teil einer Regressionsprüfung unterwerfen wollen, dann müssen Sie darlegen, weshalb sich diese Änderung nicht auf andere Teile des Software-Systems auswirken kann.
Diese Begründung wird Ihnen am besten anhand einer dokumentierten Software-Architektur gelingen. Diese sollte nämlich aufzeigen:
- Abhängigkeiten anderer Komponenten von der geänderten Komponente
- Schnittstellen, über die diese Abhängigkeiten realisiert sind
Ad 2. Beschränkung der Testziele
Besonders bei „nicht-funktionalen Anforderungen“ wie der Performanz oder der Portierbarkeit kann oft nicht ausschließlich über die (statische) Software-Architektur argumentiert werden. Allerdings sind die Begründungen offensichtlich. Beispiele:
- Durch die Änderung eines Algorithmus wird die Portierbarkeit der Software wahrscheinlich nicht beeinflusst.
- Wenn im Rahmen eines Unit-Tests nachgewiesen werden kann, dass die Performanz einer Komponente unverändert ist, ist eine Änderung der Performanz des gesamten Systems unwahrscheinlich.
Diese Möglichkeit, Regressionstests nach Art des Testziels auszuwählen bedingt jedoch, dass die Tests auch danach klassifiziert und aufgeteilt sind.
4. Regressionstest: Best Practices
a) Allgemeines Tipps
Regressionstests sind Kennzeichen einer professionellen Software-Entwicklung. Sie sind Ihre „Versicherung“, Ihre Leitplanken, v. a. bei Software-Änderungen.
Falls Sie noch keine umfassenden Regressionstests durchführen, dann starten Sie mit diesen Tipps:
- Automatisieren Sie, was automatisiert werden kann.
Das ist eine anfängliche Investition, die sich rechnet. Wenn Sie Kapazitätsprobleme haben, dann denken Sie über eine/n Werkstudenten/studentin nach, der/die im Rahmen seiner/ihrer Arbeit eine Testinfrastruktur aufbaut. Keine Zeit in Regressionstests zu investieren ist so wie keine Zeit zum Schärfen seiner Säge zu haben, weil das Holzsägen so mühsam ist. - Erhöhen Sie den Anteil der Regressionstests
Für bestehenden Code werden die meisten keine Tests mehr „nach-schreiben“ wollen. Dann legen Sie fest, dass alle geänderten und alle neuen Code-Teile in einer Regressions-Suite eingehängt werden müssen. So erhöhen Sie im Lauf der Zeit kontinuierlich den Anteil des automatisiert getesteten Codes (s. Abb. 1). - Verbessern Sie Ihre Software-Architektur
Die Aussage, dass sich ein Code nur schwer (z. B. nur mit Hardware) testen ließe, ist ein deutliches Indiz dafür, dass der Code suboptimal strukturiert ist. Ein Hardware-Abstraction-Layer, ein Architektur-Refactoring und mehr Ausbildung im Bereich des Software-Testings können Wunder bewirken. - Lassen Sie die Tests möglichst häufig laufen
Ein automatisierter Build mit einem Tool wie Hudson oder Maven hilft Ihnen, Fehler früh zu finden. Wenn Sie diese eliminieren, können Sie einen unerwarteten Projektverzug kurz vor dem Release vermeiden.
b) Testen von embedded Software
Manche Kunden vermuten: Wir können bei uns nicht automatisiert testen, weil wir sehr Hardware-nah programmieren. Außerdem verlangt die IEC 62304 das auch nicht.
Sicher trifft es zu, dass die IEC 62304 keine Automatisierung verlangt. Es ist auch zutreffend, dass bei sehr Hardware-naher embedded Software die Hardware vorhanden sein muss, um diese Software zu testen. Dennoch:
- Zum einen sind automatisierte Teststände, die diese Hardware enthalten, keine neue Erfindung.
- Zum anderen muss die Entscheidung pro oder contra automatisiertes Testen nicht pauschal für die ganze Software getroffen werden.
Wann embedded Software automatisiert getestet werden kann und soll
Eine einfache Regel z. B. für eine SOP-Software-Entwicklung könnte lauten: Alle Komponenten, die keinen Hardwarezugriff enthalten, müssen automatisiert getestet werden. Dabei ist die Feststellung, ob Hardwarezugriff erfolgt, auf jeder Hierarchieebene zu treffen.
- Abb. 2 zeigt, dass das System insgesamt (0. Bausteinebene) einen Hardwarezugriff hat, daher ist es rot und muss nicht komplett automatisiert getestet werden.
- Auf Bausteinebene 1 hat nur eine der vier Komponenten Hardwarezugriff, die anderen nicht (grün). Und von dieser einen Komponente mit Hardwarezugriff (rot) ist es auf Ebene 2 wiederum nur eine Komponente (rot).
Wenn hingegen fast alle Komponenten Hardwarezugriff hätten, dann stellt sich die Frage nach der Güte der Architektur. Hat man ein Hardware-Abstraction-Layer (HAL) vergessen? Sind Funktionalitäten gar redundant implementiert? Genau diese Übersicht und dieses Verständnis verschafft ein Komponentendiagramm.
Infrastruktur zum Testen von embedded Software
Manchmal ist es schwierig, direkt die externe Hardware-Schnittstelle zu testen, weil eine entsprechende Testinfrastruktur fehlt oder/und das Protokoll sehr aufwendig ist. Daher könnte eine weitere Regel lauten, dass in diesen Fällen das extern anzuschließende System (hellblau in Abb. 2) als Testtreiber genutzt werden darf. Ein wirklicher Komponententest im Sinne der IEC 62304 ist das zwar nicht mehr, aber immerhin besser, als ganz auf diesen Test zu verzichten.
Besser wäre es für embedded Software, eine Testinfrastruktur zu erstellen, die die Protokolle aller internen und externen Schnittstellen beherrscht. Dieser initiale Aufwand rechnet sich dann, wenn mehrere Versionen eines Produkts (einer Komponente) entwickelt werden sollen und daher Regressionstests (auch im Sinn der IEC 62304) gefordert sind.
c) Testen von KI-basierter Software
Die Aussage, dass sich KI-basierte Software, insbesondere Software, die neuronale Netzwerke verwendet wie Large Language Models, wegen ihrer „probabilistischen Natur“ schlecht mit Regressionstests testen lässt, sollte in mehrfacher Hinsicht hinterfragt werden:
- Die Wahl des jeweils nächsten Tokens erfolgt zwar auf Basis einer Wahrscheinlichkeit. Das bedeutet aber noch nicht zwingend, dass sich die Outputs bei gleichen Inputs einer Wahrscheinlichkeitsverteilung folgend ändern. Schließlich ändern sich die „weights and biases“ der neuronalen Netzwerke nicht.
- Wenn die Outputs so unvorhersehbar sind, dass sie nicht einer Spezifikation genügen, ist zu überprüfen, ob das Medizinprodukt überhaupt „zugelassen“ werden darf. Falls hingegen die Outputs den Vorgaben einer Spezifikation genügen, dann muss das auch dauerhaft gewährleistet sein. Genau das sollen und können Regressionstests verifizieren.
- Hersteller müssen in der Lage sein, solch eine Spezifikation zu erstellen. Diese Spezifikationen müssen ggf. auch die Wahrscheinlichkeit bestimmen (ggf. abhängig von Input/Feature), mit denen die Modelle korrekte Vorhersagen treffen. Regressionstests müssen daher auch diese Wahrscheinlichkeiten prüfen, was wiederum voraussetzen kann, dass diese Tests mehrfach durchlaufen werden.
Bei KI-basierten Modellen sind Regressionstests insbesondere bei Software- und Modell-Updates notwendig, weil selbst kleine Änderungen des Modells (z. B. nach einem weiteren Training) große Auswirkungen nach sich ziehen können.
Mit Phantomen (z. B. mit den Röntgenphantomen der Firma PhantomX) lassen sich diese Regressionstests von Produkten bzw. Modellen zur Bildanalyse reproduzierbar durchführen.
Änderungshistorie
- 2024-07-09: Abschnitt 4.c) ergänzt. Redaktionelle Änderungen
- 2019-01-31: Erste Version des Artikels veröffentlicht
