
Les tests de performance sont les plus faciles à concevoir pour le grand public, chaque utilisateur ayant en tête un cas où le programme qu'il utilisait a cessé de répondre pendant un moment ou garde le souvenir d'un site informatique particulièrement peu réactif… Ces situations, et bien d'autres encore, relèvent de l'analyse de la performance d'un programme informatique et du matériel sur lequel il est exécuté.
Intérêt des tests de performance
Au-delà de l'aspect ergonomique et de l'impatience bien naturelle des utilisateurs, les tests de performance peuvent servir à éviter des situations critiques en les simulant.
Prenons le cas d'une fonction permettant de trier des nombres : l'histoire est classique et illustrait à une époque le dilemme des cas particuliers pouvant perturber un programme simple. La méthode longtemps considérée comme la meilleure, car la plus véloce, pour trier des nombres était celle nommée « Quick Sort » (tri rapide). Elle possède cependant un défaut : elle devient très lente dans certains cas, notamment quand la liste de départ est déjà presque triée. Ce défaut est si grand que les implémentations modernes du Quick Sort remanient considérablement l'idée de départ afin d'éviter que cette fonction, réputée ultra-rapide, ne s'avère extraordinairement lente dans certains cas, pouvant entièrement bloquer un programme et consommer à ce point de ressources en mémoire que d'autres programmes ne puissent s'exécuter en parallèle…
L'idée générale des tests de performance est de soumettre un système informatique, matériel et logiciel, à une charge de travail devant être supporté sans que l'utilisateur soit dans l'incapacité d'utiliser plus avant le programme. Les informations recueillies peuvent par exemple valider l'achat d'un matériel (un CPU multi-cœur pour un serveur) ou l'utilisation d'un algorithme informatique (un exemple bien connu : quelle librairie choisir pour chiffrer un fichier ou calculer l'empreinte de ce dernier ?).
Typologie des tests de performance
Certains tests sont censés simuler une activité habituelle : c'est le cas des tests de charge (le système tout entier supporte-t-il telle masse de données ?), tests qui peuvent évoluer en tests de performances proprement dits si l'on cherche à évaluer en interne la réactivité des éléments du système face à différents niveaux d'afflux de données. Si la charge du système est maximale il s'agit d'un « test de stress » qui porte l'ensemble du projet aux limites qu'il est censé supporter. Typiquement, la programmation web impose aussi des tests de « montée en charge » qui simulent l'arrivée d'utilisateurs toujours plus nombreux, permettant ainsi de vérifier que l'application supporte le « web scaling », sa capacité à monter en puissance au fur et à mesure que le nombre de personnes connectées augmentent.
Présentation des résultats
Les tests de performance peuvent être présentés selon un « bilan de tests » qui recense les résultats obtenus et oriente les décisions qui en découlent. Il est normalement présenté selon trois vues. La « vue utilisateur » reprend les temps de réponse perçus par l'utilisateur et les erreurs qu'il a pu rencontrer. La « vue métier » offre la vision que pourrait avoir un superviseur attentif au nombre d'utilisateurs connectés, aux processus lancés pour satisfaire les demandes des utilisateurs, etc… Enfin, la « vue technique » est essentiellement liée à la consommation mémoire et à l'utilisation des CPUs.
Conclusion
Les tests de performance débouchent sur des décisions critiques pour un projet : le choix du langage de développement, de tel algorithme, des investissements en matériels… Ces choix pèsent lourdement dans le cycle de vie d'un logiciel. Les entreprises n'hésitent donc plus à investir dans l'achat d'infrastructures permettant d'automatiser ces tests : c'est le cas du Mercury Interactive de Hewlett-Packard ou encore du produit open-source Apache JMeter.