Rozwiązywanie problemów z Laboratorium Najczęstsze pytania

Na tej stronie znajdziesz porady dotyczące rozwiązywania problemów i odpowiedzi na najczęstsze pytania dotyczące przeprowadzania testów za pomocą Firebase Test Lab. Znane problemy są również udokumentowane. Jeśli nie możesz znaleźć tego, czego szukasz, lub potrzebujesz dodatkowej pomocy, dołącz do kanału #test-lab na Slacku Firebase lub skontaktuj się z zespołem pomocy Firebase.

Rozwiązywanie problemów

Jeśli w katalogu Test Lab wybierzesz urządzenie o dużej pojemności, testy mogą się uruchamiać szybciej. Jeśli urządzenie ma małą pojemność, 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 zająć więcej czasu.

Testy przeprowadzane na dowolnym poziomie pojemności urządzenia mogą trwać dłużej z powodu tych czynników:

  • Ruch, który wpływa na dostępność urządzenia i szybkość testu.
  • awarie urządzenia lub infrastruktury, które mogą wystąpić w dowolnym momencie. Aby sprawdzić, czy zgłoszono infrastrukturę dla usługi Test Lab, otwórz Panel stanu Firebase.

Więcej informacji o pojemności urządzenia w Test Lab znajdziesz w artykule o Androidzie i iOS.

Niejednoznaczne wyniki testów występują zwykle z powodu anulowania uruchomień testów lub błędów infrastruktury.

Błędy infrastruktury są spowodowane wewnętrznymi problemami Test Lab, takimi jak błędy sieci lub nieoczekiwane działanie urządzenia. Test Lab wycofuje wewnętrznie testy, które wielokrotnie wygenerowały błędy infrastruktury, zanim zgłoszą niejednoznaczne wyniki. Możesz jednak wyłączyć te próby za pomocą parametru failFast.

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

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

  2. Ponownie przeprowadź test w Test Lab, aby sprawdzić, czy można go odtworzyć.

  3. Spróbuj wykonać test na innym urządzeniu lub typie urządzenia (w stosownych przypadkach).

Jeśli problem będzie się powtarzał, skontaktuj się z zespołem Test Lab na kanale#test-lab na Slacku Firebase.

Fragmentacja może wydłużyć czas wykonywania testów, jeśli podana liczba fragmentów przekracza liczbę urządzeń dostępnych do użycia w Test Lab. Aby tego uniknąć, użyj innego urządzenia. Więcej informacji o wybieraniu innego urządzenia znajdziesz w artykule Pojemność urządzenia.

Gdy przesyłasz żądanie testu, aplikacja jest najpierw weryfikowana, ponownie podpisywana itp. w celu przygotowania jej do przeprowadzania testów na urządzeniu. Zwykle zajmuje to mniej niż kilka sekund, ale może zależeć od takich czynników jak rozmiar aplikacji.

Gdy aplikacja jest gotowa, testy są planowane i pozostają w kolejce do momentu, aż urządzenie będzie gotowe do ich uruchomienia. Dopóki nie zakończą się wszystkie wykonania testu, stan macierzy będzie „Oczekujący” (niezależnie od tego, czy wykonania testu są w kolejce czy są aktywnie wykonywane).

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

Elementy wykonania testu (np. zrzuty ekranu i pliki dziennika) są przechowywane w Google Cloud Storage i wyświetlane bezpośrednio w konsoli Firebase. Jeśli wykonanie testu zostało przeprowadzone w ciągu ostatnich 90 dni, sprawdź, czy masz przypisane role na poziomie projektu (właściciel projektu, edytujący projekt lub przeglądający projekt). Sprawdź też, czy w projekcie lub organizacji nie jest włączona usługa Cloud Audit Logging.

Jeśli wykonanie zostało przeprowadzone ponad 90 dni temu, prawdopodobnie artefakty testów zostały automatycznie usunięte. Konfigurację zbiornika wyników możesz sprawdzić na karcie Wyniki testu w panelu Test Lab. Domyślny zasobnik wyników jest skonfigurowany tak, aby przechowywać obiekty przez 90 dni.

Aby zachować artefakty testu na dłużej, 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.

Podczas wykonywania testów pomiarowych możesz zobaczyć błędy testów wskazujące na częściowe wyniki zawierające komunikaty takie jak Test run failed to complete. Expected x tests, received y (gdzie y jest mniejsze niż x). Ten błąd oznacza, że Test Lab nie może przeanalizować logcat pod kątem znaczników początku i końca przypadku testu, 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. Jeśli łączny czas trwania testów przekracza określony przez Ciebie czas oczekiwania lub maksymalny czas oczekiwania, Test Lab anuluje pozostałe przypadki testowe.
  • Zwiększ limit czasu dla macierzy, aby mieć pewność, że wszystkie testy zostaną ukończone.
  • Podziel testy na fragmenty (jeśli jeszcze tego nie zrobiono), aby każdy fragment przeprowadzał mniejszą część testów i zakończył je w krótszym czasie.
  • Jeśli fragmentacja jest już włączona, zwiększ liczbę fragmentów.
Nie udało się ukończyć przypadku testu, ponieważ został on zamknięty przedwcześnie lub utknął. Przypadek testowy może zostać zamknięty przedwcześnie z powodu nieprzechwyczonej wyjątku lub błędu stwierdzenia. Przypadki testowe mogą utknąć w nieskończonej pętli lub nie być w stanie kontynuować, np. gdy aplikacja nie wyświetla prawidłowego widoku i przypadek testowy nie może wykonać działania w interfejsie. Sprawdź film i logcat, aby dowiedzieć się, gdzie test się zakończył.
niestandardowy mechanizm uruchamiania testów (w tym rozszerzenie AndroidJUnitRunner) uległ nieoczekiwanie awarii lub do pliku logcat dopisał nieoczekiwane znaczniki rozpoczęcia lub zakończenia przypadku testowego. Sprawdź kod test runnera.
Do pliku logcat zapisano zbyt dużo dzienników, co spowodowało przeciążenie bufora lub zablokowanie procesu logcat. Zmniejsz liczbę zapisów do logcat.
Testowana aplikacja uległa awarii. Debugowanie aplikacji.

Najczęstsze pytania

Firebase Test Lab oferuje bezpłatne limity na testowanie na urządzeniach i korzystanie z interfejsów Cloud API. Pamiętaj, że limit testowy korzysta ze standardowego planu cenowego Firebase, a interfejs Cloud API nie.

  • Testowanie limitu

    Limity testów są określane na podstawie liczby urządzeń używanych do przeprowadzania testów. Abonament Firebase Spark ma stały limit testów, który jest bezpłatny dla użytkowników. W przypadku abonamentu Blaze limity mogą wzrosnąć, jeśli z czasem wzrośnie wykorzystanie Google Cloud. Jeśli osiągniesz limit testów, zaczekaj do następnego dnia lub przejdź na abonament Blaze, jeśli obecnie korzystasz z abonamentu Spark. Jeśli korzystasz już z abonamentu Blaze, możesz poprosić o zwiększenie limitu. Więcej informacji znajdziesz w artykule Testowanie limitu.

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

  • Limit interfejsu Cloud Testing API

    Interfejs Cloud Testing API ma 2 limity: żądań dziennie na projekt i żądań co 100 sekund na projekt. Możesz monitorować wykorzystanie w konsoli Google Cloud.

  • Limit interfejsu Cloud Tool Results API

    Interfejs Cloud Tool Results API ma 2 limity: zapytań na dzień na projekt oraz zapytań co 100 sekund na projekt. Możesz monitorować wykorzystanie w konsoli Google Cloud.

    Więcej informacji o limitach interfejsu API znajdziesz w limitach Cloud API dla Test Lab. Jeśli osiągnąłeś limit interfejsu API:

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

    • Aby poprosić o większe limity interfejsu API, wypełnij formularz prośby w konsoli Google Cloud lub skontaktuj się z zespołem pomocy Firebase.

Na backendzie możesz sprawdzić, czy ruch pochodzi z urządzeń testowych hostowanych przez Firebase, porównując adres IP źródłowy z naszym zakresem adresów IP.

Test Lab nie działa z VPC-SC, co blokuje kopiowanie aplikacji i innych artefaktów testowych między wewnętrznym miejscem na dane Test Lab a zbiorami wyników użytkowników.

Aby wykryć niestabilne działanie w testach, zalecamy użycie opcji --num-flaky-test-attempts opcji. Powtórne uruchomienia deflake są naliczane lub wliczane do dziennego limitu w taki sam sposób jak normalne wykonania testu.

Pamiętaj:

  • Gdy zostanie wykryty błąd, cała procedura testu zostanie powtórzona. Nie można powtórzyć tylko nieudanych testów.
  • Próby ponownego wykonania deflake są zaplanowane do wykonania w tym samym czasie, ale nie jest gwarantowane, że będą wykonywane równolegle, na przykład gdy ruch przekracza liczbę dostępnych urządzeń.

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

Tak. Test Lab obsługuje Google Pixel Tablet i Google Pixel Fold. Testy możesz przeprowadzać na samodzielnych urządzeniach fizycznych. Więcej informacji o urządzeniach Test Lab znajdziesz w sekcji Testowanie na dostępnych urządzeniach.

Jeśli testujesz aplikację w Firebase lub przeprowadzasz testy na potrzeby raportu przed opublikowaniem w Konsoli Play, możesz sprawdzić, czy test jest wykonywany na urządzeniu hostowanym przez Firebase. Aby to zrobić, sprawdź, czy w pliku MainActivity jest obecna właściwość systemowa firebase.test.lab. Następnie możesz wykonać dodatkowe instrukcje na podstawie wartości logicznej testLabSetting. Więcej informacji znajdziesz w artykule Zmodyfikowane zachowania testów.

Chociaż niektóre z tych elementów są uwzględnione w naszej mapie drogowej, nie możemy obecnie zagwarantować obsługi tych platform testowania i tworzenia aplikacji. Jeśli jednak aplikacja została skompilowana za pomocą frameworka obsługującego Espresso (np. Flutter), możesz napisać test instrumentacji za pomocą Espresso, a następnie uruchomić go w Test Lab.

Test Lab nie obsługuje bezpośrednio zaciemniania ani odzaciemniania. Aplikacja prawdopodobnie się uruchomi, ale wszystkie zaszyfrowane dane aplikacji, takie jak ścieżki stosu, będą zaszyfrowane w dziennikach.

Tak. Możesz przetestować urządzenie składane w różnych stanach i pozycjach składania.

Składane urządzenia mogą być w różnych stanach złożenia, takich jak FLAT (w pełni otwarte) lub HALF_OPENED (pomiędzy całkowicie otwartym a całkowicie zamkniętym).

Z drugiej strony, postawy obejmują konkretne ułożenie urządzenia i stan składania. Na przykład tryb stołu, który jest stanem HALF_OPENED w orientacji poziomej, lub tryb książki, który jest stanem 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 składanych urządzeniach, aby przetestować różne stany i pozycje.

Dostępne stany zależą od urządzenia i można je aktywować za pomocą adb shell command cmd device_state.

  • Aby wyświetlić bieżący stan, uruchom adb shell cmd device_state state.
  • Aby ustawić lub zastąpić bieżący stan, uruchom adb shell cmd device_state state <IDENTIFIER>.
  • Aby zresetować stan, uruchom adb shell cmd device_state state reset.
  • Aby sprawdzić dostępne stany, uruchom na urządzeniu składanym polecenie adb shell cmd device_state print-states.
Google Pixel Fold (identyfikator modelu felix) Samsung Galaxy Z Fold4 (identyfikator modelu: q4q)
$ 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},
]
$ 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},
]

W odróżnieniu od innych usług Firebase do korzystania z Test Lab nie musisz dodawać pakietu SDK Firebase. Jeśli nie masz jeszcze aplikacji, możesz pobrać plik APK online lub utworzyć aplikację i plik APK testowy na podstawie jednego z próbek w repozytorium AndroidX na GitHubie. Pamiętaj, że do wykonania testu Robo wystarczy plik APK aplikacji, podczas gdy testowanie z użyciem narzędzia do pomiaru wydajności wymaga zarówno aplikacji, jak i pliku APK testowego skompilowanego na podstawie kodu źródłowego. Więcej informacji znajdziesz w artykule Testy z użyciem pomiarów.

Więcej informacji o funkcjach Test Lab znajdziesz w artykule Rozpoczęcie testowania na Androidzie za pomocą Firebase Test Lab.

Testy różnic w zrzutach ekranu polegają na porównywaniu zrzutów ekranu uzyskanych podczas testu z zrzutami ekranu złotego standardu, które odzwierciedlają oczekiwane działanie. Takie testy mogą być bardziej niestabilne na niektórych typach urządzeń niż na innych. W przypadku tego typu testów zalecamy kierowanie na urządzenia z procesorem ARM (*.arm). Urządzenia emulatora ARM korzystają z obrazów, które są bardzo podobne lub identyczne z „uniwersalnymi” emulatorami Android Studio.

Zalecamy też zapoznanie się z bibliotekami testów, które mogą pomóc w zwiększeniu niezawodności testów zrzutów ekranu w przypadku spodziewanych zmian.

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

  1. Aktualizacje dotychczasowych obrazów
  2. Wycofanie starszych poziomów interfejsu API
  3. Dodano nowe poziomy interfejsu API Androida

Aby włączyć raporty dotyczące zasięgu, dodaj coverage=true do pola environmentVariables. Jeśli używasz Android Test Orchestrator, musisz podać katalog, w którym będą przechowywane wyniki testów pokrycia:

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

Jeśli nie używasz Orchestratora, możesz podać ścieżkę do pliku:

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

Szczegółowe informacje o urządzeniu są dostępne przez interfejs API i można je uzyskać z klienta gcloud za pomocą polecenia describe:

gcloud firebase test android models describe MODEL

Znane problemy

Testowanie automatyczne nie może pomijać ekranów logowania, które wymagają dodatkowych działań użytkownika poza wpisaniem danych logowania, na przykład rozwiązania CAPTCHA.

Test Robo działa najlepiej w przypadku aplikacji, które korzystają z elementów interfejsu z ramy interfejsu Androida (w tym obiektów View, ViewGroup i WebView). Jeśli używasz testu Robo do testowania aplikacji, które korzystają z innych frameworków interfejsu użytkownika, w tym aplikacji używających silnika gier Unity, test może się zamknąć bez sprawdzenia treści poza pierwszym ekranem.