Tester des profils Android sur ordinateur et serveur

Si la QA Android montre seulement qu'une page tient dans une capture étroite, utilisez le parcours navigateur fondé sur les profils BotBrowser pour répéter les contrôles tactiles, de viewport, de permissions et de navigation, puis réservez les affirmations dépendantes du matériel à un appareil réel.

Résumé

• Utilisez un profil Android approuvé comme référence navigateur documentée.
• Testez la tâche complète : tactile, orientation, permissions, erreurs et variation de l'espace visible.
• Séparez les parcours dans un navigateur autonome et dans une surface intégrée.
• Vérifiez sur matériel les capteurs, le retour vers une application native, les dialogues système et le vrai clavier ou lecteur d'écran.

Sommaire

• Un test mobile doit suivre un parcours mobile
• Usages adaptés
• Quand utiliser un appareil Android réel
• Décider du déploiement
• Questions courantes
• Conclusion

Un test mobile doit suivre un parcours mobile

Une capture étroite peut révéler un premier défaut de mise en page, mais elle ne prouve pas que le client termine sa tâche. Un parcours Android comprend le tactile, l'espace changeant autour des formulaires, l'orientation, les médias, les choix de permission, la navigation de plateforme et les conventions de la famille de navigateur.

BotBrowser propose des parcours Android fondés sur des profils pour postes et serveurs. Le profil coordonne affichage, saisie, graphismes, médias, région et identité de plateforme. Les équipes répètent une QA mobile autorisée sans maintenir un téléphone physique pour chaque exécution.

Traitez le profil comme une référence documentée. Le cas nomme la famille mobile, le parcours, la classe de compte, la langue, l'orientation et le résultat attendu. Développeurs et réviseurs peuvent reproduire la condition au lieu de deviner l'origine de réglages provisoires. Pour la stratégie plus large mobile, tablette et ordinateur qui sous-tend cette référence, consultez Tests de profils d'appareil : mobile, tablette et ordinateur, qui compare la façon de planifier et de revoir chaque classe d’appareil.

Usages adaptés

Cette couverture sert la mise en page adaptative, le consentement, la confidentialité, l'accessibilité, le support, la régression et la compatibilité entre familles de navigateur. Elle convient aux tâches qui restent dans le navigateur : connexion, recherche, achat, compte, document, lecture et application web installable.

Le même profil peut accompagner une évolution du poste de développement à la CI puis à la livraison. Lorsqu'un défaut apparaît, l'équipe rejoue la condition sans attendre une place au laboratoire.

Les critères liés au matériel restent sur appareil réel : qualité d'une caméra, radio, biométrie, batterie, température, dialogue du système ou transition vers une application native. Le profil couvre le travail navigateur répétable et libère du temps matériel.

Confidentialité sur mobile

Les pages mobiles demandent parfois des données personnelles lorsque l'écran est chargé. Position, caméra, microphone, notifications, fichiers et paiement demandent une revue attentive. La page explique la demande, offre un choix réel et reste utilisable après un refus.

Un profil cohérent maintient ensemble affichage, tactile, présentation du navigateur, médias et région. Le réviseur se concentre sur la demande de l'application et sa réponse. Pour comprendre comment l’identité mobile reste cohérente entre hôtes Android, iOS et ordinateur, consultez Cohérence d’un navigateur mobile entre Android, iOS et ordinateur, qui précise ce qu’un relecteur doit s’attendre à voir concorder.

Utilisez des comptes approuvés et des données synthétiques ou contrôlées. Captures, vidéos et traces peuvent contenir noms, adresses ou documents. Limitez la collecte, masquez avant partage et appliquez les règles d'accès et de conservation.

Navigateur autonome et surface intégrée

Une application Android peut ouvrir une page dans un navigateur autonome ou dans une surface web intégrée. Les parcours diffèrent parfois par la navigation, l'espace, le compte, les fichiers et le retour vers l'application.

Créez deux cas. Le parcours autonome part d'un point d'entrée normal et utilise la navigation du navigateur. Le parcours intégré peut commencer dans une application authentifiée, disposer de moins d'espace et rendre la main à la fin. La famille de profil correspond au scénario écrit.

Définissez chaque cas par la famille visible, le point d'entrée approuvé, la navigation et le résultat attendu. Le test reste ainsi stable lors d'une évolution de l'intégration et les preuves restent utiles à l'équipe produit.

Construire la matrice à partir des tâches

Commencez par la connexion, le consentement, l'achat et un parcours de contenu critique. Ajoutez les engagements de support, d'accessibilité et les mises en page réellement différentes. La couverture planifiée peut ensuite étendre les langues et les familles.

Chaque cas précise famille et orientation, tâche complète, résultat de succès et responsable. Un grand catalogue sans exigence utilise des ressources sans fournir une assurance claire. Une petite sélection avec des propriétaires protège mieux le produit.

Affichage adaptatif

Examinez tout le parcours. Navigation, consentement, boîtes de dialogue, formulaires, médias et actions principales restent accessibles. Contrôlez les barres fixes, l'espace aux bords et le contenu ajouté après une erreur.

Utilisez le portrait comme référence lorsqu'il correspond au produit. Ajoutez le paysage pour vidéo, carte, document, graphique ou tâche qui accepte la rotation. Conservez données saisies, choix, position de lecture et dialogues déjà fermés.

Le profil contrôle l'affichage mobile. N'ajoutez pas un réglage indépendant du framework. Une taille spéciale devient une variation nommée avec son propre résultat.

Tactile et interaction

Suivez la façon dont une personne termine la tâche. Les cibles doivent être accessibles et séparées, le défilement prévisible et les menus faciles à fermer. Testez glisser ou geste uniquement si le produit les utilise.

L'automatisation réalise les actions approuvées. Une revue humaine repère un choix de consentement difficile, une erreur éloignée du champ ou une commande trop dense. Combinez les deux formes de preuve sur les parcours sensibles.

Observez le produit et conservez les preuves applicatives nécessaires au résultat. La revue humaine complète l'automatisation lorsque le consentement, la lisibilité ou la densité des commandes demande un jugement. Pour juger de façon structurée si un profil mobile est assez solide pour ces contrôles, consultez Revue de qualité des profils de navigateur mobiles, qui traite les états de viewport, les parcours clavier et tactile, et le rythme de revue.

Formulaires et espace visible

Le clavier à l'écran réduit la partie visible. Connexion, recherche, adresse, paiement, récupération, chat et éditeur sont concernés. Le champ actif, son libellé, l'erreur et l'action suivante restent visibles ou atteignables.

Terminez la séquence. Changez de champ, corrigez une erreur, ouvrez une aide, fermez-la et revenez après annulation. Vérifiez le défilement et la position quand la saisie prend fin. La première mise au point ne suffit pas.

BotBrowser propose un mode optionnel --bot-mobile-keyboard dans les parcours mobiles compatibles. Lorsqu'il est activé, visualViewport.height diminue lorsqu'un champ modifiable reçoit le focus à la suite d'une action utilisateur de confiance, afin de représenter l'espace visible occupé par le clavier. Utilisez la préparation documentée et laissez le framework gérer seulement les actions de l'utilisateur.

Consentement et permissions

Une permission associe présentation, explication et choix conservé. Vérifiez accord initial, refus, annulation et retour lorsque le produit les prend en charge. L'application continue de manière sûre après un refus et explique comment modifier le choix.

Définissez l'état du navigateur. Un état propre représente la première visite, un état conservé le retour. Étiquetez chaque preuve et évitez de transférer permissions ou stockage entre cas.

Pour caméra et microphone, vérifiez aperçu, silence, annulation et récupération. Pour position et notifications, la demande doit apparaître au bon moment et ne pas insister après un refus.

Médias, fichiers et téléchargements

Les commandes média nécessitent de l'espace et un état clair. Testez lecture, pause, silence, sous-titres, plein écran lorsqu'il est pris en charge, interruption et retour. Les avis de confidentialité restent disponibles autour d'une capture ou d'un envoi.

Les fichiers utilisent des données synthétiques, affichent la progression et permettent annulation et reprise. Nettoyez le runner selon la politique. Lorsqu'un téléchargement passe à une application du système, le profil couvre la partie navigateur et le matériel confirme l'étape système.

Navigation et retour vers l'application

Les parcours mobiles franchissent des limites : un lien de courriel ouvre le navigateur, un paiement revient à l'application ou le support ouvre un document. Définissez la partie navigateur et celle qui exige un appareil ou un banc applicatif.

Contrôlez retour, annulation, actualisation et lien de sortie. Un utilisateur ne doit pas répéter un paiement ni perdre une récupération. Les familles autonome et intégrée ont des résultats distincts lorsque leur navigation diffère.

Basez le cas sur le point d'entrée approuvé et le résultat observable. Reliez toute transition externe à un cas géré par l'équipe responsable de cette application.

Région et langue

Consentement, adresse, paiement, date, support et mentions légales varient selon la région. Sélectionnez langue, fuseau et route dans le plan autorisé.

Chaque condition régionale forme un cas. Documentez compte, famille, langue, fuseau et route. Pour enquêter, ne changez qu'une condition significative à la fois.

Contrôlez l'expansion du texte, les langues de droite à gauche lorsqu'elles sont prises en charge, les méthodes de saisie, les formats et le repli linguistique. Une option de confidentialité ne doit pas rester non traduite.

Accessibilité

Le tactile exige des noms accessibles, un ordre de focus utile, du contraste, des erreurs claires et une alternative aux gestes exclusifs. Un clavier pris en charge sur tablette ou téléphone constitue une condition distincte. La certification avec lecteur d'écran utilise la technologie et l'environnement prévus au plan.

Les profils donnent des références visuelles et interactives répétables. Ils révèlent commandes masquées, texte coupé, perte de focus et défaut de rotation, sans remplacer les spécialistes de l'accessibilité.

Ajoutez mouvement réduit et agrandissement du texte comme variations explicites lorsqu'ils font partie des exigences.

Preuves et contrôle des données

Notez family, browser.version, parcours, classe de compte, langue, orientation, état et résultat attendu. Le compte rendu décrit la condition, pas la composition du profil.

Cadrez les captures sur l'application. Commencez l'enregistrement peu avant le comportement et terminez quand le résultat est clair. Masquez données personnelles, jetons, paiement et hôtes. Stockez les artefacts sous les contrôles existants.

Les diagnostics peuvent contenir des identifiants. Recueillez-les pendant la durée minimale et attribuez la conservation et la suppression avant d'étendre à plusieurs runners.

Reliez chaque échec à l'étape visible qui l'a produit. Une commande masquée, une erreur cachée par le clavier et un retour incomplet depuis une autre application appartiennent souvent à des responsables différents. La référence doit permettre à la bonne équipe de reproduire la condition sans conserver toute la session.

Séparez la preuve de livraison du matériel d'enquête. La première montre le résultat avec un contenu minimal. Le second peut demander davantage de contexte, mais il reçoit un accès limité, une date d'expiration et un responsable de la suppression.

Avant d'approuver une version, vérifiez que chaque référence indique l'état initial, le résultat attendu et la décision du responsable. En cas d'échec, revenez à la dernière combinaison approuvée et rejouez le parcours avec les mêmes données. Conservez les deux résultats sous la même revue afin de distinguer une régression d'une variation de l'environnement.

Exploitation en CI

Le runner reçoit navigateur, profil, tests et secrets approuvés par les contrôles normaux. Figez browser.version, le profil et les secrets pour la barrière de livraison. Un changement silencieux de profil ou de version empêche une bonne comparaison.

Séparez les données de navigateur entre cas parallèles et gérez volontairement première visite et retour. Nettoyez les fichiers synthétiques et ne gardez que les preuves requises.

Mesurez la capacité avec l'application. Médias, documents et tableaux de bord coûtent davantage qu'un formulaire. Commencez avec une concurrence modérée, observez l'achèvement et la marge, puis fixez une limite propre à la charge.

Incluez dans la barrière les fins de parcours qui libèrent les ressources: fermeture normale, annulation, délai dépassé et échec applicatif. Un parcours peut afficher le bon résultat tout en laissant un état qui affecte le cas suivant. La capacité revient au pool après le nettoyage prévu.

Lorsqu'un runner s'écarte de la référence, retirez-le des nouvelles tâches et conservez son affectation pour la revue. Modifier ensemble profil, version et route empêche une attribution claire. Restaurez une combinaison approuvée, puis changez une seule condition au prochain essai.

Développement et support

Le développeur utilise la même famille que la CI, avec version, compte, langue et parcours alignés. Un répertoire dédié et des données approuvées évitent de mêler l'état personnel. Partagez un chemin court et une preuve masquée.

Pour le support, demandez parcours, famille approximative, orientation, navigateur, langue, état et résultat visible. Ces informations suffisent généralement à sélectionner une référence de reproduction approuvée.

Rejouez avec le profil approuvé le plus proche et des données contrôlées. Si le résultat dépend d'un téléphone, d'un capteur, d'une application ou d'une politique précise, passez à l'environnement matériel.

Le rapport de support distingue une reproduction confirmée d'une approximation. Cette précision oriente l'équipe vers une correction applicative, une revue du profil ou un essai sur appareil.

Consignez le choix retenu avec le propriétaire du parcours concerné.

Reproduction pour le support

Le support doit utiliser la même référence mobile pour reproduire un problème et noter le parcours, la famille, l'orientation, la langue, l'état et le résultat visible ; les écarts dépendant d'un appareil réel sont escaladés séparément.

Mise à niveau et livraison

Exécutez la barrière mobile après une évolution du navigateur, des profils, du framework ou de l'application. Changez une couche à la fois lorsque possible et comparez avec la même famille et orientation.

Donnez la priorité au consentement, à l'accès, à l'achat, au retour de paiement, aux fichiers et au support. Vérifiez refus et annulation, pas seulement la réussite. Toute quarantaine mentionne motif, cas de diagnostic et date de révision.

Promouvez la nouvelle combinaison par groupes. Gardez la référence précédente disponible jusqu'à la fin de l'observation du groupe candidat. Le retour restaure ensemble navigateur, profil et préparation du serveur, après le drainage des tâches actives.

Quand utiliser un appareil Android réel

Choisissez le matériel pour caméra ou microphone réels, radio, biométrie, notifications système, batterie, température, particularité du fabricant, application native ou politique administrée.

Choisissez les profils pour mise en page, tactile, formulaires, consentement, navigation, région et régression dans le navigateur. Une simple simulation adaptative suffit au début de la conception si seule la largeur compte.

BotBrowser prend en charge des profils Android qui fournissent la saisie tactile, un viewport mobile défini par le profil, le ratio de pixels de l'appareil et l'orientation, ainsi qu'un mode optionnel --bot-mobile-keyboard qui réduit visualViewport.height lorsqu'un champ modifiable reçoit le focus par une action utilisateur de confiance. Pour votre équipe, cela donne une base mobile documentée à répéter dans les tests de formulaires, de consentement et de navigation, avec le changement d'espace visible lié au clavier comme condition explicite et étiquetée. BotBrowser ne remplace pas le matériel Android physique pour la caméra, la biométrie, la radio, la batterie, le passage vers une application native ou les boîtes de dialogue du système. Il ne garantit pas le comportement d'un vrai clavier à l'écran ni d'un lecteur d'écran, et il ne contrôle pas la logique adaptative de l'application ni ses résultats.

Trois façons d'exécuter un test mobile

La plupart des équipes finissent avec trois options sur la table, et le choix n'est pas une question de préférence. Chacune prouve un ensemble de faits différent, et une décision de version a besoin des faits pertinents pour l'exigence testée.

La couverture Android avec profil exécute un profil Android pris en charge sur un hôte de bureau ou serveur géré. La saisie tactile, le viewport mobile, le ratio de pixels de l'appareil, l'orientation, l'identité de plateforme et la condition du clavier mobile viennent de ce seul profil, donc la même condition se répète sur un poste de travail, un hôte de test partagé et un runner de CI. Elle prouve que le parcours côté navigateur fonctionne sous une condition mobile documentée et produit une preuve qu'une autre personne peut reproduire avec le même profil et la même compilation.

La fidélité d'entrée est là où l'écart est le plus net. Une exécution avec profil livre les événements de pointeur comme des toucher, prend en charge le nombre de points tactiles défini par le profil et peut réduire le viewport visuel lorsqu'un champ modifiable reçoit un focus de confiance. Elle envoie toutefois ces événements par une pile d'entrée de bureau, donc elle ne reproduit ni la latence, ni la pression, ni le contact accidentel de la paume d'un écran réel.

Le comportement du viewport est proche mais pas identique. Le profil fixe le viewport de mise en page et le ratio de pixels, donc les retours à la ligne, les en-têtes fixes et l'espacement des zones sûres se comportent comme sur la famille cible. Un appareil physique ajoute le chrome réel du navigateur, la barre d'état réelle et le clavier à l'écran réel, qui réduisent tous la zone visible de façons qu'aucune métrique simulée ne reproduit exactement.

La lecture multimédia est le domaine où les affirmations dépassent souvent les faits. Une exécution avec profil peut confirmer qu'un élément vidéo se charge, que les commandes sont atteignables, que les sous-titres s'affichent et que la page survit à une interruption. Elle ne peut pas confirmer le décodage matériel, le bridage thermique après une lecture prolongée, ni la prise en charge de codecs liée à la pile multimédia système de l'appareil. Ces propriétés relèvent d'un téléphone physique ou d'un laboratoire d'appareils.

Un appareil Android physique prouve toute la pile. Écran tactile réel, radio réelle, caméra et microphone réels, invite biométrique réelle, batterie et température réelles, boîtes de dialogue système réelles, passage réel vers une application native et la compilation du fabricant. C'est aussi l'option la plus lente à planifier, la plus difficile à reproduire exactement et la plus susceptible de rester inactive ou de vieillir.

Un navigateur de bureau en émulation mobile est l'option la moins chère. Il redimensionne le viewport de mise en page et active souvent l'émulation des événements tactiles, ce qui sert à une revue de conception précoce. Il ne peut pas donner à la page une identité de plateforme Android cohérente, donc les valeurs JavaScript, le user agent et les client hints se contredisent entre eux et avec le viewport. Il prouve la mise en page à une largeur, et guère plus.

Dimension	Couverture Android avec profil	Appareil Android physique	Navigateur de bureau en émulation mobile
Fidélité d'entrée	Type de pointeur tactile, points tactiles du profil, changement d'espace visible par clavier	Écran tactile réel avec latence et pression réelles	Événements de pointeur sauf activation manuelle de l'émulation tactile
Comportement du viewport	Viewport, DPR et orientation du profil, viewport de mise en page stable	Chrome réel, barre d'état et clavier à l'écran réduisent la zone visible	Seul le viewport de mise en page est redimensionné, sans chrome mobile
Lecture multimédia	Lecture au niveau de la page, commandes, sous-titres et gestion des interruptions	Décodage matériel, codecs et comportement thermique inclus	Lecture dans une pile multimédia de bureau, non représentative
Identité de plateforme	Plateforme, client hints et user agent cohérents dans un profil	L'appareil réel et la compilation du fabricant	Souvent contradictoire entre JavaScript et en-têtes
Ce que cela peut prouver	Un parcours navigateur reproductible sous une condition documentée	Comportement matériel, capteurs, système et natif	La mise en page à une largeur donnée
Ce que cela ne peut pas prouver	Caméra, radio, biométrie, batterie, passage natif, dialogues système	Rien sur l'échelle, le coût ou la répétabilité sur de nombreuses exécutions parallèles	Identité mobile, entrée, médias ou comportement des permissions
Reproductibilité	Élevée, même profil et même compilation sur tout hôte	Faible, liée à un téléphone et à son état	Moyenne, mais la condition n'est pas mobile
Coût par exécution parallèle	Faible, aucun téléphone par exécution	Élevé, chaque exécution exige un appareil planifié	Faible

Quand un parcours mobile doit passer au matériel physique

Appliquez une règle de décision avant d'écrire le cas : si la déclaration d'acceptation mentionne un capteur, un service système ou un comportement matériel, le contrôle relève d'un appareil physique et aucune exécution avec profil ne peut le satisfaire. Tout le reste peut commencer dans une base avec profil.

Déplacez le parcours vers le matériel dès que l'une de ces conditions est vraie :

• Le résultat dépend de la qualité de capture caméra ou micro, pas seulement de l'invite de permission.
• Le résultat dépend du comportement radio, du transfert de réseau ou du comportement hors ligne lié au modem de l'appareil.
• Le résultat dépend d'une invite biométrique ou d'un élément sécurisé.
• Le résultat dépend de la batterie, du bridage thermique ou d'une lecture prolongée.
• Le résultat dépend d'une boîte de dialogue du système ou d'un passage à une application native.
• Le résultat dépend de la compilation du fabricant ou d'un WebView embarqué fourni par l'appareil.
• L'équipe a besoin d'une certification lecteur d'écran ou clavier à l'écran avec une technologie d'assistance nommée.

Gardez le parcours dans la couverture avec profil quand la déclaration d'acceptation porte sur la page elle-même : mise en page, cibles tactiles, saisie de formulaire, chemins de consentement et de refus, commandes multimédias, navigation, présentation régionale et régression face à une base approuvée. Notez le motif d'escalade dans le cas pour qu'un relecteur ultérieur sache pourquoi le matériel était exigé plutôt que supposé.

Décider du déploiement

Avant d'intégrer des profils Android, confirmez autorisation, responsable, parcours, comptes, langues, capacité, conservation et escalade matérielle. Définissez qui examine les échecs et le délai d'un blocage.

Révisez la matrice après les changements importants et retirez les cas qui ne répondent plus à une exigence. Chaque cas restant conserve un responsable, un résultat attendu, une référence approuvée et une voie vers le matériel lorsque la décision dépend du système.

Questions courantes

Un profil Android peut-il tourner sur macOS, Linux ou Windows ?

Les profils pris en charge fonctionnent avec la version BotBrowser appropriée sur des hôtes administrés. Approuvez profil, navigateur et configuration comme une seule référence.

Les parcours autonome et intégré partagent-ils un cas ?

Non. Chacun possède son entrée, sa navigation, son résultat et ses preuves.

Comment tester le tactile ?

Terminez des tâches avec automatisation approuvée et revue manuelle. Vérifiez portée, défilement, focus, dialogues, gestes du produit et récupération.

Peut-on certifier caméra ou biométrie ?

Non. Les exigences liées aux capteurs ou services du système se confirment sur le matériel cible.

Comment séparer première visite et retour ?

Utilisez un état intentionnel pour chaque cas et étiquetez les preuves. Ne laissez pas permissions ou stockage passer entre tests.

Un grand catalogue est-il préférable ?

Pas forcément. Une sélection compacte liée à l'usage, au support et aux différences réelles est plus facile à maintenir.

Que doit contenir un rapport d'échec mobile ?

Indiquez la famille du profil, les versions, le parcours, la catégorie de compte, la langue, l'orientation, l'état, le résultat attendu, le comportement réel du produit et les preuves minimales expurgées.

Conclusion

La couverture Android devient utile lorsque la même condition approuvée accompagne le parcours du développement à la CI, à la livraison et au support. La cohérence maintient affichage, saisie, médias, région et plateforme dans cette condition pendant que l'équipe évalue le produit.

Téléchargez BotBrowser pour préparer un environnement mobile autorisé ou consultez les fonctions de cohérence avant le déploiement. Les profils multiplateformes traitent les hôtes.

Une observation reproductible du viewport visuel

La spécification W3C Visual Viewport permet de vérifier une limite : relevez window.innerHeight et visualViewport.height avant et après le focus d'un champ. La variation du second montre un changement de l'espace visible, pas la reproduction d'un clavier Android réel ou d'une fenêtre native.

Sources

• MDN : VisualViewport API
• MDN : Permissions API
• MDN : Media Capture and Streams API
• Android Developers : tester sur de vrais appareils
• W3C : Visual Viewport