Les gens bougent. Ils quittent le Wi-Fi de la maison, entrent dans un ascenseur, montent dans un train. Ton app doit survivre au changement de réseau pendant qu'une requête est en cours. Ce script est fait pour être remis à un testeur : chaque étape indique quoi faire, ce qui doit se passer et pourquoi.
Il complète tester le comportement hors connexion de ton app, qui couvre l'absence totale de réseau.
Avant de commencer
- Utilise un téléphone qui a à la fois le Wi-Fi et une connexion de données mobiles fonctionnelle.
- Connecte-toi d'abord, pour tester une vraie session.
- Note le modèle du téléphone, la version d'Android et la build de l'app.
Le script
- Du Wi-Fi aux données mobiles, au repos. Ouvre l'app en Wi-Fi, puis coupe le Wi-Fi. Attendu : l'app continue de fonctionner sur les données mobiles sans redémarrage. Pourquoi : les sockets liés à l'ancien réseau peuvent rester bloqués silencieusement.
- Des données mobiles au Wi-Fi, au repos. Fais l'inverse. Attendu : même chose. Pourquoi : certaines apps ne gèrent qu'un seul sens.
- Changement pendant un chargement. Ouvre une longue liste ou un écran qui récupère des données, et bascule le Wi-Fi au milieu du chargement. Attendu : soit le contenu se charge, soit tu vois un message d'erreur clair avec un bouton de nouvelle tentative. Pas un spinner sans fin.
- Changement pendant l'envoi d'un formulaire. Remplis un formulaire, appuie sur envoyer, change de réseau tout de suite. Attendu : un résultat clair. Vérifie ensuite côté serveur : pas d'enregistrement en double, pas de donnée perdue. Pourquoi : les nouvelles tentatives peuvent envoyer deux fois la même chose.
- Changement pendant un envoi ou un téléchargement. Utilise une photo ou un fichier. Attendu : l'envoi reprend ou échoue proprement avec une nouvelle tentative. Un fichier envoyé à moitié ne doit pas apparaître comme complet.
- Changement après une session longue. Reste plusieurs minutes dans l'app, bascule le réseau, attends. Attendu : la session tient. Pas de déconnexion inattendue. Pourquoi : un échec de rafraîchissement du jeton est souvent traité comme « déconnecté ».
- Mode avion activé puis désactivé. Active-le au milieu d'une tâche, puis désactive-le. Attendu : l'app voit le retour du réseau et reprend sans redémarrage.
- Signal faible. Va dans un endroit mal couvert, ou utilise une connexion bridée. Attendu : les délais d'attente se terminent par un message, pas par un écran figé.
- Passer en arrière-plan puis revenir. Change de réseau pendant que l'app est en arrière-plan, puis reviens. Attendu : les données se rafraîchissent ; aucun écran ancien ou cassé.
- Économiseur de données et connexion limitée. Si ton app synchronise beaucoup, active l'économiseur de données. Attendu : un comportement raisonnable, avec les gros téléchargements reportés ou demandant confirmation.
Quoi signaler
Pour chaque échec, demande au testeur d'écrire :
- le numéro de l'étape et ce qu'il a fait,
- ce qu'il a vu (une capture d'écran ou un enregistrement d'écran aide),
- l'heure à laquelle c'est arrivé,
- comment ça s'est terminé : récupéré tout seul, nouvelle tentative nécessaire, redémarrage nécessaire, données perdues.
Si tu peux, ajoute un journal. Voir les bases d'adb.
Conseils pour le développeur
- Les nouvelles tentatives doivent être limitées, avec une attente plus longue entre chaque essai.
- Rends les écritures sûres à répéter, pour qu'une nouvelle tentative ne crée pas de doublon.
- Montre à l'utilisateur que tu attends le réseau, au lieu d'afficher un écran vide.
Fait partie du guide de test des apps Android. Voir aussi : test du clavier et de la saisie et script de test TalkBack.
Tu veux qu'un testeur fasse ce test sur un vrai téléphone ? Commence gratuitement et demande un retour privé et structuré.