Fonctionnement du GDSL

maj 31 oct 2024

Afin de décrire un scénario de parcours utilisateur, un script doit être écrit à l'aide du langage GDSL. Celui-ci permet d'automatiser la navigation de votre application sur les smartphones du banc de mesure, et de prendre des mesures tout au long du scénario.

Structure fondamentale

Dans le fichier script, chaque étape est construite selon le même modèle de commande GDSL :

startMeasure,Nom d'étape
Instructions GDSL (saisie, clic, défilement, vérification de l'affichage de l'application, pause, etc.)
StopMeasure

Chaque instruction entre measureStart et measureStop sera mesurée et tout ce qui sera en dehors sera ignoré.

Les smartphones présents sur le banc d'essai sont configurés en anglais uniquement. Il faut en tenir compte lors de la création du script (textes détectés en anglais, boutons en anglais, etc.).

Etapes techniques standards

Référence
- au début du script
- permet de mesurer le smartphone sans l'application ou le navigateur sans le site
Arrière plan (background):
- à la fin du script
- mesure de l'application en arrière-plan puis tuée.

Types d'étapes

Il existe 4 types d'étapes utilisés et indiqués en préfixe du nom de l'étape :

Chargement : CHRGT_
Action : ACTION_
Scroll : SCROLL_
Pause : PAUSE_

Chargement :

Préfixe du nom d'étape : CHRGT_
Terminée par l'attente de l’affichage d'un élément dans la nouvelle vue

measureStart,CHRGT_exemple 
pressEnter 
waitUntilText,Accepter les cookies 
pause,1000 
measureStop

Action :

Préfixe du nom d'étape : ACTION_
L'utilisation typique est une action qui n'entraîne pas l'affichage d'une nouvelle vue.
Plusieurs actions peuvent être regroupées si cela a un sens fonctionnel

measureStart,ACTION_exemple
clickByText,Accepter les cookies
pause,500
clickById,onetrust-accept-btn-handler
pause,1000
measureStop

Scroll :

Pause :

Préfixe du nom d'étape : PAUSE_
L'utilisation typique est l'observation du comportement de la page sans action de l'utilisateur afin de détecter une consommation inhabituelle de données ou d'énergie.
Unité : ms

Format du langage

1 instruction par ligne
commentaire avec # sur une ligne distincte
Les paramètres éventuels suivent des instructions séparées par des ,

Instructions

Plusieurs instructions sont disponibles pour vous aider à automatiser votre parcours utilisateur. Voici les préfixes des principales commandes :

application : liées au démarrage, à l'arrêt, à l'effacement, à l'installation ou à la désinstallation d'applications
assert : permettent de vérifier la présence d'un élément
browser : instructions spéciales permettant de gérer le navigateur pour les tests web
click : offrent plusieurs façons de cliquer sur des boutons par le texte, l'identifiant, la position, etc.
find : permettent d'entrer dans la hiérarchie des éléments de l'interface utilisateur pour naviguer facilement jusqu'à un élément spécifique
pause : pour interrompre le test pendant un certain temps
press : utiles pour activer des boutons spéciaux, comme les boutons du clavier ou les boutons physiques
scroll
swipe
wait utiles après un changement de page pour attendre que la page soit complètement chargée

Variables

Des variables peuvent être utilisées avec ${NOM_PARAMETRE}. Les variables sont utiles si une information est récurrente ou s'il s'agit d'un contenu sensible comme un identifiant, un mot de passe, etc.

Ils doivent être définis :

commande de lancement pour un test sur le Testbench
job.yml pour un test en local dans la section extras

Aucun caractère spécial n'est pris en charge dans le nom du paramètre
Pas d'espace dans le nom du paramètre

It is useful for pause duration for example. Here are 4 pause variable types we recommend to use:

Variable	Type d'étape associé	Fonction	Valeur usuelle (ms)

Variable	Type d'étape associé	Fonction	Valeur usuelle (ms)
`${PAUSEDURATION}`	Pause	Simuler le comportement de l'utilisateur Observer ce qui se passe sans aucune action	30000 (30 sec)
`${PAUSEAFTERLOAD}`	Chargement, Action, Scroll	A la fin d'une étape active	1000 (1 sec)
`${PAUSEAFTERACTION}`	Action	S'il y a plus d'une action, pour ne pas perturber les autres actions	500 (0,5 sec)
`${PAUSEAFTERSCROLL}`	Scroll	S’il y a plus d’un scroll, pour ne pas perturber les autres scroll	500 (0,5 sec)

These indications are just propositions, it is possible to adapt them for tests (PAUSEDURATION at 1000 ms during tests and at 30000 ms during measures) or for you specified needs.

Modèles

Pour pouvoir analyser le service et obtenir des mesures comparables avec notre Ecoscore, certaines bonnes pratiques doivent être suivies dans la rédaction du GDSL.

Démarrage d'une application

Dans cette partie du test, nous allons successivement :

Nettoyer notre application et s'assurer qu'elle est arrêtée
Effectuer une mesure de référence de l'appareil
Mesurer le lancement de l'application
Faire une mesure de pause pour analyser l'application au repos

Démarrage d’un site web

Nous utilisons le navigateur Chrome avec le package com.android.chrome pour cet exemple. Par défaut, les méthodesbrowser utilisent Chrome, mais il est possible de définir un autre navigateur alternatif avec setBrowser.

Dans cette partie, nous allons successivement :

S'assurer que Chrome n'est pas démarré, puis l'ouvrir
Faire une mesure de référence de Chrome pour distinguer la consommation du navigateur de celle du site web
Entrer l'URL de notre site web
Vérifier que le texte que nous attendons après chargement n'existe pas déjà
Lancer le chargement de la page
Attendre la fin du chargement en attendant le texte
Effectuer une mesure de pause pour analyser la page au repos

Fin de parcours pour tous

Dans cette partie, nous faisons successivement :

Mesurer l'inactivité avec l'application en arrière-plan
Mesurer l'appareil après la fermeture de l'application

Comme décrit précédemment, mettre l'application en arrière-plan, fermer ou tuer (fermeture forcée) l'application n'est pas utile pour notre analyse. Ils ne se situent pas entre measureStart et measureStop et ne sont donc pas mesurés.