Utilisez des captures d'écran pour une apparence plein écran, l'OCR pour le texte visible et la correspondance d'images pour une cible visuelle connue. Les tests visuels Android les plus puissants combinent une assertion ciblée avec un timing stable et des preuves d'échec.
La réponse courte : testez ce qui doit rester vrai
Utilisez des tests de capture d'écran lorsque l'ensemble de l'écran, le composant, l'espacement, la couleur ou la typographie doivent rester visuellement cohérents. Utilisez l'OCR lorsque l'exigence concerne des mots qu'une personne peut voir, en particulier du texte localisé ou rendu dynamiquement. Utilisez la correspondance d'images lorsqu'une icône, un bouton, un badge ou une illustration connue doit apparaître même s'il n'a pas d'identifiant d'interface utilisateur fiable.
Commencez par un sélecteur d’interface utilisateur ou un état d’accessibilité lorsque l’exigence est sémantique : un contrôle existe, est activé, est sélectionné ou expose une étiquette stable. Ajoutez la détection d'objet uniquement lorsque la cible appartient à une classe visuelle et peut trop changer de taille ou de position pour un modèle. Ces méthodes sont des couches et non des cadres de test concurrents.
- Demandez quelles preuves pourraient convaincre un évaluateur que l'exigence est satisfaite.
- Choisissez le signal fiable le plus étroit au lieu de comparer chaque pixel par défaut.
- Stabilisez l'écran avant de l'observer, puis enregistrez un artefact lorsque l'assertion échoue.
Comparaison des méthodes de tests visuels Android
| Méthode | Idéal pour | Principale faiblesse | Preuve utile |
|---|---|---|---|
| État de l’interface utilisateur ou de l’accessibilité | Contrôles, étiquettes, état activé, sélection, structure de navigation | Les éléments rendus sur mesure ou inaccessibles peuvent être invisibles dans l'arborescence de l'interface utilisateur. | Hiérarchie de l'interface utilisateur, propriétés sélectionnées, capture d'écran |
| Capture d'écran ou image dorée | Mise en page, espacement, couleurs, typographie, apparence des composants | Les données dynamiques, les animations, les différences entre les appareils et les modifications du rendu peuvent créer des différences bruyantes | Image actuelle, référence approuvée, différence visuelle |
| ROC | Texte visible, localisation, reçus, messages d'état, valeurs rendues sous forme de pixels | La qualité de la reconnaissance dépend du recadrage, de l'échelle, du contraste, des données linguistiques, de la rotation et de la segmentation. | Recadrage source, texte reconnu, confiance ou liste de résultats |
| Correspondance de modèle | Une icône, un bouton, un badge, une vignette ou une petite région stable connue | Le thème, l'échelle, la compression et la refonte peuvent invalider le modèle | Modèle, région de recherche, meilleure correspondance, score, capture d'écran |
| Détection d'objet | Un objet visuel dont la classe reste significative même si la position ou la taille varie | Nécessite un modèle compatible, des classes étiquetées, des seuils et une validation du modèle | Version modèle, classe, boîte, partition, capture d'écran |
Les instructions officielles de test de capture d'écran d'Android décrivent la comparaison du rendu actuel avec une image de référence approuvée. Le plugin d'image d'Appium expose la correspondance de fonctionnalités, la correspondance de modèles et la comparaison de similarités. OpenCV documente les mécanismes de glissement d'un modèle sur une image, tandis que Tesseract explique pourquoi le prétraitement OCR et la segmentation des pages sont importants. Les outils diffèrent, mais la question de conception des tests reste la même : quelle observation prouve cette exigence ?
Choisissez la bonne affirmation avec quatre questions
1. L’exigence est-elle sémantique ou visuelle ?
Si le test indique « le bouton Soumettre est activé », inspectez d'abord l'état de l'interface utilisateur. S'il indique « le bouton Soumettre n'est pas tronqué après le changement de police », utilisez une capture d'écran ou une vérification visuelle ciblée. Une requête sémantique est généralement plus facile à maintenir, mais elle ne peut pas prouver l’apparence.
2. Le texte exact est-il important ?
Utilisez l'OCR lorsque la chaîne destinée à l'utilisateur est requise et que le texte n'est pas exposé de manière fiable via l'arborescence de l'interface utilisateur. Limitez la reconnaissance à la plus petite région significative, sélectionnez la langue correcte et comparez un résultat normalisé. Conservez une capture d'écran, car une chaîne OCR correcte ne peut pas à elle seule montrer une troncature, un chevauchement ou un mauvais contraste.
3. Existe-t-il une cible visuelle stable ?
Utilisez la correspondance de modèle pour une icône connue ou un petit contrôle. Recadrez étroitement le modèle, recherchez dans une région d'intérêt et définissez le seuil à partir d'échantillons réels positifs et négatifs. Un seuil universel est rarement défendable pour tous les thèmes, résolutions et flux distants compressés.
4. L’ensemble de la composition doit-il rester cohérent ?
Utilisez la comparaison de captures d'écran lorsque la relation entre de nombreux éléments est importante. Contrôlez les polices, les paramètres régionaux, la configuration de l'appareil, les barres système, l'heure, les données réseau, les animations et le contenu prédéfini. Si ces entrées ne peuvent pas être contrôlées, masquez ou recadrez les régions dynamiques au lieu d'accepter un test bruyant en permanence.
Construisez un test visuel qui échoue utilement
- Amenez l’application à un état de départ nommé sur un appareil ou un émulateur autorisé.
- Attendez une condition stable, pas seulement un délai fixe. UI Automator offre une attente de stabilité et un signal prêt spécifique à l'application est encore meilleur.
- Capturez la plus petite région source contenant les preuves requises.
- Exécutez une assertion principale : état de l'interface utilisateur, OCR, modèle, détection ou comparaison de capture d'écran.
- Enregistrez l'image source et le résultat structuré avant d'effectuer l'action suivante.
- En cas d'échec, arrêtez ou suivez un chemin de récupération révisé. N'appuyez pas sur un sosie à proximité simplement pour faire avancer le test.
Un contrôle visuel devient plus sécuritaire lorsqu'il autorise une transition. Observez l'état actuel, faites l'assertion, n'effectuez l'action autorisée qu'après succès et vérifiez la postcondition. Il s'agit du même principe de conception décrit dans le guide de clic automatique de reconnaissance d'image: la reconnaissance ne constitue pas une preuve que le flux de travail est terminé.
Pour le travail sur appareil réel, la mise en miroir d'écran Androidpour les tests d'applications mobilesdonne à un réviseur une vue en direct pendant la conception du test. Le guide de test de fumée QA pour l'automatisation Androidexplique comment assurer des contrôles répétés précis et reproductibles.
Trois scénarios pratiques de tests visuels Android
Contrôle qualité de la localisation sur un écran de paiement
Utilisez l'état de l'interface utilisateur pour accéder à l'écran de paiement, l'OCR pour confirmer le total localisé et l'étiquette d'action, ainsi qu'une capture d'écran ciblée pour montrer que les chaînes ne sont pas coupées ou ne se chevauchent pas. Exécutez chaque paramètre régional avec des données de test contrôlées. Une comparaison de pixels en plein écran à elle seule sera trop sensible à la longueur de la chaîne traduite, tandis que l'OCR seule ne manquera pas les dommages causés à la mise en page.
Vérification d'une icône de barre d'outils repensée
Utilisez un modèle pour l'icône acceptée dans une petite région de la barre d'outils. Conservez des modèles séparés lorsque les thèmes clairs et sombres sont tous deux pris en charge. Lorsque la correspondance échoue, attachez le recadrage de la barre d'outils et le score du meilleur candidat. Si l'icône est intentionnellement repensée, examinez et remplacez le modèle plutôt que d'abaisser le seuil jusqu'à ce qu'une forme passe.
Un test de fumée sur téléphone réel après le déploiement
Commencez à partir d'un compte et d'un état d'application connus, attendez l'écran d'accueil, affirmez son identité, effectuez une action autorisée et vérifiez l'état nommé suivant. Capturez une capture d'écran à chaque échec. La densité des appareils, les boîtes de dialogue d'autorisation, les claviers, les notifications et les mises à jour du système font partie de l'environnement du téléphone réel, le test doit donc les signaler au lieu de les masquer.
Faux échecs courants et comment les éviter
| Symptôme | Cause probable | Meilleure réponse |
|---|---|---|
| La différence de capture d'écran change à chaque exécution | Horloge, animation, publicités, données prédéfinies, clavier, barre système ou contenu réseau | Geler les entrées, attendre la stabilité, recadrer ou masquer uniquement la région dynamique |
| L'OCR renvoie un texte plausible mais erroné | Mauvaise langue, faible contraste, petit recadrage, rotation, bruit ou segmentation inappropriée | Enregistrez le recadrage, améliorez l'échelle et le contraste, choisissez délibérément la langue et la segmentation |
| La correspondance de modèle ne fonctionne que sur un seul téléphone | Densité, thème, mise à l'échelle, rapport hauteur/largeur ou compression différents | Utilisez une région d'intérêt et des modèles validés pour les variantes visuelles prises en charge |
| La bonne image est trouvée mais le robinet échoue | Les coordonnées de correspondance n'ont pas été transformées sur l'écran actuel ou une superposition bloque l'entrée | Séparez la reconnaissance de l'action et vérifiez l'état suivant |
| Le test continue sur le mauvais écran | Pas de postcondition ou de bord d'échec | Nommez les états attendus et arrêtez-vous lorsque l'écran actuel se trouve en dehors du chemin examiné |
| Le détecteur d'objet trouve la mauvaise classe | Le modèle ou les libellés ne correspondent pas au domaine de l'application, le seuil n'est pas validé | Utilisez un modèle compatible, enregistrez la version et le score, testez les échantillons négatifs |
Les discussions de la communauté sur les tests de régression Android reviennent souvent sur les mêmes coûts de maintenance : matrices d'appareils, timing irrégulier, examen de base et écrans dont le contenu change. Ce ne sont pas des raisons pour abandonner les tests visuels. Ce sont des raisons pour rendre explicites l’environnement de test, les écarts acceptés et les artefacts d’échec.
Comment LaiCai Flow s’intègre dans les tests visuels
LaiCai Flowest une fonctionnalité d'automatisation à l'intérieur de LaiCai Screen Mirroring. Un flux peut combiner capture d'écran, vérifications de l'interface utilisateur, OCR, correspondance de modèles, détection d'objets, conditions, actions et transitions explicites de réussite ou d'échec. Cela permet à un testeur de modéliser l'écran comme un état au lieu de traiter la reconnaissance comme une astuce isolée.
AvecLaiCai Flow Inside, un profil compatible peut s'exécuter via LaiCai Android Agent sur le téléphone après le déploiement. La compatibilité dépend toujours de chaque nœud et actif utilisé par ce profil. L'OCR locale utilise Tesseract ; la correspondance de modèles utilise un élément d'image sélectionné et un score configurable ; la détection locale compatible utilise un modèle pris en charge. Un nœud de réseau ou un modèle distant a toujours besoin de sa propre dépendance réseau.
Cela ne rend pas automatiquement chaque test visuel fiable. Les équipes ont toujours besoin de références représentatives, de modèles, de régions OCR, de modèles, de seuils, de cas négatifs et de postconditions. L’avantage est que ces décisions et transitions peuvent être examinées dans un seul flux de travail. Le guide d'automatisation AndroidAIoffre une vue plus large de la création et de l'exécution sur des appareils réels.
L'ensemble minimum de preuves pour un test visuel échoué
- Nom du test, version de l'application, modèle de l'appareil, version Android, paramètres régionaux, thème et orientation.
- La capture d'écran source ou la région recadrée utilisée par l'assertion.
- Propriété de référence, de modèle, de texte, de classe ou d'interface utilisateur attendue.
- La différence observée, le résultat OCR, le cadre de délimitation, le score de correspondance ou la valeur de l'interface utilisateur.
- L'état nommé précédent, l'action tentée, l'état suivant attendu et le motif de l'arrêt.
- Version de l'actif, du modèle ou de la référence afin qu'un réviseur puisse reproduire la décision.
Une étiquette réussite/échec sans ce contexte oblige la personne suivante à reproduire l’intégralité de l’exécution. Un ensemble compact de preuves transforme l'échec en une décision révisable : réparer le produit, stabiliser le test, mettre à jour un actif visuel approuvé ou rejeter une configuration d'appareil non prise en charge.
FAQ sur les tests visuels Android
Chaque test de l'interface utilisateur Android devrait-il inclure une capture d'écran ?
Non. Utilisez des captures d'écran lorsque l'apparence est importante ou lorsqu'un artefact d'échec peut aider un réviseur. Les assertions sémantiques sont généralement meilleures pour les comportements que l'arborescence de l'interface utilisateur expose de manière fiable.
L’OCR est-elle meilleure que la correspondance d’images ?
L'OCR répond aux questions sur le texte visible. La correspondance d'images répond aux questions sur un modèle visuel connu. Si l'exigence inclut à la fois l'étiquette et son apparence, utilisez l'OCR ainsi qu'une capture d'écran ciblée ou une vérification de modèle.
Les tests de capture d’écran peuvent-ils s’exécuter sur de vrais téléphones Android ?
Oui, mais les appareils réels introduisent plus de variations qu'un moteur de rendu ou un émulateur contrôlé côté hôte. Enregistrez la configuration de l'appareil, stabilisez l'interface utilisateur et les données du système et définissez les attentes concernant la matrice d'appareils que vous prenez réellement en charge.
Quand dois-je utiliser la détection d’objets ?
Utilisez-le lorsqu'une classe d'objet significative se déplace ou évolue au-delà de la tolérance d'un modèle stable, et uniquement lorsqu'un modèle compatible a été validé sur les images réelles de l'application. N'ajoutez pas de détecteur simplement parce qu'il semble plus avancé.
Choisissez les preuves avant de choisir la technologie
Des tests visuels Android fiables commencent par une phrase : que doit être capable de prouver un évaluateur ? Choisissez l'état de l'interface utilisateur pour la sémantique, les captures d'écran pour la composition, l'OCR pour le texte, la correspondance de modèles pour une cible visuelle connue et la détection d'objets pour une classe validée à géométrie variable.
Intégrez ensuite l'observation à une transition d'état : stabilisez, capturez, affirmez, n'agissez qu'après le succès, vérifiez la postcondition et préservez les preuves d'échec. Cette conception est plus facile à comprendre qu’un ensemble d’appels visuels déconnectés et beaucoup plus facile à maintenir lorsque l’application ou l’appareil change.
- Développeurs Android : tests de capture d'écran
- Développeurs Android : test de capture d'écran de l'aperçu de composition
- Développeurs Android : UI Automator
- Appium : plugin Images et modes de comparaison
- OpenCV : correspondance de modèles
- Tesseract : améliorer la qualité de l'OCR
- Discussion avec les développeurs Android : test de capture d'écran