Questa pagina fornisce assistenza per la risoluzione dei problemi e risposte alle domande frequenti sull'esecuzione di test con Developer Device Platform. Se non riesci a trovare quello che stai cercando o hai bisogno di ulteriore assistenza, contattaci.
Risoluzione dei problemi
Quali risorse hai per la migrazione da Firebase Test Lab a Developer Device Platform?
Se esegui la migrazione da Firebase Test Lab a Developer Device Platform, consulta la nostra guida alla migrazione, la traduzione di comandi e flag e la skill di migrazione per gli agenti AI.
Perché il mio test richiede così tanto tempo per essere eseguito?
Quando selezioni un dispositivo con un livello di capacità elevato nel catalogo della Developer Device Platform, i test potrebbero iniziare più rapidamente. 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 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à dei dispositivi 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 Developer Device Platform, consulta la dashboard Google Cloud Personalized Service Health.
Per scoprire di più sulla capacità del dispositivo nella Developer Device Platform, consulta il catalogo dei dispositivi.
Perché ricevo risultati del test inconcludenti?
I risultati inconcludenti dei test si verificano in genere a causa di esecuzioni di test annullate
o errori dell'infrastruttura. Oltre a PASSED e FAILED, Developer Device Platform
potrebbe restituire ERROR, TIMED_OUT e CANCELLED.
Gli errori di infrastruttura sono causati da problemi interni della Developer Device Platform, ad esempio errori di rete o comportamenti imprevisti del dispositivo. La piattaforma Developer Device Platform esegue internamente più tentativi di esecuzione dei test che producono errori di infrastruttura prima di segnalare un risultato non conclusivo.
Per determinare la causa dell'errore, segui questi passaggi:
- Controlla la presenza di interruzioni note nella dashboard Google Cloud Service Health.
Riprova il test nella Developer Device Platform per verificare che sia riproducibile.
Se applicabile, prova a eseguire il test su un altro dispositivo o tipo di dispositivo. Per saperne di più, consulta il catalogo dei dispositivi.
Perché lo sharding ha allungato la durata dei miei test?
Lo sharding può causare l'esecuzione più lunga dei test quando il numero di shard specificato supera il numero di dispositivi disponibili per l'utilizzo in Developer Device Platform. Per evitare questa situazione, limita il numero di dispositivi al numero di shard. Per ulteriori informazioni sulla scelta di un altro dispositivo, consulta il catalogo dei dispositivi.
Perché il mio test richiede così tanto tempo per iniziare?
Quando invii una richiesta di test, la tua 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.
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 in Cloud Storage. La durata di questo passaggio può essere influenzata dalla quantità e dalle dimensioni degli artefatti.
Risoluzione dei problemi specifici per Android
L'app non restituisce dati e non è possibile individuare gli screenshot
Gli artefatti di esecuzione dei test (come screenshot e file di log) vengono archiviati in Cloud Storage e visualizzati direttamente nella console Google Cloud . Verifica di aver assegnato ruoli a livello di progetto.
Tieni presente inoltre che la Developer Device Platform ha un agente di servizio dedicato che utilizza le proprie credenziali anziché le tue per:
- Leggi e scrivi nei bucket e negli oggetti Cloud Storage
- Scarica i file di input di Cloud Storage nel sistema interno
- Carica i file dal sistema interno al bucket di output Cloud Storage
È possibile che tu abbia accesso a un bucket Cloud Storage e a un file, ma che il bucket sia di proprietà di un progetto Google Cloud diverso da quello utilizzato in DDP. Pertanto, il account di servizio della piattaforma per dispositivi per sviluppatori non ha accesso.
Potresti anche avere controlli dell'accesso aggiuntivi sui singoli bucket. Consulta Device Run per scoprire come includere i file nei test e Share Storage per scoprire come concedere l'accesso alla piattaforma di sviluppo di dispositivi ai bucket esterni.
Perché ricevo risultati parziali o mancanti degli scenari di test di instrumentazione?
Quando esegui i test di strumentazione, potresti notare che i casi di test totali sono inferiori a quanto previsto. Ciò è spesso causato dall'incapacità di Developer Device Platform di analizzare il logcat per i marcatori di inizio o fine dello scenario di test, che di solito 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, Developer Device Platform annulla il resto degli scenari di test. |
|
| Il caso di test non è stato completato perché è stato chiuso prematuramente o si è bloccato. Il caso di test potrebbe terminare 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 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 capire dove si è interrotto il test.
|
Un test runner personalizzato (inclusa l'estensione di AndroidJUnitRunner) ha subito un arresto anomalo
in modo imprevisto o ha scritto marcatori di inizio o fine dello scenario di test imprevisti in
logcat.
|
Controlla il codice del test runner. |
Sono stati scritti log eccessivi in logcat, che hanno sovraccaricato il buffer
o causato l'arresto anomalo del processo logcat.
|
Riduci le scritture a logcat.
|
| L'app in fase di test ha subito un arresto anomalo. | Esegui il debug dell'app. |
Domande frequenti
Dove posso trovare informazioni sui prezzi di Developer Device Platform?
Per maggiori dettagli, consulta la sezione Domande su prezzi e fatturazione.
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
dalla CLI di Developer Device Platform con il comando device-run devices describe <device-id>:
gcloud beta device-run devices describe DEVICE_ID
Come faccio a sapere se il traffico che raggiunge il mio backend proviene da Developer Device Platform?
Dal backend, puoi determinare se il traffico proviene da dispositivi di test ospitati dalla piattaforma Developer Device controllando l'indirizzo IP di origine rispetto ai nostri intervalli IP.
Developer Device Platform funziona con VPC-SC?
Developer Device Platform non funziona con VPC-SC, che blocca la copia di app e altri artefatti di test tra lo spazio di archiviazione interno di Developer Device Platform e i bucket dei risultati degli utenti.
Come faccio a ridurre i test instabili in Developer Device Platform?
Per rilevare un comportamento instabile nei test, ti consigliamo di utilizzare l'opzione
--flaky-test-attempts. Le ripetizioni di Deflake vengono fatturate o conteggiate ai fini della quota giornaliera come le normali esecuzioni dei test.
Tieni presente che:
- Per impostazione predefinita, DDP esegue i nuovi tentativi in sequenza per risparmiare sui costi. Gli utenti devono
impostare
--flaky-test-parallel-retryper l'esecuzione in parallelo. - Il flag
--flaky-test-retry-leveldefinisce se riprovare a livello dishardo di singoloteste il valore predefinito èshard. Imposta il valore sutestper ridurre le dimensioni e la durata del test dei nuovi tentativi.
Domande frequenti specifiche per iOS
La piattaforma Developer Device Platform supporta Appium, Flutter/FlutterDriver, ReactNative/Jest o Cucumber?
Sebbene alcuni di questi elementi siano nella nostra roadmap, non possiamo impegnarci a supportare queste piattaforme di test e sviluppo di app.
Perché nel test iOS mancano video nei risultati?
Il supporto per i video nei risultati è previsto per iOS 18 o versioni successive.
Domande frequenti specifiche per Android
Developer Device Platform supporta i dispositivi indossabili?
Sì. Developer Device Platform supporta Google Pixel Watch. Ora puoi eseguire test sulla tua app per Wear OS autonoma su Google Pixel Watch. Per scoprire di più sui dispositivi della piattaforma Developer Device Platform, consulta il catalogo dei dispositivi.
Developer Device Platform supporta i dispositivi Google più recenti?
Sì. Developer Device Platform supporta Google Pixel Tablet e Google Pixel Fold. Puoi eseguire i test sui tuoi dispositivi fisici autonomi. Per saperne di più sui dispositivi disponibili in Developer Device Platform, consulta il catalogo dei dispositivi.
La piattaforma per dispositivi per sviluppatori supporta Appium, Flutter/FlutterDriver, ReactNative/Jest o Cucumber?
Sebbene alcuni di questi elementi siano nella nostra roadmap, 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 strumentazione utilizzando Espresso e poi eseguire il test nella Developer Device Platform.
La Developer Device Platform supporta il test di app offuscate, ad esempio con ProGuard o R8?
Developer Device Platform non supporta esplicitamente l'offuscamento o il deoffuscamento. Anche se l'app verrà probabilmente eseguita, tutti i dati dell'app offuscati, come le analisi dello stack, appariranno offuscati nei log.
Posso utilizzare il mio dispositivo pieghevole in diverse posizioni e stati di piegatura durante il test sulla Developer Device Platform?
Sì. Puoi testare il tuo dispositivo pieghevole in stati e posture pieghevoli.
I dispositivi pieghevoli possono essere in vari stati di piegatura, ad esempio FLAT (completamente aperto) o HALF_OPENED (tra completamente aperto e completamente chiuso).
Le posture, invece, consistono in un orientamento specifico del dispositivo e in uno stato di piegatura. Ad esempio, la postura da tavolo, che è uno stato HALF_OPENED in orientamento orizzontale, o la postura a libro, che è uno stato HALF_OPENED in orientamento verticale.
Se esegui test di strumentazione, puoi utilizzare la libreria Jetpack WindowManager e seguire la documentazione relativa ai test dell'app sui dispositivi pieghevoli per testare diversi stati e posture.
In alternativa, gli stati disponibili sono specifici per dispositivo e possono essere usati tramite adb
shell command cmd device_state.
- Per elencare lo stato attuale, esegui
adb shell cmd device_state state. - Per impostare o sostituire lo stato attuale, 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-statessul 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},
]
Posso provare Developer Device Platform se non ho un'app?
A differenza di altri prodotti Developer Device Platform, non è necessario aggiungere un SDK Developer Device Platform per utilizzare Developer Device Platform. Se non hai ancora un'app, puoi scaricare un APK online o creare un'app e un APK di test da uno degli esempi nel repository GitHub di AndroidX. Tieni presente che un test di strumentazione richiede sia un'app sia un APK di test creati dal codice sorgente. Per saperne di più, leggi l'articolo sui test strumentati.
Per scoprire di più sulle funzionalità di Developer Device Platform, consulta la panoramica del prodotto DDP.
Quali dispositivi sono più adatti per i test di confronto degli screenshot?
Il test di confronto degli screenshot si basa sul confronto delle asserzioni di test con le immagini dello schermo ottenute durante l'esecuzione di un test con le immagini di riferimento che rappresentano il comportamento previsto. Questi test potrebbero essere più fragili su alcuni tipi di dispositivi rispetto ad altri. Per questi tipi di test, ti consigliamo di scegliere come target
dispositivi emulatore Arm (*.arm). I dispositivi emulatore 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ù affidabili in presenza di modifiche previste.
Developer Device Platform aggiorna i dispositivi virtuali?
Sì. I dispositivi virtuali vengono aggiornati quando vengono apportate le seguenti modifiche:
- Aggiornamenti alle immagini esistenti
- Ritiro dei livelli API precedenti
- Vengono aggiunti nuovi livelli API Android
Come faccio ad attivare i report sulla copertura?
Per attivare i report sulla copertura, aggiungi coverage=true al
additional-test-options
campo.
Se utilizzi Android Test Orchestrator, devi fornire un percorso di directory in cui
memorizzare i risultati della copertura:
--additional-test-options coverage=true,coverageFilePath=/sdcard/Download/
Se non utilizzi Orchestrator, puoi specificare un percorso del file:
--additional-test-options coverage=true,coverageFile=/sdcard/Download/coverage.ec
Come faccio ad accedere a un'app Wear senza smartphone?
Se normalmente la tua app richiede un telefono per l'accesso, puoi creare una variante di compilazione che salta l'accesso e utilizza un token incorporato nella build di test oppure leggere dai file sul disco in genere inviati utilizzando il flag --other-files-to-push.