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), wieloplatformowe (jeden kod na obie platformy: React Native renderuje natywne komponenty systemu, a Flutter kompiluje się do kodu natywnego i rysuje interfejs własnym silnikiem), hybrydowe w ścisłym sensie, czyli aplikacja webowa w natywnej powłoce WebView (Ionic, Apache Cordova, Capacitor), 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. Dla porównania: co i jakimi narzędziami sprawdza się w przeglądarce, rozpisujemy w przewodniku testowanie aplikacji webowych.

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. Gdy zespół testuje zdalnie, farma w chmurze albo własna farma z dostępem przez sieć staje się jedynym sposobem na wspólną macierz urządzeń; jak to zorganizować razem ze środowiskami i danymi testowymi, opisujemy w tekście praca zdalna w testowaniu: wyzwania, korzyści i dane z rynku.

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: testy od etapu wymagań, sprawdzanie całej warstwy sieciowej, a nie tylko braku sieci, dobór realnych urządzeń z danych o użytkownikach, testy języków, a nie samych tłumaczeń, pomiar baterii i pracy w tle, testy sprzętu i przerwań, weryfikacja uprawnień w trzech stanach oraz automatyzacja regresji zamiast automatyzowania wszystkiego.

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.

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