Considérations relatives aux tests de l’interface utilisateur

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Lorsque vous exécutez des tests automatisés dans le pipeline CI/CD, vous pouvez avoir besoin d’une configuration spéciale afin d’exécuter des tests d’interface utilisateur tels que des tests Selenium, des tests Appium ou des tests codés de l’interface utilisateur. Cet article décrit les considérations classiques relatives à l’exécution de tests d’interface utilisateur.

Prérequis

Familiarisez-vous avec les agents et déployez un agent sur Windows.

Mode sans interface utilisateur ou mode interface utilisateur visible ?

Lors de l’exécution de tests Selenium pour une application web, vous pouvez lancer le navigateur de deux façons :

  1. Mode sans interface utilisateur. Dans ce mode, le navigateur s’exécute normalement, mais sans aucun composant d’interface utilisateur visible. Si ce mode n'est pas utile pour naviguer sur le web, il l'est en revanche pour exécuter des tests automatisés en mode sans assistance dans le cadre d'un pipeline CI/CD. Les navigateurs Chrome et Firefox peuvent être exécutés en mode sans interface utilisateur.

    Ce mode consomme généralement moins de ressources sur l’ordinateur, car l’interface utilisateur n’est pas affichée et les tests s’exécutent plus rapidement. Par conséquent, d’autres tests peuvent être exécutés en parallèle sur la même machine pour réduire le temps total d’exécution des tests.

    Les captures d’écran peuvent être réalisées dans ce mode et utilisées pour la résolution des défaillances.

    Notes

    Actuellement, le navigateur Microsoft Edge ne peut pas être exécuté en mode sans interface utilisateur.

  2. Mode Interface utilisateur visible. Dans ce mode, le navigateur s’exécute normalement et les composants de l’interface utilisateur sont visibles. Lors de l’exécution de tests dans ce mode sur Windows, une configuration spéciale des agents est requise.

Si vous exécutez des tests d'interface utilisateur pour une application de bureau, tels que les tests Appium utilisant WinAppDriver ou les tests codés de l’interface utilisateur, une configuration spéciale des agents est nécessaire.

Conseil

Les tests d'interface utilisateur de bout en bout ont généralement tendance à durer longtemps. Lorsque vous utilisez le mode d'interface utilisateur visible, il se peut, selon l’infrastructure de test, que vous ne puissiez pas exécuter les tests en parallèle sur la même machine, car l'application doit être au centre de l'attention pour recevoir les événements du clavier et de la souris. Dans ce scénario, vous pouvez accélérer les cycles de test en exécutant des tests en parallèle sur différents ordinateurs. Consultez exécuter des tests en parallèle pour n’importe quel exécuteur de test et exécuter des tests en parallèle à l’aide de la tâche de test Visual Studio.

Test de l’interface utilisateur en mode interface utilisateur visible

Une configuration spéciale est requise pour que les agents exécutent des tests d’interface utilisateur en mode interface utilisateur visible.

Test de l'interface utilisateur visible en utilisant des agents hébergés par Microsoft

Les tests visibles de l’interface utilisateur ne sont pas pris en charge dans les agents hébergés par Microsoft. Le test échoue avec le message d’erreur « élément non interagissant ». Les agents hébergés par Microsoft prennent en charge les tests de navigateur sans tête.

Test de l’interface utilisateur en mode principal à l’aide d’agents hébergés par Microsoft

Les agents hébergés par Microsoft sont préconfigurés pour les tests d’interface utilisateur et les tests d’interface utilisateur pour les applications web. Les agents hébergés par Microsoft sont également préconfigurés avec des navigateurs populaires et des versions de pilotes web correspondantes qui peuvent être utilisées pour exécuter des tests Selenium. Les navigateurs et les pilotes web correspondants sont mis à jour périodiquement. Pour en savoir plus sur l’exécution de tests Selenium, consultez test de l’interface utilisateur avec Selenium.

Tests de l'interface utilisateur visible à l'aide d'agents Windows auto-hébergés

Les agents configurés pour s’exécuter en tant que service peuvent exécuter des tests Selenium uniquement avec des navigateurs sans interface utilisateur. Si vous n’utilisez pas de navigateur sans interface utilisateur ou si vous exécutez des tests d’interface utilisateur pour les applications de bureau, les agents Windows doivent être configurés pour s’exécuter en tant que processus interactif avec ouverture de session automatique activée.

Lors de la configuration des agents, sélectionnez « Non » quand vous êtes invité à exécuter en tant que service. Les étapes suivantes vous permettent ensuite de configurer l’agent avec l’ouverture de session automatique. Lorsque vos tests d’interface utilisateur s’exécutent, les applications et les navigateurs sont lancés dans le contexte de l’utilisateur spécifié dans les paramètres d’ouverture de session automatique.

Si vous utilisez le Bureau à distance pour accéder à l’ordinateur sur lequel un agent s’exécute avec l’ouverture de session automatique, le simple fait de déconnecter le Bureau à distance entraîne le verrouillage de l’ordinateur et l’échec éventuel de tous les tests de l’interface utilisateur qui s’exécutent sur cet agent. Pour éviter cela, utilisez la commande tscon sur l’ordinateur distant pour vous déconnecter du Bureau à distance. Par exemple :

%windir%\System32\tscon.exe 1 /dest:console

Dans cet exemple, le nombre « 1 » est l’ID de la session Bureau à distance. Ce nombre peut changer d’une session à distance à l’autre, mais il peut être consulté dans le Gestionnaire des tâches. Vous pouvez également automatiser la recherche de l'identifiant de la session en cours en créant un fichier de commandes contenant le code suivant :

for /f "skip=1 tokens=3" %%s in ('query user %USERNAME%') do (
  %windir%\System32\tscon.exe %%s /dest:console
)

Enregistrez le fichier de commandes et créez un raccourci sur le bureau, puis modifiez les propriétés du raccourci en « Exécuter en tant qu'administrateur ». L'exécution du fichier batch à partir de ce raccourci permet de se déconnecter du bureau distant, mais préserve la session de l'interface utilisateur et permet l'exécution des tests de l'interface utilisateur.

Agents d’approvisionnement dans des machines virtuelles Azure pour les tests d’interface utilisateur

Si vous approvisionnez des machines virtuelles sur Azure, la configuration de l’agent pour les tests d’interface utilisateur est disponible via l’artefact Agent pour DevTest Labs.

agentArtifactDTL

Définition de la résolution de l’écran

Avant d’exécuter des tests d’interface utilisateur, vous devrez peut-être ajuster la résolution d’écran afin que les applications s’affichent correctement. Pour cela, une tâche utilitaire de résolution d’écran est disponible dans la Place de marché. Utilisez cette tâche dans votre pipeline pour définir la résolution d’écran sur une valeur prise en charge par l’ordinateur agent. Par défaut, cet utilitaire définit la résolution sur la valeur optimale prise en charge par l’ordinateur agent.

Si vous rencontrez des échecs avec la tâche de résolution d'écran, assurez-vous que l'agent est configuré pour s'exécuter avec l'ouverture de session automatique activée et que toutes les sessions de bureau à distance sont déconnectées en toute sécurité à l'aide de la commande tscon comme décrit ci-dessus.

Remarque

La tâche utilitaire de résolution d’écran s’exécute sur l’agent de build/mise en production /test unifié et ne peut pas être utilisée avec la tâche Exécuter les tests fonctionnels qui est déconseillée. La tâche utilitaire de résolution ne fonctionne pas non plus pour les machines virtuelles Azure.

Résolution des problèmes dans les tests d’interface utilisateur

Lorsque vous exécutez des tests d'interface utilisateur en mode sans assistance, la capture de données de diagnostic telles que des captures d'écran ou des vidéos est utile pour découvrir l'état de l'application au moment où la défaillance a été rencontrée.

Effectuer des captures d'écran

La plupart des infrastructures de test d’interface utilisateur offrent la possibilité de réaliser des captures d’écran. Les captures d’écran collectées sont disponibles sous forme de pièce jointe aux résultats de test lorsque ces résultats sont publiés sur le serveur.

Si vous utilisez la tâche de test Visual Studio pour exécuter des tests, les captures d’écran capturées doivent être ajoutées en tant que fichier de résultats afin d’être disponibles dans le rapport de test. Pour cela, utilisez le code suivant :

Tout d’abord, vérifiez que TestContext est défini dans votre classe de test. Par exemple : public TestContext TestContext { get; set; }

Ajouter le fichier de capture d’écran à l’aide de TestContext.AddResultFile(fileName); //Where fileName is the name of the file.

Si vous utilisez la tâche Publier les résultats des tests pour publier des résultats, les pièces jointes des résultats de test ne peuvent être publiées que si vous utilisez le format de résultats VSTest (TRX) ou le format de résultats NUnit 3.0.

Les pièces jointes de résultat ne peuvent pas être publiées si vous utilisez les résultats des tests JUnit ou xUnit. Cela est dû au fait que ces formats de résultats de test n’ont pas de définition formelle pour les pièces jointes dans le schéma de résultats. Vous pouvez utiliser l’une des approches ci-dessous pour publier des pièces jointes de test à la place.

  • Si vous exécutez des tests dans le pipeline de build (CI), vous pouvez utiliser la tâche Copier et publier des artefacts de build pour publier tout fichier supplémentaire créé dans vos tests. Celles-ci s’affichent dans la page Artefacts de votre résumé de build.

  • Utilisez les API REST pour publier les pièces jointes nécessaires. Vous trouverez des exemples de code dans ce référentiel GitHub.

Capture vidéo

Si vous utilisez la tâche de test Visual Studio pour exécuter des tests, la vidéo du test peut être capturée et est automatiquement disponible en tant que pièce jointe au résultat du test. Pour cela, vous devez configurer le collecteur de données vidéo dans un fichier .runsettings et ce fichier doit être spécifié dans les paramètres de tâche.

runSettings

Aide et support