Définir des critères d’échec pour les tests de charge à l’aide d’Azure Load Testing
Dans cet article, vous allez apprendre à définir des critères d’échec ou des critères d’arrêt automatique pour vos tests de charge avec Azure Load Testing. Les critères d’échec vous permettent de définir des attentes en matière de performances et de qualité pour votre application en charge. Azure Load Testing prend en charge différentes métriques clientes pour définir des critères d’échec, tels que le taux d’erreur ou le temps de réponse. Les critères d’arrêt automatique vous permettent d’arrêter automatiquement votre test de charge lorsque le taux d’erreur dépasse un seuil donné.
Prérequis
- Compte Azure avec un abonnement actif. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
- Une ressource de test de charge Azure. Si vous avez besoin de créer une ressource de test de charge Azure, consultez le guide de démarrage rapide Créer et exécuter un test de charge.
Critères d’échec du test de charge
Les critères d’échec du test de charge sont des conditions pour les métriques côté client, que votre test doit respecter. Vous définissez des critères de test au niveau du test de charge dans le service Test de charge Azure. Un test de charge peut avoir un ou plusieurs critères de test. Quand au moins l’un des critères de test prend la valeur true, le test de charge obtient l’état Échec.
Vous pouvez définir des critères de test à deux niveaux. Un test de charge peut combiner des critères à différents niveaux.
- Au niveau du test de charge. Par exemple, pour vous assurer que le pourcentage total d’erreurs ne dépasse pas un seuil.
- Au niveau de la requête JMeter (échantillonneur JMeter). Par exemple, vous pouvez spécifier un seuil de temps de réponse de la demande getProducts , mais ignorer l’heure de réponse de la demande de connexion .
Vous pouvez définir un maximum de 50 critères de test pour un test de charge. S’il existe plusieurs critères pour la même métrique client, le critère utilisé est celui dont la valeur de seuil est la plus basse.
Structure des critères d’échec
Le format des critères d’échec dans le service Test de charge Azure suit celui d’une instruction conditionnelle pour une métrique prise en charge. Par exemple, assurez-vous que le nombre moyen de demandes par seconde est supérieur à 500.
Les critères d’échec ont la structure suivante :
- Critères de test au niveau du test de charge :
Aggregate_function (client_metric) condition threshold
. - Critères de test appliqués à des requêtes JMeter spécifiques :
Request: Aggregate_function (client_metric) condition threshold
.
Le tableau suivant décrit les différents composant mis à jour :
Paramètre | Description |
---|---|
Client metric |
Obligatoire. Métrique client à laquelle la condition doit être appliquée. |
Aggregate function |
Obligatoire. Fonction d’agrégation à appliquer à la métrique client. |
Condition |
Obligatoire. Opérateur de comparaison, tel que greater than ou less than . |
Threshold |
Obligatoire. Valeur numérique à comparer à la métrique client. |
Request |
facultatif. Nom de l’échantillonneur dans le script JMeter auquel le critère s’applique. Si vous ne spécifiez pas de nom de requête, le critère s’applique à l’agrégation de toutes les demandes dans le script. N’incluez aucune donnée personnelle dans le nom de l’échantillonneur dans votre script JMeter. Les noms de l’échantillonneur apparaissent dans le tableau de bord des résultats du test de charge Azure. |
Métriques client prises en charge pour les critères d’échec
Le service Test de charge Azure prend en charge les métriques suivantes :
Mesure | Fonction d'agrégation | Seuil | Condition | Description |
---|---|---|---|---|
response_time_ms |
avg (moyenne)min (minimum)max (maximum)pxx (centile), xx peut être 50, 90, 95, 99 |
Valeur entière représentant un nombre de millisecondes (ms). | > (supérieur à)< (inférieur à) |
Temps de réponse ou temps écoulé, en millisecondes. Pour plus d’informations sur le temps écoulé, consultez la documentation Apache JMeter. |
latency |
avg (moyenne)min (minimum)max (maximum)pxx (centile), xx peut être 50, 90, 95, 99 |
Valeur entière représentant un nombre de millisecondes (ms). | > (supérieur à)< (inférieur à) |
Latence, en millisecondes. Pour plus d’informations sur la latence, consultez la documentation Apache JMeter. |
error |
percentage |
Valeurs numériques comprises dans une plage allant de 0 à 100 et représentant un pourcentage. | > (supérieur(e) à) |
Pourcentage de demandes ayant échoué. |
requests_per_sec |
avg (moyenne) |
Valeur numérique avec jusqu’à deux décimales. | > (supérieur à) < (inférieur à) |
Nombre de demandes par seconde. |
requests |
count |
Valeur de type entier. | > (supérieur à) < (inférieur à) |
Nombre total de requêtes. |
Définir des critères d’échec de test de charge
Dans cette section, vous configurez des critères de test pour un test de charge dans le portail Azure.
Dans le Portail Azure, accédez à votre ressource de test de charge Azure.
Dans le volet gauche, sélectionnez Tests pour afficher la liste des tests de charge.
Sélectionnez votre test de charge dans la liste, puis sélectionnez Modifier.
Dans le volet Critères de test, renseignez les valeurs Métrique, Fonction d’agrégation, Condition et Seuil pour votre test.
Si vous le souhaitez, entrez les informations dans Nom de la demande pour ajouter un critère de test pour une demande JMeter spécifique. La valeur doit correspondre au nom de l’échantillonneur JMeter dans le fichier JMX.
Cliquez sur Appliquer pour enregistrer les modifications.
Lorsque vous exécutez maintenant le test de charge, le service Test de charge Azure utilise les critères de test pour déterminer l’état de l’exécution de test de charge.
Exécutez le test et affichez l’état dans le tableau de bord de test de charge.
Le tableau de bord affiche chacun des critères de test et leur état. L’état de test global a échoué si au moins un critère a été respecté.
Configuration d’arrêt automatique
Le test de charge Azure arrête automatiquement un test de charge si le pourcentage d’erreur dépasse un seuil donné pour une certaine fenêtre de temps. L'arrêt automatique vous évite des échecs de tests occasionnant des coûts supplémentaires, par exemple, à cause d'une URL de point de terminaison mal configurée.
Dans la configuration du test de charge, vous pouvez activer ou désactiver la fonctionnalité d’arrêt automatique et configurer le seuil de pourcentage d’erreur et la fenêtre de temps. Par défaut, Le test de charge Azure arrête automatiquement un test de charge dont le pourcentage d’erreur est d’au moins 90 % pendant toute fenêtre de temps de 60 secondes.
Vous pouvez utiliser la fonctionnalité d’arrêt automatique azure Load Testing en combinaison avec un écouteur AutoStop dans votre script JMeter. Le test de charge s’arrête automatiquement quand l’un des critères de la configuration d’arrêt automatique ou de l’écouteur JMeter AutoStop est satisfait.
Attention
Si vous désactivez l’arrêt automatique pour votre test de charge, vous risquez d’entraîner des coûts même lorsque votre test de charge est configuré de manière incorrecte.
Pour configurer l’arrêt automatique pour votre test de charge dans le Portail Azure :
Dans le Portail Azure, accédez à votre ressource de test de charge Azure.
Dans le volet gauche, sélectionnez Tests pour afficher la liste des tests de charge.
Sélectionnez votre test de charge dans la liste, puis sélectionnez Modifier. Vous pouvez également sélectionner Créer>un script JMeter pour créer un test.
Accédez à l’onglet Critères de test pour configurer la fonctionnalité d’arrêt automatique.
Activez ou désactivez automatiquement l’arrêt du test de charge à l’aide du contrôle de test d’arrêt automatique.
Si vous activez l’arrêt automatique, vous pouvez remplir les champs Pourcentage d’erreur et Fenêtre Heure. Spécifiez la fenêtre de temps en secondes.
Sélectionnez Appliquer ou Vérifier + créer si vous créez un test de charge pour enregistrer les modifications.
Étapes suivantes
Pour en savoir plus sur le paramétrage d’un test de charge à l’aide de secrets, consultez Paramétrer un test de charge.
Pour en savoir plus sur l’automatisation des tests de performance, consultez Configurer des tests de performance automatisés.
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour