Afin de décrire un scénario de navigation utilisateur, un script doit être rédigé en utilisant le langage GDSL. Il permet d'automatiser la navigation dans votre application sur les smartphones du banc de mesure et de prendre les mesures tout au long de cette navigation.
**Attention** : Les smartphones du banc de test sont uniquement configurés en anglais. Il est nécessaire de prendre cela en compte lors de la réalisation du script (textes détectés en anglais, boutons en anglais, etc.).
Dans le fichier de script, chaque étape est construite selon le même modèle de commandes GDSL:
startMeasure,Nom de l’étape
Instructions GDSL de navigation (saisie, clic, scroll, vérification d’affichage sur l’application, pause, etc)
StopMeasure
Le langage GDSL est décrit ici
Vous retrouverez des mots clés débutant par un préfixe qui définit les types d’instructions :
Wait : méthodes permettant d'attendre la présence d'un élément
Click : méthodes permettant de cliquer sur un élément
SetText : méthodes permettant de saisir du texte dans un élément
Scroll : méthodes permettant de scroll ou de swipe sur la page
Application : méthodes relatives au lancement ou au kill d'applications
1 ligne = 1 instruction
un # en début de ligne commente la ligne (Impossible de mettre un commentaire en milieu de ligne)
Si une instruction échoue, le test s'arrête et échoue
Ajout d'un paramètre pouvant être passé par le CLI : ${NOMDUPARAMETRE}
Pas de caractères spéciaux supporté dans le nom du paramètre
Pas d'espace dans le nom du paramètre .
Chargement
Une action menant à l'affichage d'une nouvelle vue
Préfixe du nom de l'étape : CHRGT_
Déclenchée par un click sur un bouton ou sur un lien, par le lancement d'une application(applicationStart), ou directement en validant une url dans la barre du menu (pressEnter avec Url remplie précédemment avec browserGoToUrl)
Finie par l'attente d'un élément dans la nouvelle vue (Usage d'un mot clé commançant par Wait)
Pattern GDSL exemple : StartMeasure > Click > Wait > StopMeasure
Action :
Une action dans la vue courante n'amenant pas à l'affichage d'une nouvelle vue (mais potentiellement à une modification de la vue actuelle)
Préfixe du nom de l'étape : ACTION_ ou SCROLL_
Déclenchée par les mots clés GDSL Scroll, SetText ou les actions directement sur le smartphone (Screen et Device)
Finie par la fin de l'action elle-même (Par exemple la fin du Scroll directement).
Plusieurs actions peuvent être regroupé si il y a une cohérence fonctionnelle (Par exemple EnterText suivi de pressEnter pour passer un un champs de texte suivant)
Pattern GDSL exemple : StartMeasure > Scroll > StopMeasure
Pause :
Une étape sans action pour simuler une inaction de l'utilisateur (lecture, attente...)
Préfixe du nom de l'étape : PAUSE_
Pattern GDSL exemple : StartMeasure > Attente > StopMeasure
Nous vous conseillons d’ajouter les étapes à votre fichier de test progressivement :
Je rajoute le mot clé startMeasure,Nom de l’étape dans le fichier de test (voir guide à l’étape 3)
Je rajoute la ou les instructions GDSL pour composer l’étape (de type click par exemple) (voir la documentation GDSL)
J’identifie sur l’application un texte qui doit apparaître à la fin de l’action ou du chargement
Je rajoute le texte attendu avec un mot clé du type 'wait'.
Je rajoute le mot clé stopMeasure pour finir la mesure
Je lance le test
Lorsqu’il est souhaité d’attendre le chargement d'une vue il est important de respecter certaines bonnes pratiques.
Modèle pour une mesure de CHARGEMENT :
(Facultatif Note 1) vérifier que la vue/contenu à charger n'est pas déjà chargée
démarrer la mesure
effectuer l'action permettant de lancer le chargement
attendre l'affichage de la vue/contenu à charger
pause pour mesurer des chargements résiduels (Note 2)
arrêter la mesure
Note 1: Il est possible que l'élément attendu dans l'affichage soit aussi présent dans la page avant chargement. Il est possible d’attendre la disparition d'une vue à l'aide de waitUntilGone.
Note 2: L'étape pour mesurer les chargements résiduels est nécessaire car des ressources sont utilisées même si la vue est présente (Fin de chargement de certains éléments de la page, scripts...). Dans ce cas, on utilise la ligne pause,${PAUSEAFTERLOAD}
Si des actions préalables sont nécessaires pour déclencher le chargement alors elles doivent être extraites dans des mesures d'ACTION avant cette mesure de CHARGEMENT. Dans la mesure de CHARGEMENT, seule la dernière action permettant de déclencher le chargement doit être présente.
Parfois, il existe des éléments présents seulement au premier affichage d’un écran. Cela peut poser problème dans le cas où plusieurs tests sont effectués sur la même application.
Ainsi, nous vous conseillons d’utiliser les commandes suivantes : Les "waitUntilBeforeClick"
WaitUntilByTextBeforeClick
WaitUntilByDescBeforeClick
WaitUntilByTextExactBeforeClick
WaitUntilByIdBeforeClick
Le second paramètre de ces méthodes est un booléen optionnel qui permet s’il est à true de ne pas faire échouer le test sur cette instruction même si elle est fausse. La valeur par défaut de ce paramètre est false.
Ce test échouera si "OK" n'est pas trouvé : waitUntilByTextBeforeClick,OK
Ce test continue à la prochaine instruction si "OK" n'est pas trouvé : waitUntilByTextBeforeClick,OK,true
Si le test de fonctionne pas, vous pouvez consulter les fichiers du rapport d'erreur téléchargeable :
La ligne du fichier de test qui pose problème. Cela peut vous indiquer que l’élément sur lequel vous cherchez à cliquer ou que vous attendez n’est pas accessible ou présent.
L'image failed.png avec la copie d’écran du dernier écran avant erreur. Cela vous permet d’identifier rapidement le dysfonctionnement.
Les copies d’écran des étapes qui ont fonctionné avant le failed.
Le fichier dump.uix qui contient une extraction de la composition de l’écran. Vous pouvez rechercher dans ce fichier le texte que vous voulez automatiser ainsi que l’identifiant de cet élément.
Si le texte est présent dans l’écran failed et le dump.uix mais que vous avez une erreur, il est possible que l’élément ne soit pas accessible techniquement. Vous pouvez rechercher l’id de l’élément dans dump.uix et utiliser un mot clé d’automatisation de type clickById ou waitById.
TODO intégrer http://wiki.kali/pages/viewpage.action?pageId=19661536
Des étapes techniques standard sont obligatoires et garantissent le calibrage de l’écoscore, elles sont déjà intégrées dans le fichier de test script GDSL que vous avez téléchargé sur le portail en Etape 2 :
Référence (Etapes de type PAUSE) : permet la mesure du smartphone sans l’application ou du navigateur sans le site
Ecran d'accueil (Etape de type PAUSE) : Mesure de l’écran après le chargement. Dans le cas d’une application avec une connexion utilisateur, il s’agit de l’écran après connexion.
Background (Etape de type PAUSE) : Mesure de l’application en arrière-plan.
Chargement (Etape de type CHRGT ): Lancement de l'application. Dans le cas d’une application avec une connexion utilisateur, il s’agit de l’écran de connexion / login.
Selon le contexte, il est également nécessaire d’ajouter certaines étapes :
Si l’application nécessite une étape de connexion "longue" (le cas d’usage le plus fréquent représentant la saisie initiale d’un mot de passe qui reste enregistré à l’avenir), il vous faut ajouter cette étape :
Etape de chargement de l'application en mode connecté
Si l’application nécessite une étape de connexion, vous devez intégrer les étapes suivantes :
Etape Action (type ACTION_) : Saisie des informations de connexion
Chargement connecté (Type CHRGT_) : Chargement suite à la connexion
NB : Si ces étapes ne sont pas significatives en termes de fréquence d'usage et donc d'impact environnemental, elles peuvent être automatisées mais pas prises en compte dans la mesure. Par exemple pour le passage d’une fenêtre d’alerte. Le clic sur le bouton de fermeture de cette fenêtre doit être automatisé, par contre, les actions pour passer cette fenêtre, n’auront pas besoin d’être encadrées par un start et un stop.
Voici un document montrant les bonnes pratiques GDSL, avec comme exemple l’application YouTube.
