/
06 - Découvrir le langage de test GDSL

06 - Découvrir le langage de test GDSL

MAJ 28 aout 2024

Le Greenspector Domain-specific language (GDSL) est utilisé par Greenspector Studio pour décrire un parcours utilisateur. Par convention, les fichiers écrits en GDSL utilisent l’extension .testgb.

Structure basique

Pour indiquer ce qui doit être mesuré, la même structure est utilisée pour chaque étape :

measureStart,NOMETAPE instructions measureStop

Chaque instruction entre measureStart et measureStop sera mesurée tandis que tout ce qu’il y a à l’extérieur sera ignoré :

measureStart,NOMETAPE1 # Mesuré dans NOMETAPE1 instructions measureStop # Non mesuré instructions measureStart,NOMETAPE2 # Mesuré dans NOMETAPE2 instructions measureStop

Format

Plusieurs règles doivent être respectées pour une automatisation fonctionnelle :

  • 1 instruction par ligne

  • commentaire avec # sur une ligne séparée

  • des paramètres suivent une instruction séparés par ,

Un paramètre qui contient le symbol , n’est pas autorisé.

Exemple de GDSL:

# commentaire measureStart,NOMETAPE enterText,mon premier texte measureStop

Instruction

Des instructions sont disponibles pour automatiser un parcours utilisateur. Voici les préfixes des principales commandes :

  • application instructions sont relatives au lancement, arrêt, nettoyage, installation ou désinstallation d’applications

  • assert instructions permettent de vérifier la présence d’un élément

  • browser instructions sont des instructions spéciales qui gèrent le navigateur tests web

  • click instructions proposent différentes manières de cliquer sur des boutons par texte, id, position, etc

  • find instructions recherchent dans la hiérarchie d'éléments UI pour trouver facilement un élément spécifique

  • pause pour faire une pause d’un temps défini

  • press instructions sont pratiques pour activer boutons spéciaux, comme le clavier keyboard ou des boutons physiques

  • scroll et swipe instructions permettent de se déplacer horizontalement ou verticalement sur une page. scroll reproduit un mouvement où le doigt appuie sur l'écran, se déplace puis relâche. swipe reproduit seulement un mouvement glissant.

  • wait instructions sont pratiques après le changement d’une page à ce qu’elle soit complètement chargée

D'autres commandes spécifiques existent pour manipuler des texts, les paramètres, l'écran, des formulaires, des authentifications OTP, etc.

La documentation globale peut être trouvée ici :

Type de mesure

4 types de mesures sont utilisées, et indiquées par le préfixe du nom de l'étape :

  • CHRGT_ pour les étapes de chargement :

    • L’usage typique est l’affichage d’une nouvelle vue : lancement de l'application, clic d’un bouton menant à un changement de page

    • Elle doit se terminer avec une instruction wait pour attendre le chargement complet

  • PAUSE_ pour les étapes de pause :

    • L’usage type est d’observer le comportement d’une page sans aucune action de la part de l’utilisateur pour détecter une consommation anormale de données ou d'énergie

  • ACTION_ pour les étapes d’action :

    • L’usage type est une action qui ne résulte pas avec l’affichage d’une nouvelle vue

    • Plusieurs actions peuvent être groupées si elles ont le même sens fonctionnel

  • SCROLL_ pour les étapes de scroll :

 

Nous remarquons une pause avant la fin de chaque étape pour mesurer les consommations résiduelles et chargements.

Une practique usuelle est d’utiliser une variable pour définir les instructions de pause à la fin de chaque type d'étape.

Les variables utilisées en GDSL seront expliquées dans une section dédiée.