Regressziós tesztelés mobilfejlesztésben — mi ez, típusai és hogyan történik

Mi a regressziós tesztelés?

A regressziós tesztelés a tesztelés egy olyan fajtája, amelynek célja annak megerősítése, hogy a kódváltoztatások nem érintették a meglévő funkciókat. A „regresszió” kifejezés rosszabb állapotba való visszatérést jelent — amikor egy előző verzióban működő funkció az új verzióban már nem működik. A regressziós tesztek minden fejlesztési ciklusban többször futnak, ami megkülönbözteti őket az egyszer írt új funkciós tesztektől.

A regressziós tesztelés szükségessége a lépcsőzetes változtatások hatásából fakad: egy modul hibájának javítása megoldhatja a problémát, de tönkreteheti a szomszédos funkciót, amely attól függött. Például egy SQL-lekérdezés módosítása a felhasználói adattárban felgyorsíthatja a bejelentkezést, de tönkreteheti az adatexportálást, amely ugyanazt a lekérdezést használta. Az adatexportálásra vonatkozó regressziós teszt észleli ezt a problémát a kiadás előtt.

A CISQ 2023 jelentése szerint a termelésben felfedezett regressziós hiba javításának költsége 15-ször magasabb, mint az automatizált regressziós futtatás szakaszában. Az automatizált regressziós tesztelésbe befektető vállalatok a Capgemini World Quality Report szerint a regressziós hibák arányát a kiadásokban 25%-ról 5%-ra csökkentik a bevezetés után egy éven belül.

A regressziós tesztelés típusai

Több megközelítés létezik a regressziós tesztelésre, amelyek a tesztek mennyiségében és kiválasztási kritériumaiban különböznek. A megközelítés kiválasztása a projekt méretétől, a változtatások gyakoriságától és a CI-csővezetékben rendelkezésre álló időtől függ. Az alábbiakban a regressziós tesztelés fő típusai találhatók jellemzőikkel.

Teljes regressziós tesztelés

A teljes regressziós futtatás a projekt összes automatizált tesztjét végrehajtja kivétel nélkül. Ez a megközelítés maximális biztonságot nyújt, de jelentős számítási erőforrásokat és időt igényel. A teljes futtatás nagy kiadások előtt történik — 2–4 hetente egyszer. Egy 5000 teszttel rendelkező alkalmazásnál a teljes futtatás az infrastruktúrától függően 2–6 óráig tart.

Szelektív regressziós tesztelés

A szelektív megközelítés csak a módosított modulokhoz kapcsolódó teszteket futtatja. A kapcsolódás meghatározásához függőségelemzést használnak kód szinten: ha az UserRepository osztály módosításra került, az UserRepository-tól közvetlenül vagy tranzitíven függő tesztek futnak. A Jacoco, Android Test Coverage és Xcode Code Coverage eszközök lefedettségi térképeket biztosítanak a pontos kiválasztáshoz. A szelektív futtatás minden pull requestnél megtörténik és 5–15 percig tart.

Kockázatalapú regresszió

A kockázatalapú regresszió a teszteket a funkciók kritikussága és a meghibásodás valószínűsége szerint rangsorolja. A kritikus funkciók — fizetés, hitelesítés, szinkronizálás — minden kódváltoztatásnál tesztelésre kerülnek. A segédfunkciók — „Az alkalmazásról” képernyő, animációk — csak a kiadás előtt kerülnek tesztelésre. A rangsorolást negyedévente felülvizsgálják a termelési incidensek adatai alapján.

Miben különbözik a regressziós tesztelés az újrateszteléstől

A regressziós tesztelés és az újratesztelés fogalmát gyakran összekeverik, bár különböző folyamatokról van szó. Az újratesztelés egy korábban sikertelen teszt újbóli futtatása a hiba kijavítása után. Az újratesztelés célja annak ellenőrzése, hogy a javítás működik: a hiba már nem reprodukálható. Az újratesztelés egyszer történik, közvetlenül a javítás és a fejlesztő általi megerősítés után.

A regressziós tesztelés a NEM módosított meglévő funkciók tesztjeinek futtatása. A cél annak ellenőrzése, hogy egy hiba kijavítása nem hozott létre új hibát máshol. A regressziós tesztek minden fejlesztési ciklusban többször futnak, függetlenül attól, hogy pontosan milyen hibákat javítottak. A fő különbség: az újratesztelés magát a javítást ellenőrzi, a regresszió a javítás következményeit ellenőrzi.

A CI/CD csővezetékben mindkét folyamat egymás után zajlik. A pull request egyesítése után a konkrét hiba újratesztelése indul, majd a teljes vagy szelektív regressziós futtatás. A SmartBear (2022) szerint e folyamatok szétválasztása 30%-kal csökkenti a sikertelen CI-futtatások diagnosztizálási idejét, mivel a csapat azonnal látja, hogy a hibák mely része kapcsolódik a regresszióhoz és mely a nem működő javításokhoz.

A regressziós tesztelés automatizálása

A regressziós tesztelés automatizálása kritikus sikerfaktor a modern mobil projektek számára. A kézi regressziós tesztelés nem skálázható: 200 tesztből álló készlet esetén egy futtatáshoz 2–3 munkanapra van szükség egy QA-mérnöktől, ami lehetetlenné teszi a napi futtatásokat. Az automatizált regressziós tesztek 10–60 perc alatt futnak le emberi beavatkozás nélkül, lehetővé téve indításukat minden commitnál vagy pull requestnél.

• Egységtesztek — a regressziós készlet alapja (70%). Másodpercek alatt futnak, nem igényelnek emulátort, pontosan jelzik a törött osztályt.
• Integrációs tesztek — a második szint (20%). Ellenőrzik a hálózati réteget, adatbázist és rendszerszolgáltatásokat ellenőrzött függőségekkel.
• UI és E2E tesztek — a piramis csúcsa (10%). Lefedik a kritikus felhasználói forgatókönyveket: regisztráció, fizetés, szinkronizálás.

A regressziós készlet naprakész állapotban tartásához tesztanalitikát használnak: az Allure, ReportPortal és Xray eszközök nyomon követik minden teszt áthaladási százalékát, időtartamát és stabilitását. Azok a tesztek, amelyek stabilitása 90% alá csökken (gyakran elromlanak a követelmények változásai miatt), örököltként lesznek megjelölve és felülvizsgálatra küldve a tulajdonosnak.

Példa regressziós teszt konfigurálására

Tekintsük meg egy automatizált regressziós teszt konfigurálását Androidon a JUnit 5 könyvtár és Espresso használatával. A példa szelektív regressziót mutat be — a teszt ellenőrzi, hogy a felhasználói adattár refaktorálása után a profilképernyő nem romlott el. iOS esetén az XCTest hasonló logikával működik — ismétlődő teszt a kulcsfontosságú forgatókönyvre.

Android: profil regressziós teszt

A teszt a MockWebServer-t használja a szerver emulálásához és a teljes utat ellenőrzi: felhasználói adatok betöltése, megjelenítés a profilképernyőn és hiba kezelése, ha a szerver nem elérhető. Az ilyen tesztek bekerülnek a regressziós készletbe és minden module-profile módosításnál futnak.

@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("Betöltési hiba").assertIsDisplayed()
    }
}

iOS: regressziós teszt XCTest-tel

iOS esetén a regressziós teszt a XCTestExpectation-t használja az UI aszinkron frissülésének ellenőrzésére az API-tól kapott adatok után. A teszt hálózati választ emulál és ellenőrzi, hogy az UI elemek helyesen frissültek-e.

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

A regressziós készlet felépítésének stratégiája

Egy hatékony regressziós készlet felépítése iteratív folyamat, amely a hibákról és kódváltoztatásokról szóló adatokon alapul. Az elsődleges stratégia az összes meglévő teszt bevonása a regressziós készletbe és a teljes futtatás elvégzése minden kiadás előtt. Ahogy a tesztbázis nő (2000 teszt felett), a teljes futtatás túl hosszúvá válik és szelektív megközelítésre van szükség.

A második fázis — függőségelemző eszközök bevezetése: Jacoco Androidhoz, Xcode Test Plan iOS-hez. Ezek az eszközök „teszt — osztály — metódus” térképet építenek és lehetővé teszik annak meghatározását, hogy mely teszteket érint egy adott változtatás. A lefedettségi elemzésen alapuló szelektív futtatás a végrehajtási időt 60–80%-kal csökkenti a regressziók észlelésének 95%-os hatékonyságának megtartása mellett, a Spotify Engineering (2022) szerint.

A harmadik fázis — folyamatos monitorozás és optimalizálás. Azok a tesztek, amelyek 6 hónapig nem hibásodtak meg, alacsony prioritású készletbe kerülnek. A havonta egynél többször meghibásodó tesztek felülvizsgálatra jelöltek: vagy valós problémákat fognak (javítást igényelnek), vagy túl törékenyek (stabilizálást igényelnek). A regressziós készlet negyedéves felülvizsgálata szokásos gyakorlat a hatékonyság és végrehajtási sebesség fenntartásához.