A jour

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

Description des instructions

Mots clés du langage

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

Formatage des instructions

• 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 .

Nommer les étapes

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

Implémentation du script

processus

Nous vous conseillons d’ajouter les étapes à votre fichier de test progressivement :

1. Je rajoute le mot clé startMeasure,Nom de l’étape dans le fichier de test (voir guide à l’étape 3)

2. Je rajoute la ou les instructions GDSL pour composer l’étape (de type click par exemple) (voir la documentation GDSL)

3. J’identifie sur l’application un texte qui doit apparaître à la fin de l’action ou du chargement

4. Je rajoute le texte attendu avec un mot clé du type 'wait'.

5. Je rajoute le mot clé stopMeasure pour finir la mesure

6. Je lance le test

Automatisation d'un chargement

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.

Astuce GDSL: passer les éléments de premier lancement

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

Quelques pistes si le test ne fonctionne pas

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.

Rechercher des élements

TODO intégrer http://wiki.kali/pages/viewpage.action?pageId=19661536

Etapes techniques standard

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.

Visuel récapitulant les bonnes pratiques GDSL

Voici un document montrant les bonnes pratiques GDSL, avec comme exemple l’application YouTube.