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

iOS Android

Na tej stronie znajdziesz porady dotyczące rozwiązywania problemów oraz odpowiedzi na najczęstsze pytania dotyczące przeprowadzania testów za pomocą Firebase Test Lab. Znane problemy są też 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ą rozpocząć się 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 potrwać 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ądzeń 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 przez wewnętrzne problemy Test Lab, takie 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ąć, spróbuj zmienić urządzenie. Więcej informacji o wybieraniu innego urządzenia znajdziesz w sekcji Pojemność urządzenia.

Dlaczego rozpoczęcie testu trwa tak długo?

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 krócej niż 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. 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 tak długo trwa test?

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

Artefakty wykonania testu (takie jak zrzuty ekranu i pliki dziennika) są przechowywane w Google Cloud Storage i renderowane 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 mogą wystąpić 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 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 ustawiony przez Ciebie czas oczekiwania lub maksymalny czas oczekiwania, Test Lab 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 fragmentacja jest już włączona, zwiększ liczbę fragmentów.
Nie udało się ukończyć przypadku testowego, 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 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 test runnera.
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.	Debugowanie aplikacji.

Najczęstsze pytania

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

Firebase Test Lab oferuje bezpłatne limity testowania na urządzeniach i korzystania z interfejsów Cloud API. W przypadku limitu testowania stosowany jest standardowy abonament Firebase, a limity interfejsu 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 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. 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 testowania możesz monitorować w konsoli Google Cloud.

• Limit Cloud Testing API

  Interfejs Cloud Testing API ma 2 limity: żądań dziennie na projekt i żądań co 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: zapytań na dzień na projekt oraz zapytań co 100 sekund na projekt. Możesz monitorować swoje wykorzystanie w konsoli Google Cloud.

  Więcej informacji o limitach interfejsu API znajdziesz w artykule Limity interfejsu Cloud API w 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 (zazwyczaj większość limitów jest ustawiona na maksymalną wartość domyślną).

  • 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 mogę sprawdzić, czy ruch docierający do mojego backendu pochodzi z Test Lab?

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

Czy Test Lab współpracuje 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 wyświetlenia 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 testowania 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ń.

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

Czy usługa 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 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 mogę wykryć aktywny test w narzędziu Test Lab?

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. W tym celu sprawdź właściwość systemową firebase.test.lab w pliku MainActivity. Następnie możesz wykonać dodatkowe instrukcje na podstawie wartości logicznej wyrażenia testLabSetting. Więcej informacji znajdziesz w artykule o zmodyfikowanych 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?

Metoda Test Lab nie obsługuje bezpośrednio zaciemniania kodu ani odczytywania jego zaciemnionego 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 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 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 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ę wypróbować Test Lab, jeśli nie mam aplikacji?

W przeciwieństwie do innych usług Firebase nie musisz dodawać pakietu SDK Firebase, aby używać Test Lab. 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 między zrzutami ekranu polega na porównywaniu zrzutów ekranu uzyskanych podczas testu do złotych obrazów przedstawiających oczekiwane działanie. W przypadku niektórych typów urządzeń testy takie mogą być bardziej delikatne 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 testowymi, które mogą w razie potrzeby zapewnić większą skuteczność testów na zrzutach ekranu.

Czy Test Lab 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. 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 interfejsy ABI itp.?

Szczegółowe informacje o urządzeniu są dostępne za pomocą interfejsu API i można je uzyskać z klienta gcloud, używając 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, np. 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 struktur interfejsu, w tym tych, które używają silnika gier Unity, test może zakończyć się bez przejścia do pierwszego ekranu.