Utilisation d'UI Automation pour des tests automatisés

  • Article

Cette présentation explique comment Microsoft UI Automation peut être utile en tant qu’infrastructure pour l’accès par programmation aux scénarios de tests automatisés.

UI Automation fournit un modèle objet unifié qui permet à toutes les infrastructures d’interface utilisateur d’exposer des fonctionnalités complexes et riches de manière accessible et facilement automatisée.

UI Automation a été développé comme successeur de Microsoft Active Accessibility, une infrastructure conçue pour fournir une solution permettant de rendre les contrôles et les applications accessibles. Microsoft Active Accessibility n’a pas été conçu avec l’automatisation des tests à l’esprit, bien qu’il ait évolué vers ce rôle en raison des exigences similaires d’accessibilité et d’automatisation. UI Automation est spécifiquement conçu pour fournir des fonctionnalités robustes pour les tests automatisés, en plus de fournir des solutions plus raffinées pour l’accessibilité. Par exemple, Microsoft Active Accessibility s’appuie sur une seule interface pour exposer des informations sur l’interface utilisateur et collecter les informations nécessaires aux produits de technologie d’assistance ; UI Automation sépare les deux modèles.

Un fournisseur et un client sont tous deux tenus d’implémenter UI Automation pour qu’il soit utile en tant qu’outil de test automatisé. UI Automation fournisseurs sont des applications, telles que Microsoft Word, Microsoft Excel et d’autres applications ou contrôles tiers basés sur le système d’exploitation Windows. Les clients UI Automation incluent des scripts de tests automatisés et des applications de technologie d’assistance.

Cette rubrique contient les sections suivantes.

UI Automation dans Fournisseurs

Pour automatiser un élément de l’interface utilisateur, le développeur doit examiner les actions qu’un utilisateur final peut effectuer sur l’objet d’interface utilisateur à l’aide de l’interaction standard du clavier et de la souris. Une fois ces actions clés identifiées, les modèles de contrôle UI Automation qui miroir la fonctionnalité et le comportement de l’élément d’interface utilisateur doivent être implémentés sur le contrôle. Par exemple, l’interaction de l’utilisateur avec un contrôle de zone de liste modifiable implique généralement de développer et de réduire la zone de liste déroulante pour afficher ou masquer une liste d’éléments, de sélectionner un élément dans la liste ou d’ajouter une nouvelle valeur via l’entrée du clavier.

Avec d’autres modèles d’accessibilité, les développeurs doivent rassembler les informations directement à partir des boutons, menus ou autres contrôles individuels. Chaque type de contrôle est disponible en dizaines de variantes mineures. En d’autres termes, même si 10 variantes d’un bouton push fonctionnent de la même façon et exécutent la même fonction, elles doivent toutes être traitées comme des contrôles uniques. Il n’existe aucun moyen de savoir si ces contrôles sont équivalents d’un point de vue fonctionnel. UI Automation modèles de contrôle ont été développés pour représenter ces comportements de contrôle courants. Pour plus d'informations, consultez UI Automation Control Patterns Overview.

Sans le modèle unifié de modèles de contrôle fourni par UI Automation, les outils de test et les développeurs doivent disposer d’informations spécifiques à l’infrastructure pour exposer les propriétés et les comportements de contrôle dans cette infrastructure. Étant donné que plusieurs infrastructures d’interface utilisateur différentes peuvent être présentes en même temps dans les systèmes d’exploitation Windows, notamment Microsoft Win32, Windows Forms et Windows Presentation Foundation (WPF), il peut être difficile de tester plusieurs applications avec des contrôles qui semblent similaires. Par exemple, le tableau suivant répertorie les noms de propriétés spécifiques à l’infrastructure nécessaires pour récupérer le nom ou le texte associé à un contrôle de bouton et affiche l’équivalent UI Automation propriété.

Type de contrôle Infrastructure de l’interface utilisateur Propriété spécifique à l’infrastructure Propriété UI Automation
Bouton WPF Contenu Nom de la propriété
Bouton Win32 Caption Nom de la propriété
Image HTML alt Nom de la propriété

 

Les fournisseurs UI Automation sont chargés de mapper les propriétés spécifiques à l’infrastructure de leurs contrôles aux propriétés UI Automation équivalentes. Pour plus d’informations sur l’implémentation de UI Automation dans un fournisseur, consultez UI Automation Guide du programmeur du fournisseur. Pour plus d’informations sur l’implémentation de modèles de contrôle, consultez Implémentation de modèles de contrôle UI Automation.

UI Automation dans Clients

L’objectif des scénarios et des outils de test automatisés est la manipulation cohérente et reproductible de l’interface utilisateur. Par exemple, cela peut impliquer le test unitaire de contrôles spécifiques, ainsi que l’enregistrement et l’exécution de scripts de test qui itèrent via une série d’actions génériques sur un groupe de contrôles.

Une complication dans les applications automatisées est la difficulté de synchroniser un test avec une cible dynamique, par exemple, un contrôle de zone de liste, tel que le Gestionnaire des tâches Windows, qui affiche une liste d’applications en cours d’exécution. Étant donné que les éléments de la zone de liste sont mis à jour dynamiquement en dehors du contrôle de l’application de test, une tentative de sélection répétée d’un élément spécifique dans la zone de liste avec une cohérence quelconque est impossible. Des problèmes similaires peuvent se produire lors de la tentative de répétition de modifications de focus simples dans une interface utilisateur qui échappe au contrôle de l’application de test.

Accès par programme

L’accès par programmation permet d’imiter, avec du code, les interactions et les expériences produites par les entrées classiques au clavier et à la souris. UI Automation permet l’accès par programmation via cinq composants :

  • L’arborescence UI Automation facilite la navigation dans la structure de l’interface utilisateur. L’arborescence est créée à partir de la collection de s HWND. Pour plus d’informations, consultez UI Automation Vue d’ensemble de l’arborescence.
  • Les éléments Automation sont des composants individuels dans l’interface. Ceux-ci peuvent souvent être plus granulaires qu’un HWND.
  • Les propriétés Automation fournissent des informations spécifiques sur les éléments d’interface utilisateur . Pour plus d'informations, consultez UI Automation Properties Overview.
  • Les modèles de contrôle définissent un aspect particulier des fonctionnalités d’un contrôle. Il peut s’agir d’informations sur les propriétés, les méthodes, les événements et les structures. Pour plus d'informations, consultez UI Automation Control Patterns Overview.
  • Les événements Automation fournissent des informations et des notifications d’événements. Pour plus d'informations, consultez UI Automation Events Overview.

Propriétés principales pour l’automatisation des tests

La possibilité d’identifier de manière unique et ensuite de localiser n’importe quel contrôle dans l’interface utilisateur fournit la base pour que les applications de test automatisées fonctionnent sur cette interface utilisateur. UI Automation propriétés utilisées par les clients et les fournisseurs pour identifier et localiser des contrôles sont décrites dans le tableau suivant.

Propriété Description
AutomationId Distingue de manière unique un élément d’automatisation de ses frères. La prise en charge de la propriété AutomationId n’est pas requise. Lorsqu’elle est disponible, la propriété AutomationId d’un élément est la même dans n’importe quel instance de l’application, quelle que soit la langue locale. Bien que la propriété AutomationId soit unique parmi les éléments frères, il se peut qu’elle ne soit pas unique sur l’ensemble du bureau. Par exemple, plusieurs instances d’une application, ou plusieurs affichages de dossiers dans Microsoft Windows Explorer, peuvent contenir des éléments avec le même AutomationIdProperty, comme « SystemMenuBar ». Les clients ne doivent faire aucune hypothèse concernant les AutomationIds exposés par d’autres applications. AutomationId n’est pas garanti pour être stable dans différentes versions ou builds d’une application.
ControlType Identifie le type de contrôle représenté par un élément Automation. Des informations importantes peuvent être déduites à partir de la connaissance du type de contrôle. Pour plus d'informations, consultez UI Automation Control Types Overview.
Name Chaîne de texte qui identifie ou explique l’objectif d’un élément automation. Il doit être utilisé avec prudence, car il peut être localisé. La propriété Name n’est pas un identificateur unique parmi les frères. Pour tester l’automatisation, les clients doivent utiliser la propriété AutomationId ou la propriété RuntimeId à la place.
RuntimeId Tableau d’entiers qui représentent un identificateur pour un élément automation. L’identificateur est unique sur le bureau, mais il est garanti qu’il soit unique à l’interface utilisateur du bureau sur lequel il a été généré. Les identificateurs peuvent être réutilisés au fil du temps. Utilisez IUIAutomation::CompareElements pour déterminer si l’élément qui a actuellement un ID d’exécution particulier est l’élément qui avait précédemment cet ID. En outre, le format de la propriété RuntimeId peut changer. Il doit être traité comme une valeur opaque et utilisé uniquement à des fins de comparaison; par exemple, pour déterminer si un élément automation se trouve dans le cache.

 

Inspect (Inspect.exe) est un outil Windows que vous pouvez utiliser pour collecter des informations UI Automation pour le développement et le débogage du fournisseur et du client. Inspect est inclus dans le Kit de développement logiciel (SDK) Windows.

Considérations relatives à la sécurité UI Automation