Protractor + AngularJS : Structure d’un projet industrialisé

Diviser pour mieux tester

Bienvenue dans la 3ème et dernière partie de notre série d’articles sur la découverte des tests Protractor ! Dans l’article précédent, nous avons vu pourquoi et comment séparer les jeux de données et les scripts de test. Aujourd’hui, nous poursuivons sur notre lancée en isolant la description des pages et en structurant les dossier du projet.

  1. Installation et exemple de script
  2. Gestion des jeux de données et des dépendances du projet
  3. Structure d’un projet industrialisé

Gestion du référentiel d’objets avec le Page Object Model

Qu’est-ce que le Page Object Model ?

Le Page Object Model est un design pattern (ou patron de conception) qui consiste à regrouper en une même classe les identificateurs des composants web avec lesquels on souhaite intéragir, ainsi que les méthodes associées à ces composants. Le Page Object Model joue le même rôle dans les projets Selenium que l’Object Repository dans les projets UFT ou Katalon par exemple.

Dans les articles précédent, nous interagissons avec la page d’accueil du site d’Angular. Si nous nous servons d’un objet page pour la décrire, cela donne :

var SiteAngularPageAccueil = function() {
    this.champ_nom = element(by.model('yourName'));
    this.message_salutations = element(by.xpath("//div[contains(@class, 'well')]//h1"));

    this.entrerPrenom = function(prenom) {
        this.champ_nom.sendKeys(prenom);
    };
};

module.exports = SiteAngularPageAccueil;

La méthode entrerPrenom est vraiment simpliste ; en pratique, on pourrait s’en passer. Nous avons choisi de la créer simplement pour fournir un exemple d’utilisation de méthode d’objet.

Enregistrons ce code dans un fichier site-angular-page-accueil.js, que nous plaçons dans un dossier « pages ».

Utilisation de l’objet page dans le script

Mettons à présent à jour le cas de test en appelant l’objet page et en interagissant avec elle :

var donnees = require('./jeu-de-donnees-demo.js');
var using = require('jasmine-data-provider');
var SiteAngularPageAccueil = require('../pages/site-angular-page-accueil.js');

describe("Suite de test de la feature qui dit bonjour", function() {

    var pageAccueil = new SiteAngularPageAccueil();

    beforeEach(function () {
        browser.get(browser.baseUrl);
    });

    using(donnees.prenoms, function (data, description) {
        it("Chaîne de type " + description, function () {
            testMessageSalutations(data.prenom);
        });
    });

    using(donnees.faux_positif, function (data, description) {
        it("Si je rêvasse en écrivant mon script de test, j'obtiens un faux positif", function () {
            testMessageSalutations(data.prenomSaisi, data.prenomVoulu);
        });
    });

    function testMessageSalutations(prenomSaisi, prenomVoulu){
        pageAccueil.entrerPrenom(prenomSaisi);
        var prenomAVerifier = (prenomVoulu ? prenomVoulu : prenomSaisi);
        expect(pageAccueil.message_salutations.getText()).toEqual('Hello ' + prenomAVerifier + '!');
    }

});

Nous avons également créé une fonction testMessageSalutations pour éviter au maximum la duplication entre les deux cas de test.

Le script est maintenant concis et exempt de toute redite ! A ce stade, notre script de test a atteint un niveau de maintenabilité satisfaisant. Il peut jouer une multitude de cas de test différents, et n’est plus soumis aux changements de l’interface du site web.

Exemple de structure de projet Protractor

Pour augmenter la lisibilité de votre projet, nous vous suggérons de ranger dans des répertoires séparés vos fichiers de configuration, vos pages, vos suites de tests et vos jeux de données.

Le nombre de suites de test augmentant, n’hésitez pas à créer des sous-dossiers. Dans vos fichiers de configuration, il sera d’autant plus simple de sélectionner tel ou tel ensemble de suites de tests. Par exemple :

exports.config = {
  seleniumAddress: 'http://localhost:4444/wd/hub',
  specs: ['../specs/front-office/*.js'],
    baseUrl: 'https://www.monsupersiteweb.nc',
    framework: 'jasmine2'
};

Ici, toutes les suites de test se trouvant dans /spec/front-office seront jouées.

Vous avez maintenant tout ce qu’il vous faut pour démarrer votre projet de tests Protractor sur de bonnes bases. A vous de jouer maintenant ! Et vous souhaitez rester encore un peu avec nous, voici un petit bonus…

Bonus : le reporting Jasmine

Vous aurez beau écrire le plus beau code du monde, il y a peu de chances que celui-ci suffise à émouvoir aux larmes votre chef de projet, client ou patron. Un reporting clair et documenté est indispensable pour communiquer sur l’exécution des tests. C’est pourquoi nous ne voulions pas vous quitter avant d’évoquer la librairie Jasmine2 Screenshot Reporter.

Ajout de la librairie

Dans votre package.json, déclarez la dépendance voulue :

"dependencies": {
  // [...]
  "protractor-jasmine2-screenshot-reporter": "0.3.5"
}

Mise à jour du fichier de configuration

Il est maintenant nécessaire d’appeler la librairie dans le fichier de configuration :

var HtmlScreenshotReporter = require('protractor-jasmine2-screenshot-reporter');

var reporter = new HtmlScreenshotReporter({
    dest: '../reports',
    filename: 'reporting-' + getDate(true) + '.html',
    reportOnlyFailedSpecs: false,
    captureOnlyFailedSpecs: true,
    showQuickLinks: true,
    reportTitle: "Rapport de tests automatisés du " + getDate() + "",
    reportFailedUrl: true,
    pathBuilder: function(currentSpec, suites, browserCapabilities) {
        return currentSpec.fullName + "--" + browserCapabilities.get('browserName');
    }
});

exports.config = {
  seleniumAddress: 'http://localhost:4444/wd/hub',
  specs: ['../specs/dis-bonjour.js'],
    baseUrl: 'https://angularjs.org',
    framework: 'jasmine2',

    beforeLaunch: function() {
        return new Promise(function(resolve){
            reporter.beforeLaunch(resolve);
        });
    },

    onPrepare: function() {
        jasmine.getEnv().addReporter(reporter);
    },

    afterLaunch: function(exitCode) {
        return new Promise(function(resolve){
            reporter.afterLaunch(resolve.bind(this, exitCode));
        });
    }
};

function getDate(dansNomFichier) {
    var today = new Date();
    var dd = today.getDate();
    var mm = today.getMonth() + 1;
    var yy = today.getFullYear();
    var hh = today.getHours();
    var min = today.getMinutes();

    if(dd<10) dd='0' + dd;
    if(mm<10) mm='0' + mm;
    if(hh<10) hh='0' + hh;
    if(min<10) min='0' + min;

    if(dansNomFichier){
        today = yy + '-' + mm + '-' + dd + '--' + hh + 'h' + min;
    } else {
        today = yy + '/' + mm + '/' + dd + ', ' + hh + ':' + min;
    }
    return today;
}

Explication du fichier de configuration

dest: '../reports'

Avec cette configuration de la variable dest, si votre fichier de configuration se trouve bien dans un sous-dossier dédié (/src/confs par exemple), un sous-dossier « reports » sera créé dans le dossier « src ». A l’intérieur de ce dossier seront créés les reportings au format html, ainsi que les screenshots.

A chaque lancement, son contenu sera supprimé. Si vous souhaitez conserver les résultats des tests d’un lancement à l’autre, mettez à true la variable preserveDirectory lors de l’instanciation de votre HtmlScreenshotReporter :

preserveDirectory: true,

Dans ce cas, un sous-dossier avec un nom aléatoire sera créé à l’intérieur du dossier « reports ».

filename: 'reporting-' + getDate(true) + '.html',

La variable filename, sans surprise, définit le titre du fichier de reporting ; ici, nous avons choisi de lui ajouter la date et l’heure (voir la fonction « getDate » en bas du fichier).

reportOnlyFailedSpecs: false,
captureOnlyFailedSpecs: true,

Les variables reportOnlyFailedSpecs et captureOnlyFailedSpecs permettent de consigner tous les cas de tests dans le reporting, mais de ne prendre un screenshot qu’en cas d’échec.

showQuickLinks: true,

La variable showQuickLinks est à false par défaut. Ici, elle permet de générer au début du fichier des liens vers chacun des cas de test en échec. Pratique quand on se retrouve avec une très grande campagne de test.

reportTitle: "Rapport de tests automatisés du " + getDate() + "",

La variable reportTitle configure le titre qui s’affiche en haut du rapport html.

reportFailedUrl: true,

La variable reportFailedUrl permet d’afficher dans le reporting l’URL sur laquelle l’échec a eu lieu.

pathBuilder: function(currentSpec, suites, browserCapabilities) {
    return currentSpec.fullName + "--" + browserCapabilities.get('browserName');
}

La fonction pathBuilder permet de définir le nom des fichiers de screenshot. Ici, le nom est composé du titre du cas de test et du nom du navigateur.

Notre série sur Protractor est maintenant terminée. En espérant qu’elle vous aura apporté des éléments, nous sommes curieux d’avoir vos retours sur ce framework.

Pour en savoir plus sur les différents outils de tests automatisés ainsi que leurs usages et leurs bonnes pratiques, rendez-vous ici !

Protractor + AngularJS : installation et exemple de script

Note préalable : cet article date de 2017 mais a été revu en décembre 2020. Les scripts qu’il contient sont à jour à cette date. Bonne lecture !

Pourquoi Protractor ?

Protractor est un framework de test dont le but est de faciliter l’automatisation des tests fonctionnels pour les SUT (system under test) développés avec AngularJS. Il se base sur WebdriverJS, l’implémentation Javascript de Selenium, et intègre des solutions telles que Jasmine, qui permet de rédiger des tests en BDD (behavior-driver development), ou encore Cucumber et Mocha.

Protractor reconnaît les concepts AngularJS, tels que les attributs ng-repeaterng-controllerng-model… qui sont employés dans le code HTML pour manipuler les composants web.

D’autres frameworks de test sont bien sûr capables d’automatiser les applications AngularJS, mais utiliser Protractor améliore :

  • la rapidité d’écriture des tests
  • leur maintenabilité (passer par des xpath ou des sélecteurs CSS serait moins robuste)
  • leur lisibilité

Inversement, il est possible d’utiliser Protractor pour automatiser les tests d’une application non-AngularJS (voir cet article).

Nous vous proposons donc une série d’articles sur Protractor :

  1. Installation et exemple de script (le présent article !)
  2. Gestion des jeux de données et des dépendances du projet
  3. Structure d’un projet industrialisé

Nous utilisons ici la version 5 de Protractor.

Installation de Protractor

Voici quelques prérequis avant de pouvoir vous lancer dans les tests avec Protractor :

  • Avoir NodeJS installé sur sa machine (ce qui permet d’utiliser npm)
  • Pour l’installation, lancer les commandes suivantes :

npm install -g protractor
webdriver-manager update

  • Pour démarrer le serveur Selenium sur votre machine, démarrer une invite et lancer la commande :

webdriver-manager start

EDIT de décembre 2020 : Si à ce moment-là votre invite de commande vous indique que « java n’est pas reconnu en tant que commande interne ou externe », assurez-vous que votre PATH contient bien le chemin vers le dossier « bin » qui se trouve dans le dossier où est installé Java. Ca peut ressembler à C:Program FilesJavajdk-xx.x.xbin. (Fin de l’EDIT)

Par défaut, le serveur Selenium est lancé sur le port 4444. Vous pouvez changer le port en ajoutant un paramètre à la commande.

webdriver-manager start –seleniumPort 5555

Tant que vous utiliserez Protractor sur votre machine, ne fermez pas cette invite.

Pour vérifier que le serveur est bien lancé, rendez-vous sur http://localhost:4444/wd/hub (en changeant le port si besoin).

Exemple de test Protractor

Au cours de ce test, nous allons interagir avec un composant de la page d’accueil du site d’AngularJS.

Sur cette page, quand l’utilisateur entre une chaîne de caractères dans le champ « Name », la phrase de salutations se met immédiatement à jour. C’est cette fonctionnalité que nous allons tester.

Dans l’inspecteur, on voit que l’attribut « ng-model » du champ de saisi a pour valeur « yourName » ; c’est cet attribut qui va nous servir lors de l’identification de l’objet.

Nous avons maintenant besoin de 2 fichiers : le fichier de configuration, qui permet de lancer le test, et le script de test en lui-même.

Un script de test Protractor

Le fichier de test (appelons-le dis-bonjour.js) a le contenu suivant :

describe("Suite de test de la feature qui dit bonjour", function() {

  it("Test 1 : si je renseigne mon nom, la feature me dit bonjour", function() {
    browser.get(browser.baseUrl);
    element(by.model('yourName')).sendKeys('Zoé');
    var message= element(by.xpath("//div[contains(@class, 'well')]//h1"));
    expect(message.getText()).toEqual('Hello Zoé!');
  });

  it("Test 2 : si je rêvasse en écrivant mon script de test, j'obtiens un faux positif", function() {
    browser.get('https://angularjs.org');
    element(by.model('yourName')).sendKeys('Chloé');
    var message= element(by.xpath("//div[contains(@class, 'well')]//h1"));
    expect(message.getText()).toEqual('Hello Zoé!');
  });

});

EDIT de décembre 2020 : si vous souhaitez lancer vos tests sur une application qui n’est pas une application Angular, il est important d’intégrer la commande suivante à vos scripts, afin qu’elle empêche Protractor d’attendre qu’Angular soit correctement chargé : browser.waitForAngularEnabled(false). (Fin de l’EDIT)

Structure et la syntaxe du script Protractor

Conformément à la syntaxe Jasmine, la suite de test se déroule dans la fonction « describe ». Chaque test est détaillé dans une fonction « it ».

L’URL de base (browser.baseUrl) est définie dans le fichier de configuration. Rien n’empêche bien sûr d’utiliser une autre URL (comme par exemple dans le deuxième test du fichier).

Fichier de configuration Protractor

Et maintenant, le fichier de configuration qui va permettre de lancer ces deux courts tests. Appelons-le conf.js. Celui-ci est minimaliste et ne contient que l’adresse du serveur Selenium, le chemin du script de test, et l’URL du SUT.

exports.config = {
  seleniumAddress: 'http://localhost:4444/wd/hub',
  specs: ['dis-bonjour.js'],
  baseUrl: 'http://monsupersiteweb.nc'
};

Lancer les tests Protractor en ligne de commande

Maintenant, pour lancer les deux tests contenus dans le script, il suffit d’ouvrir une invite de commande, de se positionner dans le dossier contenant les deux fichiers et de lancer la commande :

protractor conf.js

Remarque : il est possible de changer la baseUrl au moment du lancement du test, ce qui donne :

protractor --baseUrl=http://monsupersiteweb.nc conf.js

Ce qui est pratique si l’on souhaite faire tourner les tests sur différents environnements par exemple.

Par défaut, c’est un navigateur Google Chrome qui s’ouvre et exécute les scénarios définis dans le script de test Protractor. Ce qui donne, dans notre cas, le résultat suivant :

Plutôt clair, non ?

Protractor et les IDE

Pour l’écriture des tests, un simple éditeur de texte suffit pour si l’on veut juste tester les commandes de bases et se faire une idée rapide des possibilités du framework. Mais pour industrialiser un projet de tests automatisés, il est bien sûr préférable d’utiliser un IDE. Il existe des plugins Protractor pour IntelliJ et pour Eclipse. Il est à noter que celui d’IntelliJ n’est disponible que si l’on dispose d’une licence commerciale (version Ultimate, et non Community). Il est possible d’essayer gratuitement la version Ultimate pendant 30 jours.

Protractor avec Eclipse

EDIT de décembre 2020 : le bug évoqué est peut-être résolu depuis, nous n’avons pas réessayé. (Fin de l’EDIT)

Configurer le plugin Protractor d’Eclipse nécessite quelques manipulations en plus (détaillées dans cette vidéo). Attention toutefois, en mars 2017 un bug empêchait le plugin de tourner correctement.

Une erreur s'affiche : "SyntaxError: Unexpected token ..."

En effet, la configuration de Run Protractor utilise par défaut la version 4.2.4 de NodeJS, alors que 2 versions majeures ont été publiées depuis !

Indiquer un chemin vers un exécutable plus récent est possible, mais provoque une erreur : « Error while launching client file, Cannot find node install path node-native ».

A suivre donc… Pour la suite de cette série d’articles, nous utiliserons donc la solution d’évitement : passer sur la version d’essai d’IntelliJ.

Protractor avec IntelliJ

  1. Créez un projet.
  2. Dans le fichier src, placez vos 2 fichiers (test et configuration).
  3. Créer une « Run configuration » Protractor
  4. Renseigner le chemin vers le fichier de configuration. Les chemins vers NodeJS et Protractor sont, normalement, trouvée automatiquement.

Voilà ce à quoi ressemblent les résultats d’exécution :

Protractor avec Visual Studio Code

Ce paragraphe est un EDIT de décembre 2020.

Ouvrez une nouvelle fenêtre de Visual Studio code ; dans la partie de droite de l’écran s’affiche un encart appelé « Customize ». Dans la partie « Tools and languages », faites en sorte que VSC supporte JavaScript, TypeScript, et si vous le sentez vous pouvez également installer d’autres extensions telles que Mocha Snippets ou Protractor Snippets, qui proposent des raccourcis permettant d’accélérer la saisie des scripts de test Protractor.

Cette manipulation décuplera votre productivité par l’autocomplétion !

(Fin de l’EDIT)

On se retrouve demain pour aller plus loin dans l’exploration de Protractor. Car on ne veut pas seulement créer un test, on veut pouvoir le jouer avec une multitude de jeux de données !

Protractor + AngularJS : Gestion des jeux de données et des dépendances du projet

Le problème du tas

Au commencement d’un projet de test, surtout si celui est censé n’être qu’un POC ou un tout petit projet, on a tendance à coder les jeux de données en dur dans le script et à télécharger les librairies au fil de l’eau. Trèèès bieeeen… tant que ça ne dure pas ! Car comme écrivait Beckett en 1957 :

Les grains s’ajoutent aux grains, un à un, et un jour, soudain, c’est un tas, un petit tas, l’impossible tas.

Un tas qu’il n’est pas facile à gérer quand on revient sur le projet quelques mois plus tard, ou qu’un collègue doit travailler dessus pendant qu’on est en vacances à Ouvéa.

Aujourd’hui donc, on vous donne des pistes pour gérer les jeux de données et les librairies de votre projet. Cet article est le deuxième de notre série sur les test Protractor :

  1. Installation et exemple de script
  2. Gestion des jeux de données et des dépendances du projet
  3. Structure d’un projet industrialisé

Quels problèmes souhaitons-nous éviter ?

Pour comprendre l’intérêt de ce qui va suivre, penchons-nous sur ce petit texte :

« Vous a-t-on déjà parlé de la Nouvelle Calédonie, un archipel du Pacifique dont la capitale est Nouméa, qui compte quelque 300 000 habitants et dont la devise est le franc pacifique ? Recherchez le taux de change actuel entre le franc pacifique et l’euro. La Nouvelle Calédonie, un archipel du Pacifique dont la capitale est Nouméa, qui compte quelque 300 000 habitants et dont la devise est le franc pacifique, possède un lagon exceptionnel, classé au patrimoine mondial de l’Unesco. Recherchez depuis quand c’est le cas. L’oiseau fétiche de la Nouvelle Calédonie, un archipel du Pacifique dont la capitale est Nouméa, qui compte quelque 300 000 habitants et dont la devise est le franc pacifique, est le cagou, un oiseau à huppe presque incapable de voler. Trouvez d’où lui vient son nom. Il est très agréable de vivre en Nouvelle Calédonie, un archipel du Pacifique dont la capitale est Nouméa, qui compte quelque 300 000 habitants et dont la devise est le franc pacifique, cependant il faut tenir compte du fait que ce coin de paradis se trouve à quelque 16 000 kilomètres de la métropole. Vérifiez que Nouméa et la ville française la plus éloignée de Paris. »

Du point de vue du lecteur, ce texte est totalement redondant et illisible. Vous auriez préféré ne lire chaque information qu’une seule fois, et votre cerveau aurait rattaché chacune de ces données à la variable « Nouvelle Calédonie », qu’il possédait peut-être déjà. Cela vous aurait permis de vous concentrer davantage sur les questions.

Si l’on se place du point de vue de l’auteur, au prochain recensement de la Nouvelle Calédonie, il faudra qu’il remplace chaque occurrence de « 300 000 » par, peut-être, « 320 000 » ou « 350 000 ». Au fil du temps, le texte s’allongeant les mises à jour deviendront de plus en plus fastidieuses.

Ce texte est comme un projet de test mal architecturé, qui en un seul bloc fournit une multitude d’informations souvent répétitives sur le SUT, et sollicite dans la foulée des vérifications.

La bonne pratique

Autant que possible, nous allons donc prendre soin de séparer les moments où :

  • on configure les données du test,
  • on donne des informations sur le SUT (identificateurs d’objets, descriptions de page),
  • on effectue des vérifications (tel élément est présent, tel texte est visible).

Gestion des données de test avec jasmine-data-provider

En automatisation des tests, une bonne pratique consiste à séparer les données du test et les scripts d’exécution. Cela augmente la maintenabilité des tests et permet aussi à tout un chacun de mettre à jour le jeu de données, sans avoir à connaître l’architecture du projet sur le bout des doigts.

Qui plus est, cela permet d’alimenter un même script avec X jeux de données, et d’augmenter la couverture des tests à moindre coût .

Avec Protractor, le plugin jasmine-data-provider par exemple permet d’implémenter cette séparation données/scripts.

Pour l’utiliser dans l’exemple précédent, nous allons suivre trois étapes.

1) Importer jasmine-data-provider

A la racine de votre projet, téléchargez le package jasmine-data-provider :

npm install jasmine-data-provider --save-dev

Un dossier node_modules va se créer à la racine de votre projet et contenir le paquet voulu.

Il existe une autre manière de procéder, que nous verrons plus tard. En attendant, veillez juste à ne pas répertorier le dossier node_modules dans votre outil de versionning. Par exemple, si vous utilisez Git, ajoutez la ligne « node_modules/ » dans votre fichier .gitignore et votre projet restera léger comme une plume.

2) Modifier le fichier de configuration

Ici, il n’y a qu’une ligne à ajouter :

framework: 'jasmine2'

3) Créer un fichier de données

Ce fichier doit être au format .js. Appelons-le jeux-de-donnees-demo.js.

Ici, nous avons 2 séries de jeux de données. La première comprend 5 jeux de données avec chacun 1 paramètre : le prénom. Outre les caractères spéciaux courants dans la langue française, nous voulons savoir si d’autres caractères spéciaux (ici, arabes et chinois) apparaissent correctement, et si les scripts Javascript sont traités comme du simple texte.

La deuxième série, destinée à générer un faux positif,  a 2 paramètres : le prénom saisi et le prénom attendu.

'use strict';

 module.exports = {
    prenoms: {
        'ASCII': { prenom: 'Robert' },
        'Caractères spéciaux français': { prenom: 'Rôbértà' },
        'Caractères spéciaux arabes': { prenom: 'صباح الخير' },
        'Caractères spéciaux chinois': { prenom: '安' },
        'Script': { prenom: "<script type='text/javascript'>alert('Faille 1');</script>"}
    },

    faux_positif: {
        'Fail !': { prenomSaisi: 'Chloé', prenomVoulu: "Zoé" }
    }
}

La mention « use strict » est facultative mais conseillée, car elle garantit que le code est bien formé.

4) Exploiter le fichier de données au sein du script de test Protractor

Nous allons un peu transformer le script de l’article précédent :

var donnees = require('./jeu-de-donnees-demo.js');
var using = require('jasmine-data-provider');

describe("Suite de test de la feature qui dit bonjour", function() {

    beforeEach(function () {
        browser.get(browser.baseUrl);
    });

    using(donnees.prenoms, function (data, description) {
        it("Chaîne de type " + description, function () {
            element(by.model('yourName')).sendKeys(data.prenom);
            var message= element(by.xpath("//div[contains(@class, 'well')]//h1"));
            expect(message.getText()).toEqual('Hello ' + data.prenom + '!');
        });
    });

    using(donnees.faux_positif, function(data, description) {
        it("Si je rêvasse en écrivant mon script de test, j'obtiens un faux positif", function() {
            element(by.model('yourName')).sendKeys(data.prenomSaisi);
            var message= element(by.xpath("//div[contains(@class, 'well')]//h1"));
            expect(message.getText()).toEqual(data.prenomVoulu);
        });
    });
});

Au début du script, on indique que l’on souhaite utiliser jasmine-data-provider, ainsi que le chemin de notre fichier de données.

Pour le premier cas de test, on déclare qu’on va utiliser la série de données intitulée « prenoms », ce qui nous donne accès aux données (« data ») ainsi qu’au nom de chaque jeu de données (« description »). Pour accéder au paramètre « prenom », il suffit d’indiquer « data.prenom ».

Nous avons également choisi de factoriser, entre les deux cas de test, la première étape, à savoir la consultation de l’URL de base du projet :

beforeEach(function () {
    browser.get(browser.baseUrl);
});

Au lancement, la même méthode de test sera lancée autant de fois qu’il y a de jeux de données, avec les paramètres correspondants.

Gestion des données de test avec csv-parse

NB : cette section a été ajoutée en décembre 2020.

Si vous préférez exploiter des fichiers CSV, c’est possible aussi en utilisant le module csv-parse.

Commencez par installer ce module avec la ligne de commande suivante :

npm install csv-parse

Dans cet exemple, nous utiliseront un fichier de jeu de données nommé donnees.csv, et qui contiendra les informations suivantes :

login,password,prenom
admin,M0t2p@sseAdmin,Amira
user,M0t2p@sseUser,Boniface

Nous allons appeler ce jeu de données dans le script suivant, qui vérifie qu’à l’authentification sur un certain site web, on se retrouve sur une page où l’on voit la mention « Bonjour » suivie du prénom de l’utilisateur.

'use strict';
let fs = require('fs'); // fs pour file system. Il n'y a rien besoin d'installer pour utiliser cela.
const parse = require('csv-parse/lib/sync');
let a = fs.readFileSync('donnees.csv');

const testdata = parse(a, {
    columns: true,
    skip_empty_lines: true
})

describe('Suite de tests d'authentification', function () {
    for (let i of testdata) {       
        it('Connexion et affichage de la page d'accueil', async function () {
            browser.get(browser.baseUrl)
            console.log("Saisie du login : " + i.login)
            element(by.id('input-login-username')).sendKeys(i.login)
            console.log("Saisie du mot de passe : " + i.password)
            element(by.id('input-login-password')).sendKeys(i.password)
            element(by.id('button-login-submit')).click()
            console.log("Vérification de l'affichage des salutations")
            var message= element(by.xpath("//div[contains(@class, 'h1')]"))
            expect(message.getText()).toEqual('Bonjour ' + i.prenom)
        });
    }
});

Et voilà !

(Fin de l’EDIT)

Gestion des dépendances avec le package.json

Nous venons de voir comment rapidement ajouter la dernière version de jasmine-data-provider. Mais cette façon de procéder n’est pas la meilleure au sein d’un projet industrialisé, où certaines problématiques se posent :

  • Comment alléger le projet de tests Protractor ?
  • Comment faire en sorte que tous les membres de l’équipe utilisent la même version de jasmine-data-provider ?

C’est à ce moment qu’intervient le fichier package.json. Ce fichier, que l’on va placer à la racine du projet, contient une liste de tous les packages dont a besoin le projet. Si vous venez de l’univers Maven, cela devrait vous rappeler le pom.xml, ou le build.gradle si vous venez de la constellation Gradle.

Et la bonne nouvelle, c’est que npm propose une façon rapide de générer un fichier package.json ! Pour ce faire, placez-vous à la racine de votre projet, et tapez la commande :

npm init

Une série de questions sur votre projet vous est posée. Des réponses par défaut vous sont proposées. Pour un petit projet tel que nous venons d’en créer, l’opération dure moins d’une minute.

La valeur entrée pour le « main » dans l’utilitaire n’importe pas du tout ici. Vous pourrez la supprimer de votre package.json.

Pour le « test command », entrez la commande suivante :

node_modules/.bin/protractor src/conf-demo.js

A ce stade, le fichier généré ressemble à cela :

{
  "name": "hightest-demo",
  "version": "1.0.0",
  "description": "Un petit projet de démo pour présenter les tests Protractor",
  "dependencies": {
    "jasmine-data-provider": "^2.2.0"
  },
  "devDependencies": {},
  "scripts": {
    "test": "protractor src/conf-demo.js"
  },
  "author": "",
  "license": "ISC"
}

L’utilitaire a automatiquement détecté le package jasmine-data-provider, et l’a donc déclaré dans le package.json. Vous avez remarqué ce petit accent circonflexe juste avant le numéro de version ? Il fait partie de la syntaxe de versionning de npm (que nous vous invitons à découvrir ici) et permet ici de bénéficier des mises à jour non-majeures du paquet.

Cependant, nous vous conseillons autant que possible de fixer les versions de vos projets, afin d’être sûr d’avoir des configurations similaires d’une machine à l’autre.

Vérifions que tout marche bien : supprimons sauvagement le dossier node_modules créé précédemment, et lançons la commande « npm install » à la racine du projet. Et hop, le dossier réapparaît.

De bonnes fondations sont posées, mais il reste encore quelques éléments à prendre en compte pour que le projet soit industrialisable. A demain pour aller encore plus loin avec votre projet de test Protractor !

Découvrez nos autres séries d’articles !

Notre saga du test audiovisuel

Notre série dédiée aux tests de sécurité

Le kit de secours métaphorique du testeur agile

Sondez votre code avec SonarQube

Quoi sert SonarQube ?

SonarQube est un outil d’analyse statique qui a pour but de mesurer la qualité du code d’un applicatif. Pour un projet donné, il fournit des métriques portant sur la qualité du code et permet d’identifier précisément les points à corriger (code mort, bugs potentiels, non-respect des standards, carence ou trop-plein de commentaires…)

L’analyse SonarQube ne remplace en aucun cas les tests unitaires, mais permet d’identifier rapidement certains défauts du codes.

Lancer une analyse SonarQube sur un projet

Prérequis

Installer SonarQube (voir la documentation officielle).

Démarrer votre instance avec la commande :

service sonar start

Configurer l’analyse SonarQube

  • A la racine du projet, créer un fichier intitulé « sonar-project.properties ».
  • Compléter ce fichier avec le texte suivant :

sonar.projectKey=nom.du.projet

sonar.projectName=Nom du projet

# La version de votre projet, pas celle de SonarQube
sonar.projectVersion=1.0

# Définit l’emplacement des sources que SonarQube va analyser.
sonar.sources=.

# A décommenter si besoin
#sonar.sourceEncoding=UTF-8

  • Toujours à la racine du projet, lancer la commande « sonar-scanner ».

Fonctionnalités de SonarQube

Faisons le tour des principales features de SonarQube.

Analyse des résultats SonarQube

En supposant que SonarQube soit installé en local, les résultats de l’analyse seront consultables sur http://localhost:9000/sonar/. Chaque projet dispose d’un espace d’analyse dédié.

SonarQube classe les défauts logiciels selon 3 catégories :

  • Les bugs : anomalies évidentes du code. Impactent la fiabilité (reliability) de l’application.
  • Les vulnérabilités : faiblesses du code pouvant nuire au système. Impactent la sécurité de l’application.
  • Les « code smells » : anti-patrons (ou anti-patterns). Impactent la maintenabilité de l’application.

Qu’est-ce qu’un code smell ?

En peu de mots, du code qui sent le roussi ! Wikipedia donne quelques exemples de code smells. En général, SonarQube détecte davantage de code smells que de bugs ou de vulnérabilités.

Ecran d’accueil de SonarQube

Sur l’écran d’accueil d’un projet analysé par SonarQube se trouve un récapitulatif des grandes familles de défauts :

La mention « Passed » signifie que le projet satisfait les exigences minimum définies dans l’espace « Barrières qualité ». Les paramètres par défaut peuvent être adaptés.

Onglet « Défauts »

Dans cet onglet, chaque bug, vulnérabilité ou code smell est répertorié et détaillé dans une liste.

L’intérêt immédiat, orienté projet : tel un outil de bugtracking ou de gestion de tickets, cette liste permet de prioriser les points à traiter, d’évaluer leur temps de correction et de les affecter à un développeur. Le statut de chaque défaut est affiché. Les options du projets, tels que l’utilisateur affecté par défaut, peuvent être configurés (onglet « Configuration » -> « Configuration du projet »).

En se positionnant en vue « Effort », on peut également voir le temps total que prendrait la correction de tous les défauts du code, ce qui peut faciliter la planification du travail d’un développeur lors d’un sprint par exemple.

Le second intérêt, orienté humain : comme chaque défaut comporte une explication détaillée et des pistes d’amélioration, le développeur est susceptible de monter en compétence et d’améliorer à long terme la qualité de son code.

Onglet « Mesures »

On y trouve des infos supplémentaires, plus générales, telles que la complexité du projet et le pourcentage de commentaires (20% étant habituellement reconnu comme un bon pourcentage). Contrairement à l’écran précédent, celui-ci n’est pas très bavard : à l’utilisateur de trancher si le taux de complexité est acceptable, par exemple. Pour en savoir plus sur les méthodes de calcul de la complexité, rendez-vous ici.

Onglet « Code »

Cet onglet est particulièrement pratique. Il permet de visualiser, fichier par fichier, les problèmes identifiés par SonarQube. Le code est intégralement affiché, avec des icônes au niveau des lignes posant problème.

Onglet « Tableau de bord »

Sur cette page sont rassemblées un grand nombre de métriques utiles pour communiquer sur la qualité du code. Les dashboards sont configurables selon un grand nombre de paramètres.

Penchons-nous maintenant sur le cœur de SonarQube, à savoir la définition des règles de qualité du code.

Gestion des règles SonarQube

Liste des règles

La liste exhaustive des règles associées aux défauts est disponible à cette adresse : http://localhost:9000/sonar/coding_rules.

Dans cet espace, il est possible de modifier la sévérité associée à chaque défaut. La détection de certains défauts peut aussi être désactivée.

Adapter les règles SonarQube existantes

Le contenu de certaines règles peut être configuré. Par exemple, la règle de nommage des variables locales en Java est vérifiée grâce à une expression régulière qui peut être changée :

Créer des règles SonarQube à partir d’un modèle (template)

Dans la liste des règles, cochez la case « Montrer uniquement les modèles ». A partir des modèles disponibles, vous pourrez créer de nouvelles règles.

Cette fonctionnalité est appréciable, mais il est dommage qu’il y ait si peu de modèles disponibles.

Création de nouvelles règles SonarQube

Il est possible de créer de nouvelles règles ex nihilo, mais la démarche est un peu plus lourde. Effectivement, il est nécessaire pour cela de créer un plugin SonarQube, et donc de maîtriser l’architecture des sources. Mode opératoire ici

Lancer une analyse SonarQube depuis Jenkins

Pour intégrer pleinement SonarQube à votre démarche d’intégration continue, nous vous suggérons de déclencher des lancements automatiques de l’analyse du code depuis Jenkins.

Pour ce faire :

  1. Installez le plugin SonarQube
  2. Générez un token dans l’interface SonarQube. Pour ce faire, une fois connecté, cliquez sur votre profil, puis sur « My account » et « Generate tokens ».
  3. Cliquez sur « Administrer Jenkins » puis sur « Configurer le système ». Dans la partie « SonarQube servers », entrez le token précédemment généré.
  4. Créez un job et configurez-le. Créez une étape de build « Lancer une analyse avec SonarQube Scanner ». Si vous ne remplissez pas les champs, ce sont les informations présentes dans le fichier sonar-project.properties qui seront prises en compte.

SonarQube et Jenkins Pipeline

Comme nous sommes de plus en plus nombreux à mettre en place ce type de jobs, voici un exemple de pipeline très simple réalisant une analyse SonarQube :

node {
    
    // Lors de cette phase de setup, nous récupérons dans le workspace de Jenkins les sources à analyser.
   stage(‘Setup’) {
       checkout([$class: ‘GitSCM’, branches: [[name: ‘*/master’]], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: ‘***clé générée par le plugin Credentials de Jenkins***’, url: ‘http://votresuperdepot.git’]]])
   }
   
    stage(‘Analyse SonarQube’) {
        // Le nom du « tool » et de l’argument de « withSonarQubeEnv » correspond au nom de l’instance SonarQube telle que défini dans Jenkins, dans « Configurer le système » > « SonarQube servers » > « Installations de SonarQube » > « Nom »       
        def scannerHome = tool ‘Sonar’;
        withSonarQubeEnv(‘Sonar’) {
            sh « ${scannerHome}/bin/sonar-scanner »
        }
   }

}

Ce qu’il ne faut pas attendre de SonarQube

Une exactitude indiscutable

Chaque défaut identifié par SonarQube doit être qualifié ; nul logiciel de test automatisé n’est à l’abri d’un faux positif.

Un substitut aux revues de code

Les analyses quantitatives fournies par SonarQube peuvent être trompeuses : ce n’est pas parce que 20% des lignes d’une application sont des commentaires que ceux-ci apportent de la valeur ajoutée. De même, ce n’est pas parce que SonarQube n’a pas identifié de duplicats que le programme ne comporte pas de redondances.

Même si SonarQube est très utile pour identifier des défauts spécifiques et donner une vision d’ensemble de la qualité du code, ses analyses gagnent à être complétées par une revue de code réalisée par un humain.

Conclusion

SonarQube permet d’identifier très rapidement les anomalies de code d’une application. Mais c’est une solution qui doit aller de pair avec une stratégie globale de qualité de code. Il faut connaître son applicatif afin de pouvoir analyser les reportings, trancher sur ce qu’il faut ou non corriger et fixer des seuils en-deçà desquels la qualité sera jugée insuffisante.

Vous aimerez peut-être…

La qualité de code en direct avec SonarLint !

SonarQube met son grain de sel dans Gitlab !

Katalon en 12 questions – réponses

Note du 6 janvier 2020 : Veuillez noter que cet article a été publié en mai 2017 et qu’il se base donc sur une version ancienne de Katalon. Cet outil a connu un essor impressionnant et propose des fonctionnalités qui n’existaient pas auparavant. Avant de prendre une décision quant à la mise en place de cet outil dans votre organisation, il sera pertinent de se pencher aussi sur des témoignages plus récents. Bonne lecture !

1) Qu’est-ce que Katalon ?

Katalon Studio est un framework basé sur Selenium et Appium, qui permet d’automatiser les tests web et mobiles. Dans cet article, nous découvrirons ensemble comment créer un cas de test mobile sur un téléphone Android.

Nous apporterons des réponses aux questions que nous-mêmes nous nous sommes posées avant de commencer avec Katalon. Notre SUT (system under test) sera l’application Observatoire des prix, qui permet de comparer produit par produit les tarifs pratiqués par les grandes surfaces en Nouvelle Calédonie. Développée par One Shot, cette application est une commande du Gouvernement de la Nouvelle Calédonie dans le cadre de la lutte contre la vie chère.

2) Quels systèmes d’exploitation Katalon supporte-t-il ?

Même si cela paraît étonnant, à ce jour, Katalon peut être installé sur Windows, Mac… mais pas sur Linux (source).

EDIT du 3 avril 2019 : Linux est maintenant pris en charge (en bêta), merci à un de nos lecteurs de nous l’avoir signalé par commentaire !

3) Katalon est-il gratuit ?

Développé d’abord en interne par KMS Technology, le projet a ensuite été partagé avec la communauté. L’outil est donc (et a priori restera) disponible gratuitement.

4) Comment débuter avec Katalon ?

Katalon nécessite quelques pré-requis, mais le démarrage se fait facilement. C’est une des exigences du produit, qui se veut accessible à tous.

Voici votre checklist de démarrage :

  • NodeJs est installé
  • Appium est installé (cela peut se faire indifféremment avant ou après l’installation de Katalon). Il faudra ensuite, dans l’interface Katalon, déclarer l’emplacement d’Appium.
  • Votre téléphone Android est branché à votre ordinateur via un câble USB.
    • Attention, votre téléphone ne doit pas être verrouillé par un mot de passe ou autre code durant l’exécution des tests. En l’état, Katalon ne permet pas de gérer le déverrouillage.
    • Autre point à vérifier : l’écran ne doit pas s’éteindre trop vite. Configurez votre téléphone pour que son écran s’éteigne au bout du seuil maximum.
    • EDIT du 8 février 2019 : ces points semble avoir avancé, voir la documentation dédiée au déverrouillage d’écran.
  • Le mode développeur est activé sur votre téléphone. Pour ce faire, il faut cliquer 7 fois sur le numéro de version (on dirait une formule magique ce n’est pas une blague !). L’emplacement de cette information dépend du téléphone, mais on peut trouver par exemple dans Paramètres > A propos de l’appareil > Infos logiciel.
  • Le débogage USB est autorisé sur votre téléphone. Rendez-vous dans les « Option de développement » qui apparaissent dans le menu principal lorsque le mode développeur est activé. Une popup apparaît pour demander si l’on peut faire confiance à l’ordinateur connecté. Si cette popup n’apparaît pas, débrancher et rebrancher le téléphone.

5) La documentation de Katalon est-elle suffisante ?

Les quelques modes opératoires qui existent sont clairs, mais ils sont peu nombreux. Le forum Katalon comble en partie ce manque. Extrêmement réactif, il nous a à chaque fois permis d’obtenir des réponses à nos questions en quelques heures seulement !

En-dehors du site officiel, il existe peu de ressources sur cet outil. A ce jour, aucune question n’a été posée sur Katalon sur le célèbre forum StackOverflow. EDIT du 27/03/2019 : ce n’est plus le cas ! Voici différentes étapes du développement du sujet sur ce site de questions-réponses.

Avril 2017 : le désert

En avril 2017, il n'y avait aucun post StackOverflow sur Katalon

Janvier 2018 : l’éclosion

En janvier 2018, il y avait 80 posts StackOverflow sur Katalon

Mars 2019 : l’explosion

En mars 2019, nous constatons qu'il y aura bientôt 600 posts StackOverflow sur Katalon

Juin 2020

(Au passage, on admire le nouveau mode nuit de StackOverflow… synonyme de confort supplémentaire et de meilleures performances environnementales !)

En juin 2020, on approche les 1000 posts

6) Les cas de test Katalon sont-ils maintenables ?

Quel sentiment magique ressent le testeur lorsque, pour la première fois depuis le début du projet, il lance son arsenal de tests automatisés…

Hélas, cette touchante émotion peut vite laisser place au désappointement si la maintenabilité n’a pas été au coeur de la conception de l’architecture des tests.

Heureusement, Katalon répond à cette problématique essentiellement grâce à 2 fonctionnalités :

  • le dépôt d’objets (object repository)
  • les mot-clés personnalisés (custom keywords)

Reconnaissance des objets avec l’Object repository

Comme avec UFT, que nous présentions précédemment, l’object repository permet de gérer en un même lieu tous les identificateurs d’éléments de l’interface. Un atout indispensable en cas de refonte de l’ergonomie. Au lieu de modifier chacun des tests utilisant un même objet, on ne modifie que la définition de l’objet ayant subi une modification.

Pour alimenter l’object repository, il faut utiliser l’un des deux outils de capture : « Spy Web » et « Spy Mobile ». L’utilisateur sélectionne alors, en s’aidant d’une preview, les objets qui l’intéressent. Pour ceux à qui cela fait peur, pas besoin de mettre le nez dans le code.

Le testeur peut ensuite cocher ou décocher les cases qu’il trouve les plus pertinentes.

Encapsulation d’actions avec les Custom keywords

Les custom keywords sont en fait des méthodes (au sens programmatique du terme) que l’on peut appeler au sein des cas de test. Prenons par exemple l’enchaînement d’actions permettant l’authentification d’un utilisateur : au lieu de copier-coller, au sein de chaque cas de test, qu’il faut :

  1. Vérifier que l’on se trouve sur la page d’authentification
  2. Entrer tel identifiant
  3. Entrer tel mot de passe
  4. Cliquer sur le bouton « Valider »
  5. Attendre que la page d’accueil apparaisse

Il suffit de créer un custom keyword qui prenne en paramètre l’identifiant et le mot de passe.

Cela améliore à la fois la lisibilité du test, car il y a moins d’étapes, mais aussi sa maintenabilité. Par exemple, si un jour une case « Se souvenir de moi » est ajoutée à cette page de connexion, il suffira d’ajouter une étape au custom keyword, et un paramètre pour choisir si l’on souhaite cocher la case ou non.

Notre conseil : bien réfléchir à l’organisation de ces custom keywords avant de se lancer à corps perdu dans l’automatisation des scripts de test. Sans cette étape, la scalabilité de votre projet risque d’en prendre un coup.

7) Katalon s’intègre-t-il avec Jenkins ?

Oui, on peut faire de l’intégration continue avec Katalon et Jenkins. Mais souvenez-vous… pas sur une machine Linux.

Dans l’interface de Katalon, cliquez sur le bouton « Build CMD », configurez votre exécution, puis copiez la commande générée.

Sur une instance Jenkins installée une machine Windows, créez un job free-style et ajoutez une étape de build « Exécuter une ligne de commande batch Windows ».

La commande à exécuter est la suivante :

cd chemin/vers/katalon.exe
[commande générée précédemment via Katalon]

Ce qui donne quelque chose comme ça :

Une limitation à noter

Les rapports de test sont stockés dans le dossier « Reports » consultable dans Katalon, et non pas dans le workspace de Jenkins. Nativement, un tel job ne permet pas d’en déclencher un autre (un fonctionnement courant dans une démarche d’intégration continue).

8) Puis-je lancer des tests automatisés sur iOS ?

Oui, mais seulement depuis un Mac (source).

9) Katalon s’interface-t-il avec des bugtrackers ou des outils de test management ?

A l’heure actuelle, Katalon s’interface avec Jira pour la gestion des anomalies et qTest pour la gestion des cas de test.

10) L’interface de Katalon est-elle user-friendly ?

C’est assez subjectif mais nous avons trouvé que oui. L’interface rappelle beaucoup celle d’Intellij.

L’outil a été conçu pour être utilisé aussi bien par des automaticiens que par des testeurs ne sachant pas programmer. Les cas de test peuvent donc être conçus en mode « manuel » ou en mode « script » (à noter que les scripts sont en Groovy).

A notre sens, utiliser cet outil peut être un bon moyen de s’initier en douceur aux joies du code. Mais il ne faut pas oublier que certaines fonctionnalités ne peuvent être exploitées pleinement qu’en mode script, par exemple les custom keywords.

A titre d’exemple, voici à quoi ressemble un cas de test en vue manuelle :

Et le même test en vue script :

Côté automatisation web, Katalon propose une fonctionnalité de capture-rejeu (ou playback) qui pourra vous rappeler Selenium IDE. Attention, il ne faut pas en abuser, car en tant que tels ces enregistrement sont un cauchemar pour la maintenance !

11) Existe-t-il une version de Katalon en français ?

Certaines organisations mettent un point d’honneur à utiliser des outils pouvant être configurés en français. Mais en l’occurrence, la réponse est non. De manière générale, il ne fait pas bon être francophone quand on se sert de Katalon… Vous utilisez des caractères spéciaux dans le mode Script ? Vous avez tort. Vraiment.

En mode manuel, heureusement, les caractères spéciaux s’affichent correctement.

Dans le même esprit, dans la popup d’identification des objets web, le raccourci d’enregistrement est Alt + ~. Infaisable avec un clavier français, sachant que la tilde nécessite trois touches différentes… Et à l’heure actuelle, ce raccourci n’est pas configurable dans les options de Katalon. EDIT du 17 avril 2019 : des solutions semblent avoir été apportées entre temps.

Ce ne sont que des détails, mais il est bon de le savoir avant de se lancer.

12) De manière générale, l’automatisation mobile est-elle plus difficile que l’automatisation web ?

Avec Katalon, non, pas vraiment. La gestion des appareils mobiles ajoute un peu de temps de configuration, mais cela ne fait pas de grande différence.

Le problème de l’identification des objets

Mais de manière générale, une application mobile peut être plus difficile à tester si l’équipe de développement n’a pas envisagé la possibilité que des tierces personnes relisent leur code… Lors de la capture des objets, on peut en effet se retrouver face à une liste interminable d’objets aux noms peu parlants.

Super clair !…

Pourquoi est-ce un problème ?

  • Parce que l’automaticien n’est pas toujours sûr de sélectionner le bon objet. Si deux écrans sont superposés et que chacun possède un bouton positionné au même endroit, même le mode visuel ne permet pas de savoir si l’objet sélectionné dans la liste est le bon.
  • Et surtout, parce que la spécificité des identificateurs impacte la robustesse des scripts d’automatisation. Un identificateur comprenant, en dur, un nombre arbitraire (tel bouton est le 27è de la page) est moins robuste qu’un identificateur défini par un « id » unique (« btn_enregistrer » par exemple).

Ce problème peut aussi exister au sein des applications web, mais dans une moindre mesure. En effet, les « id » et les « class » utilisées entre autres pour appliquer une mise en forme CSS au document sont d’une grande aide pour l’automaticien (sauf cas particuliers d’id générés automatiquement).

Ce problème n’est pas propre à Katalon. Si possible, incitez au plus tôt dans le projet les équipes de développement à créer des identificateurs d’objets « automation-friendly ».

Conclusion

Sans conteste, Katalon est un excellent outil. Il est même étonnant qu’il soit si peu connu.

Nous pensons que son plus gros défaut est malheureusement son incompatibilité avec Linux. On peut également déplorer une intégration trop superficielle avec Jenkins. L’outil a bien évolué depuis la publication initiale de cet article ! Voir cette documentation pour l’intégration à Jenkins, via un plugin dédié.

Si ces contraintes ne vous concernent pas, nous vous le recommandons chaleureusement. Nous serons heureux d’avoir vos retours sur ce logiciel.

Et pour en savoir plus sur l’automatisation des tests, nous vous conseillons cette ressource !

JMeter + Jenkins : la performance en continu

Hier, le lundi 10 avril 2017, le cyclone Cook traverse la Nouvelle Calédonie. Inquiets, les habitants se rendent en masse sur les sites d’informations météorologiques. Malheureusement, par intermittence, il semblerait que ces sites se soient retrouvés en état d’indisponibilité…

Une charge d’utilisateurs élevée peut compromettre la disponibilité d’un site web. Heureusement, certains tests non-fonctionnels aident à anticiper ce risque. Lancés périodiquement, au sein d’un cycle d’intégration continue, ils permettent de valider que l’applicatif résiste à une certaine charge d’utilisateurs. En prévision de la prochaine intempérie, nous vous proposons donc de voir comment intégrer des tests JMeter à votre instance Jenkins

 

Vous débutez avec JMeter ?

JMeter est un logiciel libre qui permet de réaliser des tests de performance, de charge, de stress, de vieillissement et de robustesse. Notre article ne vise pas à vous apprendre à concevoir un plan de test JMeter ; pour cela, nous vous conseillons la documentation officielle, qui fournit des tutoriels très complets.

Juste un conseil : pour commencer, configurez JMeter en anglais de façon à coller au vocabulaire spécifique utilisé dans les tutoriels.

Installation de JMeter sur Linux

Attention : à ce jour, sur Linux, la commande apt-get install jmeter n’installe pas la dernière version.

Pour installer la dernière version de JMeter, récupérez le numéro de version de JMeter à cette adresse, puis lancez les commandes suivantes :

wget -c http://ftp.ps.pl/pub/apache//jmeter/binaries/apache-jmeter-NUMVERSION.tgz

tar -xf apache-jmeter-NUMVERSION.tgz

Lancer un test JMeter en ligne de commande

Jenkins va lancer le test JMeter hors-GUI, c’est pourquoi il est important de comprendre comment lancer un test en ligne de commande. Il est aussi bon à savoir que, même si l’interface JMeter est pratique pour configurer ou débugger les tests, elle est déconseillée pour les lancer car elle consomme beaucoup de ressources et cela est donc susceptible de créer des effets de sonde.

Pour lancer un test en ligne de commande, enregistrer le plan de test au format JMX, qui est un format de fichier xml propre à JMeter.

Puis, lancer la commande suivante :

chemin/vers/bin/.jmeter -n -t chemin/vers/plan-de-test.jmx

« -n » indique que l’on souhaite lancer le test hors interface,

« -t » précède le chemin du plan de test à exécuter.

Vous pouvez configurer un alias pour écrire simplement « jmeter » à la place du chemin complet, mais Jenkins ne reconnaîtra pas cet alias.

Le résultat est un peu austère… mais le plugin Jenkins est aussi là pour ça !

Lancer un test JMeter depuis Jenkins

  • Stocker le fichier JMX dans un dépôt (Git, Mercurial, SVN ou autre)
  • Créer un nouveau job. Attention, ne pas mettre d’espace dans le titre, sinon cela provoque des erreurs.
  • Configurer la gestion du code source afin de récupérer le contenu du dépôt à chaque build.
  • Dans la section « Build », ajouter une étape « Exécuter un script shell ». La compléter avec :

    chemin/vers/bin/./jmeter -n -t $JENKINS_HOME/workspace/NomDujob/plan-de-test.jmx -l $JENKINS_HOME/workspace/JMeter/plan-de-test.jtl -e

Le fichier jtl contient les informations nécessaires à la création du reporting. Il sera automatiquement généré.

  • Dans la section « Actions à la suite du build », ajouter une étape « Publish performance test result report »
  • Dans « Performance report », sélectionner « JMeter ». Ajouter la regex « **/*.jtl ». Un fichier JTL sera généré pendant le build et interprété par le plugin pour fournir des graphiques comme ceux-ci :

Il vous reste à définir les seuils relatifs ou absolus à partir desquels vous souhaitez que votre build soit déclaré instable ou en erreur. Pour cet exemple, nous avons arbitrairement choisi une définition absolue : 1 erreur = build instable, 10 erreurs = build en échec.

Conclusion

En intégrant les tests JMeter à votre chaîne d’ordonnancement, vous serez capables à tout moment de connaître, selon vos tests, les performances, la résistance ou l’endurance de votre applicatif à tester. Des indicateurs qui peuvent se révéler tout aussi critiques que ceux que l’on obtient pendant les tests fonctionnels. Attention, la phase de définition des seuils est critique ; il faut veiller à n’être ni trop permissif, ni trop sévère. Comme souvent dans le monde du test, c’est avant tout une question de compromis entre qualité et vélocité…

Dans un prochain article, nous parlerons de Gatling, un autre outil open-source concurrent de JMeter qui peut également d’intégrer avec Jenkins.

Bonne découverte, et bon courage à tous les Calédoniens qui se remettent du cyclone.

Vous aimerez peut-être…

Gérer les paramètres Jenkins quand on est maniaque (ou flemmard)

SonarQube met son grain de sel dans Gitlab !

Performance, charge, stress… quelle différence ?

Et si vous avez besoin de prendre du recul sur l’automatisation de vos tests, nous vous conseillons cette ressource !

Quand choisir HP UFT plutôt que Selenium ?

Connaissez-vous UFT ? Non ? Qu’à celà ne tienne, en voici une présentation synthétique. Testeur novice ou expert, cet article a pour but de vous aider à comprendre l’outil et à déterminer s’il peut répondre à votre besoin. 

Kesako UFT ?

UFT, pour Unified Functional Testing est la réponse d’HP aux besoins croissants des organisations en tests logiciels automatisés. Successeur du célèbre QTP, UFT est donc un outil permettant l’automatisation des tests logiciels de façon simple et intuitive pour un testeur expérimenté comme pour un débutant.

UFT se présente sous la forme d’un environnement complet de développement comportant nativement l’ensemble des outils nécessaires à la conception, à l’exécution et au reporting des tests automatisés. Les scripts de test sont écrits dans le langage Visual Basic, facilitant considérablement l’utilisation de jeux de données au format Excel, et la gestion des objets* se fait de façon très simple grâce à l’outil « Object repository ».

*Objet : Toute application comporte des éléments avec lesquels l’utilisateur peut interagir, un bouton, un champ de saisie de texte, un label, etc… Ces éléments sont appelés des objets, et ces objets doivent impérativement être identifiés pour qu’un script de test puisse interagir avec lors de son exécution.

 

« Ok, c’est bien beau tout ça, mais concrètement, pourquoi je choisirais UFT pour automatiser mes tests, alors que tout le monde me parle de Selenium  ? »

me direz-vous. Approfondissons le sujet car la réponse n’est pas si évidente qu’il n’y parait.

Quelle application dois-je tester ?

Une première approche pour apporter un élément de réponse à cet épineux problème est de se poser la question suivante : « Quelle est l’application que je dois tester » ? Selenium est d’une redoutable efficacité en matière de test d’application web mais quid des applications desktop, les clients lourds ? L’avènement des applications web n’est pas parvenu à éradiquer des applications comme Excel, Skype, des IDE comme Eclipse, des progiciel de comptabilité comme Ciel, et bien d’autres… Ces logiciels résistant encore et toujours à l’envahisseur ont également des besoins  en termes de qualité. Et bien pour ceux là, Selenium aura la même utilité qu’un toit ouvrant sur un sous-marin. En effet UFT est un logiciel d’automatisation des tests pour application clients-serveur, il permet donc comme Selenium de tester des applications web, mais également des applications client lourds, et il faut lui reconnaître son talent en la matière.

UFT peut agir sur n’importe quel logiciel, un navigateur internet, un client mail, l’invite de commande, le dernier guide Larousse de cuisine sur CD-ROM, bref tout ce qu’un utilisateur peux effectuer comme action sur une application de type client lourd, UFT peut le faire.

D’autre part, depuis que QTP répond au doux nom d’UFT, il s’est doté des fonctionnalités d’un autre logiciel proposé par HP, « HP Service Test » permettant aux utilisateurs de concevoir et d’exécuter des test de d’API et de webservices. Cerise sur le ponpon, UFT offre également la possibilité de tester ses applications mobiles IOS et Android ( avec toutefois certaines contraintes dont, la nécéssité d’utiliser une solution tierce « M-eux » ainsi que la version des appareils mobiles à tester).

« Ah d’accord, mais ça veut dire que dès que je teste un client lourd je n’ai pas d’autres alternatives qu’UFT ? C’est embêtant, je vais devoir apprendre le Visual Basic alors que je suis un pro du cobol… »

UFT is User-Friendly !

Bien sûr UFT n’est pas le seul à permettre l’automatisation de test d’applications de type client lourd, mais UFT est simple à prendre en main et dispose de nombreux outils permettant de simplifier l’écriture de scripts. Aucun besoin d’être un développeur confirmé pour écrire un scénario en VB. Quelques notions simples en informatique, les boucles, les conditions, etc.. couplées à vos talents de testeurs suffiront amplement à rédiger vos tests automatiques.

Auto-complétion

L’auto-complétion prévue par l’IDE est très confortable et vous indiquera la syntaxe des boucles, des conditions si vous ne les connaissez pas en VB.

Built-in functions

Le framework UFT comporte des fonctions pré-conçues permettant d’effectuer des actions comme des clics, ou la saisie d’un texte dans un champ en 1 ligne de code. Il comporte également une fonction appelée « point de contrôle de fichier ». Cette dernière, tenant encore sur une unique ligne de code, permet de comparer des fichiers générés ou modifiés lors de l’exécution d’un scénario, à un fichier de référence défini lors de l’écriture du scénario. Les paramètres de comparaison sont définis dans une interface dédiée pour laquelle aucune connaissance d’un langage informatique n’est requis. Cette fonctionnalité est particulièrement pratique et utile par exemple pour valider le format et l’impression de factures lors des tests d’application front office.

Identification d’objets

Selenium a ses sélecteurs JQuery, UFT quand à lui possède son object repository ! La sélection et la gestion des objets dans UFT est grandement facilitée par 2 outils intégrés que sont l’object spy et l’object repository.

Grâce à l’object spy, aucune connaissance du code source de l’application n’est requise pour identifier un objet (champs texte, bouton, menu déroulant,…). Il suffit de lancer l’application à tester, de démarrer l’object spy puis de cliquer sur l’objet sur lequel on souhaite pouvoir effectuer des actions automatiques dans son scénario, et le tour est joué ! L’objet de test est identifié et peut être enregistré dans l’object repository.

L’object repository vous l’aurez compris, est donc la bibliothèque d’objets de vos scénarios (N.B. : C’est également lui qui contient les différents points de contrôle de fichier que vous aurez définis).

Ainsi, lors de la rédaction d’un scénario dans UFT votre liste d’objets est pré-définie et il ne vous reste plus qu’à l’appeler dans votre scénario pour lui faire subir les pires épreuves qu’un testeur peut infliger à une application !

Jeux de données

Un scénario de test automatisé, c’est un script, c’est à dire une série d’actions, que l’on applique à différents objets d’une application. Mais comment indiquer à ce script combien de fois cliquer sur l’objet X ou quel texte saisir dans le champ Y ? C’est le rôle du jeu de données.

Le jeu de données d’un scénario est une liste des valeurs que le scénario peut prendre comme paramètre. Prenons un exemple :

Je dois tester une application affichant « personne majeure » si le champ de saisie contient une valeur supérieure à 18, et « personne mineure » dans le cas contraire.

Pour réaliser ce test, j’aurais besoin :

  • d’un script : permettant la saisie d’un valeur dans le champ de l’application, puis de lire le texte affiché.
  • de 2 objets : La champs de saisie de l’application et le texte affiché
  • d’un jeu de données : comportant 2 couples de valeurs : {un nombre < 18 ; « personne mineure »} et {un nombre >= 18 ; « personne majeure »} 

Pratique non ? Grâce à mon jeu de données, à partir d’un unique script décrivant le comportement d’un scénario, je peux jouer une multitude de cas de test.

UFT permet une gestion enfantine des jeux de données en s’appuyant sur l’utilisation de fichiers Excel. Il est donc très simple de remplir les cellules de son fichier Excel avec les paramètres de ses cas de test, puis d’exploiter ses données dans son scénario via le langage Visual Basic qui, étant le langage d’écriture des macros de la suite Microsoft Office, comporte d’origine toutes les fonctions nécessaires à la lecture/écriture de fichiers Excel.

Execution et reporting

Côté Exécution et reporting, aucun outil externe n’est à prévoir. La suite UFT contient tout ce dont vous avez besoin. Les campagnes de test peuvent en effet être lancées directement depuis l’IDE en constituant des suites de test. La suite logicielle met également à disposition des utilisateurs un planificateur de test, le Test Batch Runner, permettant de créer des campagnes de test ordonnancées, planifiées, et de les sauvegarder pour les ré-exécuter ultérieurement.

Ces deux modes de lancement génèrent automatiquement à l’issue des campagnes, un rapport de tests indiquant pour chaque exécution, le statut OK/KO des tests ainsi que le détail de chaque étape.

Documentation

UFT est intuitif, simple à prendre en main. Il contient même un tutoriel constitué d’une petite application et  d’exemples de scénarios associés pour pratiquer et vous faire la main. Mais si cela ne s’avérait pas suffisant, sachez qu’UFT est très bien documenté et que l’on trouve facilement de l’aide sur les forums orientés autour du test logiciel.

Bon ça va, t’as gagné, ce logiciel à l’air vraiment génial, mais… attends… que lis-je ? Une licence ?

Personne n’est parfait…

Malgré tous ses atouts, UFT présente néanmoins quelques inconvénients qu’il convient de citer.

Premier de la liste, son prix ! UFT est commercialisé sous license renouvelable par trimestre et par utilisateur.

Autre inconvénient il ne peut être installé que sous Microsoft Windows, or dans un contexte ou la tendance est à la réduction des coûts et où les organisations tentent l’expérience open source avec des OS gratuits comme Linux, il peut s’agir là d’un obstacle à l’utilisation de cette solution d’automatisation.

Sur le plan technique, UFT étant assez gourmand en ressources système, il nécessitera une machine puissante pour s’exécuter et l’exécution d’une campagne de test sera donc plus lente, à ressources égales, qu’avec un outil comme Selenium. D’autre part, UFT ne peut exécuter qu’un test sur une application à la fois quand Selenium offre la possibilité de paralléliser l’exécution des test grâce à son plugin Selenium grid.

Bon, alors je prends UFT ou je prends pas UFT ?

Adapter l’outil au contexte et au besoin.

Pour conclure sur la question du choix d’UFT pour automatiser ses tests logiciels le schéma ci-dessous illustre, selon nous comment raisonner. Gardez toutefois à l’esprit qu’UFT et Selenium ne sont pas incompatibles, et que la solution à votre besoin en test peut résider dans l’utilisation conjointe de ces deux outils.

Besoin d’y voir plus clair sur le sujet de l’automatisation des tests en général ? Pssst, voilà une antisèche !


Quelle différence entre UFT et QTP ?

[Partie ajoutée le 03/04/2018 pour clarification suite à certaines questions]

Vous avez peut-être remarqué que sur certaines sources, les noms « UFT » et « QTP » sont interchangeables. A sa création en 1998, le logiciel s’appelait Astra Quicktest. En 2003, il a pris un autre nom : QTP, qui signifie « QuickTest Professionnal« . Ce n’est qu’en 2012 que QTP est devenu UFT. C’est pourquoi on trouve toujours, sur les forums ou sur StackOverflow, des personnes qui parlent de QTP.

Comprendre Selenium 3

Rappels sur Selenium

Créé en 2004 Selenium est un framework de tests automatisés open-source et gratuit dont le but est d’automatiser les interactions avec le navigateur et d’effectuer des checks dans les pages visitées. Très pratique pour tester les sites webs, il a inspiré de nombreux wrappers tels que Gebish, Cucumber, Serenity, Protractor, Nightwatch, Nemo… Les navigateurs pris en charge sont Firefox, Chrome, Opera, Safari et Internet Explorer. De nombreux langages sont supportés, certains bindings étant développés par l’équipe Selenium (Java, Ruby, Python, Javascript, C#), d’autres étant produits par d’autres communautés open-source (Perl, PHP, Haskell; Objective-C, R, Dart, Tcl). Le langage choisi pour développer des tests Selenium n’a aucun besoin d’être le même que celui de l’application à tester.

Au fil du temps, Selenium s’est imposé comme un standard de l’automatisation des tests open-source. Sa popularité est en constante augmentation.

Cet article s’adresse autant aux personnes qui souhaitent effectuer la migration vers Selenium 3 qu’à ceux qui souhaitent simplement comprendre la feuille de route du framework. Vous verrez, la migration demande peu d’efforts, mais vous découvrirez que c’est une version qui recèle de nombreuses promesses.

Comment migrer vers Selenium 3

La migration se fait relativement en douceur, toutefois voici la réponse à quelques questions que vous pourriez vous poser pour réaliser ce changement.

Quelle version de Java pour Selenium 3 ?

Adieu Java 7, Selenium 3 tourne uniquement avec Java 8+. Upgradez si besoin et si les autres dépendances de votre projet vous le permettent.

Attention, Squash TA nécessite encore Java 7. Si vous utilisez la suite Squash, il faudra patienter un peu.

Comment changer le POM Maven pour Selenium 3 ?

Si vous utilisez Maven, changez votre POM en remplaçant votre dépendance de Selenium par :

<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version>3.0.1</version>
</dependency>

Sinon, importez les jars dont vous avez besoin pour votre projet (ils sont disponibles ici).

Comment lancer Firefox avec Selenium 3 ?

Pour instancier un navigateur Firefox, il est maintenant nécessaire de faire appel à un driver externe : GeckodriverGecko étant le nom du moteur de rendu sur lequel se base Firefox (mais aussi ThunderBird, SeaMonkey…). Ce changement correspond à une nouvelle politique de gestion des drivers. Nous y reviendrons.

Téléchargez la dernière version de Geckodriver, placez le driver dans votre répertoire projet et ajoutez la ligne suivante avant l’instanciation de votre FirefoxDriver :

System.setProperty("webdriver.gecko.driver",chemin\vers\votre\geckodriver.exe");

Cette façon d’instancier un navigateur est la même que celle utilisée jusqu’à présent par les autres navigateurs. Aucun changement n’est donc requis pour continuer à tester avec Chrome, par exemple.

Quelles versions d’Internet Explorer sont supportées par Selenium 3 ?

Désormais, il n’est plus possible d’exécuter des tests sur une version inférieure à IE9.

Mais au fait, pourquoi Selenium 3 ?

Une modernisation en profondeur

Nous venons essentiellement de lister les contraintes liées à la migration de Selenium 2 à 3. Les avantages ne sont pas encore visibles pour l’automaticien. Les APIs WebDriver n’ont pas significativement évolué ; du moins, aucune annonce n’a été faite à ce sujet. Le véritable intérêt de Selenium 3, c’est tout le contexte dont il est issu, et les changements qu’il annonce.

Tout d’abord, cette version correspond à une refonte et une simplification importante, qui accélèrera sans doute le rythme des prochaines évolutions. Tout un pan du projet (Selenium Core) est maintenant laissé de côté et relégué en legacy. Partant du constat que le simple JavaScript ne permet pas de tout automatiser (source), Selenium repart sur une base plus moderne.

Vers une standardisation de l’automatisation web open-source

Un aspect important à prendre en compte est le contexte de standardisation du WebDriver, étant donné qu’une spécification W3C (dont le brouillon est déjà disponible) est en cours de rédaction à ce sujet. Cette standardisation précède un transfert des responsabilité, de la communauté open-source Selenium vers les organisations fournissant les navigateurs. Cela se voit d’ailleurs dans les dernières release-notes de Geckodriver, où les évolutions font directement référence à la spécification W3C.

Cette évolution donne véritablement ses lettres de noblesse à Selenium. C’est une excellente nouvelle étant donné que les fournisseurs de navigateurs, connaissant leurs produits mieux que quiconque, seront à même de concevoir les meilleures implémentations de leurs webdrivers respectifs.

Une deuxième spécification est déjà en projet, « W3C WebDriver Level 2« , qui devrait permettre à l’automaticien de résoudre un certain nombre de problèmes tout en homogénéisant les mécanismes des webdrivers. Cela impacte des actions telles que l’accès au Shadow DOM (assez casse-pied dans les projets Polymer par exemple) et les popups jusqu’alors non cliquables (par exemple la popup de demande d’autorisation de géolocalisation).

Bref, le petit monde de Selenium est en effervescence et beaucoup de bonnes choses sont à venir. Restez attentif !

Pour en savoir plus

Squash TM version 1.15.x : quelles évolutions ?

Squash TM : présentation rapide

Dans le cadre de nos projets, nous avons eu plusieurs fois l’occasion de gérer nos cas de test sur l’outil Squash TM.

Ce logiciel open-source est, pour la plupart de ses fonctionnalités, gratuit. Son grand atout est de permettre de lancer des tests automatisés directement depuis son interface. Visuellement plus agréable que Testlink, il est facile à prendre en main et à configurer. En-dehors de son site officiel, il n’est quasiment pas documenté, mais ce défaut est en partie comblé par son forum assez actif.

La dernière version mineure de Squash TM est sortie le 21 décembre dernier. Pour cette version 1.15.0, qui a été presque aussitôt suivie d’un patch, le reporting et l’ergonomie ont été mis à l’honneur. Petit tour d’horizon des principales évolutions.

Tableaux de bord

Visualisation des exigences

Créer de tableaux de bord était déjà possible pour mieux visualiser le patrimoine de cas de test et le déroulement des campagnes. Cette fonctionnalité graphique, qui fait partie des atouts de Squash TM, est maintenant également proposée dans l’espace des exigences.

Ce nouveau tableau de bord permet en un coup d’œil d’évaluer l’étendue de la couverture de tests. Il permet de répondre aux questions suivantes : où en est le travail de rédaction des exigences ? Sont-elles toutes décrites ? Sont-elles toutes associées à des cas de test ? Une bonne aide pour le test manager.

Un exemple de tableau de bord Squash TM :

Personnalisation des paramètres des tableaux de bord

Les champs personnalisés étaient déjà présents dans les versions antérieures. Il est désormais possible de les utiliser lors de la génération de graphiques et de tableaux de bord.

Avant :

Maintenant :

Création et affichage de tableaux de bord « favoris »

Dans l’espace pilotage (voir ci-dessous), les dashboards générés peuvent être sélectionnés pour être affichés en tant que « dashboard préféré » des espaces d’exigences, de cas de test ou de campagnes de test. Dans ces espaces, il est donc maintenant possible d’afficher des graphiques personnalisés, ou de revenir aux graphiques par défaut.

Sélection du dashboard favori dans l’espace cas de test :

Et si besoin, retour au graphique par défaut :

Ergonomie : des petits plus confidentiels

Drag’n’drop

La release note de la version 1.15.0 indique : « [Cas de test] Drag’n drop pour l’appel de cas de test »… et heureusement, car sans cela nous n’aurions jamais découvert cette fonctionnalité. Dans l’espace « Cas de test », sélectionnez un cas, ouvrez l’onglet des pas de test. A ce moment-là, au lieu de cliquer sur le bouton « Appeler un cas de test », cliquez sur un autre cas et glissez-le dans la zone des pas de test. Un petit tooltip serait le bienvenu pour les utilisateurs qui ne lisent pas les release notes… Ni ce blog !

Jeux de données

Les plus observateurs remarqueront le nom du jeu de données qui apparaît maintenant dans le titre de la popup d’exécution et dans le bandeau du titre du préambule.

Avant

Maintenant

Champs personnalisés de type numérique

Une petite évolution qui ne paye pas de mine, mais qui permet de se rapprocher d’une fonctionnalité présente sur un autre logiciel de test management open source, TestLinkOuvre un nouvel onglet 

Ecran Testlink

Ecran Squash TM

Et rien n’empêche maintenant de faire un graphique incorporant la notion de temps d’exécution des tests, comme ci-dessous :

Focus sur le champ

Autre amélioration sympathique : lorsque l’utilisateur clique sur le bouton « Ajouter un autre » (cas de test, par exemple), sur la popup suivante son curseur est directement positionné dans le premier champ à éditer ; plus besoin de cliquer dessus.

Ce sont ces petits détails qui rendent un logiciel agréable à utiliser.

Pour en savoir plus

  • Sur les fonctionnalités prévues pour les prochaines version, voir la roadmap de Squash TMOuvre un nouvel onglet .
  • Pour tester vous-mêmes les nouvelles fonctionnalités de Squash TM, rendez-vous sur leur démo en ligneOuvre un nouvel onglet .