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

iOS Android

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

Dlaczego test trwa tak długo?

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ń, testy mogą trwać dłużej.

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.

Dlaczego otrzymuję niejednoznaczne wyniki testów?

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łosiły 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 programie Test Lab, aby sprawdzić, czy można go odtworzyć.

   Uwaga: Test Lab nie pobiera opłat za błędy infrastruktury.

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.

Dlaczego po podzieleniu na fragmenty testy trwały dłużej?

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.

Dlaczego rozpoczęcie testu trwa tak długo?

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, gdy urządzenie będzie gotowe do jej 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).

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

Dlaczego testowanie trwa tak długo?

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.

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

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 testu 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.

Dlaczego otrzymuję częściowe lub brakujące wyniki testów przypadków użycia?

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 kończył się 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

Jakie są bezpłatne limity Test Lab? Co mam zrobić, gdy skończą mi się środki?

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 biegiem czasu 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.

• Limity 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 domyślnie większość limitów jest 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.

Jak mogę sprawdzić, czy ruch docierający do mojego backendu pochodzi z Test Lab?

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

Czy Test Lab działa z VPC-SC?

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.

Jak wykryć niestabilne testy w Test Lab?

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

Pamiętaj:

• Po wykryciu błędu cały test jest ponownie wykonywany. 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ń.

Uwaga: błędy infrastruktury są niezależne od funkcji deflake i nie powodują ponownego wykonywania deflake.

Czy Test Lab obsługuje urządzenia do noszenia?

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 artykule Testowanie na dostępnych urządzeniach.

Czy Test Lab obsługuje najnowsze urządzenia Google?

Tak. Test Lab obsługuje urządzenia 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 artykule Testowanie na dostępnych urządzeniach.

Jak wykryć uruchomiony test w Test Lab?

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 wyrażenia testLabSetting. Więcej informacji znajdziesz w modyfikowanych zachowaniach testów.

Czy Test Labobsługuje Appium, Flutter/FlutterDriver, ReactNative/Jest czy Cucumber?

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.

Czy Test Labobsługuje testowanie aplikacji zaciemnionych np. za pomocą ProGuard lub R8?

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.

Czy podczas testowania na Test Lab mogę używać składanego urządzenia w różnych stanach i pozycjach?

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, pozycja na stole, która jest stanem HALF_OPENED w orientacji poziomej, lub pozycja na książce, która 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)

$ 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ę wypróbować Test Lab, jeśli nie mam aplikacji?

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.

Jakie urządzenia są najlepsze do testowania różnic na podstawie zrzutów ekranu?

Testowanie różnic na podstawie zrzutów ekranu polega na porównywaniu zrzutów ekranu uzyskanych podczas testu do złotych obrazów przedstawiających 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.

Czy Test Lab aktualizuje urządzenia wirtualne?

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

Jak włączyć raporty dotyczące zasięgu?

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 określić ścieżkę do pliku:

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

Gdzie znajdę szczegóły urządzenia, takie jak rozdzielczość, obsługiwane ABI itp.?

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

Captcha logowania

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.

Obsługa platformy interfejsu

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.