Aperçu

Les tests mobiles reposent sur le même modèle que le web. Un cas de test est une liste d'étapes, chacune étant un résultat attendu formulé en langage courant, comme « Un nouveau compte existe pour une adresse e-mail inédite ». Sur Android, l'agent atteint chaque résultat attendu dans un émulateur qui exécute votre application : il touche, balaie, saisit et lit l'écran, et chaque action apparaît sous l'étape dans les Step Actions. Chaque étape se termine par une Final check, et l'exécution se conclut en Passed, Failed, Couldn't start ou Cancelled.

Les tests Android s'exécutent sur des émulateurs Android hébergés sur les runners d'Autonomy. Une exécution attend dans la file jusqu'à ce qu'un runner disposant d'un émulateur libre la prenne en charge. Si aucun ne se libère à temps, l'exécution se termine avec le résultat Couldn't start et le message « Aucun runner n'était disponible à temps pour démarrer cette exécution. », et elle n'est pas facturée. Un émulateur qui ne démarre pas termine l'exécution avec « Aucun appareil de test n'était disponible, l'exécution n'a donc pas pu démarrer. »

Lorsque vous enregistrez, l'assistant affiche Emulator online quand un émulateur est libre, et No emulator online quand aucun ne l'est, avec « Aucun runner n'a d'émulateur Android libre pour le moment. Rédigez ou décrivez les étapes, ou réessayez dans quelques minutes. »

D'où vient l'application

Le build de l'application se trouve dans un environnement. Un environnement a une cible par plateforme :

Les exécutions utilisent le build enregistré sur l'environnement. Pour tester un nouveau build, téléversez-le ou enregistrez à nouveau le lien de téléchargement dans l'environnement. Les téléversements passent un contrôle de sécurité avant qu'une exécution puisse les utiliser. Un projet teste toutes les plateformes pour lesquelles ses environnements ont des cibles, et le même cas de test s'exécute sur le web et Android quand son projet a des cibles pour ces plateformes.

iOS nécessitera un build pour simulateur : un .ipa pour appareil physique ne peut pas s'exécuter sur un simulateur. Voir Builds mobiles pour les commandes de build.

Comment envoyer un build

• Tableau de bord : ouvrez Environments dans le projet, modifiez l'environnement, puis, sous la cible Android, choisissez Upload pour déposer un fichier, ou URL pour un lien de téléchargement.
• CI : téléversez le build depuis votre pipeline et lancez des exécutions avec lui. Voir Builds mobiles et les recettes pour GitHub Actions, GitLab CI, Jenkins, Bitrise et CircleCI.
• Expo EAS : exécutez les tests à la fin d'un build EAS. Voir Expo EAS.

Rédiger des cas de test mobiles

Rédigez les étapes comme des résultats attendus, comme pour le web. Ne décrivez ni les touchers ni les coordonnées à l'écran : l'agent trouve lui-même son chemin vers chaque résultat attendu sur l'appareil. Les pièces jointes comme les comptes, les boîtes de réception et les données de test fonctionnent de la même façon. Voir Cas de test.

• Connexions : sur Android, les connexions utilisent des identifiants. Les sessions de navigateur enregistrées ne fonctionnent que sur le web. Voir Connexions.
• Enregistrement : Record it once fonctionne aussi sur Android : il démarre un émulateur hébergé, installe et ouvre le build de votre environnement, et le diffuse dans votre onglet. L'enregistrement sur iOS suivra quand les tests iOS seront disponibles. Voir Enregistrer sur Android.

Ce que montre une exécution mobile

Une exécution mobile a la même page d'exécution que sur le web : le résultat de chaque étape, ses Step Actions et sa Final check, ainsi que Replay, Screenshots et Logs dans le panneau des preuves. Voir Exécutions et résultats.

Limites

• Android s'exécute sur des émulateurs. L'appareil photo, le NFC, l'empreinte digitale et tout ce qui nécessite un build signé pour appareil physique ne fonctionnent pas.
• Les sessions de navigateur enregistrées avec l'extension Chrome ne peuvent pas être utilisées sur mobile.