Automatisation Android par AI pour tester la localisation des apps

Construisez un workflow de test de localisation d'application Android qui combine pseudolocales, contrôles en langage réel, RTL examen, OCR, screenshots, et jugement humain sans multiplier chaque test par chaque local.

La réponse courte : automatiser l'itinéraire, revoir la langue

Un outil d'essai fiable de localisation de l'application Android sépare le travail répétable du jugement linguistique. Automatisez la configuration du langage, le lancement de l'application, la navigation, les attentes, les captures d'écran, les vérifications de l'état connu et la collecte de preuves. Conservez la qualité de la traduction, le ton, la signification culturelle, les coupures ambiguës et l'équilibre visuel sous examen humain. L'objectif n'est pas d'exécuter chaque test dans chaque langue. Il s'agit de créer une petite matrice fondée sur le risque qui expose les défaillances les plus susceptibles d'atteindre les utilisateurs.

Cela est important parce que les défauts de localisation ne sont pas seulement de mauvais mots. Il s'agit de chaînes codées en dur, de ressources manquantes, d'extension de texte, de mises en page de droite à gauche cassées, de dates ou de monnaie incorrectes, d'inadéquations clavier, de polices illisibles, de boutons clippés et de paramètres de langue qui ne persistent pas. UneOutil d'automatisation AI Androidpeut aider à répéter l'itinéraire visible et à recueillir des preuves, mais il ne peut pas décider si une phrase semble naturelle pour un client local.

Le workflow ci-dessous combine les fonctionnalités officielles de localisation d'Android avec des contrôles d'appareil observables. Elle ne prétend pas queLaiCai Flowremplace les tests unitaires, Composez les tests, Espresso, UI Automator, Appium, un système de gestion de la traduction ou un examen en langue maternelle. Utilisez chaque couche pour la preuve qu'elle produit le mieux.

Commencez avec une matrice de diffusion de localisation, pas une liste de langues

Une liste de langues prises en charge n'est pas un plan de test. Une matrice de libération relie un local à l'écran, l'état de l'appareil, le format des données, la direction d'écriture et le risque commercial qui rendent ce local significatif. Sans cette connexion, les équipes ouvrent souvent l'écran d'accueil en plusieurs langues, prennent une capture d'écran et ratent les échecs dans la caisse, la recherche, la récupération de compte, les notifications ou les paramètres.

Choisissez un local de base, un local lourd d'expansion, un local compact ou complexe, et un local RTL pour chaque version. Ajouter des locaux spécifiques au marché uniquement aux flux qui comportent un risque commercial important.La matrice Android de Firebase Test LabDe même, traite locale comme une dimension à côté du modèle d'appareil, version Android, et l'orientation; c'est un modèle de planification utile même lorsque vous exécutez des vérifications sur vos propres appareils.

Utiliser les pseudolocales Android avant l'arrivée des traductions

Pseudolocales sont le système d'alerte rapide le moins cher dans le flux de travail.Conseil pseudolocale d'Androiddécrit`en-XA`, qui élargit et accentue le texte anglais, et`ar-XB`, qui exerce le comportement de droite à gauche. Ils peuvent exposer les chaînes codées en dur, la concaténation des chaînes cassées, la pression de mise en page, les problèmes de texte bidirectionnel et les éléments qui ne se reflètent pas avant qu'un traducteur délivre la copie finale.

• Exécutez le voyage de l'utilisateur principal dans`en-XA`et enregistrez chaque chaîne qui reste en anglais; elle peut être codée en dur ou en dehors du chemin des ressources de localisation.
• Répétez le même voyage`ar-XB`et d'inspecter l'ordre de navigation, les flèches arrière, les onglets, les indicateurs de progrès, les nombres mixtes et la ponctuation.
• Erreur de capture, vide, permission, mise à jour et états de confirmation; ils sont moins visibles lors de l'examen ordinaire du chemin heureux.
• Traiter une défaillance pseudolocale comme un défaut de localisation, pas comme une preuve qu'une traduction réelle particulière est erronée.

Les développeurs peuvent également inspecter les écrans sélectionnés plus tôt.Documentation de localisation d'AndroidetCompose l'outil d'aperçuprendre en charge les prévisualisations spécifiques à la localité, y compris les exemples RTL. Ces vérifications de code-adjoint sont rapides et devraient attraper les problèmes de niveau de composant avant un flux de travail complet de l'appareil.

Tester le chemin de langue que les utilisateurs prennent réellement

Un écran traduit ne suffit pas si les utilisateurs ne peuvent pas sélectionner, conserver ou réinitialiser la langue.Conseils linguistiques par application pour Androidexplique que Android 13 et plus tard fournir un réglage centralisé du système pour la langue préférée d'une application, tandis qu'AndroidX prend en charge la gestion compatible application-locale sur les anciennes versions. Les applications peuvent également avoir leur propre choix de langue. Chaque chemin d'entrée pris en charge nécessite un petit test de transition d'état.

1. Démarrer à partir d'un état propre nommé: nouvelle installation, mise à niveau d'installation, compte connecté, ou une sauvegarde restaurée.
2. Choisissez la locale à travers le système prévu ou le chemin dans l'application et confirmez si l'application redémarre, recrée l'activité, ou les mises à jour en place.
3. Naviguez loin des paramètres et confirmez que la zone cible apparaît sur un écran critique pour les entreprises.
4. Fermer et rouvrir l'application, puis vérifier que la préférence persiste.
5. Réinitialisez le système par défaut et confirmez que les ressources traduites inexistantes ne demeurent pas.
6. Sur les anciennes versions Android, tester le chemin de compatibilité réel au lieu d'assumer le comportement Android 13.

Le langage de l'appareil et le langage du clavier sont des préoccupations distinctes.Documentation de test de localisation de BrowserStacknote que changer de langue sur un appareil Android ne change pas nécessairement la langue du clavier. Préserver cette distinction dans la matrice de sorte qu'une défaillance d'entrée de texte n'est pas mal diagnostiquée comme une défaillance de la ressource.

Sélectionner des écrans représentatifs par risque

Ne pas multiplier chaque test de bout en bout existant par chaque local. Sélectionnez des écrans où la localisation change le comportement, la mise en page, la confiance ou l'argent. Un ensemble compact comprend généralement l'embarquement, la connexion, la navigation à domicile, la recherche, une page de détail, un formulaire, une surface de paiement ou de confirmation, les paramètres, les notifications et l'état d'erreur le plus important.

Prioriser les commandes avec largeur fixe, icônes adjacentes, variables multiples, règles plurielles, texte dynamique du serveur, cartes compactes, navigation en bas, et texte traduit sur les images. Inclure un écran avec un contenu maximum réaliste plutôt que des données de démonstration vides. Si votre application supporte les tablettes, les pliables ou le paysage, ajoutez-les seulement là où la mise en page change réellement.

Donnez à chaque écran sélectionné un propriétaire et une raison. Par exemple, la confirmation de caisse existe pour vérifier la monnaie, l'emballage des lignes, les étiquettes de boutons et la copie légale; l'écran de récupération de compte existe pour vérifier la méthode d'entrée, les messages d'erreur et les adresses de courriel bidirectionnelles. Cela rend les échecs actionnables au lieu de produire un dossier de captures d'écran inexpliquées.

Correspond à la méthode de la preuve au défaut de localisation

Aucune technique de localisation ou d'image ne prouve la qualité de localisation. Choisissez la plus petite observation qui peut appuyer la décision. LesGuide de test visuel Androidexplique les différences plus larges entre l'état de l'interface utilisateur, le ROC, le couplage d'images, la détection d'objets et les captures d'écran; l'AQ de localisation applique ces méthodes aux risques linguistiques.

Dans leLaiCai Flowcontrat, OCR renvoie une collection de résultats plutôt qu'une réponse magique. Un débit doit sélectionner le segment pertinent avant de comparer le texte ou la position. De même, une correspondance visuelle signale un état connu; elle ne doit pas être étendue dans une revendication que chaque pixel ou phrase est correcte.

Construire un flux de localisation observable sur de vrais appareils Android

Un workflow visuel observable est utile lorsque l'équipe a besoin de répéter la même navigation sur de vrais appareils Android et de donner une preuve cohérente de l'examinateur.LaiCai Flowest une fonction d'automatisation à l'intérieurLaiCai Screen Mirroring. Il peut organiser des étapes visibles telles que les attentes, les vérifications de l'état de l'interface utilisateur, OCR, la correspondance des modèles, des captures d'écran, des conditions, des boucles délimitées et des arrêts explicites. LesLaiCai Flowguidecouvre le flux de travail du produit.

1. Nommez le build, périphérique, version Android, locale, thème, échelle de police, et l'état du compte de départ.
2. Ouvrez le chemin de l'application ou des paramètres et utilisez des attentes explicites avant les observations dépendantes de l'écran.
3. Naviguez une phase au niveau de l'utilisateur à la fois, en gardant les détails techniques de recherche à l'intérieur de l'enfant lisible flux lorsque le voyage devient complexe.
4. Vérifiez une condition d'écran stable avant chaque action destructrice ou changement d'état.
5. Capturer la capture d'écran requise et tout résultat OCR sélectionné avec l'identificateur local et d'écran.
6. Vérifier une condition après la navigation au lieu de supposer qu'un robinet a réussi.
7. Arrêtez avec des preuves lorsque l'écran est inconnu; ne continuez pas à cliquer dans une langue ou une boîte de dialogue inattendue.

Cette couche complète les tests basés sur le code. Les tests de composants et d'instrumentation devraient encore posséder la recherche de ressources, la logique d'état, la sémantique d'accessibilité et les affirmations déterministes proches de l'application. Un flux visible est le plus fort lorsque les évaluateurs de support, de localisation ou de libération ont besoin d'une voie répétable et d'un paquet de preuves lisibles par l'homme. LesAndroid QA smoke-test workflowfournit un schéma général connexe.

Donnez à RTL et au contenu bidirectionnel leur propre passe de test

RTL n'est pas un élément à ajouter à la fin d'une liste de contrôle de capture d'écran LTR. Exécutez un laissez-passer dédié avec l'arabe ou un autre local de RTL pris en charge et incluez des contenus de direction mixte tels que les adresses e-mail, les numéros de téléphone, les prix, les chaînes de version, les URL, les codes et les noms de marques latines. Ces combinaisons révèlent des défaillances de ponctuation et de commande qu'un paragraphe entièrement traduit peut ne pas montrer.

• Confirmez que la navigation, les tiroirs, les onglets, la direction de progression et les icônes directionnelles ne se reflètent que lorsque leur signification doit se refléter.
• Vérifiez que les nombres, les unités, les noms de produits et les curseurs d'entrée restent lisibles dans les phrases RTL.
• Inspecter l'alignement dans les états vides, les dialogues, les snackbars, les explications de permission et les messages de validation de formulaire.
• Tester la navigation et la navigation arrière par comportement, pas en supposant que chaque geste s'inverse avec la direction du texte.
• Utilisez un évaluateur de langue maternelle pour la ponctuation, le phrasé, les pauses et l'interprétation culturelle.

Utilisation`ar-XB`tôt pour exposer les défaillances structurelles, puis exécuter au moins une vraie locale RTL avant la libération. Un pseudolocale peut révéler des défauts miroirs, mais il ne valide pas la typographie ou le sens de la production Copie arabe.

Formats d'essai, entrées, notifications et surfaces externes

Certaines des défaillances de localisation les plus coûteuses se trouvent en dehors de l'écran principal de l'application. Ajoutez des vérifications ciblées pour la date et l'heure, séparateurs décimals, placement de devises, ordre d'adresse, unités de mesure, numéros de téléphone, formulaires pluriels, entrée clavier, comportement du presse-papiers, texte de notification, liens profonds, contenu web, et toute boîte de dialogue système dont dépend le trajet.

Enregistrez quelle locale conduit chaque valeur. La langue de l'application, la localisation du système, le pays de compte, la préférence du serveur, le fuseau horaire et le clavier peuvent être en désaccord. Une capture d'écran montrant une valeur surprenante est une preuve utile, mais le rapport de bogue doit également nommer ces entrées afin que l'ingénierie puisse reproduire la source de l'inadéquation.

Traiter les listes de magasins et les captures d'écran promotionnelles comme une surface de sortie séparée. Leur texte peut provenir d'un dépôt différent et leurs images peuvent être générées par un pipeline différent. Réutiliser le même schéma d'inventaire d'écran et de nommage, mais ne pas marquer l'application localisée simplement parce que la description du magasin est traduite.

Gardez l'examen humain là où l'automatisation est faible

L'automatisation est bonne pour répéter une route et détecter des preuves connues. Les humains restent meilleurs au sens, au ton, au contexte, à l'ajustement culturel, à la hiérarchie visuelle, à l'humour, à l'ambiguïté, et décident si une rupture de ligne n'a qu'une apparence différente ou nuit à la compréhension. Construisez la remise délibérément au lieu de traiter l'examen manuel comme une exception imprévue.

• Automatiser : configuration locale, lancement, navigation, attente, contrôle de l'état stable, présence de texte sélectionnée, captures d'écran, nommage de fichiers et emballage de preuves.
• Révision manuelle : signification de la traduction, naturalité, nuance juridique, accessibilité de scripts complexes, tronquage ambigu, imagerie culturelle et équilibre visuel.
• Faire des tests de code : cartographie exacte des ressources, logique plurielle, fonctions de formatage déterministe et sémantique des composants.
• Escalate to device or framework tests: permissions système, comportement cross-app, intégration clavier, et transitions cycle de vie.

Une règle d'arrêt utile est simple : lorsque l'état visible n'est pas l'un des états approuvés, recueillir des preuves et s'arrêter. Ne laissez pas l'automatisation se poursuivre par un écran de consentement inconnu, une étape de paiement, une action destructrice ou un chemin système non traduit. LesComparaison des outils de test d'automatisation Androidpeut aider à attribuer chaque assertion à la bonne couche.

Créer un paquet de preuves une équipe de libération peut agir sur

Un tableau de bord passé/échec sans contexte crée une autre enquête. Chaque recherche de localisation doit identifier le paquet build, app et version, locale et région, version Android, périphérique et résolution, échelle de police, thème, état de départ, nom d'écran, résultat attendu, résultat réel, et la capture d'écran ou l'observation sélectionnée qui supporte la revendication.

Utilisez des noms de fichiers stables comme`build-locale-device-screen-state.png`, puis garder un manifeste qui map les fichiers à la matrice de test. Séparer la variation visuelle attendue des défauts : une rupture de ligne différente peut être acceptable, alors qu'un prix caché, un bouton inaccessible, une marque inversée ou un message d'erreur manquant ne l'est pas. Attribuer la gravité par impact utilisateur, et non par différence de pixel.

Étant donné qu'aucun appareil géré par LaiCai n'était disponible dans le contexte de la génération actuelle, cet article décrit un workflow basé sur le contrat plutôt que de réclamer des résultats de référence pour une application, un appareil ou un local particulier. Exécutez un pilote représentatif dans votre environnement avant d'élargir la matrice.

Android localisation QA liste de contrôle de libération

1. Définir la liste locale prise en charge, la liste locale de retrait, les chemins de sélection des langues et les marchés à haut risque.
2. Cours`en-XA`et`ar-XB`sur des écrans représentatifs avant l'arrivée des traductions finales.
3. Vérifier le changement de langage réel par application, système et in-app où chaque chemin est pris en charge.
4. Couvrez une localité étendue, une localité complexe et une localité RTL sur un petit écran.
5. Inclure les états d'erreur, vide, chargement, confirmation, permission, mise à jour et notification.
6. Vérifiez les formats régionaux, les méthodes d'entrée, l'échelle de police, le thème de lumière/dark et la persistance de la langue.
7. Utilisez l'état de l'assurance-chômage, le ROC, la correspondance de modèles, les captures d'écran et l'examen humain seulement pour les réclamations qu'ils peuvent soutenir.
8. Enregistrer un paquet de preuves nommé et arrêter sur les états non reconnus.
9. Demandez à un examinateur de langue maternelle d'approuver le sens, le ton, la ponctuation et l'ajustement culturel.
10. Gardez l'automatisation primaire CTA sur la page propriétaire locale-aware et utilisez des guides de support pour les détails de mise en œuvre.

A propos de l'auteur: BeePOS LLC développeLaiCai Screen Mirroringet sesLaiCai Flowfonction d'automatisation. Ce guide est basé sur la documentation Android actuelle, les pratiques d'essai de localisation observées, et la publicationLaiCai Flowcontrat de noeud. Les questions sur le produit peuvent être envoyées par l'intermédiaire deLaiCai entreprise et page support.

Sources

• Développeurs Android: Testez votre application avec des pseudolocales
• Développeurs Android : préférences linguistiques par application
• Développeurs Android: Localisez votre application
• Développeurs Android: Prévisualiser votre interface utilisateur avec des prévisualisations composables
• Firebase: Commencez à tester pour Android avec Test Lab
• BrowserStack: Test de localisation en utilisant App Live