Améliorer la robustesse des scripts de test

Parfois, les étapes enregistrées dans un test ne sont pas reconnues à la relecture et font échouer le test. Pour éviter les problèmes de reconnaissance, vous pouvez changer la manière dont les objets sont identifiés, utiliser des conditions de localisation ou appliquer des conditions de conception adaptative. De cette manière, vous améliorez la robustesse des tests et avez de meilleures chances de pouvoir les inclure dans un processus de test automatisé.

L'une des raisons d'un échec d'étape dans un test est la mise à jour d'une application. Vous enregistrez un test avec une version précise d'une application. Vous réutilisez ce test avec une nouvelle version de l'application. Or, dans cette nouvelle version, il y a de nouveaux boutons ou certains objets ont changé de place. Un autre motif d'échec de l'étape est que les données du test ont pu changer entre le moment où le test a été enregistré et celui où il est lu (par exemple, la date).

Voici quelques moyens d'améliorer la robustesse d'un script de test :

Propriétés des objets

Les propriétés des objets sont capturées à l'enregistrement du test et affichées en lecture seule dans la table des propriétés de la vue Données d'interface utilisateur Web et mobile. A la lecture d'un test, pour trouver un objet dans l'application testée, le Test Workbench compare les propriétés qui ont été capturées lors de l'enregistrement à la description des propriétés visible dans la section Détails d'action utilisateur de l'éditeur de test. Ces propriétés diffèrent selon la nature de l'application (Android, iOS ou interface web).

Lorsque vous sélectionnez une étape d'un test enregistré, l'éditeur de test affiche les propriétés de l'objet cible de l'action effectuée dans cette étape. Les propriétés de cet objet sont listées dans le champ Objet identifié par, lui-même suivi d'une liste de sélection d'opérateur et d'un champ d'insertion pour la valeur de la propriété.

Figure 1. Editeur de test, étape sélectionnée avec l'objet correspondant, identifié par une propriété, un opérateur et une valeur.
Editeur de test, étape sélectionnée avec l'objet correspondant, identifié par une propriété, un opérateur et une valeur.

Vous pouvez changer ces conditions (propriété, opérateur et valeur de propriété) dans la section Détails d'action utilisateur de l'éditeur de test ou dans la vue Données d'interface utilisateur Web et mobile (via le menu contextuel). Lorsque des actions sont sélectionnées dans la liste Contenu du test, la vue Données d'interface utilisateur Web et mobile est automatiquement synchronisée pour afficher la capture d'écran pour l'étape sélectionnée. Les propriétés peuvent être modifiées dans l'onglet Capture d'écran, dans l'onglet Eléments ou dans la table des propriétés à l'aide du menu contextuel.

Les propriétés peuvent être modifiées à partir de la vue Données d'interface utilisateur Web et mobile, dans l'onglet Capture d'écran, dans l'onglet Eléments ou dans la table des propriétés à l'aide du menu contextuel.
Figure 2. Les propriétés peuvent être modifiées à partir de la vue Données d'interface utilisateur Web et mobile, dans l'onglet Capture d'écran, dans l'onglet Eléments ou dans la table des propriétés à l'aide du menu contextuel.
Pour plus de détails, voir Changer la propriété utilisée pour identifier un objet dans un script de test.

Emplacement des objets dans un test

A l'exécution d'un test, les objets graphiques sont normalement détectés automatiquement, mais il arrive que l'élément auquel s'applique une action soit difficile à identifier. Dans cette situation, vous devez mettre à jour le script du test afin de fournir des informations plus précises sur la position de l'objet auquel l'action est censée s'appliquer.

Voyons un exemple : vous enregistrez un test et, à une étape particulière, l'action consiste à cliquer sur un texte à éditer, dont le contenu est '30 août 2013'. Si le test est relu automatiquement à une date ultérieure, il échouera, du fait du changement de date. Vous devez donc modifier l'étape et fournir des informations plus précises sur la position de l'objet auquel l'action est censée s'appliquer. Cet objet pourra ainsi être localisé et utilisé automatiquement à l'exécution du test. Le Test Workbench offre différents moyens d'identifier et de situer les objets afin d'accroître la fiabilité des tests.

Dans le Test Workbench, différents opérateurs de localisation d'objet sont disponibles afin de permettre l'identification des objets dans une application Android, iOS ou web que vous testez. Ils sont visibles dans les champs de la partie Emplacement de l'objet, sous la section Détails d'action utilisateur de l'éditeur de test. Deux emplacements (principal et secondaires) peuvent être utilisés dans une étape de test pour fixer les conditions de localisation de l'objet cible. Pour plus de détails, voir Définir les conditions de localisation d'objet dans un script de test.

Figure 3. Champs d'emplacement d'objet avec la liste des opérateurs de localisation (pour les applications Android dans cet exemple)
Champs des emplacements d'objet principal et secondaire, avec la liste des opérateurs ouverte pour l'emplacement secondaire (représentée ici pour les applications Android)

Pour un tutoriel vidéo incluant une démonstration des différentes techniques d'identification d'un objet dans un test, voir How to create robust test scripts for mobile and desktop web applications.

Reconnaissance d'image dans un test

Lors de l'enregistrement d'un test, l'objet sur lequel s'exerce une action à une étape particulière est identifié par sa propriété principale, qui est généralement un texte. Les propriétés de type 'texte' ne sont pas toujours facilement identifiables. Cela peut être le cas lorsqu'il n'y a pas de propriété 'description' ni de libellé pour identifier l'élément cible dans une étape de test. Dans ces conditions, le générateur de test utilise une propriété 'image' pour identifier l'élément.

Pour reconnaître et gérer les objets à la relecture du test, le Test Workbench utilise un procédé de corrélation d'images. L'image sur laquelle l'action est effectuée est capturée à l'enregistrement. Il s'agit de l'image de référence. A la relecture du test, elle est comparée à l'image de l'application testée, que l'on appelle image candidate. Un seuil de reconnaissance réglable autorise un certain degré de variation entre l'image de référence et l'image candidate. Conjointement avec la tolérance de rapport hauteur/largeur, il détermine si les images comparées son concordantes ou non. Le seuil de reconnaissance est réglé à 80, par défaut. La tolérance de rapport hauteur/largeur est quant à elle réglée à 20, par défaut.

Voici quelques exemples de scénarios de test mettant en jeu le procédé de corrélation d'images :
  • Vous enregistrez un test sur un téléphone mobile et vous le lisez sur une tablette. Comme la largeur et la hauteur de l'image changent d'un appareil à un autre, la lecture du test échoue sur les appareils dont l'écran n'a pas le même rapport hauteur/largeur.
  • Certains objets cible présents à l'enregistrement ne sont plus les mêmes à la relecture du test. Par exemple, dans une application sécurisée avec saisie d'un code secret, la position des chiffres du clavier virtuel change d'une session à l'autre.

Dans certains cas, l'application testée contient un objet personnalisé ou un autre objet que le Test Workbench ne trouve pas. Dans d'autres cas, l'image sélectionnée n'est pas la bonne et le test échoue. Pour remédier à ces situations, vous pouvez changer l'image utilisée pour identifier l'objet cible de l'étape en cause ou changer les valeurs de seuil de reconnaissance et de tolérance de rapport hauteur/largeur utilisées dans le test.

Remarque : Il est possible d'utiliser des images dans les points de vérification des contrôles. Par exemple, vous pouvez vérifier la position d'une liste déroulante dans un écran. Pour plus de détails, voir Création de points de vérification à partir de la vue Données d'interface utilisateur Web et mobile.

Si le seuil est réglé à 0, l'image candidate présentant le plus de similitudes avec l'image de référence sera sélectionnée, même s'il ne s'agit pas de la même image. Si vous réglez le seuil à 100, la plus infime différence par rapport à l'image de référence empêchera la reconnaissance de toute image candidate. Par exemple, si le test est relu sur une tablette, une image dont la largeur ou la hauteur diffère sera redimensionnée en conséquence. Or, si le seuil est réglé à 100, l'image ne sera pas sélectionnée, même s'il s'agit de la même image qu'à l'enregistrement. Vous pouvez changer la tolérance de rapport hauteur/largeur si la relecture d'un test échoue sur un appareil qui n'a pas le même rapport hauteur/largeur que l'appareil utilisé à l'enregistrement, ou si les images affichées dans l'application à la relecture sont différentes de celles qui étaient disponibles à l'enregistrement.

Lorsque vous réglez le seuil de reconnaissance, le Test Workbench affiche un aperçu des images en correspondance dans l'éditeur pour vous aider à choisir l'image qui permettra d'identifier précisément l'objet cible à la relecture du test. Les meilleures images candidates sont en vert, celles dont le score est au-dessus du seuil et qui ne sont pas les plus appropriées sont en jaune et celles dont le score est en dessous sont en rouge. Ces images candidates ne concordent pas avec les images de référence.

Les détails de la corrélation d'images sont fournis dans le rapport de test affiché au terme de l'exécution du test.

Pour plus de détails, voir Modifier une cible d'étape en utilisant une image comme propriété principale.

Condition de conception adaptative

Certaines applications ont une conception adaptative (Responsive Design), c'est-à-dire que leur comportement ou leur affichage graphique s'adaptent à l'appareil cible utilisé. De plus en plus d'applications sont conçues pour adapter le format de leurs éléments graphiques à la taille de l'écran ou à son orientation, ou encore à la version du système d'exploitation ou à d'autres conditions.

D'autres applications demandent à leurs utilisateurs de se connecter et d'indiquer leur position géographique. D'autres encore déroulent, à leur première exécution, un tutoriel qu'elles n'affichent plus ensuite. Toutes ces situations peuvent faire échouer un test.

Pour y remédier, vous pouvez appliquer des conditions d'exécution à une sélection d'actions variables. Elles permettent d'exécuter un bloc d'actions à la première exécution du test, mais pas lors des exécutions suivantes. On parle alors de conditions de conception adaptative. Pour plus de détails, voir Créer des conditions de conception adaptative dans un test. Cette fonctionnalité n'est disponible, pour les applications Android, que dans la version 8.7.1 du Test Workbench.


Retour d'informations