Risoluzione dei problemi di Test Lab e DOMANDE FREQUENTI

Questa pagina fornisce assistenza per la risoluzione dei problemi e risposte alle domande frequenti sull'esecuzione di test con Firebase Test Lab. I problemi noti sono inoltre documentati. Se non riesci a trovare ciò che stai cercando o hai bisogno di ulteriore assistenza, partecipa al canale #test-lab su Firebase Slack o contatta l'assistenza Firebase.

Risoluzione dei problemi

Se nel catalogo Test Lab selezioni un dispositivo con un livello di capacità elevato, i test potrebbero iniziare più velocemente. Quando un dispositivo ha una capacità ridotta, l'esecuzione dei test potrebbe richiedere più tempo. Se il numero di test richiamati è molto più elevato 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 controllare se è stata segnalata un'infrastruttura per Test Lab, consulta la dashboard dello stato di Firebase.

Per scoprire di più sulla capacità del dispositivo in Test Lab, consulta le informazioni sulla capacità del dispositivo per Android e iOS.

I risultati dei test inconcludenti si verificano di solito a causa di esecuzioni di test annullate o di errori dell'infrastruttura.

Gli errori di infrastruttura sono causati da problemi Test Lab interni, come errori di rete o comportamenti imprevisti del dispositivo. Test Lab ritira internamente le esecuzioni di test che generano errori di infrastruttura più volte prima di segnalare un risultato inconcludente. Tuttavia, puoi disattivare questi tentativi utilizzando failFast.

Per determinare la causa dell'errore:

  1. Controlla se sono presenti interruzioni note nella dashboard dello stato di Firebase.

  2. Riprova il test in Test Lab per verificare che sia riproducibile.

  3. Prova a eseguire il test su un altro dispositivo o tipo di dispositivo, se applicabile.

Se il problema persiste, contatta il team di Test Lab nel canale#test-lab su Firebase Slack.

Lo sharding può prolungare 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, consulta Capacità del dispositivo.

Quando invii una richiesta di test, la tua app viene prima convalidata, firmata di nuovo e così via in preparazione all'esecuzione dei test su un dispositivo. Di solito, questa procedura viene completata in meno di qualche secondo, 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 coda fino a quando un dispositivo non è pronto per eseguirle. Fino al completamento di tutte le esecuzioni del test, lo stato della matrice sarà "In attesa" (indipendentemente dal fatto che le esecuzioni del test siano in coda o in esecuzione attiva).

Al termine dell'esecuzione del test, gli elementi 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 elementi.

Gli elementi di esecuzione dei test (ad esempio screenshot e file di log) vengono archiviati in Google Cloud Storage e visualizzati direttamente nella console Firebase. Se l'esecuzione del test è stata eseguita negli ultimi 90 giorni, controlla di avere assigned ruoli a livello di progetto (proprietario del progetto, editor del progetto o visualizzatore del progetto). Assicurati inoltre che l'audit logging di Cloud non sia abilitato per il tuo progetto o la tua organizzazione.

Se l'esecuzione è stata eseguita più di 90 giorni fa, molto probabilmente gli elementi di test sono stati eliminati automaticamente. Puoi controllare la configurazione del bucket dei risultati facendo clic sulla scheda Risultati del test nella dashboard Test Lab. Il bucket risultati predefinito è configurato per conservare gli oggetti per 90 giorni.

Per conservare gli elementi di test più a lungo, esegui il comando gcloud firebase test android run con il flag --results-bucket e passa il nome del bucket dei risultati. Per saperne di più, consulta la documentazione di riferimento di gcloud firebase test android run.

Quando esegui i test di misurazione, potresti visualizzare errori di test che indicano risultati parziali contenenti messaggi come Test run failed to complete. Expected x tests, received y (dove y è inferiore a x). Questo errore indica che Test Lab non è stato in grado di analizzare il logcat per gli indicatori di inizio o fine del caso di test che in genere vengono generati da AndroidJUnitRunner.

Di seguito sono riportate alcune cause comuni del problema:

Descrizione del problema Possibile risoluzione
Lo scenario di test non è stato eseguito a causa di un timeout. Se la durata totale dei test è superiore a un timeout specificato o a un timeout massimo, Test Lab annulla il resto degli scenari di test.
  • Aumenta il timeout per la matrice per assicurarti che tutti i test possano essere completati.
  • Se non l'hai ancora fatto, suddividi i test in modo che ogni shard esegua un sottoinsieme di test e venga completato in un periodo di tempo più breve.
  • Se hai già attivato lo sharding, aumenta il numero di shard.
Il test case non è stato completato perché è stato chiuso prematuramente o si è bloccato. Il caso di test potrebbe uscire prematuramente a causa di un'eccezione non rilevata o di un errore di asserzione. I casi di test possono bloccarsi in un ciclo infinito o non essere in grado di procedere, ad esempio se l'app non mostra la visualizzazione corretta e il caso di test non può eseguire l'azione nell'interfaccia utente. Controlla il video e logcat per capire dove si è interrotto il test.
Un executor di test personalizzato (inclusa l'estensione di AndroidJUnitRunner) ha avuto un arresto anomalo o ha scritto indicatori di inizio o fine dello scenario di test inaspettati in logcat. Controlla il codice del programma di test.
Sono stati scritti log eccessivi in logcat, che ha sovraccaricato il buffer o ha causato l'arresto anomalo del processo logcat. Riduci le scritture a logcat.
L'app in test ha avuto un arresto anomalo. Esegui il debug dell'app.

Domande frequenti

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 Firebase standard, mentre le quote dell'API Cloud no.

  • Quota di test

    Le quote di test sono determinate dal numero di dispositivi utilizzati per eseguire i test. Il piano Firebase Spark ha una quota di test fissa senza costi per gli utenti. Per il piano Blaze, le 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 al momento utilizzi il piano Spark. Se utilizzi già il piano Blaze, puoi richiedere un aumento della quota. Per ulteriori informazioni, consulta Testare la quota.

    Puoi monitorare l'utilizzo della quota di test nella console Google Cloud.

  • Quota dell'API Cloud Testing

    L'API Cloud Testing ha due limiti di quota: richieste al giorno per progetto e richieste ogni 100 secondi per progetto. Puoi monitorare il tuo utilizzo nella console Google Cloud.

  • Quota dell'API Cloud Tool Results

    L'API Cloud Tool Results ha due limiti di quota: query al giorno per progetto e query ogni 100 secondi per progetto. Puoi monitorare il tuo utilizzo nella console Google Cloud.

    Per ulteriori informazioni sui limiti delle API, consulta le quote delle API Cloud per Test Lab. Se hai raggiunto una quota API:

    • Invia una richiesta di quote più alte modificando le quote direttamente nella console Google Cloud (tieni presente che la maggior parte dei limiti è impostata su valore massimo per impostazione predefinita) oppure

    • Richiedi quote API più elevate compilando un modulo di richiesta nella consoleGoogle Cloud o contattando l'assistenza Firebase.

Dal tuo backend, puoi determinare se il traffico proviene da dispositivi di test ospitati su Firebase controllando l'indirizzo IP di origine rispetto ai nostri intervalli IP.

Test Lab non funziona con VPC-SC, che blocca la copia di app e altri elementi di test tra lo spazio di archiviazione interno di Test Lab e i bucket dei risultati degli utenti.

Per rilevare un comportamento incostante nei test, ti consigliamo di utilizzare l'opzione --num-flaky-test-attempts . Le riesecuzione di deflake vengono fatturate o conteggiate ai fini della quota giornaliera come le normali esecuzioni dei test.

Tieni presente che:

  • L'intera esecuzione del test viene eseguita di nuovo quando viene rilevato un errore. Non è supportato il nuovo tentativo solo per i casi di test non riusciti.
  • Le esecuzioni di ripetizione 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.

Sì! Test Lab supporta Google Pixel Watch. Ora puoi eseguire test sulla tua app Wear autonoma su Google Pixel Watch. Per scoprire di più sui dispositivi Test Lab, consulta Eseguire test su dispositivi disponibili.

Sì! Test Lab supporta Google Pixel Tablet e Google Pixel Fold. Puoi eseguire i test sui tuoi dispositivi fisici autonomi. Per scoprire di più sui dispositivi Test Lab, consulta Eseguire test su dispositivi disponibili.

Se stai testando la tua app in Firebase o esegui test per un report pre-lancio in Play Console, puoi rilevare se un test è in corso su un dispositivo ospitato da Firebase controllando la proprietà di sistema firebase.test.lab nel file MainActivity. Puoi quindi eseguire altre istruzioni in base al valore booleano di testLabSetting. Per ulteriori informazioni, consulta Comportamenti di test modificati.

Sebbene alcuni di questi elementi siano inclusi nella nostra roadmap, al momento non possiamo impegnarci a supportare queste piattaforme di test e sviluppo di app. Tuttavia, se hai creato la tua app con un framework che supporta Espresso (ad esempio Flutter), puoi scrivere un test di misurazione utilizzando Espresso e poi eseguirlo in Test Lab.

Test Lab non supporta esplicitamente l'oscuramento o la deoscuramento. Anche se l'app verrà probabilmente eseguita, eventuali dati dell'app offuscati, come le tracce dello stack, verranno visualizzati come offuscati nei log.

Sì! Puoi testare il tuo dispositivo pieghevole in stati e posizioni pieghevoli.

I dispositivi pieghevoli possono essere in vari stati di chiusura, ad esempio FLAT (completamente aperto) o HALF_OPENED (tra completamente aperto e completamente chiuso).

Le posture, invece, consistono in orientamenti e stati di chiusura specifici del dispositivo. Ad esempio, la postura da tavolo, che è uno stato HALF_OPENED con orientamento orizzontale, o la postura da libro, che è uno stato HALF_OPENED con orientamento verticale.

Se esegui test di strumentazione, puoi utilizzare la libreria Jetpack WindowManager e seguire la documentazione relativa al test dell'app sui dispositivi pieghevoli per eseguire test in stati e posizioni diversi.

In alternativa, gli stati disponibili sono specifici del dispositivo e possono essere utilizzati con adb shell command cmd device_state.

  • Per elencare lo stato attuale, esegui adb shell cmd device_state state.
  • Per impostare o ignorare lo stato corrente, esegui adb shell cmd device_state state <IDENTIFIER>.
  • Per reimpostare lo stato, esegui adb shell cmd device_state state reset.
  • Per controllare gli stati disponibili, esegui il comando adb shell cmd device_state print-states sul dispositivo pieghevole.
Google Pixel Fold (ID modello felix) Samsung Galaxy Z Fold4 (ID modello q4q)
$ 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},
]
$ 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},
]

A differenza di altri prodotti Firebase, non è necessario aggiungere un SDK Firebase per utilizzare Test Lab. Se non hai ancora un'app, puoi scaricare un APK online o creare un'app e un APK di test da uno dei sample nel repository GitHub di AndroidX. Tieni presente che per eseguire un test Robo è sufficiente il file APK dell'app, mentre un test di misurazione richiede sia un'app sia un APK di test compilati dal codice sorgente. Per ulteriori informazioni, consulta la sezione sui test con strumenti.

Per scoprire di più sulle funzionalità di Test Lab, consulta Iniziare a eseguire test per Android con Firebase Test Lab.

I test di differenza di screenshot si basano sul confronto delle immagini sullo schermo ottenute durante l'esecuzione di un test con le immagini di riferimento che rappresentano il comportamento previsto. Questi test potrebbero essere meno affidabili su alcuni tipi di dispositivi rispetto ad altri. Per questi tipi di test, ti consigliamo di scegliere come target i dispositivi emulatore Arm (*.arm). I dispositivi di emulazione ARM utilizzano immagini molto simili o identiche a quelle degli emulatori "generici" di Android Studio.

Ti consigliamo inoltre di esaminare le librerie di test che possono contribuire a rendere più affidabili i test degli screenshot in presenza di modifiche previste.

Sì! I dispositivi virtuali vengono aggiornati quando vengono apportate le seguenti modifiche:

  1. Aggiornamenti alle immagini esistenti
  2. Ritiro dei livelli API precedenti
  3. Vengono aggiunti nuovi livelli API Android

Per attivare i report sulla copertura, aggiungi coverage=true al campo environmentVariables. Se utilizzi Android Test Orchestrator, dovrai fornire una directory per memorizzare i risultati della copertura:

--environment-variables coverage=true,coverageFilePath=/sdcard/Download/

Se non utilizzi Orchestrator, puoi specificare un percorso file:

--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec

Le informazioni dettagliate sul dispositivo sono disponibili tramite l'API e possono essere accessibili dal client gcloud utilizzando il comando describe:

gcloud firebase test android models describe MODEL

Problemi noti

Il test Robo non può bypassare le schermate di accesso che richiedono un'azione aggiuntiva dell'utente oltre all'inserimento delle credenziali per accedere, ad esempio il completamento di un CAPTCHA.

Il test Robo funziona al meglio con le app che utilizzano elementi dell'interfaccia utente 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 uscire senza esplorare oltre la prima schermata.