Narzędzia do automatyzacji testów aplikacji mobilnych: Appium, Espresso, XCUITest, Maestro, Detox i jak wybrać

Czas czytania: około 13 minut

Aplikacja ma działać na kilkuset modelach telefonów, kilku wersjach Androida i iOS, w trybie ciemnym i jasnym, z uprawnieniami i bez, przy słabej sieci i offline. Zespół, który sprawdza to ręcznie przed każdym wydaniem, ma dwie opcje: wydawać rzadko albo sprawdzać mało. Narzędzia do automatyzacji testów aplikacji mobilnych dają trzecią, pod warunkiem, że wybierzecie właściwe do Waszej aplikacji, języka zespołu i miejsca, w którym testy mają biegać.

W tym tekście wyjaśniamy, jak działają narzędzia do automatyzacji mobilnej, dlaczego mobilna automatyzacja jest trudniejsza niż webowa, które narzędzia liczą się dziś (Appium, Espresso, XCUITest, Maestro, Detox, Flutter, Katalon), kiedy wybrać narzędzie wieloplatformowe, a kiedy natywne, gdzie uruchamiać testy, jak wybrać narzędzie w siedmiu pytaniach, jak wygląda test w praktyce, jak wpiąć go w CI/CD i jakie błędy popełniają zespoły. Piszemy z projektów, w których aplikacja mobilna klienta wytrzymała sezon przy ruchu większym o 120 procent.

Czym są narzędzia do automatyzacji testów mobilnych i jak działają?

Narzędzie do automatyzacji mobilnej łączy się z aplikacją przez interfejsy testowe systemu (UiAutomator i Espresso na Androidzie, XCTest na iOS), odnajduje elementy interfejsu po identyfikatorach, tekstach albo dostępności, wykonuje na nich akcje i porównuje stan ekranu z oczekiwanym; różnica między narzędziami polega na tym, czy działają z zewnątrz przez protokół, czy wewnątrz procesu aplikacji.

Appium działa z zewnątrz: serwer przyjmuje polecenia w protokole WebDriver od skryptu napisanego w Javie, Pythonie, JavaScripcie czy C#, a sterownik (UiAutomator2 dla Androida, XCUITest dla iOS) tłumaczy je na akcje na urządzeniu. Dzięki temu jeden skrypt może obsłużyć obie platformy, kosztem dodatkowej warstwy, która spowalnia i bywa źródłem niestabilności. Espresso i XCUITest działają wewnątrz: test jest częścią projektu aplikacji, uruchamia się w tym samym procesie albo obok niego i synchronizuje z wątkiem interfejsu, co daje szybkość i stabilność, ale wiąże test z jedną platformą i językiem jej programistów.

Trzecia grupa to narzędzia, które ukrywają tę mechanikę: Maestro opisuje scenariusz w pliku YAML i sam dobiera sposób wykonania, Detox wpina się w aplikację React Native i czeka na zakończenie animacji i żądań sieciowych, a integration_test we Flutterze uruchamia test na urządzeniu z dostępem do drzewa widżetów. Pytanie „które narzędzie jest najlepsze” nie ma odpowiedzi, bo każde odpowiada na inne pytanie: ile platform, jaki język, jaka technologia aplikacji i gdzie testy mają biegać.

Dlaczego automatyzacja testów mobilnych jest trudniejsza niż webowa?

Automatyzacja mobilna jest trudniejsza niż webowa z pięciu powodów: fragmentacja urządzeń i wersji systemu, gesty i klawiatura zamiast kliknięć, uprawnienia i okna systemowe, zmienne warunki sieci i baterii oraz dystrybucja przez sklepy, która wymaga testowania paczek, a nie adresu URL.

• Fragmentacja. Przeglądarek jest kilka, urządzeń z Androidem tysiące. Ten sam test musi przejść na małym ekranie z 2021 roku i na składanym telefonie z tego roku, na Androidzie 11 i 15.
• Gesty i klawiatura. Przewijanie, przeciąganie, przybliżanie, klawiatura systemowa zasłaniająca pole, autouzupełnianie. Kliknięcie w link to najprostsza z akcji, których w aplikacji mobilnej prawie nie ma.
• Uprawnienia i okna systemowe. Prośba o lokalizację, powiadomienia, aparat, logowanie biometryczne. Okno systemowe nie należy do aplikacji, więc narzędzie musi umieć je obsłużyć albo obejść.
• Warunki. Słaba sieć, przejście z Wi-Fi na sieć komórkową, tryb oszczędzania baterii, przerwanie połączeniem telefonicznym. W przeglądarce nic z tego nie istnieje.
• Dystrybucja. Testuje się zbudowaną paczkę (APK, AAB, IPA) na konkretnym urządzeniu, nie adres na serwerze. Budowanie, podpisywanie i instalowanie to część pipeline, której web nie ma.

Z tych powodów testy mobilne przez interfejs są droższe i bardziej kruche niż webowe, więc jeszcze ważniejsza jest zasada z piramidy testów: logika biznesowa w testach jednostkowych i API, przez interfejs mobilny tylko ścieżki krytyczne. Rodzaje testów, które w ogóle wchodzą w grę w projekcie mobilnym, opisujemy w tekście Testowanie aplikacji mobilnych, część 2: rodzaje i typy testów.

Które narzędzia do automatyzacji testów mobilnych liczą się dziś?

Na rynku liczy się siedem narzędzi: Appium (wieloplatformowe, wiele języków), Espresso (Android, natywne), XCUITest (iOS, natywne), Maestro (wieloplatformowe, YAML, niski próg wejścia), Detox (React Native), integration_test (Flutter) i Katalon (niskokodowe na bazie Appium); każde ma inny profil zespołu i aplikacji.

Dokumentacja: Appium, Espresso, XCTest i XCUITest, Maestro, Detox, testy integracyjne Fluttera, Katalon. Uczymy pracy z Appium na szkoleniach Appium w Javie i Appium w Pythonie, a narzędzi niskokodowych na szkoleniu Katalon Studio.

Appium czy narzędzia natywne: Espresso i XCUITest?

Appium wybiera się, gdy jeden zespół QA ma pokryć Androida i iOS wspólnym zestawem w znanym języku; Espresso i XCUITest wybiera się, gdy testy mają pisać developerzy w repozytorium aplikacji i liczy się szybkość oraz stabilność; wiele zespołów łączy oba podejścia: natywne dla warstwy komponentów, Appium dla ścieżek end to end.

Decyzję rozstrzyga jedno pytanie: kto będzie te testy utrzymywał. Zestaw w Espresso pisany przez testera bez wsparcia developerów zostaje sierotą po pierwszej refaktoryzacji. Zestaw w Appium pisany przez developerów, którzy wolą Kotlina, kończy jako obowiązek nikogo. Narzędzie ma pasować do ludzi, którzy będą przy nim siedzieć w środę o siedemnastej, gdy pipeline jest czerwony, a nie do rankingu z bloga.

Maestro, Detox, Flutter: co wybrać dla aplikacji wieloplatformowych?

Dla React Native pierwszym wyborem jest Detox, dla Fluttera integration_test, a dla zespołów bez doświadczenia w automatyzacji Maestro, które obsługuje obie technologie plus aplikacje natywne z jednego pliku YAML; Appium działa ze wszystkimi, ale w aplikacjach wieloplatformowych ma najwięcej problemów z lokatorami.

• Maestro. Scenariusz to lista kroków w YAML: uruchom aplikację, dotknij „Zaloguj”, wpisz tekst, sprawdź, że element jest widoczny. Narzędzie samo czeka na ładowanie i animacje, więc znika największe źródło niestabilności. Dobre na start i na smoke testy w pipeline; przy złożonej logice warunkowej zaczyna brakować możliwości kodu.
• Detox. Zbudowany dla React Native, wie, kiedy aplikacja jest bezczynna (animacje, żądania sieciowe, timery), więc test nie musi zgadywać, ile czekać. Wymaga konfiguracji po stronie natywnej i działa tylko z React Native.
• integration_test we Flutterze. Test ma dostęp do drzewa widżetów, więc lokatory są stabilne niezależnie od platformy. Do interakcji z oknami systemowymi (uprawnienia, klawiatura) potrzebne są dodatki albo Appium z odpowiednim sterownikiem.
• Appium w aplikacjach wieloplatformowych. Działa, ale elementy React Native i Fluttera bywają niewidoczne dla standardowych lokatorów bez identyfikatorów dostępności ustawionych przez developerów. Bez tej współpracy testy są kruche.

Niezależnie od narzędzia, warunkiem stabilnych testów są identyfikatory testowe w kodzie aplikacji: developer nadaje elementowi stały identyfikator, tester po nim odnajduje element. Zespoły, które tego nie ustalą na początku, piszą lokatory po tekstach i pozycjach, które psują się przy każdym tłumaczeniu i zmianie układu. To jeden z ośmiu punktów w tekście o dobrych praktykach testowania aplikacji mobilnych.

Emulator, symulator, własne urządzenia czy farma urządzeń w chmurze?

Emulatory i symulatory służą do szybkich testów w pipeline i na maszynie developera, własne urządzenia do testów gestów, aparatu, biometrii i wydajności, a farmy urządzeń w chmurze (Firebase Test Lab, AWS Device Farm, BrowserStack, Sauce Labs) do regresji na dziesiątkach realnych modeli bez kupowania szafy telefonów.

Strony usług: Firebase Test Lab, AWS Device Farm, BrowserStack App Automate, Sauce Labs. Rozsądny układ w większości projektów: emulatory w pipeline przy każdej zmianie, farma w chmurze raz dziennie i przed wydaniem na wybranej macierzy urządzeń, własne telefony do eksploracji i wydajności. Jak dobrać macierz urządzeń z analityki, opisujemy w tekście Testowanie aplikacji mobilnych, część 1.

Liczby z projektu dla Autono (automotive i wynajem samochodów), potwierdzone przez klienta. Efektem projektu był też wzrost satysfakcji użytkowników aplikacji mobilnej, mierzony po stronie klienta.

Jak wybrać narzędzie do automatyzacji testów mobilnych: siedem pytań

Narzędzie wybiera się, odpowiadając na siedem pytań: ile platform, w jakiej technologii jest aplikacja, kto pisze i utrzymuje testy, w jakim języku, gdzie testy mają biegać, jaki jest zakres (komponenty czy ścieżki end to end) i jaki budżet na farmę urządzeń; odpowiedzi zwykle zawężają wybór do jednego lub dwóch narzędzi.

Jeżeli po siedmiu pytaniach zostają dwa narzędzia, zróbcie tygodniowy pilot: pięć scenariuszy krytycznych w każdym, uruchomionych dziesięć razy z rzędu na emulatorze i na jednym realnym urządzeniu. Wygrywa to, które ma mniej padnięć bez błędu w aplikacji i które zespół chce utrzymywać. Kiedy w ogóle automatyzować, a kiedy nie, rozkładamy w tekście o zaletach i wadach automatyzacji testów, a porównanie narzędzi webowych w tekście Selenium, Cypress czy Playwright.

Jak wygląda test mobilny w praktyce?

Ten sam scenariusz logowania w Maestro to kilkanaście linijek YAML czytelnych dla każdego, a w Appium kilkadziesiąt linijek kodu z konfiguracją sesji, lokatorami i oczekiwaniem na elementy; oba działają, różnią się tym, kto może je napisać i jak dużo logiki da się w nich zamknąć.

Maestro, plik login.yaml

appId: pl.przyklad.rezerwacje
---
- launchApp
- tapOn: "Zaloguj się"
- tapOn:
    id: "login_email"
- inputText: "tester@przyklad.pl"
- tapOn:
    id: "login_password"
- inputText: "Haslo123!"
- tapOn: "Dalej"
- assertVisible: "Twoje rezerwacje"

Appium w Pythonie, ten sam scenariusz (fragment)

driver.find_element(AppiumBy.ACCESSIBILITY_ID, "login_email").send_keys("tester@przyklad.pl")
driver.find_element(AppiumBy.ACCESSIBILITY_ID, "login_password").send_keys("Haslo123!")
driver.find_element(AppiumBy.ACCESSIBILITY_ID, "login_next").click()
WebDriverWait(driver, 10).until(
    EC.presence_of_element_located((AppiumBy.ACCESSIBILITY_ID, "reservations_title")))

Dwie rzeczy w tym przykładzie decydują o stabilności: identyfikatory dostępności nadane przez developerów (login_email, reservations_title) zamiast lokatorów po tekście albo pozycji oraz jawne oczekiwanie na element w Appium zamiast stałych opóźnień. Maestro robi drugie samo, pierwsze wymaga umowy z zespołem developerskim w każdym narzędziu. Test mobilny, który używa stałego uśpienia na trzy sekundy, jest niestabilny z definicji: za krótki na wolnym urządzeniu, za długi na szybkim, i zawsze ukrywa prawdziwy czas odpowiedzi aplikacji.

Jak wpiąć testy mobilne w CI/CD?

W CI/CD testy mobilne biegną warstwami: testy jednostkowe i komponentów przy każdej zmianie, smoke testy przez interfejs na emulatorach po zbudowaniu paczki, regresja na farmie realnych urządzeń raz dziennie i przed wydaniem; warunkiem jest zautomatyzowane budowanie i podpisywanie paczek oraz limit czasu dla każdej warstwy.

• Budowanie paczek. APK lub AAB dla Androida i IPA dla iOS budowane i podpisywane w pipeline, nie na laptopie developera. Budowanie iOS wymaga maszyny z macOS, lokalnej albo w chmurze.
• Emulatory w pipeline. Uruchamiane na czas testu, z ustaloną wersją systemu i rozdzielczością, bez animacji systemowych. Smoke test krytycznych ścieżek w kilka minut.
• Farma urządzeń. Regresja na macierzy z analityki: pięć do piętnastu modeli, które mają najwięcej użytkowników, plus jeden najstarszy wspierany i jeden najnowszy. Równolegle, z nagraniami padnięć.
• Wyniki i artefakty. Raport w formacie JUnit, zrzuty i nagrania z padniętych testów, logi urządzenia. Bez tego padnięcie na farmie jest nie do zdiagnozowania.
• Kwarantanna testów niestabilnych. Test, który migocze, trafia do osobnej grupy z właścicielem i terminem, nie jest ponawiany do skutku.

Zasady budowy potoków i pracy z testami niestabilnymi opisujemy w tekstach o testach regresyjnych i shift left testing. Testy wydajności aplikacji mobilnej to osobny temat, poruszamy go w tekście o testach wydajnościowych.

Jakie są najczęstsze błędy w automatyzacji testów mobilnych?

Najczęstsze błędy to wybór narzędzia z rankingu zamiast z profilu zespołu, lokatory po tekście i pozycji, stałe opóźnienia zamiast oczekiwania na elementy, testy tylko na emulatorach, automatyzacja logiki biznesowej przez interfejs mobilny, brak identyfikatorów testowych w kodzie i brak właściciela zestawu po odejściu osoby, która go napisała.

1. Narzędzie z rankingu. Espresso wybrane przez zespół, w którym nikt nie zna Kotlina, albo Appium tam, gdzie testy mają pisać developerzy iOS. Narzędzie ma pasować do ludzi, nie do artykułu.
2. Lokatory po tekście. Test szuka przycisku „Zaloguj się” i pada po przetłumaczeniu aplikacji na angielski. Identyfikatory dostępności są stałe niezależnie od języka i układu.
3. Stałe opóźnienia. Uśpienie na trzy sekundy zamiast czekania na element. Niestabilne na wolnych urządzeniach, wolne na szybkich.
4. Tylko emulatory. Zielony pipeline i awaria na telefonach z 2021 roku, których emulator nie odda. Farma realnych urządzeń przed wydaniem to minimum.
5. Logika przez interfejs. Sto wariantów naliczania rabatu klikanych w aplikacji zamiast sprawdzonych testami API. Regresja mobilna trwa noc, a padnięcia nie mówią, która reguła zawiodła.
6. Brak identyfikatorów w kodzie. Bez umowy z developerami tester pisze lokatory po strukturze ekranu, które psują się przy każdej zmianie układu.
7. Zestaw bez właściciela. Osoba, która wdrożyła Appium, odchodzi, a nikt nie umie uruchomić serwera. Dokumentacja uruchomienia i dwie osoby znające zestaw to warunek przetrwania.

Listę błędów po stronie procesu, nie narzędzi, spisaliśmy w tekście o najczęstszych błędach w testowaniu aplikacji mobilnych. Wdrożenie automatyzacji mobilnej od wyboru narzędzia po regresję na farmie urządzeń prowadzimy w ramach automatyzacji testów mobilnych, a wiedzę dla liderów jakości publikujemy na portalu Strefa QA.

Najczęstsze pytania o narzędzia do automatyzacji testów mobilnych

Jakie są najpopularniejsze narzędzia do automatyzacji testów aplikacji mobilnych?

Appium (wieloplatformowe, wiele języków), Espresso (Android, natywne), XCUITest (iOS, natywne), Maestro (wieloplatformowe, scenariusze w YAML), Detox (React Native), integration_test (Flutter) i Katalon (niskokodowe na bazie Appium). Każde ma inny profil zespołu i aplikacji.

Co to jest Appium?

Appium to otwarte narzędzie do automatyzacji aplikacji mobilnych na Androida i iOS, natywnych, hybrydowych i webowych. Skrypt w Javie, Pythonie, JavaScripcie lub C# wysyła polecenia w protokole WebDriver do serwera Appium, a sterownik (UiAutomator2, XCUITest) wykonuje je na urządzeniu. Jeden zestaw może obsłużyć obie platformy.

Appium czy Espresso i XCUITest?

Appium, gdy jeden zespół QA ma pokryć obie platformy wspólnym zestawem w znanym języku. Espresso i XCUITest, gdy testy piszą developerzy w repozytorium aplikacji i liczy się szybkość oraz stabilność. Wiele zespołów łączy oba: natywne dla komponentów, Appium dla ścieżek end to end.

Czym jest Maestro?

Maestro to wieloplatformowe narzędzie do testów mobilnych, w którym scenariusz opisuje się w pliku YAML bez kodu. Samo czeka na ładowanie i animacje, ma najniższy próg wejścia i sprawdza się na start oraz w smoke testach. Przy złożonej logice warunkowej zaczyna brakować możliwości kodu.

Czy testy mobilne można uruchamiać na emulatorach?

Tak, do testów komponentów i smoke testów w pipeline. Emulatory nie oddają wydajności, aparatu, biometrii ani sieci komórkowej, więc regresję przed wydaniem uruchamia się na realnych urządzeniach: własnych albo na farmie w chmurze, takiej jak Firebase Test Lab, AWS Device Farm, BrowserStack czy Sauce Labs.

Jak wybrać narzędzie do automatyzacji testów mobilnych?

Odpowiadając na siedem pytań: ile platform, w jakiej technologii jest aplikacja, kto pisze i utrzymuje testy, w jakim języku, gdzie testy mają biegać, jaki zakres i jaki budżet na urządzenia. Jeśli zostają dwa narzędzia, tygodniowy pilot z pięcioma scenariuszami uruchomionymi dziesięć razy rozstrzyga.

Dlaczego testy mobilne są niestabilne?

Najczęściej przez lokatory po tekście lub pozycji, stałe opóźnienia zamiast oczekiwania na elementy, brak identyfikatorów testowych w kodzie, animacje systemowe na emulatorach i różnice wydajności między urządzeniami. Narzędzia takie jak Detox i Maestro czekają na bezczynność aplikacji, co usuwa część problemu.

Czy do automatyzacji testów mobilnych trzeba umieć programować?

Nie zawsze. Maestro i Katalon pozwalają pisać scenariusze bez kodu. Appium wymaga języka programowania, Espresso Kotlina lub Javy, XCUITest Swifta. Wybór narzędzia bez kodu ma sens na start, ale przy złożonej logice zespół zwykle dochodzi do potrzeby kodu.

Powiązane na blogu Quality Island

• Testowanie aplikacji mobilnych część 1: podstawy, typy aplikacji i sposoby testowania
• Testowanie aplikacji mobilnych część 2: rodzaje i typy testów
• Best practices testowania aplikacji mobilnych: osiem zasad
• Najczęściej popełniane błędy podczas testowania aplikacji mobilnych
• Automatyzacja testów: Selenium WebDriver, Cypress czy Playwright
• Piramida testów: co to jest, warstwy, proporcje i techniki projektowania testów

Pełna lista źródeł

• Dokumentacja narzędzi: Appium, Espresso, UI Automator, XCTest, Maestro, Detox, Flutter integration tests, Katalon
• Farmy urządzeń: Firebase Test Lab, AWS Device Farm, BrowserStack App Automate, Sauce Labs
• Dane własne Quality Island z projektu dla Autono (automotive i wynajem samochodów), liczby potwierdzone przez klienta; ponad 450 000 napisanych testów automatycznych, ponad 152 zrealizowane projekty