PDF Imprimer Envoyer

Le test de charge

 

Le test de charge peut s'intégrer dans une démarche de test de performances. Dans ce contexte, cela signifie un accroissement linéaire de la charge via des outils de test appropriés. Pour un serveur web, la charge est définie en termes d'utilisateurs concurrents ou de connections HTTP simultanées.

 

Dans la littérature du test, le terme de "test de charge" est couramment défini comme le processus de solliciter le système testé en lui faisant réaliser la tache la plus importante qu'il puisse accomplir. Le test de charge est parfois appelé test volumétrique, test d'endurance ou test de longévité.

 

Exemples de tests de volumétrie :

  • tester un processeur de texte en éditant un document de grande taille
  • tester une imprimante en lui envoyant un fichier de très grande taille
  • tester un serveur mail en créant des milliers de boites mails
  • un cas spécifique du test de volumétrie est le test de volumétrie nulle, où une tâche vide est demandée au système, mais on entre là dans le domaine du test aux limites

Exemples de tests de longévité, d'endurance :

  • Tester une application client/serveur en exécutant le client en boucle durant une période de temps donnée

Buts du test de charge :

  • mettre à jour des bugs qui n'ont pas été découverts dans les tests unitaires ou d'intégration, comme des bugs dans la gestion mémoire, des fuites de mémoire, des buffers overflows, etc.
  • s'assurer que l'application atteint le niveau de performance de référence établis lors des tests de performance. Ceci est réalisé en exécutant des tests de non régression de l'application face à une charge maximale.

Bien que le test de performances et le test de charge puissent paraitre similaires, leurs buts sont différents. D'un coté, le test de performances utilise les techniques et les outils de test de charge avec des objectifs de mesure et de référencement des performances en testant une grande variété de niveaux de charge, en général, le plus haut niveau de charge que le système puisse accepter tout en continuant à fonctionner correctement. Il est à noter que le test de charge ne signifie pas faire s'effondrer le système testé en l'inondant sous la charge, mais plutôt d'essayer d'atteindre le niveau de charge lui permettant de ronronner comme une machine bien huilée.

Dans le contexte du test de charge, je tiens à souligner la grande importance d'avoir un grand panel de données disponibles pour tester. L'expérience montre qu'une grande quantité de bugs importants ne font surface que quand on travaille avec de grandes quantités, comme des milliers d'utilisateurs dans des annuaires comme LDAP/NIS/AD, des milliers de boites mails sur un serveur mail, des tables de plusieurs gigaoctets dans des bases de données, de grandes arborescences sur des systèmes de fichiers, etc.

 

 

 

 Creative Commons License
Cette création est mise à disposition sous un contrat Creative Commons.
Article original publié par Grig Gheorghiu.

 
AppLoad Consulting, Powered by Joomla!; Joomla templates by SG web hosting