Regressionstest

Aus besserwiki.de

Bei Regressionstests (seltener auch Nicht-Regressionstests) werden funktionale und nicht-funktionale Tests erneut durchgeführt, um sicherzustellen, dass die zuvor entwickelte und getestete Software auch nach einer Änderung noch funktioniert. Ist dies nicht der Fall, spricht man von einer Regression.

Zu den Änderungen, die Regressionstests erfordern können, gehören Fehlerbehebungen, Softwareerweiterungen, Konfigurationsänderungen und sogar der Austausch von elektronischen Komponenten. Da Regressionstestsuiten in der Regel mit jedem gefundenen Fehler anwachsen, ist häufig eine Testautomatisierung erforderlich. Manchmal wird eine Analyse der Auswirkungen von Änderungen durchgeführt, um eine geeignete Teilmenge von Tests zu bestimmen (Nicht-Regressionsanalyse).

Unter einem Regressionstest (von lateinisch regredior, regressus sum ‚zurückschreiten‘) versteht man in der Softwaretechnik die Wiederholung von Testfällen, um sicherzustellen, dass Modifikationen in bereits getesteten Teilen der Software keine neuen Fehler („Regressionen“) verursachen. Solche Modifikationen entstehen regelmäßig z. B. aufgrund der Pflege, Änderung und Korrektur von Software. Der Regressionstest gehört zu den dynamischen Testtechniken.

Aufgrund des Wiederholungscharakters und der Häufigkeit dieser Wiederholungen ist es sinnvoll, wenn für Regressionstests Testautomatisierung zum Einsatz kommt.

In der Praxis steht der Begriff des Regressionstests für die reine Wiederholung von Testfällen. Die Testfälle selbst müssen spezifiziert und mit einem Soll-Ergebnis versehen sein, welches mit dem Ist-Ergebnis eines Testfalls verglichen wird. Ein direkter Bezug auf die Ergebnisse eines vorherigen Testdurchlaufs findet nicht statt.

Im Gegensatz dazu ordnet Liggesmeyer den Regressionstest in die Gruppe der diversifizierenden Tests ein. Dadurch wird im Unterschied zu funktionsorientierten Testtechniken die Korrektheit der Testergebnisse nicht anhand der Spezifikation entschieden, sondern durch Vergleich der Ausgaben der aktuellen Version mit den Ausgaben des Vorgängers. Ein Testfall gilt beim Regressionstest als erfolgreich absolviert, wenn die Ausgaben identisch sind.

Hintergrund

Wenn Software aktualisiert, geändert oder auf einem geänderten Zielsystem wiederverwendet wird, treten häufig neue Fehler auf und/oder alte Fehler tauchen wieder auf.

Manchmal kommt es zu einem erneuten Auftreten, weil ein Fix durch schlechte Revisionskontrollpraktiken (oder einfaches menschliches Versagen bei der Revisionskontrolle) verloren geht. Oft ist eine Problembehebung insofern "anfällig", als sie das Problem in dem engen Fall behebt, in dem es zuerst beobachtet wurde, aber nicht in allgemeineren Fällen, die während der Lebensdauer der Software auftreten können. Häufig verursacht die Behebung eines Problems in einem Bereich unbeabsichtigt einen Softwarefehler in einem anderen Bereich.

Schließlich kann es vorkommen, dass bei der Neugestaltung einer Funktion einige der gleichen Fehler, die bei der ursprünglichen Implementierung der Funktion gemacht wurden, auch bei der Neugestaltung gemacht werden. In den meisten Situationen der Softwareentwicklung gilt es daher als gute Programmierpraxis, nach dem Auffinden und Beheben eines Fehlers einen Test aufzuzeichnen, der den Fehler aufdeckt, und diesen Test nach späteren Änderungen am Programm regelmäßig erneut auszuführen.

Obwohl dies durch manuelle Testverfahren unter Verwendung von Programmiertechniken geschehen kann, wird es oft mit automatisierten Testwerkzeugen durchgeführt. Eine solche Testsuite enthält Softwaretools, die es der Testumgebung ermöglichen, alle Regressionstests automatisch auszuführen. Einige Projekte richten sogar automatisierte Systeme ein, die alle Regressionstests in bestimmten Zeitabständen erneut ausführen und alle Fehler melden (was auf eine Regression oder einen veralteten Test hindeuten könnte).

Übliche Strategien sind, ein solches System nach jedem erfolgreichen Kompilieren (bei kleinen Projekten), jede Nacht oder einmal pro Woche laufen zu lassen. Diese Strategien können durch ein externes Tool automatisiert werden.

Regressionstests sind ein wesentlicher Bestandteil der Softwareentwicklungsmethode Extreme Programming. Bei dieser Methode werden die Entwurfsdokumente durch umfangreiche, wiederholbare und automatisierte Tests des gesamten Softwarepakets in jeder Phase des Softwareentwicklungsprozesses ersetzt. Regressionstests werden nach Abschluss der Funktionstests durchgeführt, um zu überprüfen, ob die anderen Funktionalitäten funktionieren.

In der Unternehmenswelt werden Regressionstests traditionell von einem Software-Qualitätssicherungsteam durchgeführt, nachdem das Entwicklungsteam seine Arbeit abgeschlossen hat. Allerdings ist die Behebung von Fehlern, die in dieser Phase gefunden werden, am kostspieligsten. Dieses Problem wird durch das Aufkommen von Unit-Tests angegangen. Obwohl Entwickler schon immer Testfälle als Teil des Entwicklungszyklus geschrieben haben, handelte es sich bei diesen Testfällen im Allgemeinen entweder um Funktionstests oder um Unit-Tests, die nur die beabsichtigten Ergebnisse überprüfen. Das Entwicklertesten zwingt einen Entwickler, sich auf Unit-Tests zu konzentrieren und sowohl positive als auch negative Testfälle einzubeziehen.

Techniken

Die verschiedenen Regressionstesttechniken sind:

Alle erneut testen

Bei dieser Technik werden alle Testfälle des aktuellen Programms überprüft, um dessen Integrität zu prüfen. Sie ist zwar kostspielig, da alle Fälle erneut ausgeführt werden müssen, stellt aber sicher, dass keine Fehler aufgrund des geänderten Codes auftreten.

Auswahl von Regressionstests

Im Gegensatz zu Retest all führt diese Technik einen Teil der Testsuite aus (aufgrund der Kosten von Retest all), wenn die Kosten für die Auswahl des Teils der Testsuite geringer sind als bei Retest all.

Priorisierung von Testfällen

Priorisierung der Testfälle, um die Fehlerentdeckungsrate einer Testsuite zu erhöhen. Bei den Techniken zur Priorisierung von Testfällen werden die Testfälle so geplant, dass die Testfälle mit höherer Priorität vor den Testfällen mit niedrigerer Priorität ausgeführt werden.

Arten der Priorisierung von Testfällen

  • Allgemeine Priorisierung - Priorisierung von Testfällen, die für nachfolgende Versionen von Nutzen sein werden
  • Versionsspezifische Priorisierung - Priorisierung von Testfällen im Hinblick auf eine bestimmte Version der Software.

Hybride

Diese Technik ist eine Mischung aus der Auswahl von Regressionstests und der Priorisierung von Testfällen.

Vorteile und Nachteile

Regressionstests werden durchgeführt, wenn Änderungen an der bestehenden Funktionalität der Software vorgenommen werden oder wenn ein Fehler in der Software behoben wurde. Regressionstests können mit verschiedenen Ansätzen durchgeführt werden. Wenn ein Test-Alles-Ansatz verfolgt wird, bietet er die Gewissheit, dass die an der Software vorgenommenen Änderungen keine Auswirkungen auf die bestehenden Funktionalitäten haben, die unverändert bleiben.

In der agilen Softwareentwicklung - wo die Lebenszyklen der Softwareentwicklung sehr kurz, die Ressourcen knapp und die Änderungen an der Software sehr häufig sind - können Regressionstests eine Menge unnötigen Overhead verursachen.

In einer Softwareentwicklungsumgebung, die dazu neigt, Black-Box-Komponenten von Drittanbietern zu verwenden, kann die Durchführung von Regressionstests schwierig sein, da jede Änderung an der Komponente eines Drittanbieters den Rest des Systems beeinträchtigen kann (und die Durchführung von Regressionstests an einer Komponente eines Drittanbieters ist schwierig, da es sich um eine unbekannte Einheit handelt).

Verwendet

Regressionstests können nicht nur zum Testen der Korrektheit eines Programms verwendet werden, sondern oft auch zum Verfolgen der Qualität seiner Ausgabe. Bei der Entwicklung eines Compilers könnten Regressionstests zum Beispiel die Codegröße und die Zeit, die für die Kompilierung und Ausführung der Testfälle benötigt wird, verfolgen.

Auch als Folge der Einführung neuer Fehler erfordert die Programmpflege weit mehr Systemtests pro geschriebener Anweisung als jede andere Programmierung. Theoretisch muss nach jeder Fehlerbehebung der gesamte Stapel der zuvor gegen das System durchgeführten Testfälle ausgeführt werden, um sicherzustellen, dass das System nicht auf unerklärliche Weise beschädigt wurde. In der Praxis müssen solche Regressionstests in der Tat dieser theoretischen Idee nahe kommen, und das ist sehr kostspielig.

- Fred Brooks, The Mythical Man Month, S. 122

Regressionstests lassen sich grob in funktionale Tests und Unit-Tests einteilen. Funktionstests trainieren das gesamte Programm mit verschiedenen Eingaben. Unit-Tests testen einzelne Funktionen, Unterprogramme oder Objektmethoden. Sowohl Funktionstests als auch Unit-Tests werden in der Regel automatisiert durchgeführt und sind oft Produkte von Drittanbietern, die nicht Teil der Compiler-Suite sind. Ein Funktionstest kann eine Reihe von Programmeingaben in Form von Skripten sein, möglicherweise sogar mit einem automatisierten Mechanismus zur Steuerung von Mausbewegungen und -klicks. Ein Unit-Test kann eine Reihe separater Funktionen innerhalb des Codes selbst oder eine Treiberschicht sein, die mit dem Code verbunden ist, ohne den zu testenden Code zu verändern.

Regressionstests in Echtzeitsystemen

Der Regressionstest stellt insbesondere bei nichtdeterministischen Echtzeitsystemen ein wesentliches Problem dar, da in diesen Systemen eine Wiederholung des Tests streng genommen nicht gewährleistet ist. Zum einen führen typischerweise bereits geringfügige Änderungen an der Hardware des Systems zu einem veränderten Verhalten, andererseits sind hier im Allgemeinen manuelle Eingriffe (zum Beispiel bei Telefonanlagen oder Flugüberwachungssystemen) notwendig, die wegen des menschlichen Zeitverhaltens nicht „regressionstestgerecht“ erfolgen können. Eine Lösung dieses Problems liegt in der Implementierung eines automatischen Testsystems. Der Aufwand hierfür wird jedoch aus folgenden Gründen meistens gescheut:

  1. das automatische Testsystem muss alle Funktionen des Prüflings abdecken
  2. das automatische Testsystem muss parallel zum Prüfling entwickelt werden
  3. das automatische Testsystem muss parallel zum Prüfling angepasst werden
  4. eine Hardware-Änderung führt zu einem Neu-Aufsetzen der Testergebnisse, gegen die verglichen werden soll