Définir des critères d’échec de test de charge à l’aide du service Test de charge Azure

Cet article explique comment définir des critères d’échec ou des critères d’arrêt automatique pour vos tests de charge avec le service Test de charge Azure. 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 client et serveur pour définir des critères d’échec, tels que le taux d’erreur ou le pourcentage d’UC pour une ressource Azure. 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, 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 au maximum 50 critères de test pour un test de charge. S’il existe plusieurs critères pour la même métrique, le critère utilisé est celui dont la valeur de seuil est la plus basse.

Structure des critères d’échec pour les métriques du client

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.

Pour les métriques côté client, 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. La structure des critères est la suivante : Aggregate_function (client_metric) condition threshold.
• Au niveau de la requête JMeter (échantillonneur JMeter). Par exemple, vous pouvez spécifier un seuil de temps de réponse pour la requête getProducts, mais ignorer le temps de réponse pour la requête de connexion. La structure des critères est la suivante : 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 pas de données personnelles dans le nom de l’échantillonneur dans votre script JMeter. Les noms des échantillonneurs apparaissent dans le tableau de bord des résultats de 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 (percentile), xx peut être 50, 75, 90, 95, 96, 97, 98, 99, 999 et 9999	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 pour les métriques du client

Azure portal

Dans cette section, vous configurez des critères de test pour les métriques du client pour un test de charge dans le portail Azure.

1. Dans le Portail Azure, accédez à votre ressource de test de charge Azure.

2. Dans le volet gauche, sélectionnez Tests pour afficher la liste des tests de charge.

3. Sélectionnez votre test de charge dans la liste, puis sélectionnez Modifier.

   

4. 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.

   

5. 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.

6. 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 global du test est défini sur Échec si au moins un critère est rempli.

   

Azure Pipelines / GitHub Actions

Dans cette section, vous allez configurer des critères de test pour une métrique du client pour un test de charge, dans le cadre d’un workflow CI/CD. Découvrez comment configurer des tests de performances automatisés avec CI/CD.

Pour les workflows CI/CD, vous configurez les paramètres de test de charge dans un fichier de configuration de test YAML. Vous stockez le fichier de configuration du test de charge en même temps que le fichier de script de test JMeter dans le référentiel de contrôle de code source.

Pour spécifier des critères d’échec dans le fichier de configuration YAML :

1. Ouvrez le fichier de configuration de test YAML pour votre test de charge dans l’éditeur de votre choix.

2. Ajoutez vos critères de test dans le paramètre failureCriteria.

   Utilisez le format de critères d’échec, comme décrit précédemment. Vous pouvez ajouter plusieurs critères d’échec pour un test de charge.

   L’exemple suivant définit trois critères d’échec. Les deux premiers critères s’appliquent au test de charge global, et le dernier spécifie une condition pour la demande GetCustomerDetails.

   version: v0.1
   testId: SampleTestCICD
   displayName: Sample test from CI/CD
   testPlan: SampleTest.jmx
   description: Load test website home page
   engineInstances: 1
   failureCriteria:
     - avg(response_time_ms) > 300
     - percentage(error) > 50
     - GetCustomerDetails: avg(latency) >200
   

   Lorsque vous définissez un critère de test pour une demande JMeter spécifique, le nom de la demande doit correspondre au nom de l’échantillonneur JMeter dans le fichier JMX.

   

3. Enregistrez le fichier de configuration YAML et validez les modifications dans le contrôle de code source.

4. Une fois le workflow CI/CD exécuté, vérifiez l’état du test dans le journal CI/CD.

   Le journal affiche l’état global du test et l’état de chacun des critères de test. L’état de l’exécution du workflow CI/CD reflète également l’état de l’exécution du test.

   

Accéder au composant d’application pour les critères de test sur les métriques du serveur

Lorsque vous définissez des critères d’échec sur une métrique dans votre composant d’application, votre ressource de test de charge utilise une identité managée pour accéder à ce composant. Une fois l’identité managée configurée, vous devez accorder à l’identité managée de votre ressource de test de charge l’autorisation de lire ces valeurs à partir du composant de l’application.

Pour accorder à votre ressource de test de charge Azure les autorisations de lecture des métriques à partir de votre composant d’application :

1. Dans le portail Azure, accédez à votre composant d’application.

2. Dans le volet de gauche, sélectionnez Contrôle d’accès (IAM), puis sélectionnez +Ajouter et finalement Ajouter une attribution de rôle.

   

3. Sous l’onglet Rôle, sous Rôles de fonctions de travail, recherchez Lecteur de surveillance ou Contributeur de surveillance.

4. Sous l’onglet Membres, sous Affecter l’accès à, sélectionnez Identité managée.

5. Cliquez sur Sélectionner des membres, recherchez et sélectionnez l’identité managée de la ressource de test de charge, puis sélectionnez Suivant. Si vous utilisez une identité managée affectée par le système, le nom de l’identité managée correspond à celui de votre ressource de test de charge Azure.

6. Sélectionnez Vérifier + affecter l’identité à l’autorisation.

   

Lorsque votre test s’exécute, l’identité managée associée à votre ressource de test de charge peut désormais lire les métriques de votre test de charge à partir de votre composant d’application.

Définir des critères d’échec de test de charge pour les métriques de serveur

Important

Azure Load Testing ne prend pas en charge la configuration des critères d’échec sur les métriques côté serveur à partir d’Azure Pipelines/Github Actions.

Dans cette section, vous allez configurer des critères d’échec de test sur les métriques côté serveur pour un test de charge dans le portail Azure.

1. Dans le Portail Azure, accédez à votre ressource de test de charge Azure.

2. Sélectionnez Créer un test.

3. Sous l’onglet Surveillance, configurez les composants d’application que vous souhaitez surveiller pendant le test.

4. Configurez l’identité de référence métriques. Cette identité peut correspondre l’identité affectée par le système de la ressource de test de charge ou à l’une des identités affectées par l’utilisateur. Veillez à utiliser la même identité que celle à laquelle vous avez accordée l’accès précédemment.

   

5. Dans le volet Critères de test, renseignez l’ID de ressource, l’espace de noms, la métrique, l’agrégation, la condition, les valeurs de seuil pour votre test. Vous pouvez définir des critères d’échec uniquement pour les ressources/composants d’application que vous surveillez pendant le test.

   

6. 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.

7. 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 global du test est défini sur Échec si au moins un critère est rempli.

   

Configuration d’arrêt automatique

Le service Test de charge Azure arrête automatiquement un test de charge si le pourcentage d’erreur dépasse un seuil donné pendant 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 service Test de charge Azure arrête automatiquement un test de charge avec un pourcentage d’erreur d’au moins 90 % au cours d’une fenêtre de temps de 60 secondes.

Vous pouvez utiliser la fonctionnalité d’arrêt automatique du service Test de charge Azure 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 AutoStop JMeter 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.

Azure portal

Pour configurer l’arrêt automatique de votre test de charge dans le portail Azure :

1. Dans le Portail Azure, accédez à votre ressource de test de charge Azure.

2. Dans le volet gauche, sélectionnez Tests pour afficher la liste des tests de charge.

3. Sélectionnez votre test de charge dans la liste, puis sélectionnez Modifier. Vous pouvez également sélectionner Créer>Charger un script JMeter pour créer un test.

4. 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 de temps. Spécifiez la fenêtre de temps en secondes.

     

5. Sélectionnez Appliquer ou Vérifier + créer si vous créez un test de charge, pour enregistrer les modifications.

Azure Pipelines / GitHub Actions

Pour configurer l’arrêt automatique de votre test de charge dans un flux de travail CI/CD, vous mettez à jour le fichier YAML de configuration du test de charge.

Pour spécifier les paramètres d’arrêt automatique dans le fichier de configuration YAML :

1. Ouvrez le fichier de configuration de test YAML pour votre test de charge dans l’éditeur de votre choix.

   • Pour activer l’arrêt automatique, ajoutez le paramètre autoStop et spécifiez les errorPercentage et timeWindow.

     L’exemple suivant arrête automatiquement le test de charge lorsque le pourcentage d’erreur dépasse 80 % durant une fenêtre de temps de 2 minutes :

     version: v0.1
     testId: SampleTestCICD
     displayName: Sample test from CI/CD
     testPlan: SampleTest.jmx
     description: Load test website home page
     engineInstances: 1
     autoStop:
       errorPercentage: 80
       timeWindow: 120
     

   • Pour désactiver l’arrêt automatique, ajoutez autoStop: disable au fichier de configuration.

     L’exemple suivant désactive l’arrêt automatique pour votre test de charge :

     version: v0.1
     testId: SampleTestCICD
     displayName: Sample test from CI/CD
     testPlan: SampleTest.jmx
     description: Load test website home page
     engineInstances: 1
     autoStop: disable
     

2. Enregistrez le fichier de configuration YAML et validez les modifications dans le contrôle de code source.

Découvrez comment configurer des tests de performances automatisés avec CI/CD.

É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.