Configurer le lancement automatique des tests d'interface utilisateur des applications Android via TeamCity

Tôt ou tard, tout testeur développant la pratique de l'auto-test est confronté au problème de l'exécution autonome de ses tests. De plus, si le spécialiste est expérimenté, il essaie de résoudre ce problème le plus tôt possible. J'ai donc décidé, après la première exécution réussie de l'autotest localement, de configurer immédiatement le lancement dans TeamCity.

Je note que dans notre entreprise, il n'y a pratiquement aucune expertise sur le lancement à distance de tests instrumentaux Android, j'ai donc dû chercher dur sur Google, mais je n'y ai trouvé aucun guide détaillé non plus. Par conséquent, j'ai décidé d'entailler cette instruction.

A l'entrée nous avons:

  • test (s) exécuté avec succès localement
  • exécuter le serveur TeamCity
  • serveur sur debian avec KVM et X

La clause de non-responsabilité concernant le serveur sur lequel le lancement sera effectué: la configuration du système d'exploitation, la virtualisation matérielle et le shell graphique ne font pas l'objet de cet article et seront omis.

Installer et configurer l'agent TeamCity


Commençons par Java. L'essentiel ici est de choisir la bonne version. J'avais 3 dépendances: les tests eux-mêmes, les outils Android et l'agent Teamcity. Je me suis arrêté à la version 8 pour utiliser une JVM pour tout le monde. Si vous êtes moins chanceux et qu'il y aura des conflits, vous devrez configurer l'utilisation de plusieurs versions de Java sur la même machine. Une dernière remarque: si vous avez Debian, vous devez d'abord ajouter le référentiel webupd8team (Google est très rapide).

sudo apt-get install oracle-java8-installer sudo apt-get install oracle-java8-set-default 

Ensuite, créez un utilisateur sous lequel l'agent sera lancé et, par conséquent, tout le reste. N'oubliez pas de définir un mot de passe.

 sudo useradd -d /home/tc_agent -s /bin/bash -m tc_agent sudo passwd tc_agent 

La distribution des agents peut être effectuée dans l'interface Web de votre équipe. Pour ce faire, accédez à la section Agents et cliquez sur le lien Installer les agents de génération en haut à droite. Téléchargez et décompressez dans le dossier souhaité sur le serveur (je recommande le dossier de base de notre utilisateur - /home/tc_agent ). Ensuite, ajoutez les droits pour exécuter tous les scripts:

 sudo chmod +x /home/tc_agent/BuildAgent/bin/* 

Si votre version de teamcity prend en charge l'agent Push, c'est encore plus facile. Ouvrez simplement l'onglet correspondant dans l'interface Web, cliquez sur le bouton Installer l'agent ... et suivez les instructions.

Nous configurons une config. Si vous avez utilisé une installation à distance, celle-ci a déjà été créée et vous n'avez qu'à y spécifier le nom de l'agent. Sinon, créez:

 cd /home/tc_agent/BuildAgent/conf cp buildAgent.dist.properties buildAgent.properties nano buildAgent.properties 

serverUrl= adresse de l'interface web du serveur, et name= nom unique de l'agent. Si vous avez plusieurs agents ou que le port par défaut (9090) est occupé, définissez le vôtre à l'aide du paramètre ownPort= .

Nous /home/tc_agent/BuildAgent/bin/agent.sh start commande /home/tc_agent/BuildAgent/bin/agent.sh start . Si tout est correctement configuré, nous verrons notre agent dans l'onglet Non autorisé . Nous autorisons et vous pouvez utiliser.

Pour démarrer l'agent automatiquement, créez le script /etc/init.d/teamcity_agent avec le contenu suivant:

 #!/bin/bash BINARY="/home/tc_agent/BuildAgent/bin/agent.sh" RUNAS="tc_agent" LOGFILE="/home/tc_agent/BuildAgent/logs/start.log" CMD="$BINARY $1 $2" runuser - "$RUNAS" -c "$CMD > $LOGFILE" cat $LOGFILE 

Ajoutez les droits pour exécuter sudo chmod +x /etc/init.d/teamcity_agent et ajoutez la ligne /etc/init.d/teamcity_agent start au fichier /etc/rc.local .

Contrôlez le redémarrage, l'agent a augmenté, nous allons de l'avant.

Installer le SDK Android et l'émulateur


Téléchargez les outils Android SDK ( outils de ligne de commande uniquement) et décompressez-le dans le répertoire souhaité. Créez un répertoire pour stocker les futures images AVD (il devrait y avoir suffisamment d'espace). Pour moi, les administrateurs ont connecté le référentiel principal au répertoire /var, et je vais tout y mettre. Ensuite, nous changeons le propriétaire des fichiers en notre utilisateur et les prochaines étapes sont mieux effectuées sous lui.

 sudo chown tc_agent -R /var/opt/android-sdk sudo mkdir /var/opt/.android sudo chown tc_agent /var/opt/.android 

Ajoutez des variables d'environnement. Ouvrez le fichier /home/tc_agent/.bash_profile pour le modifier et l'écrire:

 export ANDROID_HOME=/var/opt/android-sdk export ANDROID_AVD_HOME=/var/opt/.android/avd export PATH=$ANDROID_HOME/platform-tools:$PATH export PATH=$ANDROID_HOME/tools:$PATH 

Nous redémarrons et vérifions que les variables sont correctement affichées dans l'interface Web teamcity sur l'onglet Paramètres de l' agent .

Nous essayons d'exécuter sdkmanager: la commande $ANDROID_HOME/tools/bin/sdkmanager --list doit lister les packages installés et disponibles. Si vous obtenez une erreur comme Exception in thread "main" java.lang.NoClassDefFoundError , essayez cette solution .

Installez les outils nécessaires et la ou les images des machines virtuelles.

 $ANDROID_HOME/tools/bin/sdkmanager emulator platform-tools tools $ANDROID_HOME/tools/bin/sdkmanager 'system-images;android-25;google_apis;x86' 

Créer et exécuter AVD


Nous avons donc téléchargé l'image de 'system-images;android-25;google_apis;x86' (Android 7.1.1), créez un appareil virtuel basé sur celui-ci. Je n'entrerai pas dans les détails de tous les paramètres possibles de l'utilitaire avdmanager, je le montrerai sur le montant minimum possible:

 $ANDROID_HOME/tools/bin/avdmanager create avd -n avd_name -k "system-images;android-25;google_apis;x86" 

Nous transférons le nom et l'image d'origine (elle doit être téléchargée à l'avance via sdkmanager). Si l'erreur est revenue, ajoutez l'indicateur -v pour afficher le texte.

Nous passons à l'émulateur. Tout d'abord, recherchez l'émulateur, les plates-formes, les outils de plate-forme, les dossiers d'images système dans le répertoire SDK. J'ai créé des plateformes avec mes mains, le reste a été créé lors de l'installation de packages via sdkmanager. Ensuite, vérifiez l'accélération matérielle. Il devrait y avoir une telle réponse.

 $ANDROID_HOME/emulator/emulator -accel-check accel: 0 KVM (version 12) is installed and usable. accel 

S'il y a une erreur lors de l'accès à /dev/kvm , ajoutez les droits:

 addgroup kvm usermod -a -G kvm tc_agent chown root:kvm /dev/kvm 

De plus, j'avais encore besoin d'installer QEMU: sudo apt-get install qemu-kvm
Relogon et vérifiez à nouveau l'émulateur.

Si tout va bien, essayez de courir. Pour voir à travers les yeux, connectez-vous au serveur via vnc. Et lancez l'émulateur:

 $ANDROID_HOME/emulator/emulator @avd_name 

La fenêtre suivante devrait apparaître:


Pendant les tests, nous exécuterons sans graphiques, nous ajouterons donc le paramètre -no-window .

Configurer la construction dans TeamCity


Nous passons à l'étape finale - mise en place d'un lancement autonome de nos tests. J'ai obtenu un build de 4 étapes.

1. Démarrage de l'émulateur

 nohup /var/opt/android-sdk/emulator/emulator @avd_name -no-snapshot-save -no-boot-anim -no-window -snapshot clean_snap_1 > start_emulator.log 2>&1& 

Étant donné que l'émulateur «verrouille» le terminal, vous devez délier le processus à l'aide de l'utilitaire nohup (vous pouvez également le faire dans l'autre sens). Au cas où, enregistrez le journal de l'émulateur dans le fichier start_emulator.log . Pour exécuter les tests, j'ai créé un instantané propre (voir ici comment faire) et ajouté le commutateur -no-snapshot-save pour qu'il ne soit pas écrasé.

2. En attente de démarrage de l'appareil.

 adb wait-for-device shell 'while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;' 

D'abord, nous attendons l'état d' wait-for-device , puis dans la boucle, nous attendons lorsque la variable sys.boot_completed renvoie 1.

3. Exécution de tests. Tout est individuel ici, voici mon exemple:

 ./gradlew clean connectedAndroidTest 

4. Fermez l'émulateur. Ici jusqu'à présent, j'ai fait une simple fin du processus.

 kill -s 2 `pgrep qemu-system` 

Mais il vaut mieux, bien sûr, se souvenir de l'ID de processus lors de la création de l'émulateur. Cela sera nécessaire lorsque nous commencerons à exécuter les tests dans plusieurs threads, ce qui ne «tue» pas accidentellement le mauvais processus.

C'est tout, merci d'avoir lu. S'il y a des commentaires de collègues plus expérimentés, je serai heureux d'apporter des modifications au manuel.

Source: https://habr.com/ru/post/fr415769/


All Articles