Błędy w aplikacji mobilnej: 7 luk w testach i jak je zamknąć

Błędy w aplikacji mobilnej, które trafiają do użytkowników, rzadko wynikają z jednego złego commita. Najczęściej to skutek kilku powtarzalnych luk w samym procesie testów: jeden telefon zamiast matrycy urządzeń, brak testu aktualizacji, zero scenariuszy słabej sieci. Ten tekst opisuje siedem takich luk i do każdej daje konkretne narzędzie: polecenie adb, profil sieci w emulatorze, tabelę urządzeń z danymi dla Polski albo listę kontroli bezpieczeństwa.

Piszemy dla testerów, liderów QA i zespołów, które budują aplikacje na Androida i iOS. Jeśli dopiero układacie fundamenty, zacznijcie od naszego kompletnego przewodnika po testowaniu aplikacji mobilnych. Tutaj skupiamy się na tym, gdzie proces najczęściej przecieka.

Dlaczego błędy w aplikacji mobilnej kosztują więcej niż w webie?

Błąd w aplikacji mobilnej uderza w trzy miejsca naraz: w użytkownika, w ocenę w sklepie i w widoczność w samym sklepie. Według dokumentacji Android vitals z 2026 roku Google Play może ograniczyć widoczność aplikacji, która przekracza 1,09% użytkowników z awarią albo 0,47% użytkowników z ANR. Ten sam dokument podaje osobny próg 8% dla pojedynczego modelu telefonu. Przy jego przekroczeniu sklep może pokazać ostrzeżenie na karcie aplikacji.

Wniosek jest prosty: aplikacja może być stabilna średnio i jednocześnie dostać ostrzeżenie na jednym popularnym modelu. Dlatego matryca urządzeń nie jest dodatkiem do testów, tylko obroną konkretnej liczby w konsoli Google Play. Na webie błąd naprawiacie wdrożeniem w kilka minut. W mobile poprawka czeka na przegląd w sklepie i na to, aż użytkownik zainstaluje aktualizację.

Błąd 1: czy testujecie mobilkę tak samo jak stronę WWW?

To błąd testerów, którzy przychodzą z projektów webowych. Strona WWW żyje w karcie przeglądarki. Aplikacja mobilna ma własny cykl życia: system może ją wstrzymać, wyrzucić z pamięci, uśpić w trybie Doze albo przerwać połączeniem telefonicznym.

Typowe defekty z tej kategorii wyglądają tak: formularz traci wpisane dane po powrocie z aparatu, płatność wisi po odebraniu połączenia, a powiadomienie nie przychodzi, bo system uśpił aplikację. Żaden z nich nie wyjdzie w teście, który klika ścieżkę od początku do końca bez przerw.

Jak tego uniknąć: dopiszcie do każdej ścieżki krytycznej scenariusze przerwań. Na Androidzie większość z nich wywołacie poleceniami z dokumentacji Android Developers, bez fizycznego telefonu w ręku:

# tryb Doze i App Standby (Android Developers, Optimize for Doze and App Standby)
adb shell dumpsys battery unplug
adb shell dumpsys deviceidle force-idle
adb shell am set-inactive pl.firma.aplikacja true
# powrót do normalnego stanu
adb shell dumpsys deviceidle unforce
adb shell dumpsys battery reset
# emulator: połączenie przychodzące i 5% baterii
adb emu gsm call 600700800
adb emu power capacity 5

Do tego włączcie w opcjach programisty ustawienie „Nie zachowuj aktywności”. Każde wyjście z ekranu niszczy wtedy aktywność, więc od razu widać, czy aplikacja poprawnie zapisuje i odtwarza stan. Szerszy przegląd tego, jakie rodzaje testów wchodzą w grę, znajdziecie w tekście o rodzajach i typach testów aplikacji mobilnych.

Błąd 2: jak zbudować matrycę urządzeń zamiast testować na jednym telefonie?

Testy na jednym telefonie dają fałszywe poczucie bezpieczeństwa. Nie przetestujecie wszystkich modeli, więc potrzebujecie matrycy: małej, uzasadnionej danymi listy konfiguracji. Najlepszym źródłem są Wasze własne dane z Google Play Console, App Store Connect albo analityki. Gdy aplikacja jest nowa, punktem startu mogą być dane rynkowe.

Z takich danych składamy matrycę w trzech poziomach. Poziom pierwszy przechodzi pełną regresję przy każdym wydaniu, poziom drugi testy dymne, a trzeci tylko ścieżki krytyczne raz na cykl.

Fizyczne telefony z poziomu pierwszego warto mieć na biurku. Resztę matrycy taniej jest wynająć w chmurowej farmie urządzeń. Porównanie dwóch największych usług, z cenami sprawdzonymi u dostawców, opisujemy w tekście o Sauce Labs i BrowserStack.

Błąd 3: dlaczego sama warstwa wizualna to za mało?

Interfejs to tylko wierzch aplikacji. Pod spodem są lokalna baza danych, synchronizacja, API i zadania w tle. W naszych projektach najdroższe błędy w aplikacji mobilnej siedzą właśnie tam: dane rozjeżdżają się między telefonem a serwerem, a użytkownik widzi poprawny ekran z nieaktualną treścią.

Częsty mit mówi, że lokalna baza SQLite jest wolna. Sam silnik jest szybki i działa w miliardach urządzeń. Problemy robią zapytania na głównym wątku, brak indeksów i migracje schematu. Na Androidzie zapytanie na głównym wątku potrafi zamrozić ekran, a każdy taki przypadek podnosi wskaźnik ANR z Android vitals.

• Wątek główny. Włączcie StrictMode w buildzie testowym, żeby odczyt z dysku na głównym wątku od razu kończył się logiem albo awarią.
• Kontrakt z API. Sprawdzajcie odpowiedzi serwera osobno od interfejsu. Pomagają w tym automatyczne testy API, które wyłapią zmianę pola, zanim zrobi to aplikacja.
• Synchronizacja offline. Zapiszcie dane bez sieci, wróćcie do sieci i sprawdźcie konflikt, gdy ten sam rekord zmienił się na serwerze.
• Długie listy. Przewińcie listę z kilkoma tysiącami pozycji na najsłabszym telefonie z matrycy i obserwujcie zużycie pamięci.

Błąd 4: co pomijacie w testach instalacji i aktualizacji?

Test świeżej instalacji to za mało. Prawdziwy użytkownik nie instaluje aplikacji od zera, tylko aktualizuje wersję sprzed miesiąca z własnymi danymi. Jeśli migracja schematu bazy się wysypie, aplikacja przestaje działać tylko u tych, którzy już ją lubili. Takie błędy w aplikacji mobilnej uderzają w najwierniejszych użytkowników.

Dla Androida z bazą Room dokumentacja Android Developers opisuje klasę MigrationTestHelper. Tworzy ona bazę w starej wersji, uruchamia migracje i sprawdza schemat. Pamiętajcie jednak, że helper weryfikuje strukturę, a poprawność samych danych musicie sprawdzić własnymi asercjami.

Terminy też robią swoje. Według wymagań Google Play od 31 sierpnia 2026 roku nowe aplikacje i aktualizacje muszą celować w Androida 16, czyli API 36. Każde takie podniesienie zmienia zachowanie aplikacji, więc to dobry moment na pełną regresję, a nie tylko na zmianę jednej liczby w pliku Gradle.

Błąd 5: jak sprawdzać bezpieczeństwo bez pentestu przy każdym wydaniu?

Telefon jest dziś portfelem, kluczem do banku i archiwum zdjęć. Pełny test penetracyjny przy każdym wydaniu jest jednak nierealny. Rozwiązaniem jest stała lista kontroli oparta na standardzie OWASP MASVS, który dzieli wymagania na osiem grup. Część kontroli zespół QA wykona sam, bez specjalistów od bezpieczeństwa.

Kontrole z tabeli warto wpiąć w regresję i powtarzać przy każdym wydaniu. Pełny przegląd raz w roku albo przed dużą zmianą zostawcie specjalistom. Opisujemy go w tekście o testach bezpieczeństwa i testach penetracyjnych, a zakres usługi znajdziecie na stronie testów bezpieczeństwa Quality Island.

Błąd 6: jak ustawić priorytety, gdy nie da się przetestować wszystkiego?

Testowanie wszystkiego po równo kończy się tym, że ścieżka płatności dostaje tyle samo uwagi co ekran „O aplikacji”. Priorytety ustalcie z dwóch osi: jak bardzo zaboli błąd i jak często użytkownik korzysta z danej funkcji. Pomaga w tym zasada Pareto w analizie ryzyka.

Taką tabelę zapiszcie w planie testów i wracajcie do niej po każdym incydencie z produkcji. Jak ją rozpisać na zadania, pokazujemy w artykule o tym, jak napisać plan testów.

Błąd 7: jak symulować słabą sieć, skoro 3G znika z Polski?

Stary zapis „testujcie w sieciach 3G, LTE i 5G” przestał być aktualny. Według benchmark.pl T-Mobile zakończył wygaszanie 3G w 2023 roku, a Orange w listopadzie 2025 roku, zostawiając tę technologię na około 0,5% stacji. Według spidersweb.pl Play planuje wyłączyć 3G w całym kraju do końca 2026 roku, a według komunikatu Polsatu Plus z maja 2026 roku Plus zacznie wyłączanie w grudniu 2026 roku.

Błędy w aplikacji mobilnej związane z siecią widać dopiero w terenie, więc testujcie nie nazwę technologii, tylko warunki: niską przepustowość, duże opóźnienie, utratę pakietów i przełączanie między Wi-Fi a LTE. Do tego dochodzą tryb samolotowy w połowie operacji, windy, parkingi podziemne i publiczne Wi-Fi z ekranem logowania.

# emulator Androida: start z wolnym łączem i dużym opóźnieniem
emulator -avd Pixel_API_36 -netspeed edge -netdelay gprs
# zmiana w trakcie działania (konsola emulatora)
adb emu network speed 14.4 80
adb emu network delay 150 550
adb emu network status

Profile „edge” i „umts” w emulatorze to tylko gotowe zestawy przepustowości, nie prawdziwe sieci. Dobrze nadają się do udawania słabego zasięgu. Na iOS ten sam efekt daje okno Devices and Simulators w Xcode: Apple pokazało tam warunek Network Link i stan termiczny urządzenia na sesji WWDC 2019. Na Macu dla symulatora użyjcie narzędzia Network Link Conditioner.

Użytkownik nie zgłosi Wam, że „aplikacja źle obsługuje utratę pakietów”. Napisze w sklepie, że „nic nie działa w pociągu”, i da jedną gwiazdkę. Dlatego scenariusze z kart warto mieć w regresji, a nie w pamięci jednego testera.

Jak złożyć te siedem lekcji w jeden plan testów?

Wszystkie siedem błędów ma wspólny mianownik: proces testów skrojony pod web, a nie pod telefon w kieszeni. U naszych klientów najlepiej działa prosta kolejność. Najpierw dane o urządzeniach, potem analiza ryzyka, na końcu automatyzacja tego, co powtarzalne.

1. Zbierzcie dane o urządzeniach i zbudujcie trzypoziomową matrycę.
2. Rozpiszcie ryzyka i dopasujcie głębokość testów do każdego obszaru.
3. Dopiszcie przerwania, Doze i słabą sieć do każdej ścieżki krytycznej.
4. Testujcie aktualizację z danymi, nie tylko świeżą instalację.
5. Kontrole MASVS wepnijcie w regresję na stałe.
6. Automatyzujcie powtarzalne ścieżki, a eksplorację zostawcie ludziom.

Powtarzalne błędy w aplikacji mobilnej najtaniej łapie automatyzacja. Wybierzcie narzędzie pasujące do zespołu. Porównanie Appium, Espresso, XCUITest i Maestro znajdziecie w tekście o narzędziach do automatyzacji testów aplikacji mobilnych. Jeśli wolicie nauczyć się tego w praktyce, prowadzimy szkolenie Testowanie manualne aplikacji mobilnych oraz kurs automatyzacji testów mobilnych w Appium (Java).

Gdy budujecie pierwszą wersję produktu i budżet na testy jest mały, przyda się też tekst na Strefie QA o tym, co testować w MVP, żeby nie zabić pomysłu błędem.

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, które chronią ocenę w sklepie
• Testowanie aplikacji mobilnych część 2: rodzaje i typy testów
• Narzędzia do automatyzacji testów aplikacji mobilnych: Appium, Espresso, XCUITest, Maestro
• Sauce Labs i BrowserStack: chmurowe platformy do testów cross-browser i cross-device

Pełna lista źródeł

• Google, Android Developers, Android vitals, 2026. Stąd progi 1,09% awarii, 0,47% ANR i 8% na model telefonu oraz konsekwencje dla widoczności w Google Play.
• StatCounter Global Stats, Mobile Operating System Market Share Poland, wrzesień 2025 i wrzesień 2026, odczyt 11.10.2026. Stąd udziały Androida i iOS, wersji systemu, producentów i rozdzielczości.
• Google, Android Developers, Optimize for Doze and App Standby, 2026. Stąd polecenia adb do testów Doze i App Standby.
• Google, Android Developers, Send emulator console commands, 2026. Stąd polecenia network speed, network delay, gsm call i power capacity.
• Google, Android Developers, Migrate your Room database, 2026. Stąd opis MigrationTestHelper i testów migracji.
• Google, Android Developers, Meet Google Play’s target API level requirement, 2026. Stąd wymóg API 36 dla nowych aplikacji i aktualizacji od 31 sierpnia 2026 roku.
• OWASP, Mobile Application Security Verification Standard (MASVS), 2026. Stąd osiem grup wymagań bezpieczeństwa aplikacji mobilnych.
• Apple, Debugging in Xcode 11, WWDC 2019, 2019. Stąd warunki urządzenia Network Link i stan termiczny w oknie Devices and Simulators.
• benchmark.pl, Już drugi operator w Polsce wyłączył 3G, 1 grudnia 2025. Stąd terminy wyłączenia 3G w T-Mobile i Orange.
• spidersweb.pl, Play wyłącza 3G: harmonogram na 2026 rok, 14 kwietnia 2026. Stąd plan Play wyłączenia 3G do końca 2026 roku.
• Grupa Polsat Plus, Plus to begin switching off the 3G network in December 2026, 5 maja 2026. Stąd start wyłączania 3G w sieci Plus.
• Dane własne Quality Island, 2026: case study Autono z liczbami potwierdzonymi przez klienta.