Lors de la rédaction de son étude comparative sur les outils d’automatisation de tests fonctionnels, Osaxis a été amenée à utiliser et décortiquer un certain nombre d’outils permettant d’automatiser les tests par pilotage de l’interface graphique. Une fonctionnalité présente dans la quasi-totalité de ces logiciels est la gestion du référentiel d’objets. Par différentes approches, chaque éditeur propose des opérations plus ou moins complexes qui vont de la visualisation des objets présents dans le référentiel jusqu’à la création d’objets personnalisés.

D’une manière générale, plus le référentiel d’objets est paramétrable, meilleure est la reconnaissance des objets. Cela est d’autant plus vrai lorsque l’on souhaite tester une application utilisant des composants personnalisés ou non standards.

Principe

Le référentiel d’objets est un élément central pour un outil d’automatisation de tests fonctionnels. Il constitue la base d’informations permettant de reconnaître les différents objets d’une application quelles que soient les technologies utilisées.

Les logiciels de tests fonctionnels cherchent à reproduire le comportement d’un utilisateur lors de l’utilisation d’une application. L’outil doit donc reconnaître les actions et évènements déclenchés sur les différents éléments de l’interface. La reconnaissance des objets est ainsi importante car si l’outil arrive à reconnaître un objet en utilisant ses caractéristiques et non pas par ses coordonnées à l’écran, le test sera de meilleure qualité et pourra être réutilisé même en cas d’une réorganisation des objets à l’écran.

Les nombreux éditeurs d’outils de tests fonctionnels ont des approches différentes. On constate que certains offrent un référentiel contenant une collection d’objets-types que le produit est susceptible de rencontrer dans la majorité des cas. D’un autre côté, certains préfèrent initialiser le référentiel uniquement avec les objets reconnus et utilisés par les différents cas de tests.

Lors de la création d’un test, l’outil dispose généralement d’un pointeur d’objets qui met en avant l’objet situé sous le pointeur de la souris. La reconnaissance de cet objet passe par la comparaison de ses propriétés à celles des objets ou types d’objets présents dans le référentiel. Si la correspondance entre l’objet pointé et celui du référentiel est forte, il est alors possible de définir avec une grande probabilité que l’objet pointé est du même type que celui du référentiel.

Dans certains cas, ou bien lors de l’utilisation de composants personnalisés, la comparaison des objets n’est pas assez fiable. L’objet peut ne pas être reconnu ou seulement en partie. Dans ce cas, des outils proposent le paramétrage des propriétés de reconnaissances et certains permettent même de créer de nouveaux objets.

La gestion du référentiel d’objets passe par diverses manipulations de la collection d’objets, comme par exemple son import/export ou encore la fusion de plusieurs référentiels. Cependant, ces opérations ne sont pas toujours proposées.

Quelques exemples

Chaque logiciel présenté ci-après gère son référentiel d’objets d’une manière différente. vTest propose de visualiser et de modifier les propriétés uniquement des objets qui sont reconnus lors des tests. TestComplete et TestPartner permettent de créer des modèles ou des objets-types et donnent la possibilité de faire reconnaître au logiciel des objets complexes aux propriétés personnalisées.

Lors d’un précédent article sur le blog, l’outil libre Selenium était présenté. Selenium utilise une autre approche en faisant référence aux objets d’une page Web directement dans le script de tests (par l’intermédiaire des propriétés et attributs des balises HTML). Il n’existe pas dans Selenium d’outil donnant accès à la liste des objets présents ni permettant leur paramétrage, c’est à dire de véritable référentiel d’objets exploitable.

vTest

Verisium, entreprise située à Fremont en Californie propose des outils d’assurance qualité logicielle dont vTest. vTest propose les fonctionnalités de base sur la gestion d’un référentiel d’objets. Listant les différents éléments rencontrés lors des tests, une fenêtre donne ainsi la possibilité d’en modifier les propriétés de reconnaissances.

llustration 1: Le référentiel d’objets de vTest.

Malheureusement vTest ne propose pas de modèle ou d’objet-type. Les modifications effectuées impactent directement les éléments reconnus dans la page Web. Ainsi, si plusieurs objets identiques sont détectés, vTest crée plusieurs lignes dans son référentiel.

TestComplete

TestComplete est un outil d’automatisation des tests fonctionnels édité par AutomatedQA, une entreprise basée à Beverly aux États-Unis (Massachusetts). Le référentiel d’objets de cet outil possède plusieurs fonctionnalités intéressantes comme la création de « Modèle » de reconnaissance ainsi que le paramétrage des propriétés de reconnaissance des objets.

Dans cet exemple, le but est de faire en sorte qu’un type de titre des articles du Blog d’Osaxis (balise HTML H2) ne soit plus reconnu comme un titre simple mais un titre de couleur bleue (« Titre Bleu ») et cela de manière générique, quel que soit le texte contenu dans le titre.

L’exercice se base sur une application PHP mais le principe reste le même pour les autres technologies (Java, .NET…).

TestComplete ne possède pas de référentiel type pré-initialisé. La création du référentiel se fait soit automatiquement lors de l’enregistrement d’un nouveau test, soit manuellement en l’ajoutant explicitement au projet.

Avant toutes autres opérations qui initialiserait le référentiel d’objets, il est nécessaire de sélectionner l’objet que l’on désire définir comme un objet de type « Titre Bleu » afin d’en paramétrer sa reconnaissance. Cette première étape permettra la reconnaissance de cet objet pour tous les tests fonctionnels à venir.

Cette opération est réalisée grâce à un outil que la plupart des logiciels de tests fonctionnels possèdent : un pointeur d’objets. Avec le navigateur ouvert sur un article de notre blog, la sélection du titre se fait simplement.

Illustration 2: Sélection du titre avec le pointeur d’objets de TestComplete.

TestComplete affiche les propriétés de reconnaissance par défaut utilisées pour cet objet. Comme le montre l’illustration ci dessous, les critères de reconnaissances sont très discriminants et ne permettent que d’identifier cet objet strictement. La seule propriété ici présente qui sera utile par la suite est le type de l’objet (« ObjectType ») mais elle ne peut suffire à elle seule.

Illustration 3: Propriétés discriminantes utilisées pour la détection de l’objet.

L’objet sélectionné précédemment est un titre HTML (balise H2) possédant une classe CSS qui permet de le différencier d’un titre classique de second niveau. TestComplete propose un système de modèle (« Template ») qui offre la possibilité de définir des couples propriétés/valeurs que doivent posséder les objets pour être identifiés comme étant du même type.

Illustration 4: Sélection des nouvelles propriétés discriminantes.

Les trois propriétés sélectionnées sur l’illustration précédente suffisent à identifier notre objet de manière fiable. Le type de l’objet est conservé par rapport à l’identification par défaut de TestComplete. Le nom de la balise HTML (Tag Name) est ajouté ainsi que le nom de la classe CSS afin de ne pas confondre cet objet avec un titre classique.

Après application de ce modèle, il est possible de vérifier la bonne prise en compte des nouveaux paramètres sur l’objet précédemment sélectionné. La liste des propriétés doit alors ressembler à cela :

Illustration 5: Nouvelles propriétés de reconnaissance.

Le but est maintenant de vérifier que ce nouveau modèle fonctionne et s’applique aux autres liens de ce type dans un article différent. En répétant l’étape de sélection de l’objet titre, voici une illustration de la reconnaissance d’objet grâce au nouveau paramétrage.

Illustration 6: Reconnaissance de l’objet grâce au nouveau modèle.

Sur cette illustration les propriétés reconnues (1) sont bien celles de notre modèle qui a d’ailleurs été appliqué automatiquement (2) pour un article ayant comme sujet le composant SSIS du framework .NET (3).

TestPartner

TestPartner, anciennement produit de la société Compuware, est édité par Micro Focus, société basée à Newbury en Angleterre. Micro Focus a acquis en 2009 les activités de tests de Compuware. TestPartner propose d’automatiser les tests fonctionnels et permet également de définir des objets personnalisés. TestPartner peut gérer différents référentiels d’objets grâce à des bases de données telles que Oracle ou Microsoft SQL Server.

L’application utilisée ici est une simulation de gestion de bibliothèque utilisant le langage C# et les composants graphiques Telerik. Pour chaque présentation de livre, deux boutons sont disponibles : le premier permettant de voir la description détaillée du livre, l’autre permettant un retour à la liste des livres. Ces deux boutons sont du même type mais il peut être intéressant de les faire reconnaître comme deux types différents : un « Bouton Retour » et un « Bouton Description ».

Illustration 7: Création d’un nouveau type dans le référentiel d’objets.

TestPartner ne propose pas de référentiel initialisé. Un nouvel objet type doit être ajouté au référentiel. La recherche de l’objet se fait alors à l’aide du pointeur d’objet.

Illustration 8: Objet reconnu en tant que GUIObject

Le bouton retour est reconnu en tant qu’objet graphique (GUIObject). De plus, sa classe reconnue n’est pas très lisible ni pratique à utiliser. Les propriétés utilisées pour sa reconnaissance sont celles listées ci dessous. Il s’agit des propriétés par défaut utilisées par TestPartner :

Illustration 9: Propriétés utilisées pour la reconnaissance de l’objet avant paramétrage.

Ici, l’objet est lié à l’application ce qui contraint fortement sa reconnaissance. Si un objet du même type est reconnu dans une autre application, TestPartner va tout de même créer un nouvel objet, faisant ainsi grossir le référentiel en ajoutant des objets très similaires.

La reconnaissance utilise aussi le nom de la classe de l’objet alors que le nom de la classe .NET est plus lisible. De plus, la propriété contenant le texte du bouton n’est pas présente ici, alors qu’elle va permettre de distinguer les deux types de boutons.

Afin de bénéficier au mieux du référentiel, une solution consiste à modifier les propriétés de reconnaissance de la manière suivante :

• Suppression du nom de l’application et du nom de la classe. Cette dernière est remplacée par le nom de la classe .NET.
• Ajout du texte contenu dans le bouton.
• Ajout du type de base de l’objet (Objet graphique).

Ceci donne donc l’utilisation des propriétés suivantes pour la reconnaissance du « Bouton Retour » :

Illustration 10: Propriétés utilisées pour la reconnaissance après personnalisation.

Cette manipulation a permis de configurer la reconnaissance de l’objet « Bouton Retour ». De la même manière, l’opération est à renouveler pour paramétrer la détection du « Bouton Description ».

La bonne application du paramétrage peut être vérifiée avec l’explorateur d’objet de TestPartner. Cette fenêtre donne, pour une application donnée, l’organisation des différents composants la constituant. On découvre dans l’arbre, les deux objets dont les propriétés de reconnaissance ont été adaptées. Encadré en bleu, le bouton « Description » est ainsi reconnu en tant que tel et est différencié du bouton « Retour », encadré en vert :

Illustration 11: Vérification de la reconnaissance des objets grâce au nouveau paramétrage.

Conclusion

Les exemples décrits ci-dessus sont relativement simples. Cependant les possibilités de paramétrages permettent des créer des objets types beaucoup plus complexes. Par exemple, TestComplete peut tester le nombre de nœuds enfants ainsi que leurs types, s’adaptant ainsi à la quasi-totalité des situations rencontrées lors de la création de tests fonctionnels.

La reconnaissance d’objets est une fonctionnalité importante pour un outil d’automatisation de tests fonctionnels. Les entreprises utilisant des composants graphiques avancés ou personnalisés pour leurs développements apprécieront les fonctionnalités leur permettant de reconnaître ces objets particuliers. La capacité par exemple d’un outil tel que TestPartner à reconnaître des objets Telerik constitue un plus indéniable.

De plus, au delà de la reconnaissance d’objets, une grande majorité des outils proposent un référentiel d’objets plus ou moins évolué. Cela permet dans un second temps d’exploiter au mieux les différents objets de l’interface même si ceux-ci n’ont pas été initialement reconnus.