Testy regresyjne w rozwoju aplikacji mobilnych — co to jest, rodzaje i jak są przeprowadzane

Co to są testy regresyjne?

Testy regresyjne to rodzaj testowania mający na celu potwierdzenie, że zmiany w kodzie nie naruszyły istniejącej funkcjonalności. Termin „regresja” oznacza powrót do gorszego stanu — gdy funkcja działająca w poprzedniej wersji przestaje działać w nowej. Testy regresyjne są wykonywane wielokrotnie w każdym cyklu programistycznym, co odróżnia je od testów nowej funkcjonalności, które są pisane jednorazowo.

Konieczność testów regresyjnych wynika z efektu zmian kaskadowych: naprawa błędu w jednym module może rozwiązać problem, ale zepsuć sąsiednią funkcjonalność, która od niego zależała. Na przykład zmiana zapytania SQL w repozytorium użytkowników może przyspieszyć logowanie, ale zepsuć eksport danych, który używał tego samego zapytania. Test regresyjny eksportu danych wykryje to naruszenie przed wydaniem.

Według raportu CISQ 2023, koszt naprawy defektu regresyjnego wykrytego w produkcji jest 15 razy wyższy niż na etapie zautomatyzowanego przebiegu regresyjnego. Firmy inwestujące w zautomatyzowane testy regresyjne zmniejszają udział defektów regresyjnych w wydaniach z 25% do 5% w ciągu roku po wdrożeniu, według Capgemini World Quality Report.

Rodzaje testów regresyjnych

Istnieje kilka podejść do testów regresyjnych, różniących się zakresem i kryteriami doboru testów. Wybór podejścia zależy od rozmiaru projektu, częstotliwości zmian i dostępnego czasu w potoku CI. Poniżej przedstawiono główne rodzaje testów regresyjnych z ich charakterystykami.

Pełne testy regresyjne

Pełny przebieg regresyjny wykonuje wszystkie zautomatyzowane testy projektu bez wyjątku. Takie podejście daje maksymalną pewność, ale wymaga znacznych zasobów obliczeniowych i czasu. Pełny przebieg jest wykonywany przed dużymi wydaniami — raz na 2–4 tygodnie. Dla aplikacji z 5000 testów pełny przebieg zajmuje od 2 do 6 godzin w zależności od infrastruktury.

Wybiórcze testy regresyjne

Podejście wybiórcze uruchamia tylko testy związane ze zmienionymi modułami. Do określenia powiązań wykorzystuje się analizę zależności na poziomie kodu: jeśli zmieniono klasę UserRepository, uruchamiane są testy zależne od UserRepository bezpośrednio lub przechodnio. Narzędzia Jacoco, Android Test Coverage i Xcode Code Coverage dostarczają mapy pokrycia do precyzyjnego doboru. Wybiórczy przebieg jest wykonywany przy każdym pull request i zajmuje 5–15 minut.

Regresja oparta na ryzyku

Regresja oparta na ryzyku rankinguje testy według krytyczności funkcjonalności i prawdopodobieństwa awarii. Funkcje krytyczne — płatność, autoryzacja, synchronizacja — są testowane przy każdej zmianie kodu. Funkcje pomocnicze — ekran „O aplikacji”, animacje — są testowane tylko przed wydaniem. Ranking jest weryfikowany raz na kwartał na podstawie danych o incydentach produkcyjnych.

Czym testy regresyjne różnią się od retestu

Pojęcia testów regresyjnych i retestu są często mylone, choć to różne procesy. Retest to ponowne uruchomienie konkretnego testu, który wcześniej nie przeszedł, po naprawie defektu. Celem retestu jest upewnienie się, że naprawa działa: błąd nie jest już reprodukowany. Retest jest wykonywany jednorazowo, natychmiast po naprawie i potwierdzeniu naprawy przez programistę.

Testy regresyjne to uruchamianie testów istniejącej funkcjonalności, która NIE była zmieniana. Celem jest upewnienie się, że naprawa jednego defektu nie stworzyła nowego defektu w innym miejscu. Testy regresyjne są uruchamiane wielokrotnie w każdym cyklu programistycznym, niezależnie od tego, jakie konkretne błędy były naprawiane. Główna różnica: retest sprawdza samą naprawę, regresja sprawdza skutki naprawy.

W potoku CI/CD oba procesy są wykonywane sekwencyjnie. Po scaleniu pull request uruchamiany jest retest konkretnego błędu, a następnie pełny lub wybiórczy przebieg regresyjny. Według SmartBear (2022), rozdzielenie tych procesów skraca czas diagnozowania nieudanych przebiegów CI o 30%, ponieważ zespół od razu widzi, która część defektów jest związana z regresją, a która z niedziałającymi naprawami.

Automatyzacja testów regresyjnych

Automatyzacja testów regresyjnych to krytyczny czynnik sukcesu dla nowoczesnych projektów mobilnych. Ręczne testy regresyjne nie skalują się: przy zestawie 200 testów na jeden przebieg potrzeba 2–3 dni roboczych inżyniera QA, co uniemożliwia codzienne przebiegi. Zautomatyzowane testy regresyjne są wykonywane w 10–60 minut bez udziału człowieka, co pozwala uruchamiać je przy każdym commicie lub pull request.

• Testy jednostkowe — podstawa zestawu regresyjnego (70%). Wykonywane w sekundach, nie wymagają emulatora, precyzyjnie wskazują uszkodzoną klasę.
• Testy integracyjne — drugi poziom (20%). Sprawdzają warstwę sieciową, bazę danych i usługi systemowe z kontrolowanymi zależnościami.
• Testy UI i E2E — szczyt piramidy (10%). Pokrywają krytyczne scenariusze użytkownika: rejestrację, płatność, synchronizację.

Do utrzymania zestawu regresyjnego w aktualnym stanie wykorzystuje się analitykę testową: narzędzia takie jak Allure, ReportPortal i Xray śledzą wskaźniki przejścia, czas trwania i stabilność każdego testu. Testy, których stabilność spada poniżej 90% (często psują się z powodu zmian w wymaganiach), są oznaczane jako legacy i kierowane do przeglądu przez właściciela.

Przykład konfiguracji testu regresyjnego

Rozważmy konfigurację zautomatyzowanego testu regresyjnego na Androidzie z użyciem biblioteki JUnit 5 i Espresso. Przykład demonstruje wybiórczą regresję — test sprawdza, czy po refaktoryzacji repozytorium użytkowników nie zepsuł się ekran profilu. Dla iOS używany jest XCTest z analogiczną logiką — powtarzalny test kluczowego scenariusza.

Android: regresyjny test profilu

Test wykorzystuje MockWebServer do emulacji serwera i sprawdza pełną ścieżkę: pobieranie danych użytkownika, wyświetlanie na ekranie profilu oraz obsługę błędu przy niedostępnym serwerze. Takie testy są włączane do zestawu regresyjnego i wykonywane przy każdej zmianie w module-profile.

@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("Błąd ładowania").assertIsDisplayed()
    }
}

iOS: regresyjny test z XCTest

Dla iOS test regresyjny używa XCTestExpectation do asynchronicznego sprawdzania aktualizacji UI po otrzymaniu danych z API. Test emuluje odpowiedź sieciową i sprawdza, czy elementy UI zaktualizowały się poprawnie.

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)
    }
}

Strategia budowania zestawu regresyjnego

Budowanie efektywnego zestawu regresyjnego to iteracyjny proces oparty na danych o defektach i zmianach kodu. Strategia podstawowa polega na włączeniu do zestawu regresyjnego wszystkich istniejących testów i uruchamianiu pełnego przebiegu przed każdym wydaniem. W miarę wzrostu bazy testów (powyżej 2000 testów) pełny przebieg staje się zbyt długi i wymaga podejścia wybiórczego.

Druga faza — wdrożenie narzędzi analizy zależności: Jacoco dla Androida, Xcode Test Plan dla iOS. Narzędzia te budują mapę „test — klasa — metoda” i pozwalają określić, które testy są dotknięte konkretną zmianą. Wybiórczy przebieg oparty na analizie pokrycia skraca czas wykonania o 60–80% przy zachowaniu 95% skuteczności wykrywania regresji, według Spotify Engineering (2022).

Trzecia faza — ciągły monitoring i optymalizacja. Testy, które nie zawiodły przez 6 miesięcy, są przenoszone do zestawu niskopriorytetowego. Testy zawodzące częściej niż raz w miesiącu są kandydatami do przeglądu: albo wykrywają rzeczywiste problemy (wymagają naprawy), albo są zbyt kruche (wymagają stabilizacji). Kwartalna rewizja zestawu regresyjnego to standardowa praktyka utrzymania jego skuteczności i szybkości wykonania.