Rozwiązywanie problemów z Laboratorium Najczęstsze pytania
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Na tej stronie znajdziesz pomoc w rozwiązywaniu 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źć potrzebnych informacji 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 Labwybierzesz urządzenie o wysokim poziomie pojemności, 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ż możliwości wybranych urządzeń, testy mogą trwać dłużej.
Testy przeprowadzane na urządzeniach o dowolnym poziomie wydajności 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ądzeń lub infrastruktury, które mogą wystąpić w dowolnym momencie; Aby sprawdzić, czy zgłoszono problemy z infrastrukturą Test Lab, otwórz panel stanu Firebase.
Więcej informacji o pojemności urządzenia w Test Lab znajdziesz w artykule o pojemności urządzenia na Androida i iOS.
Dlaczego otrzymuję niejednoznaczne wyniki testów?
Niejednoznaczne wyniki testów występują zwykle z powodu anulowanych uruchomień testów lub błędów infrastruktury.
Błędy infrastruktury są spowodowane wewnętrznymi problemami z Test Lab, takimi jak błędy sieci lub nieoczekiwane zachowania urządzeń. Test Lab wewnętrznie wycofuje przebiegi testów
wielokrotnie powodujące błędy infrastruktury, zanim zgłosi
niejednoznaczny wynik. Możesz jednak wyłączyć te ponowienia za pomocą
failFast.
Aby ustalić przyczynę błędu, wykonaj te czynności:
Sprawdź, czy nie występują znane przerwy w działaniu usługi w panelu stanu Firebase.
Powtórz test w Test Lab, aby sprawdzić, czy wynik jest powtarzalny.
W razie potrzeby spróbuj przeprowadzić test na innym urządzeniu lub innym typie urządzenia.
Jeśli problem będzie się powtarzał, skontaktuj się z zespołem Test Lab na kanale#test-lab w społeczności Firebase na Slacku.
Dlaczego dzielenie na partycje wydłużyło czas działania moich testów?
Fragmentacja może wydłużyć czas trwania testów, jeśli liczba fragmentów przekracza liczbę urządzeń dostępnych do użycia w Test Lab. Aby uniknąć tej sytuacji, spróbuj użyć innego urządzenia. 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 prośbę o test, aplikacja jest najpierw weryfikowana, ponownie podpisywana itp. w ramach przygotowań do przeprowadzenia testów na urządzeniu. Zwykle trwa to mniej niż kilka sekund, ale może zależeć od takich czynników jak rozmiar aplikacji.
Gdy aplikacja będzie gotowa, zaplanowane zostaną wykonania testów, które pozostaną w kolejce, dopóki urządzenie nie będzie gotowe do ich uruchomienia. Dopóki wszystkie wykonania testu nie zostaną ukończone, stan macierzy będzie „Oczekujący” (niezależnie od tego, czy wykonania testu są w kolejce, czy aktywnie działają).
Dlaczego test 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 kroku może zależeć od liczby i rozmiaru artefaktów.
Najczęstsze pytania
Jakie są bezpłatne limity dla Test Lab? Co zrobić, jeśli mi się skończą?
Firebase Test Lab oferuje bezpłatne limity na testowanie na urządzeniach i korzystanie z interfejsów Cloud API. Pamiętaj, że limit testowy jest zgodny ze standardowym planem cenowym Firebase, a limity interfejsu Cloud API nie.
Limit testowania
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, który jest bezpłatny dla użytkowników. W przypadku abonamentu Blaze limity mogą się zwiększać, jeśli z czasem wzrośnie wykorzystanie Google Cloud. Jeśli osiągniesz limit testowania, poczekaj do następnego dnia lub przejdź na abonament Blaze, jeśli korzystasz obecnie z abonamentu Spark.
Jeśli korzystasz już z abonamentu Blaze, możesz poprosić o zwiększenie limitu.
Więcej informacji znajdziesz w sekcji Limit testowy.
Interfejs Cloud Testing API ma 2 limity: żądania dziennie na projekt i żądania co 100 sekund na projekt. Możesz monitorować wykorzystanie w Google Cloudkonsoli.
Limit interfejsu Cloud Tool Results API
Interfejs Cloud Tool Results API ma 2 limity: zapytania dziennie na projekt i zapytania co 100 sekund na projekt. Możesz monitorować wykorzystanie w Google Cloudkonsoli.
Prześlij prośbę o zwiększenie 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ść) lub
Aby poprosić o zwiększenie przydziału danych w interfejsie API, wypełnij formularz w Google Cloudkonsoli lub skontaktuj się z zespołem pomocy Firebase.
Jak sprawdzić, czy ruch docierający do mojego backendu pochodzi z Test Lab?
W backendzie możesz sprawdzić, czy ruch pochodzi z urządzeń testowych hostowanych przez Firebase, porównując źródłowy adres IP z naszymi zakresami adresów IP.
Czy Test Lab działa z VPC-SC?
Test Lab nie działa z VPC-SC, która blokuje kopiowanie aplikacji i innych artefaktów testowych między wewnętrznym miejscem na dane Test Lab a zasobnikami wyników użytkowników.
Jak wykrywać niestabilne testy w Test Lab?
Aby wykryć niestabilne zachowanie w testach, zalecamy użycie opcji
--num-flaky-test-attempts
. Ponowne uruchomienia testów w celu wyeliminowania niestabilności są rozliczane lub wliczane do dziennego limitu tak samo jak zwykłe wykonania testów.
Pamiętaj:
Po wykryciu błędu całe wykonanie testu jest uruchamiane ponownie. Nie ma możliwości ponawiania tylko testów zakończonych niepowodzeniem.
Ponowne uruchomienia w celu wyeliminowania niestabilności są zaplanowane na tę samą godzinę, ale nie ma gwarancji, że będą wykonywane równolegle, np. gdy ruch przekracza liczbę dostępnych urządzeń.
Czy Test Lab obsługuje Appium, Flutter/FlutterDriver, ReactNative/Jest lub Cucumber?
Niektóre z tych elementów są uwzględnione w naszym planie rozwoju, ale obecnie nie możemy zagwarantować obsługi tych platform testowych i do tworzenia aplikacji.
Gdzie znajdę szczegóły urządzenia, takie jak rozdzielczość?
Szczegółowe informacje o urządzeniu są dostępne w interfejsie API i można je uzyskać z klienta gcloud za pomocą polecenia describe:
gcloud firebase test ios models describe MODEL
Czy mogę używać dzielenia na partycje w przypadku testów iOS?
Dzielenie na partycje nie jest natywnie obsługiwane w Test Lab na iOS. Możesz jednak użyć klienta Flank, aby podzielić przypadki testowe iOS na mniejsze części.
W tym celu należy ustawić klucz OnlyTestIdentifiers i wartości w pliku .xctestrun.
Więcej informacji znajdziesz na stronie man w sekcji xcodebuild.xctestrun.
Dlaczego w wynikach testu na iOS brakuje filmów?
W przypadku systemu iOS 18 lub nowszego nie możemy obsługiwać filmów w wynikach.
Znane problemy
Captcha logowania
Test automatyczny nie może pominąć ekranów logowania, które wymagają dodatkowych działań użytkownika poza wpisaniem danych logowania, np. wypełnienia testu CAPTCHA.
Obsługa platformy interfejsu
Testy Robo najlepiej sprawdzają się w przypadku aplikacji, które korzystają z elementów interfejsu z platformy interfejsu Androida (w tym obiektów View, ViewGroup i WebView). Jeśli używasz testu Robo do testowania aplikacji, które korzystają z innych platform interfejsu, w tym aplikacji korzystających z silnika gier Unity, test może zakończyć się bez eksplorowania kolejnych ekranów.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 2025-09-03 UTC."],[],[],null,["\u003cbr /\u003e\n\niOS Android \n\nThis page provides troubleshooting help and answers to frequently asked\nquestions about running tests with Firebase Test Lab. Known issues are also\ndocumented. If you can't find what\nyou're looking for or need additional help, join the [#test-lab\nchannel](https://firebase-community.slack.com/messages/test-lab) on\nFirebase Slack or contact [Firebase\nsupport](https://support.google.com/firebase/contact/support).\n\nTroubleshooting\n\n\u003cbr /\u003e\n\nWhy is my test taking so long to run?\n\n\u003cbr /\u003e\n\nWhen you select a device with a high capacity level in the Test Lab\ncatalog, tests may start faster. When a\ndevice has low capacity, tests might take longer to run. If the number of\ntests invoked is much larger than the capacity of the selected devices, tests\ncan take longer to finish.\n\n\nTests running on any level device capacity level may take longer due to the\nfollowing factors:\n\n- Traffic, which affects device availability and test speed.\n- 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](https://status.firebase.google.com/summary).\n\n\nTo learn more about device capacity in Test Lab, see device capacity\ninformation for [Android](https://firebase.google.com/docs/test-lab/android/available-testing-devices#device-capacity) and [iOS](https://firebase.google.com/docs/test-lab/ios/available-testing-devices#device-capacity).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy am I receiving inconclusive test results?\n\n\u003cbr /\u003e\n\nInconclusive test outcomes commonly occur either because of canceled test runs\nor infrastructure errors.\n\nInfrastructure errors are caused by internal Test Lab issues, like network\nerrors or unexpected device behaviors. Test Lab internally retires test runs\nthat produce infrastructure errors multiple times before reporting an\ninconclusive outcome; however, you can disable these retries using\n[failFast](/docs/test-lab/reference/testing/rest/v1/projects.testMatrices#TestMatrix.FIELDS.fail_fast).\n\nTo determine the cause of the error, follow these steps:\n\n1. Check for known outages in the [Firebase status dashboard](https://status.firebase.google.com/summary).\n2. Retry the test in Test Lab to verify that it is reproducible.\n\n | **Note:** Test Lab does not charge you for infrastructure errors.\n3. Try running the test on a different device or device type, if applicable.\n\nIf the issue persists, contact the Test Lab team in the\n[#test-lab channel](https://firebase-community.slack.com/messages/test-lab) on\nFirebase Slack.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy did sharding make my tests run\nlonger?\n\n\u003cbr /\u003e\n\nSharding can cause your tests to run longer when the number of shards you\nspecified exceeds the number of devices available for use in Test Lab. To\navoid this situation, try switching to a different device. For more information\nabout choosing a different device, see\n\n[Device Capacity](https://firebase.google.com/docs/test-lab/ios/available-testing-devices#device_capacity).\n\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is it taking a long time for my\ntest to start?\n\n\u003cbr /\u003e\n\nWhen you submit a test request, your app is first validated, re-signed, etc. in\npreparation for running tests on a device. Normally, this process completes in\nless than a few seconds, but it can be affected by factors like the size of your\napp.\n\nAfter your app is prepared, test executions are scheduled and remain in a queue\nuntil a device is ready to run it. Until all test executions finish running,\nthe matrix status will be \"Pending\" (regardless of whether test executions are\nin the queue or actively running).\n| **Note:** The time your test spends waiting for an available device does not count toward your billing time.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is it taking a long time for my\ntest to finish?\n\n\u003cbr /\u003e\n\nAfter the test execution is finished, test artifacts are downloaded from the\ndevice, processed, and uploaded to Cloud Storage. The duration of this step can\nbe affected by the amount and size of the artifacts.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nFrequently asked questions\n\n\u003cbr /\u003e\n\nWhat are the no-cost quotas\nfor Test Lab? What should I do if I run out?\n\n\u003cbr /\u003e\n\nFirebase Test Lab offers no-cost quotas for testing on devices and for using\nCloud APIs. Note that the testing quota uses the standard Firebase pricing plan,\nwhile the Cloud API quotas do not.\n\n- **Testing quota**\n\n Testing quotas are determined by the number of devices used to run tests.\n The Firebase Spark plan has a fixed testing quota at no cost to users. For\n the Blaze plan, your quotas might increase if your usage of Google Cloud\n increases over time. If you reach your testing quota, wait until the next\n day or upgrade to the Blaze plan if you are currently on the Spark plan.\n If you are already on the Blaze plan, you can request a quota increase.\n For more information, see\n [Testing quota](/docs/test-lab/usage-quotas-pricing#testing-quota).\n\n You can monitor your testing quota usage in the [Google Cloud console](https://console.cloud.google.com/apis/api/testing.googleapis.com/quotas).\n- **Cloud Testing API quota**\n\n The Cloud Testing API comes with two quota limits: requests per day per\n project, and requests per every 100 seconds per project. You can monitor your\n usage in the\n [Google Cloud console](https://console.cloud.google.com/apis/api/testing.googleapis.com/quotas).\n- **Cloud Tool Results API quota**\n\n The Cloud Tool Results API comes with two quota limits: queries per day per\n project, and queries per every 100 seconds per project. You can monitor your\n usage in the\n [Google Cloud console](https://console.cloud.google.com/apis/api/toolresults.googleapis.com/quotas).\n\n Refer to [Cloud API quotas for Test Lab](/docs/test-lab/usage-quotas-pricing#cloud-api-quota)\n for more information on API limits. If you've reached an API quota:\n - Submit a request for higher quotas by\n [editing your quotas](https://cloud.google.com/docs/quota#requesting_higher_quota)\n directly in the Google Cloud console (note that most limits are set to\n maximum by default), or\n\n - Request higher API quotas by filling out a request form in the\n Google Cloud console or by contacting\n [Firebase support](https://support.google.com/firebase/contact/support).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nHow do I find out if the\ntraffic reaching my backend is coming from Test Lab?\n\n\u003cbr /\u003e\n\nFrom your backend, you can determine if traffic is coming from Firebase-hosted\ntest devices by checking the source IP address against our\n[IP ranges](https://firebase.google.com/docs/test-lab/android/get-started#ip-blocks).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nDoes Test Lab work with\nVPC-SC?\n\n\u003cbr /\u003e\n\nTest Lab does not work with VPC-SC, which blocks the\ncopying of apps and other test artifacts between Test Lab's internal\nstorage and users' results buckets.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nHow do I detect flaky tests in\nTest Lab?\n\n\u003cbr /\u003e\n\nTo detect flaky behavior in your tests, we recommend using the\n\n[--num-flaky-test-attempts](https://cloud.google.com/sdk/gcloud/reference/firebase/test/ios/run#--num-flaky-test-attempts)\n\noption. Deflake reruns are billed or counted toward your daily quota the same as\nnormal test executions.\n\nKeep the following in mind:\n\n- The entire test execution runs again when a failure is detected. There's no support for retrying only failed test cases.\n- 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.\n\n| **Note:** Infrastructure errors are independent from the deflake feature and don't trigger deflake reruns.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nDoes Test Lab support\nAppium, Flutter/FlutterDriver, ReactNative/Jest, or Cucumber?\n\n\u003cbr /\u003e\n\nWhile some of these items are on our roadmap, we're currently unable to provide\ncommitment to supporting these testing and app development platforms.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhere can I find device details,\nlike resolution, etc.?\n\n\u003cbr /\u003e\n\nDetailed device information is available through the API and can be accessed\nfrom the gcloud client using the\n[describe command](https://cloud.google.com/sdk/gcloud/reference/firebase/test/android/models/describe):\n\n`gcloud firebase test ios models describe `\u003cvar translate=\"no\"\u003eMODEL\u003c/var\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nCan I use sharding with iOS tests?\n\n\u003cbr /\u003e\n\nSharding isn't natively supported within Test Lab for iOS. However, you can\nuse the [Flank](https://flank.github.io/flank/) client to shard iOS test cases.\n| **Note:** Using Flank iOS sharding creates separate test matrices for each shard.\n\nThis works by setting `OnlyTestIdentifiers` key and values in `.xctestrun` file.\nSee `man` page for `xcodebuild.xctestrun` for more details.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is my iOS test missing videos in the\nresults?\n\n\u003cbr /\u003e\n\nFor iOS 18 or later, we are not able to support videos in the results.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nKnown issues\n\n\u003cbr /\u003e\n\nSign-in Captchas\n\n\u003cbr /\u003e\n\nRobo test cannot bypass sign-in screens that require\nadditional user action beyond entering credentials to sign in, for example,\ncompleting a CAPTCHA.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nUI framework support\n\n\u003cbr /\u003e\n\nRobo test works best with apps that use UI elements from the Android UI\nframework (including `View`, `ViewGroup`, and `WebView`\nobjects). If you use Robo test to exercise apps that use other UI\nframeworks, including apps that use the Unity game engine, the test may exit\nwithout exploring beyond the first screen.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e"]]
