LoadView Goal-Based Load Test est un outil de test intelligent qui permet de tester par rapport à un nombre cible de transactions, en ajustant automatiquement tous les paramètres de test nécessaires, tels que la charge de l’utilisateur et la durée du test.

Si vous utilisez un nombre simultané d’utilisateurs ou de visiteurs lors de la configuration du test de charge, envisagez d’utiliser la courbe d’étape de charge comme type de charge.

Dans LoadView, une transaction représente un script de test (exemple de test) qui peut inclure une ou plusieurs actions de l’utilisateur, telles que l’accès à une page Contactez-nous, le remplissage d’un formulaire et l’envoi. L’objectif de transaction représente le nombre de ces transactions que votre site peut traiter par minute.

L’algorithme de test expliqué

Pour atteindre le nombre souhaité de transactions par minute et tenir compte des fluctuations potentielles des performances du serveur et de l’application cible, LoadView exécute un test en plusieurs cycles. Ce processus itératif se poursuit jusqu’à ce que la durée de test prédéterminée soit écoulée.

Au cours de chaque cycle, le système effectue les étapes suivantes.

1. Démarrez le calcul de la charge utilisateur (uniquement dans le premier cycle)

Pour correspondre à l’objectif de transaction spécifié, le nombre initial d’utilisateurs simultanés est calculé en fonction de l’objectif de transaction défini et du temps de réponse mesuré pour la série de tests monoposte exécutée lors de la validation du test :

Charge utilisateur de démarrage = objectif de transaction par minute × durée de la réponse de validation

La validation des tests est cruciale pour les tests de charge basés sur des objectifs. Assurez-vous que la cible de test a réussi la validation avant de configurer votre courbe basée sur les objectifs.

2. Génération de charge

Le système génère une charge d’utilisateur virtuel en fonction des calculs.

3. Évaluation du nombre de transactions réalisées par minute par rapport à l’objectif de transaction

À la fin du premier cycle de test, le système calcule le nombre réel de transactions par minute pour le cycle. Ensuite, le système vérifie si le nombre généré d’utilisateurs virtuels simultanés correspond à l’objectif de transaction souhaité, compte tenu de la durée moyenne de réponse dans le cycle en cours (durée moyenne de réponse).

Si ce nombre ne correspond pas à l’objectif de transaction souhaité, la charge d’utilisateurs pour le cycle suivant est ajustée à l’aide de la formule suivante :

Charge utilisateur = objectif de transaction par minute × Avg. Durée de la réponse

Lorsque l’ Avg. Durée de la réponse est calculé comme le temps de réponse moyen mesuré pour le cycle en cours. Pour garantir la précision, le script de test est exécuté plusieurs fois au cours de chaque cycle, le nombre d’exécutions étant défini par le paramètre de test Taux d’ajustement .

Exemple concret

Pour expliquer comment cela fonctionne dans la vie réelle, examinons le rapport ci-dessous où l’objectif de transaction est défini sur 2 000 transactions par minute (TPM) et la durée de réponse de validation de 0,18 seconde.

La charge utilisateur de départ recommandée pour le premier cycle est calculée comme suit :

Démarrer la charge de l’utilisateur = 2000 TPM × 0,18 s = 377 utilisateurs virtuels simultanés.

Premier cycle : Évaluation initiale

Au cours du premier cycle de test, LoadView a atteint 1 176 TPM, ce qui n’est pas le cas de l’objectif de 2 000 TPM. Le temps de réponse moyen (durée moyenne de réponse) enregistré était de 19,39 secondes. Sur la base de ces données, le système recalcule la charge utilisateur requise pour le cycle suivant à l’aide de la formule :

Charge utilisateur₂ = (2 000 / 60) × 19,39 ≈ 646 utilisateurs virtuels simultanés

Deuxième cycle : Ajustement de la charge utilisateur

Au cours du deuxième cycle, la charge utilisateur est passée à 646 utilisateurs virtuels simultanés. Cependant, le temps de réponse du serveur cible a commencé à augmenter (comme indiqué par la première flèche sur le graphique Temps de réponse). Cette augmentation a entraîné une augmentation de la durée moyenne de réponse de 32,39 secondes.

Malgré l’augmentation de la charge utilisateur, le système n’a atteint que 1 176 TPM. Cela indique que le taux de transaction ne s’est pas amélioré avec la charge supplémentaire.

Troisième et quatrième cycles : autres ajustements et observations

LoadView a recalculé la charge utilisateur pour le troisième cycle :

Charge utilisateur₃ = (2 000 / 60) × 32,39 ≈ 1 079 utilisateurs virtuels simultanés

Au cours du troisième cycle, le temps de réponse a continué à croître proportionnellement à l’augmentation de la charge des utilisateurs. Au cours du quatrième cycle, le temps de réponse du serveur a continué d’augmenter avec la charge des utilisateurs, suivant les tendances observées lors des cycles précédents. Ce modèle suggère que les performances du serveur se dégradaient à mesure que d’autres utilisateurs étaient ajoutés, empêchant LoadView d’atteindre l’objectif de transaction souhaité.

Cet exemple montre qu’une augmentation significative du temps de réponse, même avec une charge utilisateur plus élevée, peut indiquer des problèmes de performances de serveur ou d’application qui doivent être résolus pour atteindre l’objectif de transaction souhaité.

Résultats potentiels d’un test basé sur les objectifs

Lors de l’exécution d’un test de charge basé sur un objectif dans LoadView, deux résultats clés sont possibles.

Réalisation réussie de l’objectif
DébitDans LoadView, un test de charge basé sur un objectif est considéré comme réussi lorsque le système atteint ou s’approche de l’objectif de transaction spécifié. En raison des fluctuations naturelles des performances du serveur cible et du temps de réponse lors de l’exécution du test, le nombre exact de transactions réalisées par minute peut différer légèrement de l’objectif défini. Des écarts mineurs sont attendus car la charge de l’utilisateur est ajustée dynamiquement sur la base de mesures de réponse en temps réel. Tant que le débit atteint reste dans une plage acceptable de la valeur cible, le test est considéré comme un succès

Échec de l’atteinte de l’objectif
Si le test basé sur l’objectif n’atteint pas le débit spécifié, il signale généralement des problèmes de performances dans l’environnement cible. Les raisons courantes sont les suivantes :

  • Une augmentation proportionnelle des temps de réponse du serveur à mesure que la charge des utilisateurs augmente.
  • Erreurs côté serveur qui perturbent le traitement normal des transactions.

Dans de tels cas, malgré l’application d’une charge utilisateur supplémentaire, le nombre de transactions réussies par minute reste inférieur à l’objectif souhaité, ce qui met en évidence les goulets d’étranglement potentiels ou les limitations du système qui nécessitent une optimisation supplémentaire. Pour plus de détails, veuillez consulter notre article sur le dépannage des tests de charge basés sur les objectifs .