Débit dans les tests de performance : pourquoi c'est important

Les testeurs de logiciels pratiquent plusieurs techniques pour vérifier la qualité des applications. Les tests de performance sont l'une des mesures décisives où l'équipe teste la vitesse, le temps de réponse, l'évolutivité et la fiabilité du logiciel.

Dans cet article, nous allons discuter des éléments essentiels concernant le débit dans les tests de performances.

Les bases du débit dans les tests de performances

Avant de commencer avec les détails, examinons quelques éléments essentiels des tests de performance.

Pourquoi des tests de performances ?

Les tests de performance sont importants car :

• Outre les problèmes logiques ou fonctionnels couramment signalés, les applications sont également aux prises avec des problèmes de réseau qui déterminent leur fiabilité.

• Les clients sont facilement frustrés lorsque leur expérience d'accessibilité des applications n'est pas bonne.

• La vitesse et les performances des applications changent en fonction de la région où elles sont utilisées. Il est donc important de juger des performances de l'application à différents débits et réseaux.

• Un système peut fonctionner parfaitement avec un nombre spécifique d'utilisateurs, mais il peut se comporter différemment lorsque le nombre d'utilisateurs dépasse cette limite. Il est donc nécessaire de vérifier les bases des tests de performance dans des conditions spécifiques.

Quand devriez-vous commencer les tests de performance ?

Vous pouvez commencer les tests de performances le plus tôt possible dans les étapes de développement de votre application logicielle. De cette façon, vous pouvez optimiser votre serveur Web et éviter des coûts commerciaux ultérieurs.

Découvrir les problèmes de performances après le déploiement de l'application signifie de nombreuses heures de travail pour résoudre les problèmes. Cela peut donc coûter très cher.

Dès que les pages Web de base de l'application fonctionnent, l'équipe d'assurance qualité doit effectuer les tests de charge initiaux. À partir de ce moment, ils doivent effectuer régulièrement des tests de performances pour chaque version.

Il existe différents outils et critères pour tester les performances des applications. Ici, nous allons parler d'une mesure importante, à savoir le débit.

Qu'est-ce que le débit dans les tests de performances ?

Chaque application logicielle ou site Web compte de nombreux utilisateurs qui effectuent différentes demandes. Les testeurs doivent s'assurer que l'application répond à la capacité requise de demandes avant de la mettre en ligne.

Certaines bases des tests de performance doivent être mesurées au cours du processus. Le débit en est un . Voyons quel est le débit dans les tests de performances.

Le débit est une mesure clé qui indique le nombre de requêtes qu'une application logicielle peut traiter en un temps spécifique (seconde, minute ou heure).

Avant de commencer le test, nous devons définir un objectif de débit de performance réaliste, afin d'obtenir des résultats plus précis et fiables.

Voici quelques facteurs importants pour déterminer un débit réaliste :

• Quantité estimée et types d'utilisateurs qui vont utiliser l'application ou le site Web.

• Le comportement de l'utilisateur, c'est-à-dire les actions qu'il va effectuer à l'aide de l'application.

• Les types de connexion qui vont affecter la réponse du système et, en fin de compte, l'expérience utilisateur également.

• Les effets des pauses et des retards sur le système.

Débit dans le scénario réel

Ici, nous expliquerons le concept de débit à l'aide d'un exemple concret. Imaginez qu'il y ait un stand de restauration rapide nommé "Yummy Burgers". Ils servent des hamburgers et des frites pour les clients.

Disons que "Yummy Burgers" a trois travailleurs dans le stand, et chaque travailleur prend toujours 5 minutes pour servir la nourriture à un client.

Ainsi, s'ils ont trois clients alignés pour être servis par trois employés, cela signifie que "Yummy Burgers" peut servir de la nourriture à trois clients en 5 minutes.

Par conséquent, si nous devions faire un rapport de performance de "Yummy Burgers", cela montrerait que son débit est de trois clients toutes les cinq minutes.

C'est le dilemme de Yummy Burgers que, quel que soit le nombre de clients qui attendent la nourriture, le nombre maximum qu'ils peuvent gérer pendant une période de temps spécifique sera toujours le même, c'est-à-dire trois. C'est le débit maximal .

Au fur et à mesure que de plus en plus de clients font la queue pour la nourriture, ils doivent attendre leur tour, créant ainsi une file d'attente.

Le même concept s'applique au test d'une application Web.

Si une application Web reçoit 100 requêtes par seconde, mais qu'elle ne peut gérer que 70 requêtes par seconde, les 30 requêtes restantes doivent attendre dans une file d'attente.

Dans les tests de performances, nous désignons le débit par « Transactions par seconde » ou TPS .

Débit dans les tests de performances JMeter :

L'utilisation d'Apache JMete r est très populaire pour tester les performances d'une application logicielle. JMeter est utile pour déterminer le nombre maximum d'utilisateurs simultanés que l'application peut gérer et fournit également une analyse graphique pour les tests de performances.

JMeter fournit de nombreuses façons d'enregistrer la valeur du débit. Voici quelques écouteurs JMeter que vous pouvez utiliser à cette fin :

• Rapport sommaire
• Rapport agrégé
• Graphique agrégé
• Résultats du graphique

JMeter fournit également un composant de minuterie, ' Constant Throughput Timer' , que vous pouvez utiliser pour définir la valeur de Transactions per Second (TPS) afin de tester la charge de l'application.

Maintenant, nous allons montrer l'utilisation du débit dans le test de performance à l'aide de JMeter. Supposons que nous allons effectuer un exemple de test avec 100 threads simultanés et suivre la valeur du débit.

Supposons que la dernière version de JMeter soit installée sur notre système et que nous ayons déjà effectué toutes les autres configurations requises. Maintenant, nous devons construire un plan de test.

1. Configuration du test

Dans ce test, nous allons définir cinq éléments ThreadGroup. Chacun de ces éléments aura un temps de montée en puissance différent, c'est-à-dire 0, 15, 25, 35 et 45. Le temps de montée en puissance est la durée de démarrage de chaque thread. Nous allons configurer 100 utilisateurs dans ces éléments ThreadGroup.

Si nous voulons configurer un plus grand nombre d'utilisateurs, plus de temps de montée en puissance sera nécessaire.

Ces groupes de threads auront un échantillonneur HTTP qui générera des requêtes sur la page d'accueil d'un exemple de site Web (supposons www.samplesite.com).

Dans le cas d'utilisation 1, nous avons un élément ThreadGroup configuré avec 100 threads et son temps de montée en puissance est de 0.

Le champ "Nombre de threads" sera défini sur 100. Cela signifie que 100 utilisateurs enverront des demandes à la fois. De même, nous pouvons également configurer les 4 threads restants et définir leur temps de montée en puissance sur 15, 25, 35 et 45. En outre, nommez les échantillonneurs pour chaque groupe de threads.

Comme mentionné précédemment, ces échantillonneurs HTTP pointeront vers la page d'accueil de l'exemple de site Web.

Il est nécessaire d'exécuter ces groupes de threads dans un ordre approprié. À cette fin, sélectionnez "Plan de test" dans le panneau de configuration et cochez le champ "Exécuter les groupes de threads consécutivement".

2. Analyse des résultats des tests

« Aggregate Report » est un écouteur qui est utilisé pour analyser et observer les résultats des tests. Pour utiliser cet écouteur, faites un clic droit sur "Plan de test" et sélectionnez :

Ajouter → Écouteur → Rapport agrégé

Cliquez ensuite sur l'icône de démarrage pour exécuter le test.

Voyons maintenant comment comprendre les résultats du débit du rapport agrégé.

Le premier groupe de threads avec un temps de montée de 0 montre que tous les threads mettent une charge instantanée sur le serveur en démarrant immédiatement. Ce scénario a un débit assez élevé, mais il n'est pas pratique. Donc, cela ne montrera pas une sortie réaliste.

Les deuxième et troisième groupes de threads ont un temps de montée en puissance d'une plage réaliste, ils sont donc plus susceptibles d'afficher un débit de performances et un temps de chargement de demande appropriés.

Les groupes de threads quatre et cinq ont un temps de montée en puissance plus élevé, ce qui signifie que leur débit diminuera.

Par conséquent, la sortie fiable peut être déterminée à partir des résultats des deuxième et troisième groupes de threads.

Points importants à retenir lors du test de débit :

La décision de déployer une nouvelle version ou une modification repose sur la capacité de l'application à gérer des TPS spécifiques. Ainsi, le plan de test de performance a certains objectifs de débit. Mais nous devons nous assurer que ces objectifs sont réalistes et représentent les véritables caractéristiques de la production.

Le plan de test est en vain si nous le réussissons en utilisant des conditions irréalistes. Par exemple, le plan de test que nous avons décrit ci-dessus avait des valeurs de débit plus élevées pour le premier groupe de threads, mais il ne décrivait pas le scénario réel de l'environnement en direct.

Ainsi, en utilisant de telles méthodes, nous ne pouvons pas avoir la bonne idée si notre application va gérer la charge réelle ou non. Par conséquent, la mise en place de tests adaptés est cruciale.

Nous allons maintenant discuter de certains points importants que nous devons prendre en compte pour tester le débit des performances.

• Conception de test appropriée : la conception de test détermine si le débit généré est réaliste ou non. Dans le scénario en temps réel, chaque demande peut être différente et peut également déclencher des processus compliqués pour les résultats requis. Nous devons donc manipuler les tests en fonction de l'environnement en direct attendu.

• Représentation des utilisateurs réels : Chaque utilisateur de l'application peut avoir des requêtes qui affectent les ressources du système. Ainsi, si de vrais utilisateurs ne sont pas représentés dans le scénario de test, les résultats peuvent montrer une utilisation inexacte des ressources au niveau du backend. Ainsi, le test n'émulera pas les bonnes conditions.

• **==Considérez les pauses et les retards : ==**Dans un environnement en direct, les utilisateurs doivent réfléchir, prendre et traiter des informations, saisir des informations dans les champs, etc. Mais les serveurs utilisent toujours des ressources pendant cette pause. Essayez donc d'intégrer ces comportements d'utilisateurs dans vos scripts.

• Vitesse de connexion : les utilisateurs de l'application sont connectés via différentes vitesses de réseau, régions ou via des réseaux mobiles. Il est donc nécessaire de choisir une bande passante qui représente également ces connexions utilisateur.

conclusion

En un mot, le débit est un indicateur de performance crucial des applications Web . Mais, dépendre uniquement des métriques de débit ne suffit pas. Par conséquent, il doit être vérifié avec la latence et les temps de réponse .

Il est également très important de créer un débit réaliste pour atteindre les objectifs de test de performance définis.