A quand une professionnalisation du métier de testeur de performance ?

En France, il n'y a peu de cursus, de diplôme ou de certificat professionnel du métier de testeur de performance.

Parcours diplômant ?

En France, il existe très peu de parcours diplômants orienté tests et encore moins sur les tests de performance.

Cela semble une expérience qui ne peut s'acquérir que via des formations spécialisées ou/et sur le tas.

On préfère vendre aux jeunes des filières de développement où ils créaient une application de A à Z entièrement nouvelle.  Ca existe mais la TMA (Tierce Maintenance Applicative) est beaucoup plus courante que de commencer un projet de zéro notamment pour des jeunes recrues.

L'ISTQB:

En dehors de la France, il a le "ISTQB" qui est un institut international qui propose des certifications plutôt orientées tests applicatifs. Il existe pourtant un chapitre sur les tests de performances.

Les diverses phases des tests de performance vu par l'ISTQB :

Cela est juste du côté de la description des étapes.

Quant à la description des métriques, on pourrait y voir une part "trop belle" à la moyenne.

Le métier de "testeurs de performance":

N'ayant pas de vraie discipline dédiée aux tests de performance dans les parcours diplômants, la plupart des testeurs de performance actuels sont arrivés à ce métier ou cette activité par le fruit du hasard ou de la passion.

Et c'est triste à dire mais :

• Il ne suffit pas de télécharger un outil de stress applicatif pour s'improviser testeur de performance (voir mon autre article)
• Faire ça depuis des années ne suffit pas (voir encore un autre article)
• Trop souvent les PERFS, c'est seulement A LA FIN, c'est à dire en production qu'on voit le souci et qu'on ne s'en souci pas avant.  Et cela arrive encore même en 2020... (et là, c'est bien le chef de projet qui a manqué de réalisme et d'anticipation lorsque ce genre de chose arrive, le testeur de perf n'y est pour rien)

Ce qui ferait un bon cursus de "testeur de perf":

 En plus de cours d'informatique, il faudrait des cours de maths notamment sur :

• les statistique descriptives (centiles, histogrammes, ACP...)
• les tests statistiques (intervalle de confiance, ANOVA, Khi Deux, tests non paramétrique..)
• les plan d'expérience  (notamment lors d'ajustement de "n" paramètres lors des tests)
• les séries chronologiques 

Pour renforcer l'expertise sur la fiabilité des applications, des cours en sûreté de fonctionnement (= des maths encore derrière).

Le testeur de performance rédige un rapport pour ses pairs et aussi pour des non spécialistes, il devrait donc y avoir une composante forte de :

• français (pour bien rédiger)
• communication (le testeur de perf doit interagir avec de multiples acteurs et les comprendre et se faire comprendre lui aussi)
• psychologie (être factuel et éviter tout sentiment ou opinion dans le rapport ou échange)

Et vous, qu'en pensez-vous ?

Test de performance et série chaotique, des points communs ?

Quels points communs entre les séries chaotiques et les tests de performance ?

Petite définition des séries dites "chaotiques" :

Les séries dites chaotiques font partie en physique de l'ensemble des systèmes dynamiques eux-mêmes pouvant être classés parmi les séries temporelles.

Ce qui différencie les séries chaotiques des autres systèmes dynamiques, ce sont :

• une sensibilité aux conditions initiales (pouvant en entraîner des différences très marquées lorsque la série évolue dans le temps ensuite)
• un certain déterminisme (contrairement à ce que le nom "chaotique" semble suggérer, si on connait les conditions initiales, son évolution dans le temps est prévisible ensuite) 
• une forte récurrence

Quel est le lien avec les tests de performance ?

Il y a un tout un pan primordial des tests de performance auquel peu de gens font attention et qui pourtant fait toute la différence entre un bon test et un test impossible à reproduire.

Il s'agit bien sûr des conditions initiales du test de performances:

• Quelle est l'architecture utilisée ? Est-t-elle iso-prod ?
• Quels matériels physiques sont utilisés (version du CPU, taille mémoire, type de disque dur, type de carte réseau utilisée..) ?
• Quels logiciels sont utilisés ? (L'OS est-il virtualisé ou "dockerisé" ?), Quel est l'OS et sa version précise (n° de patch), quel est l'antivirus et sa politique de scan temps réel ?
• Quels middleware sont installés (leur version précise) ? 

Ensuite viennent d'autres questions concernant l'application et son backend :

• Quelle est la version exacte de l'application ? de ces paramétrages techniques (pool vers la base de données, ou pool de thread http...) Est-on bien en mode ERROR dans les logs ?
• La base de données a-t-elle bien une volumétrie représentative de celle prévue en production ? En effet, combien de tests de performance sont fait avec une base quasiment vide ? La base (si relationnelle) a-t-elle eu un re-calcul de ses statistiques pour améliorer la performance de l'optimiseur des requêtes? 

Autres éléments qui concourent aux conditions initiales:

• Des sondes OS et/ou JVM sont-elles en place avec le risque de léger overhead que cela présente ? Des APM de type DynaTrace sont-ils démarrés sur le Front et le backend ?
• Quel est l'outil de test de performance ?  Pareil quelle version , quel paramétrage et plugins éventuels ?
• Quel est la version du script d'injection ? A-t-on versionné toutes les variantes du script d'injection avec notamment : la durée de montée en charge, la durée du plateau, le nombre de VUser, le comportement en cas d'erreur, le temps d'attente (thinkTime) min/max, etc...

Autre élément: le déterminisme.

En effet, connaissant le nombre de VUsers lors de la montée en charge, la même application va réagir de la même façon (les conditions initiales), les temps de réponse seront normalement identiques pour le même tir avec exactement les mêmes paramètres.

Et justement, comme toute expérimentation scientifique, chaque tir de performance devrait suffisamment bien documenter ses conditions initiales pour qu'une éventuelle seconde équipe de contre-expertise de test de performance puissent reproduire le même comportement dans les mêmes conditions.  J'ai déjà eu à jouer ce rôle où sur un projet sensible, c'est même 3 équipes différentes qui ont fait ce travail de contre-expertise pour valider le résultat obtenu par une première équipe.

Un exemple dans le domaine de tests hardware

Lorsqu'un composant hardware est testé, les magazines de tests vont en général décrire rapidement les autres composants de l'ordinateur et les logiciels utilisés.

Mais certains font l'impasse dessus, exemple ici pour un test de carte 3D avec un modèle RTX 2070 de NVIDIA (je n'ai pas de sponsor) :

• Chez les numériques : très peu de détails quand au protocole de test (on sait juste que le boîtier est fermé lorsqu'ils testent la chaleur dégagée pour la carte)
• Chez Tom's Hardware, moins de détail, mais il existe un dossier dédié décrivant comment le site teste des cartes 3D
• Chez Comptoir-Hardware, il y a une page dédiée au protocole de test très complète.

Juste à travers ces 3 exemples et pour rejoindre le fait que faire des tests depuis des années ne garantit pas de faire de bons tests, cela illustre bien que décrire comment on fait le test (et avec quelles conditions initiales) est aussi important que le résultat du stress applicatif effectué par l'outil de test de performance.

Conclusion

J'espère que ce long article vous a convaincu de mieux documenter ce qui se passe au début de vos tirs de performance et ne pas se contenter juste du résultat qui (je ne le répéterais jamais assez) ne peut se résumer à la moyenne.

Il faut rédiger 2 documents :

1. un résumé compréhensible par tout le monde 
2. et un document plus détaillé (pour nos pairs) en cas où une contre-expertise de performance serait demandée.

Test de performance : Quand le meilleur outil ne suffit pas

LoadRunner, la "Rolls Royce" des outils de tests de performance n'aide pas à faire de bons rapports

LoadRunner est considéré dans la "profession" de testeurs de performance comme la Rolls Royce des outils de stress applicatif.  Multi-protocole, multiples sondes intégrées, création de script et de rapport simplifiée, fonctionnalités avancées et prix exorbitant; ne pas connaître LoadRunner est une gageure en test de performance.

La qualité des rapports de LoadRunner

Malgré toutes ses qualités, son défaut majeur qui est le prix de sa licence.
En outre, très clairement, LoadRunner n'est pas fait par des statisticiens et ça se voit...

Exemple de tableau "typique" généré automatiquement par LoadRunner (le tableau est orienté pour mettre en avant la moyenne alors que le 90è centile est beaucoup plus intéressant à suivre ainsi que le nombre de tir effectué et la valeur max)

Exemple de graphique "typique" généré par LoadRunner.  Avec un bas un tableau où les min/max et la médiane (50ème centile) sont les seules informations utiles, le focus reste sur la moyenne et son écart-type.

Mais alors que manque-t-il à ces rapports de tirs de performances ?

En bien, une vision "statisticienne" de l'histoire que le tir de performance raconte et qui NE PEUT PAS se résumer à un simple chiffre: la moyenne.

On va d'abord s'intéresser aux chiffres suivants :

• Nombre total de chaque scénario joué sur la période. Cela permettra de déterminer combien de scénario passent en dessous ou au-dessus des centiles.
• avec aussi le nombre ou pourcentage d'échecs. 
• et bien sûr le nombre de VUsers demandés

Un peu de statistique descriptive:

En statistique, pour décrire la distribution des diverses observations d'un échantillon (où on sous-entend que les données étudiées sont le sous-ensemble appartenant à une loi statique plus globale), on va utiliser plusieurs métriques "classiques":

le minimum, la moyenne, l'écart-type (ou la variance), le mode, la médiane le maximum, l'étendue

On peut aussi utiliser les quartiles jusqu'aux centiles.

Graphiquement, on va pouvoir utiliser des histogrammes et courbes de répartition pour montrer de 2 façons différentes la répartition des temps de réponse et idéalement que sur la période du plateau après la montée en charge progressive en terme de "virtual user" (vusers).

Histogramme montrant la répartition des temps de réponse durant la durée du test de performance

Courbe représentant les temps de réponse triés sur l'axe Y des centiles (du 1er centile au 100è) et sur l'axe des X les temps de réponse correspondant.

Une courbe avec les centiles est utile, en connaissant le nombre de scénarios en succès total (dans cet exemple 800), on peut déterminer combien de tirs ont dépassé les 1000ms.

ICI, 67,25% des tirs sont en dessous des 1000ms.
Mais cela veut dire aussi que 100-67,25=32,75% des tirs dépassent 1 seconde et vont jusqu'au maximum (ici: 200secondes)
En quantité, cela fait 800*32,75% = 200 requêtes qui ont dépassées 1 seconde.

Pour mesurer des SLA (Service Level Agreement) d'un système, on va s'intéresser plus aux centiles qu'à la moyenne.  Au 90ème centile, quel est le temps de réponse le plus grand ? On assure donc que 90% du trafic sur tel scénario sera en dessous d'un certain seuil de temps de réponse.  

Quoi faire pour améliorer le système pour que 95% ou 99% des requêtes passent en dessous d'un certain seuil ? C'est avec les centiles que l'on peut travailler pour savoir gérer le 80/20 (la fameuse loi Pareto) pour se concentrer sur les 20% de problèmes qui pourront augmenter d'un seuil significatif les temps de réponse (optimisation OS, JVM, serveur d'application et applicative notamment au niveau des algorithmes et consommation de ressources).

D'autres graphes et représentations peuvent être utiles mais n'ont pas le même poids que le graphe de temps de réponse par centile:

• Temps de réponse par nombre de VUsers (utile pour voir à quel moment le système décroche, ex: un pool de thread saturé, une taille mémoire atteinte...)
• Nombre de transactions par nombre de VUsers

Le meilleur graphe en test de performance :

Le graphique précédent montre le tri des temps de réponse mais on perd la notion temporelle du tir de performance.

Le graphique suivant propose une vision en centile (ou en quartile) à chaque seconde de notre tir de performance, cela suppose bien sûr  pour être exploitable avoir plus de 10 sollicitations par seconde durant le test de performance.

Ce graphique montre les temps de réponse en quartile  et centile durant toute la durée du tir de performance.

Comment comprendre ce graphique et les couleurs ?

• En terme temporel, la seconde étudiée est 1mn 30sec après le début du test. Les centiles ou quartiles présentés durant cette seconde-là représente de façon triée les meilleures au plus lentes requêtes effectuées durant cette intervalle d'une seconde.
• 25%  des requêtes les plus rapides (=le 1er quartile) sur cette seconde en cours apparaissent en rouge, car si cette zone rouge est bien visible sur le graphique c'est que les 25% des meilleurs réponses sont déjà lentes. Ici, sur la photo d'exemple, au 25è centile, les temps de réponse vont jusqu'à 259ms.
• 50% (le 50è centile) correspond à la médiane. On est sur une couleur rouge orangée, notre seuil max correspond à la moitié des sollicitations sur cette seconde en cours. Ici, on est à 284ms.
• 75% (ou 3ème quartile) apparaît en orange où dans l'exemple sur la photo, les temps de réponse peuvent aller sur cette période analysée jusqu'à 3 005ms.
• Ainsi de suite sur les suivants mais de moins en moins rouge. 
• Les derniers centiles 99% et 100% apparaissent en vert (ici à ~146secondes) car le focus est bien de se concentrer sur l'amélioration des zones les plus rouges (que les meilleurs temps de réponse soient eux-mêmes bien performants avant de voir pour traiter les valeurs "aux limites").

D'où proviennent ces graphiques ?

D'un site BlazeMeter proposant d'uploader ces tirs de performances (à anonymiser avant) pour exploiter de façon statistique les tests effectués avec l'outil Open Source Apache JMeter 
Voici une url avec des exemples de rendu : https://sense.blazemeter.com/examples

Conclusion

Comme pour la conduite automobile avoir une Rolls-Royce fait-il de son possesseur un bon conducteur ? Pour paraphraser les inconnus ou plus vieux avec 3 compères : Blondin, Tuco et Sentenza, il y a 2 catégories de testeurs de performances. je vous laisse compléter selon la version des inconnus ou de Sergio Leone.

Avoir un outil hors de prix considéré comme le Nec Plus Ultra ne suffit pas à faire un bon test de performance.  Des outils gratuits comme JMeter et le site BlazeMeter donne un niveau bien meilleur en terme de rapports et graphiques sur l'histoire que raconte le tir de performance.

De plus, des notions de statistique et de pédagogie sont nécessaires pour expliquer et résumer sans parler de moyenne un test de performance.

Attention, j'ai vu qu'il existe une toute nouvelle version 2020 de LoadRunner que je n'ai pas pu tester mais qui j'espère tente de gommer les principaux défauts que je lui ai adressé ici.

A noter que les tests de performances ne peuvent pas être représentatif à 100% de tous les scénarios et usages d'une application, il convient donc, une fois l'application lancée en production, de mesurer également les temps de réponse réels et de calculer les centiles de ces temps de réponse.

Comment rater professionnellement ses tests de performance ?

Comment rater ses tests de performance malgré un professionnalisme avéré ?

Les tests de performances applicatifs sont une activité très complexe où chaque détail peut compter. La moindre négligence dans certaines étapes peut mettre à mal la meilleure volonté de bien réaliser les tests et aussi de produire un rapport factuel.

Résumé grossièrement, que fait-on lors d'un test de performance ?

On stresse une application pour voir comment elle réagit lorsque celle-ci est fortement ou longuement sollicitée sur des scénarios établis par la maîtrise d'oeuvre (MOE). En général, on vérifie aussi les ressources consommées (CPU, RAM, I/O) par l'application lors de ces stress.

Il y a 5 problèmes insolvables (et à accepter) lors des campagnes:

1. On ne peut tester 100% des usages, on doit cibler certains scénarios fonctionnels (ou ceux qui sont techniquement complexes)
2. Parmi les scénarios choisis, ceux-ci sont rejoués automatiquement. La qualité de cette pseudo automatisation peut varier selon l'équipe et l'outil dédié aux tests de performances (variabilisation, temps d'attente, détection de mots clés dans les réponses serveur, ...)
3. Les tests sont réalisés sur une plate-forme qui ne sera jamais équivalente à celle de production
4. Le temps total perçu côté du client (depuis son navigateur) est rarement pris en compte intégralement (les applications Front de type SPA ont une latence lié à Javascript, au accès DOM, au garbage collector du navigateur)
5. Loi de Murphy oblige, même avec une campagne de tests de performances "parfaite",  des aléas peuvent survenir le jour de la mise en prod et/ou de l'exploitation avec le nombre d'utilisateur nominal de l'application.

Exemple des tests de performance sur les cartes 3D et jeux vidéos :

Pour se convaincre qu'on peut professionnellement faire très sérieusement des tests qui ne servent pas à grand chose, voici un domaine que certains d'entre vous doivent connaître depuis des années, les tests de carte 3D sur les jeux vidéo pour choisir entre tel ou tel autre modèle de NVIDIA ou AMD/ATI.

L'idée ici n'est pas de tester une application mais une carte 3D mais les principes restent les mêmes :

1. Stresser le composant (ici avec des jeux 3D)
2. Mesurer ses performances (on parle malheureusement trop de moyenne qui n'est pas un bon indicateur)
3. Mesurer la consommation de ressources (pour les cartes 3D, on s’intéressera en autre aux Watts et au bruit) 
4. Faire un rapport pour résumer tout ça pour un public pas forcément technique en donnant une conclusion voire des axes d'améliorations

Le test de carte graphique 3D est établi depuis leur toute première apparition en 1996.  Les sites Web  et magazines de guide d'achat et de comparatif de matériel informatique font ça depuis de nombreuses années.

Cependant, le seul est unique indicateur souvent utilisé est (et reste pour la plupart d'entre eux) la MOYENNE.   Cet indicateur pour un statisticien n'est pas un indicateur fiable et ne devrait pas être utilisé lors de comparaison (pas sans tests statistiques de type ANOVA [pour vérifier si la moyenne de chaque échantillon peut potentiellement issues de la même loi] et sans évoquer les intervalles de confiance).

Voici les sites web qui n'utilisent QUE la moyenne pour tester les cartes 3D et quelques exemples :

• AnandTech, tests récent de juillet 2019 : Ne précise même pas que c'est la moyenne sur la durée d'un scénario joué
• TechPowerUp, tests de juillet 2019.
• Ginjfo, test récent d'avril 2019, pareil, aucune précision qu'on parle de moyenne.
• Comptoir-Hardware
• Les Numériques  
• 01Net 
• CowCotLand 
• HardWare.fr (avant leur arrêt) test de 2017 :

Finalement, le seul site à faire différemment des autres et depuis 2012, c'est Tom's Hardware.
Que nous raconte ce test de 2012 ? https://www.tomshardware.fr/les-performances-de-far-cry-3/6/

Test Tom's Hardware datant de 2012

Que voit-on ?  Dans chaque jeu, si celui-ci ne dispose pas d'un benchmark intégré permettant de rejouer automatiquement la même séquence, un déplacement "à la main" est effectué par le testeur dans le jeu pendant que des sondes enregistrent le comportement de la carte 3D durant cette séquence temporelle.

Il y a donc des hauts et des bas dans le nombre d'image par seconde durant chaque scénario enregistré. Le taux d'image par seconde est rarement constant. C'est aussi le cas lors d'un tir de performance sur une application.

Toujours sur cette image, on voit en pointillé orange que le CrossFire d'ATI Radeon HD 7870 a une variation très importante de son nombre d'image par seconde.  Parler de moyenne ici ne reflétera pas la réalité.  Ça va résumer grossièrement.

Dès 2012, Tom's Hardware propose une autre valeur que la moyenne (en plus de montrer la courbe temporelle liée au scénario enregistré) : La valeur minimum, en effet, malgré ses variations, qu'elle est la valeur minimum que je pourrais avoir sur tel jeu avec quelle carte 3D ? 

Tests Tom's Hardware indiquant dès 2012 moyenne et minimum

Tom's hardware a continué à explorer ces autres aspects non liés à la "pure" moyenne:
Dès 2016, ils parlent de temps de création de chaque image (Frame Time):

Test Tom's Hardware indiquant le temps de fabrication de chaque image selon la carte 3D

Ils introduisent aussi la notion de variance entre chaque frame :

Dès 2018, ils introduisent la notion de centile :

Ici, pour rappel, la variation du nombre d'image par seconde selon le temps (et du scénario joué) et de la carte 3D

Ici en plus de la moyenne, on a le 99ème centile indiquant que, durant le scénario joué,  99% du nombre d'images générées par seconde n'ont pas chuté plus bas que cette valeur.  

Ci-contre, les centiles avec un zoom sur la zone 50% (la médiane) jusqu'à 99,9 centile (ou ici le minimum est considéré comme un souci et devient le 100ème centile).  En test de perf applicatif, le maximum sera le 100ème centile.

Ici, un autre indicateur utile en test de perf applicatif, la répartition des temps de réponses sous forme d'histogramme.

Quelle conclusion à travers le prisme des tests de carte 3D ?

Peut-on dire que les autres magazines et sites Web de tests matériels sont moins bons ou moins professionnels que Tom's Hardware dans leurs tests ?  Evidemment NON !

Cependant, les tests effectués de la manière la plus professionnelle peuvent parfois être partiellement utiles.

Stresser une carte 3D comme une application ne peut pas se résumer au seul chiffre d'une moyenne.

Chaque scénario de test raconte une histoire qui peut être perçue plus fidèlement avec d'autres éléments que la moyenne: 

• le nombre de scénario exécutés réussis et en échec
• le graphique temporel des temps de réponse
• la répartition des temps de réponse sous forme d'histogramme
• les bornes minimum et maximum ainsi que la médiane (50% des effectifs triés)
• les centiles

 Ceci est le premier article sur la performance applicative, l'idée est de montrer que l'expérience de plusieurs années dans un domaine ne suffit pas