Automazione Android con AI per testare la localizzazione delle app

Costruire un flusso di lavoro di test di localizzazione di app Android che combina pseudolocali, controlli in lingua reale, recensione RTL, OCR, screenshot e giudizio umano senza moltiplicare ogni prova da ogni locale.

La risposta breve: automatizzare il percorso, rivedere la lingua

Un flusso di lavoro di test di localizzazione di app Android affidabile separa il lavoro ripetibile del dispositivo dal giudizio di lingua. Automatizza l'impostazione del linguaggio, il lancio di app, la navigazione, le attese, gli screenshot, i controlli noti e la raccolta di prove. Mantenere la qualità della traduzione, tono, significato culturale, clipping ambiguo e equilibrio visivo sotto la revisione umana. L'obiettivo è non eseguire ogni test in ogni lingua. È quello di creare una piccola matrice basata sul rischio che espone i fallimenti più probabili per raggiungere gli utenti.

Questo è importante perché i difetti di localizzazione non sono solo parole sbagliate. Essi includono stringhe hardcoded, risorse mancanti, l'espansione del testo, layout rotti da destra a sinistra, date errate o valuta, errore tastiera, caratteri illeggibili, pulsanti clip e impostazioni di lingua che non persistono. AnonimoAI strumento di automazione Androidpuò aiutare a ripetere il percorso visibile e raccogliere prove, ma non può decidere se una frase suona naturale a un cliente locale.

Il flusso di lavoro qui sotto combina le caratteristiche ufficiali di localizzazione di Android con controlli di dispositivo osservabili. Non pretende cheLaiCai Flowsostituisce test di unità, test Compose, Espresso, UI Automator, Appium, un sistema di gestione delle traduzioni, o recensione in lingua madre. Utilizzare ogni strato per le prove che produce meglio.

Inizia con una matrice di rilascio di localizzazione, non una lista di lingua

Un elenco di lingue supportate non è un piano di prova. Una matrice di rilascio collega un locale allo schermo, condizione del dispositivo, formato di dati, direzione di scrittura e rischio di business che rendono tale locale significativo. Senza tale connessione, le squadre spesso aprono la schermata iniziale in diverse lingue, prendono uno screenshot, e mancano i guasti in checkout, ricerca, recupero account, notifiche o impostazioni.

Scegli un locale di base, un locale di espansione-pesante, un locale compatto o complesso, e un locale RTL per ogni versione. Aggiungere località specifiche del mercato solo ai flussi che portano il rischio di business materiale.Matrice Android di Firebase Test Laballo stesso modo tratta locale come una dimensione accanto al modello di dispositivo, versione Android e orientamento; questo è un modello di pianificazione utile anche quando si esegue controlli sui propri dispositivi.

Utilizzare pseudolocali Android prima dell'arrivo delle traduzioni

Pseudolocales sono il sistema di allarme rapido più economico nel flusso di lavoro.Guida pseudolocale di Androiddescrive`en-XA`, che espande e accenti testo inglese, e`ar-XB`, che esercita il comportamento da destra a sinistra. Possono esporre stringhe codificate duramente, concatenazione di stringhe rotte, pressione di layout, problemi di testo bidirezionali, e elementi che non riescono a specchiare prima che un traduttore consegni copia finale.

• Eseguire il viaggio utente principale in`en-XA`e registrare ogni stringa che rimane inglese normale; può essere codificato o al di fuori del percorso delle risorse di localizzazione.
• Ripetere lo stesso viaggio`ar-XB`e ispezionare l'ordine di navigazione, frecce posteriori, schede, indicatori di progresso, numeri misti e punteggiatura.
• Errore di cattura, vuoto, permesso, aggiornamento e stati di conferma; sono meno visibili durante la normale recensione del percorso felice.
• Trattare un fallimento pseudolocale come un difetto di localizzazione, non come prova che una particolare traduzione reale è sbagliata.

Gli sviluppatori possono anche controllare gli schermi selezionati prima.Documentazione di localizzazione di AndroideStrumenti di anteprima Composesupporta le anteprime locali, inclusi gli esempi RTL. Questi controlli code-adjacent sono veloci e dovrebbero catturare i problemi di livello dei componenti prima di un flusso di lavoro completo del dispositivo.

Testare il percorso di lingua che gli utenti prendono

Una schermata tradotta non è sufficiente se gli utenti non possono selezionare, conservare o ripristinare la lingua.Guida linguistica per-app di Androidspiega che Android 13 e successivamente fornire un'impostazione centralizzata del sistema per la lingua preferita di un'app, mentre AndroidX supporta la gestione compatibile delle applicazioni-locale nelle versioni precedenti. Le app possono anche avere il proprio raccoglitore di lingua. Ogni percorso di ingresso supportato ha bisogno di un piccolo test di transizione statale.

1. Inizia da uno stato pulito denominato: installazione fresca, installazione aggiornata, conto firmato, o backup ripristinato.
2. Scegliere il locale attraverso il sistema previsto o il percorso in-app e confermare se l'app riavvia, ricrea l'attività, o aggiornamenti in atto.
3. Navigare lontano dalle impostazioni e confermare il target locale appare su uno schermo business-critical.
4. Chiudere e riaprire l'app, quindi verificare che la preferenza persista.
5. Reset al sistema predefinito e confermare che le risorse tradotte stanti non rimangono.
6. Nelle versioni Android più vecchie, testare il percorso di compatibilità reale invece di assumere il comportamento Android 13.

La lingua del dispositivo e la lingua della tastiera sono preoccupazioni separate.Documentazione di test di localizzazione di BrowserStacknota che cambiare il linguaggio su un dispositivo Android non cambia necessariamente la lingua della tastiera. Conservare quella distinzione nella matrice in modo che un errore di input del testo non sia diagnosticato come un fallimento delle risorse.

Seleziona schermi rappresentativi a rischio

Non moltiplicare ogni test end-to-end esistente da ogni locale. Seleziona schermi in cui la localizzazione cambia comportamento, layout, fiducia o denaro. Un insieme compatto di solito include onboarding, sign-in, home navigation, ricerca, una pagina di dettaglio, un modulo, una superficie di pagamento o di conferma, impostazioni, notifiche e lo stato di errore più importante.

Primatizzare i controlli con larghezza fissa, icone adiacenti, variabili multiple, regole plurali, testo dinamico del server, schede compatte, navigazione in basso e testo tradotto su immagini. Includere una schermata con il massimo contenuto realistico piuttosto che solo i dati demo vuoti. Se la tua app supporta tablet, pieghevoli o paesaggio, aggiungili solo dove il layout cambia in modo autentico.

Dare a ogni schermata selezionata un proprietario e un motivo. Ad esempio, esiste la conferma del checkout per verificare la valuta, l'imballaggio della linea, le etichette dei pulsanti e la copia legale; la schermata di ripristino dell'account esiste per verificare il metodo di input, i messaggi di errore e gli indirizzi email bidirezionali. Questo rende i guasti attuabili invece di produrre una cartella di screenshot non spiegati.

Abbina il metodo di prova al difetto di localizzazione

Nessun singolo locatore o tecnica dell'immagine dimostra la qualità della localizzazione. Scegliere l'osservazione più piccola che può sostenere la decisione. L'esistenteGuida di prova visiva Androidspiega le differenze più ampie tra lo stato dell'interfaccia utente, OCR, corrispondenza delle immagini, rilevamento degli oggetti e screenshot; la localizzazione QA applica tali metodi ai rischi specifici della lingua.

Nella correnteLaiCai Flowcontratto, OCR restituisce una raccolta di risultati piuttosto che una risposta magica. Un flusso deve selezionare il segmento rilevante prima di confrontare testo o posizione. Allo stesso modo, una corrispondenza visiva segnala uno stato conosciuto; non dovrebbe essere teso in una pretesa che ogni pixel o frase è corretta.

Costruire un flusso di localizzazione osservabile su dispositivi Android reali

Un flusso di lavoro visivo osservabile è utile quando il team ha bisogno di ripetere la stessa navigazione attraverso dispositivi Android reali e consegnare una prova coerente del recensore.LaiCai Flowè una funzione di automazione all'internoLaiCai Screen Mirroring. Può organizzare passi visibili come attese, UI-stato controlli, OCR, modello di corrispondenza, screenshot, condizioni, loop legati, e fermate esplicite. TheLaiCai Flowguidacopre il flusso di lavoro del prodotto.

1. Nominare la costruzione, dispositivo, versione Android, locale, tema, scala del carattere e stato del conto di partenza.
2. Aprire l'app o il percorso delle impostazioni e utilizzare attese esplicite prima delle osservazioni app-dipendenti.
3. Navigare una fase di livello utente alla volta, mantenendo i dettagli tecnici di ricerca all'interno dei flussi di bambino leggibili quando il viaggio diventa complesso.
4. Controllare una condizione dello schermo stabile prima di ogni azione distruttiva o di cambiamento dello stato.
5. Cattura lo screenshot richiesto e qualsiasi risultato OCR selezionato con l'identificatore locale e dello schermo.
6. Verificare una condizione post dopo la navigazione invece di assumere un rubinetto riuscito.
7. Smettere con le prove quando lo schermo è sconosciuto; non continuare a fare clic attraverso una lingua inaspettata o dialogo.

Questo strato completa test basati su codice. Test di componenti e strumentazione dovrebbero ancora possedere la ricerca delle risorse, la logica dello stato, l'accessibilità semantica, e le affermazioni deterministiche vicino all'app. Un flusso visibile è più forte quando il supporto, la localizzazione o i recensori di rilascio hanno bisogno di un percorso ripetibile e di un pacchetto di prova leggibile dall'uomo. TheFlusso di lavoro di prova fumo di Android QAfornisce un modello generale relativo.

Dare a RTL contenuti bidirezionali il proprio pass di prova

RTL non è un elemento da aggiungere alla fine di una lista di controllo screenshot LTR. Eseguire un pass dedicato con arabo o un altro locale RTL supportato e includere contenuti di reindirizzamento misto come indirizzi e-mail, numeri di telefono, prezzi, stringhe di versione, URL, codici e marchi latini. Queste combinazioni rivelano puntuazioni e errori di ordinazione che un paragrafo completamente tradotto non può mostrare.

• Confermare che la navigazione, i cassetti, le schede, la direzione del progresso e le icone direzionali rispecchiano solo quando il loro significato dovrebbe rispecchiare.
• Controlla che i numeri, le unità, i nomi dei prodotti e i cursori di input rimangano leggibili all'interno delle frasi RTL.
• Ispezionare l'allineamento in stati vuoti, finestre di dialogo, barre degli snack, spiegazioni dei permessi e messaggi di convalida del modulo.
• Testare le onde e la navigazione posteriore per comportamento, non assumendo che ogni gesto inverti con la direzione del testo.
• Utilizzare un recensore in lingua madre per punteggiatura, fraseggio, interruzioni di linea e interpretazione culturale.

Uso`ar-XB`presto per esporre guasti strutturali, quindi eseguire almeno un vero RTL locale prima del rilascio. Uno pseudolocale può rivelare difetti specchianti, ma non convalida la tipografia o il significato della produzione copia araba.

Formati di prova, input, notifiche e superfici esterne

Alcuni dei guasti di localizzazione più costosi siedono fuori dello schermo principale in-app. Aggiungi controlli focalizzati per data e ora, separatori decimali, collocazione valuta, ordine indirizzo, unità di misura, numeri di telefono, moduli plurali, input tastiera, comportamento di appunti, testo di notifica, link profondi, contenuti web e qualsiasi dialogo di sistema su cui il viaggio dipende.

Registra quale locale guida ogni valore. La lingua dell'app, il sistema locale, il paese dell'account, la preferenza del server, il fuso orario e la tastiera possono essere in disaccordo. Uno screenshot che mostra un valore sorprendente è una prova utile, ma il bug report deve anche nominare quegli input in modo che l'ingegneria possa riprodurre la fonte del errore.

Tratti gli elenchi di negozio e gli screenshot promozionali come una superficie di rilascio separata. Il loro testo può provenire da un repository diverso e le loro immagini possono essere generate da un'altra pipeline. Riutilizzare lo stesso inventario dello schermo e schema di denominazione, ma non contrassegnare l'app localizzata semplicemente perché la descrizione del negozio è tradotta.

Mantenere la revisione umana dove l'automazione è debole

L'automazione è buona a ripetere un percorso e rilevare le prove conosciute. Gli esseri umani rimangono meglio al significato, al tono, al contesto, alla forma culturale, alla gerarchia visiva, all'umorismo, all'ambiguità, e decidere se una pausa di linea semplicemente sembra diversa o realmente danneggia la comprensione. Costruire il handoff deliberatamente invece di trattare la revisione manuale come un'eccezione non pianificata.

• Automatizza: configurazione locale, lancio, navigazione, attese, controlli di stato stabili, presenza di testo selezionata, screenshot, nome del file e imballaggio delle prove.
• Revisione manuale: significato di traduzione, naturalezza, sfumatura legale, accessibilità di script complessi, ambiguo tronca, immagini culturali, e equilibrio visivo.
• Escalate ai test di codice: mappatura esatta delle risorse, logica plurale, funzioni di formattazione deterministica e semantica dei componenti.
• Escalate a test di dispositivo o quadro: autorizzazioni di sistema, comportamento cross-app, integrazione della tastiera e transizioni del ciclo di vita.

Una regola di arresto utile è semplice: quando lo stato visibile non è uno degli stati approvati, raccogliere prove e fermare. Non lasciare che un'automazione continui attraverso uno schermo di consenso sconosciuto, passo di pagamento, azione distruttiva, o percorso di sistema non traslato. TheConfronto degli strumenti di test dell'automazione Androidpuò aiutare a assegnare ogni affermazione allo strato giusto.

Creare un pacchetto di prove su cui un team di rilascio può agire

Una plancia senza contesto crea un'altra indagine. Ogni ricerca di localizzazione dovrebbe identificare la costruzione, il pacchetto app e la versione, locale e regione, la versione Android, il dispositivo e la risoluzione, la scala del carattere, il tema, lo stato di partenza, il nome dello schermo, il risultato atteso, il risultato effettivo, e l'osservazione dello screenshot o selezionata che supporta il reclamo.

Utilizzare nomi di file stabili come`build-locale-device-screen-state.png`, quindi mantenere un manifesto che mappa i file alla matrice di prova. Variazione visiva prevista separata da difetti: una pausa di linea diversa può essere accettabile, mentre un prezzo nascosto, un pulsante non raggiungibile, marca invertita, o messaggio di errore mancante non è. Assegna la gravità per impatto dell'utente, non per differenza di pixel.

Poiché nessun dispositivo LaiCai-gestito era disponibile nel contesto di generazione attuale, questo articolo descrive un flusso di lavoro basato sul contratto piuttosto che rivendicare risultati di riferimento per una particolare app, dispositivo o locale. Eseguire un pilota rappresentativo nel vostro ambiente prima di espandere la matrice.

Localizzazione Android QA release checklist

1. Definire l'elenco locale supportato, la localizzazione dei fallback, i percorsi di selezione della lingua e i mercati ad alto rischio.
2. Corri!`en-XA`e`ar-XB`sugli schermi rappresentativi prima dell'arrivo delle traduzioni finali.
3. Verificare reale per-app, sistema e in-app di commutazione di lingua dove ogni percorso è supportato.
4. Coprire un'espansione-heavy locale, un complesso-scritto locale, e un RTL locale su un piccolo schermo.
5. Includere gli stati di errore, vuoto, caricamento, conferma, autorizzazione, aggiornamento e notifica.
6. Controllare i formati regionali, i metodi di input, la scala dei caratteri, il tema della luce/dark e la persistenza della lingua.
7. Utilizzare lo stato dell'interfaccia utente, OCR, modello di corrispondenza, screenshot e recensione umana solo per le affermazioni che possono supportare.
8. Salvare un pacchetto di prove chiamato e fermarsi sugli stati non riconosciuti.
9. Avere un recensore in lingua madre approva il significato, il tono, la punteggiatura e la vestibilità culturale.
10. Mantenere la CTA di automazione primaria nella pagina del proprietario locale-aware e utilizzare guide di supporto per i dettagli di implementazione.

Circa l'autore: BeePOS LLC si sviluppaLaiCai Screen Mirroringe la suaLaiCai Flowfunzione di automazione. Questa guida si basa sulla documentazione attuale Android, le pratiche di test di localizzazione osservate, e il pubblicatoLaiCai Flowcontratto nodo. Le domande del prodotto possono essere inviate attraverso ilLaiCai azienda e pagina di supporto.

Fonti

• Sviluppatori Android: Prova la tua app con pseudolocali
• Android Sviluppatori: Per-app preferenze della lingua
• Sviluppatori Android: Localizzare la tua app
• Sviluppatori Android: Anteprima il tuo UI con anteprime componibili
• Firebase: Inizia i test per Android con Test Lab
• BrowserStack: Test di localizzazione utilizzando App Live