UI-tesztelés mobilalkalmazásokban: mi ez, típusai és hogyan történik

Mi az UI-tesztelés?

UI-tesztelés az automatizált ellenőrzés egy olyan fajtája, ahol a tesztkód pontosan úgy lép kölcsönhatásba az alkalmazás grafikus interfészével, ahogyan egy valódi felhasználó tenné. A teszt megtalálja a képernyőn az elemet — gombot, szövegmezőt, listát — végrehajt rajta egy műveletet és ellenőrzi a felület várt reakcióját. Például, hibás jelszó megadása után az UI-teszt ellenőrzi, hogy megjelent-e a képernyőn a hibaüzenet a megfelelő szöveggel.

Az UI-tesztek és az automatizálás más típusai közötti fő különbség, hogy azok az operációs rendszer Accessibility rétegen keresztül működnek, nem az alkalmazás belső API-ján keresztül. Ez azt jelenti, hogy az UI-tesztek pontosan úgy látják a felületet, mint a felhasználó és a képernyőolvasó rendszer. Ennek köszönhetően az UI-tesztek nemcsak a funkcionalitást, hanem az elemek akadálymentességét is ellenőrzik — a WCAG követelményeknek való megfelelést.

A JetBrains Developer Ecosystem 2023 felmérése szerint a mobil csapatok 58%-a használ UI-teszteket a CI/CD csœvezetékében. Az UI-tesztekkel való átlagos lefedettség a kereskedelmi projektekben az alkalmazás képernyőinek 30–40%-a. Az UI-tesztekkel rendelkező projektek 25%-kal kevesebb negatív értékelést kapnak az alkalmazásáruházakban a felületi összeomlásokkal kapcsolatban.

Miben különbözik az UI-tesztelés az egységtesztektől

Az UI-tesztek és az egységtesztek közötti fő különbség az absztrakciós szint. Egységtesztek egyedi osztályokkal és függvényekkel dolgoznak, elkülönítve az Android vagy iOS keretrendszertől. A JVM-en (Android esetén) futnak az emulator elindítása nélkül, és ezredmásodpercekig tartanak. Az UI-tesztek valódi eszközön vagy emulatoron futnak, kölcsönhatásba lépnek a rendszerszolgáltatásokkal, és másodperceket vagy perceket igényelnek egy forgatókönyvre.

A tesztek célközönsége is eltér. UI-tesztek végfelhasználói forgatókönyveket ellenőriznek — regisztráció, rendelés leadása, keresés. Az egységtesztek az üzleti logikát fedik le: számítások, érvényesítés, adatátalakítás. Az UI-teszt nem ellenőrzi az adószámítás helyességét — azt ellenőrzi, hogy a végösszeg megjelenik-e a képernyőn. Magát a számítást az egységteszt ellenőrzi.

A Google Testing Blog (2020) szerint a projektekben a tesztek optimális arányának a tesztpiramis szabályát kell követnie: 70% egységteszt, 20% integrációs teszt és 10% UI-teszt. Ennek az aránynak az UI-tesztek javára történő megsértése a végrehajtási idő növekedéséhez és a tesztkészlet törékenységéhez vezet, mivel az UI-tesztek érzékenyek a képernyőelrendezés változásaira.

Keretrendszerek UI-teszteléshez

Android esetén a domináns keretrendszer az Espresso — egy Google könyvtár, amely az AndroidX Test része. Az Espresso automatikusan szinkronizálódik az UI-szállal, megvárva az animációk és háttérfeladatok befejeződését a következő ellenőrzés előtt. A Jetpack Compose-hoz a Compose UI Test kiterjesztést használják, amely a hagyományos nézetazonosítók helyett szemantikai csomópontokon keresztül működik.

iOS esetén a fő eszköz az Xcode részét képező XCUITest. A teszteket Swift nyelven írják és Accessibility-azonosítókat használnak az elemek megtalálásához. Az XCUITest támogatja a tesztek rögzítését a record funkción keresztül és a CI-rendszerekkel való integrációt az xcodebuild segítségével. Platformfüggetlen projektekhez a WebDriver protokollon alapuló Appium-ot használják, amely minimális kódmódosítással teszi lehetővé ugyanazon tesztek futtatását Androidon és iOS-en.

Espresso és Compose UI Test

Espresso a hagyományos View rendszerrel dolgozik az onView és erőforrás-azonosítók segítségével. A Compose UI Test egy szemantikai réteget használ, ami kevésbé teszi a teszteket a nézethierarchiától függővé. Például, egy gomb keresése Espressoban: onView(withId(R.id.submit)), Compose-ban: onNodeWithTag(„submit”). A Compose-tesztek automatikusan kezelik a rekompozíciót és nem igényelnek explicit várakozást az inaktív állapotra.

XCUITest iOS-re

XCUITest az XCUIApplication-t használja belépési pontként. Minden felületi elem Accessibility tulajdonságokon keresztül kereshető: accessibilityIdentifier programozott hozzáféréshez és accessibilityLabel a VoiceOver-hez. A keretrendszer támogatja a tesztek rögzítését az Xcode record funkcióján keresztül — a fejlesztő műveleteket végez a szimulátoron, az Xcode pedig létrehozza a tesztkódot. A kész tesztek az xcodebuild test segítségével futtathatók.

Platformfüggetlen megoldások

Appium a WebDriver protokollon alapul és bármely nyelvet támogat: Java, Python, JavaScript. Az elemek kereséséhez az id, xpath, class name és accessibility id stratégiákat használják. Az Appium szerver telepítést és Desired Capabilities — platformName, deviceName, appPackage konfigurálást igényel. Alternatíva a Maestro, amely YAML-forgatókönyveket használ és nem igényel tesztkód fordítást.

• Espresso — onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed()))
• XCUITest — app.buttons[„loginButton”].tap(); XCTAssertTrue(app.staticTexts[„welcome”].exists)
• Appium — driver.findElement(By.id(„com.example:id/button”)).click()
• Detox — a Wix keretrendszere React Native-hoz, amely szinkronizálódik a JS-szállal
• Maestro — modern eszköz YAML-forgatókönyvekkel, nem igényel kódírást

Kódpéldák UI-tesztekhez

Nézzük meg az UI-teszteket ugyanarra a forgatókönyvre — bejelentkezés az alkalmazásba — három különböző keretrendszerben: Espresso Androidra, XCUITest iOS-re és Appium a platformfüggetlen megközelítéshez. Forgatókönyv: adja meg a felhasználónevet és jelszót, nyomja meg a bejelentkezés gombot, ellenőrizze az üdvözlő üzenet megjelenését.

Android: Espresso

A teszt Espressoban az onView-t használja az elem azonosítóval történő megkereséséhez és a perform-t a művelet végrehajtásához. A check metódus az isDisplayed illesztővel megerősíti, hogy az elem látható a képernyőn.

@RunWith(AndroidJUnit4::class)
class LoginUiTest {

    @Rule
    @JvmField
    val composeTestRule = createComposeRule()

    @Test
    fun login_withValidCredentials_showsWelcome() {
        composeTestRule
            .onNodeWithTag("emailField")
            .performTextInput("user@example.com")
        composeTestRule
            .onNodeWithTag("passwordField")
            .performTextInput("secret123")
        composeTestRule
            .onNodeWithTag("loginButton")
            .performClick()
        composeTestRule
            .onNodeWithText("Üdvözöljük, Felhasználó!")
            .assertIsDisplayed()
    }
}

iOS: XCUITest

XCUITest az XCUIApplication-t használja a felületi elemek eléréséhez Accessibility-azonosítókon keresztül. A tap() és exists metódusok biztosítják az interakciót és ellenőrzést.

class LoginUITests: XCTestCase {
    let app = XCUIApplication()

    override func setUp() {
        continueAfterFailure = false
        app.launch()
    }

    func testLogin_withValidCredentials_showsWelcome() {
        app.textFields["emailField"].tap()
        app.textFields["emailField"].typeText("user@example.com")
        app.secureTextFields["passwordField"].tap()
        app.secureTextFields["passwordField"].typeText("titok123")
        app.buttons["loginButton"].tap()
        XCTAssertTrue(app.staticTexts["Welcome, User!"].exists)
    }
}

UI-tesztelés legjobb gyakorlatai

Első elv — használjon Accessibility-azonosítókat a szöveges címkék helyett az elemek megtalálásához. A gomb szövege megváltozhat lokalizáció során, míg az azonosító stabil marad. Androidon ez a contentDescription tulajdonság, iOS-en az accessibilityIdentifier. Ez a megközelítés függetlenné teszi a teszteket a felület nyelvétől és csökkenti a karbantartási költségeket a copywriting változásakor.

Kerülje a sleep() és fix késleltetéseket — használja a keretrendszer beépített várakozási mechanizmusait. Az Espresso automatikusan megvárja az animációk és háttérfeladatok befejeződését. Az XCUITest timeout-tal ellátott XCTAssertTrue-t biztosít. Az explicit szünetek lelassítják a teszteket és kevésbé stabilá teszik azokat, különösen lassú eszközökön CI környezetben.

Csoportosítsa a teszteket kritikusság szerint: a smoke-teszteket (3–5 kulcsforgatókönyv) minden commitnál futtassa, a teljes UI-tesztkészletet — a kiadás előtt. A Google Testing Blog (2022) szerint azok az UI-tesztek, amelyek több mint 30 percet vesznek igénybe CI-ben, 40%-kal csökkentik a futtatások gyakoriságát, ami csökkenti a hatékonyságukat a regressziók korai felismerésének eszközeként.

Az UI-tesztek korlátai és hogyan kerülhetők el

Az UI-tesztek számos korláttal rendelkeznek. Érzékenység az elrendezés változásaira: az azonosító, hierarchia vagy elemtípus megváltozása még változatlan funkcionalitás mellett is töri a tesztet. Megoldás — a Page Object minta használata, amely az elemválasztókat külön osztályokba centralizálja. Elrendezésváltozáskor egy Page Object fájlt javítanak, nem tucatnyi tesztet.

Végrehajtási idő: valódi eszközön vagy emulatoron történő futtatás 10–50-szer több ideig tart, mint egy egységteszt. Megoldás — az UI-tesztek párhuzamos futtatása több eszközön a Firebase Test Lab vagy AWS Device Farm segítségével. Instabilitás (flakiness) — a CI-futtatások gyakori problémája, amelyet animációk, hálózati késleltetések vagy az emulator állapota okoz. A flakiness elleni küzdelemhez a sikertelen tesztek automatikus újraindítását és az egyes tesztforgatókönyvek stabilitási analitikáját alkalmazzák.