• Ryan Fridjine

La Planification du test de performance ou comment allier les forces de tout un SI



Il en va de même pour le test de performance ! Une démarche naïve de réalisation de tests de charge serait d’effectuer des tests sans se préoccuper de l’environnement et obtenir des résultats concluants qui puissent répondre à une problématique établie. La réalité est, elle bien différente !


Le but initial des tests de charge est de trouver les points faibles d’une architecture dans le but d’améliorer sa performance. Cet objectif d’optimisation n’est qu’un simple maillon de la chaine. En effet comme le dit William Edwards Deming:


Un des autres axes et non des moindres est de satisfaire un utilisateur de plus en plus exigeant tant en termes de qualité de services que de temps de réponses.


La recherche de la performance sous tous ces aspects est nécessaire à l’amélioration des coûts de l’entreprise pour qui un temps de réponse amélioré entraine un utilisateur optimisé.


Les principaux objectifs étant définis, je vais désormais en quelques lignes vous résumer les bonnes pratiques pour qu’un test de performance se déroule sans accrocs.


La méthodologie du test de performance


Pour cela une méthodologie de type Roue de Deming peut être appliquée. Basée sur une pensée simple d’un modèle d’amélioration continue utilisée en management de la qualité.


Cette roue a pour vocation de tourner à l’infini, peu importe la lourdeur du système qui l’entoure.

  • Le Plan : Cadrage et conception des scénarii, connaissance de l’infrastructure client, réalisation des scripts

  • Le Do est la phase de faire, celle où on effectue les tests

  • Le Check est le moment où l’on vérifie les résultats

  • Le A sert à améliorer le système que l’on teste. C’est la phase d’optimisation.


Nous allons dans cet article essentiellement nous focaliser sur le PLAN. Trop facilement laissée de côté ou en tout cas négligée, cette phase sera le socle permettant ou non la bonne réalisation d’un projet.


L’identification de la problématique du client, un élément essentiel à la conception du projet.


Avant de se lancer dans ce cercle vertueux d’amélioration, il est important de déterminer le but des tests demandés par le client. Est-il de :

  • S’assurer qu’un système fonctionne sans erreur sous certaines conditions de charge

  • S’assurer qu’un système répond aux critères d’acceptabilité des performances

  • Optimiser les temps de réponse pour augmenter la satisfaction utilisateur

  • Optimiser les coûts d’infrastructure

  • Connaître la capacité du système

  • Valider de nouvelles fonctionnalités

Les cas sont multiples, aussi il faudra en fonction des réponses à ces questions, déterminer quelle(s) orientation(s) donner aux tests.


Ce travail de préparation et de cadrage n’est pas à prendre à la légère. Il doit permettre de conceptualiser au mieux la chaine du test de charge et d’identifier au mieux la problématique du client et l’origine de ces tests.


Une problématique bien identifiée permettra d’orienter le client en fonction de sa maturité vers la bonne série de test à lancer.


Les scénarii métiers : Une base nécessaire


L’identification de la problématique faite, il faudra nécessairement échanger avec le client afin de définir au mieux les scénarii.


Le mot scénarii est vaste, il recoupe en effet un ensemble de paramètres. Afin de les définir au mieux le testeur devra enquêter, dialoguer, poser les questions pertinentes mais également, accompagner le client en fonction de son degré de maturité vers des tests les plus pertinents.


Quelques remarques peut-être évidentes doivent être faites :

  • Quels scénarii utilisateurs ont déjà été identifiés comme posant problème ?

  • Combien d’utilisateurs sont sur la plateforme ?

  • Combien d’itérations sont reproduites sur une durée donnée ?

  • Est-ce que l’utilisation de certaines fonctionnalités va augmenter ?

Ce travail peut paraître long, voire même inutile pour certains testeurs mais il est essentiel !


Pourquoi ? Et bien pour une raison très simple !


Il permet au test de performance non seulement de refléter la réalité de l’utilisation (ce qui est quand même essentiel à notre métier) mais permet également de donner au client une explication cohérente à sa problématique.

En effet notre devoir de conseil est avant tout de donner une réponse par rapport à un problème donné. Si l’infrastructure du client ne peut supporter plus de 500 utilisateurs, quel est l’intérêt et la pertinence de lancer un test de performance à 1000 utilisateurs sauf si ce dernier compte augmenter de manière exponentielle son nombre d’utilisateurs ?


Le but de notre approche et de notre intervention n’est pas de casser une application mais de comprendre ce qui ne fonctionne pas ou qui ne pourrait pas fonctionner.


La connaissance et l’identification de la problématique du client est essentielle à l’accomplissement de notre mission !


Cette dernière passe bien évidemment par l’écoute et par l’échange. Sans informations sur l’environnement et sans échanges avec tous les parties prenantes de l’équipe (Métiers, infrastructure, réseau), il est difficile d’identifier l’origine d’un goulet d’étranglement ou de temps de réponse long …


Afin de réaliser les meilleurs scénarii de tests possible, l’aspect fonctionnel ne doit en aucun cas être mis de côté. Le testeur n’est pas un simple codeur !


Il doit avant tout comprendre les tenants et les aboutissants de l’application ainsi que ses règles de gestion qui lui permettront d’identifier des erreurs dans les tests qui ne sont pas forcément des erreurs applicatives mais juste une simple méconnaissance de l’utilisation de l’application.


Toutes les forces vives d’un projet doivent rentrer en symbiose pour que l’accomplissement et le résultat d’un test de performance soient donner mais surtout puissent donner des résultats pertinents !


La mise en place d’une campagne de tests de performance est généralement coûteuse. Afin de la rendre la plus efficace possible, il convient d’adopter une démarche stricte pour ne pas se perdre dans les méandres de l’optimisation sans fin ou inutile.


Les 3 dernières phases de la roue de Deming sont très souvent bien maitrisées. Néanmoins elles ne sont que le fruit de la première.


Un test de performance c’est un peu comme une brique convergée. Il ne doit pas sa réussite au hasard. Il est le fruit d’une collaboration étroite et d’une préparation sans faille.




30 vues

Posts récents

Voir tout