Selon la définition ISTQB, les tests de performance sont un processus de test pour déterminer les performances d’un logiciel.

Selon le glossaire IEEE :

« Essais effectués pour évaluer la conformité d’un système ou d’un composant aux exigences de performance spécifiées. Souvent, cela est effectué à l’aide d’un outil de test automatisé pour simuler un grand nombre d’utilisateurs. Également appelé “test de charge”. »

Ou

« Les essais effectués pour déterminer le degré auquel un système ou un composant accomplit ses fonctions désignées dans des limites données concernant le temps de traitement et le débit. »

Les différents types de test associés au test de performance

Test de charge

Un type de test concerné par la mesure du comportement d‘un composant ou système avec une charge croissante. Par exemple le nombre d‘utilisateurs et/ou le nombre de transactions en parallèle pour déterminer quelle charge peut être gérée par le composant ou système.

Test de stress

Un type de test de performance mené pour évaluer un système ou composant à ou au-delà des limites de sa charge de travail anticipées ou spécifiées, ou avec une disponibilité réduite de ressources telles que l‘accès mémoire ou serveurs [d‘après IEEE 610]. Test d’endurance

Test de robustesse

Test pour déterminer la robustesse d‘un produit logiciel (robustesse : le degré pour lequel un composant ou système peut fonctionner correctement en présence de données d‘entrée invalides ou de conditions environnementales stressantes)

Test de capacité

Il s’agit d’un test au cours duquel on va simuler un nombre d’utilisateurs sans cesse croissant de manière à déterminer quelle charge limite le système est capable de supporter. Éventuellement, des paramétrages peuvent être effectués, dans la même logique que lors des tests de dégradation. L’objectif du test étant néanmoins ici de déterminer la capacité maximale de l’ensemble système-applicatif dans une optique prévisionnelle.

Test aux limites

Il s’agit d’un test au cours duquel on va simuler en général une activité bien supérieure à l’activité normale, pour voir comment le système réagit aux limites du modèle d’usage de l’application. Proche du test de capacité, il ne recouvre pas seulement l’augmentation d’un nombre d’utilisateurs simultanés qui se limite ici à un pourcentage en principe prédéfini, mais aussi les possibilités d’augmentation du nombre de processus métier réalisés dans une plage de temps ou en simultané, en jouant sur les cadences d’exécutions, les temps d’attente, mais aussi les configurations de la plateforme de test dans le cadre d’architectures redondées (Crash Tests).

Test de fiabilité

Le test de la fiabilité consiste à exécuter une application afin de détecter et d’éliminer les défaillances avant que le système soit déployé.

Test de maintenabilité

Processus de test utilisé pour déterminer la maintenabilité d‘un produit logiciel (maintenabilité : facilité avec laquelle un produit logiciel peut être modifié pour en corriger les défauts, modifié pour couvrir de nouvelles exigences, modifié pour rendre des maintenances ultérieures plus aisées, ou adapté à un changement d‘environnement [ISO 9126])

Test de dégradation des transactions

Simulation de l’activité transactionnelle d’un seul scénario fonctionnel parmi tous les scénarios du périmètre des tests, de manière à déterminer quelle charge le système est capable de supporter pour chaque scénario fonctionnel et d’isoler éventuellement les transactions qui dégradent le plus l’ensemble du système. Ce test peut tenir compte ou non de la cadence des itérations, la représentativité en termes d’utilisateurs simultanés vs. Sessions simultanées n’étant pas ici un objectif obligatoire, s’agissant ici plutôt de déterminer les points de contention générés par chaque scénario fonctionnel. La démarche utilisée est d’effectuer une montée en charge linéaire jusqu’au premier point de blocage ou d’inflexion. Pour dépasser celui-ci, il faut paramétrer méthodiquement les composants systèmes ou applicatifs afin d’identifier les paramètres pertinents, ce jusqu’à obtention des résultats satisfaisants. Méthodologiquement, ce test est effectué avant les autres types de tests tels que performance, robustesse, etc. où tous les scénarios fonctionnels sont impliqués.

Test de volume

Tests quand le système est soumis à de larges volumes de données.

Le concept de test de performance

Outil de test de performance

Un outil de test est utile pour soutenir les tests de performance et a généralement deux installations principales : la génération de charge et la mesure des transactions de test. La génération de charge peut simuler des utilisateurs multiples ou des volumes élevés de données d’entrée. Pendant l’exécution, les mesures de temps de réponse sont prises à partir de transactions sélectionnées et celles-ci sont enregistrées. Les outils de test de performance fournissent normalement des rapports basés sur des journaux de test et des graphiques de charge par rapport aux temps de réponse.

 

 

 

Les caractéristiques ou les caractéristiques des outils de test de performance incluent le support pour :

• générer une charge sur le système à tester
• mesurer le calendrier des transactions spécifiques, car la charge sur le système varie
• mesurer les temps de réponse moyens
• produire des graphiques ou des graphiques de réponses au fil du temps

Test de chargement

Type d’essai visant à mesurer le comportement d’un composant ou d’un système à charge croissante, p. Ex. Le nombre d’utilisateurs parallèles et / ou le nombre de transactions pour déterminer quelle charge peut être gérée par le composant ou le système.

En effectuant des tests de performance, nous mesurons certains des éléments suivants :

• Caractéristique (SLA) Mesure (unités)
• Temps de réponse Secondes
• Hits par seconde #Hits
• Octets de débit par seconde
• Transactions per Second (TPS) #Transactions d’un processus métier spécifique
• Total TPS (TTPS) Nombre total de transactions
• Connexions par seconde (CPS) # Connexions / Sec
• Pages téléchargées par seconde (PDPS) # Pages / Sec

Quelques définitions et importance de ce qui précède

Temps de réponse

Qu’est-ce que le temps de réponse des transactions ?

Le temps de réponse des transactions représente le temps pris par l’application pour achever une transaction ou un processus métier défini.

Pourquoi est-il important de mesurer le temps de réponse des transactions ?

L’objectif d’un test de performance est de s’assurer que l’application fonctionne parfaitement sous charge. Cependant, la définition de “parfaitement” sous charge peut varier selon les systèmes.

En définissant un temps de réponse acceptable initial, nous pouvons comparer l’application si elle fonctionne comme prévu. L’importance du temps de réponse de transaction est qu’il donne à l’équipe de projet / l’équipe d’application une idée de comment l’application exécute dans la mesure du temps. Avec cette information, ils peuvent se rapporter aux utilisateurs / clients sur le temps attendu lors du traitement de la demande ou la compréhension de la façon dont leur application effectuée.

Que comprend le temps de réponse de transaction ?

Le temps de réponse de la transaction englobe le temps nécessaire à la demande faite au serveur Web, après avoir été traité par le serveur Web et envoyé au serveur d’applications. Qui dans la plupart des cas fera une demande au serveur de base de données. Tout cela sera alors répété à nouveau vers l’arrière à partir du serveur de base de données, du serveur d’application, du serveur Web et de nouveau à l’utilisateur. Prenez note que le temps pris pour la demande ou les données dans la transmission réseau est également pris en compte.

Pour simplifier, le temps de réponse de transaction comprend les éléments suivants :

• Temps de traitement sur le serveur Web
• Temps de traitement sur le serveur d’applications
• Temps de traitement sur le serveur de base de données.
• Latence du réseau entre les serveurs et le client

Comment mesurons-nous ?

Mesure du temps de réponse de la transaction commence lorsque la transaction définie fait une demande à la demande. À partir de là, jusqu’à ce que la transaction soit terminée avant de poursuivre la prochaine demande suivante (en termes de transaction), l’heure est mesurée et s’arrête lorsque la transaction est terminée.

Différences avec les Hits par secondes

Hits per Seconds mesure le nombre de “hits” effectués sur un serveur web. Ces “hits” pourraient être une requête faite au serveur web pour des données ou des graphiques. Toutefois, ce compteur ne représente pas bien pour les utilisateurs sur la façon dont leurs applications est performante car il mesure le nombre de fois que le serveur Web est accessible.

Comment pouvons-nous utiliser le temps de réponse des transactions pour analyser le problème de performance ?

Le temps de réponse de la transaction nous permet d’identifier les anomalies quand les problèmes de performance se posent. Cela sera représenté comme une réponse lente de la transaction, qui diffère significativement (ou légèrement) de la moyenne du temps de réponse de la transaction.

Avec cela, nous pouvons approfondir la corrélation en utilisant d’autres mesures telles que le nombre d’utilisateurs virtuels qui accèdent à l’application au moment du temps et les métriques liées au système (par exemple, l’utilisation du processeur) pour identifier la cause racine.

En rassemblant toutes les données qui ont été collectées lors du test de charge, nous pouvons corréler les mesures pour trouver les tendances et les goulets d’étranglement entre le temps de réponse, la quantité de charge générée et la charge utile de tous les composants de l’application.

Comment cela est-il bénéfique pour l’équipe du projet ?

En utilisant le temps de réponse de transaction, l’équipe de projet peut mieux se rapporter à leurs utilisateurs en utilisant des transactions comme une forme de protocole de langue que leurs utilisateurs peuvent comprendre. Les utilisateurs seront en mesure de savoir que les transactions (ou les processus d’affaires) se comportent à un niveau acceptable en termes de temps.

Les utilisateurs peuvent être incapables de comprendre la signification de l’utilisation du processeur ou de l’utilisation de la mémoire et donc utiliser un langage commun du temps est idéal pour transmettre les problèmes liés à la performance.

Relation entre la charge, le temps de réponse et la performance :

• La charge est directement proportionnelle au temps de réponse
• Le rendement est inversement proportionnel au temps de réponse.

Ainsi, comme et quand la charge augmente le temps de réponse augmente. Lorsque le temps de réponse augmente, la performance diminue.

Hits par seconde

Un Hit est une requête de n’importe quel type faite du client virtuel à l’application testée (client vers serveur). Il est mesuré par le nombre de Hits. Plus les Hits par seconde sont élevés, plus la demande est traitée par seconde.

Un client virtuel peut demander une page HTML, une image, un fichier, etc. Test de l’application pour Hits par seconde vous indiquera s’il existe un problème d’extensibilité possible avec l’application. Par exemple, si la contrainte sur une application augmente mais que les Hits par seconde ne le sont pas, il peut y avoir un

problème d’extensibilité dans l’application.

Un problème avec cette mesure est que Hits Per Second concerne toutes les requêtes de manière égale. Ainsi, une demande pour une petite image et HTML complexe généré à la volée seront tous deux considérés comme des coups. Il est possible que sur une centaine de visites sur l’application, le serveur d’applications a effectivement répondu à un seul et tous les autres ont été soit mis en cache sur le serveur Web ou un autre mécanisme de mise en cache.

Donc, il est très important d’examiner cette métrique pour L’application est prévue pour fonctionner. Est-ce que vos utilisateurs recherchent le même morceau de (Un formulaire de prestations statique) ou le même nombre d’utilisateurs engagera-t-il l’application dans une variété de tâches, comme la récupération d’images, l’achat d’articles ou la collecte de données à partir d’un autre site? Pour créer le test approprié, il est important de comprendre cette métrique dans le contexte de l’application. Si vous testez une fonction d’application qui requiert que le site fonctionne, par opposition aux données statiques actuelles, utilisez la mesure de pages par seconde.

Pages par seconde

Pages par seconde mesure le nombre de pages demandées à partir de l’application par seconde. Plus la page par seconde est élevée, plus le travail effectué par seconde est important. La mesure d’une requête explicite dans le script ou d’une trame dans un jeu de cadres fournit une mesure sur la façon dont l’application répond aux demandes de travail réelles. Ainsi, si un script contient une commande Naviguer vers une URL, cette demande est considérée comme une page. Si le code HTML renvoyé inclut les cadres, ils seront également considérés comme des pages, mais tous les autres éléments récupérés tels que les images ou les fichiers JS, seront considérés comme des occurrences, et non comme des pages. Cette mesure est essentielle à l’expérience de l’utilisateur final en matière de performances applicatives.

Corrélation : Si le stress augmente, mais le nombre de pages par seconde ne le fait pas, il peut y avoir un problème d’extensibilité. Par exemple, si vous commencez par 75 utilisateurs virtuels demandant 25 pages différentes simultanément, puis ajoutez les utilisateurs à 150, le nombre de pages par seconde devrait augmenter. Si ce n’est pas le cas, certains utilisateurs virtuels ne reçoivent pas leurs pages. Cela pourrait être causé par un certain nombre de problèmes et un doute probable est le débit.

Débit

“La quantité de données transférées sur le réseau est appelée débit. Il considère la quantité de données transférées du serveur au client uniquement et est mesurée en octets / sec.

Il s’agit d’une métrique de référence importante et est souvent utilisée pour vérifier que l’application et sa connexion au serveur fonctionnent. Le débit mesure le nombre moyen d’octets par seconde transmis de l’application testée aux clients virtuels exécutant l’ordre du test pendant un intervalle de rapport spécifique.

Cette métrique est la taille des données de réponse (somme) divisée par le nombre de secondes dans l’intervalle de rapport. Généralement, plus le stress sur une application, plus le débit. Si le stress augmente, mais le débit ne le fait pas, il peut y avoir un problème d’extensibilité ou un problème d’application.

Une autre note sur le débit en tant que mesure : il ne fournit généralement aucune information sur le contenu des données en cours de récupération. Ainsi, il peut être trompeur en particulier dans les tests de régression. Lors de la construction de tests de régression, laissez le temps dans le plan de test pour comparer la qualité des données retournées.

Allers-retours

Une autre mesure d’évolutivité et de performance utile est le test de Round Trips. Roundtrips vous indique le nombre total de fois où l’ordre du test a été exécuté par rapport au nombre total de fois où les clients virtuels ont tenté d’exécuter l’ordre du jour. Plus le programme est exécuté, plus le travail est effectué par le test et l’application.

Le scénario de test que représente l’ordre du jour influence la mesure des déplacements aller-retour. Cette métrique peut fournir toutes sortes d’informations utiles à partir de l’analyse comparative d’une application à la disponibilité de l’utilisateur final d’une application plus complexe. Ce n’est pas recommandé pour les tests de régression parce que chaque programme de test peut avoir un scénario et / ou une durée de scénario différents.

Heure de frappe

Temps de frappe est le temps moyen en secondes qu’il a fallu pour récupérer avec succès un élément de toute nature (image, HTML, etc). Le temps d’un coup est la somme des temps de connexion, d’envoi, de réponse et de traitement. Il représente la réactivité ou les performances de l’application pour l’utilisateur final. Plus l’application est accentuée, plus il faudra longtemps pour récupérer un élément moyen. Mais, comme Hits Per Second, les technologies de mise en cache peuvent influencer cette métrique. Pour tirer le meilleur parti de cette métrique, il faut savoir comment l’application répondra à l’utilisateur final.

Il s’agit également d’une excellente mesure pour la surveillance des applications après le déploiement.

Temps au premier octet

Cette mesure est importante parce que les utilisateurs considèrent souvent un mauvais fonctionnement du site s’il ne réagit pas assez rapidement. Time to First Byte mesure le nombre de secondes pendant lesquelles une requête est requise pour renvoyer son premier octet de données au Load Generator du logiciel de test.

Par exemple, Time to First Byte représente le temps pris après que l’utilisateur a poussé le bouton “enter” dans le navigateur jusqu’à ce que l’utilisateur commence à recevoir les résultats. Généralement, plus de connexions utilisateur simultanées ralentiront le temps de réponse d’une requête. Mais il ya aussi d’autres causes possibles d’une réponse ralentie.

Par exemple, il pourrait y avoir des problèmes avec les problèmes de matériel, de logiciel système ou de mémoire ainsi que des problèmes avec des structures de base de données ou des composants à réponse lente dans l’application.

Page Time

Page Time calcule le temps moyen en secondes nécessaire pour récupérer une page avec tout son contenu. Cette statistique est similaire à Hit Time mais ne concerne que les pages. Dans la plupart des cas, il s’agit d’une meilleure statistique pour travailler avec parce qu’il traite avec la vraie dynamique de l’application.

Puisque tous les hits ne peuvent pas être mis en cache, ces données sont plus utiles en termes de suivi de l’expérience d’un utilisateur (positif ou frustré). Il est important de noter que dans de nombreux logiciels d’essai, vous pouvez activer ou désactiver la mise en cache en fonction des besoins de votre application.

Généralement, plus le stress sur le site est lent, plus sa réponse. Mais comme le stress est une combinaison du nombre d’utilisateurs simultanés et de leur activité, un stress plus important peut ou non avoir un impact sur l’expérience de l’utilisateur. Tout dépend des fonctions de l’application et des utilisateurs. Un site avec 150 utilisateurs simultanés qui recherchent des renseignements sur les prestations diffère d’un site de nouvelles lors d’une urgence nationale. Comme toujours, les mesures doivent être examinées dans le contexte.

Rounds échoués / Rounds échoués par seconde

Lors d’un test de charge, il est important de savoir que les requêtes d’application attendu. Les Rounds échoués et les Rounds par seconde défaillants testent le nombre de Rounds qui échouent.

Cette métrique est un « indicateur métrique » qui fournit l’assurance de la qualité et de tester la performance de l’application et l’état de défaillance. Si vous commencez à voir les arrêts ratés ou les redondances par seconde infructueux, vous devriez généralement consulter les journaux pour voir quels types de défaillances correspondent à ce rapport de métrique. En outre, avec certains paquetages de test logiciel, vous pouvez définir ce que la définition d’un round échoué dans une application.

Parfois, les erreurs d’image de base ou de page manquantes (codes d’erreur HTTP 404) pourraient être définies pour échouer une ronde, ce qui arrêterait l’exécution de l’ordre du jour de test à ce point et recommencer au sommet de l’ordre du jour.

Échec de la réussite / Échec des succès par seconde

Ce test offre un aperçu de l’intégrité de l’application pendant le test de charge. Un exemple de requête pouvant échouer pendant l’exécution est un lien interrompu ou une image manquante du serveur. Le nombre d’erreurs devrait croître avec la taille de la charge. S’il n’y a pas d’erreurs avec une charge faible, le nombre d’erreurs avec une charge élevée doit rester nul. Si le pourcentage d’erreurs augmente seulement pendant les charges élevées, l’application peut avoir un problème d’extensibilité.

Échec des connexions

Ce test est simplement le nombre de connexions refusées par l’application au cours du test. Ce test mène à d’autres tests. Une connexion échouée pourrait signifier que le serveur était trop occupé pour traiter toutes les requêtes, donc il a commencé à les refuser. Il pourrait s’agir d’un problème de mémoire. Cela pourrait également signifier que l’utilisateur a envoyé des données fausses ou malformées auxquelles le serveur ne pouvait pas répondre, de sorte qu’il a refusé la connexion.

Vous trouvez cette article intéressant ?

Lisez la suite ici