In questa guida
Il report pre-lancio è un test automatico che Google Play esegue sulla tua build prima che la rilasci. Non richiede configurazione extra da parte tua, quindi vale la pena leggerlo ogni volta. È anche facile leggerlo male: è un robot, non un utente.
Cosa fa
Secondo la Play Console Help di Google, il report cerca problemi di stabilità, compatibilità con Android, prestazioni e accessibilità. Parte quando carichi un app bundle o un APK e quando salvi una release in produzione. L'app viene avviata su dispositivi del laboratorio di test di Google. Poi un crawler tocca, scrive e scorre per diversi minuti. Infine i risultati vengono compilati.
Dettagli della stessa pagina che influenzano come leggerlo:
- I risultati di solito arrivano entro un'ora dal caricamento. Se un report non è completo dopo due giorni, ricarica la build.
- I dispositivi di test usano Android 9 o superiore e includono telefoni, tablet, Wear OS e dispositivi di classe desktop. Android Automotive OS e Android TV non possono essere testati.
- I dispositivi si trovano negli Stati Uniti e girano in verticale per impostazione predefinita.
- Puoi aggiungere fino a tre deep link come punti d'ingresso aggiuntivi, credenziali di un account di test, uno script Robo o un game loop, e scegliere fino a cinque lingue.
- Le app senza un'activity di avvio principale non possono essere testate (Google cita launcher, widget, tastiere e quadranti da orologio).
L'ambito cambia nel tempo. Apri la pagina attuale prima di fare affidamento su tutto questo.
Cosa non può vedere
Il crawler non conosce il tuo prodotto. Non può giudicare se l'onboarding ha senso, se un prezzo è chiaro o se il testo si legge bene. Potrebbe non superare un login se non gli dai credenziali. Tutto ciò che sta dietro un pagamento, uno stato raro o un'azione reale (una consegna, un dispositivo Bluetooth) è fuori dalla sua portata.
Come fare il triage dei risultati
Il riepilogo del report raggruppa i problemi in errori, avvisi e problemi minori, e dà una raccomandazione di lancio. Usalo come punto di partenza, non come verdetto.
| Segnalazione | Cosa fare |
|---|---|
| Crash con stack trace nel tuo codice | Riproducilo a mano. Se puoi, correggi prima del rilascio. |
| Crash in una libreria di terze parti | Controlla se riguarda un flusso reale; aggiorna la libreria se possibile. |
| Crash solo dopo che il crawler ha fatto qualcosa di innaturale | Priorità più bassa, ma verifica che l'app gestisca input anomali senza perdere dati. |
| Avviso di accessibilità (area di tocco, contrasto, etichetta mancante) | Di solito costa poco da correggere e vale molto. Verifica sul tuo dispositivo. |
| Avviso di prestazioni | Confronta con un telefono di fascia media reale prima di agire. |
| Schermata di login, nulla testato | Aggiungi credenziali di test ed esegui di nuovo. |
Una regola semplice: correggi ciò che puoi riprodurre, annota ciò che non puoi, e non ignorare nulla senza un motivo scritto.
Usalo insieme ai tester reali
Il report trova rapidamente crash e difetti evidenti su un insieme fisso di dispositivi. Le persone trovano flussi confusi, parole sbagliate e problemi sui propri telefoni. Usa entrambi. Per il lato dei dati sul campo, vedi Nozioni base di Android vitals; per il confronto, vedi test su dispositivi cloud e tester reali.
Parte della guida al test di app Android.
Ti servono persone reali per provare la tua build? Inizia qui e ricevi feedback privato e strutturato.