Configurer un test de charge dans YAML

Découvrez comment configurer votre test de charge dans Azure Load Testing à l’aide de YAML. Vous utilisez le fichier de configuration de test YAML pour créer et exécuter des tests de charge à partir de votre flux de travail d’intégration continue et de livraison continue (CI/CD).

Syntaxe YAML du test de charge

Une configuration de test de charge utilise les clés suivantes :

Clé	Catégorie	Obligatoire	Valeur par défaut	Descriptif
version	ficelle	O		Version de la spécification du test de charge. La seule valeur possible est v0.1.
testId	ficelle	O		Identificateur unique du test de charge. La valeur doit être comprise entre 2 et 50 caractères ([a-z0-9_-]). Pour un test existant, vous pouvez obtenir le testId depuis la page des détails du test dans le Portail Microsoft Azure.
testName	ficelle	N		Déconseillé. Identificateur unique du test de charge. Ce paramètre est remplacé par testId. Vous pouvez toujours exécuter des tests existants avec le champ testName.
displayName	ficelle	N		Nom d’affichage du test. Cette valeur est affichée dans la liste des tests du Portail Microsoft Azure. S’il n’est pas fourni, testId est utilisé comme nom d’affichage.
description	ficelle	N		Brève description du test. Le valeur est limitée à 100 caractères.
testType	ficelle	O		Type de test. Valeurs possibles : URL : Test de charge basé sur l’URL JMX : Test de charge basé sur JMeter Locust: test de charge basé sur locust
testPlan	ficelle	O		Référence au fichier du plan de test. Si testType: JMX : chemin relatif du script de test JMeter. Si testType: Locust: chemin relatif du script de test Locust. Si testType: URL: chemin relatif au fichier JSON des demandes.
engineInstances	entier	O		Nombre d’instances de moteurs de test parallèles pour l’exécution du plan de test. En savoir plus sur la configuration de la charge à grande échelle.
configurationFiles	tableau de chaînes	N		Liste des fichiers externes requis par le script de test. Par exemple, les fichiers de fragment JMX, les fichiers de données CSV, les images ou tout autre fichier de données. Test de charge Azure télécharge tous les fichiers dans le même dossier que le script de test. Dans le script JMeter ou le script Locust, reportez-vous uniquement aux fichiers externes à l’aide du nom de fichier et supprimez les informations de chemin d’accès de fichier.
failureCriteria	objet	N		Critères d’échec du test de charge. Pour plus d’informations, consultez failureCriteria .
autoStop	chaîne ou objet	N		Arrêter automatiquement le test de charge lorsque le pourcentage d’erreur dépasse une certaine valeur. Valeurs possibles : - disable : n’arrêtez pas automatiquement un test de charge. - objet : consultez la configuration autostop pour plus d’informations.
properties	objet	N		Si : références testType: JMXde fichier de propriété utilisateur JMeter. Si testType: Locust: références de fichier de configuration locust. Pour plus d’informations, consultez les propriétés .
zipArtifacts	tableau de chaînes	N		Spécifie la liste des fichiers d’artefacts zip. Pour les fichiers autres que le script de test principal et les propriétés utilisateur des tests JMeter et des fichiers de script locust et de configuration pour les tests locust, si la taille du fichier dépasse 50 Mo, compressez-les dans un fichier ZIP. Vérifiez à ce que la taille du fichier ZIP soit inférieure à 50 Mo. Seuls 5 artefacts ZIP sont autorisés avec un maximum de 1 000 fichiers dans chaque fichier et une taille non compressée de 1 Go. S’applique uniquement pour testType: JMX et testType: Locust.
splitAllCSVs	booléen	N	Faux	Répartissez uniformément les fichiers CSV d’entrée sur toutes les instances du moteur de test. Pour plus d’informations, consultez Lire un fichier CSV dans les tests de charge.
secrets	objet	N		Liste des secrets référencés par le script Apache JMeter ou Locust. Pour plus d’informations, consultez les secrets .
env	objet	N		Liste des variables d’environnement référencées par le script Apache JMeter ou locust. Pour plus d’informations, consultez les variables d’environnement.
certificates	objet	N		Liste des certificats clients pour l’authentification avec des points de terminaison d’application dans le script JMeter ou Locust. Pour plus d’informations, consultez les certificats .
appComponents	objet	N		Liste des ressources -side serveur à surveiller pendant le test de charge. Pour plus d’informations, consultez appComponents .
subnetId	ficelle	N		ID de ressource du sous-réseau du réseau virtuel pour tester les points de terminaison hébergés en privé. Ce sous-réseau héberge les machines virtuelles du moteur de test injecté. Pour plus d’informations, consultez comment charger des points de terminaison hébergés en privé.
publicIPDisabled	booléen	N		Désactiver le déploiement d'une adresse IP publique, d'un équilibreur de charge et d'un groupe de sécurité réseau tout en testant un point de terminaison privé. Pour plus d’informations, consultez comment charger des points de terminaison hébergés en privé.
regionalLoadTestConfig	objet	N		Répartir la charge entre les régions pour simuler le trafic utilisateur à partir de plusieurs régions. Pour plus d’informations, consultez la configuration du test de charge régional pour plus d’informations.
referenceIdentities	objet	N		Liste des identités managées utilisées dans le test pour accéder aux secrets à partir de votre coffre de clés Azure, des métriques pour les critères d’échec côté serveur et l’authentification de vos points de terminaison. Pour plus d’informations, consultez referenceIdentities .

Exemple de configuration de test de charge

L’extrait YAML suivant contient un exemple de configuration de test de charge.

version: v0.1
testId: SampleTest
displayName: Sample Test
description: Load test website home page
testPlan: SampleTest.jmx
testType: JMX
engineInstances: 1
subnetId: /subscriptions/abcdef01-2345-6789-0abc-def012345678/resourceGroups/sample-rg/providers/Microsoft.Network/virtualNetworks/load-testing-vnet/subnets/load-testing
configurationFiles:
  - 'sampledata.csv'
  - 'testfragment.jmx'
zipArtifacts:
   - bigdata.zip
splitAllCSVs: True
failureCriteria:
  - avg(response_time_ms) > 300
  - percentage(error) > 50
  - GetCustomerDetails: avg(latency) >200
autoStop:
  errorPercentage: 80
  timeWindow: 60
secrets:
  - name: my-secret
    value: https://akv-contoso.vault.azure.net/secrets/MySecret/abc1234567890def12345
keyVaultReferenceIdentity: /subscriptions/abcdef01-2345-6789-0abc-def012345678/resourceGroups/sample-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/sample-identity

Configuration failureCriteria

Les critères d’échec de test vous permettent de définir des conditions pour déterminer si une exécution de test de charge a réussi ou non. Si un ou plusieurs critères d’échec sont remplis, le test obtient un résultat de test ayant échoué. En savoir plus sur l’utilisation des critères d’échec de test de charge. Vous pouvez définir des critères d’échec sur les métriques clientes, telles que le temps de réponse, la latence, etc. et les métriques côté serveur pour vos composants d’application côté serveur.

Métriques du client

Vous pouvez définir des critères d’échec qui s’appliquent à l’ensemble du test de charge ou qui s’appliquent à une demande spécifique. 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 demandes spécifiques : Request: Aggregate_function (client_metric) condition threshold.

Le service Test de charge Azure prend en charge les métriques suivantes :

Mesure	Fonction d'agrégation	Seuil	État	Descriptif
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 à)	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.

Métriques côté serveur

Vous pouvez définir des critères d’échec sur les métriques côté serveur pour vos composants d’application côté serveur.

Le tableau suivant décrit les différents champs de la serverMetrics: configuration :

Paramètre	Descriptif
resourceId	Obligatoire. ID de ressource du composant d’application sur lequel les critères doivent être appliqués
metricNamespace	Obligatoire. Espace de noms de métrique côté serveur.
metricName	Obligatoire. Métriques côté serveur sur lesquelles les critères doivent être appliqués.
aggregation	Obligatoire. Agrégation à appliquer sur les métriques côté serveur.
condition	Optionnel. Opérateur de comparaison, tel que greater than ou less than.
value	Obligatoire. Valeur numérique à comparer à la métrique.

Exemple de configuration des critères d’échec

L’extrait de code suivant montre une configuration de test de charge, qui a trois critères d’échec de test de charge.

version: v0.1
testId: SampleTest
displayName: Sample Test
description: Load test website home page
testPlan: SampleTest.jmx
testType: JMX
engineInstances: 1
failureCriteria:
  clientMetrics:
    - avg(responseTimeMs) > 300
    - percentage(error) > 50
    - getCustomerDetails: avg(latency) > 200
  serverMetrics:
    - resourceId: /subscriptions/abcdef01-2345-6789-0abc-def012345678/resourceGroups/sample-rg/providers/Microsoft.Compute/virtualMachines/sample-vm
      metricNamespace: Microsoft.Compute/virtualMachines
      metricName: Percentage CPU
      aggregation: Average
      condition: GreaterThan
      value: 80
    - resourceId: /subscriptions/abcdef01-2345-6789-0abc-def012345678/resourceGroups/sample-rg/providers/Microsoft.Compute/virtualMachines/sample-vm
      metricNamespace: Microsoft.Compute/virtualMachines
      metricName: Available Memory
      aggregation: Average
      condition: LessThan
      value: 20

Configuration appComponents

Vous pouvez surveiller les ressources côté serveur pendant le test de charge. En savoir plus sur la surveillance des ressources côté serveur. Lorsque vous exécutez un test de charge pour une application hébergée par Azure, le Test de charge Azure collecte les indicateurs de ressources pour vos composants d’application et les présente dans le tableau de bord de test de charge.

Le tableau suivant décrit les différents champs de la appComponents: configuration :

Paramètre	Descriptif
resourceId	Obligatoire. ID de ressource du composant d’application sur lequel les critères doivent être appliqués.
resourceName	Optionnel. Nom de la ressource à surveiller.
kind	Optionnel. Type de ressource à surveiller.
metrics	Obligatoire. Liste des métriques à surveiller pour le composant d’application. Cela contient le nom, l’espace de noms et l’agrégation pour la métrique.

Exemple de configuration des composants d’application

L’extrait de code suivant montre une configuration de test de charge, qui a deux composants d’application.

version: v0.1
testId: SampleTest
displayName: Sample Test
description: Load test website home page
testPlan: SampleTest.jmx
testType: JMX
engineInstances: 1
appComponents:
  - resourceId: "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/samplerg/providers/microsoft.insights/components/appComponentResource"
    resourceName: appComponentResource #Optional
    kind: web # Optional
    metrics:
      - name: "requests/duration"
        namespace: microsoft.insights/components 
        aggregation: "Average"
      - name: "requests/count"
        aggregation: "Total"
        namespace: microsoft.insights/components   
  - resourceId: "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/samplerg/providers/microsoft.insights/components/appComponentResource"
    resourceName: appComponentResource #Optional
    kind: web # Optional
    metrics:
      - name: "requests/duration"
        aggregation: "Average"
        namespace: microsoft.insights/components
      - name: "requests/count"
        aggregation: "Total"
        namespace: microsoft.insights/components

Configuration autoStop

La fonctionnalité de démarrage automatique du test de charge vous permet d’arrêter automatiquement un test de charge lorsque le pourcentage d’erreur dépasse un seuil spécifique pendant une fenêtre de temps donnée. En savoir plus sur la fonctionnalité de démarrage automatique du test de charge.

Clé	Catégorie	Valeur par défaut	Descriptif
errorPercentage	entier	90	Seuil du pourcentage d’erreur, pendant le timeWindow. Si le pourcentage d’erreur dépasse ce pourcentage pendant une fenêtre de temps donnée, l’exécution du test s’arrête automatiquement.
timeWindow	entier	soixante	Fenêtre de temps en secondes pour calculer le errorPercentage.

Exemple de configuration autostop

L’extrait de code suivant montre une configuration de test de charge, qui a trois critères d’échec de test de charge.

version: v0.1
testId: SampleTest
displayName: Sample Test
description: Load test website home page
testPlan: SampleTest.jmx
testType: JMX
engineInstances: 1
autoStop:
  errorPercentage: 80
  timeWindow: 60

Configuration properties

Vous pouvez spécifier un fichier de propriétés utilisateur JMeter pour votre test de charge. Le fichier de propriétés utilisateur est chargé en même temps que le plan de test et d’autres fichiers. En savoir plus sur l’utilisation des propriétés utilisateur JMeter dans Azure Load Testing.

Clé	Catégorie	Valeur par défaut	Descriptif
userPropertyFile	ficelle		Fichier à utiliser en tant que fichier de propriétés utilisateur Apache JMeter ou fichier de configuration Locust. Pour Locust, les fichiers avec extensions .conf, .ini et .toml sont pris en charge en tant que fichier de configuration. Le fichier est chargé dans la ressource Test de charge Azure en même temps que le script de test et d’autres fichiers de configuration. Si le fichier se trouve dans un sous-dossier sur votre ordinateur local, utilisez un chemin d’accès relatif à l’emplacement du script de test.

Exemple de configuration de fichier de propriété utilisateur

L’extrait de code suivant montre une configuration de test de charge, qui spécifie un fichier de propriétés utilisateur.

version: v0.1
testId: SampleTest
displayName: Sample Test
description: Load test website home page
testPlan: SampleTest.jmx
testType: JMX
engineInstances: 1
properties:
  userPropertyFile: 'user.properties'

L’extrait de code suivant montre une configuration de test de charge, qui spécifie un fichier de configuration locust.

version: v0.1
testId: SampleTest
displayName: Sample Test
description: Load test website home page
testPlan: SampleTest.py
testType: Locust
engineInstances: 1
properties:
  userPropertyFile: 'locust.conf'

Configuration secrets

Vous pouvez stocker des valeurs secrètes dans Azure Key Vault et les référencer dans votre plan de test. En savoir plus sur l’utilisation des secrets avec Azure Load Testing.

Clé	Catégorie	Valeur par défaut	Descriptif
name	ficelle		Nom du secret. Ce nom doit correspondre au nom du secret que vous utilisez dans les demandes de plan de test.
value	ficelle		URI (identificateur secret) correspondant au secret Azure Key Vault.

Exemple de configuration des secrets

L’extrait de code suivant montre une configuration de test de charge, qui fait référence à un secret my-secret dans Azure Key Vault.

version: v0.1
testId: SampleTest
displayName: Sample Test
description: Load test website home page
testPlan: SampleTest.jmx
testType: JMX
engineInstances: 1
secrets:
  - name: my-secret
    value: https://akv-contoso.vault.azure.net/secrets/MySecret/abc1234567890def12345

Configuration env

Vous pouvez spécifier des variables d’environnement et les référencer dans votre plan de test. En savoir plus sur l’utilisation de variables d’environnement avec Azure Load Testing.

Clé	Catégorie	Valeur par défaut	Descriptif
name	ficelle		Nom de la variable d’environnement. Ce nom doit correspondre au nom de variable que vous utilisez dans les demandes de plan de test.
value	ficelle		Valeur de la variable d’environnement.

Exemple de configuration de variable d’environnement

L’extrait de code suivant montre une configuration de test de charge, qui spécifie une variable my-variable d’environnement et une valeur my-value.

version: v0.1
testId: SampleTest
displayName: Sample Test
description: Load test website home page
testPlan: SampleTest.jmx
testType: JMX
engineInstances: 1
env:
  - name: my-variable
    value: my-value

Configuration certificates

Vous pouvez passer des certificats clients à votre test de charge. Le certificat est stocké dans Azure Key Vault. En savoir plus sur l’utilisation de certificats clients avec Azure Load Testing.

Clé	Catégorie	Valeur par défaut	Descriptif
name	ficelle		Nom du certificat.
value	ficelle		URI (identificateur secret) du certificat dans Azure Key Vault.

Exemple de configuration de certificat

L’extrait de code suivant montre une configuration de test de charge, qui fait référence à un certificat client dans Azure Key Vault.

version: v0.1
testId: SampleTest
displayName: Sample Test
description: Load test website home page
testPlan: SampleTest.jmx
testType: JMX
engineInstances: 1
certificates:
  - name: my-certificate
    value: https://akv-contoso.vault.azure.net/certificates/MyCertificate/abc1234567890def12345

Configuration referenceIdentities

Vous pouvez utiliser des identités managées pour différents scénarios dans votre test de charge. Les identités managées peuvent être utilisées dans le test pour accéder aux secrets ou certificats à partir de votre coffre de clés Azure, extraire des métriques pour les critères d’échec côté serveur et l’authentification de vos points de terminaison.

Le tableau suivant décrit les différents champs de la referenceIdentities: configuration :

Paramètre	Descriptif
kind	Obligatoire. Cela définit le scénario pour lequel l’identité managée est utilisée. Il peut s’agir de l’un des éléments suivants KeyVault, Metricsou Engine. Il peut y avoir plusieurs éléments pour le type Engine.
type	Obligatoire. Type d’identité. Cela peut être UserAssigned ou SystemAssigned.
value	Obligatoire. ID de ressource de l’identité managée. Cela n’a pas besoin d’être fourni si le type est SystemAssigned.

Exemple de configuration des identités de référence

L’extrait de code suivant montre une configuration de test de charge pour plusieurs identités.

version: v0.1
testId: SampleTest
displayName: Sample Test
description: Load test website home page
testPlan: SampleTest.jmx
testType: JMX
engineInstances: 1
secrets:
  - name: my-secret
    value: https://akv-contoso.vault.azure.net/secrets/MySecret/abc1234567890def12345
failureCriteria:
  serverMetrics:
    - resourceId: /subscriptions/abcdef01-2345-6789-0abc-def012345678/resourceGroups/sample-rg/providers/Microsoft.Compute/virtualMachines/sample-vm
      metricNamespace: Microsoft.Compute/virtualMachines
      metricName: Percentage CPU
      aggregation: Average
      condition: GreaterThan
      value: 80
referenceIdentities:
  - kind: KeyVault
    type: UserAssigned
    value: /subscriptions/abcdef01-2345-6789-0abc-def012345678/resourceGroups/sample-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/sample-identity
  - kind: Metrics
    type: SystemAssigned
  - kind: Engine
    type: UserAssigned
    value: /subscriptions/abcdef01-2345-6789-0abc-def012345678/resourceGroups/sample-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/sample-identity
  - kind: Engine
    type: UserAssigned
    value: /subscriptions/abcdef01-2345-6789-0abc-def012345678/resourceGroups/sample-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/sample-identity1

Demande un fichier JSON

Si vous utilisez un test basé sur une URL, vous pouvez spécifier les requêtes HTTP dans un fichier JSON au lieu d’utiliser un script de test. Veillez à définir la testType valeur URL dans le fichier YAML de configuration de test et référencez le fichier JSON des demandes.

Des requêtes HTTP

Le fichier JSON des requêtes utilise les propriétés suivantes pour définir les requêtes dans la requests propriété :

Propriété	Catégorie	Descriptif
requestName	ficelle	Nom de la demande unique. Vous pouvez référencer le nom de la demande lorsque vous configurez des critères d’échec de test.
responseVariables	tableau	Liste des variables de réponse. Utilisez des variables de réponse pour extraire une valeur de la requête et la référencer dans une requête ultérieure. En savoir plus sur les variables de réponse.
responseVariables.extractorType	ficelle	Mécanisme permettant d’extraire une valeur de la sortie de la réponse. Les valeurs prises en charge sont XPathExtractor, JSONExtractor et RegularExpression.
responseVariables.expression	ficelle	Expression pour récupérer la sortie de la réponse. L’expression dépend de la valeur de type extracteur.
responseVariables.variableName	ficelle	Nom de variable de réponse unique. Vous pouvez référencer cette variable dans une requête suivante à l’aide de la {$variable-name} syntaxe.
queryParameters	tableau	Liste des paramètres de chaîne de requête à passer au point de terminaison.
queryParameters.key	ficelle	Nom du paramètre de chaîne de requête.
queryParameters.value	ficelle	Valeur du paramètre de chaîne de requête.
requestType	ficelle	Type de requête. Les valeurs prises en charge sont : URL ou CURL.
endpoint	ficelle	URL du point de terminaison d’application à tester.
headers	tableau	Liste des en-têtes HTTP à transmettre au point de terminaison de l’application. Spécifiez une paire clé-valeur pour chaque en-tête.
body	ficelle	Texte du corps de la requête HTTP. Vous pouvez utiliser la requestBodyFormat méthode pour spécifier le format du contenu du corps.
requestBodyFormat	ficelle	Format du contenu du corps. Les valeurs prises en charge sont Text, JSON, JavaScript, HTML et XML.
method	ficelle	Méthode HTTP pour appeler le point de terminaison. Les valeurs prises en charge sont les suivantes : GET, , POSTPUT, DELETEPATCH, , HEADet OPTIONS.
curlCommand	ficelle	Commande cURL à exécuter. Exige que l’objet requestType est CURL.

L’extrait de code JSON suivant contient un exemple de fichier JSON :

{
    "version": "1.0",
    "scenarios": {
        "requestGroup1": {
            "requests": [
                {
                    "requestName": "add",
                    "responseVariables": [],
                    "queryParameters": [
                        {
                            "key": "param1",
                            "value": "value1"
                        }
                    ],
                    "requestType": "URL",
                    "endpoint": "https://www.contoso.com/orders",
                    "headers": {
                        "api-token": "my-token"
                    },
                    "body": "{\r\n  \"customer\": \"Contoso\",\r\n  \"items\": {\r\n\t  \"product_id\": 321,\r\n\t  \"count\": 50,\r\n\t  \"amount\": 245.95\r\n  }\r\n}",
                    "method": "POST",
                    "requestBodyFormat": "JSON"
                },
                {
                    "requestName": "get",
                    "responseVariables": [],
                    "requestType": "CURL",
                    "curlCommand": "curl --request GET 'https://www.contoso.com/orders'"
                },
            ],
            "csvDataSetConfigList": []
        }
    },
    "testSetup": [
        {
            "virtualUsersPerEngine": 1,
            "durationInSeconds": 600,
            "loadType": "Linear",
            "scenario": "requestGroup1",
            "rampUpTimeInSeconds": 30
        }
    ]
}

Configuration de chargement

Le fichier JSON de requêtes utilise les propriétés suivantes pour définir la configuration de charge dans la testSetup propriété :

Propriété	Catégorie	Type de charge	Descriptif
loadType	ficelle		Type de modèle de charge. Les valeurs prises en charge sont linear, step et spike.
scenario	ficelle		Référence au groupe de requêtes, spécifiée dans la scenarios propriété.
virtualUsersPerEngine	entier	Tous	Nombre d’utilisateurs virtuels par instance de moteur de test.
durationInSeconds	entier	Tous	Durée totale du test de charge en secondes.
rampUpTimeInSeconds	entier	Linéaire, étape	Durée en secondes pour augmenter le nombre cible d’utilisateurs virtuels.
rampUpSteps	entier	Étape	Nombre d’étapes à suivre pour atteindre le nombre cible d’utilisateurs virtuels.
spikeMultiplier	entier	Pic	Facteur de multiplication du nombre d’utilisateurs cibles avec pendant la durée de pic.
spikeHoldTimeInSeconds	entier	Pic	Durée totale en secondes pour maintenir la charge de pic.

Configuration du test de charge régional

Vous pouvez répartir la charge entre les régions pour mieux simuler des modèles de trafic réels. Vous pouvez spécifier les régions à partir de lesquelles vous souhaitez générer la charge et la quantité de charge que vous souhaitez simuler à partir de chaque région. Pour ce faire, spécifiez le nom de la région et le nombre d’instances de moteur souhaitées dans cette région. En savoir plus sur la génération de la charge à partir de plusieurs régions.

Clé	Catégorie	Valeur par défaut	Descriptif
region	ficelle		Nom de la région Azure.
engineInstances	entier		Nombre d’instances de moteur pour cette région Azure.

Exemple de configuration de test de charge régional

L’extrait de code suivant montre une configuration de test de charge, qui spécifie deux régions eastus Azure et eastasia le nombre d’instances de moteur pour chaque région.

displayName: Sample Test
testPlan: sampleScript.jmx
description: 'Load test website home page'
engineInstances: 4
testId: SampleTest
testType: Locust
splitAllCSVs: False
regionalLoadTestConfig:
- region: eastus
  engineInstances: 2
- region: eastasia
  engineInstances: 2
failureCriteria:
- p90(response_time_ms) > 10000
autoStop:
  errorPercentage: 90
  timeWindow: 60

Contenu connexe

• Découvrez comment créer des tests de régression automatisés dans votre flux de travail CI/CD.
• Découvrez comment paramétriser des tests de charge configurables avec des secrets et des variables d’environnement.
• Découvrez comment effectuer un test de charge des points de terminaison sécurisés.