Les r\u00e9ponses \u00e0 ces questions vous aideront \u00e0 cr\u00e9er une strat\u00e9gie\/fr\/test\/ planifi\u00e9s<\/a> de qualit\u00e9. Si le client n’est pas en mesure de fournir des r\u00e9ponses \u00e0 toutes ces questions, pas de souci. Nous pouvons toujours explorer l’application test\u00e9e et trouver les r\u00e9ponses. Par exemple, si un outil APM\/journal<\/a> est en place, nous pouvons en d\u00e9duire les utilisateurs concurrents<\/a>, le d\u00e9bit, et le temps de r\u00e9ponse du syst\u00e8me de production. Ne supposez jamais que vous obtiendrez ce dont vous avez besoin sans demander.<\/p>\n Un testeur de performance devrait choisir avec soin le meilleur outil de test de performance. Il y a beaucoup de facteurs \u00e0 consid\u00e9rer avant de finaliser et de proposer l’outil. Rappelez-vous que le budget du client est toujours un facteur majeur lors du choix de l’outil de test de performance<\/a>.<\/p>\n Si vous cherchez un outil de test performance qui soit rentable, facile \u00e0 utiliser, et qui puisse fournir une solution compl\u00e8te de performance, vous devriez absolument essayer LoadView<\/a>. Compar\u00e9 aux outils traditionnels de test de charge, LoadView ne n\u00e9cessite aucun investissement co\u00fbteux, configuration chronophage, ni connaissance pr\u00e9alable des frameworks<\/a> de script. De plus, la plateforme offre plus de 20 emplacements globaux permettant de lancer des injecteurs de charge, ainsi vous pouvez tester et mesurer la performance depuis plusieurs emplacements lors de chaque test.<\/p>\n Tous les types de tests de performance demandent du temps et des efforts. R\u00e9aliser des tests de charge peut sauver une organisation d’une humiliation potentielle, mais en m\u00eame temps, les tests sur un outil libre open source comme JMeter ne justifieront pas l’investissement. Quand il s’agit de comprendre vraiment la performance d’un site web ou d’une application du point de vue de l’utilisateur final, les tests bas\u00e9s sur un protocole<\/a> ne suffisent pas. Vous devez aussi mesurer la performance des interactions c\u00f4t\u00e9 client et des \u00e9tapes. Voici une comparaison de LoadView avec d’autres solutions de test de performance\/charge<\/a> et pourquoi vous devriez choisir LoadView pour vos besoins en tests de performance.<\/p>\n En ce qui concerne les sites et applications \u00e0 chargement lent, les clients peuvent vite devenir impatients, partir et trouver un remplacement si votre site\/application ne r\u00e9pond pas \u00e0 leurs attentes. Savoir combien votre site\/application peut supporter est tr\u00e8s important pour diverses raisons, mais il y a plusieurs sc\u00e9narios significatifs avec lesquels la plateforme LoadView peut aider :<\/p>\n Une fois que vous avez recueilli les exigences du client et choisi un outil de test de performance adapt\u00e9, il faut documenter notre plan de test\/strat\u00e9gie de test. Assurez-vous de faire valider le plan de test par le client avant de commencer toute activit\u00e9 de test de performance. C’est tr\u00e8s important, cela vous aidera \u00e0 \u00e9viter des probl\u00e8mes inutiles par la suite. Voici quelques points qui doivent \u00eatre inclus dans le plan de test.<\/p>\n Le test de performance r\u00e9el repose sur une combinaison de techniques<\/a>. Pour atteindre les objectifs attendus, nous devons pr\u00e9parer une strat\u00e9gie diff\u00e9rente pour chaque exigence de test de performance. Il y a diff\u00e9rentes m\u00e9triques, telles que la charge utilisateur, les utilisateurs concurrents, les mod\u00e8les de charge, etc., qui doivent \u00eatre prises en compte avant de planifier la charge. Si vous avez d\u00e9j\u00e0 travaill\u00e9 sur la mod\u00e9lisation de la charge, vous avez probablement entendu parler de la loi de Little<\/a>. Vous devriez l’apprendre et la mettre en \u0153uvre avant de planifier un test pour obtenir les r\u00e9sultats souhait\u00e9s.<\/p>\n Une fois que nous avons convenu d’un plan ou d’une strat\u00e9gie de performance avec le client, il est temps de pr\u00e9parer le scripting en utilisant l’outil de test de performance choisi. Construire des scripts de qualit\u00e9 est la cl\u00e9 du succ\u00e8s des tests de performance, et plusieurs consid\u00e9rations importantes doivent \u00eatre gard\u00e9es \u00e0 l’esprit tout au long du processus.<\/p>\n Tout d’abord, suivez toujours les \u00e9tapes document\u00e9es du cas de test lors de la cr\u00e9ation des scripts pour garantir leur exactitude. Commencez par rejouer le script pour un seul utilisateur et r\u00e9glez les besoins de corr\u00e9lation ou de param\u00e9trage. Le param\u00e9trage peut inclure les en-t\u00eates, les cookies, ou les param\u00e8tres de corps. Une fois que le script fonctionne parfaitement pour un utilisateur unique, testez-le avec plusieurs it\u00e9rations et diff\u00e9rentes donn\u00e9es utilisateur. Soyez pr\u00eat \u00e0 ajuster la corr\u00e9lation ou le param\u00e9trage car de nouvelles donn\u00e9es peuvent r\u00e9v\u00e9ler des besoins suppl\u00e9mentaires.<\/p>\n Dans certains cas, la r\u00e9alisation de certains cas d’usage peut n\u00e9cessiter l’\u00e9criture de blocs de code personnalis\u00e9s. Par exemple, vous pourriez avoir besoin d’extraire des donn\u00e9es sp\u00e9cifiques de la r\u00e9ponse d’un utilisateur et de les manipuler pour une autre requ\u00eate. De plus, n’oubliez pas d’inclure le temps de r\u00e9flexion, le rythme, et les m\u00e9canismes de gestion des erreurs bas\u00e9s sur le mod\u00e8le de charge. V\u00e9rifier la fonctionnalit\u00e9 du script avec des contr\u00f4les textuels ou d’images est tout aussi important pour garantir les r\u00e9sultats souhait\u00e9s.<\/p>\n Au-del\u00e0 du scripting, consid\u00e9rez des facteurs comme la simulation du cache, des cookies, et des conditions r\u00e9seau variables pour refl\u00e9ter des sc\u00e9narios r\u00e9alistes. En tant qu’ing\u00e9nieur performance, cr\u00e9er un comportement utilisateur virtuel r\u00e9aliste est crucial. Ce processus commence par la collecte de d\u00e9tails pr\u00e9cis pendant la phase de collecte des exigences.<\/p>\n Les questions cl\u00e9s \u00e0 aborder sont :<\/p>\n Ces r\u00e9ponses peuvent \u00eatre obtenues via un questionnaire de collecte des exigences ou en analysant des donn\u00e9es statistiques collect\u00e9es \u00e0 partir d’outils comme les solutions APM ou Google Analytics. L’analyse des transactions est particuli\u00e8rement utile pour identifier les transactions m\u00e9tier critiques et concevoir des sc\u00e9narios de test de performance qui refl\u00e8tent fid\u00e8lement l’utilisation r\u00e9elle. En suivant ces \u00e9tapes, vous serez bien \u00e9quip\u00e9 pour ex\u00e9cuter des tests de performance efficaces et fournir des r\u00e9sultats fiables.<\/p>\n Nous pouvons planifier notre mod\u00e8le de charge de diff\u00e9rentes mani\u00e8res. Les ing\u00e9nieurs performance devraient apprendre et pratiquer le concept de la \u00ab loi de Little \u00bb avant de s\u00e9lectionner un mod\u00e8le de charge. Voici quelques mod\u00e8les de charge existants. Encore une fois, l’ing\u00e9nieur performance devrait choisir le mod\u00e8le de charge en fonction des exigences en main.<\/p>\n Mod\u00e8le de charge 1<\/strong>. C’est un mod\u00e8le simple, o\u00f9 le nombre d’utilisateurs augmente continuellement \u00e0 mesure que le test progresse. Exemple : un utilisateur par seconde jusqu’\u00e0 la fin du test.<\/p>\n Mod\u00e8le de charge 2<\/strong>. Dans ce mod\u00e8le, le nombre d’utilisateurs augmente par paliers pour toute la dur\u00e9e du test. Par exemple, les 15 premi\u00e8res minutes seront avec 100 utilisateurs, les 15 minutes suivantes avec 200, etc. Ce type de test peut \u00eatre planifi\u00e9 pour les tests d’endurance.<\/p>\n Mod\u00e8le de charge 3<\/strong>. C’est le mod\u00e8le de test de performance le plus courant. Le nombre d’utilisateurs augmente continuellement pendant une certaine p\u00e9riode (appel\u00e9e p\u00e9riode de mont\u00e9e en charge). Ensuite, les utilisateurs restent stables pendant une certaine dur\u00e9e. Puis les utilisateurs diminuent progressivement et le test se termine. Par exemple, si nous pr\u00e9voyons 1,5 heure de test, nous pouvons allouer 15 minutes pour la mont\u00e9e en charge des utilisateurs et 15 minutes pour la descente. L’\u00e9tat stable durera une heure. Lors de l’analyse des r\u00e9sultats, seul l’\u00e9tat stable sera pris en compte.<\/p>\n Mod\u00e8le de charge 4<\/strong>. Dans ce mod\u00e8le, le nombre d’utilisateurs augmente et diminue soudainement pendant toute la dur\u00e9e. Ce type de test porte diff\u00e9rents noms, tels que test singe, test de pic, etc.<\/p>\n Nous devons \u00e9tablir un ensemble complet d’objectifs et d’exigences pour les tests de performance. D\u00e9finissez les param\u00e8tres des tests de performance et ce qui constitue les crit\u00e8res d’acceptation pour chacun. Si vous ne connaissez ni les exigences du test ni le r\u00e9sultat<\/a> souhait\u00e9, alors le test de performance est une perte de temps.<\/p>\n Voici quelques-unes des m\u00e9triques tr\u00e8s importantes \u00e0 observer lors de la mod\u00e9lisation de la charge de performance.<\/p>\n Temps de r\u00e9ponse :<\/strong> Le temps de r\u00e9ponse est le temps que met le serveur pour r\u00e9pondre \u00e0 la requ\u00eate du client. De nombreux facteurs peuvent affecter le temps de r\u00e9ponse du serveur. Le test de charge aidera \u00e0 identifier et \u00e9liminer ces facteurs qui d\u00e9gradent le temps de r\u00e9ponse.<\/p>\n Temps de r\u00e9ponse moyen :<\/strong> C’est la valeur moyenne du temps de r\u00e9ponse pendant toute la dur\u00e9e de l’\u00e9tat stable lors d’un test de charge.<\/p>\n Temps de r\u00e9ponse du 90e percentile :<\/strong> Le temps de r\u00e9ponse du 90e percentile signifie que 90 % du temps de r\u00e9ponse est inf\u00e9rieur \u00e0 cette valeur. Par exemple, si vous avez 500 requ\u00eates avec des temps de r\u00e9ponse diff\u00e9rents, le 90e percentile est une valeur telle que 90 % de toutes les autres valeurs sont inf\u00e9rieures \u00e0 cette valeur. Seuls 10 % des temps de r\u00e9ponse seront sup\u00e9rieurs \u00e0 cette valeur du 90e percentile. Cela est utile si certaines de vos requ\u00eates ont un temps de r\u00e9ponse tr\u00e8s \u00e9lev\u00e9 et biaisent la moyenne.<\/p>\n Requ\u00eates par seconde :<\/strong> Nous devons trouver cette valeur avec les outils APM ou \u00e0 l’aide des journaux de production. En fonction des utilisateurs concurrents, nous pouvons planifier le nombre de requ\u00eates par seconde vers le serveur.<\/p>\n Utilisation de la m\u00e9moire :<\/strong> Ce sont des m\u00e9triques c\u00f4t\u00e9 infrastructure qui aident \u00e0 d\u00e9couvrir les goulots d’\u00e9tranglement. Aussi, vous devriez planifier votre charge de fa\u00e7on aussi r\u00e9aliste que possible. Assurez-vous de ne pas bombarder le serveur avec des requ\u00eates continues.<\/p>\n Utilisation du CPU :<\/strong> Comme pour la m\u00e9moire, il faut surveiller cette m\u00e9trique lors des tests de performance.<\/p>\n Taux d’erreur :<\/strong> Nous devrions suivre le ratio transactions r\u00e9ussies\/transactions en erreur. Le taux d’erreur ne devrait pas d\u00e9passer 2 % des transactions r\u00e9ussies. Si le taux d’erreur augmente avec le nombre d’utilisateurs concurrents, il peut y avoir un goulot d’\u00e9tranglement potentiel.<\/p>\n Utilisateurs concurrents :<\/strong> Cette valeur doit \u00eatre trouv\u00e9e via les outils APM ou \u00e0 partir des journaux de production. Normalement, cette valeur est bas\u00e9e sur une journ\u00e9e type d’activit\u00e9.<\/p>\n D\u00e9bit :<\/strong> Le d\u00e9bit montre la capacit\u00e9 du serveur \u00e0 g\u00e9rer les utilisateurs concurrents. Il y a une relation directe entre utilisateurs concurrents et d\u00e9bit. Le d\u00e9bit devrait augmenter avec le nombre d’utilisateurs acc\u00e9dant \u00e0 l’application. Si le d\u00e9bit diminue malgr\u00e9 l’augmentation du nombre d’utilisateurs, cela indique un possible goulot d’\u00e9tranglement.<\/p>\n R\u00e9partition de la charge utilisateur :<\/strong> La r\u00e9partition de la charge utilisateur est un facteur important \u00e0 prendre en compte lors de la conception de la charge. Si nous avons cinq scripts qui effectuent cinq fonctionnalit\u00e9s diff\u00e9rentes d’une application, nous devons r\u00e9partir la charge utilisateur aussi fid\u00e8lement que possible, bas\u00e9e sur notre investigation en production ou via les outils APM.<\/p>\n Ce sont des m\u00e9triques tr\u00e8s importantes que nous devrions garder en t\u00eate lors de la conception du mod\u00e8le de charge. Il y aura d’autres m\u00e9triques selon l’architecture et les exigences de l’application du client.<\/p>\n L’exemple de liste de contr\u00f4le ci-dessous est g\u00e9n\u00e9ralement suivi pour les tests de performance bout en bout au niveau entreprise, o\u00f9 un grand nombre de syst\u00e8mes sont impliqu\u00e9s. Il est toujours recommand\u00e9 de suivre une liste de contr\u00f4le de l’environnement m\u00eame pour les tests de performance \u00e0 plus petite \u00e9chelle<\/a>. Les activit\u00e9s changeront en fonction des environnements d’application, car il y a une grande diff\u00e9rence compar\u00e9e \u00e0 une application sur cloud versus une application sur site.<\/p>\n Un test de performance logiciel r\u00e9ussi ne se produit pas par hasard. Les architectes, responsables produits, d\u00e9veloppeurs, et l’\u00e9quipe de test de performance doivent travailler ensemble et aborder les exigences des tests de performance avant d’\u00e9valuer le logiciel. Pour des informations plus d\u00e9taill\u00e9es sur la plateforme LoadView, lisez notre article Technical Overview<\/a> pour voir comment tirer le meilleur parti de vos tests de performance. Les tests de performance devraient \u00eatre un processus continu. Lorsque votre site ou application web commence \u00e0 cro\u00eetre, vous devrez effectuer des modifications pour accueillir une base d’utilisateurs plus large. Il y a toujours une marge d’am\u00e9lioration dans toute application et pour les tests.<\/p>\n Nous esp\u00e9rons que cela vous a donn\u00e9 un bon aper\u00e7u des meilleures pratiques en mati\u00e8re de tests de performance. Si vous souhaitez une d\u00e9monstration compl\u00e8te de la solution LoadView, inscrivez-vous pour une d\u00e9mo<\/a> avec un ing\u00e9nieur performance. Il vous guidera \u00e9tape par \u00e9tape \u00e0 travers chaque partie du processus, de la cr\u00e9ation des scripts de test de charge et la configuration des tests, \u00e0 l’ex\u00e9cution des tests et l’analyse des r\u00e9sultats.<\/p>\nTrouver un outil de test de performance adapt\u00e9<\/h2>\n
\n
Plan\/Strat\u00e9gie de test de performance<\/h2>\n
\n
Scripts\/Sc\u00e9narios de performance en temps r\u00e9el<\/h3>\n
\n
Mod\u00e9lisation de la charge<\/h2>\n
Collecte des donn\u00e9es<\/h2>\n
Liste de contr\u00f4le pour l’environnement de test de performance (avant ex\u00e9cution)<\/h2>\n
![\"Performance](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/Performance-Testing-Checklist-1024x270.jpg\")
<\/p>\nConclusion : Liste de contr\u00f4le de pr\u00e9paration aux tests de charge<\/h2>\n