Unter einem Regressionstest verstehen Software-Tester meist die Wiederholung eines bestehenden Tests. Damit möchten sie prüfen, ob dieser Test nach einer Software-Änderung noch immer erfolgreich durchläuft.
| Inhaltsübersicht |
|---|
| Ziele von Regressionstests » |
| Regulatorische Anforderungen » |
| Teile, die erneut zu testen sind » |
| Best Practices » |
1. Ziele von Regressionstests
Ziel 1: „Alter Code funktioniert noch“
Die IEC 62304 fordert eine Regressionsprüfung, die notwendig ist, um festzustellen, dass eine Ä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 im 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 von 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. Zu diesem Punkt lesen Sie weiter unten mehr.
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 im Software Validation Guide:
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 und eine Analyse, welche Teile der Software nochmals zu prüfen sind.
Regressionstest während der Integrationsprüfung
Analog zur IEC 62304 findet sich auch die 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 hat die FDA auf dem Konfigurationsmanagement und der 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 eine 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:
- die Abhängigkeiten anderer Komponenten von der geänderten Komponente,
- die 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 gelingt eine ausschließliche Argumentation über die (statische) Software-Architektur oft nicht. Allerdings sind die Begründungen offensichtlich. Beispiele:
- Durch die Änderung eines Algorithmus wird sich 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 bei v.a. bei Software-Änderungen.
Falls Sie noch keine umfassenden Regressionstests durchführen, wären das meine 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 einen Bachelor- oder Master-Studenten/Studentin nach, der/die im Rahmen seiner/ihrer Arbeit eine Testinfrastruktur aufbaut. Wer nicht in einen Regressionstest investiert, gleich demjenigen, 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
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, 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 Jenkins oder TestAF hilft Ihnen, Fehler früh zu finden und zu eliminieren und so einen unerwarteten Projektverzug kurz vor dem Release zu vermeiden.
b) Testen von embedded Software
Wir können bei uns nicht automatisiert testen, weil wir sehr Hardware-nah programmieren, vermuten manche Kunden. Außerdem würde das die IEC 62304 auch nicht verlangen.
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, dass alle Komponenten, die keinen Hardwarezugriff enthalten, automatisiert getestet werden müssen. Dabei ist die Feststellung, ob Hardwarezugriff erfolgt, auf jeder Hierarchieebene zu treffen.
Die Grafik 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 ist es auf Ebene 2 wiederum nur eine Komponente.
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 (hier in hellblau) als Testtreiber genutzt werden darf. Ein wirklicher Komponententests 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 aber dann, wenn mehrere Versionen eines Produkts (einer Komponente) entwickelt werden sollen und daher Regressionstests (auch im Sinn der IEC 62304) gefordert sind.
