Testowanie aplikacji mobilnych: kompletny przewodnik po typach, urządzeniach i narzędziach

Czas czytania: około 14 minut

Premiera Cyberpunka 2077 pokazała, jak boleśnie mści się niedopracowana jakość: lawina błędów była tak duża, że dystrybutorzy czasowo usunęli grę ze sklepów. W aplikacjach mobilnych ryzyko jest większe niż w webie, bo produkt trafia na setki modeli telefonów, kilka wersji systemu i do użytkownika, który testuje go w autobusie, przy słabym zasięgu, z baterią na piętnastu procentach.

Ten tekst jest przewodnikiem po całym temacie testowania aplikacji mobilnych: typy aplikacji, dlaczego testy mobilne różnią się od webowych, gdzie je uruchamiać (urządzenia, emulatory, chmura), jakie rodzaje testów stosować, jakich narzędzi użyć do automatyzacji, jak wygląda dobra praktyka i najczęstsze błędy, oraz gdzie w tym wszystkim mieszczą się testy wydajnościowe i testy alfa i beta. Każdy wątek rozwijamy osobno w linkowanych tekstach, tu dostajecie mapę całości.

Czym jest aplikacja mobilna i jakie ma typy?

Aplikacje mobilne dzielą się na natywne (napisane pod jedną platformę, Kotlin lub Swift, najlepsza wydajność i dostęp do sprzętu), hybrydowe (jeden kod na obie platformy, na przykład React Native lub Flutter) oraz webowe, czyli strony dopasowane do telefonu, uruchamiane w przeglądarce bez instalacji; każdy typ ma inny profil ryzyka i inny sposób testowania.

Wybór typu aplikacji determinuje wybór narzędzi do automatyzacji: pełny przegląd siedmiu narzędzi (Appium, Espresso, XCUITest, Maestro, Detox, integration_test, Katalon) z tabelą decyzyjną znajdziecie w tekście Narzędzia do automatyzacji testów aplikacji mobilnych.

Dlaczego testowanie aplikacji mobilnych różni się od webowego?

Testowanie mobilne jest trudniejsze niż webowe z pięciu powodów: fragmentacja urządzeń i wersji systemu, gesty i klawiatura systemowa zamiast kliknięć myszą, uprawnienia i okna systemowe, zmienne warunki sieci i baterii oraz dystrybucja przez sklepy, która wymaga testowania zbudowanej paczki, nie adresu URL.

Użytkownik aplikacji mobilnej jest bezlitosny: jeden błąd w krytycznym momencie, na przykład podczas płatności, kończy się skasowaniem aplikacji i negatywną opinią w sklepie, zanim ktokolwiek zdąży zgłosić błąd wsparciu. Aplikacja, która działa bez zarzutu na telefonie testera, może sypać się u połowy użytkowników na starszym modelu albo przy słabym zasięgu w metrze. To nie jest argument za testowaniem wszystkiego wszędzie, tylko za świadomym wyborem macierzy urządzeń i warunków, które odzwierciedlają realnych klientów, a nie wygodę zespołu.

Jak testować na realnych urządzeniach, emulatorach i w chmurze?

Testy uruchamia się na trzech rodzajach środowisk: realnych urządzeniach (gesty, aparat, biometria, prawdziwa sieć, ale drogie w skali), emulatorach i symulatorach (szybkie, darmowe, w pipeline, ale nie oddają wydajności i sprzętu) oraz w chmurowych farmach urządzeń (macierz realnych modeli bez kupowania szafy telefonów, rozliczenie za minuty).

Rozsądny układ w większości projektów: emulatory w pipeline przy każdej zmianie, farma w chmurze (Firebase Test Lab, AWS Device Farm, BrowserStack, Sauce Labs) raz dziennie i przed wydaniem, własne urządzenia do eksploracji i testów wydajności. Szczegóły tych usług i przykład konfiguracji CI/CD w tekście o narzędziach do automatyzacji testów mobilnych.

Jakie rodzaje testów mobilnych warto stosować i kiedy?

W projekcie mobilnym stosuje się te same rodzaje testów co w webie (funkcjonalne, niefunkcjonalne, regresyjne, akceptacyjne), z dodatkowymi kategoriami specyficznymi dla telefonu: testy instalacji i aktualizacji, testy przerwań (połączenie, powiadomienie, niski poziom baterii), testy zgodności wsteczącej wersji systemu oraz testy gestów i orientacji ekranu.

• Testy funkcjonalne. Czy proces logowania, zakupu i płatności działa zgodnie z wymaganiami, niezależnie od urządzenia.
• Testy instalacji i aktualizacji. Instalacja od zera, aktualizacja z poprzedniej wersji, migracja danych lokalnych, dezinstalacja bez pozostawionych śladów.
• Testy przerwań. Połączenie telefoniczne w trakcie płatności, powiadomienie push zasłaniające formularz, przełączenie z Wi-Fi na sieć komórkową, blokada ekranu.
• Testy zgodności wstecznej. Najstarsza wspierana wersja systemu i najnowsza, na urządzeniach z różną wielkością ekranu i gęstością pikseli.
• Testy gestów i orientacji. Przewijanie, przeciąganie, przybliżanie, obrót ekranu w trakcie wypełniania formularza.
• Testy wydajnościowe. Czas uruchomienia, zużycie baterii i pamięci, zachowanie pod słabym zasięgiem; rozwijamy w osobnej sekcji niżej.

Pełny podział rodzajów testów mobilnych, w tym testy specyficzne dla platformy, opisujemy w tekście Testowanie aplikacji mobilnych, część 2: rodzaje i typy testów, a ogólny podział typów testów (funkcjonalne, niefunkcjonalne, strukturalne, regresja) w tekście Typy testów oprogramowania.

Jakie narzędzia do automatyzacji testów mobilnych wybrać?

Do automatyzacji testów mobilnych wybiera się Appium dla obu platform jednym zestawem, Espresso i XCUITest dla natywnych testów pisanych przez developerów, Maestro dla szybkiego startu bez kodu, oraz Detox i integration_test odpowiednio dla React Native i Fluttera; wybór zależy od technologii aplikacji, języka zespołu i tego, kto testy utrzymuje.

Pełne porównanie siedmiu narzędzi z tabelą decyzyjną, przykładem tego samego testu w Maestro i Appium oraz sekcją o CI/CD znajdziecie w tekście Narzędzia do automatyzacji testów aplikacji mobilnych. Uczymy pracy z Appium na szkoleniach Appium w Javie i Appium w Pythonie.

Jak wygląda dobra praktyka testowania aplikacji mobilnych?

Dobra praktyka testowania mobilnego opiera się na ośmiu zasadach: testowanie na realnym sprzęcie przed wydaniem, macierz urządzeń z analityki (nie z domysłu), identyfikatory testowe w kodzie od pierwszego dnia, testy przerwań jako standard, a nie wyjątek, oraz automatyzacja ścieżek krytycznych przy zachowaniu eksploracji dla nowych funkcji.

Osiem zasad z pełnym uzasadnieniem i przykładami z projektów rozkładamy w tekście Best practices testowania aplikacji mobilnych. Skrót: nie ufajcie wyłącznie emulatorom, budujcie macierz urządzeń z danych o realnych użytkownikach (system operacyjny, model, rozdzielczość), a testy automatyczne piszcie na identyfikatorach testowych, nie na tekście czy pozycji elementu.

Jakich błędów unikać przy starcie testów mobilnych?

Najczęstsze błędy na starcie testów mobilnych to testowanie wyłącznie na emulatorach, ignorowanie testów przerwań i utraty sieci, brak testów aktualizacji z poprzedniej wersji, macierz urządzeń dobrana z domysłu zamiast z analityki oraz automatyzacja logiki biznesowej przez interfejs zamiast przez API.

Pełną listę błędów z przykładami, w tym te, które kosztowały realne projekty utratę użytkowników, opisujemy w tekście Najczęściej popełniane błędy podczas testowania aplikacji mobilnych.

Testy wydajnościowe, alfa i beta w projekcie mobilnym

Przed wydaniem aplikacji mobilnej dochodzą jeszcze dwa etapy: testy wydajnościowe sprawdzające czas uruchomienia, zużycie baterii i zachowanie pod obciążeniem sieci, oraz testy alfa i beta, w których produkt trafia najpierw do pracowników wewnątrz firmy, potem do zaproszonych użytkowników na ich własnych urządzeniach.

Testy wydajnościowe aplikacji mobilnej, w tym rodzaje testów obciążeniowych i narzędzia, opisujemy w tekście Testy wydajnościowe. Testy alfa i beta, czyli ostatni etap przed wydaniem produktu dla wielu użytkowników, z sześcioma krokami programu beta i szablonem zgłoszenia, rozkładamy w tekście Testy alfa i testy beta. Apple pozwala zaprosić do programu beta w TestFlight do 10 000 zewnętrznych testerów, Google Play rozróżnia testy wewnętrzne, zamknięte i otwarte.

Jak zaplanować testy aplikacji mobilnej krok po kroku?

Plan testów aplikacji mobilnej powstaje w sześciu krokach: wybór typu aplikacji i wynikające z niego narzędzia, macierz urządzeń z analityki, rozkład testów między emulatory, realne urządzenia i farmę w chmurze, automatyzacja ścieżek krytycznych, testy wydajnościowe przed sezonem oraz program alfa i beta przed każdą większą wersją.

Wdrożenie takiego planu, od doboru narzędzi po regresję na farmie urządzeń, prowadzimy w ramach automatyzacji testów mobilnych. Kompetencje manualne budujemy na szkoleniu Testowanie manualne aplikacji mobilnych. Wiedzę dla liderów jakości publikujemy na portalu Strefa QA.

Najczęstsze pytania o testowanie aplikacji mobilnych

Jakie są typy aplikacji mobilnych?

Natywne (napisane pod jedną platformę, Kotlin lub Swift), hybrydowe (jeden kod na obie platformy, na przykład React Native lub Flutter) oraz webowe, czyli strony dopasowane do telefonu uruchamiane w przeglądarce. Każdy typ testuje się innymi narzędziami i z innym naciskiem.

Dlaczego testowanie aplikacji mobilnych jest trudniejsze niż webowe?

Z powodu fragmentacji urządzeń i wersji systemu, gestów i klawiatury systemowej zamiast kliknięć, uprawnień i okien systemowych, zmiennych warunków sieci i baterii oraz dystrybucji przez sklepy, która wymaga testowania zbudowanej paczki, nie adresu URL.

Czy testy mobilne można prowadzić tylko na emulatorach?

Nie do końca. Emulatory są darmowe i szybkie, dobre do testów w pipeline, ale nie oddają wydajności, aparatu, biometrii ani sieci komórkowej. Regresję przed wydaniem warto uruchomić na realnych urządzeniach: własnych albo na farmie w chmurze.

Jakie narzędzia wybrać do automatyzacji testów mobilnych?

Appium dla obu platform jednym zestawem, Espresso dla natywnego Androida, XCUITest dla natywnego iOS, Maestro dla szybkiego startu bez kodu, Detox dla React Native, integration_test dla Fluttera. Wybór zależy od technologii aplikacji i języka zespołu.

Co to jest farma urządzeń w chmurze?

Usługa dająca dostęp do dziesiątek realnych modeli telefonów bez ich kupowania, rozliczana za minuty testów. Przykłady: Firebase Test Lab, AWS Device Farm, BrowserStack App Automate, Sauce Labs. Używa się jej do regresji przed wydaniem na szerokiej macierzy urządzeń.

Jakie są testy alfa i beta w aplikacji mobilnej?

Alfa to testy wewnątrz firmy, przez pracowników spoza zespołu projektowego, na wersji jeszcze niedopracowanej. Beta to testy przez realnych, zaproszonych użytkowników na ich własnych urządzeniach, na wersji bliskiej wydaniu. Oba poprzedzają wydanie produktu dla wielu klientów.

Jak zbudować macierz urządzeń do testów?

Z analityki aplikacji: najczęstsze modele, wersje systemu i rozdzielczości wśród realnych użytkowników, plus jeden najstarszy wspierany model. Macierz dobrana z domysłu zamiast z danych to jeden z najczęstszych błędów na starcie testów mobilnych.

Powiązane na blogu Quality Island

• Testowanie aplikacji mobilnych część 2: rodzaje i typy testów
• Narzędzia do automatyzacji testów aplikacji mobilnych: Appium, Espresso, XCUITest, Maestro
• Best practices testowania aplikacji mobilnych
• Najczęściej popełniane błędy podczas testowania aplikacji mobilnych
• Testy wydajnościowe: co to jest, rodzaje, metryki, narzędzia
• Testy alfa i testy beta: czym się różnią, kto je prowadzi i kiedy je stosować

Pełna lista źródeł

• Google, wspieranie wielu ekranów na Androidzie
• Apple, Human Interface Guidelines
• 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