Lorsqu’il s’agit de tests de charge, il y a toujours la question à un million de dollars : « En termes de performance, que veut faire le client avec son application et système ? » Je suis sûr que vous n’obtiendrez jamais une réponse facile à cette question, et la plupart d’entre nous supposent toujours certaines choses et effectuent les tests de performance, ce qui peut finir par omettre de tester des éléments critiques, et aboutir à un client mécontent. Un client mécontent signifie une perte d’affaires pour votre organisation et une carrière déclinante en tant qu’ingénieur performance. Mais ne vous inquiétez pas, dans cet article, nous allons parler de la création d’une liste de contrôle qui vous aidera avec ces questions.
Cette liste de contrôle est plus un processus étape par étape que vous pouvez suivre et adapter à votre cycle de vie des tests de performance. Dans le scénario discuté, nous ne pouvons pas toujours blâmer nos clients, car au départ, ils ne connaissent peut-être pas les résultats exacts de performance qu’ils souhaitent, mais ils ont une connaissance claire de la façon dont l’application fonctionne sous différentes conditions. Un bon testeur de performance peut gérer cette ambiguïté avec un questionnaire bien défini. Et c’est le tout premier élément de la liste de contrôle, le questionnaire de collecte des exigences.
Questionnaire de collecte des exigences
Voici un format de questionnaire que vous pouvez suivre dans votre projet. Nous devons obtenir autant de réponses que possible à ces questions. Il sera préférable de pouvoir organiser un appel pour discuter de ces questions. Assurez-vous que l’architecte de l’application ou le développeur se joigne à vous et au client lors de l’appel. La présence de personnel supplémentaire peut aider à fournir des insights et à découvrir des questions auxquelles vous n’avez peut-être pas pensé auparavant. Les questions ci-dessous vous fournissent une feuille de route pour créer un test de charge plus efficace et efficient.
| N° | Sujet | Questions |
| 1 | Application | Type d’application à considérer pour les tests (par exemple, application web/application mobile, etc.). |
| 2 | Architecture et technologie/plateforme de l’application. | |
| 3 | Technique d’équilibrage de charge utilisée. | |
| 4 | Protocole de communication entre client et serveur (par exemple : HTTP/S, FTP). | |
| 5 | Objectif du test de performance. Métriques de performance à surveiller (par exemple, temps de réponse pour chacune des actions, utilisateurs concurrents, etc.). | |
| 6 | Scénarios critiques à considérer pour les tests de performance. | |
| 7 | Détails des tâches/processus programmés en arrière-plan, s’il y en a. | |
| 8 | Technique utilisée pour la gestion de session et nombre de sessions parallèles prises en charge. | |
| 9 | SLA/Exigences Client | Nombre attendu d’utilisateurs concurrents et base totale d’utilisateurs. Répartition des utilisateurs pour les scénarios dans le périmètre. |
| 10 | SLA pour toutes les transactions dans le périmètre du PT (débit attendu, temps de réponse, etc.). | |
| 11 | Types de tests de performance à réaliser (tests de charge, tests d’endurance, etc.). | |
| 12 | Système/Environnement | Détails de l’environnement de test (web/app/BD, etc., avec nombre de nœuds). Un environnement proche de la production est recommandé pour l’exécution des tests de performance. |
| 13 | Comparaison de l’environnement de production et de l’environnement de test de performance. | |
| 14 | Si l’application doit être isolée pendant l’exécution du test de performance pour éviter l’interaction avec d’autres applications. | |
| 15 | Détails du mécanisme de journalisation intégré ou du mécanisme de surveillance. | |
| 16 | Autres | Résultats de référence de la performance de l’application. |
| 17 | Problèmes de performance actuels, s’il y en a. | |
Les réponses à ces questions vous aideront à créer une stratégie/fr/test/ planifiés de qualité. Si le client n’est pas en mesure de fournir des réponses à toutes ces questions, pas de souci. Nous pouvons toujours explorer l’application testée et trouver les réponses. Par exemple, si un outil APM/journal est en place, nous pouvons en déduire les utilisateurs concurrents, le débit, et le temps de réponse du système de production. Ne supposez jamais que vous obtiendrez ce dont vous avez besoin sans demander.
Trouver un outil de test de performance adapté
Un testeur de performance devrait choisir avec soin le meilleur outil de test de performance. Il y a beaucoup de facteurs à considérer 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.
Si vous cherchez un outil de test performance qui soit rentable, facile à utiliser, et qui puisse fournir une solution complète de performance, vous devriez absolument essayer LoadView. Comparé aux outils traditionnels de test de charge, LoadView ne nécessite aucun investissement coûteux, configuration chronophage, ni connaissance préalable des frameworks 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.
Tous les types de tests de performance demandent du temps et des efforts. Réaliser des tests de charge peut sauver une organisation d’une humiliation potentielle, mais en même 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és sur un protocole ne suffisent pas. Vous devez aussi mesurer la performance des interactions côté client et des étapes. Voici une comparaison de LoadView avec d’autres solutions de test de performance/charge et pourquoi vous devriez choisir LoadView pour vos besoins en tests de performance.
En ce qui concerne les sites et applications à chargement lent, les clients peuvent vite devenir impatients, partir et trouver un remplacement si votre site/application ne répond pas à leurs attentes. Savoir combien votre site/application peut supporter est très important pour diverses raisons, mais il y a plusieurs scénarios significatifs avec lesquels la plateforme LoadView peut aider :
- Adaptabilité et scalabilité. Déterminer pourquoi votre site ou application ralentit lorsque plusieurs utilisateurs y accèdent.
- Infrastructure. Comprendre quelles mises à niveau matérielles sont nécessaires, le cas échéant. Le coût d’implémentation de matériel supplémentaire, et sa maintenance, pourrait représenter un gaspillage de ressources.
- Exigences de performance. Votre site ou application peut bien gérer quelques utilisateurs, mais que se passe-t-il dans des situations réelles ?
- Services tiers. Voir comment les services externes se comportent sous des conditions de charge normales, voire de pointe.
Plan/Stratégie de test de performance
Une fois que vous avez recueilli les exigences du client et choisi un outil de test de performance adapté, il faut documenter notre plan de test/stratégie de test. Assurez-vous de faire valider le plan de test par le client avant de commencer toute activité de test de performance. C’est très important, cela vous aidera à éviter des problèmes inutiles par la suite. Voici quelques points qui doivent être inclus dans le plan de test.
- Objectifs du test de performance. Ce que nous allons accomplir.
- Portée du projet. Quelle est la portée du projet, par exemple : nombre de scripts, durée des tests, etc.
- Architecture de l’application. Détails de l’application tels que serveur d’applications, serveur BD, vous pouvez inclure un diagramme d’architecture si vous en avez un.
- Détails de l’environnement. Détails sur l’environnement que nous allons tester. Il est toujours préférable d’avoir un environnement isolé pour les tests de performance.
- Configuration de l’infrastructure. Configuration initiale pour le test de performance (par exemple, environnement cloud, installation de l’outil, etc.).
- Approche du test de performance. Comment nous allons procéder. Nous devrions commencer par un test de référence avec un petit nombre d’utilisateurs, puis augmenter progressivement le nombre d’utilisateurs et effectuer différents types de tests comme stress, endurance, etc.
- Critères d’entrée et de sortie. C’est très important. Nous devrions toujours commencer les tests de performance lorsqu’il n’y a aucun défaut fonctionnel. De la même manière, nous devons documenter quand arrêter les tests de performance.
- Gestion des défauts. Nous devrions suivre le même outil et les mêmes pratiques utilisées par le client pour enregistrer les défauts liés aux tests de performance.
- Rôles et responsabilités. Détails sur les parties prenantes impliquées dans les différentes activités lors des tests de performance.
- Hypothèses et risques. S’il y a des objectifs qui peuvent représenter un risque pour les tests de performance, nous devons les documenter.
- Stratégie des données de test. Détails sur la stratégie des données de test et comment nous pouvons les extraire.
- Calendrier du plan de test et principales livrables. Calendrier du scripting, de l’exécution des tests, de l’analyse, et des livrables pour la revue client.
Le test de performance réel repose sur une combinaison de techniques. Pour atteindre les objectifs attendus, nous devons préparer une stratégie différente pour chaque exigence de test de performance. Il y a différentes métriques, telles que la charge utilisateur, les utilisateurs concurrents, les modèles de charge, etc., qui doivent être prises en compte avant de planifier la charge. Si vous avez déjà travaillé sur la modélisation de la charge, vous avez probablement entendu parler de la loi de Little. Vous devriez l’apprendre et la mettre en œuvre avant de planifier un test pour obtenir les résultats souhaités.
Scripts/Scénarios de performance en temps réel
Une fois que nous avons convenu d’un plan ou d’une stratégie de performance avec le client, il est temps de préparer le scripting en utilisant l’outil de test de performance choisi. Construire des scripts de qualité est la clé du succès des tests de performance, et plusieurs considérations importantes doivent être gardées à l’esprit tout au long du processus.
Tout d’abord, suivez toujours les étapes documentées du cas de test lors de la création des scripts pour garantir leur exactitude. Commencez par rejouer le script pour un seul utilisateur et réglez les besoins de corrélation ou de paramétrage. Le paramétrage peut inclure les en-têtes, les cookies, ou les paramètres de corps. Une fois que le script fonctionne parfaitement pour un utilisateur unique, testez-le avec plusieurs itérations et différentes données utilisateur. Soyez prêt à ajuster la corrélation ou le paramétrage car de nouvelles données peuvent révéler des besoins supplémentaires.
Dans certains cas, la réalisation de certains cas d’usage peut nécessiter l’écriture de blocs de code personnalisés. Par exemple, vous pourriez avoir besoin d’extraire des données spécifiques de la réponse d’un utilisateur et de les manipuler pour une autre requête. De plus, n’oubliez pas d’inclure le temps de réflexion, le rythme, et les mécanismes de gestion des erreurs basés sur le modèle de charge. Vérifier la fonctionnalité du script avec des contrôles textuels ou d’images est tout aussi important pour garantir les résultats souhaités.
Au-delà du scripting, considérez des facteurs comme la simulation du cache, des cookies, et des conditions réseau variables pour refléter des scénarios réalistes. En tant qu’ingénieur performance, créer un comportement utilisateur virtuel réaliste est crucial. Ce processus commence par la collecte de détails précis pendant la phase de collecte des exigences.
Les questions clés à aborder sont :
- Quel est le nombre total d’utilisateurs interagissant avec l’application pendant les heures ouvrables ?
- Quelles actions les utilisateurs effectuent-ils généralement, et à quelle fréquence ?
- Combien d’utilisateurs accèdent à l’application pendant les pics de charge ?
Ces réponses peuvent être obtenues via un questionnaire de collecte des exigences ou en analysant des données statistiques collectées à partir d’outils comme les solutions APM ou Google Analytics. L’analyse des transactions est particulièrement utile pour identifier les transactions métier critiques et concevoir des scénarios de test de performance qui reflètent fidèlement l’utilisation réelle. En suivant ces étapes, vous serez bien équipé pour exécuter des tests de performance efficaces et fournir des résultats fiables.
Modélisation de la charge
Nous pouvons planifier notre modèle de charge de différentes manières. Les ingénieurs performance devraient apprendre et pratiquer le concept de la « loi de Little » avant de sélectionner un modèle de charge. Voici quelques modèles de charge existants. Encore une fois, l’ingénieur performance devrait choisir le modèle de charge en fonction des exigences en main.
Modèle de charge 1. C’est un modèle simple, où le nombre d’utilisateurs augmente continuellement à mesure que le test progresse. Exemple : un utilisateur par seconde jusqu’à la fin du test.
Modèle de charge 2. Dans ce modèle, le nombre d’utilisateurs augmente par paliers pour toute la durée du test. Par exemple, les 15 premières minutes seront avec 100 utilisateurs, les 15 minutes suivantes avec 200, etc. Ce type de test peut être planifié pour les tests d’endurance.
Modèle de charge 3. C’est le modèle de test de performance le plus courant. Le nombre d’utilisateurs augmente continuellement pendant une certaine période (appelée période de montée en charge). Ensuite, les utilisateurs restent stables pendant une certaine durée. Puis les utilisateurs diminuent progressivement et le test se termine. Par exemple, si nous prévoyons 1,5 heure de test, nous pouvons allouer 15 minutes pour la montée en charge des utilisateurs et 15 minutes pour la descente. L’état stable durera une heure. Lors de l’analyse des résultats, seul l’état stable sera pris en compte.
Modèle de charge 4. Dans ce modèle, le nombre d’utilisateurs augmente et diminue soudainement pendant toute la durée. Ce type de test porte différents noms, tels que test singe, test de pic, etc.
Nous devons établir un ensemble complet d’objectifs et d’exigences pour les tests de performance. Définissez les paramètres des tests de performance et ce qui constitue les critères d’acceptation pour chacun. Si vous ne connaissez ni les exigences du test ni le résultat souhaité, alors le test de performance est une perte de temps.
Collecte des données
Voici quelques-unes des métriques très importantes à observer lors de la modélisation de la charge de performance.
Temps de réponse : Le temps de réponse est le temps que met le serveur pour répondre à la requête du client. De nombreux facteurs peuvent affecter le temps de réponse du serveur. Le test de charge aidera à identifier et éliminer ces facteurs qui dégradent le temps de réponse.
Temps de réponse moyen : C’est la valeur moyenne du temps de réponse pendant toute la durée de l’état stable lors d’un test de charge.
Temps de réponse du 90e percentile : Le temps de réponse du 90e percentile signifie que 90 % du temps de réponse est inférieur à cette valeur. Par exemple, si vous avez 500 requêtes avec des temps de réponse différents, le 90e percentile est une valeur telle que 90 % de toutes les autres valeurs sont inférieures à cette valeur. Seuls 10 % des temps de réponse seront supérieurs à cette valeur du 90e percentile. Cela est utile si certaines de vos requêtes ont un temps de réponse très élevé et biaisent la moyenne.
Requêtes par seconde : Nous devons trouver cette valeur avec les outils APM ou à l’aide des journaux de production. En fonction des utilisateurs concurrents, nous pouvons planifier le nombre de requêtes par seconde vers le serveur.
Utilisation de la mémoire : Ce sont des métriques côté infrastructure qui aident à découvrir les goulots d’étranglement. Aussi, vous devriez planifier votre charge de façon aussi réaliste que possible. Assurez-vous de ne pas bombarder le serveur avec des requêtes continues.
Utilisation du CPU : Comme pour la mémoire, il faut surveiller cette métrique lors des tests de performance.
Taux d’erreur : Nous devrions suivre le ratio transactions réussies/transactions en erreur. Le taux d’erreur ne devrait pas dépasser 2 % des transactions réussies. Si le taux d’erreur augmente avec le nombre d’utilisateurs concurrents, il peut y avoir un goulot d’étranglement potentiel.
Utilisateurs concurrents : Cette valeur doit être trouvée via les outils APM ou à partir des journaux de production. Normalement, cette valeur est basée sur une journée type d’activité.
Débit : Le débit montre la capacité du serveur à gérer les utilisateurs concurrents. Il y a une relation directe entre utilisateurs concurrents et débit. Le débit devrait augmenter avec le nombre d’utilisateurs accédant à l’application. Si le débit diminue malgré l’augmentation du nombre d’utilisateurs, cela indique un possible goulot d’étranglement.
Répartition de la charge utilisateur : La répartition de la charge utilisateur est un facteur important à prendre en compte lors de la conception de la charge. Si nous avons cinq scripts qui effectuent cinq fonctionnalités différentes d’une application, nous devons répartir la charge utilisateur aussi fidèlement que possible, basée sur notre investigation en production ou via les outils APM.
Ce sont des métriques très importantes que nous devrions garder en tête lors de la conception du modèle de charge. Il y aura d’autres métriques selon l’architecture et les exigences de l’application du client.
Liste de contrôle pour l’environnement de test de performance (avant exécution)
L’exemple de liste de contrôle ci-dessous est généralement suivi pour les tests de performance bout en bout au niveau entreprise, où un grand nombre de systèmes sont impliqués. Il est toujours recommandé de suivre une liste de contrôle de l’environnement même pour les tests de performance à plus petite échelle. Les activités changeront en fonction des environnements d’application, car il y a une grande différence comparée à une application sur cloud versus une application sur site.
Conclusion : Liste de contrôle de préparation aux tests de charge
Un test de performance logiciel réussi ne se produit pas par hasard. Les architectes, responsables produits, développeurs, et l’équipe de test de performance doivent travailler ensemble et aborder les exigences des tests de performance avant d’évaluer le logiciel. Pour des informations plus détaillées sur la plateforme LoadView, lisez notre article Technical Overview pour voir comment tirer le meilleur parti de vos tests de performance. Les tests de performance devraient être un processus continu. Lorsque votre site ou application web commence à croître, vous devrez effectuer des modifications pour accueillir une base d’utilisateurs plus large. Il y a toujours une marge d’amélioration dans toute application et pour les tests.
Nous espérons que cela vous a donné un bon aperçu des meilleures pratiques en matière de tests de performance. Si vous souhaitez une démonstration complète de la solution LoadView, inscrivez-vous pour une démo avec un ingénieur performance. Il vous guidera étape par étape à travers chaque partie du processus, de la création des scripts de test de charge et la configuration des tests, à l’exécution des tests et l’analyse des résultats.
Ou inscrivez-vous pour l’essai gratuit LoadView pour commencer à exécuter des tests de charge dès maintenant. Nous vous offrirons des tests de charge gratuits pour débuter ! Bon test de charge !