Testarea de regresie în dezvoltarea aplicațiilor mobile — ce este, tipuri și cum se efectuează

Ce este testarea de regresie?

Testarea de regresie este un tip de testare menit să confirme că modificările din cod nu au afectat funcționalitatea existentă. Termenul „regresie” înseamnă revenirea la o stare mai proastă — atunci când o funcție care funcționa în versiunea anterioară încetează să mai funcționeze în cea nouă. Testele de regresie se execută de mai multe ori în fiecare ciclu de dezvoltare, ceea ce le diferențiază de testele funcționalităților noi, care sunt scrise o singură dată.

Necesitatea testării de regresie decurge din efectul modificărilor în cascadă: remedierea unei erori într-un modul poate rezolva problema, dar poate strica funcționalitatea adiacentă care depindea de acesta. De exemplu, modificarea unei interogări SQL în depozitul de utilizatori poate accelera autentificarea, dar poate strica exportul de date care folosea aceeași interogare. Un test de regresie pentru exportul de date va detecta această încălcare înainte de lansare.

Conform raportului CISQ 2023, costul remedierii unui defect de regresie detectat în producție este de 15 ori mai mare decât în etapa de rulare automatizată de regresie. Companiile care investesc în testarea automatizată de regresie reduc ponderea defectelor de regresie în lansări de la 25% la 5% în decurs de un an de la implementare, conform Capgemini World Quality Report.

Tipuri de testare de regresie

Există mai multe abordări ale testării de regresie, care diferă prin volum și criterii de selecție a testelor. Alegerea abordării depinde de dimensiunea proiectului, frecvența modificărilor și timpul disponibil în pipeline-ul CI. Mai jos sunt prezentate principalele tipuri de testare de regresie cu caracteristicile lor.

Testarea completă de regresie

Rularea completă de regresie execută toate testele automatizate ale proiectului fără excepție. Această abordare oferă încredere maximă, dar necesită resurse de calcul și timp semnificative. Rularea completă se efectuează înaintea lansărilor majore — o dată la 2–4 săptămâni. Pentru o aplicație cu 5000 de teste, o rulare completă durează între 2 și 6 ore, în funcție de infrastructură.

Testarea selectivă de regresie

Abordarea selectivă lansează doar testele legate de modulele modificate. Pentru determinarea conexiunilor se utilizează analiza dependențelor la nivel de cod: dacă clasa UserRepository a fost modificată, se lansează testele care depind de UserRepository direct sau tranzitiv. Instrumentele Jacoco, Android Test Coverage și Xcode Code Coverage oferă hărți de acoperire pentru selecție precisă. Rularea selectivă se efectuează la fiecare pull request și durează 5–15 minute.

Regresia bazată pe risc

Regresia bazată pe risc clasifică testele după criticitatea funcționalității și probabilitatea de defecțiune. Funcțiile critice — plată, autorizare, sincronizare — sunt testate la fiecare modificare de cod. Funcțiile auxiliare — ecranul „Despre aplicație”, animații — sunt testate doar înainte de lansare. Clasificarea este revizuită trimestrial pe baza datelor despre incidentele de producție.

Cum diferă testarea de regresie de retestare

Adesea conceptele de testare de regresie și retestare sunt confundate, deși sunt procese diferite. Retestarea este rularea repetată a unui test specific care a eșuat anterior, după remedierea defectului. Scopul retestării este de a se asigura că remedierea funcționează: eroarea nu se mai reproduce. Retestarea se efectuează o singură dată, imediat după remediere și confirmarea remedierii de către dezvoltator.

Testarea de regresie este rularea testelor asupra funcționalității existente care NU a fost modificată. Scopul este de a se asigura că remedierea unui defect nu a creat un nou defect în altă parte. Testele de regresie se execută de mai multe ori în fiecare ciclu de dezvoltare, indiferent de ce erori specifice au fost remediate. Diferența principală: retestarea verifică remedierea în sine, regresia verifică consecințele remedierii.

În pipeline-ul CI/CD, ambele procese se execută secvențial. După îmbinarea pull request-ului, se lansează retestarea erorii specifice, apoi rularea completă sau selectivă de regresie. Potrivit SmartBear (2022), separarea acestor procese reduce timpul de diagnosticare a rulărilor CI eșuate cu 30%, deoarece echipa vede imediat ce parte a defectelor este legată de regresie și ce parte de remedieri nefuncționale.

Automatizarea testării de regresie

Automatizarea testării de regresie este un factor critic de succes pentru proiectele mobile moderne. Testarea manuală de regresie nu se scalează: pentru un set de 200 de teste, o singură rulare necesită 2–3 zile lucrătoare ale unui inginer QA, ceea ce face imposibile rulările zilnice. Testele de regresie automatizate se execută în 10–60 de minute fără intervenție umană, permițând lansarea lor la fiecare commit sau pull request.

• Teste unitare — baza setului de regresie (70%). Se execută în câteva secunde, nu necesită emulator, indică precis clasa defectă.
• Teste de integrare — al doilea nivel (20%). Verifică stratul de rețea, baza de date și serviciile de sistem cu dependențe controlate.
• Teste UI și E2E — vârful piramidei (10%). Acoperă scenarii critice de utilizator: înregistrare, plată, sincronizare.

Pentru menținerea setului de regresie în stare actualizată se utilizează analitica testelor: instrumente precum Allure, ReportPortal și Xray urmăresc procentele de promovare, durata și stabilitatea fiecărui test. Testele a căror stabilitate scade sub 90% (se strică frecvent din cauza modificărilor în cerințe) sunt marcate ca legacy și trimise spre revizuire proprietarului.

Exemplu de configurare a testului de regresie

Să analizăm configurarea unui test de regresie automatizat pe Android utilizând biblioteca JUnit 5 și Espresso. Exemplul demonstrează regresia selectivă — testul verifică că după refactorizarea depozitului de utilizatori, ecranul de profil nu s-a stricat. Pentru iOS se utilizează XCTest cu o logică similară — un test repetat asupra scenariului cheie.

Android: test de regresie a profilului

Testul utilizează MockWebServer pentru emularea serverului și verifică calea completă: încărcarea datelor utilizatorului, afișarea pe ecranul de profil și gestionarea erorii atunci când serverul este indisponibil. Astfel de teste sunt incluse în setul de regresie și se execută la fiecare modificare în 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("Eroare de încărcare").assertIsDisplayed()
    }
}

iOS: test de regresie cu XCTest

Pentru iOS, testul de regresie utilizează XCTestExpectation pentru verificarea asincronă a actualizării UI după primirea datelor de la API. Testul emulează răspunsul rețelei și verifică că elementele UI s-au actualizat corect.

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 de construire a setului de regresie

Construirea unui set de regresie eficient este un proces iterativ bazat pe date despre defecte și modificări de cod. Strategia primară constă în includerea tuturor testelor existente în setul de regresie și rularea completă înainte de fiecare lansare. Pe măsură ce baza de teste crește (peste 2000 de teste), rularea completă devine prea lungă și este necesară o abordare selectivă.

A doua fază — implementarea instrumentelor de analiză a dependențelor: Jacoco pentru Android, Xcode Test Plan pentru iOS. Aceste instrumente construiesc o hartă „test — clasă — metodă” și permit determinarea testelor afectate de o anumită modificare. Rularea selectivă bazată pe analiza acoperirii reduce timpul de execuție cu 60–80%, păstrând 95% din eficacitatea detectării regresiilor, conform Spotify Engineering (2022).

A treia fază — monitorizare continuă și optimizare. Testele care nu au eșuat timp de 6 luni sunt mutate într-un set cu prioritate scăzută. Testele care eșuează mai des de o dată pe lună sunt candidate pentru revizuire: fie detectează probleme reale (necesită remediere), fie sunt prea fragile (necesită stabilizare). Revizuirea trimestrială a setului de regresie este o practică standard pentru menținerea eficacității și vitezei sale de execuție.