Test d'endurance dans les logiciels : signification et exemples
Thomas Hamilton
⚡ Résumé intelligent
Les tests de charge continue (Soak Testing) appliquent une charge réaliste et soutenue à une application sur une période prolongée afin de révéler les problèmes qui n'apparaissent qu'avec le temps. Les fuites de mémoire, la saturation des connexions et la lente dérive des performances sont les défauts qu'ils permettent de détecter.
Qu'est-ce que le test d'immersion ?
Test de trempage est un type de test non fonctionnel utilisé pour mesurer les performances d'une application logicielle sous un énorme volume de charge pendant une période de temps prolongée. L'objectif des tests Soak est de garantir si l'application logicielle supporte un volume d'utilisation élevé et de vérifier ce qui se passerait en dehors de ses attentes de conception.
L'image ci-dessous représente un cycle de test qui montre à quelle étape le test de trempage (Type de test de performances) est effectué sur une application.
Dans ce type de test, ce qui est essentiellement surveillé est l'utilisation de la mémoire par une application dans un système. Il s'agit de tests au niveau du système, pour déterminer si le système résistera à un volume d'utilisation très élevé et pour voir ce qui se passerait en dehors de ses attentes de conception.
Pourquoi effectuer des tests de trempage ?
Un système peut se comporter normalement lorsqu'il est utilisé pendant 2 heures, mais lorsque le même système est utilisé en continu pendant 10 heures ou plus, il peut tomber en panne ou se comporter de manière anormale/aléatoire/il peut planter. Pour prédire une telle défaillance, des tests de trempage sont effectués.
Quand faire des tests de trempage ?
Les tests de trempage doivent être effectués dans les scénarios suivants : –
- Avant que le build ne soit déployé sur le client, c'est-à-dire avant la sortie de toute application sur une plate-forme spécifique, il doit passer par une série de tests de charge réussis à des niveaux de trafic élevés ou équivalents. Après cela des tests de trempage sont effectués. Cela nous aide à déterminer comment exécuter une application particulière pendant une période prolongée. Si des problèmes tels que des fuites de mémoire/une corruption de la mémoire sont détectés pendant la période, c'est-à-dire lorsqu'il est en mode Soak, ils doivent être immédiatement signalés.
- Le meilleur moment pour effectuer un test d'immersion est le week-end, car une application doit être en état d'exécution aussi longtemps que pendant une journée ou une nuit. Cela dépend totalement des limites de la situation de test. Les tests d'immersion sont l'une des exigences de conformité les plus importantes qui doivent être très strictement suivies par chaque entreprise.
Stratégie de test d'immersion
Les tests d’immersion de longue session sont une stratégie dans laquelle un système est sous charge pendant une période plus longue.
Un exemple simple est celui où l'utilisateur reste connecté à un système pendant de nombreuses heures pour exécuter un certain nombre de transactions commerciales. De cette façon, beaucoup de données sont créées. Il peut y avoir beaucoup de charge sur le système/serveur de base de données, ce qui peut entraîner un blocage/plantage du système/serveur de base de données.
Dans le cadre des tests d'immersion de longue session, des activités de plusieurs jours (disons 30 jours) sont effectuées dans un laps de temps restreint (disons 2 jours). Le nombre de transactions au cours de cette période restreinte doit correspondre ou dépasser plusieurs jours de transactions. L'accent doit être mis sur le nombre de transactions traitées. La partie la plus importante du Soak Testing consiste à vérifier la mémoire disponible dans le processeur et la quantité de mémoire qui sera utilisée. Nous devons enregistrer l'utilisation de la mémoire au début et à la fin d'un test d'immersion. Si nécessaire, l'utilisation de la mémoire par des installations telles que Java Les machines virtuelles sont également importantes et doivent être surveillées.
Vous trouverez ci-dessous quelques vérifications supplémentaires qui doivent être effectuées par tout utilisateur/testeur avant de commencer le test de trempage :
a) Surveiller la consommation des ressources de la base de données.
b) Surveiller la consommation des ressources du serveur (hors utilisation du processeur).
c) Le test d'immersion doit s'exécuter avec une concurrence réaliste des utilisateurs.
Caractéristiques des tests de trempage
Une méthode de test de trempage standard doit avoir les caractéristiques suivantes : –
- La durée de la plupart des tests de trempage est souvent déterminée par le temps disponible.
- Toute application doit s'exécuter sans aucune interruption si elle nécessite une période de temps prolongée.
- Il doit couvrir tous les scénarios convenus par les parties prenantes.
- La plupart des systèmes ont une période de maintenance régulière et le temps entre ces périodes est un facteur clé pour déterminer la portée d'un test d'immersion.
Exemples de tests d'immersion
- Dans le cas du domaine bancaire où il y a une grande quantité de données provenant des commerçants, le testeur mettra le système en charge en continu pendant 70h à 150h pour vérifier le comportement de l'application pendant cette période de chargement.
- Supposons qu'il y ait 33,000 60 connexions à passer par le système, cela représente sept jours et demi d'activité. Dans ce cas, un test de trempage de 70 à 6 heures peut être démarré vendredi soir vers heures et complété par Monday matin à 6 heures du matin. Ce n'est qu'avec un tel test qu'il sera possible d'observer une dégradation des performances dans des conditions contrôlées.
- Dans le cas des jeux vidéo, Mobile les applications, etc. impliquent de laisser le jeu ou l'application en cours d'exécution pendant une période de temps prolongée, dans divers modes de fonctionnement, tels que la veille, la pause à l'écran titre, etc. pour savoir si une application peut gérer la charge attendue en permanence. .
Problèmes courants observés lors des tests de trempage
- Allocation de mémoire (fuites de mémoire pouvant éventuellement entraîner une crise de mémoire ou des erreurs d'arrondi qui ne se manifestent qu'au fil du temps).
- Utilisation des ressources de la base de données (échec de la fermeture des curseurs de la base de données dans certaines conditions, ce qui entraînerait éventuellement le blocage de l'ensemble du système).
- Cela peut également conduire à une dégradation des performances, c'est-à-dire garantir que le temps de réponse après une longue période d'activité soutenue soit aussi bon qu'il l'était au début du test.
- Défaut de fermer les connexions entre les niveaux d'un système à plusieurs niveaux dans certaines circonstances, ce qui pourrait bloquer certains ou tous les modules du système.
- La dégradation progressive du temps de réponse de certaines fonctions à mesure que les structures de données internes deviennent moins efficaces au cours d'un long test.
Comment ce test s'intègre à la famille des tests de performance
Les tests de performance constituent un terme générique. Les variantes décrites ci-dessous diffèrent uniquement par la forme de la charge appliquée et sa durée, ce qui explique la confusion fréquente entre elles.
| Type de test | Modèle de charge | Question à laquelle il répond |
|---|---|---|
| Test de charge | Charge de pointe prévue, courte durée | Le système atteint-il ses objectifs en conditions de trafic de pointe normales ? |
| Tests de résistance | Augmentation au-delà de la capacité jusqu'à la défaillance | Où se casse-t-il, et la défaillance est-elle gracieuse ? |
| Test de pointe | Montée en puissance extrême et soudaine, puis retrait | Peut-elle survivre et se remettre d'un choc de trafic ? |
| Essais d'endurance | La charge normale a été maintenue pendant de nombreuses heures. | Les performances se dégradent-elles avec le temps ? |
| Test de trempage | Charge soutenue sur une période prolongée | Y a-t-il des fuites de mémoire ou une saturation des ressources ? |
| Test de stabilité | Charge variable selon les conditions | Le système reste-t-il fiable lorsque les conditions changent ? |
| Tests de volume | Utilisateurs normaux, volume de données très important | Est-ce que le système peut gérer la croissance de la base de données ? |
Les tests d'endurance et les tests d'immersion sont souvent considérés comme synonymes. En pratique, on les appelle tests d'endurance : les deux consistent à supporter une charge soutenue pendant une longue période. Lorsque les équipes font la distinction, les tests d'endurance se concentrent sur l'évolution des temps de réponse, tandis que les tests de charge se concentrent sur la consommation de ressources telles que la mémoire, les descripteurs de fichiers et les pools de connexions. L'exécution d'un seul de ces tests permet généralement d'obtenir des résultats pour les deux.
Indicateurs clés à recueillir pendant le test
La qualité d'un test de performance dépend de la qualité des données enregistrées pendant son exécution. Capturez ces six éléments côté serveur et côté client, puis comparez-les à la valeur de référence plutôt qu'à votre intuition.
| Métrique | Ce que ça te dit | Panneau d'avertissement |
|---|---|---|
| Temps de réponse moyen | Expérience utilisateur typique | Toute dérive ascendante à travers la course |
| temps de réponse au 95e percentile | L'expérience des utilisateurs les plus lents | Bien au-dessus de la moyenne, ce qui signifie une incohérence |
| Cadence de production | Requêtes traitées par seconde | Chute alors que la charge reste constante |
| Taux d'erreur | Part des requêtes ayant échoué ou expiré | Toute augmentation au-delà du seuil convenu |
| Utilisation du processeur et de la mémoire | marge de ressources du serveur | Un souvenir qui s'élève et ne revient jamais. |
| Connexions et threads de base de données | épuisement de la piscine | Des comptes qui augmentent régulièrement sans libération |
Lisez la moyenne et le percentile ensemble. Une moyenne de 800 ms avec un 95e centile de 900 ms caractérise un système stable. La même moyenne, associée à un 95e centile de 9 secondes, signifie qu'un utilisateur sur vingt rencontre des difficultés, et que la moyenne masque ce problème.
Observez la forme, pas seulement la valeur. Dans tout test de longue durée, une ligne de ressource plate indique une réussite et une ligne montante indique une fuite, même si le nombre absolu reste largement dans la limite au moment où l'exécution se termine.
