Comment reproduire des bugs Android sur plusieurs téléphones réels

Un flux de travail de support pratique pour transformer une plainte Android spécifique à un appareil en un cas reproductible, un paquet d'éléments de preuve et un transfert d'ingénierie utile.

Pourquoi les équipes de support gardent-elles plus d'un téléphone Android ?

Un client peut décrire un dysfonctionnement de manière précise et laisser le support incapable de le reproduire. La version de l'application peut être correcte, mais le problème ne se produit que sur une seule version de fabrication, version Android, taille de l'écran, état des permissions, langue, réseau ou politique de batterie. Un seul téléphone de référence ne peut pas représenter cette plage. C'est pourquoi les équipes de support mobile gardent souvent un petit ensemble de vrais téléphones Android même lorsque l'ingénierie utilise déjà des émulateurs et des tests automatisés.

L'objectif n'est pas d'avoir tous les modèles. Il s'agit de maintenir une couverture suffisante pour répondre rapidement à trois questions : peut-il l'équipe reproduire le rapport, quelle condition l'active et quelles preuves permettront à l'ingénierie de continuer sans répéter toute la conversation de support ? AWS Device Farm identifie également les représentants du support clientèle aux côtés des développeurs et des équipes de QA, et décrit l'interaction réelle avec les appareils comme un moyen de déboguer et de reproduire les problèmes des clients.

• Authentification, paiement, notification, autorisation, caméra, Bluetooth et pannes de processus en arrière-plan.
• Les mises en page qui se cassent sur une densité d'écran particulière, une échelle de police, une langue ou un mode de navigation particulier.
• Problèmes de mise à niveau ou d'installation liés à une version Android ou au micrologiciel du fabricant.
• Problèmes qui apparaissent uniquement après un changement de réseau, un arrière-plan d'application, une restriction de batterie ou une interruption.
• Les rapports des clients qui nécessitent une capture d'écran, une courte enregistrement, les détails de l'appareil et les étapes exactes de reproduction avant l'escalade.

Collectez les données minimales de la coque avant de choisir un téléphone.

Ne commencez pas par cliquer sur des téléphones aléatoires. Convertissez d'abord la conversation d'assistance en un cas testable. La perte de données d'entrée perd plus de temps que la configuration du dispositif physique parce que l'équipe ne peut pas distinguer un défaut spécifique au dispositif d'un problème de compte, de version, de réseau ou de données obsolètes.

Si un client ne peut pas fournir tout ce qui est nécessaire, enregistrez ce qui est inconnu au lieu de combler silencieusement les lacunes. Le support peut toujours tester le chemin connu, mais l'ingénierie devrait être en mesure de voir quelles hypothèses ont été faites. Ne demandez jamais aux clients d'envoyer des mots de passe, des détails de paiement, des documents d'identité, des messages privés ou des fichiers personnels non liés.

Construisez une petite matrice de dispositifs à partir des preuves fournies par le client.

Un service d'assistance utile est basé sur les appareils que vos clients utilisent réellement, et non sur une étagère de téléphones phares attrayants. Commencez par les analyses, les rapports de crash, le volume des tickets et les segments critiques pour les revenus. Sélectionnez un appareil de bas de gamme, un modèle de milieu de gamme courant, un téléphone phare récent et tout fabricant ou version Android qui apparaît à plusieurs reprises dans les cas non résolus.

1. Exportez les meilleurs modèles de appareils et les versions Android à partir de données de produits fiables.
2. Groupez les appareils similaires par micrologiciel du fabricant, niveau de performance, caractéristiques de l'écran et génération du système d'exploitation.
3. Choisissez le plus petit ensemble physique qui couvre la plus grande part des cas importants.
4. Ajoutez un modèle uniquement lorsque les billets ou le risque du produit justifient le coût de sa maintenance.
5. Examinez la matrice trimestrielle et retirez les appareils qui ne représentent plus un trafic ou un risque significatifs.

Un bureau de trois à six téléphones est souvent plus utile qu'une grande collection non entretenue. Des tests de compatibilité plus larges peuvent toujours être effectués sur un service cloud. Le bureau local existe pour une reproduction interactive rapide, des démonstrations de support et des cas où les mêmes appareils sont utilisés à plusieurs reprises. Pour l'installation physique, voir leGuide de laboratoire pour appareils Android à faible coût.

Organiser le bureau de support multi-téléphones

Chaque téléphone a besoin d'une identité stable. Donnez-lui un court code, étiquettez-le physiquement et enregistrez son modèle, sa version Android, la date de dernière réinitialisation, l'état de la batterie, la méthode de connexion, la version de test installée et les comptes de test attribués. Utilisez des câbles fiables et des hubs USB alimentés lorsque plusieurs téléphones partagent un ordinateur ; une alimentation instable et des câbles endommagés peuvent créer des pannes qui ressemblent à des défauts d'application.

Contrôlez plusieurs téléphones AndroidÀ partir d'un espace de travail commun lorsque l'équipe doit comparer des écrans, passer d'un appareil à un autre ou répéter une étape de configuration autorisée. dansLaiCai Screen MirroringLes appareils peuvent être visibles depuis une seule station de travail Windows ou macOS, ce qui permet à l'opérateur de passer moins de temps à répondre aux appels téléphoniques et plus de temps à comparer l'état du boîtier. Le regroupement est utile pour séparer les lignes de base propres, les cas de support actifs, les appareils de bas de gamme et les téléphones en attente de réinitialisation.

• Gardez un appareil de base connu comme bon pour la comparaison.
• Utilisez des comptes de test dédiés avec des données synthétiques lorsque c'est possible.
• Réinitialiser les données de l'application entre les cas lorsque l'état précédent pourrait modifier le résultat.
• Gardez le code du téléphone visible dans chaque capture d'écran ou note de cas.
• Enregistrez la charge, le USB, le Wi-Fi et les conditions thermiques lorsqu'ils affectent le test.

Effectuez un passage de reproduction contrôlée

Le chemin le plus rapide vers un résultat utile est généralement une comparaison contrôlée, et non un grand nombre d'actions simultanées. Commencez sur l'appareil qui correspond le mieux et reproduisez l'état initial du client. Effectuez les étapes signalées une fois sans rien changer. Si le problème apparaît, répétez-le pour confirmer la fréquence. Si ce n'est pas le cas, modifiez une variable à la fois : réseau, autorisation, langue, données de l'application, version Android, fabricant, échelle de police ou politique de batterie.

1. Créez la carte de cas avec le code de téléphone, la construction de l'application, le type de compte, le réseau, la langue et l'écran de démarrage.
2. Reproduisez les étapes exactes du client sur le téléphone correspondant le plus proche.
3. Répétez le même chemin sur le téléphone de référence en bon état connu.
4. Changez seulement une condition suspecte et exécutez à nouveau le chemin.
5. Arrêtez lorsque le déclencheur est isolé ou que la limite d'essais convenue est atteinte.
6. Écrivez les tentatives réussies et infructueuses ; les preuves négatives réduisent la portée de l'enquête suivante.

Ne pas utiliser l'entrée synchronisée lorsque les appareils ont déjà divergé. Une boîte de dialogue de permission, un chargement lent, un clavier ou un message d'actualisation peuvent envoyer le même clic vers des contrôles différents. Les actions partagées ne sont utiles que lorsque chaque téléphone sélectionné est visiblement dans le même état sûr. Sinon, opérez les appareils individuellement et préservez la différence que vous essayez de comprendre.

Créez un paquet de preuves que l'ingénierie peut reproduire.

Un transfert d'information utile est suffisamment petit pour être examiné rapidement et suffisamment complet pour être reproduit. Un ticket doit relier l'environnement, les étapes, le résultat observé, le résultat attendu et les preuves justificatives. Les captures d'écran prouvent un état statique ; une courte enregistrement d'écran prouve le temps et la séquence ; les journaux expliquent ce que l'interface ne peut pas montrer. Aucun de ces éléments ne remplace les autres.

Nommez les fichiers avec l'ID du ticket, le code du téléphone, la version et l'horodatage. Le transfert devrait permettre à un ingénieur de comprendre l'échec en quelques minutes sans ouvrir plusieurs fils de discussion. Pour un flux de travail QA plus large, voirMise en miroir de l'écran Android pour le test des applications mobiles..

Choisissez des téléphones locaux, des émulateurs ou un service de dispositif en nuage.

Ces outils résolvent différents problèmes de couverture. Un poste téléphonique local ne remplace pas une ferme de dispositifs en nuage, et un laboratoire en nuage ne supprime pas la valeur des téléphones familiers à côté de l'équipe de support. Sélectionnez l'environnement le moins coûteux qui peut reproduire fidèlement la condition.

Une séquence pratique est l'émulateur en premier pour un contrôle rapide de la santé, les téléphones locaux pour des causes vraies du dispositif, et les appareils en nuage lorsque le modèle est manquant ou que le boîtier nécessite une confirmation plus large.Mise en miroir de l'écran Android sur un PC ou un Macest le plus utile lorsque le support a besoin d'un contrôle visuel direct sur les téléphones locaux plutôt que de gérer les politiques sur une flotte d'entreprise distribuée.

Protéger les données des clients pendant la reproduction

Le dépannage des appareils réels peut exposer des informations personnelles si le processus est négligent. Utilisez par défaut des comptes synthétiques et des données de test. Si des données de production sont réellement nécessaires, obtenez la bonne autorisation, restreignez l'accès, capturez uniquement ce dont le cas a besoin et suivez la politique de rétention de l'entreprise. AWS met également en garde les utilisateurs de son service d'appareils contre la saisie des informations de connexion, des informations personnelles ou d'autres détails sensibles à la sécurité, car les sessions peuvent produire des journaux et des vidéos.

• Ne copiez jamais le mot de passe, les informations de paiement, le jeton d'authentification, les photos privées ou les documents d'identité d'un client dans un téléphone de laboratoire.
• Flouez ou recadrez les noms, les messages, les adresses e-mail et les numéros de compte non liés avant d'attacher des preuves.
• Gardez les comptes de test séparés par environnement et faites tourner les identifiants en fonction de la politique de l'entreprise.
• Supprimez les captures d'écran, les enregistrements, les journaux, les fichiers téléchargés et les données de l'application lorsque la période de rétention prend fin.
• Notez qui a accédé à un cas sensible et pourquoi lorsque la politique exige une trace d'audit.

Piloter le flux de travail avec trois téléphones

Ne commencez pas par acheter un mur de téléphones. Choisissez une catégorie récurrente de cas de support et trois appareils représentatifs : une base de données connue pour être en bon état, le téléphone le plus courant des clients et un téléphone bas de gamme contrastant ou spécifique au fabricant. Exécutez le flux de travail pendant deux semaines, puis décidez si un autre appareil ou un service cloud résoudrait les cas que le pilote ne pouvait pas couvrir.

1. Sélectionnez dix billets récents qui ont été retardés en raison de l'incertitude du dispositif.
2. Définissez les champs d'entrée requis et un seul modèle de paquet d'éléments probants.
3. Étiquetez et préparez trois téléphones avec des comptes de test propres.
4. Suivre le temps nécessaire à la première reproduction significative, les boucles de clarification, l'acceptation de l'escalade et les lacunes non résolues dans l'appareil.
5. Examinez quel téléphone ou quelle condition environnementale a réellement changé le résultat.
6. Élargissez uniquement lorsque les preuves montrent une lacune de couverture répétée.

Le résultat à vérifier est simple : un ingénieur de support devrait être capable de recevoir un cas, de sélectionner un téléphone approprié, de reproduire le chemin et de livrer un transfert autonome sans rechercher plusieurs systèmes non liés. Si un espace de travail local partagé aide ce pilote,LaiCai Screen MirroringPeut garder les téléphones Android sélectionnés visibles et contrôlables depuis un ordinateur Windows ou macOS.

Questions fréquemment posées

Combien de téléphones Android a besoin une équipe de support ?

Commencez par trois à six téléphones choisis parmi les données réelles de billets et d'utilisation. Ajoutez des appareils uniquement lorsque des cas répétés et importants ne peuvent pas être couverts par la matrice actuelle ou par une session cloud occasionnelle.

Devrait-il être possible de reproduire chaque rapport client ?

Non. Priorisez la gravité, les utilisateurs concernés, l'impact sur l'entreprise, le risque de sécurité, la récidive et si la reproduction changera la prochaine action. Un laboratoire de dispositifs est un outil de décision, pas un devoir de relire chaque plainte vague.

Le contrôle synchronisé peut-il reproduire un bug sur tous les téléphones en même temps ?

Seulement lorsque les appareils sont visiblement dans le même état et que l'action est sûre. Une fois que le temps, les dialogues, les autorisations, les claviers ou les mises en page diffèrent, opérez les téléphones individuellement. La divergence est une preuve, pas quelque chose à cliquer aveuglément.

LaiCai remplace-t-il une plateforme de gestion des appareils mobiles ?

Non.LaiCai Screen Mirroringest un outil de contrôle visuel et de flux de travail local. Les flotteurs d'entreprise distribués qui ont besoin d'une inscription sans contact, d'une application de mise en œuvre de politiques, de distribution d'applications, d'inventaire ou de nettoyage à distance doivent utiliser un système MDM ou EMM approprié.

Sources

• FAQ sur AWS Device Farm
• Guide du développeur AWS Device Farm
• Laboratoire de test fonctionnel OpenText pour les mobiles et le web
• Laboratoire de test à distance Samsung
• Guide de support Google Android Enterprise