{"id":691,"date":"2018-06-27T16:37:31","date_gmt":"2018-06-27T14:37:31","guid":{"rendered":"https:\/\/www.tests-performance.fr\/?page_id=691"},"modified":"2020-12-11T15:10:05","modified_gmt":"2020-12-11T14:10:05","slug":"presentation-2","status":"publish","type":"page","link":"https:\/\/www.tests-performance.fr\/?page_id=691","title":{"rendered":"Pr\u00e9sentation"},"content":{"rendered":"

Pr\u00e9sentation des tests de performance<\/h1>\n

Avant-propos<\/a>
\nG\u00e9n\u00e9ralit\u00e9s<\/a>
\nLes risques<\/a>
\nLes enjeux des tests de performance<\/a>
\nLes diff\u00e9rents types de tests de performance<\/a>
\nBien comprendre les tests de performance<\/a>
\nStrat\u00e9gie<\/a>
\nIdentifier les sc\u00e9narios critiques<\/a>
\nProcessus de campagne de performance<\/a>
\nM\u00e9thodologie<\/a>
\nScripting<\/a>
\nMod\u00e9lisation<\/a>
\nTirs et analyses<\/a>
\nRestitution<\/a><\/p>\n

\n

<\/a>
\nAvant-propos<\/h2>\n

A l'aube de l'informatique populaire et accessible \u00e0 tous, l'explosion des applications a provoqu\u00e9 une prise de conscience par les responsables informatiques du co\u00fbt de maintenance \"\u00e0 chaud\" \u00e9lev\u00e9 des syst\u00e8mes lorsque des erreurs graves apparaissaient en production.<\/p>\n

Cette prise de conscience a permis de mettre en lumi\u00e8re la n\u00e9cessit\u00e9 de r\u00e9aliser des tests dans les phases amonts de la production pour r\u00e9duire ce co\u00fbt. Il existe diff\u00e9rents types de tests : tests agile par sprint, tests d'int\u00e9gration par brique ou de bout-en-bout, tests semi-automatis\u00e9s ou automatis\u00e9s, tests de recette fonctionnels par brique, tests m\u00e9tier par brique ou de bout-en bout, tests de charge et tests de performance.<\/p>\n

Si chaque type de test permet de participer \u00e0 l'effort collectif pour am\u00e9liorer progressivement la qualit\u00e9 applicative et ainsi \u00e9viter les probl\u00e8mes graves en production, seuls les tests de charge apportent une dimension multi-utilisateurs qui est aussi une des r\u00e9alit\u00e9s de production.<\/p>\n

En r\u00e9sum\u00e9, il ne suffit pas qu'une application soit exempt d'erreur pour dire qu'elle aura un v\u00e9ritable succ\u00e8s aupr\u00e8s des utilisateurs finaux, il faut aussi compter sur la patience de ces utilisateurs (qui est de plus en plus limit\u00e9e) et donc se concentrer sur les temps de r\u00e9ponse vus de l\u2019utilisateur final.<\/p>\n

En conclusion, il n\u2019y a pas de r\u00e9sultats complets ni probants si les tests de performance de sont pas accompagn\u00e9s de tests de charge.<\/p>\n

<\/a>
\nG\u00e9n\u00e9ralit\u00e9s<\/h2>\n

Les tests de performance (et de charge) ont pour principal objectif la validation d'une solution logicielle et de son architecture sous-jacente li\u00e9es \u00e0 une utilisation simultan\u00e9e multi-utilisateurs, permettant ainsi d'\u00e9viter certains probl\u00e8mes en production. Ils permettent de garantir une qualit\u00e9 de service applicative dans des conditions r\u00e9elles d'utilisation.<\/p>\n

L'objectif des tests de performance n'est pas de couvrir 90% des cas de tests possibles et imaginables (comme les tests fonctionnels unitaires), mais de couvrir les aspects applicatifs pr\u00e9sentant des risques syst\u00e8mes en charge, des risques d'interactions avec d'autres briques applicatifs, des risques strat\u00e9giques ou financiers sur des fonctionnalit\u00e9s cibl\u00e9es.<\/p>\n

Les tests de performance devraient th\u00e9oriquement \u00eatre r\u00e9alis\u00e9s au plus t\u00f4t dans le cycle de d\u00e9veloppement applicatif afin de minimiser les modifications applicatives engendr\u00e9es par la d\u00e9couverte des anomalies de performance. Ainsi, il est possible de pr\u00e9voir des tests de performance en amont, dans un environnement stable (hors environnement de d\u00e9veloppement) et dans le cadre d'une d\u00e9marche Agile. Dans ce cadre, les objectifs de ces tests seront alors limit\u00e9s : temps de r\u00e9ponses unitaires et\/ou \u00e0 faible charge, capacit\u00e9 de l'application \u00e0 maintenir un acc\u00e8s concurrent multi-utilisateurs \u00e0 faible charge.<\/p>\n

Classiquement, les tests de performance sont r\u00e9alis\u00e9s dans un environnement de pr\u00e9production afin d'\u00eatre au plus proche de la r\u00e9alit\u00e9 techniques de production (iso architecture serveurs, cha\u00eenes de liaisons compl\u00e8tes, volum\u00e9trie bdd). Les r\u00e9sultats seront alors r\u00e9ellement complets et probants.<\/p>\n

Les tests de performance permettent de d\u00e9terminer des points de contention de l'architecture technique s'ils existent et de les \u00e9liminer par modifications de param\u00e9trages techniques \/ tirs de charge it\u00e9ratifs. Ces probl\u00e8mes de performance proviennent souvent, soit de l'architecture (probl\u00e8me de dimensionnement des machines, param\u00e8tres limites des serveurs inadapt\u00e9s,...), soit d'un probl\u00e8me applicatif (bonnes pratiques de programmation non respect\u00e9s ou inexistantes, ...). Ils permettent \u00e9galement de d\u00e9terminer des seuils limites de bon fonctionnement (nombre d'utilisateurs, fr\u00e9quence d'utilisation applicative maximum garanti,\u2026).<\/p>\n

<\/a>
\nLes risques<\/h2>\n

Si une application n\u2019est pas performante, les cons\u00e9quences pourraient \u00eatre :<\/b><\/u><\/p>\n