Un test de performance est un test dont l'objectif est de déterminer la performance d'un dispositif informatique.

L'acception la plus courante de ce terme est celle dans laquelle ces tests logiciels vont avoir pour objectif de mesurer les temps de réponse d'un dispositif applicatif selon sa sollicitation. Cette définition est par conséquent particulièrement proche de celle de test de charge où on mesure le comportement d'un dispositif selon la charge d'utilisateurs simultanés.

Types de Tests

Ces tests peuvent être de plusieurs types, surtout :

• Test de Charge : c'est un test au cours duquel on va simuler un nombre d'utilisateurs virtuels prédéfinis, pour valider l'application pour une charge attendue d'utilisateurs. Ce type de test sert à mettre en évidence les points sensibles et critiques de l'architecture technique. Il permet en outre de mesurer le dimensionnement des serveurs, de la bande passante indispensable sur le réseau, etc.

• Test de Performance : proche du Test de Charge, c'est un test au cours duquel on va mesurer les performances de l'application soumise à une charge d'utilisateurs. Les informations recueillies concernent les temps de réponse utilisateurs, les temps de réponse réseau et les temps de traitement d'une requête sur le (s) serveur (s). La nuance avec le type précédent réside dans le fait qu'on ne cherche pas ici à valider les performances pour la charge attendue en production, mais plutôt vérifier les performances intrinsèques à différents niveaux de charge d'utilisateurs.

• Test de Dégradations des Transactions : c'est un test technique essentiel au cours duquel on ne va simuler que l'activité transactionnelle d'un seul scénario fonctionnel parmi l'ensemble des scénarios du périmètre des tests, de façon à déterminer quelle charge limite simultanée le dispositif est capable de supporter pour chaque scénario fonctionnel et d'isoler peut-être les transactions qui dégradent le plus la totalité du dispositif. Ce test peut tenir compte ou non de la cadence des itérations, la représentativité en termes d'utilisateurs simultanés vs. sessions simultanées n'étant pas ici un objectif obligatoire, s'agissant ici plutôt de déterminer les points de contention générés par chaque scénario fonctionnel. La démarche utilisée est d'effectuer une montée en charge linéaire jusqu'au premier point de blocage ou d'inflexion. Pour dépasser ce dernier, il faut paramétrer méthodiquement les composants dispositifs ou applicatifs afin d'identifier les paramètres pertinents, ce jusqu'à obtention des résultats satisfaisants. Méthodologiquement, ce test est effectué avant les autres types de tests tels que performance, robustesse, etc. où l'ensemble des scénarios fonctionnels sont impliqués.

• Test de stress : c'est un test au cours duquel on va simuler l'activité maximale attendue tous scénarios fonctionnels confondus en heures de pointe de l'application, pour voir comment le dispositif réagit au maximum de l'activité attendue des utilisateurs. La durée du palier en pleine charge, généralement de 2 heures, doit tenir compte du remplissage des différents caches applicatifs et clients, mais aussi de la stabilisation de la plateforme de test suite à l'éventuel effet de pic-rebond consécutif à la montée en charge. Dans le cadre de ces tests, il est envisageable de pousser le stress jusqu'à simuler des défaillances dispositifs ou applicatives afin d'effectuer des tests de récupération sur incident (Fail-over) ou pour vérifier le niveau de service en cas de défaillance.

• Test de Robustesse, d'endurance, de fiabilité : il s'agit de tests au cours duquel on va simuler une charge importante d'utilisateurs sur une durée assez longue, pour voir si le dispositif testé est capable de supporter une activité intense sur une longue période sans dégradations des performances et des ressources applicatives ou dispositif. Le résultat est satisfaisant quand l'application a supporté une charge supérieure à la moitié de la capacité maximale du dispositif, ou quand l'application a supporté l'activité d'une journée ou plusieurs jours/mois/années, pendant 8 à 10 heures, sans dégradation de performance (temps, erreurs), ni perte de ressources dispositifs.

• Test de capacité, Test de montée en charge : c'est un test au cours duquel on va simuler un nombre d'utilisateurs sans cesse croissant de façon à déterminer quelle charge limite le dispositif est capable de supporter. Peut-être, des paramétrages peuvent être effectués, dans la même logique que lors des tests de dégradation, l'objectif du test étant néanmoins ici de déterminer la capacité maximale de la totalité dispositif-applicatif dans une optique prévisionnelle (cf. Capacity planning, Gestion de la capacité en français).

• Test aux limites : c'est un test au cours duquel on va simuler généralement une activité bien supérieure à l'activité normale, pour voir comment le dispositif réagit aux limites du modèle d'usage de l'application. Proche du test de capacité, il ne recouvre pas uniquement l'augmentation d'un nombre d'utilisateurs simultanés qui se limite ici à un pourcentage habituellement prédéfini, mais également les possibilités d'augmentation du nombre de processus métier réalisés dans une plage de temps ou en simultané, en jouant sur les cadences d'exécutions, les temps d'attente, mais également les configurations de la plateforme de test dans le cadre d'architectures redondées (Crash Tests).

• Il existe d'autre types de tests, plus ciblés et fonction des objectifs à atteindre dans la campagne de tests : Test de Benchmark (comparaisons de logiciel, matériels, architectures, ... ), Tests de non-régression des performances, Tests de Composants, Tests de Volumétrie des données, etc. Étant entendu qu'en principe un type de test correspond à un type d'objectif, et que dans une matrice de couverture des tests les résultats se recoupent obligatoirement, il est rare (et coûteux) de réaliser la totalité de ces tests pour une application donnée.

Si l'application est déjà en production, ou en phase pilote, on peut aussi, pour connaître les performances du dispositif, réaliser une métrologie, qualifiée fréquemment de "métrologie de suivi de site"^{[réf.  nécessaire]}, qui permettra d'observer dans le détail le fonctionnement du dispositif sur la base d'actions réelles des utilisateurs. Les résultats d'une telle campagne de métrologie servant à connaître les fonctionnalités réellement utilisées, et leur fréquence d'utilisation, ils peuvent ensuite servir de base pour orienter les tests à réaliser dans des simulations futures.

Définition du plan de tests

Le plan de tests est l'expression du besoin de la campagne de tests. On y trouve la présentation du projet (résumé, architecture technique et logicielle), les objectifs, le modèle de charge, le type de tests à réaliser, les scénarios fonctionnels (ou cas d'utilisation) à tester accompagnés des jeux de données nécessaires, et un planning d'exécution de ces tests.

Les jeux de données permettent de simuler au plus juste la réalité. Un jeu de données peut, par exemple, consister en n logins et n mots de passe, donnant la possibilité d'ainsi de simuler des utilisateurs différents se connectant à l'application.

Le modèle de charge consiste, à partir d'un modèle d'usage de l'application (nombre d'utilisateurs simultanés, nombre de processus métier réalisés, périodes d'utilisation, heures de pointe... ) à modéliser la charge qui devra être simulée et qui se devra d'être représentative de l'activité réelle ou attendue de l'application en pic, généralement lors d'un test de stress. Cette modélisation contient par conséquent un nombre d'utilisateurs à simuler, leur répartition sur les différents scripts (scénarios fonctionnels), leurs rythmes d'exécution respectifs, mais aussi les profils de montée ou descente de charge des groupes d'utilisateurs.

Méthodologie

Les tests de performance doivent être implémentés et réalisés tout au long du cycle de développement, et ce le plus tôt envisageable. Un résultat plus ou moins précis désormais vaut mieux qu'un résultat particulièrement précis plus tard.

• Tester de façon large, puis de façon approfondie
• Tester dans un environnement contrôlé
• L'environnement de test doit être dans la mesure du possible semblable à l'environnement de production, à défaut à une échelle étalonnée reconnue fiable permettant d'établir des abaques

Étape 1 : Analyse de Référence (l'analyse préliminaire consiste en l'enregistrement d'un ou de plusieurs scénarios (ou cas d'utilisation) pour mieux comprendre l'application et l'étendue du test ).

• Définir le dispositif à tester, les processus métier, et les objectifs (métiers, techniques, économiques)
• Définir les scénarios, comparé à une analyse complète des risques métiers et techniques
• Définir le modèle de charge, comparé au modèle d'usage de l'application
• Caractériser les données pour chaque scénario
• Enregistrer les scénarios

Étape 2 : Tests Préliminaires

• Mettre en œuvre des moyens et définir la plate-forme de test
• Exécuter les tests de charge (préliminaires)
• Analyser les résultats

Étape 3 : Test de Charge à Grande Échelle

• Mettre en œuvre des moyens et définir la plate-forme de test
• Exécuter les tests de charge
• Analyser les résultats
• Optimiser le dispositif

Outillage nécessaire

Comme il s'agit généralement de simuler un nombre d'utilisateurs important, il s'avère indispensable d'automatiser ces tests. L'automatisation des tests, que ce soit pour des tests de performance ou non, nécessite de répondre à deux problèmes :

• être capable d'enchaîner des actions sur le dispositif selon des scénarios qui ont du sens pour les objectifs de test
• valoriser ces actions sur des données qui sont pertinentes à la fois vis-à-vis des scénarios et de l'état du dispositif au moment où on exécute ces tests

Prenons par exemple le cas du test de performance d'un portail eCommerce dans lequel on va adresser surtout la fonction de constitution d'un panier d'achat. Il faut disposer d'un mécanisme d'automatisation des actions de sélection d'article, de validation de commande, etc. Mais il faut aussi valoriser ces actions en donnant les articles qui seront effectivement commandés par les utilisateurs virtuels (simulés) dans le cadre du test de performance. Or, la nature et le nombre de ces articles peuvent fluctuer selon le contenu de la base de données d'articles de l'application, du profil de consommateur de l'utilisateur simulé, ou encore de la période de l'année qu'on simule dans le test .

Une plate-forme de test de performances va le plus souvent comporter :

• Un injecteur de charge (appelé aussi générateur ou moteur de charge)  : logiciel qui va être capable de simuler les actions des utilisateurs et par conséquent générer la charge sur l'application. Ces actions sont définies dans des scripts automatisant des scénarios et valorisés sur un lot de données spécifique. On peut par conséquent distinguer deux catégories d'outils :
  • Les simulateurs d'utilisateurs qui, grosso modo, instancient les scripts de test sur la plupart d'utilisateurs (virtuels)
  • Les générateurs de données qui vont permettre de valoriser les scripts utilisés et ainsi assurer que chaque utilisateur virtuel n'effectue pas précisément la même opération ce qui n'aurait pas énormément de sens du point de vu des performances mesurées ensuite.
• Des sondes : positionnées au niveau du dispositif cible, elles permettent de remonter des mesures dont l'objet est de savoir comment réagissent individuellement des composantes du dispositif. Les éléments sur lesquels on va généralement placer des sondes sont l'utilisation de la mémoire, processeur, disque et réseau. Il est bien entendu préférable d'utiliser des sondes qui ne perturbent pas le dispositif, en privilégiant au maximum les API disponibles en natif au sein des composants techniques, et en évitant l'utilisation d'agents.

Les solutions de tests de performances Web vont permettre de simplifier et d'automatiser les tests : création plus ou moins automatisée des scénarios de tests, configuration des scénarios avec ou sans script, simulation d'utilisateurs virtuels avec collecte des mesures (et génération automatique de rapports), etc.

Acteurs et outils du marché

Plusieurs outils permettent de réaliser des tests de performances ; ce qui les différencie, ce sont surtout :

• La technologie employée (mode graphique, mode protocolaire, scripting, monitoring, reporting).
• Le type d'application testée (web, SAP, Oracle, RDP, Citrix, Mainframe, Windows Sockets.... ).
• Le prix des licences.
• Le coût de la mise en œuvre (en dehors des licences).
• La maturité et l'efficacité du produit.
• Le support.

Selon plusieurs cabinets d'analyse tels IDC ou Gartner Group, des leaders se démarquent sur le marché, mais il existe aussi quantité de produits Open Source ou à prix réduits, en particulier pour les applications Web. Les outils les plus représentatifs du marché sont :

• HP LoadRunner/Performance Center^[1], ex produit Mercury Interactive, le leader du marché.
• Micro Focus QALoad^[2], ex produit Compuware racquis en 2009^[3].
• Oracle Load Testing^[4], ex produit Empirix, racquis par Oracle Corporation en 2008
• IBM Rational Performance Tester^[5].
• Borland SilkPerformer^[6], ex produit Segue Software (Borland ayant été racquis entièrement par Micro Focus en 2009^[7]).
• Radview WebLOAD^[8].
• OpenSTA (produit Open Source) ^[9], et Quotium QTest^[10], tous deux ex produits Cyrano.
• Apache JMeter (produit Open Source) ^[11].

Gestion des données de test

On peut distinguer dans la gestion des données de test deux principaux types d'acteurs. Il y a ceux qui s'appuient sur les données de production et proposent des outils d'extraction et de transformation des données de production et ceux qui s'appuient sur des mécanismes de génération pour produire à partir de rien (ou presque) les jeux de données de test .

Les outils basés sur l'extraction sont spécifiquement pertinents pour construire des bases de test de référence comme par exemple des catalogues de produits. D'ailleurs, n'importe quel outil d'extraction de base de données doit pouvoir faire l'affaire. Cependant, IBM avec Optim et MicroFocus (ex-Compuware) avec FileAid se sont situés sur ce marché avec des outils qui, à l'origine, servent à faire de la duplication de base de données (pour adresser des problématiques d'archivage des données anciennes, par exemple).

Une solution basée sur la génération automatique est presque inévitable pour produire les différentes transactions (constitution d'un panier d'achat par exemple) qui vont servir à valoriser les scripts de test . Si la variabilité du comportement des utilisateurs virtuels est un critère de pertinence pour la campagne de test alors chacune des transactions injectées dans une campagne de test doivent être originales et globalement la totalité des transactions doivent avoir une cohérence vis à vis des objectifs de tests. Sur le marché des outils de génération de données on trouve moins d'acteurs, mais on peut noter Grid-Tools, une société anglaise qui édite DataMaker et GenieLog qui édite l'atelier de production de jeux de données GEDIS Studio.

Organismes du secteur

• Le TPC (Transaction Processing Performance Council) est un organisme indépendant des constructeurs qui définit des protocoles de test et publie des classements, suivant plusieurs critères^[12]. Le plus connu est le TPC-C pour le transactionnel, mais il existe des classements pour les dispositifs décisionnels (TPC-H). Les classements ne sont pas fait uniquement suivant la puissance, mais également suivant le rapport coût/performance^[13].
• Le SPEC (Standard Performance Evaluation Corporation) est un organisme indépendant sans but lucratif qui établit et publie des tests de performance de dispositifs, surtout un test de mesure de puissance CPU^[14].

Notes et références

Liens externes

• Catégorie benchmark de DMOZ

Principaux mots-clés de cette page : test - performance - charge - dispositif - utilisateurs - données - application - scénario - simuler - outils - objectif - produit - nombre - activité - résultats - temps - cours - duquel - fonctionnel - actions - virtuels - technique - production - transactions - modèle - base - utilisation - tester - scripts - marché -

---

Ce texte est issu de l'encyclopédie Wikipedia. Vous pouvez consulter sa version originale dans cette encyclopédie à l'adresse http://fr.wikipedia.org/wiki/Test_de_performance.
Voir la liste des contributeurs.
La version présentée ici à été extraite depuis cette source le 26/10/2010.
Ce texte est disponible sous les termes de la licence de documentation libre GNU (GFDL).
La liste des définitions proposées en tête de page est une sélection parmi les résultats obtenus à l'aide de la commande "define:" de Google.
Cette page fait partie du projet Wikibis.

---