Les tests de performances ?

On (et particulièrement moi) parle souvent de tests de performances. Je les aborde notamment lorsque je parle de déploiement continu. Je n’ai néanmoins jamais expliqué concrètement ce que sont les tests de performances ni en quoi ils consistent.

D’après la définition ISTQB les tests de performances sont « le processus de test pour déterminer les performances d’un produit logiciel ».

Que ce cache-t-il derrière cette appellation de « performances » ?

De manière générale lorsque que l’on parle de performances d’une application plusieurs idées nous viennent à l’esprit :

  • La vitesse de réponse de l’application à une demande (je veux voir mes contact, en combien de temps sont-ils affichés ?)
  • La capacité de l’application à répondre lors de pics de charge (ex : le nombre de visiteurs sur des sites de réservation lors du lancement de promotions)
  • La capacité de l’application à réagir lors de l’envoi de données erronées ou mal formatées (ex : mauvaise url sur une application de navigateur)
  • Plus rarement, pour les applications mobiles, la batterie consommée par l’application.

Tous ces scénarios ont des types de tests de performances dédiés comme les tests de « performances », les tests de « robustesse », les tests de « charge »…. Je vous invite à lire l’article du blog Hightest si vous souhaitez rentrer plus en détails sur les différents types de tests de performances.

Comment mettre en place ces cas de tests ?

Comme pour tous les tests il faut avoir un indicateur afin de comparer des résultats. L’indicateur peut être le ressenti, ce qui est de mon point de vue assez mauvais car dépend de l’utilisateur, mais provient de préférence de 2 autres points :

Pour spécifier des performances, il faut être très clair (on ne peut pas accepter des spécifications du type : l’application doit répondre rapidement ou la navigation doit être fluide). Il faut, en plus de définir les résultats attendus (ex : la page s’affiche en moins de 2 secondes), définir les conditions pour obtenir ces résultats en spécifiant l’environnement. Par exemple on peut donner un temps de réponse maximum sur un mobile particulier (2 secondes pour afficher la page du site sur un Honor 7 en 3G).

  • De l’historique de l’application :

Ici, on prend comme base les performances de l’application en production et on a pour but de les améliorer ou au pire, ne pas les dégrader (exemple : pas de dégradation du temps de réponse ou du % de réponse en Timeout… Ou bien améliorations de certains paramètres lorsque le but est d’améliorer ces performances). Comme pour les spécifications, l’environnement doit également être défini.

Lorsque les indicateurs sont définis on peut alors faire des tests qui ne sont pas interprétables et se basant sur des données mesurables. On peut donc commencer à tester !

Oui… Mais comment tester ?

Calculer un temps de réponse manuellement, c’est faisable avec un chrono à côté et en mesurant le temps à l’aide de ce dernier… Cela reste très peu précis (lorsque l’on veut des performances inférieures à 2 secondes, on ne peut se permettre d’avoir des mesures fiables à 0,5 seconde près !).

Faire des tests de charge manuellement s’avère beaucoup plus compliquer. Sur mon site j’ai des pics à 500 utilisateurs par minute. Il faudrait alors 500 testeurs, tous équipés de chronomètres… Et prenant le temps de la même façon… Bref ce n’est pas possible.

Pour faire des tests de performances il faut des outils spécifiques !

Ces outils permettent de simuler des requêtes, des nombres d’utilisateurs… L’un de ces outils les plus célèbres est JMeter. JMeter envoie des requêtes et attend une réponse afin de l’analyser. Il est capable de calculer le temps pour recevoir cette dernière.

JMeter est également capable de simuler des charges en multipliant les utilisateurs tout en continuant de faire ces mesures.

Un outil du type JMeter est donc quasiment indispensable pour les tests de performances car permet d’avoir des mesures fiables et précises, de simuler des utilisateurs et d’automatiser tout cela.

Les outils de tests de performance permettent beaucoup de possibilités, néanmoins il faut une grande connaissance de ces outils et des tests de performance afin de faire ce qui est vraiment souhaité. Les tests de performances étant souvent avec une priorité faible, ils sont également souvent négligés. De plus les connaissances liés à ces tests sont spécifiques, il est donc rare de travailler avec des spécialistes de ces tests…

Conclusion

Les tests de performances sont souvent négligés pour différentes raisons comme la difficulté de les spécifier ou le manque de connaissances à ce sujet dans l’équipe projet.

Ils sont tellement négligés qu’ils en sont méconnus et forment un fourre-tout en regroupant différents types de test biens décrits dans l’article d’HighTest.

Ils vont pourtant prendre une part de plus en plus importante. En effet, les performances deviennent de plus en plus un critère de différenciation. De mauvaises performances entrainent un abandon des applications :

53% de visiteurs abandonnent le site si ce dernier ne se charge pas en 3 secondes. (Source : Chrome Dev Summit2017)

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

Publié par

2 réponses sur « Les tests de performances ? »

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s