Questa pagina fornisce assistenza per la risoluzione dei problemi e risposte alle domande frequenti sull'esecuzione di test con Firebase Test Lab. Vengono documentati anche i problemi noti. Se non riesci a trovare quello che stai cercando o hai bisogno di ulteriore aiuto, unisciti al canale #test-lab su Firebase Slack o contatta il supporto Firebase .
Risoluzione dei problemi
Quando selezioni un dispositivo con un livello di capacità elevato nel catalogo Test Lab, 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 maggiore della capacità dei dispositivi selezionati, il completamento dei test potrebbe richiedere più tempo.
I test eseguiti a 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 è presente un'infrastruttura segnalata per Test Lab, consulta la dashboard dello stato di Firebase .
Per ulteriori informazioni 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 comunemente a causa di esecuzioni di test annullate o di errori dell'infrastruttura.
Gli errori dell'infrastruttura sono causati da problemi interni del laboratorio di test, come errori di rete o comportamenti imprevisti del dispositivo. Test Lab ritira internamente le esecuzioni di test che producono errori infrastrutturali più volte prima di riportare un risultato inconcludente; tuttavia, puoi disabilitare questi tentativi utilizzando failFast .
Per determinare la causa dell'errore, attenersi alla seguente procedura:
- Verifica la presenza di interruzioni note nella dashboard dello stato di Firebase .
Riprovare il test in Test Lab per verificare che sia riproducibile.
Prova a eseguire il test su un dispositivo o tipo di dispositivo diverso, se applicabile.
Se il problema persiste, contatta il team Test Lab nel canale #test-lab su Firebase Slack.
Lo sharding può far sì che i test vengano eseguiti più a lungo quando il numero di shard specificati supera il numero di dispositivi disponibili per l'uso in Test Lab. Per evitare questa situazione, prova a passare a un dispositivo diverso. Per ulteriori informazioni sulla scelta di un dispositivo diverso, consulta Capacità del dispositivo.
Quando invii una richiesta di test, la tua app viene prima convalidata, firmata nuovamente, ecc. in preparazione all'esecuzione dei test su un dispositivo. Normalmente, questo processo viene completato in meno di pochi secondi, ma può essere influenzato da fattori come la dimensione della tua app.
Dopo che l'app è stata preparata, le esecuzioni dei test vengono pianificate e rimangono in coda finché un dispositivo non è pronto per eseguirlo. Fino al termine dell'esecuzione di tutte le esecuzioni dei test, lo stato della matrice sarà "In sospeso" (indipendentemente dal fatto che le esecuzioni dei test siano in coda o attivamente in esecuzione).
Al termine dell'esecuzione del test, gli artefatti del 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.
Gli elementi di esecuzione dei test (come screenshot e file di log) vengono archiviati in Google Cloud Storage e sottoposti a rendering direttamente nella console Firebase. Se l'esecuzione del test è stata eseguita negli ultimi 90 giorni, verifica di aver assegnato ruoli a livello di progetto (proprietario del progetto, editor del progetto o visualizzatore del progetto). Assicurati inoltre che Cloud Audit Logging non sia abilitato per il tuo progetto o la tua organizzazione.
Se l'esecuzione è stata eseguita più di 90 giorni fa, molto probabilmente gli artefatti del test sono stati eliminati automaticamente. È possibile controllare la configurazione del bucket dei risultati facendo clic sulla scheda Risultati del test nel dashboard Test Lab. Il bucket dei risultati predefinito è configurato per conservare gli oggetti per 90 giorni.
Per conservare gli artefatti 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 ulteriori informazioni, consulta la documentazione di riferimento gcloud firebase test android run
.
Quando esegui test della strumentazione, potresti visualizzare errori di test che indicano risultati parziali che contengono messaggi come Test run failed to complete. Expected x tests, received y
(dove y
è inferiore a x
). Questo errore significa che Test Lab non è riuscito ad analizzare il logcat per gli indicatori di inizio o fine del test case che in genere vengono generati da AndroidJUnitRunner .
Di seguito sono riportate le cause comuni di questo problema:
Descrizione del problema | Possibile risoluzione |
---|---|
Il test case non è stato eseguito a causa di un timeout. Se la durata totale dei test è superiore a un timeout specificato o superiore a un timeout massimo , Test Lab annulla il resto dei casi di test. |
|
Il test case non è stato completato perché è uscito prematuramente o si è bloccato. Il test case potrebbe terminare prematuramente a causa di un'eccezione non rilevata o di un errore di asserzione. I casi di test possono rimanere bloccati in un ciclo infinito o potrebbero 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 sull'interfaccia utente. | Controlla il video e il logcat per verificare dove si è interrotto il test. |
Un test runner personalizzato (inclusa l'estensione AndroidJUnitRunner) si è bloccato in modo imprevisto o ha scritto indicatori di inizio o fine del test case imprevisti in logcat . | Controlla il codice del test runner. |
Sono stati scritti registri eccessivi in logcat , che hanno sovraccaricato il buffer o bloccato il processo logcat . | Riduci le scritture su logcat . |
L'app in prova si è bloccata. | Esegui il debug della tua app. |
Domande frequenti
Firebase Test Lab offre quote gratuite 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 prevede una quota di test fissa senza alcun costo per gli utenti. Per il piano Blaze, le tue quote potrebbero aumentare se l'utilizzo di Google Cloud aumenta nel tempo. Se raggiungi la quota di test, attendi fino al giorno successivo o esegui l'upgrade al piano Blaze se attualmente utilizzi il piano Spark. Se hai già il piano Blaze puoi richiedere un aumento della quota. Per ulteriori informazioni, consulta Quota di test .
Puoi monitorare l'utilizzo della quota di test nella console Google Cloud .
Quota API Cloud Testing
L'API Cloud Testing prevede due limiti di quota: richieste giornaliere per progetto e richieste ogni 100 secondi per progetto. Puoi monitorare il tuo utilizzo nella console Google Cloud .
Quota API Risultati di Cloud Tool
L'API Cloud Tool Results prevede 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 API, fai riferimento a Quote API Cloud per Test Lab . Se hai raggiunto una quota API:
Invia una richiesta per quote più elevate modificando le tue quote direttamente nella console Google Cloud (tieni presente che la maggior parte dei limiti sono impostati sul massimo per impostazione predefinita) oppure
Richiedi quote API più elevate compilando un modulo di richiesta nella console Google Cloud o contattando l'assistenza Firebase .
Dal tuo backend, puoi determinare se il traffico proviene da dispositivi di test ospitati su Firebase confrontando l'indirizzo IP di origine con i nostri intervalli IP .
Test Lab non funziona con VPC-SC, che blocca la copia di app e altri elementi di test tra la memoria interna di Test Lab e i bucket dei risultati degli utenti.
Per rilevare comportamenti instabili nei test, ti consigliamo di utilizzare l'opzione--num-flaky-test-attempts. Le repliche di Deflake vengono fatturate o conteggiate ai fini della quota giornaliera come le normali esecuzioni dei test.
Tieni presente quanto segue:
- L'intera esecuzione del test viene eseguita nuovamente quando viene rilevato un errore. Non è disponibile alcun supporto per riprovare solo i casi di test non riusciti.
- Le esecuzioni dei 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.
SÌ! Test Lab supporta Google Pixel Watch. Ora puoi eseguire test sulla tua app Wear autonoma su Google Pixel Watch. Per ulteriori informazioni sui dispositivi Test Lab, consulta Test sui dispositivi disponibili .
SÌ! Test Lab supporta Google Pixel Tablet e Google Pixel Fold. Puoi eseguire i test sui tuoi dispositivi fisici autonomi. Per ulteriori informazioni sui dispositivi Test Lab, consulta Test sui dispositivi disponibili .
Se stai testando la tua app in Firebase o eseguendo test per un report pre-lancio nella Play Console, puoi rilevare se un test è in esecuzione su un dispositivo ospitato da Firebase controllando la proprietà di sistema firebase.test.lab
in il tuo file MainActivity
. È quindi possibile eseguire istruzioni aggiuntive in base al valore booleano per testLabSetting
. Per ulteriori informazioni, consulta Comportamenti dei test modificati .
Sebbene alcuni di questi elementi siano presenti nella nostra tabella di marcia, al momento non siamo in grado di impegnarci a supportare queste piattaforme di test e di sviluppo di app. Tuttavia, se hai creato la tua app con un framework che supporta Espresso (ad esempio, Flutter), puoi scrivere un test di strumentazione utilizzando Espresso e quindi eseguire il test in Test Lab.
Test Lab non supporta esplicitamente l'offuscamento o il deoffuscamento. Sebbene l'app venga probabilmente eseguita, tutti i dati dell'app offuscati, come le analisi dello stack, verranno visualizzati come offuscati nei log.
SÌ! Puoi testare il tuo dispositivo pieghevole in stati e posture pieghevoli .
I dispositivi pieghevoli possono trovarsi in vari stati piegati, come FLAT
(completamente aperto) o HALF_OPENED
(tra completamente aperto e completamente chiuso).
Le posture, d'altra parte, consistono nell'orientamento specifico del dispositivo e nello stato pieghevole. Ad esempio, la postura del tavolo, che è uno stato HALF_OPENED
con orientamento orizzontale, o la postura del libro, che è uno stato HALF_OPENED
con orientamento verticale.
Se stai eseguendo test di strumentazione, puoi utilizzare la libreria Jetpack WindowManager e seguire il test della tua app sulla documentazione pieghevole per testare stati e posture diversi.
In alternativa, gli stati disponibili sono specifici del dispositivo e possono essere interagiti utilizzando il adb shell command cmd device_state
.
- Per elencare lo stato corrente, esegui
adb shell cmd device_state state
. - Per impostare o sovrascrivere lo stato corrente, esegui
adb shell cmd device_state state <IDENTIFIER>
. - Per ripristinare lo stato, esegui
adb shell cmd device_state state reset
. - Per verificare gli stati disponibili, esegui il comando
adb shell cmd device_state print-states
sul dispositivo pieghevole.
Google Pixel Fold (ID modello 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 (ID modello 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}, ]
A differenza di altri prodotti Firebase, non è necessario aggiungere un SDK Firebase per utilizzare Test Lab. Se non disponi già di un'app, puoi scaricare un APK online o creare un'app e un APK di prova da uno degli esempi nel repository GitHub di AndroidX . Tieni presente che per eseguire un test Robo è necessario solo il file APK dell'app, mentre un test di strumentazione richiede sia un'app che un APK di test creati dal codice sorgente. Per ulteriori informazioni, leggere Test strumentati .
Per ulteriori informazioni sulle funzionalità di Test Lab, consulta Iniziare a testare per Android con Firebase Test Lab .
Il test Screenshot-diff è il caso in cui le asserzioni del test si basano sul confronto delle immagini dello schermo ottenute durante l'esecuzione di un test con immagini dorate che rappresentano il comportamento previsto. Tali test potrebbero essere più fragili su alcuni tipi di dispositivi rispetto ad altri. Consigliamo di scegliere come target i dispositivi emulatori Arm ( *.arm
) per questo tipo di test. I dispositivi emulatori Arm utilizzano immagini molto simili o identiche agli emulatori "generici" di Android Studio.
Ti consigliamo inoltre di esaminare le librerie di test che possono contribuire a rendere i test degli screenshot più robusti in presenza di modifiche previste.
SÌ! I dispositivi virtuali vengono aggiornati quando vengono apportate le seguenti modifiche:
- Aggiornamenti alle immagini esistenti
- Deprecazione dei livelli API precedenti
- Vengono aggiunti nuovi livelli API Android
Per abilitare i report di copertura, aggiungi coverage=true
al campo environmentVariables
. Se utilizzi Android Test Orchestrator, dovrai fornire una directory in cui archiviare 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 ed è possibile accedervi dal client gcloud utilizzando il comando description :
gcloud firebase test android models describe MODEL
Problemi conosciuti
Il test Robo non può ignorare le schermate di accesso che richiedono ulteriori azioni da parte dell'utente oltre all'immissione delle credenziali per l'accesso, ad esempio il completamento di un CAPTCHA.
Il test Robo funziona meglio con le app che utilizzano elementi dell'interfaccia utente del framework dell'interfaccia utente Android (inclusi oggetti View
, ViewGroup
e WebView
). Se utilizzi il test Robo per esercitare app che utilizzano altri framework dell'interfaccia utente, incluse le app che utilizzano il motore di gioco Unity, il test potrebbe terminare senza esplorare oltre la prima schermata.