Ta strona zawiera pomoc w rozwiązywaniu problemów i odpowiedzi na często zadawane pytania dotyczące przeprowadzania testów w 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 w Firebase Slack lub skontaktuj się z pomocą techniczną Firebase .
Rozwiązywanie problemów
Po wybraniu urządzenia o wysokim poziomie wydajności w katalogu Test Lab testy mogą rozpocząć się szybciej. Gdy urządzenie ma małą pojemność, testy mogą trwać dłużej. Jeśli liczba wywołanych testów jest znacznie większa niż pojemność wybranych urządzeń, ukończenie testów może zająć więcej czasu.
Testy uruchomione na dowolnym poziomie pojemności urządzenia mogą trwać dłużej ze względu na następujące czynniki:
- 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ądzeń w Test Lab, zobacz informacje o pojemności urządzeń z Androidem i iOS .
Niejednoznaczne wyniki testów często pojawiają się z powodu anulowanych przebiegów testów lub błędów infrastruktury.
Błędy infrastruktury są spowodowane wewnętrznymi problemami laboratorium testowego, takimi jak błędy sieci lub nieoczekiwane zachowanie urządzeń. Test Lab wewnętrznie wycofuje przebiegi testów, które wielokrotnie powodują błędy infrastruktury, zanim zgłasza niejednoznaczny wynik; można jednak wyłączyć te ponowne próby, używając metody failFast .
Aby ustalić przyczynę błędu, wykonaj następujące kroki:
- Sprawdź znane awarie w panelu stanu Firebase .
Spróbuj ponownie wykonać test w Laboratorium testowym, aby sprawdzić, czy jest powtarzalny.
Spróbuj uruchomić test na innym urządzeniu lub innym 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.
Dzielenie na fragmenty może spowodować wydłużenie testów, gdy 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 wyboru innego urządzenia, zobaczPojemność urządzenia .
Gdy przesyłasz prośbę o test, Twoja aplikacja jest najpierw weryfikowana, ponownie podpisana itd. w ramach przygotowań do uruchomienia testów na urządzeniu. Zwykle ten proces trwa krócej niż kilka sekund, ale mogą na niego wpływać takie czynniki, jak rozmiar Twojej aplikacji.
Po przygotowaniu aplikacji zaplanowane są wykonania testów, które pozostają w kolejce do momentu, gdy urządzenie będzie gotowe do jej uruchomienia. Dopóki wszystkie wykonania testów nie zakończą się, stan macierzy będzie miał wartość „Oczekująca” (niezależnie od tego, czy wykonania testów są w kolejce, czy aktywnie działają).
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.
Często Zadawane Pytania
Firebase Test Lab oferuje bezpłatne limity testowania na urządzeniach i korzystania z interfejsów Cloud API. Pamiętaj, że przydział testowy korzysta ze standardowego planu cenowego Firebase, podczas gdy limity Cloud API nie.
Kwota testowa
Przydziały testowania są określane na podstawie liczby urządzeń używanych do uruchamiania testów. Plan Firebase Spark ma stały limit testów bez żadnych kosztów dla użytkowników. W przypadku planu Blaze Twoje limity mogą wzrosnąć, jeśli z czasem zwiększy się Twoje 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 testowy .
Wykorzystanie przydziału testowego możesz monitorować w Google Cloud Console .
Limit interfejsu API do testowania w chmurze
Cloud Testing API ma dwa limity przydziału: żądania dziennie na projekt i żądania co 100 sekund na projekt. Możesz monitorować wykorzystanie w Google Cloud Console .
Limit interfejsu Cloud Tool Results
Interfejs Cloud Tool Results API ma dwa limity przydziału: zapytania na dzień na projekt i zapytania na każde 100 sekund na projekt. Możesz monitorować wykorzystanie w Google Cloud Console .
Więcej informacji o limitach API znajdziesz w artykule Limity Cloud API dla Test Lab . Jeśli osiągnąłeś limit API:
Prześlij prośbę o zwiększenie limitów, edytując limity bezpośrednio w Google Cloud Console (zwróć uwagę, że większość limitów jest domyślnie ustawiona na maksimum) lub
Poproś o wyższe limity interfejsu API, wypełniając formularz prośby w Google Cloud Console lub kontaktując się z pomocą techniczną Firebase .
Ze swojego zaplecza możesz określić, czy ruch pochodzi z urządzeń testowych hostowanych przez Firebase, porównując źródłowy adres IP z naszymi zakresami adresów IP .
Test Lab nie współpracuje z VPC-SC, który blokuje kopiowanie aplikacji i innych artefaktów testowych między wewnętrzną pamięcią Test Lab 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 tak samo, jak normalne wykonania testów.
Pamiętaj o następujących kwestiach:
- Całe wykonanie testu jest uruchamiane ponownie po wykryciu awarii. Nie ma obsługi ponawiania prób tylko przypadków testowych zakończonych niepowodzeniem.
- Uruchomienie ponownych prób Deflake jest zaplanowane w tym samym czasie, ale nie ma gwarancji, że będą działać równolegle, na przykład, gdy ruch przekroczy liczbę dostępnych urządzeń.
Chociaż niektóre z tych elementów są na naszej mapie drogowej, obecnie nie jesteśmy w stanie zapewnić wsparcia dla tych platform do testowania i tworzenia aplikacji.
Szczegółowe informacje o urządzeniu są dostępne za pośrednictwem interfejsu API i można uzyskać do nich dostęp z poziomu klienta gcloud za pomocą polecenia opisującego :
gcloud firebase test ios models describe MODEL
Dzielenie na fragmenty nie jest natywnie obsługiwane w ramach Test Lab dla systemu iOS. Możesz jednak użyć klienta Flank do podzielenia przypadków testowych systemu iOS.
Działa to poprzez ustawienie klucza i wartości OnlyTestIdentifiers w pliku .xctestrun . Zobacz stronę man dla xcodebuild.xctestrun , aby uzyskać więcej informacji.
Znane problemy
Test Robo nie może ominąć ekranów logowania, które wymagają dodatkowych działań użytkownika poza wprowadzeniem poświadczeń w celu zalogowania się, na przykład wypełnienia CAPTCHA.
Test Robo działa najlepiej z aplikacjami, które używają elementów interfejsu użytkownika z platformy interfejsu użytkownika systemu Android (w tym obiektów View , ViewGroup i WebView ). Jeśli użyjesz testu Robo do przetestowania aplikacji korzystających z innych ram interfejsu użytkownika, w tym aplikacji korzystających z silnika gry Unity, test może zakończyć się bez eksploracji poza pierwszym ekranem.
Ta strona zawiera pomoc w rozwiązywaniu problemów i odpowiedzi na często zadawane pytania dotyczące przeprowadzania testów w 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 w Firebase Slack lub skontaktuj się z pomocą techniczną Firebase .
Rozwiązywanie problemów
Po wybraniu urządzenia o wysokim poziomie wydajności w katalogu Test Lab testy mogą rozpocząć się szybciej. Gdy urządzenie ma małą pojemność, testy mogą trwać dłużej. Jeśli liczba wywołanych testów jest znacznie większa niż pojemność wybranych urządzeń, ukończenie testów może zająć więcej czasu.
Testy uruchomione na dowolnym poziomie pojemności urządzenia mogą trwać dłużej ze względu na następujące czynniki:
- 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ądzeń w Test Lab, zobacz informacje o pojemności urządzeń z Androidem i iOS .
Niejednoznaczne wyniki testów często pojawiają się z powodu anulowanych przebiegów testów lub błędów infrastruktury.
Błędy infrastruktury są spowodowane wewnętrznymi problemami laboratorium testowego, takimi jak błędy sieci lub nieoczekiwane zachowanie urządzeń. Test Lab wewnętrznie wycofuje przebiegi testów, które wielokrotnie powodują błędy infrastruktury, zanim zgłasza niejednoznaczny wynik; można jednak wyłączyć te ponowne próby, używając metody failFast .
Aby ustalić przyczynę błędu, wykonaj następujące kroki:
- Sprawdź znane awarie w panelu stanu Firebase .
Spróbuj ponownie wykonać test w Laboratorium testowym, aby sprawdzić, czy jest powtarzalny.
Spróbuj uruchomić test na innym urządzeniu lub innym 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.
Dzielenie na fragmenty może spowodować wydłużenie testów, gdy 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 wyboru innego urządzenia, zobaczPojemność urządzenia .
Gdy przesyłasz prośbę o test, Twoja aplikacja jest najpierw weryfikowana, ponownie podpisana itd. w ramach przygotowań do uruchomienia testów na urządzeniu. Zwykle ten proces trwa krócej niż kilka sekund, ale mogą na niego wpływać takie czynniki, jak rozmiar Twojej aplikacji.
Po przygotowaniu aplikacji zaplanowane są wykonania testów, które pozostają w kolejce do momentu, gdy urządzenie będzie gotowe do jej uruchomienia. Dopóki wszystkie wykonania testów nie zakończą się, stan macierzy będzie miał wartość „Oczekująca” (niezależnie od tego, czy wykonania testów są w kolejce, czy aktywnie działają).
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.
Często Zadawane Pytania
Firebase Test Lab oferuje bezpłatne limity testowania na urządzeniach i korzystania z interfejsów Cloud API. Pamiętaj, że przydział testowy korzysta ze standardowego planu cenowego Firebase, podczas gdy limity Cloud API nie.
Kwota testowa
Przydziały testowania są określane na podstawie liczby urządzeń używanych do uruchamiania testów. Plan Firebase Spark ma stały limit testów bez żadnych kosztów dla użytkowników. W przypadku planu Blaze Twoje limity mogą wzrosnąć, jeśli z czasem zwiększy się Twoje 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 testowy .
Wykorzystanie przydziału testowego możesz monitorować w Google Cloud Console .
Limit interfejsu API do testowania w chmurze
Cloud Testing API ma dwa limity przydziału: żądania dziennie na projekt i żądania co 100 sekund na projekt. Możesz monitorować wykorzystanie w Google Cloud Console .
Limit interfejsu Cloud Tool Results
Interfejs Cloud Tool Results API ma dwa limity przydziału: zapytania na dzień na projekt i zapytania na każde 100 sekund na projekt. Możesz monitorować wykorzystanie w Google Cloud Console .
Więcej informacji o limitach API znajdziesz w artykule Limity Cloud API dla Test Lab . Jeśli osiągnąłeś limit API:
Prześlij prośbę o zwiększenie limitów , edytując limity bezpośrednio w Google Cloud Console (zwróć uwagę, że większość limitów jest domyślnie ustawiona na maksimum) lub
Poproś o wyższe limity interfejsu API, wypełniając formularz prośby w Google Cloud Console lub kontaktując się z pomocą techniczną Firebase .
Ze swojego zaplecza możesz określić, czy ruch pochodzi z urządzeń testowych hostowanych przez Firebase, porównując źródłowy adres IP z naszymi zakresami adresów IP .
Test Lab nie współpracuje z VPC-SC, który blokuje kopiowanie aplikacji i innych artefaktów testowych między wewnętrzną pamięcią Test Lab 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 tak samo, jak normalne wykonania testów.
Pamiętaj o następujących kwestiach:
- Całe wykonanie testu jest uruchamiane ponownie po wykryciu awarii. Nie ma obsługi ponawiania prób tylko przypadków testowych zakończonych niepowodzeniem.
- Uruchomienie ponownych prób Deflake jest zaplanowane w tym samym czasie, ale nie ma gwarancji, że będą działać równolegle, na przykład, gdy ruch przekroczy liczbę dostępnych urządzeń.
Chociaż niektóre z tych elementów są na naszej mapie drogowej, obecnie nie jesteśmy w stanie zapewnić wsparcia dla tych platform do testowania i tworzenia aplikacji.
Szczegółowe informacje o urządzeniu są dostępne za pośrednictwem interfejsu API i można uzyskać do nich dostęp z poziomu klienta gcloud za pomocą polecenia opisującego :
gcloud firebase test ios models describe MODEL
Dzielenie na fragmenty nie jest natywnie obsługiwane w ramach Test Lab dla systemu iOS. Możesz jednak użyć klienta Flank do podzielenia przypadków testowych systemu iOS.
Działa to poprzez ustawienie klucza i wartości OnlyTestIdentifiers w pliku .xctestrun . Zobacz stronę man dla xcodebuild.xctestrun , aby uzyskać więcej informacji.
Znane problemy
Test Robo nie może ominąć ekranów logowania, które wymagają dodatkowych działań użytkownika poza wprowadzeniem poświadczeń w celu zalogowania się, na przykład wypełnienia CAPTCHA.
Test Robo działa najlepiej z aplikacjami, które używają elementów interfejsu użytkownika z platformy interfejsu użytkownika systemu Android (w tym obiektów View , ViewGroup i WebView ). Jeśli użyjesz testu Robo do przetestowania aplikacji korzystających z innych ram interfejsu użytkownika, w tym aplikacji korzystających z silnika gry Unity, test może zakończyć się bez eksploracji poza pierwszym ekranem.
Ta strona zawiera pomoc w rozwiązywaniu problemów i odpowiedzi na często zadawane pytania dotyczące przeprowadzania testów w 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 w Firebase Slack lub skontaktuj się z pomocą techniczną Firebase .
Rozwiązywanie problemów
Po wybraniu urządzenia o wysokim poziomie wydajności w katalogu Test Lab testy mogą rozpocząć się szybciej. Gdy urządzenie ma małą pojemność, testy mogą trwać dłużej. Jeśli liczba wywołanych testów jest znacznie większa niż pojemność wybranych urządzeń, ukończenie testów może zająć więcej czasu.
Tests running on any level device capacity level may take longer due to the following factors:
- Traffic, which affects device availability and test speed.
- Device or infrastructure failures, which can happen at any time. To check if there is a reported infrastructure for Test Lab, see the Firebase status dashboard .
To learn more about device capacity in Test Lab, see device capacity information for Android and iOS .
Inconclusive test outcomes commonly occur either because of canceled test runs or infrastructure errors.
Infrastructure errors are caused by internal Test Lab issues, like network errors or unexpected device behaviors. Test Lab internally retires test runs that produce infrastructure errors multiple times before reporting an inconclusive outcome; however, you can disable these retries using failFast .
To determine the cause of the error, follow these steps:
- Check for known outages in the Firebase status dashboard .
Retry the test in Test Lab to verify that it is reproducible.
Try running the test on a different device or device type, if applicable.
If the issue persists, contact the Test Lab team in the #test-lab channel on Firebase Slack.
Sharding can cause your tests to run longer when the number of shards you specified exceeds the number of devices available for use in Test Lab. To avoid this situation, try switching to a different device. For more information about choosing a different device, seeDevice Capacity .
When you submit a test request, your app is first validated, re-signed, etc. in preparation for running tests on a device. Normally, this process completes in less than a few seconds, but it can be affected by factors like the size of your app.
After your app is prepared, test executions are scheduled and remain in a queue until a device is ready to run it. Until all test executions finish running, the matrix status will be "Pending" (regardless of whether test executions are in the queue or actively running).
After the test execution is finished, test artifacts are downloaded from the device, processed, and uploaded to Cloud Storage. The duration of this step can be affected by the amount and size of the artifacts.
Frequently asked questions
Firebase Test Lab offers no-cost quotas for testing on devices and for using Cloud APIs. Note that the testing quota uses the standard Firebase pricing plan, while the Cloud API quotas do not.
Testing quota
Testing quotas are determined by the number of devices used to run tests. The Firebase Spark plan has a fixed testing quota at no cost to users. For the Blaze plan, your quotas might increase if your usage of Google Cloud increases over time. If you reach your testing quota, wait until the next day or upgrade to the Blaze plan if you are currently on the Spark plan. If you are already on the Blaze plan, you can request a quota increase. For more information, see Testing quota .
You can monitor your testing quota usage in the Google Cloud Console .
Cloud Testing API quota
The Cloud Testing API comes with two quota limits: requests per day per project, and requests per every 100 seconds per project. You can monitor your usage in the Google Cloud Console .
Cloud Tool Results API quota
The Cloud Tool Results API comes with two quota limits: queries per day per project, and queries per every 100 seconds per project. You can monitor your usage in the Google Cloud Console .
Refer to Cloud API quotas for Test Lab for more information on API limits. If you've reached an API quota:
Submit a request for higher quotas by editing your quotas directly in the Google Cloud Console (note that most limits are set to maximum by default), or
Request higher API quotas by filling out a request form in the Google Cloud Console or by contacting Firebase support .
From your backend, you can determine if traffic is coming from Firebase-hosted test devices by checking the source IP address against our IP ranges .
Test Lab does not work with VPC-SC, which blocks the copying of apps and other test artifacts between Test Lab's internal storage and users' results buckets.
To detect flaky behavior in your tests, we recommend using the--num-flaky-test-attemptsoption. Deflake reruns are billed or counted toward your daily quota the same as normal test executions.
Keep the following in mind:
- The entire test execution runs again when a failure is detected. There's no support for retrying only failed test cases.
- Deflake retry runs are scheduled to run at the same time, but are not guaranteed to run in parallel, for example, when traffic exceeds the number of available devices.
While some of these items are on our roadmap, we're currently unable to provide commitment to supporting these testing and app development platforms.
Detailed device information is available through the API and can be accessed from the gcloud client using the describe command :
gcloud firebase test ios models describe MODEL
Sharding isn't natively supported within Test Lab for iOS. However, you can use the Flank client to shard iOS test cases.
This works by setting OnlyTestIdentifiers key and values in .xctestrun file. See man page for xcodebuild.xctestrun for more details.
Known issues
Robo test cannot bypass sign-in screens that require additional user action beyond entering credentials to sign in, for example, completing a CAPTCHA.
Robo test works best with apps that use UI elements from the Android UI framework (including View , ViewGroup , and WebView objects). If you use Robo test to exercise apps that use other UI frameworks, including apps that use the Unity game engine, the test may exit without exploring beyond the first screen.