Regressionstests in der mobilen Entwicklung — was es ist, Arten und wie es durchgeführt wird

Was sind Regressionstests?

Regressionstests sind eine Testart, die bestätigen soll, dass Codeänderungen die vorhandene Funktionalität nicht beeinträchtigt haben. Der Begriff „Regression“ bedeutet eine Rückkehr zu einem schlechteren Zustand — wenn eine Funktion, die in der vorherigen Version funktioniert hat, in der neuen Version nicht mehr funktioniert. Regressionstests werden in jedem Entwicklungszyklus wiederholt ausgeführt, was sie von Tests neuer Funktionen unterscheidet, die einmal geschrieben werden.

Die Notwendigkeit von Regressionstests ergibt sich aus dem Effekt kaskadierender Änderungen: Die Behebung eines Fehlers in einem Modul kann das Problem lösen, aber die angrenzende Funktionalität beeinträchtigen, die davon abhängig war. Zum Beispiel kann die Änderung einer SQL-Abfrage im Benutzerrepository die Authentifizierung beschleunigen, aber den Datencxport beeinträchtigen, der dieselbe Abfrage verwendete. Ein Regressionstest für den Datencxport wird diese Verletzung vor der Veröffentlichung erkennen.

Laut dem CISQ 2023-Bericht sind die Kosten für die Behebung eines in der Produktion gefundenen Regressionsfehlers 15-mal höher als in der Phase des automatisierten Regressionstestlaufs. Unternehmen, die in automatisierte Regressionstests investieren, reduzieren den Anteil der Regressionsfehler in Veröffentlichungen innerhalb eines Jahres nach der Einführung von 25 % auf 5 %, laut dem Capgemini World Quality Report.

Arten von Regressionstests

Es gibt mehrere Ansätze für Regressionstests, die sich im Umfang und in den Testauswahlkriterien unterscheiden. Die Wahl des Ansatzes hängt von der Projektgröße, der Häufigkeit der Änderungen und der verfügbaren Zeit in der CI-Pipeline ab. Nachfolgend sind die wichtigsten Arten von Regressionstests mit ihren Merkmalen aufgeführt.

Vollständige Regressionstests

Der vollständige Regressionstestlauf führt ausnahmslos alle automatisierten Tests des Projekts aus. Dieser Ansatz bietet maximale Sicherheit, erfordert jedoch erhebliche Rechenressourcen und Zeit. Ein vollständiger Lauf wird vor größeren Veröffentlichungen durchgeführt — alle 2–4 Wochen. Bei einer Anwendung mit 5000 Tests dauert ein vollständiger Lauf je nach Infrastruktur 2 bis 6 Stunden.

Selektive Regressionstests

Der selektive Ansatz führt nur Tests aus, die mit den geänderten Modulen zusammenhängen. Zur Bestimmung der Zusammengehörigkeit wird eine Abhängigkeitsanalyse auf Codeebene verwendet: Wenn die Klasse UserRepository geändert wird, werden Tests ausgeführt, die direkt oder transitiv von UserRepository abhängen. Tools wie Jacoco, Android Test Coverage und Xcode Code Coverage bieten Abdeckungskarten für eine genaue Auswahl. Ein selektiver Lauf wird bei jedem Pull-Request durchgeführt und dauert 5–15 Minuten.

Risikobasierte Regression

Die risikobasierte Regression ordnet Tests nach Kritikalität der Funktionalität und Wahrscheinlichkeit eines Bruchs. Kritische Funktionen — Zahlungen, Authentifizierung, Synchronisierung — werden bei jeder Codeänderung getestet. Hilfsfunktionen — der „Über“-Bildschirm, Animationen — werden nur vor der Veröffentlichung getestet. Die Rangfolge wird vierteljährlich auf der Grundlage von Daten zu Produktionsausfällen überprüft.

Unterschied zwischen Regressionstests und Nachtest

Die Konzepte von Regressionstests und Nachtest werden oft verwechselt, obwohl es sich um unterschiedliche Prozesse handelt. Der Nachtest ist eine erneute Ausführung eines bestimmten Tests, der zuvor fehlgeschlagen ist, nach der Behebung des Fehlers. Der Zweck des Nachtests besteht darin, zu bestätigen, dass die Korrektur funktioniert: Der Fehler tritt nicht mehr auf. Der Nachtest wird einmal durchgeführt, unmittelbar nach der Korrektur und der Bestätigung der Korrektur durch den Entwickler.

Regressionstests sind die Ausführung von Tests für vorhandene Funktionalität, die NICHT geändert wurde. Das Ziel ist sicherzustellen, dass die Behebung eines Fehlers keinen neuen Fehler an anderer Stelle verursacht hat. Regressionstests werden in jedem Entwicklungszyklus wiederholt ausgeführt, unabhängig davon, welche spezifischen Fehler behoben wurden. Der Hauptunterschied: Der Nachtest überprüft die Korrektur selbst, die Regression überprüft die Folgen der Korrektur.

In einer CI/CD-Pipeline werden beide Prozesse nacheinander ausgeführt. Nach dem Zusammenführen eines Pull-Requests wird ein Nachtest des spezifischen Fehlers durchgeführt, gefolgt von einem vollständigen oder selektiven Regressionstestlauf. Laut SmartBear (2022) verkürzt die Trennung dieser Prozesse die Diagnosezeit fehlgeschlagener CI-Läufe um 30 %, da das Team sofort sieht, welche Fehler mit der Regression und welche mit nicht funktionierenden Korrekturen zusammenhängen.

Automatisierung von Regressionstests

Die Automatisierung von Regressionstests ist ein entscheidender Erfolgsfaktor für moderne Mobilprojekte. Manuelle Regressionstests sind nicht skalierbar: Bei einer Suite von 200 Tests erfordert ein Lauf 2–3 Arbeitstage eines QA-Ingenieurs, was tägliche Läufe unmöglich macht. Automatisierte Regressionstests laufen in 10–60 Minuten ohne menschliches Eingreifen und können bei jedem Commit oder Pull-Request ausgeführt werden.

• Komponententests — die Grundlage der Regressionssuite (70 %). Sie werden in Sekunden ausgeführt, benötigen keinen Emulator und geben eine genaue Angabe der beschädigten Klasse.
• Integrationstests — die zweite Ebene (20 %). Sie überprüfen die Netzwerkschicht, die Datenbank und die Systemdienste mit kontrollierten Abhängigkeiten.
• UI-Tests und E2E-Tests — die Spitze der Pyramide (10 %). Sie decken kritische Benutzerszenarien ab: Registrierung, Zahlung, Synchronisierung.

Um die Regressionssuite aktuell zu halten, wird Testanalytik verwendet: Tools wie Allure, ReportPortal und Xray verfolgen Bestehensquoten, Dauer und Stabilität jedes Tests. Tests, deren Stabilität unter 90 % fällt (häufig aufgrund von Anforderungsänderungen fehlschlagen), werden als Legacy markiert und dem Eigentümer zur Überprüfung zugewiesen.

Beispiel für die Einrichtung eines Regressionstests

Betrachten wir die Einrichtung eines automatisierten Regressionstests auf Android mit der Bibliothek JUnit 5 und Espresso. Das Beispiel zeigt die selektive Regression — der Test überprüft, ob nach der Refaktorisierung des Benutzerrepositories der Profilbildschirm nicht beschädigt wurde. Für iOS wird XCTest mit ähnlicher Logik verwendet — ein wiederholter Test für ein wichtiges Szenario.

Android: Regressionstest des Profils

Der Test verwendet MockWebServer zur Emulation des Servers und überprüft den vollständigen Pfad: Laden von Benutzerdaten, Anzeige auf dem Profilbildschirm und Fehlerbehandlung bei nicht verfügbarem Server. Solche Tests werden in die Regressionssuite aufgenommen und bei jeder Änderung im Modul-Profil ausgeführt.

@RunWith(AndroidJUnit4::class)
class ProfileRegressionTest {

    @get:Rule
    val composeRule = createComposeRule()

    @Test
    fun profileScreen_rendersCorrectly() {
        val user = User(id = 1, name = "Alice", email = "alice@test.com")
        composeRule.setContent {
            ProfileScreen(user)
        }
        composeRule.onNodeWithText("Alice").assertIsDisplayed()
        composeRule.onNodeWithText("alice@test.com").assertIsDisplayed()
    }

    @Test
    fun profileScreen_handlesNetworkError() {
        setNetworkError()
        composeRule.onNodeWithText("Ladefehler").assertIsDisplayed()
    }
}

iOS: Regressionstest mit XCTest

Für iOS verwendet der Regressionstest XCTestExpectation zur asynchronen Überprüfung der UI-Aktualisierung nach dem Empfang von Daten von der API. Der Test emuliert eine Netzwerkantwort und überprüft, ob die UI-Elemente korrekt aktualisiert wurden.

class ProfileRegressionTests: XCTestCase {
    func testProfileScreen_rendersCorrectly() {
        let viewModel = ProfileViewModel(userId: 1)
        let view = ProfileView(viewModel: viewModel)
        viewModel.loadProfile()

        let expectation = expectation(description: "profile loaded")
        viewModel.onProfileLoaded = {
            XCTAssertEqual(viewModel.userName, "Alice")
            XCTAssertEqual(viewModel.userEmail, "alice@test.com")
            expectation.fulfill()
        }
        waitForExpectations(timeout: 3.0)
    }
}

Strategie zum Aufbau einer Regressionssuite

Der Aufbau einer effektiven Regressionssuite ist ein iterativer Prozess, der auf Fehler- und Codeänderungsdaten basiert. Die anfängliche Strategie besteht darin, alle vorhandenen Tests in die Regressionssuite aufzunehmen und vor jeder Veröffentlichung einen vollständigen Lauf durchzuführen. Mit dem Wachstum der Testbasis (über 2000 Tests) wird ein vollständiger Lauf zu lang und ein selektiver Ansatz ist erforderlich.

Die zweite Phase — Einführung von Abhängigkeitsanalyse-Tools: Jacoco für Android, Xcode Test Plan für iOS. Diese Tools erstellen eine „Test — Klasse — Methode“-Karte und ermöglichen die Bestimmung, welche Tests von einer bestimmten Änderung betroffen sind. Ein selektiver Lauf basierend auf der Abdeckungsanalyse reduziert die Ausführungszeit um 60–80 % bei gleichbleibender 95%iger Effektivität der Regressionserkennung, laut Spotify Engineering (2022).

Die dritte Phase — kontinuierliche Überwachung und Optimierung. Tests, die in 6 Monaten nicht fehlgeschlagen sind, werden in eine Suite mit niedriger Priorität verschoben. Tests, die mehr als einmal im Monat fehlschlagen, sind Kandidaten für eine Überprüfung: Entweder erfassen sie echte Probleme (benötigen eine Korrektur) oder sie sind zu anfällig (erfordern eine Stabilisierung). Eine vierteljährliche Überprüfung der Regressionssuite ist eine Standardpraxis, um ihre Effektivität und Ausführungsgeschwindigkeit zu erhalten.