Test de performance - Définition

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 possible. Un résultat plus ou moins précis maintenant vaut mieux qu’un résultat très 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 identique à 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 système à tester, les processus métier, et les objectifs (métiers, techniques, économiques)
• Définir les scénarios, par rapport à une analyse complète des risques métiers et techniques
• Définir le modèle de charge, par rapport 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 système

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, permettant 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, en général lors d'un test de stress. Cette modélisation contient donc un nombre d'utilisateurs à simuler, leur répartition sur les différents scripts (scénarios fonctionnels), leurs rythmes d'exécution respectifs, ainsi que les profils de montée ou descente de charge des groupes d'utilisateurs.

Acteurs et outils du marché

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

• 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, surtout pour les applications Web. Les outils les plus représentatifs du marché sont :

• HP LoadRunner/Performance Center, ex produit Mercury Interactive, le leader du marché.
• Micro Focus QALoad, ex produit Compuware racheté en 2009.
• Oracle Load Testing, ex produit Empirix, racheté par Oracle Corporation en 2008
• IBM Rational Performance Tester.
• Borland SilkPerformer, ex produit Segue Software (Borland ayant été racheté entièrement par Micro Focus en 2009).
• Radview WebLOAD.
• OpenSTA (produit Open Source), et Quotium QTest, tous deux ex produits Cyrano.
• Apache JMeter (produit Open Source).

Gestion des données de test

On distingue 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 particulièrement 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. Toutefois, IBM avec Optim et MicroFocus (ex-Compuware) avec FileAid se sont positionné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 quasiment incontournable 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 l'ensemble 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.