Posts taggés java

Initiation à Gatling, un outil de tests de charges

0

Gatling-logo

Après avoir développé, testé fonctionnellement une application, une autre étape importante consiste à tester l’application dans des conditions plus proches de la production. Pour cela, une étape de tests de charge semble indispensable. En effet, une application est souvent testée unitairement par un développeur, profil après profil, fonctionnalité après fonctionnalité.

Nous allons nous intéresser ici à un outil permettant de réaliser ces tests de charge, à savoir Gatling. Gatling est un outil basé sur le langage Scala, Netty et Akka. Grâce à Netty, les requêtes sont lancées de manière asynchrone, ce qui permet d’utiliser un grand nombre d’utilisateurs virtuels. Les scénarios générés sont écrits en langage Scala. Ce langage est proche de Java mais est plus simple à appréhender. Quant à Akka, c’est un Framework qui implémente le modèle d’acteurs.

Gatling s’installe facilement grâce à un fichier zip. Étant basé sur Akka, il a néanmoins besoin de la présence du JDK pour fonctionner. Il suffit ensuite de paramétrer manuellement son navigateur pour qu’il passe par le port 8000.

Création du scénario

Les scénarios peuvent être écrits entièrement à la main, ou nous pouvons utiliser le « recorder ». Celui-ci permet d’enregistrer un scénario simplement en navigant dans l’application, à la façon d’un internaute. Le scénario généré peut ensuite être modifié à l’envi à l’aide du langage Scala.

Nous allons ici tester Gatling dans sa version la plus simple. Prenons par exemple une application de réservation de billets de train :
– Ouvrir l’URL du site
– Rechercher un billet aller-retour Paris-Marseille pour une personne avec une carte jeune de réduction
– Accéder à l’ensemble des tickets disponibles
– Choisir le trajet aller et valider
– Choisir le trajet retour et valider
– Renseigner les données pour le mail récapitulatif
– Accéder à la page de paiement

L’entête du fichier est généré automatiquement, suivant les informations renseignées dans la fenêtre de Gatling. Par défaut, le nom de la classe est « RecordedSimulation ». Le nom du package doit commencer par une lettre est doit être en minuscule.

Le fichier résultant va être créé dans le répertoire paramétré dans « Output folder » et, dans notre exemple, va porter le nom « RecordedSimulation.scala ».

 

1

 

Dans l’entête du fichier généré se retrouve le nom du package et du nom de la classe. De plus, la variable baseURL indique l’adresse principale du site testé. Les fichiers générés peuvent être modifiés grâce à un éditeur de texte type Notepad++. Ils peuvent également être ouverts dans Eclipse, si celui-ci est présent sur le poste.

 

2

 

Lorsque l’on navigue sur une page web ou que l’on saisit des informations dans un formulaire, toutes les URLs sont enregistrées par Gatling. Un extrait des actions exécutées lors de la saisie des villes de départ et de destination est présenté, ici un Paris-Marseille aller-retour. Plusieurs fonctions similaires sont générées car la fonction d’autocomplétion est enregistrée.

 

3

 

Ce type d’enregistrement génère un grand nombre de requêtes. Nous pouvons modifier leur nom, afin de les rendre plus parlantes. Cela permettra de les retrouver plus facilement dans les graphiques de résultats. Nous allons détailler la saisie des informations après validation des billets aller et retour et avant la page de paiement. Le site demande la date de naissance du voyageur, ses nom et prénom ainsi que son adresse email.

Le nom de la requête a été ainsi modifié :

 

4

 

Ce morceau de scénario peut être écrit comme une fonction. Ceci permet de factoriser le code et de potentiellement le réutiliser par la suite.

 

5

 

La génération des scénarios est donc facilitée par l’utilisation des fonctions. Un scénario se compose d’une succession de fonctions. Une même fonction pouvant être appelée par plusieurs scénarios, il est donc possible de lancer plusieurs fois les mêmes actions, par exemple pour des profils différents.

 

6

 

Pour l’instant, le scénario est exécuté par une seule personne avec des informations de date de naissance, de nom, de prénom et d’adresse email fixes. Nous pouvons pousser le paramétrage de la fonction de saisie d’information avec un fichier. Dans notre exemple, nous pouvons mettre en facteur le jour, le mois et l’année de naissance, les nom et prénom ainsi que l’adresse email.
Le fichier nécessaire à ce paramétrage doit être un fichier au format CSV. Le nom des colonnes doit reprendre le nom des variables qui sera utilisé par la suite dans le scénario. Un exemple de fichier est présenté ci-dessous. Notre fichier se nomme param.csv.

 

7

 

Le nom du fichier paramétré doit être inséré dans la fonction où il est appelé, avant l’appel des variables. Les variables ainsi définies sont appelées grâce à l’écriture ${nomvariable}, ce qui donne un fichier plus générique.

 

8

 

Paramétrage du test de charge

Pour l’instant, un seul utilisateur se connecte à l’application. Pour faire des tests de charge probants et simuler les vraies conditions de navigation, le nombre d’utilisateurs peut être augmenté. Par exemple, 6 utilisateurs peuvent se connecter à l’application toutes les 15 secondes grâce aux fonctions inject et rampUsers.

9

Si nous voulons plutôt tester des utilisateurs simultanés, il faut utiliser la fonction atOnceUsers avec le nombre d’utilisateurs en paramètre. Par défaut, le scénario est enregistré avec un seul utilisateur.

10

 

Affichage des résultats

Les résultats sont ensuite disponibles, après leur génération dans un répertoire /results. Un nouveau dossier est généré, portant le nom de package, suivi d’un tiret et de plusieurs chiffres. Les résultats sont fournis au format HTML et la page racine, index.html, permet d’accéder à l’ensemble de ces derniers.

Un premier graphique en bâtons fournit une vue du temps de réponse des requêtes. Les requêtes sont partagées en différentes catégories suivant leur temps de réponse. Dans notre cas avec un utilisateur, nous pouvons voir que plus de 400 requêtes répondent en moins de 800 ms, mais qu’un certain nombre sont en erreur, dans la colonne ‘failed’.

 

11

 

Dans ce deuxième graphe en bâtons, où 10 utilisateurs sont envoyés en simultané, il est possible de voir que le résultat est plus nuancé. On peut noter que l’écrasante majorité des requêtes répondent en moins de 800 ms à quelques exceptions près. On retrouve également des requêtes en erreur.

 

12

 

La page index.html contient également un tableau récapitulatif de toutes les requêtes. Pour chaque ligne, on peut voir le nombre de requêtes total, le nombre de requêtes OK, le nombre de requêtes KO ainsi que les temps de réponses.

 

13

 

En cliquant sur le nom d’une requête, une nouvelle page s’ouvre, pour afficher les résultats de la requête spécifiquement. Par exemple, si on ouvre la request_41, il est possible de voir que 7 requêtes ont abouti en moins de 800 ms et 3 n’ont pas abouti.

 

14

 

D’autres types de graphiques sont également disponibles. Par exemple, nous pouvons voir le nombre de requêtes par utilisateur ou le nombre de réponses par utilisateur.

Ces analyses permettent de voir quelles requêtes sont les plus problématiques, et de corriger le tir rapidement.

 

Synthèse

Gatling dispose de nombreux points forts :

  • Cet outil est gratuit et simple à installer. Il ne requiert aucun logiciel supplémentaire hormis un JDK à jour.
  • La facilité d’utilisation du recorder : avec un simple navigateur et un minimum de paramétrage, il est possible d’instancier de nombreux scénarios, des plus simples au plus complexes.
  • L’existence d’un plug-in pour Eclipse : pour les développeurs Java, il devient simple de lancer le recorder, ou par la suite de lancer les tests de charge.
  • La possibilité de créer des scénarios ou de les modifier grâce au langage Scala. Le langage Scala est suffisamment simple et « parlant » pour pouvoir être utilisé facilement.
  • La clarté du site : La documentation sur le site est assez complète pour faire des scénarios simples, puis pour les complexifier par la suite.
  • La détection des problèmes de compilation : lorsque nous essayons de lancer les tests de charges, l’outil pointe les erreurs de compilation dans la console.
  • La clarté des graphiques générés : nous pouvons faire aisément des analyses globales ou des analyses plus détaillées, requête par requête.

 

Gatling a aussi ses points faibles :

  • La génération différée des rapports : les rapports sont générés après l’exécution de la totalité des tests de charge.
  • L’interface qui permet de lancer les tests de charge, dans sa version native, n’est pas graphique.

 

En conclusion, Gatling gagne à être connu et utilisé dans le cycle de vie d’un projet. Avec un minimum de connaissance en langage informatique, des scénarios complexes peuvent être élaborés. Cela permet de pointer du doigt les portions d’application à modifier ou à optimiser. Je l’ai testé dans sa version la plus basique. Malgré un manque d’ergonomie dans l’outil de tests de charges en lui-même, les fichiers générés se retrouvent facilement et le paramétrage est aisé.

 

Retour d’expérience d’un projet basé sur Apache Cordova + AngularJS + Angular Material

0

Contexte du projet

Dans le cadre d’un projet de recherche et développement, nous avons été amenés à réaliser une application mobile qui vient compléter un site web déjà existant et qui contribue au partage des bonnes trouvailles du web. Les systèmes d’exploitation ciblés étaient Android et IOS, aussi bien sur smartphones que sur tablettes. Le temps imparti au développement de celle-ci était limité mais sans contrainte particulaire sur les technologies à utiliser.

 

Orientation technique

Notre choix technique c’est porté sur :

Apache Cordova

Apache Cordova est un Framework open-source développé par la Fondation Apache. Il permet de créer des applications mobiles cross-plateformes en HTML, CSS et JavaScript pour la plupart des OS du marché (Android, Amazon Fire OS, Bada, Blackberry10, Firefox OS, IOS, Ubuntu, Windows Phone 8, Windows 8, Tizen), tout en bénéficiant des fonctionnalités natives des appareils (localisation GPS, appareil photo, contacts, etc). Les applications qui en résultent sont dites « hybrides », ce qui signifie qu’elles ne sont pas vraiment natives, ni purement basées sur les langages HTML, CSS et Javascript.

 

L’adoption d’une plateforme hybride pour la conception de l’application mobile au détriment du développement natif s’est justifiée principalement pour des raisons de timing. En effet les développeurs affectés à cette tâche n’avaient que très peu d’expérience dans les langages de programmations spécifique à chaque plateformes mobiles (Objective-C, Java, C#, etc) et avec une deadline à respecter.

AngularJS

Développé par Google, AngularJS est un Framework JavaScript MVW (Model View Whatever) très puissant, riche en fonctionnalité, libre et open-source. Il est fondé sur l’extension du langage HTML par de nouvelles balises et attributs, ce qui va nous permettre de créer une application web. Il est basé sur le patron de conception MVC (Modèle, Vue, Contrôleur).

Voici quelques aspects d’AngularJs qui nous ont poussés à l’utiliser :

  • Architecture du projet : le code est modulaire et structurer grâce notamment à un ensemble de vues conceptuels : Template, Directives, Model, Scope, Module, Injection de dépendance, …
  • Data-binding bidirectionnel : les modèles et les vues se mettent à jour automatiquement dès lors qu’une modification sur un objet, auxquelles elles sont liées, survient.
  • Directives : une directive permet de créer de nouveaux éléments (attributs HTML) que l’on va pouvoir utiliser directement dans nos vue. Cale permet de factoriser du code et de faciliter la ré-utilisabilité des composants. Autre aspect positif, nos vues ne contiennent que du HTML.
  • Il existe une multitude de modules Angular disponible pouvant enrichir une application.

Angular Material

Angular Material est une librairie développer par Google et conçu pour les développeurs qui utilisent AngularJS. Ce projet fournit un ensemble de composants (menus, interfaces) et de fonctionnalités qui sont propre à une application mobile (exemple : le slide pour faire apparaître un menu, etc). Il est très facile à prendre en main et suffit amplement pour de petites applications.

 

Utilisation

Il existe une multitude de tutoriel sur comment développer en AngularJs ou Cordova, donc ce que je vous propose, c’est une petit récapitulatif sur les problèmes auxquels nous avons été confrontés tout au long du projet.

 

Dès le début du projet, nous avons été confrontés à un problème de taille : gérer l’ordre d’instanciation afin de ne charger les classes JavaScripts qu’après l’initialisation d’Apache Cordova.

 

Pour ce faire nous avons utilisé la librairie « RequireJs » (site officiel).

Au sein de notre application, nous avons créé un fichier « autoload.js » qui fait appel à la méthode « require() » qui comporte deux paramètres :

  • le premier étant un tableau contenant la liste des fichiers à instancier (on y placera la déclaration de nos contrôleurs, services, directives, filtres, helpers, …)
  • le second étant une fonction. C’est dans celle-ci qu’on va pouvoir déterminer les actions à mener. Dans notre car instancier Angular et la base de données seulement après que Cordova le soit.
    • On va pouvoir déterminer que Cordova a bien été initialisé grâce à la méthode :

 

1

 

Ce fichier « autoload.js » que l’on vient de créer doit bien évidement être charger sur la page HTML (fichier index.html), après avoir déclaré toutes les librairies nécessaires au bon fonctionnement de l’application (Cordova, AngularJs, Angular Material, jQuery, …).

 

Pendant la phase de développement, nous avons utilisé le simulateur de l’IDE (Telerik App Builder), mais lorsque nous déployer notre application sur un téléphone, le résultat obtenu ne correspondait pas du tout au rendu sur le simulateur. Et pour cause, la connexion à la base de données locale ne s’effectue pas de la même façon.

Pour gérer la connexion à la base de données sur un vrai appareil, nous utilisons le plugin Cordova: « sqlitePlugin ».

Ce qui permet de faire la différence avec le simulateur, c’est en se basant sur l’identifiant unique de l’appareil utilisé. En effet, chaque appareil à un identifiant qui lui est propre.

 

Voici un exemple de connexion à la base de données :

2

 

La dernière partie concerne l’intégration avec l’utilisation d’Angular Material. Il faut savoir que les toutes les versions d’Android ne sont malheureusement pas compatible, en effet seules les versions supérieurs ou égale à la 4.4 le sont. Il faudra utiliser d’autres librairies pour assurer la rétrocompatibilité des styles sur les anciennes plateformes.

 

Liens

Apache Cordova :

AngularJs :

Angular Material :

RequireJs :

 

angularjs

apache-cordova

Angular Material