Définir les critères d’échec et l’arrêt automatique

  • 5 minutes

Les critères d’échec vous permettent de définir des attentes en matière de performances et de qualité pour une application soumise à une charge. Le service Test de charge Azure prend en charge différentes métriques clientes pour la définition de critères d’échec, notamment 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é.

Dans cette unité, vous allez apprendre à définir des critères d’échec et des critères d’arrêt automatique pour des tests 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 un des critères de test prend la valeur true, le test de charge obtient l’état d’échec .

Vous pouvez définir des critères de test à deux niveaux. Un test de charge peut combiner des critères à différents niveaux.

  • Niveau de test de charge : Par exemple, pour vous assurer que le pourcentage d’erreur total ne dépasse pas un seuil.
  • Niveau de 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 au maximum 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 Descriptif
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.

Exemple de 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.

Les critères de test sont ajoutés dans le paramètre failureCriteria.

```yaml
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.

Capture d’écran de l’interface utilisateur JMeter, mettant en évidence le nom de la demande.

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 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 AutoStop JMeter est satisfait.

Arrêt automatique avec GitHub Actions

Pour configurer l’arrêt automatique d’un test de charge dans un workflow GitHub Actions, mettez à jour le fichier YAML de configuration de test de charge avec le paramètre autoStop et spécifiez 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 :

    ```yaml
    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 :

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