GDSL presentation

Owned by Maeva Rondeau
Jul 26, 2024
3 min read

 

In order to describe a user navigation scenario, a script must be written using the GDSL language. This allows to automate the navigation of your application on the measurement bench's smartphones, and to take measurements along the scenario.

Basic structure

In the script file, each step is built according to the same GDSL command model :

startMeasure,Step name GDSL instructions (input, click, scroll, check application display, pause, etc.) StopMeasure

Every instruction between measureStart and measureStop will be measured and everything outside will be ignored.

The smartphones on the Test bench are configured in English only. This must be taken into account when creating the script (texts detected in English, buttons in English, etc.).

Standard technical steps

  • Reference

    • at the beginning of the script

    • allows measurement of smartphone without the application or browser without the site

  • Background:

    • at the end of the script

    • measure of the application in background then killed.

Steps types

There are 4 types of steps used and currently indicated in prefix of step name:

  • Load : CHRGT_

  • Action : ACTION_

  • Scroll : SCROLL_

  • Pause : PAUSE_

Load :

  • Prefix of step name : CHRGT_

  • Ended by waiting for an element in the new view (use of a keyword starting with Wait)

measureStart,CHRGT_example pressEnter waitUntilText,Accept cookies pause,1000 measureStop

Action :

  • Prefix of step name : ACTION_

  • Typical use is an action with doesn’t result in the display of a new view

  • Several actions can be grouped if it makes a functional sense

measureStart,ACTION_example clickByText,Accept cookies pause,500 clickById,onetrust-accept-btn-handler pause,1000 measureStop

Scroll :

Pause :

  • Prefix of step name : PAUSE_

  • Typical use is to observe the behaviour of the page without user action to detect unusual data or energy consumption

  • Unit : ms

Language format

  • 1 instruction by line

  • comment with # on a separate line

  • eventual parameters follow instruction separated by ,

Instructions

Several instruction are available to help you to automate your user journey. Here are the prefix of the main commands:

  • application instructions are related to start, kill, clear, install or uninstall apps

  • assert instructions allow to check the presence of an element

  • browser instructions are special instructions to manage browser for web tests

  • click instructions offer several way to click on buttons by text, id, position, etc

  • find instructions let you enter in UI elements hierarchy to easily browse to a specific element

  • pause to pause test during a certain amount of time

  • press instructions are useful to activate special buttons, as keyboard or physical buttons

  • scroll instructions

  • swipe instructions

  • wait instructions are helpful after a page change to wait a page to be fully loaded

Variables

Variables can be used with ${PARAMETERNAME}. Variables can be useful if an information is recurrent or if it is sensitive content as an ID, a password, etc.

They have to be defined in:

  • launch command for Testbench test

  • job.yml for local test in extras section

  • No special characters supported in parameter name

  • No spaces in parameter name

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

Variable

Location

Function

Usual value (ms)

Variable

Location

Function

Usual value (ms)

${PAUSEDURATION}

Pause step

  • Simulate the user behaviour

  • Observe what it’s happening without any action

30000 (30 sec)

${PAUSEAFTERLOAD}

Load, Action, Scroll step

  • At the end of an active step

1000 (1 sec)

${PAUSEAFTERACTION}

Action step

  • If there is more than one action, not to disturb other actions

500 (0,5 sec)

${PAUSEAFTERSCROLL}

Scroll step

  • If there is more than one scroll, not to disturb other 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.

Templates

To be able to analyse the service and to obtain comparable measurements with our Ecoscore, some good practices has to be followed in GDSL redaction.

Start for an application

Please update MYPACKAGE and MYTEXT with your data.

In this part, we successively :

  • Clear our application and ensure it is stopped

  • Do a reference measure of device

  • Measure app launch

  • Do a pause measure to analyse app in idle

Start for a website

We will use Chrome browser with package com.android.chrome for this example. By default, browser instructions use Chrome, but you can’t define an alternative browser with setBrowser.

At the beginning :

In this part, we successively :

  • Ensure Chrome isn’t started, then open it

  • Do a reference measure of Chrome to separate browser and website consumption

  • Enter the URL of our website

  • Verify the text we are waiting for after loading doesn’t already exist

  • Launch page loading

  • Wait for loading end by waiting for the text

  • Do a pause measure to analyse the page in idle

End for all

In this part, we successively :

  • Measure idle with application in background

  • Measure our device after application was close by

Â