Glossar · Testgrundlagen
Regressionstest
Englisch: Regression testing
Auch genannt: Regressionstests, Regressionstesten, Regressionstestsuite
Definition
Das erneute Ausführen bestehender Tests nach einer Änderung, um zu bestätigen, dass Funktionierendes weiter funktioniert und der Fix nichts anderes kaputt gemacht hat.
Ein Regressionstest prüft, dass eine Änderung nichts kaputt gemacht hat, was vorher funktioniert hat. Eine „Regression“ ist eine Funktion, die in einem früheren Build funktioniert hat und es jetzt nicht mehr tut. Sie finden sie, indem Sie nach jedem Bugfix, jedem Feature, jedem Refactoring, jedem Upgrade einer Abhängigkeit und jeder Konfigurationsänderung die Tests für das bestehende Verhalten erneut ausführen.
Beispiel
Ein Team ergänzt den Checkout um die Option „Mit Geschenkkarte bezahlen“. Das neue Feature erhält eigene Tests. Der Regressionstest stellt eine andere Frage: Verhalten sich Kartenzahlungen, Rabattcodes, Steuerberechnung und Bestell-E-Mails noch genau wie vorher? Eine gemeinsame Änderung am Modul für die Preisberechnung könnte jede dieser Funktionen leicht beschädigen, ohne den neuen Codepfad zu berühren.
Auswählen, was ausgeführt wird
Bei jedem Commit alle Tests auszuführen ist die einfachste Strategie, und mit einer schnellen automatisierten Suite ist sie oft die richtige. Ist die vollständige Suite zu langsam oder teilweise manuell, wählen Teams aus:
- Nach Risiko. Geschäftskritische Abläufe (Registrierung, Zahlung, Datenexport) laufen immer.
- Nach Auswirkung. Bereiche, die Code, Daten oder Dienste mit der Änderung teilen.
- Nach Historie. Module, die schon einmal regressiert sind, regressieren tendenziell erneut.
Eine gängige Aufteilung ist eine schnelle Regressions-Teilmenge bei jedem Pull Request und die vollständige Suite nächtlich oder vor einem Release.
Warum Teams ihn als Erstes automatisieren
Regressionstests führen immer wieder dieselben Schritte gegen dieselben erwarteten Ergebnisse aus, und genau darin ist Automatisierung gut. Manuelle Regression wächst mit jedem Release, die verfügbare Zeit aber nicht, also wird sie als Erstes gekürzt. Eine automatisierte Regressionssuite in der CI verwandelt die Frage „Haben wir etwas kaputt gemacht?“ von einer Woche manueller Prüfung in ein Pipeline-Ergebnis.
Häufige Fehler
- Die Suite als reines Anhängsel behandeln. Veraltete und doppelte Tests verlangsamen jeden Lauf. Überprüfen und ausmisten.
- Flaky Tests tolerieren. Wenn Fehlschläge routinemäßig wiederholt werden, bis sie grün sind, werden auch echte Regressionen einfach weggewiederholt.
- Nur über die UI testen. Der Großteil der Regressionsabdeckung ist auf Unit- und API-Ebene günstiger und stabiler.