Risoluzione dei problemi di Test Lab e DOMANDE FREQUENTI
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina fornisce assistenza per la risoluzione dei problemi e risposte alle domande frequenti sull'esecuzione di test con Firebase Test Lab. Sono documentati anche i problemi noti. Se non riesci a trovare quello che cerchi o hai bisogno di ulteriore aiuto, unisciti al canale #test-lab su Firebase Slack o contatta l'assistenza Firebase.
Risoluzione dei problemi
Perché l'esecuzione del test richiede così tanto tempo?
Quando selezioni un dispositivo con un livello di capacità elevato nel catalogo Test Lab, i test potrebbero iniziare più rapidamente. Quando un
dispositivo ha una capacità ridotta, i test potrebbero richiedere più tempo. Se il numero di test richiamati è molto maggiore della capacità dei dispositivi selezionati, il completamento dei test può richiedere più tempo.
I test eseguiti su qualsiasi livello di capacità del dispositivo potrebbero richiedere più tempo a causa dei
seguenti fattori:
Traffico, che influisce sulla disponibilità del dispositivo e sulla velocità del test.
Guasti del dispositivo o dell'infrastruttura, che possono verificarsi in qualsiasi momento. Per verificare
se è stata segnalata un'infrastruttura per Test Lab, consulta la
dashboard dello stato di Firebase.
Per scoprire di più sulla capacità dei dispositivi in Test Lab, consulta le informazioni sulla capacità dei dispositivi per Android e iOS.
Perché ricevo risultati del test inconcludenti?
I risultati inconcludenti dei test si verificano comunemente a causa di esecuzioni di test annullate
o errori dell'infrastruttura.
Gli errori di infrastruttura sono causati da problemi interni di Test Lab, come errori di rete o comportamenti imprevisti del dispositivo. Test Lab ritira internamente le esecuzioni di test
che producono errori di infrastruttura più volte prima di segnalare un
risultato non conclusivo; tuttavia, puoi disattivare questi tentativi utilizzando
failFast.
Per determinare la causa dell'errore, segui questi passaggi:
Ripeti il test in Test Lab per verificare che sia riproducibile.
Se applicabile, prova a eseguire il test su un altro dispositivo o tipo di dispositivo.
Se il problema persiste, contatta il team Test Lab nel
canale#test-lab su
Firebase Slack.
Perché lo sharding ha allungato
i tempi di esecuzione dei miei test?
Lo sharding può allungare la durata dei test quando il numero di shard specificato supera il numero di dispositivi disponibili per l'utilizzo in Test Lab. Per
evitare questa situazione, prova a passare a un altro dispositivo. Per ulteriori informazioni
sulla scelta di un altro dispositivo, vedi
Capacità del dispositivo.
Perché il mio test
richiede molto tempo per iniziare?
Quando invii una richiesta di test, l'app viene prima convalidata, firmata nuovamente e così via in
preparazione all'esecuzione dei test su un dispositivo. Normalmente, questa procedura viene completata in
meno di pochi secondi, ma può essere influenzata da fattori come le dimensioni dell'app.
Una volta preparata l'app, le esecuzioni dei test vengono pianificate e rimangono in una coda
finché un dispositivo non è pronto per eseguirle. Finché non vengono completate tutte le esecuzioni dei test, lo stato della matrice sarà "In attesa" (indipendentemente dal fatto che le esecuzioni dei test siano in coda o in esecuzione).
Perché il mio test richiede
molto tempo per essere completato?
Al termine dell'esecuzione del test, gli artefatti di test vengono scaricati dal
dispositivo, elaborati e caricati su Cloud Storage. La durata di questo passaggio può
essere influenzata dalla quantità e dalle dimensioni degli artefatti.
Domande frequenti
Quali sono le quote senza costi
per Test Lab? Cosa devo fare se le esaurisco?
Firebase Test Lab offre quote senza costi per i test sui dispositivi e per l'utilizzo
delle API Cloud. Tieni presente che la quota di test utilizza il piano tariffario standard di Firebase,
mentre le quote dell'API Cloud non lo fanno.
Quota di test
Le quote di test sono determinate dal numero di dispositivi utilizzati per eseguire i test.
Il piano Firebase Spark prevede una quota di test fissa senza costi per gli utenti. Per il piano Blaze, le tue quote potrebbero aumentare se il tuo utilizzo di Google Cloud aumenta nel tempo. Se raggiungi la quota di test, attendi il giorno successivo o esegui l'upgrade al piano Blaze se attualmente utilizzi il piano Spark.
Se hai già scelto il piano Blaze, puoi richiedere un aumento della quota.
Per maggiori informazioni, vedi
Quota di test.
L'API Cloud Testing prevede due limiti di quota: richieste al giorno per progetto e richieste ogni 100 secondi per progetto. Puoi monitorare l'utilizzo nella console Google Cloud.
Quota dell'API Cloud Tool Results
L'API Cloud Tool Results prevede due limiti di quota: query al giorno per progetto e query ogni 100 secondi per progetto. Puoi monitorare l'utilizzo nella console Google Cloud.
Invia una richiesta per quote più elevate
modificando le quote
direttamente nella console Google Cloud (tieni presente che la maggior parte dei limiti è impostata
sul valore massimo per impostazione predefinita) oppure
Richiedi quote API più elevate compilando un modulo di richiesta nella
console Google Cloud o contattando
l'assistenza Firebase.
Come faccio a sapere se il traffico che raggiunge il mio backend proviene da Test Lab?
Dal backend, puoi determinare se il traffico proviene da dispositivi di test ospitati da Firebase controllando l'indirizzo IP di origine rispetto ai nostri intervalli IP.
Test Lab funziona con
VPC-SC?
Test Lab non funziona con VPC-SC, che blocca la
copia di app e altri artefatti di test tra lo spazio di archiviazione
interno di Test Lab e i bucket dei risultati degli utenti.
Come faccio a rilevare test instabili in
Test Lab?
Per rilevare un comportamento instabile nei test, ti consigliamo di utilizzare l'opzione
--num-flaky-test-attempts
. Le nuove esecuzioni di test per la rimozione di test instabili vengono fatturate o conteggiate ai fini della quota giornaliera come le normali esecuzioni di test.
Tieni presente che:
L'intera esecuzione del test viene eseguita di nuovo quando viene rilevato un errore. Non è previsto
il supporto per il nuovo tentativo solo dei casi di test non riusciti.
Le esecuzioni di nuovi tentativi di deflake sono pianificate per essere eseguite contemporaneamente, ma non è garantito che vengano eseguite in parallelo, ad esempio quando il traffico supera il numero di dispositivi disponibili.
Test Lab supporta
Appium, Flutter/FlutterDriver, ReactNative/Jest o Cucumber?
Sebbene alcuni di questi elementi siano nella nostra roadmap, al momento non siamo in grado di impegnarci a supportare queste piattaforme di test e sviluppo di app.
Dove posso trovare i dettagli del dispositivo,
come la risoluzione e così via?
Informazioni dettagliate sul dispositivo sono disponibili tramite l'API e sono accessibili
dal client gcloud utilizzando il
comando describe:
gcloud firebase test ios models describe MODEL
Posso utilizzare lo sharding con i test iOS?
Lo sharding non è supportato in modo nativo in Test Lab per iOS. Tuttavia, puoi
utilizzare il client Flank per suddividere gli scenari di test iOS.
Per farlo, imposta la chiave e i valori OnlyTestIdentifiers nel file .xctestrun.
Per ulteriori dettagli, consulta la pagina man per xcodebuild.xctestrun.
Perché nel mio test iOS mancano video nei
risultati?
Per iOS 18 o versioni successive, non siamo in grado di supportare i video nei risultati.
Problemi noti
Captcha di accesso
Il test Robo non può bypassare le schermate di accesso che richiedono
un'azione aggiuntiva dell'utente oltre all'inserimento delle credenziali di accesso, ad esempio,
il completamento di un CAPTCHA.
Supporto del framework UI
Il test Robo funziona meglio con le app che utilizzano elementi UI del framework UI di Android (inclusi gli oggetti View, ViewGroup e WebView). Se utilizzi il test Robo per testare app che utilizzano altri framework UI, incluse le app che utilizzano il motore di gioco Unity, il test potrebbe terminare senza esplorare oltre la prima schermata.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-05 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"]]
