Testowanie aplikacji mobilnych część 2: rodzaje i typy testów

Testy funkcjonalne aplikacji mobilnych sprawdzają, czy aplikacja robi to, czego oczekuje użytkownik, ale to dopiero jeden z dziesięciu rodzajów testów, które realnie chronią ocenę w sklepie. Ten tekst to część 2 cyklu: zamiast definicji dostajecie do każdego rodzaju testu ryzyko, gotowy przypadek testowy i narzędzie. Szeroki przegląd tematu, urządzeń i środowisk znajdziecie w części 1 o testowaniu aplikacji mobilnych.

Zanim zaczniecie, krótka mapa cyklu, żeby nie czytać dwa razy tego samego. Zasady pracy i checklistę 16 przypadków opisuje wpis o best practices testowania aplikacji mobilnych, typowe wpadki zespołów zebraliśmy w artykule o błędach w testowaniu aplikacji mobilnych, a porównanie Appium, Espresso i XCUITest w tekście o narzędziach do automatyzacji testów aplikacji mobilnych. Tutaj skupiamy się wyłącznie na rodzajach testów.

Jakie są typy aplikacji mobilnych i dlaczego to zmienia dobór testów?

Typ aplikacji decyduje o tym, gdzie mieszkają błędy. W aplikacji natywnej szukacie ich osobno na Androidzie i iOS, w hybrydowej w styku WebView z warstwą natywną, a w webowej w przeglądarce i sieci. Starsze materiały, także nasz poprzedni tekst, wrzucały React Native i Flutter do worka z aplikacjami hybrydowymi. To nieprecyzyjne: oba to frameworki wieloplatformowe, które nie renderują interfejsu w WebView.

Dokumentacja React Native mówi wprost, że w czasie działania framework tworzy odpowiadające komponentom widoki Androida i iOS. Flutter idzie inną drogą: według dokumentacji architektury ma własne implementacje każdej kontrolki i rysuje je silnikiem Impeller, a kod wydania kompiluje do kodu maszynowego. Dla testów ma to konkretną konsekwencję, o której piszemy niżej w ciekawostce.

Jakie rodzaje testów aplikacji mobilnych warto znać?

Poniższa tabela to ściąga na planowanie wydania. Każdy rodzaj testu odpowiada na inne ryzyko, więc kolejność wierszy nie jest przypadkowa: pierwsze trzy wiersze robicie przy każdym wydaniu, kolejne zależnie od zmiany i domeny.

Testy funkcjonalne aplikacji mobilnych: jak wygląda dobry przypadek testowy?

Testy funkcjonalne aplikacji mobilnych zaczynają się od ścieżek, za które płaci biznes: logowanie, koszyk, płatność, rezerwacja. Dobry przypadek ma warunki wstępne, kroki, oczekiwany wynik i zaznacza stan aplikacji, który mobilny system potrafi zabić w tle. Tego ostatniego brakuje w większości przypadków, które widzimy u klientów przy audytach.

Ten sam scenariusz w wersji automatycznej. Maestro opisuje przepływ w YAML, więc test czyta także osoba bez doświadczenia w programowaniu. W projektach z istniejącym kodem w Javie albo Pythonie częściej wybieramy Appium, którego uczymy na szkoleniach Appium Java i Appium Python.

appId: pl.sklep.demo
---
- launchApp:
    clearState: true
- tapOn: "Zaloguj"
- inputText: "anna.test@example.com"
- tapOn: "Dalej"
- inputText: "Haslo!2026"
- tapOn: "Zaloguj"
- assertVisible: "Twój koszyk"
- tapOn: "Dodaj do koszyka"
- assertVisible: "1 produkt"
- stopApp
- launchApp
- assertVisible: "1 produkt"

Zwróćcie uwagę na ostatnie trzy kroki: zatrzymanie i ponowne uruchomienie to najtańszy sposób, żeby sprawdzić, czy stan zapisuje się trwale, a nie tylko w pamięci procesu.

Testy zgodności i konfiguracji: jak zbudować matrycę urządzeń?

Testy zgodności sprawdzają tę samą funkcję na różnych urządzeniach, wersjach systemu i rozdzielczościach. Nikt nie przetestuje wszystkich kombinacji, więc matrycę buduje się z danych o Waszych użytkownikach, a nie z rankingów sprzedaży. Źródłem jest Google Play Console, App Store Connect albo analityka produktu.

Matryca bez danych to zgadywanie, a zgadywanie kosztuje. Przy testach dla Autono, wypożyczalni samochodów, praca na realnych scenariuszach sezonowych pozwoliła potwierdzić stabilność systemu przy obciążeniu większym o 120 procent i obniżyć liczbę błędów krytycznych w procesach rezerwacji o 55 procent (dane klienta z case study Quality Island). Więcej o doborze urządzeń piszemy w przewodniku po testowaniu aplikacji mobilnych.

Testy wydajnościowe aplikacji mobilnych: co mierzyć i jakimi progami?

Testy wydajnościowe aplikacji mobilnych mierzą czas startu, płynność, zużycie pamięci i baterii. Najprostszy punkt odniesienia daje Google: według dokumentacji Android vitals zimny start trwający 5 sekund lub dłużej, ciepły 2 sekundy lub dłużej i gorący 1,5 sekundy lub dłużej to start nadmierny. Te same zestawienia pokazują progi stabilności, po przekroczeniu których Google Play ogranicza widoczność aplikacji.

Pomiar zacznijcie od komend, które nie wymagają żadnego narzędzia poza adb. Pierwsza para daje czas zimnego startu w milisekundach, druga wymusza tryb Doze, w którym system ogranicza pracę w tle, trzecia spowalnia sieć w emulatorze.

# czas zimnego startu (TotalTime w ms), po zatrzymaniu procesu
adb shell am force-stop pl.sklep.demo
adb shell am start -W -n pl.sklep.demo/.MainActivity

# wymuszenie trybu Doze, żeby sprawdzić synchronizację w tle
adb shell dumpsys deviceidle force-idle
adb shell dumpsys deviceidle unforce

# słaba sieć w emulatorze (konsola emulatora przez adb)
adb emu network speed edge
adb emu network delay gprs

Mierzcie na telefonie z niższej półki, nie na flagowcu z biurka programisty. Wąskie gardła wychodzą tam kilka razy szybciej. Gdy aplikacja korzysta z backendu, połączcie test mobilny z obciążeniem serwera: wprowadzenie do metryk i narzędzi daje artykuł o testach wydajnościowych, a zlecone testy wydajności obejmują oba końce.

Testy bezpieczeństwa aplikacji mobilnych: od czego zacząć według OWASP MASVS?

Testy bezpieczeństwa aplikacji mobilnych najłatwiej zaplanować według standardu OWASP MASVS, który dzieli wymagania na osiem grup. Każda grupa to inne pytanie do aplikacji, a tabela pokazuje po jednym przypadku testowym na start. Pełny katalog kontroli i przypadków testowych znajdziecie na stronie OWASP MAS.

Statyczny skan zrobi MobSF w kilka minut, ale wyniki trzeba czytać ze zrozumieniem, bo część alarmów to fałszywe trafienia. Szerzej o rodzajach i etapach piszemy w tekście o testach bezpieczeństwa i testach penetracyjnych. Gdy aplikacja obsługuje płatności albo dane zdrowotne, warto zlecić niezależne testy bezpieczeństwa aplikacji.

Testy sieciowe: jak symulować słabe połączenie, skoro 3G znika z Polski?

Poprzednia wersja tego tekstu radziła testować aplikację w sieciach 3G. Dziś to rada nieaktualna: według Spider’s Web (maj 2026) T-Mobile wyłączył 3G w 2023 roku, Orange pod koniec 2025 roku, Play kończy wygaszanie do końca 2026 roku, a Plus zaczyna w grudniu 2026 roku. Słabe połączenie nie zniknęło jednak razem z 3G: przeniosło się do zatłoczonego LTE, piwnic, wind i pociągów.

Dlatego w testach sieciowych opisujcie warunki, a nie nazwę technologii: przepustowość, opóźnienie, utratę pakietów i zmianę sieci w trakcie operacji. Cztery przypadki, które warto mieć w każdej regresji:

• płatność przerwana włączeniem trybu samolotowego po kliknięciu Zapłać: brak podwójnego obciążenia, czytelny komunikat, możliwość ponowienia
• przejście z Wi-Fi na sieć komórkową podczas wysyłania formularza: dane nie giną
• start aplikacji bez sieci: ekran z treścią z pamięci podręcznej zamiast pustej białej strony
• opóźnienie 2 sekund na każdym żądaniu: przyciski nie przyjmują podwójnego kliknięcia

Na Androidzie spowolnienie ustawicie w konsoli emulatora poleceniami network speed i network delay, opisanymi w dokumentacji konsoli emulatora. Na iOS służy do tego Network Link Conditioner z narzędzi Xcode, a na obu platformach proxy Charles z ograniczaniem przepustowości.

Testy użyteczności i dostępności: jakie wymiary i gesty sprawdzić?

Testy użyteczności sprawdzają, czy ludzie kończą zadanie, a nie czy przycisk działa. Badanie nie musi być drogie: Jakob Nielsen w artykule Nielsen Norman Group (2000) pokazał, że pierwsze badanie z pięcioma uczestnikami wykrywa około 85 procent problemów użyteczności, i radzi rozłożyć budżet na trzy rundy po pięć osób. Mobilny dodatek to warunki: jedna ręka, słońce na ekranie, powiadomienie w połowie formularza.

Dostępność testujcie czytnikami ekranu przez całą ścieżkę, nie ekran po ekranie: TalkBack na Androidzie, VoiceOver na iOS. Typowe błędy to ikony bez etykiet, focus uciekający po zamknięciu okna i komunikaty błędów niewidoczne dla czytnika. Checklistę z przykładami znajdziecie w artykule o 7 obszarach dostępności do przetestowania, a audyt robimy w ramach usługi testów dostępności. Badania z użytkownikami prowadzimy w ramach testów użyteczności.

Testy instalacji, aktualizacji i lokalizacji: co psuje się po wydaniu?

Test instalacji na czystym telefonie przechodzi prawie zawsze. Psuje się aktualizacja, bo dopiero ona uruchamia migrację bazy danych, zmianę formatu zapisanych ustawień i nowe uprawnienia. W naszych projektach mobilnych przypadek aktualizacji z wersji N-1 z wypełnionymi danymi jest obowiązkowy przed każdym wydaniem i regularnie łapie błędy, których nie widać na świeżej instalacji.

1. Zainstalujcie wersję produkcyjną, zalogujcie się, wypełnijcie koszyk, ulubione i ustawienia.
2. Zaktualizujcie aplikację do kandydata wydania z kanału testowego (wewnętrzne testy Google Play, TestFlight).
3. Sprawdźcie zachowanie sesji, danych lokalnych i uprawnień, potem powtórzcie po aktualizacji samego systemu operacyjnego.
4. Odinstalujcie i zainstalujcie ponownie: aplikacja nie może zakładać, że dane z poprzedniej instalacji istnieją.

Lokalizację sprawdzicie, zanim pojawi się tłumacz. Android ma wbudowane pseudolokalizacje: en-XA wydłuża teksty i dodaje akcenty, a ar-XB odwraca kierunek pisania. Jeden przebieg na takim ustawieniu pokazuje ucięte etykiety i teksty zaszyte w kodzie. Pamiętajcie też o formatach: data, waluta z przecinkiem dziesiętnym i polska odmiana liczebników (1 produkt, 2 produkty, 5 produktów).

Które rodzaje testów mobilnych automatyzować, a które zostawić ludziom?

Automatyzujcie to, co powtarzalne i stabilne: regresję ścieżek krytycznych, smoke test każdego buildu, zgodność na matrycy urządzeń i pomiary startu. Ludziom zostawcie użyteczność, eksplorację nowych funkcji, ocenę pierwszego wrażenia i dostępność z czytnikiem ekranu, gdzie liczy się ocena, a nie asercja. Jak policzyć, który przypadek opłaca się automatyzować, pokazuje artykuł o tym, czym różni się testowanie manualne i automatyczne.

W Quality Island napisaliśmy ponad 450 000 testów automatycznych, a mimo to w projektach mobilnych zawsze planujemy też sesje ręczne na fizycznych urządzeniach. Automat nie poczuje, że telefon się grzeje. Tester poczuje, a czasem nawet ogrzeje sobie dłonie w styczniu. Gdy chcecie zbudować automatyzację u siebie, punktem startu jest automatyzacja testów mobilnych, a kompetencje zespołu rozwinie szkolenie testowanie aplikacji mobilnych.

O tym, jak inne zespoły układają strategię testów mobilnych, regularnie opowiadają prelegenci Testing Ground Conference, a krótsze analizy dla liderów publikuje Strefa QA.

Powiązane na blogu Quality Island

• Testowanie aplikacji mobilnych: kompletny przewodnik po typach, urządzeniach i narzędziach
• Best practices testowania aplikacji mobilnych: osiem zasad i checklista
• Najczęściej popełniane błędy podczas testowania aplikacji mobilnych
• Narzędzia do automatyzacji testów aplikacji mobilnych: Appium, Espresso, XCUITest
• Typy testów oprogramowania: funkcjonalne, niefunkcjonalne, strukturalne i regresja

Pełna lista źródeł

• Android Developers, Android vitals: progi złego zachowania (2025)
• Android Developers, App startup time w Android vitals (2025)
• OWASP, Mobile Application Security Verification Standard (MASVS), wersja 2 (2023 i aktualizacje 2025)
• React Native, Core Components and Native Components (2025)
• Flutter, Architectural overview (2025)
• Spider’s Web, wyłączenie 3G w sieci Plus i stan u pozostałych operatorów (2026)
• W3C, WCAG 2.2, kryterium 2.5.8 Target Size Minimum (2023)
• Jakob Nielsen, Nielsen Norman Group, Why You Only Need to Test with 5 Users (2000)
• Android Developers, konsola emulatora: network speed i network delay (2025)
• Android Developers, testowanie z pseudolokalizacjami (2025)
• Android Developers, Doze i App Standby (2025)
• Maestro, dokumentacja przepływów testów mobilnych w YAML (2025)
• Quality Island, case study Autono i dane własne o liczbie testów automatycznych (2026)