Les tests de performance (1/3)

test

Je vais vous présenter en une série d'articles, dont celui ci est le premier, l'importance des tests de performance sur les applications que nous développons ainsi que les étapes à suivre pour les réaliser de façon optimale.

L'importance de réaliser des tests de performance aujourd'hui

Aujourd’hui, les performances des applications sont au cœur des préoccupations des DSI. Cette préoccupation est liée au fait qu’une application labellisée stratégique et utilisée à grande échelle au sein d’une entreprise, doit  faciliter la tâche de ses utilisateurs et non pas rajouter plus de complexité.

Ces exigences sont prises au sérieux et suivies de très près par les utilisateurs finaux dont le ressenti lors des phases de la recette métier peut causer un non GO pour l’application.
De plus en plus d’entreprises intègrent dans leurs feuilles de route une phase de tests de performance, qui peut être menée et réalisée d’une manière indépendante :

  • La stratégie est définie par le projet;
  • Cette phase est hors périmètre de l’intégrateur. Par contre, elle servira pour se prononcer sur la recevabilité technique du livrable;
  • Le déroulement des tests, basé sur la stratégie définie par le projet, est prévu par une entité externe au projet.

Pour des projets dont le développement d’une simple version nécessite des milliers de jours/homme, et par conséquent une réalisation qui dure quelques mois, il faut absolument éviter l’effet tunnel.

Si à l’issue de ces mois de développement et recettes nous nous apercevons que les exigences n’ont pas été respectées et que les problèmes détectés peuvent remettre en cause quelques points de l’architecture technique ou fonctionnelle, alors il sera trop tard pour les appliquer ou tout du moins cela aura un impact néfaste sur le planning qui risque de glisser.

Pour éviter ceci, des tests de pré-performance doivent être exigés auprès de l’intégrateur tout au long de la réalisation de l’application et des rapports précis devraient être transmis d’une manière continue afin de desceller tout problème et de s’assurer en amont que l’intégrateur est capable de tenir les temps de réponses demandés.

Si cette option est retenue, elle ne se substitue pas aux tests prévus côté projet afin de valider les résultats transmis par l’intégrateur en se basant sur la même stratégie qui l’avait défini. Si elle couvre tous les aspects identifiés par le projet, ou bien sur une stratégie différente adoptée par l’équipe Projet.

Afin de s’assurer que les résultats obtenus refléteront le comportement de l’application dans l’environnement de production et d’utilisation cible, la stratégie devra être établie à partir de scénarios quasi réels et basée sur des données qui représentent celles qui devraient être utilisées réellement par l’application. En fonction de la complexité du système, il est parfois très difficile de reproduire ou même de déterminer l’usage (scénarios, fréquences, …). Même d’un point de vue environnement, si notre application interagit avec d’autres SI, il sera très difficile de s’affranchir des plateformes dédiées à leurs propres tests (Planning et contraintes du SI en face).

Quelles sont les étapes à suivre pour réaliser ces tests de performance ?

La première étape consiste en l’identification des objectifs à atteindre en terme de temps de réponses pour l’ensemble des services offerts par l’application. Bien sûr, il pourrait exister des services ou fonctionnalités qui n’ont aucune exigence de performance.
La deuxième étape est la stratégie elle-même qui permettra de vérifier et de s’assurer que cet objectif est atteint. Les axes majeurs qui la définissent sont :
• Identification des acteurs, des rôles et des responsabilités. Plus simplement : qui fait quoi ? ;
• Identification des fonctionnalités présentant un risque majeur pour les performances ;
• Déterminer les exigences en termes de temps de réponses ou d’exécution pour les fonctionnalités identifiées ;
• Identification des fonctionnalités qui ne présentent pas un risque majeur, mais leurs exécutions en parallèle avec d’autres fonctionnalités, peuvent avoir un impact non négligeable ;
• Identification des environnements techniques nécessaires (VM, …) ;
• Faire un bilan des outils nécessaires pour mesurer les différents temps de réponse, si l'architecture est complexe et que les services ne sont pas atomiques ;
• Description des différents scénarios ;
• Déterminer le plan de charge pour chaque scénario ;
• Scripting des scénarios ;
• Détermination des jeux de données adéquats ;
• Définition des campagnes de tests ;
• Analyse.

Voilà pour les étapes, je vous développerez les plus importantes dans les prochains articles.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.