Guide#tests#qa#multi-appareils
Tester une appli Android sur plusieurs appareils en parallèle, sans labo hors de prix
Tailles d'écran, versions d'Android, constructeurs : comment monter un petit banc de test multi-appareils sur ton PC et faire tourner le même parcours sur tous les téléphones à la fois.

Ton appli marche parfaitement sur ton téléphone. Puis un utilisateur t'envoie une capture : le bouton de paiement est coupé en deux sur un petit écran, ou l'appli plante au lancement sur une ancienne version d'Android. Tu ne l'avais pas vu parce que tu ne testes que sur un appareil.
Android, c'est des milliers de combinaisons de tailles d'écran, de densités, de versions et de surcouches constructeur. Impossible de tout couvrir. Mais tester sur une poignée d'appareils bien choisis, en parallèle, attrape déjà la grande majorité des problèmes visibles. Voici comment monter ce banc de test sur ton PC.
Pourquoi tester en parallèle plutôt qu'à la suite
Tester sur cinq téléphones l'un après l'autre, c'est cinq fois le même parcours, cinq fois la même attente, et la tentation de « sauter » un appareil quand on est pressé. En parallèle :
- le même parcours tourne en même temps sur tous les appareils ;
- les différences sautent aux yeux, parce que les écrans sont côte à côte ;
- un parcours automatisé se relance à chaque version sans effort.
Choisir ses appareils de test
Pas besoin d'un labo. Quelques appareils qui couvrent des extrêmes valent mieux que dix téléphones semblables :
- un petit écran (ou un écran à faible densité) pour les mises en page qui débordent ;
- un grand écran ou une tablette pour les mises en page étirées ;
- une version ancienne d'Android encore utilisée par ton public, pour les API manquantes ;
- la version la plus récente, pour les changements de comportement et de permissions ;
- au moins deux constructeurs différents, car les surcouches modifient polices, gestes et gestion de la batterie.
LDPlayer (géré explicitement par AppsMobs) peut compléter ce parc pour les configurations que tu n'as pas sous la main. Ils ne remplacent pas complètement un vrai appareil (capteurs, performances, comportement réel de la batterie), mais ils élargissent la couverture à moindre coût.
Monter le banc de test sur ton PC
1. Connecter tous les appareils
Active le débogage USB sur chaque appareil et branche-les au PC (ou démarre LDPlayer pour un émulateur). Dans AppsMobs, ils apparaissent tous en miniatures en direct sur le Tableau de bord. Android 7 à 15 sont pris en charge, ainsi que LDPlayer ; les autres émulateurs passent par ADB, sans garantie. La doc de connexion donne le détail.
2. Installer la version à tester partout
Une ligne install_app("app-debug.apk") au début de ton script installe l'APK sur chaque appareil sur lequel il tourne. Plus besoin de répéter la même commande pour chaque téléphone.
3. Écrire le parcours une fois
Un parcours de test, c'est une suite d'étapes : lancer l'appli, passer l'écran d'accueil, se connecter avec un compte de test, ouvrir tel écran, remplir tel formulaire, vérifier qu'un élément est bien affiché. Tu peux l'écrire :
- en Python, avec la bibliothèque d'AppsMobs (plus de 80 fonctions documentées pour les taps, la saisie, les attentes, les captures ; voir les scripts Python) ;
- en blocs, si ton équipe compte des testeurs qui ne codent pas : les blocs exposent les mêmes fonctions.
L'historique des versions de chaque script permet de revenir à un parcours qui marchait.
4. Lancer sur tous les appareils à la fois
Tu sélectionnes les appareils et tu lances. Chaque appareil exécute le parcours de son côté, et tu vois tous les écrans bouger ensemble.
5. Lire les résultats
Chaque exécution écrit son journal dans la Console, appareil par appareil. Ajoute un screenshot() à chaque étape clé : quand un test échoue sur un seul appareil, tu as directement l'écran fautif sous les yeux au lieu de devoir reproduire le problème.
Vérifier ce qui est à l'écran
Un test qui se contente de taper au bon endroit ne vérifie rien. Il faut aussi s'assurer que ce qui doit apparaître apparaît. Trois approches complémentaires :
- le texte à l'écran, avec
text_visible("Payer")ouwait_text("Commande confirmée", timeout=20), pour tout ce qui s'affiche en toutes lettres ; - la correspondance de modèle (template matching), pour un élément qui ne change jamais : un logo, une icône fixe ;
- la Vision IA, pour des éléments qui changent de place ou d'aspect selon l'écran. Tu entraînes un modèle de détection sur des captures de ton appli, et ton test peut demander « le bouton de paiement est-il visible ? » plutôt que « le pixel en (540, 1820) est-il vert ? ». C'est précisément ce qui rend un test robuste sur des écrans de tailles différentes.
Un point d'honnêteté : un modèle entraîné sur une vingtaine de captures d'un seul appareil ne généralisera pas forcément à un format d'écran très différent. Ajoute des captures de chaque type d'écran de ton banc.
Faire tourner les tests tout seuls
Le planificateur lance tes parcours à intervalle régulier ou la nuit, sur « n'importe quel appareil libre » plutôt que sur des numéros de série figés. Sur plusieurs appareils, il les traite l'un après l'autre, et un script lancé par une tâche est coupé au bout de 5 minutes. La relance auto du Tableau de bord redémarre un script qui plante (3 fois maximum en 10 minutes), et une tâche qui échoue 3 fois d'affilée s'arrête et apparaît dans « À vérifier ».
C'est un banc de test qui tourne sur ton PC : il a besoin qu'AppsMobs soit ouvert sur la machine hôte. Ce n'est pas un service d'intégration continue hébergé.
Ce qu'un banc de test local fait bien (et moins bien)
Il fait bien :
- tester sur de vrais appareils, avec leurs vraies surcouches ;
- comparer visuellement les écrans côte à côte ;
- garder tout en local : APK, comptes de test, captures ;
- coûter le prix d'une poignée de téléphones et d'un abonnement, pas celui d'un labo.
Il fait moins bien :
- couvrir des centaines de modèles : pour ça, les fermes d'appareils en ligne restent utiles ;
- tourner quand le PC est éteint.
Pour démarrer
Commence petit : deux ou trois appareils aux extrêmes de ton public, un seul parcours critique (l'inscription ou le paiement, par exemple). Une fois qu'il tourne de façon fiable, ajoute des appareils et des parcours.
Les formules vont de 1 à 10 appareils. Le tour du produit détaille les modules et leurs limites, et tu peux télécharger AppsMobs pour brancher ton premier appareil de test.


