performance testing vs load testing vs stress testing
Différence entre les tests de performance, les tests de charge et les tests de résistance - avec des exemples
Notre précédent tutoriel dans cette série sera le meilleur Guide des tests de performance pour tout débutant.
Dans le domaine des tests de logiciels, nous rencontrons des termes comme les tests de performance, les tests de charge, les tests de résistance, etc. Ces termes sont souvent mal compris et interprétés comme les mêmes concepts.
Cependant, il existe une différence significative entre ces trois types de tests et il est important pour un testeur de comprendre la même chose.
=> Cliquez ici pour une série complète de didacticiels sur les tests de performance
modèle de rapport de résumé de test dans Excel
Dans ce didacticiel, nous aborderons chacun de ces types de tests pour comprendre les différences exactes entre eux.
Ce que vous apprendrez:
Différence entre les tests de performances, les tests de charge et les tests de résistance
# 1) Test de performance
Qu'est-ce que le test de performance?
Les tests de performances sont les tests effectués pour vérifier les performances des composants d'un système dans une situation donnée.
L'utilisation des ressources, l'évolutivité et la fiabilité du produit sont également validées dans le cadre de ces tests. Ces tests sont le sous-ensemble de l'ingénierie des performances, qui se concentre sur la résolution des problèmes de performances dans la conception et l'architecture d'un produit logiciel.
L'image ci-dessus nous explique clairement que Les tests de performance sont le sur-ensemble des tests de charge et de contrainte. Les autres types de tests inclus dans les tests de performance sont les tests de pointes, les tests de volume, les tests d'endurance et Test d'évolutivité . Ainsi, les tests de performance sont fondamentalement un terme très large.
Objectif du test de performance:
Le principal objectif des tests de performance consiste à établir le comportement de référence du système. Il existe un certain nombre de critères de référence définis par l'industrie qui doivent être respectés lors des tests de performance.
Les tests de performance ne visent pas à trouver des défauts dans l'application. Il ne réussit pas ou n'échoue pas non plus le test. Il aborde plutôt la tâche critique de définir le benchmark et standard pour une application . Les tests de performance doivent être effectués de manière très précise. Une surveillance étroite des performances de l'application / du système est la principale caractéristique des tests de performances.
La référence et la norme de l'application doivent être définies en termes d'attributs tels que la vitesse, le temps de réponse, le débit, l'utilisation des ressources et la stabilité. Tous ces attributs sont testés dans un test de performance.
Par exemple,
Par exemple, vous pouvez tester les performances du réseau de l'application via le graphique «Vitesse de connexion par rapport à la latence». La latence est la différence de temps entre les données à atteindre de la source à la destination.
Une page de 70 Ko ne prendrait pas plus de 15 secondes pour se charger pour la pire connexion du modem 28,8 kbps (latence = 1000 millisecondes), tandis que la page de même taille apparaîtrait dans les 5 secondes pour la connexion moyenne de 256 kbps DSL (latence = 100 millisecondes).
Une connexion T1 de 1,5 Mbps (latence = 50 millisecondes) aurait le benchmark de performance défini sur 1 seconde pour atteindre cet objectif.
Une autre Exemple serait celle d'un modèle de demande-réponse. Nous pouvons établir un point de repère selon lequel la différence de temps entre la génération de la demande et l'accusé de réception de la réponse doit être comprise entre x ms (millisecondes) et y ms, où x et y sont les chiffres standard.
Un test de performance réussi devrait projeter la plupart des problèmes de performance, qui pourraient être liés à la base de données, au réseau, aux logiciels, au matériel, etc.
# 2) Test de charge
Les tests de charge sont destinés à tester le système en augmentant constamment et régulièrement la charge sur le système jusqu'à ce qu'il atteigne la limite de seuil. Il s'agit d'un sous-ensemble de tests de performances.
Les tests de charge peuvent être facilement effectués en utilisant l'un des outils d'automatisation appropriés disponibles sur le marché. WAPT et LoadRunner sont deux outils célèbres qui facilitent les tests de charge. Les tests de charge sont également connus sous des noms tels que Test de volume et Test d'endurance .
Cependant, les tests de volume se concentrent principalement sur les bases de données. Test d'endurance teste le système en le maintenant sous une charge importante pendant une période prolongée.
Le seul but des tests de charge est d'attribuer au système le travail le plus important qu'il peut éventuellement gérer pour tester l'endurance du système et surveiller les résultats. Un fait intéressant ici est que parfois le système est alimenté par une tâche vide pour déterminer le comportement du système en situation de charge nulle.
Les attributs qui sont surveillés dans un test de charge incluent les performances de pointe, le débit du serveur, le temps de réponse sous différents niveaux de charge (en dessous du seuil de rupture), l'adéquation de l'environnement H / W, le nombre d'applications utilisateur qu'il peut gérer sans affecter les performances.
Objectif de test de charge:
Les objectifs des tests de charge incluent:
- Exposer les défauts d'une application liés au débordement de la mémoire tampon, aux fuites de mémoire et à la mauvaise gestion de la mémoire. Les problèmes qui résulteraient des tests de charge peuvent inclure des problèmes d'équilibrage de charge, des problèmes de bande passante, la capacité du système existant, etc.
- Pour déterminer la limite supérieure de tous les composants d'une application comme une base de données, du matériel, un réseau, etc. afin que l'application puisse gérer la charge anticipée à l'avenir.
- Pour définir les SLA de l'application.
Par exemple,
Pensons à vérifier la fonctionnalité de messagerie d'une application, qui pourrait être inondée de 1 000 utilisateurs à la fois. Désormais, 1000 utilisateurs peuvent déclencher les transactions par e-mail (lire, envoyer, supprimer, transférer, répondre) de différentes manières.
Si nous prenons une transaction par utilisateur et par heure, alors ce serait 1000 transactions par heure. En simulant 10 transactions / utilisateurs, nous pourrions charger tester le serveur de messagerie en l'occupant avec 10000 transactions / heure.
Un autre exemple de test de charge est illustré dans l'image ci-dessous:
L'image ci-dessus représente un test de charge effectué dans l'outil appelé JMeter . Ce test est effectué pour identifier le nombre d'utilisateurs qu'un système peut gérer. Dans ce test, 100 utilisateurs sont ajoutés toutes les 30 secondes jusqu'à ce que la charge atteigne 1000 utilisateurs. Chaque étape prend 30 secondes et JMeter attend 30 secondes avant de lancer l'étape suivante.
Une fois que la charge atteint 1000 threads, tous continueront à fonctionner pendant 300 secondes (5 minutes) ensemble, puis arrêteront finalement 10 threads toutes les 3 secondes.
# 3) Test de résistance
Dans le cadre des tests de résistance, diverses activités visant à surcharger les ressources existantes avec des emplois excédentaires sont menées dans le but de briser le système. Test négatif , qui comprend le retrait des composants du système est également effectué dans le cadre des tests de résistance.
Aussi connu sous le nom essai de fatigue , ces tests doivent capturer la stabilité d'une application en la testant au-delà de sa capacité de bande passante.
Ainsi, fondamentalement, les tests de résistance évaluent le comportement d'une application au-delà de la charge de pointe et des conditions normales.
Le but des tests de résistance est de vérifier la défaillance du système et de surveiller la façon dont le système récupère en douceur. Le défi ici est de mettre en place un environnement contrôlé avant de lancer le test afin de pouvoir capturer précisément le comportement du système à plusieurs reprises dans les scénarios les plus imprévisibles.
Les problèmes qui pourraient éventuellement survenir à la suite des tests de résistance peuvent inclure des problèmes de synchronisation, des fuites de mémoire, des conditions de course, etc. Si le test de résistance vérifie le comportement du système dans la situation d'une augmentation soudaine du nombre d'utilisateurs , alors cela s'appelle un test de pointe.
Si le test de résistance consiste à vérifier la durabilité du système sur une période de temps en augmentant lentement le nombre d'utilisateurs, il est appelé test d'imprégnation.
Objectif du test de résistance:
Le but des tests de résistance est d'analyser les rapports post-crash pour définir le comportement de l'application après une panne.
Le plus grand défi est de s'assurer que le système ne compromet pas la sécurité des données sensibles après la panne. Lors d'un test de résistance réussi, le système reviendra à la normale avec tous ses composants, même après la panne la plus terrible.
Par exemple,
Par exemple, un traitement de texte comme Writer1.1.0 par OpenOffice.org est utilisé dans le développement de lettres, présentations, feuilles de calcul, etc. Le but de nos tests de résistance est de le charger avec des caractères en excès.
Pour ce faire, nous allons coller à plusieurs reprises une ligne de données, jusqu'à ce qu'elle atteigne son seuil limite de traitement d'un grand volume de texte. Dès que la taille des caractères atteint 65 535 caractères, il refuse tout simplement d'accepter plus de données.
Le résultat des tests de résistance sur Writer 1.1.0 produit le résultat qu'il ne plante pas sous le stress et il gère la situation avec grâce, ce qui garantit que l'application fonctionne correctement même dans des conditions de stress rigoureuses.
Un autre exemple de test de charge qui décrit un test de pointe via une montée en puissance soudaine de 7000 utilisateurs est illustré ci-dessous:
FAQ
Après avoir eu suffisamment de discussions sur les tests de performance, les tests de résistance et les tests de charge, examinons maintenant quelques questions fréquentes liées auxquelles les testeurs cherchent une réponse.
Q # 1) Le test de charge et le test de performance sont-ils identiques?
Répondre: La réponse à cette question est «non». Ils ne sont pas les mêmes.
Vous devez maintenant avoir clairement compris la différence entre les tests de performances et les tests de charge. Vous pouvez vous référer au résumé tabulaire ci-dessous pour voir comment les tests de performance et de charge ont des objectifs différents, des attributs de portée à étudier et des problèmes à découvrir.
Q # 2) Est-ce un test injuste d'effectuer des tests de résistance en même temps que vous effectuez des tests de charge?
Répondre: C'est également une question courante dans de nombreux entretiens de test de logiciels et examens de certification, car il est injuste de faire des tests de résistance et des tests de charge en parallèle? La réponse à cette question est «non». Il n'est pas injuste de faire des tests de résistance en même temps que vous effectuez des tests de charge.
Aucun test n'est jamais injuste. En tant que testeur, votre travail consiste à trouver des problèmes. Cependant, les actualités des tests logiciels peuvent s'appliquer et tout problème que vous détectez dans cette situation peut ne pas être résolu.
Q # 3) Les tests de récupération font-ils partie des tests de performances?
Répondre: Oui, les tests de récupération sont classés dans les tests de performance et parfois ils sont également menés avec des tests de charge. Dans test de récupération , on y accède pour savoir dans quelle mesure une application est capable de récupérer des pannes, plantages, pannes matérielles et autres problèmes similaires.
Dans cette activité, le logiciel est forcé de tomber en panne, puis il est vérifié s'il est capable de récupérer correctement. Par exemple, redémarrage soudain du système lorsqu'une application est en cours d'exécution, puis vérification de l'intégrité des données de l'application.
Q # 4) Les tests de performance nécessitent-ils un codage?
Répondre: Les tests de performances ne vous obligent pas à connaître le niveau avancé de codage. Cependant, avoir une connaissance fondamentale de la programmation est un avantage supplémentaire.
Par exemple, si vous utilisez JMeter, il est bon que vous connaissiez les principes de base de Java. Cela peut vous aider à déboguer certaines choses et vous pouvez également écrire votre propre script si nécessaire.
Q # 5) Qu'est-ce que le test Spike dans les tests de performance?
Répondre: Dans les tests de pointe, la charge est brusquement augmentée ou diminuée par un grand nombre d'utilisateurs et plus tard, le comportement du système est observé. Les tests de pointes sont principalement effectués pour vérifier si le système est capable de gérer les changements soudains de la charge.
Différence entre les tests de charge et de contrainte
Pour résumer, observons les principales différences entre les tests de charge, les tests de résistance et les tests de performances dans le tableau ci-dessous:
Test de performance | Test de charge | Test de stress | |
---|---|---|---|
Domaine | Superset de tests de charge et de stress | Un sous-ensemble de tests de performances. | Un sous-ensemble de tests de performances. |
Portée | Portée très large. Comprend - Test de charge, test de résistance, test de capacité, test de volume, test d'endurance, test de pointe, test d'évolutivité et test de fiabilité, etc. | Portée plus étroite par rapport aux tests de performance. Comprend des tests de volume et des tests d'endurance. | Portée plus étroite par rapport aux tests de performance. Comprend des tests de trempage et des tests de pointes. |
Objectif majeur | Pour définir la référence et les normes de l'application. | Pour identifier la limite supérieure du système, définissez le SLA de l'application et voyez comment le système gère les volumes de charge élevés. | Identifier comment le système se comporte sous des charges intenses et comment il se remet d'une panne. Fondamentalement, pour préparer votre application à la pointe de trafic inattendue. |
Limite de charge | Les deux - au-dessous et au-dessus du seuil d'une pause. | Jusqu'au seuil de la pause | Au-dessus du seuil de rupture |
Attributs étudiés | Utilisation des ressources, fiabilité, évolutivité, utilisation des ressources, temps de réponse, débit, vitesse, etc. | performances de pointe, débit du serveur, temps de réponse sous différents niveaux de charge (en dessous du seuil de rupture), l'adéquation de l'environnement H / W, le nombre d'applications utilisateur peut gérer, les exigences d'équilibrage de charge, etc. | Stabilité au-delà de la capacité de bande passante, temps de réponse (au-dessus du seuil de rupture), etc. |
Problèmes identifiés grâce à ce type de test | Tous les bogues de performance, y compris le gonflement de l'exécution, la portée de l'optimisation, les problèmes liés à la vitesse, la latence, le débit, etc. Fondamentalement - tout ce qui concerne les performances! | Problèmes d'équilibrage de charge, problèmes de bande passante, problèmes de capacité du système, temps de réponse médiocre, problèmes de débit, etc. | Failles de sécurité avec surcharge, problèmes de corruption des données en situation de surcharge, lenteur, fuites de mémoire, etc. |
Différence entre les tests de charge, de contrainte et de volume
À présent, nous connaissons déjà les tests de charge et de contrainte ainsi que les différences entre les deux. Explorons maintenant ce qu'est le test de volume et en quoi est-il différent des tests de charge et des tests de résistance.
Le test de volume est également une sorte de test de performance qui se concentre principalement sur la base de données.
Dans les tests de volume, il est vérifié comment le système se comporte par rapport à un certain volume de données. Ainsi, les bases de données sont remplies de leur capacité maximale et leurs niveaux de performance tels que le temps de réponse et le débit du serveur sont surveillés.
Pour rester très simple, la différence entre les tests de charge, de contrainte et de volume est indiquée ci-dessous:
Test de volume | Test de charge | Test de stress |
---|---|---|
Une énorme quantité de données | Un grand nombre d'utilisateurs | Trop d'utilisateurs, trop de données, vers un crash système. |
Conclusion
Dans ce tutoriel, nous avons vu et compris à travers des exemples comment les tests de performance, les tests de charge et les tests de résistance sont différents les uns des autres et quelle est la portée de chaque type de test.
Nous avons également examiné brièvement de nombreuses catégories soumises à des tests de performances, comme les tests de pics, les tests de récupération, les tests de volume, etc. et avons compris en quoi chacune d'elles est différente les unes des autres.
Nous espérons que ce tutoriel vous aurait été d'une immense aide pour comprendre la différence pratique entre les tests de performance, de charge et de stress.
Consultez notre prochain didacticiel pour en savoir plus sur les tests fonctionnels et les tests de performances.
meilleur site Web pour regarder l'anime gratuitement
=> Visitez ici pour une série complète de didacticiels sur les tests de performances
Tutoriel PREV | Tutoriel SUIVANT
lecture recommandée
- Un guide complet de test de performance avec des exemples
- Guide des tests de stress pour les débutants
- Guide complet de test de charge pour les débutants
- Test de charge, de stress et de performance des applications Web à l'aide de WAPT
- Test de charge avec les didacticiels HP LoadRunner
- Test des performances du cloud: fournisseurs de services de test de charge basés sur le cloud
- Test fonctionnel vs test de performance: doit-il être fait simultanément?
- Test de charge à l'aide de LoadUI - Un outil de test de charge gratuit et open source