Come riprodurre bug Android su più telefoni reali

Un flusso di lavoro di supporto pratico per trasformare un reclamo Android specifico per il dispositivo in un caso riproducibile, un pacchetto di prove e un utile passaggio di consegne ingegneristiche.

Perché i team di supporto mantengono più di un telefono Android

Un cliente può descrivere un guasto in modo accurato e comunque lasciare il supporto incapace di riprodurlo. La versione dell'app potrebbe essere corretta, eppure il problema appare solo su una singola build del produttore, versione di Android, dimensione dello schermo, stato delle permessi, lingua, rete o politica della batteria. Un singolo telefono di riferimento non può rappresentare quella gamma. Ecco perché i team di supporto mobile spesso mantengono un piccolo insieme di telefoni Android reali anche quando l'ingegneria utilizza già emulatori e test automatizzati.

L'obiettivo non è possedere ogni modello. È mantenere una copertura sufficiente per rispondere rapidamente a tre domande: il team può riprodurre il rapporto, quale condizione lo innesca e quali prove permetteranno all'ingegneria di continuare senza ripetere l'intera conversazione di supporto? AWS Device Farm identifica inoltre i rappresentanti del supporto clienti insieme a sviluppatori e team QA e descrive l'interazione con i dispositivi reali come un modo per debugare e riprodurre i problemi dei clienti.

• Autenticazione, pagamento, notifica, autorizzazione, fotocamera, Bluetooth e errori di elaborazione in background.
• Layout che si rompono su una particolare densità di schermo, scala del carattere, lingua o modalità di navigazione.
• Problemi di aggiornamento o installazione legati a una versione di Android o al firmware del produttore.
• Problemi che appaiono solo dopo un cambiamento di rete, in background delle app, restrizioni della batteria o interruzioni.
• I rapporti dei clienti che richiedono uno screenshot, una breve registrazione, i dettagli del dispositivo e i passaggi esatti di riproduzione prima dell'escalation.

Raccogli i dati minimi della custodia prima di scegliere un telefono

Non iniziare cliccando su telefoni casuali. Prima converti la conversazione di supporto in un caso testabile. La mancata conversione dei dati di ingresso spreca più tempo rispetto alla configurazione del dispositivo fisico perché il team non può distinguere un difetto specifico del dispositivo da un problema di account, build, rete o dati obsoleti.

Se un cliente non può fornire tutto, registra ciò che è sconosciuto invece di colmare silenziosamente le lacune. Il supporto può comunque testare il percorso noto, ma l'ingegneria dovrebbe essere in grado di vedere quali ipotesi sono state fatte. Non chiedere mai ai clienti di inviare password, dettagli di pagamento, documenti d'identità, messaggi privati o file personali non correlati.

Costruire una piccola matrice di dispositivi dalle prove del cliente

Un utile desk di supporto si basa sui dispositivi che i tuoi clienti usano effettivamente, non su un scaffale di attraenti telefoni di punta. Inizia con l'analisi, i rapporti di crash, il volume dei ticket e i segmenti critici per le entrate. Seleziona un dispositivo di fascia bassa, un modello comune di fascia media, un recente modello di punta e qualsiasi produttore o versione di Android che appare ripetutamente in casi irrisolti.

1. Esporta i migliori modelli di dispositivi e le versioni di Android da dati di prodotto affidabili.
2. Raggruppa dispositivi simili in base al firmware del produttore, al livello di prestazioni, alle caratteristiche dello schermo e alla generazione del sistema operativo.
3. Scegli il set fisico più piccolo che copra la più ampia percentuale di casi importanti.
4. Aggiungi un modello solo quando i biglietti o il rischio del prodotto giustificano il suo costo di manutenzione.
5. Esamina la matrice trimestralmente e ritira i dispositivi che non rappresentano più traffico o rischio significativi.

Un bancone con tre o sei telefoni è spesso più utile di una grande collezione non mantenuta. Le run di compatibilità più ampie possono ancora andare a un servizio cloud. Il bancone locale esiste per una rapida riproduzione interattiva, dimostrazioni di supporto e casi in cui gli stessi dispositivi vengono utilizzati ripetutamente. Per l'impostazione fisica, vedere ilGuida al laboratorio per dispositivi Android a basso costo.

Organizzare il bancone di supporto multi-telefono

Ogni telefono ha bisogno di un'identità stabile. Dagli un codice breve, etichettalo fisicamente e registra il suo modello, la versione di Android, l'ultima data di ripristino, lo stato della batteria, il metodo di connessione, la build di prova installata e gli account di prova assegnati. Utilizza cavi affidabili e hub USB alimentati quando diversi telefoni condividono un computer; una potenza instabile e cavi danneggiati possono causare guasti che sembrano difetti delle app.

Controlla più telefoni AndroidDa uno spazio di lavoro comune quando il team ha bisogno di confrontare schermi, passare tra dispositivi o ripetere un passaggio di configurazione autorizzato. inLaiCai Screen Mirroring, i dispositivi possono essere visibili da una singola postazione di lavoro Windows o macOS, in modo che l'operatore passi meno tempo a raccogliere telefoni e più tempo a confrontare lo stato della custodia. Il raggruppamento è utile per separare basi pulite, casi di supporto attivi, dispositivi di fascia bassa e telefoni in attesa di essere reimpostati.

• Tieni un dispositivo di base noto come buono per il confronto.
• Utilizza account di prova dedicati con dati sintetici ogni volta che possibile.
• Reimposta i dati dell'app tra i casi quando lo stato precedente potrebbe cambiare il risultato.
• Tieni il codice del telefono visibile in ogni screenshot o nota del caso.
• Registra il caricamento, l'USB, il Wi-Fi e le condizioni termiche quando influenzano il test.

Esegui un passaggio di riproduzione controllato

Il percorso più veloce per ottenere un risultato utile è solitamente un confronto controllato, non un grande lote di azioni simultanee. Inizia con il dispositivo che corrisponde di più e riproduci lo stato iniziale del cliente. Esegui le fasi riportate una volta senza cambiare nulla. Se il problema si verifica, ripetilo per confermare la frequenza. Altrimenti, cambia una variabile alla volta: rete, autorizzazione, lingua, dati dell'app, versione di Android, produttore, scala del carattere o politica della batteria.

1. Crea la scheda del caso con il codice telefonico, la versione dell'app, il tipo di account, la rete, la lingua e lo schermo iniziale.
2. Riproduci i passaggi esatti del cliente sul telefono corrispondente più vicino.
3. Ripeti lo stesso percorso sul telefono di base noto come buono.
4. Cambia solo una condizione sospetta e esegui nuovamente il percorso.
5. Smettere quando il trigger è isolato o quando è raggiunto il limite di tentativi concordato.
6. Scrivete sia i tentativi riusciti che quelli falliti; le prove negative restringono la prossima indagine.

Non utilizzare l'input sincronizzato quando i dispositivi si sono già divergenti. Una finestra di dialogo di autorizzazione, un caricamento lento, una tastiera o un prompt di aggiornamento possono inviare lo stesso clic a controlli diversi. Le azioni condivise sono utili solo quando ogni telefono selezionato è visibilmente nello stesso stato sicuro. Altrimenti, operare i dispositivi individualmente e preservare la differenza che stai cercando di capire.

Crea un pacchetto di prove che l'ingegneria può riprodurre

Un passaggio di consegne utile è abbastanza piccolo da poterlo rivedere rapidamente e abbastanza completo da poterlo riprodurre. Un biglietto dovrebbe collegare l'ambiente, i passaggi, il risultato osservato, il risultato previsto e le prove a sostegno. Le schermate mostrano uno stato statico; una breve registrazione dello schermo dimostra il tempo e la sequenza; i registri spiegano ciò che l'interfaccia non può mostrare. Nessuno di questi sostituisce gli altri.

Nomina i file con l'ID del biglietto, il codice telefonico, la versione e l'orario di creazione. Il passaggio di consegne dovrebbe permettere a un ingegnere di capire il guasto in pochi minuti senza aprire più thread di chat. Per un flusso di lavoro QA più ampio, vedereSpiegazione dello schermo Android per il test delle app mobili.

Scegli telefoni locali, emulatori o un servizio di dispositivo cloud

Questi strumenti risolvono diversi problemi di copertura. Un ufficio telefonico locale non è un sostituto di un parco di dispositivi cloud e un laboratorio cloud non elimina il valore dei telefoni familiari accanto al team di supporto. Seleziona l'ambiente meno costoso che possa riprodurre fedelmente la condizione.

Una sequenza pratica è l'emulatore per prima per un rapido controllo della sanità, i telefoni locali per possibili cause reali del dispositivo e i dispositivi cloud quando il modello manca o la custodia necessita di una conferma più ampia.Spiegazione dello schermo Android sullo schermo di un PC o MacÈ più utile quando il supporto ha bisogno di un controllo visivo diretto sui telefoni locali piuttosto che di una gestione delle politiche su una flotta aziendale distribuita.

Proteggere i dati dei clienti durante la riproduzione

La risoluzione dei problemi con dispositivi reali può esporre informazioni personali se il processo è negligente. Utilizza account sintetici e dati di test per impostazione predefinita. Se i dati di produzione sono veramente necessari, ottieni la giusta autorizzazione, limita l'accesso, cattura solo ciò di cui ha bisogno il caso e segui la politica di conservazione dell'azienda. AWS avverte inoltre gli utenti del suo servizio per dispositivi di non inserire le credenziali dell'account, le informazioni personali o altri dettagli sensibili alla sicurezza perché le sessioni possono produrre registri e video.

• Non copiare mai la password, le informazioni di pagamento, il token di autenticazione, le foto private o i documenti d'identità di un cliente in un telefono di laboratorio.
• Sbiadisci o ritaglia nomi, messaggi, indirizzi email e numeri di conto non correlati prima di allegare le prove.
• Mantenere gli account di prova separati per ambiente e ruotare le credenziali in base alla politica aziendale.
• Rimuovi screenshot, registrazioni, log, file scaricati e dati dell'app quando termina il periodo di conservazione.
• Registrare chi ha effettuato l'accesso a un caso sensibile e perché, quando la politica richiede una traccia di audit.

Gestisci il flusso di lavoro con tre telefoni

Non iniziare comprando un muro di telefoni. Scegli una classe ricorrente di casi di supporto e tre dispositivi rappresentativi: una base di buono stato, il telefono più comune del cliente e un telefono di fascia bassa o specifico del produttore in contrasto. Esegui il flusso di lavoro per due settimane, quindi decidi se un altro dispositivo o un servizio cloud risolverebbe i casi che il pilota non poteva coprire.

1. Seleziona dieci biglietti recenti che sono stati ritardati a causa dell'incertezza del dispositivo.
2. Definisci i campi di ingresso richiesti e un singolo modello di pacchetto di prove.
3. Etichettare e preparare tre telefoni con conti di prova puliti.
4. Traccia il tempo per la prima riproduzione significativa, i cicli di chiarimento, l'accettazione dell'escalation e le lacune nei dispositivi non risolte.
5. Esamina quale telefono o condizione ambientale abbia effettivamente cambiato l'esito.
6. Espandi solo quando le prove mostrano una ripetuta lacuna di copertura.

Il risultato da verificare è semplice: un ingegnere di supporto dovrebbe essere in grado di ricevere un caso, selezionare un telefono appropriato, riprodurre il percorso e fornire un handover autonomo senza cercare in diversi sistemi non correlati. Se uno spazio di lavoro locale condiviso aiuta quel pilota,LaiCai Screen Mirroringpuò mantenere visibili e controllabili i telefoni Android selezionati da un computer Windows o macOS.

Domande frequenti

Quanti telefoni Android ha bisogno un team di supporto?

Inizia con tre o sei telefoni scelti dai dati effettivi del biglietto e dell'utilizzo. Aggiungi dispositivi solo quando un caso ripetuto e importante non può essere coperto dalla matrice attuale o da una sessione occasionale in cloud.

Dovrebbe supportare la riproduzione di ogni rapporto cliente?

No. Dai priorità alla gravità, agli utenti interessati, all'impatto sull'azienda, al rischio di sicurezza, alla recidiva e alla possibilità che la riproduzione modifichi l'azione successiva. Un laboratorio di dispositivi è uno strumento decisionale, non un requisito per riprodurre ogni vaga lamentela.

Il controllo sincronizzato può riprodurre un bug su tutti i telefoni contemporaneamente?

Solo mentre i dispositivi sono visibilmente nello stesso stato e l'azione è sicura. Una volta che il temporizzatore, i dialoghi, le autorizzazioni, le tastiere o i layout differiscono, operare i telefoni individualmente. La divergenza è una prova, non qualcosa da cliccare ciecamente.

LaiCai sostituisce una piattaforma di gestione dei dispositivi mobili?

N.LaiCai Screen MirroringÈ uno strumento di controllo visivo e flusso di lavoro locale. Le flotte aziendali distribuite che necessitano di iscrizione a tocco zero, applicazione delle politiche, distribuzione di app, inventario o cancellazione remota dovrebbero utilizzare un sistema MDM o EMM appropriato.

Fonti

• Domande frequenti su AWS Device Farm
• Guida allo sviluppo di AWS Device Farm
• Laboratorio di test funzionali OpenText per dispositivi mobili e web
• Laboratorio di test remoto Samsung
• Guida di supporto per Google Android Enterprise