Présentation des tests de performance

Définition
Généralités
Les risques
Les enjeux des tests de performance
Les différents types de tests de performance
Bien comprendre les tests de performance
Stratégie
Identifier les scénarios critiques
Processus de Réalisation
Méthodologie
Scripting
Modélisation
Restitution


Définition

Les tests de performance et de charge ont pour principal objectif la validation d'une solution logicielle et de son architecture sous-jacente liées à une utilisation simultanée multi-utilisateurs, permettant ainsi d'éviter certains problèmes en production. Ils permettent de garantir une qualité de service applicative dans des conditions réelles d'utilisation.

Généralités

Les tests de performance devraient théoriquement être réalisés au plus tôt dans le cycle de développement applicatif afin de minimiser les modifications applicatives engendrées par la découverte des anomalies de performance. Ainsi, il est possible de prévoir des tests de performance en amont, dans un environnement stable (hors environnement de développement) et dans le cadre d'une démarche Agile. Dans ce cadre, les objectifs de ces tests seront alors limités : temps de réponses unitaires ou à faible charge, capacité de l'application à maintenir un accès concurrent multi-utilisateur.

Classiquement, les tests de performance sont réalisés dans un des environnements de pré-production afin d'être au plus proche de la réalité techniques de production (iso architecture et chaînes de liaisons). Les résultats seront alors réellement complets et probants.

Les tests de performance et de charge permettent de déterminer des points de contention de l'architecture technique s'ils existent et de les éliminer par modifications de paramétrages techniques / tirs de charge itératifs. Ces problèmes de performance proviennent, souvent, soit de l'architecture (problème de dimensionnement des machines, paramètres limites des serveurs inadaptés,...), soit d'un problème applicatif (bonnes pratiques de programmation non respectés ou inexistantes, ...). Ils permettent également de déterminer des seuils limites de bon fonctionnement (nombre d'utilisateurs, fréquence d'utilisation applicative maximum garanti,…).

Les tests de performance et de charge de doivent pas, comme les tests fonctionnels unitaires, couvrir 90% des cas de tests, mais doivent couvrir les aspects applicatifs présentant des risques systèmes en charge, des risques d'interactions avec d'autres applicatifs, des risques stratégiques ou financiers sur des fonctionnalités ciblées dans un contexte multi-utilisateurs.

Les risques

Si une application n’est pas performante, les conséquences pourraient être :

  • La qualité d’accueil des clients qui se dégrade
  • La perte de productivité (Traitement de dossier très long, impossibilité de déclarer des sinistres, …)
  • La perte de clients
  • La perte de revenu
  • L’attention des médias avec, par conséquent, une perte de popularité
  • Etc.

Exemples :

  • Dans une banque de finance : une anomalie de production coûte en moyenne 300 000 €.
  • Chez un voyagiste : une indisponibilité d'1 minute du site web coûte 20 000 €.

Les enjeux des tests de performance

La stratégie de test dépendra en grande partie des enjeux des tests de performance.

Exemples d’enjeux :

  • Dimensionner une infrastructure de production pour un déploiement national
  • Rassurer la DSI sur la montée en charge d'une application
  • Valider les performances/l'endurance/la robustesse d'une application
  • Comparer des solutions
  • Valider que les performances ne se dégradent pas suite à une migration du socle technique et / ou applicatif (Exemple : nouvelle infrastructure Siebel)
  • Vérifier ou optimiser les performances d’une application et au besoin résoudre les problèmes de performances de cette application
  • Etc.

Stratégie de tests :

  • Tir de non régression
  • Tit de bout en bout
  • Tir de validation du SI
  • Tir aux limites
  • Etc.

Les différents types de tests de performance

Test de faisabilité :

  • Objectif : vérifier l’éligibilité d’une application vis-à-vis de l’outillage d’injection (Est-ce que l’application à tester est compatible avec les outils disponibles ?)
  • Particularités : Pas d’objectifs précis, ce test est effectué en dehors de l’environnement de performance, utilisation de VM possible, vérification accès applicatif multi-utilisateurs

Test de performance en charge nominale et en pics de charge :

  • Objectif : vérifier l'aptitude de l’application à fonctionner dans des conditions d’utilisation « normales » (Référence : Heure la plus chargée de la journée) et en « pics de charge » (Saisonnalité, exemple : attestation scolaire) par rapport aux indicateurs de production/MOE
  • Particularités : Exigences précises, utilisation de VM, vérification de la tenue en charge, peut être utilisé pour des tests de non régression ou donner des orientations de scalabilité pour les architectes, montée en charge lente

Test de charge aux limites et de rupture :

  • Objectif : atteindre la limite ou la rupture de l’application afin de déterminer la limite acceptable des temps de réponse avant la rupture système ou applicative, la limite doit être définie par le projet. (Il n’est pas simple d’obtenir des exigences précises)
  • Particularités : Exigences précises, utilisation de serveurs de même type et/ou de même dimensionnement que la cible, vérification de la tenue en charge, recherche de valeurs limites supportées par l’architecture applicative, montée en charge lente

Test de surcharge (ou de stress) :

  • Objectif : vérifier le comportement de l’application à subir une surcharge (Coefficient multiplicateur de la charge nominale doit être défini par le projet)
  • Particularité : Exigences précises, utilisation de serveurs de même type et/ou de même dimensionnement que la cible, identification des éléments de la chaîne de liaison ayant provoqué la rupture, montée en charge rapide

Test d’endurance (ou longue durée) :

  • Objectif : vérifier l'aptitude de l’application à fonctionner dans des conditions d’endurance (débit métier moyen sur une longue période, minimum 8 heures)
  • Particularités : Exigences précises, utilisation de VM, vérification de la tenue en charge et recherche de fuites mémoires, montée en charge lente

Test de robustesse :

  • Objectif : vérifier les exigences en mode dégradé (Arrêt d’un serveur) pour une architecture en Load balancing
  • Particularités : Ces tests sont généralement pilotés par l’expertise et la production (DES), ils nécessitent des exigences précises, vérification de la tenue en charge et recherche de fuites mémoires, montée en charge lente

Bien comprendre les tests de performance

 

Comprendre

Stratégie

Tester en charge une application c'est réaliser une succession de campagnes de test de charge. Il convient de réfléchir aux objectifs de chaque campagne, de déterminer le périmètre des tests afin d'identifier les risques applicatifs à couvrir et de déterminer et valider les hypothèses de départ.

Les résultats de la campagne de tests ne sont probants que dans un contexte optimal dans un environnement matériel représentatif de celle de production ; s'il existe des serveurs physique ou virtuels en production, il convient de choisir le même type de serveur en environnement de test. Cependant, dans un souci d'économie et compte tenu d'une rapidité de mise en œuvre, une machine virtuelle peut être utilisée même si en production des serveurs physiques existent. Dans ce cas de figure, seuls les tests en charge nominaux seront probants et on vérifiera seulement si l'application fonctionne en mode multi-utilisateurs. Il ne sera pas question, par exemple, de réaliser des tests en pics de charge ou tests aux limites compte tenu des capacités de performances moindres des VM.

Outre cette nécessité de contexte iso-production, la validation applicative n'est effective que si l'ensemble des exigences de performance (en termes d'utilisateurs en charge, « fréquence » d'utilisation applicative constatée en production ou imaginée par expérience (démarche par hypothèses lorsque l'application n'existe pas en production), volumétrie en base de données, temps de réponse utilisateurs, ..) sont respectées.

Les tests de charge doivent être réalisés de façon à prendre connaissance des résultats dans leurs globalités. Si certains résultats ne sont pas conformes à ce qui est attendu, il convient de s'interroger sur la véracité de ceux-ci. S'ils se révèlent exacts, il est nécessaire de mettre en place un dispositif réseau ou de profiling applicatif, permettant d'investiguer plus précisément le ou les éléments de développement responsables de ces mauvais résultats ou un outil de trace de transactions applicative (Ex : appinternals xpert) afin de déterminer le temps de réponse trop important dans la chaîne de liaison.

Dans le contexte d'un SI, l'application peut accéder à des services d'un prestataire externe.  Etant donné qu'il faut mettre en place les modalités et conditions pour chaque tir de performance avec le prestataire, on peut utiliser un logiciel applicatif lors de la phase de mise au point (appelé stub) qui permet de simuler de façon plus ou moins intelligente les réponses applicatives et de disposer de résultats de référence sans solliciter ce prestataire (et le temps du Cloud).

Identifier les scénarios critiques

Il est très important d'identifier les scénarios pertinents.

Pour définir ces scénarios, on peut :

  • Récupérer les statistiques de l'utilisation de l'application si elles existent (par exemple le nombre quotidien ou mensuel de transactions « métier », l'analyse des statistiques Web (access_log), etc.)
  • Définir avec le projet les scénarios majeurs d'utilisation (les fonctions les plus utilisées, les plus avancées ou les plus consommatrices) de leur application (suites d'écrans et nombre d'utilisateurs).

Ces scénarios devront être :

  • Réalistes au niveau des tests de performance (écrans consultés, champs saisis dans les formulaires, temps entre chaque action...)

 

Il y a trois types de scénarios à prendre en compte :

  • Fréquents

- Les scénarios du quotidien (Exemple : les recherches, les consultations d’un sociétaire)

  • Vitaux

- Les scénarios qui sont vitaux (Exemple : l’affectation des tâches aux gestionnaires, le déclenchement de la paye)

  • Risqués

- Les scénarios risqués d’un point de vue performance pour l’application (Exemple : l’accès à la GED, une recherche complexe, la génération de document)

 

Processus de Réalisation

 

Processus

 

Méthodologie

La méthodologie repose sur un ensemble de documents permettant de définir l'ensemble des éléments nécessaires à sa réalisation, d'exposer les résultats d'analyses et de donner le bilan de la campagne.

Les documents sont : Besoins de tests, Plan de tests, Rapports de tests, Retour d'expérience, Bilan de campagne, …

Etape 1 : Définition du Besoin de tests :

-       Définir le planning de la campagne,

-       Définir le périmètre fonctionnel,

-       Définir l'architecture technique,

-       Définir les exigences,

-       Définir le jeu de données,

-       Définir les scénarios fonctionnels,

-       Définir les types de montée en charge,

-       Définir les modélisations de charge,

-       Définir les actions pré et post tests de charge

-       Définir la volumétrie

-       …

Etape 2 : Réalisation :

-       Enregistrer une cinématique fonctionnelle à l'aide d'un outil de scripting (cf § Scripting),

-       Déterminer plusieurs modélisations de charge de cette cinématique fonctionnelle (cf § Modélisation),

-       Exécuter un test de charge préliminaire (de validation script / scénario de charge),

-       Exécuter les tirs de charge,

-       Analyser les résultats

-       Relancer les tirs de charge après ajustement,

-       Rédiger des rapports Flash et Point de situation

Etape 3 : Restitution :

-       Rédiger le Rapport de Tests de la campagne

-       Rédiger le Bilan des tests de charge

-       Rédiger un rapport d'expérience (le cas échéant)

Scripting

Les tests de charge sont réalisés à l'aide d'outils capables de simuler des utilisateurs virtuels. L'opération de scripting est une opération permettant la transformation d'une capture de l'application en un script (en langage de programmation ou graphiquement).

Au préalable, le document besoin des tests de charge contient l'ensemble des scénarios fonctionnels (sous forme de captures d'écran de l'application) qu'il faut scripter. Pour être valables, ces scénarios fonctionnels doivent respecter des conditions de rejouabilité (création suivi d'une suppression, …), de cohérence (connexion suivi d'une déconnexion), de réalisme (certaines fonctionnalités ne sont jamais utilisées d'une certaine façon mais toujours d'une autre) mais aussi de compatibilité avec les outils de scripting (toutes les applications ne sont scriptables). Il convient de réaliser, dès le début du projet, un test de faisabilité technique.

Suite à la phase d'enregistrement, le script, créé avec un utilisateur applicatif, n'est pas rejouable en l'état. Il faut le variabiliser avec le jeu de données (liste des users, données applicatives). Il faut réaliser ensuite une corrélation qui consiste à assurer la cohérence des enchaînements d'appels applicatifs (Id de sessions entre pages web, paramètres d'entrée issus des paramètres de sortie des pages précédentes, …).

La dernière phase consiste à encapsuler chaque appel applicatif par des transactions. Ce sont les résultats de ces transactions qui seront visibles dans les analyses. Il faut aussi considérer les temps de réflexion des utilisateurs entre deux actions utilisateurs (un temps nul entre deux appels applicatifs est irréel dans la majorité des cas).

Modélisation

Il existe plusieurs types de modélisation de charge dont le nom peut varier : Tests en charge nominale, Pic de charge(ou test des stress), Test de vieillissement (ou d'endurance), Tests aux limites, Tests de robustesse (ou en mode dégradé).

La modélisation repose souvent sur une connaissance de l'activité réelle en production. Si le modèle de charge en charge nominale se contente de restituer un nombre d'utilisateurs virtuels moyens constaté en production, le modèle de charge pour le Pic de charge (ou stess) doit être déterminé conformément à la réalité des moyennes et maximums réels constatés. Le modèle le plus commun est le modèle dit en « M ». Ce modèle présente la particularité de dessiner un M sur une activité d'une journée où les deux pointes du M sont les deux maximums de la journée (souvent entre 10 heures et 12 heures et entre 14 heures et 16 heures).

Restitution

Lorsque la campagne de tests est terminée, il convient, par l'analyse des résultats, de mettre en évidence les éléments définis comme exigences dans le Plan de tests et de vérifier que ceux-ci soient conformes. Il est nécessaire également, de préciser dans le Rapport de tests de charge les préconisations de paramétrage pour la mise en production, rappeler le cadre applicatif et paramètres techniques ou conditions pour lesquels les résultats ont une valeur  probante. Lorsque le périmètre définit dans le Plan de tests n'a pas pu être respecté, il faut émettre des réserves dans le Rapport de Test.

 

 

Co-rédigé par Philippe Naveau et Marc Tuffreau