WinAppDriver : alternatives pour applications sans arbre d'accessibilité

Quand l'outil de test ne voit pas votre application

Vous pointez Inspect sur le bouton Sauvegarder de votre application, et il n'affiche qu'un seul panneau vide.Votre localisateur ne trouve rien, le test WinAppDriver échoue, et la recherche d'une alternative à WinAppDriver commence.

L'outil est rarement le problème.Presque tous les outils de test d'applications de bureau demandent à l'arbre d'accessibilité de l'application où se trouve le bouton, et certaines applications n'en ont pas.

Ce guide explique comment fonctionne l'automatisation des tests d'applications de bureau Windows, quelles applications elle ne voit pas, et comment tester malgré tout une telle application de bureau Windows : en trouvant chaque élément à vue, comme le fait une personne.

Comment fonctionne l'automatisation des tests d'applications de bureau Windows ?

L'automatisation des tests d'applications de bureau, ce sont des logiciels qui pilotent une application par son interface, comme le ferait un testeur, et vérifient ce qu'elle affiche.Sous Windows, elle passe presque entièrement par Microsoft UI Automation, le framework d'accessibilité qui alimente aussi les lecteurs d'écran.

Chaque application décrit son interface à Windows sous la forme d'un arbre.La fenêtre contient des panneaux, et les panneaux contiennent des boutons, des champs et des listes, chacun avec un nom, un type et un emplacement à l'écran.Microsoft Active Accessibility, ou MSAA, est la technologie plus ancienne qui fait de même pour les programmes plus anciens.

Un outil de test lit cet arbre, trouve un élément avec un localisateur comme son AutomationId, son nom ou un XPath à travers l'arbre, puis clique dessus, y saisit du texte ou lit sa valeur.

Cela fonctionne bien quand l'arbre est complet.Microsoft fournit la description de chaque contrôle standard Win32, Windows Forms (WinForms) et WPF, si bien que ceux-ci apparaissent d'eux-mêmes dans l'arbre.Un contrôle personnalisé est différent : ses développeurs doivent écrire cette description, et sans elle, d'après la documentation de Microsoft, le contrôle est en grande partie opaque pour UI Automation, qui ne peut guère indiquer que son emplacement.

WinAppDriver et ses alternatives lisent le même arbre

WinAppDriver, le Windows Application Driver de Microsoft, a apporté une automatisation à la Selenium aux applications UWP, Windows Forms, WPF et Win32 classiques.Sa dernière version stable sur GitHub, la version 1.2.1, date de novembre 2020, suivie d'une version candidate 1.3 en juillet 2021.Le pilote Windows d'Appium, construit sur lui, est désormais marqué comme obsolète, et sa documentation désigne le pilote Appium WinCore comme son remplaçant officiel.

Les alternatives habituelles prennent chacune un chemin différent vers le même arbre :

• Appium WinCore et NovaWindows sont des pilotes Appium qui agissent sur les éléments d'UI Automation, depuis un test écrit dans n'importe quel langage que prend en charge Appium.
• FlaUI est une bibliothèque .NET open source qui encapsule les bibliothèques UI Automation de Microsoft pour des tests écrits en C#.
• pywinauto est une bibliothèque Python open source avec deux back-ends : l'API Win32 et UI Automation.
• Coded UI, le framework de tests d'interface propre à Visual Studio, est obsolète : Visual Studio 2019 est la dernière version qui crée des tests avec lui.
• TestComplete et Ranorex sont des outils commerciaux qui identifient les contrôles par leurs propriétés, et tous deux proposent une automatisation basée sur l'image pour les contrôles qu'ils ne savent pas reconnaître.

Même les recommandations les plus récentes de Microsoft pour les applications WinUI 3, les commandes winapp ui destinées aux agents IA, lisent l'arbre d'accessibilité en direct et demandent aux développeurs de définir un AutomationId sur chaque contrôle interactif.

Pour voir côte à côte les outils de test web, consultez l'étude comparative.

Quelles applications Windows n'ont pas d'arbre d'accessibilité ?

Pointez Inspect sur l'une d'elles, et vous trouverez souvent un seul panneau vide là où vous attendiez un formulaire.C'est le quotidien du test des applications historiques (legacy), et de beaucoup d'applications modernes aussi.

Parfois l'arbre existe, mais vous n'avez pas le droit de toucher à l'application : un programme d'un autre éditeur, une version verrouillée pour un audit, une équipe qui ne peut pas ajouter d'AutomationId pour vous.Tout outil qui a besoin d'une version de test, d'un agent dans l'application ou d'une modification de son code est alors hors de portée.

Comment vérifier votre propre application en deux minutes

1. 1

   Ouvrir un outil d'inspection

   Installez Accessibility Insights for Windows, l'outil d'inspection de Microsoft, ou utilisez Inspect, fourni avec le Windows SDK.

2. 2

   Survoler les éléments dont vos tests ont besoin

   Chacun devrait apparaître avec un nom, un type et un AutomationId.

3. 3

   Lire ce que vous voyez

   Un seul panneau pour toute la fenêtre, ou des éléments sans nom, signifie qu'un outil basé sur l'arbre ne peut pas les trouver de façon fiable.

Le test basé sur l'image : tester ce qui est à l'écran

Le test basé sur l'image est une automatisation des tests qui trouve les éléments par leur apparence à l'écran, et non par ce que l'application en dit.C'est ainsi que fonctionne l'automatisation des tests d'applications de bureau sans informations d'accessibilité.Il n'a besoin de rien de la part de l'application : ni arbre, ni localisateur, ni modification de son code.Si vous pouvez voir un élément, un test peut l'atteindre.

SikuliX en est l'exemple open source classique : vous capturez une image de chaque élément et écrivez chaque étape comme une ligne de script.Les outils commerciaux le proposent comme solution de repli.La documentation de TestComplete, par exemple, indique que ses tests basés sur l'image ne peuvent être enregistrés que sur des applications Android : sur une application de bureau, vous capturez les images et ajoutez les commandes de test à la main.

Fait naïvement, un test à vue a des points faibles bien connus.Chacun a sa réponse :

Une alternative à WinAppDriver qui n'a besoin d'aucun arbre

GUI Test Studio est une suite de tests GUI de bout en bout pour Windows qui teste n'importe quelle application que vous voyez sur votre écran, sans code.Elle ne choisit pas entre l'arbre et l'écran.

Le GTS Engine + AI interroge d'abord les informations d'accessibilité de l'application, quand il y en a, et trouve l'élément à vue quand il n'y en a pas.

Comment GUI Test Studio trouve les éléments explique comment les deux chemins fonctionnent ensemble.Voici ce que cela signifie pour une application sans arbre, étape par étape.

1. 1

   Enregistrer l'application

   Dans GUI Test Runner-Recorder, cliquez sur Enregistrer et choisissez Une application.Choisissez le programme parmi les applications ouvertes, ou parcourez vos dossiers jusqu'à un programme qui n'est pas encore lancé.Cochez la case qui le lance avec le test et le ferme à la fin, pour que chaque exécution parte d'une application fraîchement lancée.Utilisez ensuite l'application comme d'habitude.

   

   Agrandir

   Choisir une application tient une notification d'un autre programme à l'écart de votre test, tandis que chacun de vos clics et chacune de vos touches restent enregistrés.Voir Enregistrer un test.

2. 2

   Chaque élément est gardé de deux façons

   Chaque clic reçoit une assertion visuelle juste avant lui : une image de l'élément, sa cible visuelle.Quand l'application décrit cet élément à Windows, le test garde aussi cette description.Quand l'application répond par un seul panneau vide, il n'y a rien qui vaille la peine d'être gardé, et l'image seule trouve l'élément.

   Certains programmes dessinent leurs formulaires à la main et ne décrivent que la fenêtre du formulaire lui-même.Le test garde cette fenêtre, si bien qu'un formulaire qui a bougé est retrouvé là où il se trouve maintenant.

3. 3

   Vérifier ce qui est affiché

   Une assertion visuelle vérifie qu'un élément est à l'écran et a le bon aspect.Une assertion de texte demande à l'application ce que dit un élément, et lit les mots à l'écran quand l'application ne peut pas le dire.Une assertion de texte dynamique vérifie par son format une valeur qui change à chaque exécution, comme une date ou un numéro de commande.

   Chaque comparaison ignore les petites différences de rendu que tout écran présente et détecte tout de même les vraies régressions, ce qu'une personne appellerait un changement : une mauvaise couleur, une icône manquante, un mot qui a changé.Voir Assertions visuelles.

4. 4

   L'exécuter, où que la fenêtre s'ouvre

   Le test rejoue vos clics et vos touches comme de vraies entrées souris et clavier, visées là où se trouve maintenant chaque élément.Quand une assertion n'a pas trouvé son élément dans sa zone de recherche au bout d'une seconde, elle regarde aussi sur tout l'écran, si bien qu'une fenêtre qui a bougé ne fait pas échouer le test.Le rapport de confiance indique alors que l'élément a été trouvé en dehors de sa zone de recherche, et propose de l'élargir dans GUI Test Studio.

   Sur un ordinateur à plusieurs moniteurs, un test utilise un seul écran ou tous les écrans, et retient son choix.

   

   Agrandir

Citrix, Bureau à distance et machines virtuelles

Une session Citrix, Bureau à distance (RDP) ou VMware Horizon arrive sur votre ordinateur sous la forme d'une seule fenêtre de pixels.Certains outils ne peuvent atteindre ses contrôles que s'ils sont installés sur le serveur distant lui-même, comme SmartBear le décrit pour TestComplete.GUI Test Studio teste la session depuis l'ordinateur qui l'affiche, à vue, comme n'importe quelle autre fenêtre.

Choisissez Une application et la fenêtre de la session à l'enregistrement, ou Une zone de l'écran pour l'un de ses panneaux.Une application dans une machine virtuelle fonctionne de la même façon : donnez à la machine virtuelle une taille de fenêtre fixe, la même sur chaque ordinateur qui exécute les tests.Voir Ce que vous pouvez tester.

Exécuter les tests d'applications de bureau à chaque build

gtr-cli, l'outil en ligne de commande, exécute un test exactement comme le bouton Exécuter le test.Il ajoute ce dont un pipeline a besoin : un code de sortie, un fichier JUnit, et toutes les preuves d'un échec dans un seul dossier.

gtr-cli run tests --countdown 0 --junit results\junit.xml --artifacts results\artifacts

Un test d'application de bureau se rejoue sur un écran réel, l'agent de build a donc besoin d'une session de bureau Windows déverrouillée.Une machine virtuelle avec une taille d'écran fixe convient bien comme agent de test.Le guide CI/CD explique sa mise en place étape par étape.

Questions

WinAppDriver, Windows, Visual Studio, Selenium, Appium, FlaUI, pywinauto, TestComplete, Ranorex, SikuliX, Delphi, Java, Citrix, VMware Horizon et Electron sont des marques de leurs propriétaires respectifs.