Na tej stronie znajdziesz pomoc w rozwiązywaniu problemów oraz odpowiedzi na często zadawane pytania dotyczące przeprowadzania testów w laboratorium testowym Firebase. 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 w Firebase Slack lub skontaktuj się z pomocą techniczną Firebase .
Rozwiązywanie problemów
Jeśli w katalogu Laboratorium Testowego wybierzesz urządzenie o wysokim poziomie wydajności, testy mogą rozpocząć się szybciej. Jeśli urządzenie ma małą pojemność, testy mogą zająć więcej czasu. Jeśli liczba wywołanych testów jest znacznie większa niż pojemność wybranych urządzeń, zakończenie testów może zająć więcej czasu.
Testy przeprowadzane na dowolnym poziomie wydajności urządzenia mogą potrwać dłużej z następujących powodów:
- Ruch, który wpływa na dostępność urządzenia i szybkość testu.
- Awarie urządzeń lub infrastruktury, które mogą wystąpić w dowolnym momencie. Aby sprawdzić, czy istnieje zgłoszona infrastruktura dla Laboratorium Testowego, zobacz panel stanu Firebase .
Aby dowiedzieć się więcej o pojemności urządzenia w laboratorium testowym, zapoznaj się z informacjami o pojemności urządzenia dla systemów Android i iOS .
Niejednoznaczne wyniki testów często powstają z powodu anulowania testów lub błędów w infrastrukturze.
Błędy infrastruktury są spowodowane problemami wewnętrznymi laboratorium testowego, takimi jak błędy sieciowe lub nieoczekiwane zachowania urządzeń. Laboratorium testowe wewnętrznie wycofuje przebiegi testowe, które wielokrotnie powodowały błędy w infrastrukturze, zanim zgłoszą niejednoznaczny wynik; można jednak wyłączyć te ponowne próby za pomocą funkcji Fast .
Aby ustalić przyczynę błędu, wykonaj następujące kroki:
- Sprawdź znane awarie w panelu stanu Firebase .
Ponów test w laboratorium testowym, aby sprawdzić, czy jest on powtarzalny.
Spróbuj uruchomić test na innym urządzeniu lub typie urządzenia, jeśli ma to zastosowanie.
Jeśli problem będzie się powtarzał, skontaktuj się z zespołem Test Lab na kanale #test-lab w Firebase Slack.
Fragmentowanie może spowodować wydłużenie czasu trwania testów, jeśli określona liczba fragmentów przekracza liczbę urządzeń dostępnych do użycia w laboratorium testowym. Aby uniknąć tej sytuacji, spróbuj przełączyć się na inne urządzenie. Aby uzyskać więcej informacji na temat wybierania innego urządzenia, zobaczPojemność urządzenia .
Kiedy przesyłasz prośbę o test, Twoja aplikacja jest najpierw sprawdzana, ponownie podpisana itp. w ramach przygotowań do uruchomienia testów na urządzeniu. Zwykle proces ten trwa krócej niż kilka sekund, ale mogą na niego wpływać takie czynniki, jak rozmiar aplikacji.
Po przygotowaniu aplikacji zaplanowane są wykonania testów, które pozostają w kolejce do czasu, aż urządzenie będzie gotowe do jej uruchomienia. Dopóki wszystkie wykonania testów nie zostaną zakończone, macierz będzie miała status „Oczekująca” (niezależnie od tego, czy wykonania testów znajdują się w kolejce, czy są aktywnie uruchomione).
Po zakończeniu wykonywania testu artefakty testowe są pobierane z urządzenia, przetwarzane i przesyłane do Cloud Storage. Na czas trwania tego kroku może mieć wpływ ilość i rozmiar artefaktów.
Artefakty wykonania testu (takie jak zrzuty ekranu i pliki dziennika) są przechowywane w Google Cloud Storage i bezpośrednio renderowane w konsoli Firebase. Jeśli wykonanie testu zostało wykonane w ciągu ostatnich 90 dni, sprawdź, czy przypisałeś role na poziomie projektu (właściciel projektu, redaktor projektu lub przeglądający projekt). Upewnij się również, że w Twoim projekcie lub organizacji nie jest włączone rejestrowanie inspekcji w chmurze.
Jeśli wykonanie zostało wykonane ponad 90 dni temu, najprawdopodobniej artefakty testowe zostały automatycznie usunięte. Możesz sprawdzić konfigurację zasobnika wyników, klikając kartę Wyniki testów na pulpicie nawigacyjnym laboratorium testowego. Domyślny zasobnik wyników jest skonfigurowany tak, aby przechowywać obiekty przez 90 dni.
Aby dłużej zachować artefakty testowe, uruchom polecenie gcloud firebase test android run
z flagą --results-bucket
i podaj nazwę segmentu wyników. Aby uzyskać więcej informacji, odwiedź dokumentację referencyjną gcloud firebase test android run
.
Po uruchomieniu testów oprzyrządowania mogą zostać wyświetlone błędy testów wskazujące częściowe wyniki zawierające komunikaty typu: Test run failed to complete. Expected x tests, received y
(gdzie y
jest mniejsze niż x
). Ten błąd oznacza, że laboratorium testowe nie mogło przeanalizować logcat pod kątem znaczników początku i końca przypadku testowego, które są zwykle generowane przez AndroidJUnitRunner .
Oto typowe przyczyny tego problemu:
Opis problemu | Możliwe rozwiązanie |
---|---|
Przypadek testowy nie został uruchomiony z powodu przekroczenia limitu czasu. Jeśli całkowity czas trwania testów jest dłuższy niż określony limit czasu lub dłuższy niż maksymalny limit czasu , Laboratorium testowe anuluje pozostałe przypadki testowe. |
|
Przypadek testowy nie został ukończony, ponieważ zakończył się przedwcześnie lub utknął. Przypadek testowy może zakończyć się przedwcześnie z powodu nieprzechwyconego wyjątku lub błędu asercji. Przypadki testowe mogą utknąć w nieskończonej pętli lub nie być w stanie kontynuować działania, na przykład, jeśli aplikacja nie wyświetla prawidłowego widoku, a przypadek testowy nie może wykonać akcji w interfejsie użytkownika. | Obejrzyj wideo i logcat aby sprawdzić, gdzie zakończył się test. |
Niestandardowy moduł uruchamiający test (w tym rozszerzający AndroidJUnitRunner) nieoczekiwanie uległ awarii lub zapisał nieoczekiwane znaczniki początku lub końca przypadku testowego w logcat . | Sprawdź swój kod osoby uruchamiającej test. |
Do logcat zapisano zbyt dużo logów, co przeciążyło bufor lub spowodowało awarię procesu logcat . | Zmniejsz liczbę zapisów do logcat . |
Testowana aplikacja uległa awarii. | Debuguj swoją aplikację. |
Często Zadawane Pytania
Firebase Test Lab oferuje bezpłatne limity na testowanie na urządzeniach i korzystanie z Cloud API. Należy pamiętać, że limit testowy wykorzystuje standardowy plan cenowy Firebase, podczas gdy limity Cloud API nie.
Limit testowy
Limity testowania są określane na podstawie liczby urządzeń używanych do przeprowadzania testów. Plan Firebase Spark ma stały limit bezpłatnych testów dla użytkowników. W przypadku planu Blaze Twoje limity mogą wzrosnąć, jeśli z czasem zwiększy się wykorzystanie Google Cloud. Jeśli osiągniesz limit testów, poczekaj do następnego dnia lub przejdź na plan Blaze, jeśli obecnie korzystasz z planu Spark. Jeśli korzystasz już z planu Blaze, możesz poprosić o zwiększenie limitu. Aby uzyskać więcej informacji, zobacz Limit testowania .
Możesz monitorować wykorzystanie limitu testowego w konsoli Google Cloud .
Limit interfejsu API do testowania w chmurze
Interfejs Cloud Testing API ma dwa limity przydziału: żądania dziennie na projekt i żądania na każde 100 sekund na projekt. Możesz monitorować swoje wykorzystanie w konsoli Google Cloud .
Limit interfejsu API wyników narzędzia Cloud Tool
Interfejs API Cloud Tool Results API ma dwa limity: liczba zapytań dziennie na projekt i liczba zapytań co 100 sekund na projekt. Możesz monitorować swoje wykorzystanie w konsoli Google Cloud .
Więcej informacji na temat limitów API można znaleźć w artykule Limity Cloud API dla laboratorium testowego . Jeśli osiągnąłeś limit API:
Prześlij prośbę o większe limity , edytując je bezpośrednio w konsoli Google Cloud (pamiętaj, że większość limitów jest domyślnie ustawiona na maksimum) lub
Poproś o wyższe limity API, wypełniając formularz żądania w konsoli Google Cloud lub kontaktując się z pomocą techniczną Firebase .
Z poziomu swojego zaplecza możesz określić, czy ruch pochodzi z urządzeń testowych hostowanych w Firebase, porównując źródłowy adres IP z naszymi zakresami adresów IP .
Laboratorium testowe nie współpracuje z VPC-SC, które blokuje kopiowanie aplikacji i innych artefaktów testowych między pamięcią wewnętrzną laboratorium testowego a zasobnikami wyników użytkowników.
Aby wykryć niestabilne zachowanie w testach, zalecamy użycie opcji--num-flaky-test-attempts. Ponowne uruchomienia Deflake są rozliczane lub wliczane do dziennego limitu w taki sam sposób, jak normalne wykonania testów.
Pamiętaj o następujących kwestiach:
- Całe wykonanie testu jest uruchamiane ponownie po wykryciu błędu. Nie ma obsługi ponawiania tylko nieudanych przypadków testowych.
- Ponowne próby Deflake są zaplanowane w tym samym czasie, ale nie ma gwarancji, że będą działać równolegle, na przykład gdy ruch przekracza liczbę dostępnych urządzeń.
Tak! Laboratorium testowe obsługuje zegarek Google Pixel. Możesz teraz przeprowadzać testy samodzielnej aplikacji Wear na zegarkach Google Pixel. Aby dowiedzieć się więcej o urządzeniach Laboratorium testowego, zobacz Testowanie na dostępnych urządzeniach .
Tak! Laboratorium testowe obsługuje tablety Google Pixel i Google Pixel Fold. Możesz uruchamiać testy na samodzielnych urządzeniach fizycznych. Aby dowiedzieć się więcej o urządzeniach Laboratorium testowego, zobacz Testowanie na dostępnych urządzeniach .
Jeśli testujesz aplikację w Firebase lub przeprowadzasz testy raportu przed opublikowaniem w Konsoli Play, możesz wykryć, czy test jest uruchamiany na urządzeniu hostowanym w Firebase, sprawdzając właściwość systemową firebase.test.lab
w Twój plik MainActivity
. Następnie możesz wykonać dodatkowe instrukcje w oparciu o wartość logiczną testLabSetting
. Aby uzyskać więcej informacji, zobacz temat Zmodyfikowane zachowania testowe .
Chociaż niektóre z tych elementów znajdują się w naszym planie działania, obecnie nie jesteśmy w stanie zapewnić wsparcia dla tych platform testowania i tworzenia aplikacji. Jeśli jednak zbudowałeś aplikację przy użyciu platformy obsługującej Espresso (na przykład Flutter), możesz napisać test oprzyrządowania przy użyciu Espresso , a następnie uruchomić test w laboratorium testowym.
Laboratorium testowe nie obsługuje jawnie zaciemniania ani usuwania zaciemnień. Chociaż aplikacja prawdopodobnie będzie działać, wszelkie zaciemnione dane aplikacji, takie jak ślady stosu, będą widoczne w dziennikach jako zaciemnione.
Tak! Możesz przetestować swoje składane urządzenie w stanie i pozycji złożonej .
Urządzenia składane mogą znajdować się w różnych stanach złożenia, np. FLAT
(całkowicie otwarte) lub HALF_OPENED
(pomiędzy całkowicie otwartym a całkowicie zamkniętym).
Z drugiej strony pozycje obejmują określoną orientację urządzenia i stan złożenia. Na przykład postawa blatu, która jest stanem HALF_OPENED
w orientacji poziomej, lub pozycja książki, która jest stanem HALF_OPENED
w orientacji pionowej.
Jeśli przeprowadzasz testy oprzyrządowania, możesz użyć biblioteki Jetpack WindowManager i przetestować swoją aplikację na dokumentacji składanych , aby przetestować różne stany i postawy.
Alternatywnie dostępne stany są specyficzne dla urządzenia i można z nimi wchodzić w interakcję 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}, ]
W przeciwieństwie do innych produktów Firebase, aby korzystać z laboratorium testowego, nie musisz dodawać pakietu SDK Firebase. Jeśli nie masz jeszcze aplikacji, możesz pobrać plik APK online lub zbudować aplikację i testowy plik APK z jednego z przykładów w repozytorium AndroidX GitHub . Pamiętaj, że do uruchomienia testu Robo potrzebny jest tylko plik APK aplikacji, podczas gdy test oprzyrządowania wymaga zarówno aplikacji, jak i testowego pliku APK utworzonych z kodu źródłowego. Aby uzyskać więcej informacji, przeczytaj o testach instrumentalnych .
Aby dowiedzieć się więcej o funkcjach Laboratorium testowego, zobacz Rozpoczęcie testowania systemu Android w laboratorium testowym Firebase .
Testowanie porównawcze zrzutów ekranu polega na tym, że twierdzenia testowe opierają się na porównaniu obrazów ekranowych uzyskanych podczas wykonywania testu ze złotymi obrazami przedstawiającymi oczekiwane zachowanie. Takie testy mogą być bardziej kruche na niektórych typach urządzeń niż na innych. Do tego rodzaju testów zalecamy kierowanie na urządzenia emulujące Arm ( *.arm
). Urządzenia emulujące ARM używają obrazów, które są bardzo podobne lub identyczne z „ogólnymi” emulatorami Android Studio.
Zalecamy również zapoznanie się z bibliotekami testowymi, które mogą pomóc w zwiększeniu niezawodności testów zrzutów ekranu w obecności oczekiwanych zmian.
Tak! Urządzenia wirtualne są aktualizowane po wprowadzeniu następujących zmian:
- Aktualizacje istniejących obrazów
- Wycofanie wcześniejszych poziomów API
- Dodano nowe poziomy API systemu Android
Aby włączyć raporty zasięgu, dodaj coverage=true
do pola environmentVariables
. Jeśli używasz Android Test Orchestrator, musisz podać katalog do przechowywania wyników pokrycia:
--environment-variables coverage=true,coverageFilePath=/sdcard/Download/
Jeśli nie używasz programu Orchestrator, możesz określić ścieżkę pliku:
--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec
Szczegółowe informacje o urządzeniu są dostępne za pośrednictwem interfejsu API i można uzyskać do nich dostęp w kliencie gcloud za pomocą polecenia opisu :
gcloud firebase test android models describe MODEL
Znane problemy
Test Robo nie może ominąć ekranów logowania, które wymagają od użytkownika dodatkowych działań poza wprowadzeniem danych uwierzytelniających w celu zalogowania się, na przykład wykonaniem testu CAPTCHA.
Test Robo działa najlepiej z aplikacjami korzystającymi z elementów interfejsu użytkownika ze struktury interfejsu użytkownika systemu Android (w tym obiektów View
, ViewGroup
i WebView
). Jeśli używasz testu Robo do ćwiczenia aplikacji korzystających z innych struktur interfejsu użytkownika, w tym aplikacji korzystających z silnika gry Unity, test może zakończyć się bez konieczności przekraczania pierwszego ekranu.