Regresní testování v mobilním vývoji — co to je, typy a jak se provádí

Co je regresní testování?

Regresní testování je typ testování zaměřený na potvrzení, že změny v kódu nenarušily stávající funkcionalitu. Termín „regrese” znamená návrat k horšímu stavu — když funkce, která fungovala v předchozí verzi, přestane fungovat v nové. Regresní testy se provádějí opakovaně v každém vývojovém cyklu, což je odlišuje od testů nové funkcionality, které se píší jednorázově.

Potřeba regresního testování vyplývá z efektu kaskádových změn: oprava chyby v jednom modulu může vyřešit problém, ale narušit sousední funkcionalitu, která na něm závisela. Například změna SQL dotazu v úložišti uživatelů může urychlit přihlášení, ale narušit export dat, který používal stejný dotaz. Regresní test exportu dat odhalí toto narušení před vydáním.

Podle zprávy CISQ 2023 jsou náklady na opravu regresního defektu odhaleného v produkci 15krát vyšší než ve fázi automatizovaného regresního běhu. Společnosti investující do automatizovaného regresního testování snižují podíl regresních defektů ve vydáních z 25 % na 5 % do jednoho roku po implementaci, podle Capgemini World Quality Report.

Typy regresního testování

Existuje několik přístupů k regresnímu testování, které se liší rozsahem a kritérii výběru testů. Výběr přístupu závisí na velikosti projektu, frekvenci změn a dostupném čase v CI pipeline. Níže jsou uvedeny hlavní typy regresního testování s jejich charakteristikami.

Úplné regresní testování

Úplný regresní běh provádí všechny automatizované testy projektu bez výjimky. Tento přístup poskytuje maximální jistotu, ale vyžaduje značné výpočetní zdroje a čas. Úplný běh se provádí před velkými vydáními — jednou za 2–4 týdny. Pro aplikaci s 5000 testy trvá úplný běh 2 až 6 hodin v závislosti na infrastruktuře.

Selektivní regresní testování

Selektivní přístup spouští pouze testy související se změněnými moduly. Pro určení souvislosti se používá analýza závislostí na úrovni kódu: pokud byla změněna třída UserRepository, spouštějí se testy závislé na UserRepository přímo nebo tranzitivně. Nástroje Jacoco, Android Test Coverage a Xcode Code Coverage poskytují mapy pokrytí pro přesný výběr. Selektivní běh se provádí při každém pull request a trvá 5–15 minut.

Regrese založená na riziku

Risk-based regrese řadí testy podle kritičnosti funkcionality a pravděpodobnosti rozbití. Kritické funkce — platba, autorizace, synchronizace — jsou testovány při každé změně kódu. Pomocné funkce — obrazovka „O aplikaci”, animace — jsou testovány pouze před vydáním. Pořadí je přezkoumáváno čtvrtletně na základě údajů o produkčních incidentech.

Jak se regresní testování liší od retestu

Pojmy regresního testování a retestu jsou často zaměňovány, i když jde o odlišné procesy. Retest je opětovné spuštění konkrétního testu, který dříve selhal, po opravě defektu. Cílem retestu je ujistit se, že oprava funguje: chyba se již nereprodukuje. Retest se provádí jednorázově, ihned po opravě a potvrzení opravy vývojářem.

Regresní testování je spouštění testů na stávající funkcionalitu, která NEBYLA změněna. Cílem je ujistit se, že oprava jednoho defektu nevytvořila nový defekt na jiném místě. Regresní testy se spouštějí opakovaně v každém vývojovém cyklu, bez ohledu na to, jaké konkrétní chyby byly opravovány. Hlavní rozdíl: retest kontroluje samotnou opravu, regrese kontroluje důsledky opravy.

V CI/CD pipeline se oba procesy provádějí sekvenčně. Po sloučení pull request se spustí retest konkrétní chyby a poté úplný nebo selektivní regresní běh. Podle SmartBear (2022) zkracuje oddělení těchto procesů dobu diagnostiky neúspěšných CI běhů o 30 %, protože tým okamžitě vidí, která část defektů souvisí s regresí a která s nefunkčními opravami.

Automatizace regresního testování

Automatizace regresního testování je kritickým faktorem úspěchu pro moderní mobilní projekty. Ruční regresní testování není škálovatelné: při sadě 200 testů vyžaduje jeden běh 2–3 pracovní dny QA inženýra, což znemožňuje každodenní běhy. Automatizované regresní testy se provádějí za 10–60 minut bez lidského zásahu, což umožňuje jejich spouštění při každém commitu nebo pull request.

• Unit testy — základ regresní sady (70 %). Provádějí se v sekundách, nevyžadují emulátor, přesně ukazují na rozbitou třídu.
• Integrační testy — druhá úroveň (20 %). Kontrolují síťovou vrstvu, databázi a systémové služby s řízenými závislostmi.
• UI a E2E testy — vrchol pyramidy (10 %). Pokrývají kritické uživatelské scénáře: registraci, platbu, synchronizaci.

Pro udržování regresní sady v aktuálním stavu se používá testovací analytika: nástroje jako Allure, ReportPortal a Xray sledují procenta úspěšnosti, dobu trvání a stabilitu každého testu. Testy, jejichž stabilita klesne pod 90 % (často se rozbijí kvůli změnám v požadavcích), jsou označeny jako legacy a odeslány k přezkoumání vlastníkovi.

Příklad konfigurace regresního testu

Podívejme se na konfiguraci automatizovaného regresního testu na Androidu s použitím knihovny JUnit 5 a Espresso. Příklad demonstruje selektivní regresi — test kontroluje, že po refaktoringu úložiště uživatelů nebyla rozbita obrazovka profilu. Pro iOS se používá XCTest s analogickou logikou — opakující se test klíčového scénáře.

Android: regresní test profilu

Test používá MockWebServer pro emulaci serveru a kontroluje celou cestu: načtení dat uživatele, zobrazení na obrazovce profilu a zpracování chyby při nedostupném serveru. Takové testy jsou zahrnuty do regresní sady a provádějí se při každé změně v 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("Chyba načítání").assertIsDisplayed()
    }
}

iOS: regresní test s XCTest

Pro iOS používá regresní test XCTestExpectation pro asynchronní kontrolu aktualizace UI po obdržení dat z API. Test emuluje síťovou odpověď a kontroluje, zda se prvky UI správně aktualizovaly.

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 budování regresní sady

Budování efektivní regresní sady je iterativní proces založený na datech o defektech a změnách kódu. Primární strategie je zahrnout všechny existující testy do regresní sady a spouštět úplný běh před každým vydáním. S růstem testovací základny (nad 2000 testů) se úplný běh stává příliš dlouhým a je vyžadován selektivní přístup.

Druhá fáze — zavedení nástrojů pro analýzu závislostí: Jacoco pro Android, Xcode Test Plan pro iOS. Tyto nástroje vytvářejí mapu „test — třída — metoda” a umožňují určit, které testy jsou ovlivněny konkrétní změnou. Selektivní běh založený na analýze pokrytí zkracuje dobu provádění o 60–80 % při zachování 95% účinnosti detekce regresí, podle Spotify Engineering (2022).

Třetí fáze — nepřetržitý monitoring a optimalizace. Testy, které neselhaly po dobu 6 měsíců, jsou přesunuty do nízko-prioritní sady. Testy selhávající častěji než jednou měsíčně jsou kandidáty na přezkoumání: buď zachycují skutečné problémy (vyžadují opravu), nebo jsou příliš křehké (vyžadují stabilizaci). Čtvrtletní revize regresní sady je standardní praxí pro udržení její účinnosti a rychlosti provádění.