Rozwiązywanie problemów z Laboratorium i najczęstsze pytania

iOS Android

Na tej stronie znajdziesz pomoc w rozwiązywaniu problemów oraz odpowiedzi na najczęstsze pytania dotyczące przeprowadzania testów w Laboratorium Firebase. Opisaliśmy też znane problemy. Jeśli nie możesz znaleźć tego, czego szukasz, lub potrzebujesz dodatkowej pomocy, dołącz do #test-lab channel na Slacku Firebase lub skontaktuj się z zespołem pomocy Firebase.

Rozwiązywanie problemów

Dlaczego trwa tak długo test?

Jeśli w katalogu Laboratorium wybierzesz urządzenie o dużej pojemności, testy mogą rozpocząć się szybciej. Gdy urządzenie ma małą wydajność, testy mogą potrwać dłużej. Jeśli liczba wywołanych testów jest znacznie większa niż pojemność wybranych urządzeń, ich wykonanie może potrwać dłużej.

Testy na dowolnym poziomie wydajności urządzenia mogą potrwać dłużej z tych powodów:

• Ruch, który wpływa na dostępność urządzeń i szybkość testu.
• Awarie urządzeń lub infrastruktury, które mogą wystąpić w dowolnym momencie. Aby sprawdzić, czy dla Laboratorium istnieje zgłoszona infrastruktura, otwórz panel stanu Firebase.

Aby dowiedzieć się więcej o pojemności urządzeń w Laboratorium, zapoznaj się z informacjami o pojemności urządzeń z Androidem i iOS.

Dlaczego otrzymuję niejednoznaczne wyniki testu?

Niejednoznaczne wyniki testów często występują z powodu anulowanych testów lub błędów infrastruktury.

Błędy infrastruktury są spowodowane przez wewnętrzne problemy z Laboratorium, np. błędy sieci lub nieoczekiwane działanie urządzeń. Test Lab wewnętrznie wycofuje testy, które wielokrotnie wywołują błędy infrastruktury, zanim przekażemy niejednoznaczny wynik. Możesz jednak wyłączyć takie ponowienia za pomocą metody failFast.

Aby określić przyczynę błędu, wykonaj te czynności:

1. Sprawdź w panelu stanu Firebase, czy występują znane przerwy w działaniu usługi.

2. Ponów test w Laboratorium, aby sprawdzić, czy da się go odtworzyć.

   Uwaga: Laboratorium nie nalicza opłat za błędy w infrastrukturze.

3. W razie potrzeby spróbuj przeprowadzić test na innym urządzeniu lub urządzeniu.

Jeśli problem będzie się powtarzał, skontaktuj się z zespołem Laboratorium w #test-lab w kanale Firebase Slack.

Dlaczego fragmentacja wydłużyła moje testy?

Fragmentacja może wydłużyć czas trwania testów, gdy określona liczba fragmentów przekroczy liczbę urządzeń dostępnych do użycia w Laboratorium. Aby tego uniknąć, spróbuj zmienić urządzenie. Więcej informacji o wybieraniu innego urządzenia znajdziesz w sekcji Pojemność urządzenia.

Dlaczego tak długo uruchamiam test?

Gdy przesyłasz żądanie testowe, Twoja aplikacja jest najpierw weryfikowana, ponownie podpisana itp., aby przygotować ją do testów na urządzeniu. Normalnie ten proces trwa niecałe kilka sekund, ale na jego wpływ mogą mieć różne czynniki, np. rozmiar aplikacji.

Gdy aplikacja jest gotowa, wykonania testów są zaplanowane i pozostają w kolejce do momentu, aż urządzenie będzie gotowe do uruchomienia. Do momentu zakończenia wszystkich wykonań testów stan macierzy będzie oznaczony jako „Oczekujące” (niezależnie od tego, czy wykonania testu znajdują się w kolejce, czy są aktywne).

Uwaga: czas oczekiwania na dostępne urządzenie nie jest wliczany do czasu rozliczeniowego.

Dlaczego tak długo trwa test?

Po zakończeniu testu artefakty są pobierane z urządzenia, przetwarzane i przesyłane do Cloud Storage. Czas trwania tego kroku może zależeć od liczby i rozmiaru artefaktów.

Aplikacja nie zwraca danych i nie może znaleźć zrzutów ekranu

Artefakty wykonania testu (np. zrzuty ekranu i pliki dziennika) są przechowywane w Google Cloud Storage i renderowane bezpośrednio w konsoli Firebase. Jeśli test został przeprowadzony w ciągu ostatnich 90 dni, sprawdź, czy masz przypisane role na poziomie projektu (właściciel projektu, edytujący projekt lub wyświetlający projekt). Sprawdź też, czy w projekcie lub organizacji nie włączono Cloud Audit Logging.

Jeśli wykonanie zostało wykonane ponad 90 dni temu, najprawdopodobniej artefakty testowe zostały usunięte automatycznie. Aby sprawdzić konfigurację zasobnika wyników, kliknij kartę Wyniki testu w panelu Laboratorium. Domyślny zasobnik wyników jest skonfigurowany do przechowywania obiektów przez 90 dni.

Aby dłużej przechowywać artefakty testowe, uruchom polecenie gcloud firebase test android run z flagą --results-bucket i przekaż nazwę zasobnika wyników. Więcej informacji znajdziesz w dokumentacji referencyjnej gcloud firebase test android run.

Dlaczego otrzymuję częściowe lub brakujące wyniki testu dotyczącego narzędzi?

Podczas testów instrumentacji mogą pojawić się błędy testowe wskazujące na częściowe wyniki zawierające takie komunikaty jak Test run failed to complete. Expected x tests, received y (gdzie y ma wartość mniejszą niż x). Ten błąd oznacza, że Laboratorium nie mogło przeanalizować pliku logcat dla znaczników początku lub końca przypadku testowego, które są zwykle generowane przez AndroidJUnitRunner.

Oto najczęstsze przyczyny tego problemu:

Opis problemu	Możliwe rozwiązanie
Przypadek testowy nie został uruchomiony z powodu przekroczenia limitu czasu oczekiwania. Jeśli łączny czas trwania testów przekracza ustawiony przez Ciebie czas oczekiwania lub maksymalny czas oczekiwania, Laboratorium anuluje pozostałe przypadki testowe.	Zwiększ czas oczekiwania macierzy, aby mieć pewność, że wszystkie testy się zakończą. Podziel testy na fragmenty, aby każdy fragment uruchomił podzbiór testów i zakończył je w krótszym czasie. Jeśli masz już włączone fragmentowanie, zwiększ liczbę fragmentów.
Nie udało się ukończyć przypadku testowego, ponieważ zakończyło się ono przedwcześnie lub zacięło. Przypadek testowy może zakończyć się przedwcześnie z powodu nieobsłużonego wyjątku lub błędu asercji. Przypadki testowe mogą utknąć w nieskończonej pętli lub mogą nie kontynuować, jeśli na przykład aplikacja nie wyświetla właściwego widoku, a przypadek testowy nie może wykonać tego działania w interfejsie użytkownika.	Sprawdź film i logcat, aby dowiedzieć się, gdzie test się zakończył.
Niestandardowy mechanizm uruchamiający test (w tym rozszerzenie AndroidJUnitRunner) nieoczekiwanie uległ awarii lub zapisał nieoczekiwane znaczniki początku lub końca przypadku testowego w pliku logcat.	Sprawdź kod mechanizmu uruchamiania testów.
Nadmiarowe logi zostały zapisane w logcat, co spowodowałoby przeciążenie bufora lub awarię procesu logcat.	Zmniejsz liczbę zapisów do logcat.
Testowana aplikacja uległa awarii.	Debuguj aplikację.

Najczęstsze pytania

Jakie są bezpłatne limity w Laboratorium? Co zrobić, gdy mi się skończą?

Laboratorium Firebase oferuje bezpłatne limity do testowania na urządzeniach oraz do korzystania z interfejsów Cloud API. W przypadku limitu testowania stosowany jest standardowy abonament Firebase, a limity interfejsu Cloud API – nie.

• Limit testowania

  Limity testowania są określane na podstawie liczby urządzeń używanych do przeprowadzania testów. Abonament Firebase Spark ma stały limit testowania bez opłat dla użytkowników. W przypadku abonamentu Blaze limity mogą wzrosnąć, jeśli z czasem zwiększy się wykorzystanie Google Cloud. Po osiągnięciu limitu testowania poczekaj do następnego dnia lub przejdź na abonament Blaze, jeśli korzystasz obecnie z abonamentu Spark. Jeśli masz już abonament Blaze, możesz poprosić o zwiększenie limitu. Więcej informacji znajdziesz w artykule o limitach testowania.

  Wykorzystanie limitu testowania możesz monitorować w konsoli Google Cloud.

• Limit Cloud Testing API

  Interfejs Cloud Testing API ma 2 limity: liczbę żądań dziennie na projekt i liczbę żądań na 100 sekund na projekt. Wykorzystanie możesz monitorować w konsoli Google Cloud.

• Limit interfejsu Cloud Tool Results API

  Interfejs Cloud Tool Results API ma 2 limity: liczbę zapytań dziennie na projekt i zapytań na 100 sekund na projekt. Wykorzystanie możesz monitorować w konsoli Google Cloud.

  Więcej informacji o limitach interfejsów API znajdziesz w artykule Limity interfejsu Cloud API w Laboratorium. Po osiągnięciu limitu interfejsu API:

  • Prześlij prośbę o zwiększenie limitów, edytując je bezpośrednio w konsoli Google Cloud (pamiętaj, że większość limitów jest domyślnie ustawiona na wartość maksymalną) lub

  • Poproś o zwiększenie limitów interfejsu API, wypełniając formularz prośby w konsoli Google Cloud lub kontaktując się z zespołem pomocy Firebase.

Jak sprawdzić, czy ruch trafiający do mojego backendu pochodzi z Laboratorium?

Z poziomu backendu możesz określić, czy ruch pochodzi z urządzeń testowych hostowanych przez Firebase, sprawdzając źródłowy adres IP w porównaniu z naszymi zakresami adresów IP.

Czy Laboratorium działa z VPC-SC?

Laboratorium nie działa ze środowiskiem VPC-SC, które blokuje kopiowanie aplikacji i innych artefaktów testowych między wewnętrzną pamięcią masową Laboratorium a zasobnikami wyników użytkowników.

Jak wykrywać niestabilne testy w Laboratorium?

Aby wykryć niestabilne działanie testów, zalecamy użycie opcji --num-flaky-test-attempts . Nierozliczone ponowne uruchomienia są rozliczane lub wliczane do limitu dziennego tak samo jak normalne wykonania testów.

Pamiętaj:

• Całe wykonanie testu jest uruchamiane ponownie po wykryciu błędu. Nie ma możliwości ponawiania tylko nieudanych przypadków testowych.
• Zaplanowane uruchomienia ponawiania będą zaplanowane w tym samym czasie, ale nie będą działać równolegle, na przykład gdy ruch przekroczy liczbę dostępnych urządzeń.

Uwaga: błędy infrastruktury są niezależne od funkcji deflake i nie powodują ponownych uruchomień deflake.

Czy Laboratorium obsługuje urządzenia do noszenia?

Tak. Laboratorium obsługuje zegarek Google Pixel Watch. Teraz na zegarkach Google Pixel Watch możesz przeprowadzać testy w samodzielnej aplikacji na Wear. Więcej informacji o urządzeniach w Laboratorium znajdziesz w sekcji Testowanie na dostępnych urządzeniach.

Czy Laboratorium obsługuje najnowsze urządzenia Google?

Tak. Laboratorium obsługuje urządzenia Google Pixel Tablet i Google Pixel Fold. Możesz przeprowadzać testy na samodzielnych urządzeniach fizycznych. Więcej informacji o urządzeniach w Laboratorium znajdziesz w sekcji Testowanie na dostępnych urządzeniach.

Jak wykryć aktywny test w Laboratorium?

Jeśli testujesz aplikację w Firebase lub przeprowadzasz testy raportu przed opublikowaniem w Konsoli Play, możesz sprawdzić, czy test jest przeprowadzany na urządzeniu hostowanym przez Firebase, sprawdzając właściwość systemową firebase.test.lab w pliku MainActivity. Następnie możesz wykonywać dodatkowe instrukcje na podstawie wartości logicznej testLabSetting. Więcej informacji znajdziesz w artykule Zmodyfikowane działania testowe.

Czy Laboratorium obsługuje aplikacje Appium, Flutter/FlutterDriver, ReactNative/Jest lub Ogórek?

Choć niektóre z nich znajdują się w planach, obecnie nie jesteśmy w stanie zapewnić wsparcia dla tych platform testowania i tworzenia aplikacji. Jeśli jednak Twoja aplikacja korzysta z platformy obsługującej Espresso (np. Flutter), możesz napisać test instrumentacji w Espresso, a potem uruchomić go w Laboratorium.

Czy Laboratorium obsługuje testowanie zaciemnionych aplikacji, np. ProGuard lub R8)?

Laboratorium nie obsługuje bezpośrednio zaciemniania kodu ani usuwania zaciemnienia kodu. Aplikacja prawdopodobnie będzie działać, ale wszelkie zaciemnione dane aplikacji, takie jak zrzuty stosu, będą widoczne w logach jako zaciemnione.

Czy podczas testowania w Laboratorium mogę używać urządzenia składanego w różnych stanach i stanach składanych?

Tak. Urządzenie składane możesz przetestować w stanach i stanach składanych.

Urządzenia składane mogą znajdować się w różnych stanach złożonych, np. FLAT (w pełni otwarte) lub HALF_OPENED (pomiędzy pełnym złożeniem a otwartym).

Z kolei stany składają się z określonej orientacji urządzenia i stanu złożenia. Na przykład stan stołu, czyli stan HALF_OPENEDw orientacji poziomej, lub stan książki, który jest HALF_OPENED w orientacji pionowej.

Jeśli przeprowadzasz testy instrumentacji, możesz użyć biblioteki Jetpack WindowManager i postępować zgodnie z dokumentacją testowania aplikacji na urządzeniach składanych, aby przetestować różne stany i stany.

Dostępne stany są też zależne od urządzenia i można z nich korzystać za pomocą adb shell command cmd device_state.

• Aby wyświetlić bieżący stan, uruchom polecenie adb shell cmd device_state state.
• Aby ustawić lub zastąpić bieżący stan, uruchom polecenie adb shell cmd device_state state <IDENTIFIER>.
• Aby zresetować stan, uruchom polecenie adb shell cmd device_state state reset.
• Aby sprawdzić dostępne stany, uruchom polecenie adb shell cmd device_state print-states na urządzeniu składanym.

Google Pixel Fold (identyfikator modelu: felix)

$ adb shell cmd device_state print-states
Supported states: [
    DeviceState{identifier=0, name='CLOSED', app_accessible=true},
    DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true},
    DeviceState{identifier=2, name='OPENED', app_accessible=true},
    DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true},
]

Samsung Galaxy Z Fold4 (identyfikator modelu q4q)

$ adb shell cmd device_state print-states
Supported states: [
    DeviceState{identifier=0, name='CLOSE', app_accessible=true},
    DeviceState{identifier=1, name='TENT', app_accessible=true},
    DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true},
    DeviceState{identifier=3, name='OPEN', app_accessible=true},
]

Czy mogę skorzystać z Laboratorium, jeśli nie mam aplikacji?

W przeciwieństwie do innych usług Firebase nie musisz dodawać pakietu SDK Firebase, aby korzystać z Laboratorium. Jeśli nie masz jeszcze aplikacji, możesz pobrać plik APK online lub utworzyć aplikację i testowy plik APK z jednego z przykładów z repozytorium AndroidaX na GitHubie. Pamiętaj, że do uruchomienia testu Robo potrzebujesz tylko pliku APK aplikacji, a test instrumentacji wymaga zarówno aplikacji, jak i testowego pakietu APK utworzonego na podstawie kodu źródłowego. Więcej informacji znajdziesz w artykule o testach instrumentowanych.

Więcej informacji o funkcjach Laboratorium Firebase znajdziesz w artykule Pierwsze kroki z testowaniem na Androidzie w Laboratorium Firebase.

Jakie urządzenia są najlepsze do testowania różnic między zrzutami ekranu?

Testy różnic na zrzutach ekranu polegają na porównaniu obrazów ekranu uzyskanych podczas testu ze złotymi obrazami obrazującymi oczekiwane zachowanie. W przypadku niektórych typów urządzeń takie testy mogą być bardziej delikatne niż w przypadku innych. W przypadku tego rodzaju testów zalecamy kierowanie na urządzenia z emulatorami grup (*.arm). Emulatory Armum używają obrazów, które są bardzo podobne do „ogólnych” emulatorów Android Studio lub są identyczne.

Zalecamy też zapoznanie się z bibliotekami testowymi, które mogą w razie potrzeby zapewnić większą skuteczność testów na zrzutach ekranu.

Czy Laboratorium aktualizuje urządzenia wirtualne?

Tak. Urządzenia wirtualne są aktualizowane po wprowadzeniu tych zmian:

1. Aktualizacje dotychczasowych obrazów
2. Wycofanie wcześniejszych poziomów interfejsu API
3. Dodane są nowe poziomy interfejsu API Androida

Jak włączyć raporty o stanie?

Aby włączyć raporty o stanie, dodaj coverage=true do pola environmentVariables. Jeśli korzystasz z narzędzia Android Test Agency, musisz podać katalog, w którym będą przechowywane wyniki pokrycia:

--environment-variables coverage=true,coverageFilePath=/sdcard/Download/

Jeśli nie używasz narzędzia Sessiontor, możesz podać ścieżkę pliku:

--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec

Gdzie znajdę informacje o urządzeniu, takie jak rozdzielczość, obsługiwane interfejsy ABI itp.?

Szczegółowe informacje o urządzeniu są dostępne w interfejsie API. Można je uzyskać z poziomu klienta gcloud za pomocą poleceniadescribe.

gcloud firebase test android models describe MODEL

Znane problemy

Captcha logowania

Test Robo nie może ominąć ekranów logowania, które wymagają od użytkownika dodatkowych działań poza wpisaniem danych logowania, np. przez wykonanie obrazu CAPTCHA.

Obsługa platformy UI

Test Robo działa najlepiej w przypadku aplikacji, które korzystają z elementów interfejsu Androida (w tym obiektów View, ViewGroup i WebView). Jeśli używasz testu Robo do testowania aplikacji, które korzystają z innych struktur interfejsu, w tym tych, które używają silnika gier Unity, test może zakończyć się bez przejścia do pierwszego ekranu.