Utilizza gli screenshot per l'aspetto a schermo intero, l'OCR per il testo visibile e la corrispondenza delle immagini per un target visivo noto. I test visivi Android più efficaci combinano un'affermazione mirata con tempistiche stabili e prove di fallimento.
La risposta breve: prova ciò che deve rimanere vero
Utilizza il test degli screenshot quando l'intero schermo, il componente, la spaziatura, il colore o la tipografia devono rimanere visivamente coerenti. Utilizzare l'OCR quando il requisito riguarda le parole che una persona può vedere, in particolare testo localizzato o visualizzato in modo dinamico. Utilizza la corrispondenza delle immagini quando un'icona, un pulsante, un badge o un'illustrazione noti devono essere visualizzati anche senza un identificatore dell'interfaccia utente affidabile.
Inizia con un selettore dell'interfaccia utente o uno stato di accessibilità quando il requisito è semantico: un controllo esiste, è abilitato, è selezionato o espone un'etichetta stabile. Aggiungi il rilevamento degli oggetti solo quando la destinazione appartiene a una classe visiva e potrebbe cambiare dimensione o posizione troppo per un modello. Questi metodi sono livelli, non strutture di test concorrenti.
- Chiedere quali prove potrebbero convincere un revisore che il requisito è stato superato.
- Scegli il segnale affidabile più stretto invece di confrontare ogni pixel per impostazione predefinita.
- Stabilizza lo schermo prima di osservarlo, quindi salva un artefatto quando l'asserzione fallisce.
Metodi di test visivi Android a confronto
| Metodo | Meglio per | Principale punto debole | Prove utili |
|---|---|---|---|
| Stato dell'interfaccia utente o di accessibilità | Controlli, etichette, stato abilitato, selezione, struttura di navigazione | Gli elementi con rendering personalizzato o inaccessibili potrebbero essere invisibili alla struttura dell'interfaccia utente | Gerarchia dell'interfaccia utente, proprietà selezionate, screenshot |
| Screenshot o immagine dorata | Layout, spaziatura, colori, tipografia, aspetto dei componenti | Dati dinamici, animazioni, differenze tra dispositivi e modifiche al rendering possono creare differenze rumorose | Immagine corrente, riferimento approvato, differenza visiva |
| OCR | Testo visibile, localizzazione, ricevute, messaggi di stato, valori resi come pixel | La qualità del riconoscimento dipende dal ritaglio, dalla scala, dal contrasto, dai dati linguistici, dalla rotazione e dalla segmentazione | Ritaglio di origine, testo riconosciuto, confidenza o elenco dei risultati |
| Corrispondenza del modello | Un'icona, un pulsante, un badge, una miniatura o una piccola regione stabile conosciuta | Tema, scala, compressione e riprogettazione possono invalidare il modello | Modello, regione di ricerca, migliore corrispondenza, punteggio, screenshot |
| Rilevamento oggetti | Un oggetto visivo la cui classe rimane significativa mentre la posizione o la dimensione variano | Richiede un modello compatibile, classi etichettate, soglie e convalida del modello | Versione del modello, classe, box, punteggio, screenshot |
La guida ufficiale al test degli screenshot di Android descrive il confronto del rendering corrente con un'immagine di riferimento approvata. Il plug-in di immagini di Appium espone la corrispondenza delle funzionalità, la corrispondenza dei modelli e il confronto delle somiglianze. OpenCV documenta i meccanismi di scorrimento di un modello su un'immagine, mentre Tesseract documenta il motivo per cui la preelaborazione OCR e la segmentazione della pagina sono importanti. Gli strumenti differiscono, ma la domanda sulla progettazione del test rimane la stessa: quale osservazione dimostra questo requisito?
Scegli l'affermazione giusta con quattro domande
1. Il requisito è semantico o visivo?
Se il test dice "il pulsante Invia è abilitato", controlla prima lo stato dell'interfaccia utente. Se dice "il pulsante Invia non viene tagliato dopo la modifica del carattere", utilizza uno screenshot o un controllo visivo mirato. Una query semantica è solitamente più semplice da mantenere, ma non può dimostrare l'apparenza.
2. Il testo esatto è importante?
Utilizza l'OCR quando la stringa rivolta all'utente è un requisito e il testo non viene esposto in modo affidabile attraverso la struttura dell'interfaccia utente. Limita il riconoscimento alla regione significativa più piccola, seleziona la lingua corretta e confronta un risultato normalizzato. Conserva uno screenshot perché una stringa OCR corretta da sola non può mostrare troncamenti, sovrapposizioni o scarso contrasto.
3. Esiste un obiettivo visivo stabile?
Utilizza la corrispondenza del modello per un'icona conosciuta o un piccolo controllo. Ritaglia il modello in modo preciso, cerca all'interno di una regione di interesse e imposta la soglia tra campioni reali positivi e negativi. Una soglia universale è raramente difendibile attraverso temi, risoluzioni e flussi remoti compressi.
4. L'intera composizione deve rimanere coerente?
Utilizza il confronto degli screenshot quando è importante la relazione tra molti elementi. Controlla i caratteri, le impostazioni locali, la configurazione del dispositivo, le barre di sistema, l'ora, i dati di rete, le animazioni e i contenuti inseriti. Se tali input non possono essere controllati, mascherare o ritagliare le regioni dinamiche invece di accettare un test permanentemente rumoroso.
Costruisci un test visivo che fallisca in modo utile
- Porta l'app a uno stato iniziale denominato su un dispositivo o emulatore autorizzato.
- Attendere una condizione stabile, non solo un ritardo fisso. UI Automator fornisce stabilità in attesa e un segnale di pronto specifico per l'app è ancora migliore.
- Cattura la regione di origine più piccola che contiene le prove richieste.
- Esegui un'asserzione primaria: stato dell'interfaccia utente, OCR, modello, rilevamento o confronto degli screenshot.
- Salva l'immagine sorgente e il risultato strutturato prima di intraprendere l'azione successiva.
- In caso di errore, interrompere o seguire un percorso di ripristino esaminato. Non toccare un sosia nelle vicinanze semplicemente per continuare il test.
Un controllo visivo diventa più sicuro quando autorizza una transizione. Osserva lo stato corrente, fai l'asserzione, esegui l'azione consentita solo dopo il successo e verifica la postcondizione. Si tratta dello stesso principio di progettazione descritto nellaguida al clic automatico per il riconoscimento delle immagini: il riconoscimento non è la prova che il flusso di lavoro sia terminato.
Per il lavoro su dispositivi reali,Mirroring dello schermo Android per il test di app mobilioffre al revisore una visualizzazione dal vivo mentre il test viene progettato. LaGuida al test del fumo QA di automazione Androidspiega come mantenere i controlli ripetuti ristretti e riproducibili.
Tre scenari pratici di test visivi Android
QA della localizzazione su una schermata di pagamento
Utilizza lo stato dell'interfaccia utente per accedere alla schermata di pagamento, l'OCR per confermare il totale localizzato e l'etichetta dell'azione e uno screenshot focalizzato per mostrare che le stringhe non sono tagliate o sovrapposte. Esegui ciascuna locale con dati di test controllati. Il solo confronto dei pixel a schermo intero sarà troppo sensibile alla lunghezza della stringa tradotta, mentre il solo OCR non consentirà di danneggiare il layout.
Controllo di un'icona della barra degli strumenti ridisegnata
Utilizza un modello per l'icona accettata in una piccola area della barra degli strumenti. Mantieni modelli separati quando sono supportati entrambi i temi chiari e scuri. Quando la corrispondenza fallisce, allega il ritaglio della barra degli strumenti e il miglior punteggio del candidato. Se l'icona viene ridisegnata intenzionalmente, rivedi e sostituisci il modello anziché abbassare la soglia finché non viene superata qualsiasi forma.
Un test del fumo sul telefono reale dopo l'implementazione
Inizia da un account e da uno stato dell'app noti, attendi la schermata di destinazione, afferma la propria identità, esegui un'azione consentita e verifica lo stato successivo con nome. Cattura uno screenshot su ogni errore. La densità del dispositivo, le finestre di dialogo delle autorizzazioni, le tastiere, le notifiche e gli aggiornamenti di sistema fanno parte dell'ambiente del telefono reale, quindi il test dovrebbe segnalarli invece di nasconderli.
Falsi guasti comuni e come prevenirli
| Sintomo | Probabile causa | Risposta migliore |
|---|---|---|
| La differenza tra gli screenshot cambia ad ogni esecuzione | Orologio, animazione, annunci, dati seed, tastiera, barra di sistema o contenuti di rete | Congela gli input, attendi la stabilità, ritaglia o maschera solo la regione dinamica |
| L'OCR restituisce un testo plausibile ma sbagliato | Lingua errata, contrasto basso, ritaglio ridotto, rotazione, rumore o segmentazione inadeguata | Salva il ritaglio, migliora la scala e il contrasto, scegli deliberatamente la lingua e la segmentazione |
| La corrispondenza del modello funziona solo su un telefono | Densità, tema, ridimensionamento, proporzioni o compressione diversi | Utilizza una regione di interesse e modelli convalidati per le varianti visive supportate |
| Viene trovata l'immagine giusta ma il tocco non riesce | Le coordinate della corrispondenza non sono state trasformate nella schermata corrente o una sovrapposizione blocca l'input | Separare il riconoscimento dall'azione e verificare lo stato successivo |
| Il test continua sulla schermata sbagliata | Nessuna postcondizione o limite di fallimento | Assegna un nome agli stati previsti e interrompi quando la schermata corrente è al di fuori del percorso esaminato |
| Il rilevatore di oggetti trova la classe sbagliata | Il modello o le etichette non si adattano al dominio dell'app, la soglia non è convalidata | Utilizzare un modello compatibile, registrare la versione e il punteggio, testare campioni negativi |
Le discussioni della community sui test di regressione Android spesso riportano agli stessi costi di manutenzione: matrici di dispositivi, tempistiche instabili, revisione di base e schermate il cui contenuto cambia. Questi non sono motivi per abbandonare i test visivi. Sono ragioni per rendere espliciti l'ambiente di test, la varianza accettata e gli artefatti di errore.
Come LaiCai Flow si inserisce nei test visivi
LaiCai Flowè una funzione di automazione all'interno di LaiCai Screen Mirroring. Un flusso può combinare l'acquisizione di screenshot, controlli dell'interfaccia utente, OCR, corrispondenza di modelli, rilevamento di oggetti, condizioni, azioni e transizioni esplicite di successo o errore. Ciò consente al tester di modellare lo schermo come uno stato invece di trattare il riconoscimento come un trucco isolato.
ConLaiCai Flow Inside, un profilo compatibile può essere eseguito tramite LaiCai Android Agent sul telefono dopo la distribuzione. La compatibilità dipende ancora da ogni nodo e risorsa utilizzata da quel profilo. L'OCR locale utilizza Tesseract; la corrispondenza del modello utilizza una risorsa immagine selezionata e un punteggio configurabile; il rilevamento locale compatibile utilizza un modello supportato. Un nodo di rete o un modello remoto necessita comunque della propria dipendenza di rete.
Ciò non rende ogni test visivo automaticamente affidabile. I team necessitano ancora di linee di base, modelli, regioni OCR, modelli, soglie, casi negativi e postcondizioni rappresentativi. Il vantaggio è che tali decisioni e transizioni possono essere riviste in un unico flusso di lavoro. LaAI Guida all'automazione Androidoffre una visione più ampia della creazione e dell'esecuzione su dispositivi reali.
Il pacchetto di prove minimo per un test visivo fallito
- Nome del test, build dell'app, modello del dispositivo, versione di Android, impostazioni internazionali, tema e orientamento.
- Lo screenshot di origine o l'area ritagliata utilizzata dall'asserzione.
- La linea di base, il modello, il testo, la classe o la proprietà dell'interfaccia utente previsti.
- La differenza osservata, il risultato OCR, il riquadro di delimitazione, il punteggio di corrispondenza o il valore dell'interfaccia utente.
- Lo stato denominato precedente, l'azione tentata, lo stato successivo previsto e il motivo dell'interruzione.
- Asset, modello o versione di base in modo che un revisore possa riprodurre la decisione.
Un'etichetta pass/fail senza questo contesto obbliga la persona successiva a riprodurre l'intera esecuzione. Un pacchetto di prove compatto trasforma il fallimento in una decisione rivedibile: correggere il prodotto, stabilizzare il test, aggiornare una risorsa visiva approvata o rifiutare una configurazione del dispositivo non supportata.
Domande frequenti sui test visivi Android
Ogni test dell'interfaccia utente Android dovrebbe includere uno screenshot?
No. Utilizza gli screenshot quando l'aspetto è importante o quando un elemento di errore può aiutare un revisore. Le asserzioni semantiche sono generalmente migliori per il comportamento che l'albero dell'interfaccia utente espone in modo affidabile.
L'OCR è migliore della corrispondenza delle immagini?
L'OCR risponde a domande sul testo visibile. La corrispondenza delle immagini risponde a domande su un modello visivo noto. Se il requisito include sia l'etichetta che il suo aspetto, utilizza l'OCR più uno screenshot mirato o un controllo del modello.
I test degli screenshot possono essere eseguiti su telefoni Android reali?
Sì, ma i dispositivi reali introducono più variazioni rispetto a un renderer o un emulatore controllato sul lato host. Registra la configurazione del dispositivo, stabilizza l'interfaccia utente e i dati del sistema e imposta le aspettative per la matrice del dispositivo effettivamente supportata.
Quando dovrei utilizzare il rilevamento degli oggetti?
Usalo quando una classe di oggetti significativa si sposta o si ridimensiona oltre la tolleranza di un modello stabile e solo quando un modello compatibile è stato convalidato sulle immagini reali dell'app. Non aggiungere un rilevatore solo perché sembra più avanzato.
Scegli le prove prima di scegliere la tecnologia
Un test visivo affidabile su Android inizia con una frase: cosa deve essere in grado di dimostrare un revisore? Scegli lo stato dell'interfaccia utente per la semantica, gli screenshot per la composizione, l'OCR per il testo, la corrispondenza del modello per un target visivo noto e il rilevamento degli oggetti per una classe convalidata con geometria variabile.
Quindi rendi l'osservazione parte di una transizione di stato: stabilizza, cattura, afferma, agisci solo dopo il successo, verifica la postcondizione e preserva l'evidenza del fallimento. Questo design è più facile da comprendere rispetto a una raccolta di chiamate visive sconnesse e molto più facile da gestire quando l'app o il dispositivo cambiano.
- Sviluppatori Android: test degli screenshot
- Sviluppatori Android: componi test di screenshot di anteprima
- Sviluppatori Android: UI Automator
- Appium: plugin per immagini e modalità di confronto
- OpenCV: corrispondenza dei modelli
- Tesseract: miglioramento della qualità dell'OCR
- Discussione sugli sviluppatori Android: test degli screenshot