YAML でのロードテストを構成する

2025-05-11

YAML を使用して Azure Load Testing でロードテストを構成する方法について説明します。テスト構成 YAML ファイルを使用して、継続的インテグレーションと継続的デリバリー (CI/CD) ワークフローからロードテストを作成して実行します。

ロードテストの YAML 構文

ロードテストの構成では、次のキーを使います。

キー	タイプ	必須	規定値	説明
`version`	ひも	年		ロードテスト仕様のバージョン。値 `v0.1` のみがサポートされています。
`testId`	ひも	年		ロードテストの一意識別子。値は、2 から 50 文字にする必要があります ([a-z0-9_-])。既存のテストの場合は、Azure portal のテストの詳細ページから `testId` を取得できます。
`testName`	ひも	N		削除されました。ロードテストの一意識別子。この設定は、 `testId`に置き換えられます。 `testName` フィールドを使って既存のテストを実行することもできます。
`displayName`	ひも	N		テストの表示名。この値は、Azure portal のテストの一覧で示されます。指定しないと、`testId` が表示名として使われます。
`description`	ひも	N		テストの簡単な説明。値の最大長は 100 文字です。
`testType`	ひも	年		テストの種類。指定できる値 `URL`: URL ベースのロードテスト `JMX`: JMeter ベースのロードテスト `Locust`:ローカストベースロードテスト
`testPlan`	ひも	年		テスト計画ファイルへの参照。 `testType: JMX` の場合: JMeter テストスクリプトへの相対パス。 `testType: Locust`場合: 子テストスクリプトへの相対パス。 `testType: URL`場合: 要求 JSON ファイルへの相対パス。
`engineInstances`	整数 (integer)	年		テスト計画を実行するための並列テストエンジンインスタンスの数。高スケールの負荷構成する方法の詳細についてはを参照してください。
`configurationFiles`	文字列の配列	N		テストスクリプトに必要な外部ファイルの一覧。たとえば、JMX フラグメントファイル、CSV データファイル、イメージ、またはその他のデータファイルなどです。 Azure Load Testing は、すべてのファイルをテストスクリプトと同じフォルダーにアップロードします。 JMeter スクリプトまたは子スクリプトでは、ファイル名を使用して外部ファイルのみを参照し、ファイルパス情報を削除します。
`failureCriteria`	オブジェクト	N		ロードテストの失敗条件。詳細については、 failureCriteria を参照してください。
`autoStop`	文字列またはオブジェクト	N		エラーの割合がある値を超えると、ロードテストを自動的に停止します。指定できる値 - `disable`: ロードテストを自動的に停止しません。 - object: 詳細については、 autostop の構成を参照してください。
`properties`	オブジェクト	N		`testType: JMX`場合: JMeter ユーザープロパティファイル参照。 `testType: Locust`場合: 子構成ファイル参照。詳細については、 properties を参照してください。
`zipArtifacts`	文字列の配列	N		zip 成果物ファイルの一覧を指定します。 JMeter ベースのテスト用のメインテストスクリプトおよびユーザープロパティ以外のファイル、および、子ベースのテスト用の子スクリプトと構成ファイルの場合、ファイルサイズが 50 MB を超える場合は、ZIP ファイルに圧縮します。 ZIP ファイルのサイズが 50 MB 未満であることを確認します。 ZIP アーティファクトは 5 つしか許可されず、各ファイルに最大 1,000 個のファイルがあり、圧縮されていないサイズは 1 GB です。 `testType: JMX`と`testType: Locust`にのみ適用されます。
`splitAllCSVs`	ブーリアン	N	いいえ	入力 CSV ファイルをすべてのテストエンジンインスタンスに均等に分割します。詳細については、ロードテストのCSVファイルを読むを参照してください。
`secrets`	オブジェクト	N		Apache JMeter または子スクリプトが参照するシークレットの一覧。詳細については、 secrets を参照してください。
`env`	オブジェクト	N		Apache JMeter スクリプトまたは子が参照する環境変数の一覧。詳細については、 environment 変数を参照してください。
`certificates`	オブジェクト	N		JMeter または子スクリプトのアプリケーションエンドポイントで認証するためのクライアント証明書の一覧。詳細については、 certificates を参照してください。
`appComponents`	オブジェクト	N		ロードテスト中に監視するサーバー -side リソースの一覧。詳細については、 appComponents を参照してください。
`subnetId`	ひも	N		プライベートにホストされるエンドポイントをテストするための仮想ネットワークサブネットのリソース ID。このサブネットは、挿入されたテストエンジン VM をホストします。詳細については、プライベートにホストされているエンドポイントをロードテストする方法に関する記事を参照してください。
`publicIPDisabled`	ブーリアン	N		プライベートエンドポイントのテスト中は、パブリック IP アドレス、ロードバランサー、ネットワークセキュリティグループのデプロイを無効にします。詳細については、プライベートにホストされているエンドポイントをロードテストする方法に関する記事を参照してください。
`regionalLoadTestConfig`	オブジェクト	N		リージョン間で負荷を分散して、複数のリージョンからのユーザートラフィックをシミュレートします。詳細については、「リージョンのロードテストの構成を参照してください。
`referenceIdentities`	オブジェクト	N		Azure Key Vault からシークレットにアクセスするためにテストで使用されるマネージド ID の一覧、サーバー側の障害条件のメトリック、エンドポイントの認証。詳細については、 referenceIdentities を参照してください。

ロードテスト構成サンプル

次の YAML スニペットには、ロードテスト構成の例が含まれています。

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

`failureCriteria` 構成

テストの失敗条件を使用すると、ロードテストの実行が成功したかどうかを判断する条件を定義できます。 1 つ以上の不合格条件が満たされた場合、テストは失敗したテスト結果を取得します。ロードテストの失敗条件使用する方法の詳細についてはを参照してください。応答時間、待機時間などのクライアントメトリックと、サーバー側アプリコンポーネントのサーバー側メトリックに対して、エラー条件を定義できます。

クライアントメトリック

ロードテスト全体に適用される、または特定の要求に適用される失敗条件を定義できます。不合格条件の構造は次のとおりです。

ロードテストレベルでのテスト条件: Aggregate_function (client_metric) condition threshold。
特定の要求に適用されるテスト条件: Request: Aggregate_function (client_metric) condition threshold。

Azure Load Testing では、次のクライアントメトリックがサポートされています。

メトリック	集計関数	しきい値	条件	説明
`response_time_ms`	`avg` (平均) `min` (最小) `max` (最大) `pxx` (パーセンタイル): xx は 50、75、90、95、96、97、98、99、999、9999 のいずれかです。	ミリ秒 (ms) を表す整数値。	`>` (より大きい) `<` (より小さい)	応答時間または経過時間 (ミリ秒単位)。経過時間の詳細については、「Apache JMeter のドキュメント」を参照してください。
`latency`	`avg` (平均) `min` (最小) `max` (最大) `pxx` (パーセンタイル)、xx は 50、90、95、99 にすることができます	ミリ秒 (ms) を表す整数値。	`>` (より大きい) `<` (より小さい)	待機時間 (ミリ秒単位)。待機時間の詳細については、「Apache JMeter のドキュメント」を参照してください。
`error`	`percentage`	パーセントを表す 0 - 100 の範囲の数値。	`>` (より大きい)	失敗した要求の割合。
`requests_per_sec`	`avg` (平均)	小数点以下 2 桁までの数値。	`>` (より大きい) `<` (より小さい)	1 秒あたりの要求回数。
`requests`	`count`	整数値。	`>` (より大きい) `<` (より小さい)	要求の合計数。

サーバー側のメトリック

サーバー側アプリコンポーネントのサーバー側メトリックで失敗条件を定義できます。

次の表では、 serverMetrics: 構成のさまざまなフィールドについて説明します。

パラメーター	説明
`resourceId`	必須。条件を適用するアプリコンポーネントのリソース ID
`metricNamespace`	必須。サーバー側のメトリック名前空間。
`metricName`	必須。条件を適用するサーバー側のメトリック。
`aggregation`	必須。サーバー側のメトリックに適用する集計。
`condition`	任意。 `greater than`、`less than` などの比較演算子。
`value`	必須。メトリックと比較する数値。

エラー条件の構成サンプル

次のコードスニペットは、ロードテストの失敗条件が 3 つのロードテスト構成を示しています。

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

`appComponents` 構成

ロードテスト中にサーバー側のリソースを監視できます。サーバー側リソースの監視について詳しくは、こちらをご覧ください。 Azure でホストされるアプリケーションのロードテストを実行すると、Azure Load Testing によって、アプリケーションコンポーネントのリソースメトリックが収集され、負荷テストダッシュボードに表示されます。

次の表では、 appComponents: 構成のさまざまなフィールドについて説明します。

パラメーター	説明
`resourceId`	必須。条件を適用する必要があるアプリコンポーネントのリソース ID。
`resourceName`	任意。監視するリソースの名前。
`kind`	任意。監視するリソースの種類。
`metrics`	必須。アプリコンポーネントの監視対象となるメトリックの一覧。これには、メトリックの名前、名前空間、および集計が含まれます。

アプリコンポーネントの構成サンプル

次のコードスニペットは、2 つのアプリコンポーネントを含むロードテスト構成を示しています。

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

`autoStop` 構成

ロードテストの自動停止機能を使用すると、特定の時間枠内にエラーの割合が特定のしきい値を超えたときに、ロードテストを自動的に停止できます。自動停止のテスト機能の読み込みの詳細については。

キー	タイプ	規定値	説明
`errorPercentage`	整数 (integer)	90	`timeWindow`中のエラー率のしきい値。特定の時間枠中にエラーの割合がこの割合を超えると、テストの実行は自動的に停止します。
`timeWindow`	整数 (integer)	六十	`errorPercentage`を計算するための時間枠 (秒単位)。

Autostop 構成サンプル

次のコードスニペットは、ロードテストの失敗条件が 3 つのロードテスト構成を示しています。

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

`properties` 構成

ロードテスト用の JMeter ユーザープロパティファイルを指定できます。ユーザープロパティファイルは、テスト計画やその他のファイルと共にアップロードされます。 Azure Load Testing での JMeter ユーザープロパティの使用の詳細。

キー	タイプ	規定値	説明
`userPropertyFile`	ひも		Apache JMeter user プロパティファイルとして使用するファイルまたは構成ファイル。また、1 つの構成ファイルとして、.conf、.ini、.toml という拡張子のファイルがサポートされています。このファイルは、テストスクリプトやその他の構成ファイルと共に Azure Load Testing リソースにアップロードされます。ファイルがローカルコンピューター上のサブフォルダー内にある場合は、テストスクリプトの場所を基準とした相対パスを使用します。

ユーザープロパティファイルの構成サンプル

次のコードスニペットは、ユーザープロパティファイルを指定するロードテスト構成を示しています。

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'

次のコードスニペットは、ロードテストの構成を示しています。この構成では、子の構成ファイルを指定します。

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'

`secrets` 構成

シークレット値は Azure Key Vault に格納し、テスト計画で参照できます。 Azure Load Testing でのシークレットの使用の詳細。

キー	タイプ	規定値	説明
`name`	ひも		シークレットの名前。この名前は、テスト計画要求で使用するシークレット名と一致する必要があります。
`value`	ひも		Azure Key Vault シークレットの URI (シークレット識別子)

シークレット構成のサンプル

次のコードスニペットは、Azure Key Vault 内のシークレット my-secret を参照するロードテスト構成を示しています。

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

`env` 構成

環境変数を指定し、テスト計画でそれらを参照できます。 Azure Load Testing を使用した環境変数の使用の詳細。

キー	タイプ	規定値	説明
`name`	ひも		環境変数の名前。この名前は、テスト計画要求で使用する変数名と一致する必要があります。
`value`	ひも		環境変数の値。

環境変数の構成サンプル

次のコードスニペットは、環境変数の my-variable と値の 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

`certificates` 構成

ロードテストにクライアント証明書を渡すことができます。この証明書は Azure Key Vault に格納されます。 Azure Load Testing を使用したクライアント証明書の使用の詳細。

キー	タイプ	規定値	説明
`name`	ひも		証明書の名前。
`value`	ひも		Azure Key Vault の証明書の URI (シークレット識別子)。

証明書構成のサンプル

次のコードスニペットは、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

`referenceIdentities` 構成

ロードテストでは、さまざまなシナリオでマネージド ID を使用できます。マネージド ID は、Azure Key Vault からシークレットまたは証明書にアクセスし、サーバー側の障害条件とエンドポイントの認証のメトリックをフェッチするために、テストで使用できます。

次の表では、 referenceIdentities: 構成のさまざまなフィールドについて説明します。

パラメーター	説明
`kind`	必須。これにより、マネージド ID が使用されるシナリオが定義されます。これは、`KeyVault`または`Metrics`の次の`Engine`のいずれかになります。種類 `Engine`には複数の項目が存在する場合があります。
`type`	必須。 ID の種類。これは、 `UserAssigned` または `SystemAssigned`できます。
`value`	必須。マネージド ID のリソース ID。型が `SystemAssigned`場合は、これを指定する必要はありません。

参照 ID の構成サンプル

次のコードスニペットは、複数の ID のロードテスト構成を示しています。

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

JSON ファイルを要求します

URL ベースのテストを使用する場合は、テストスクリプトを使用する代わりに、JSON ファイルで HTTP 要求を指定できます。テスト構成 YAML ファイルでtestTypeするようにURLを設定し、要求 JSON ファイルを参照してください。

HTTP 要求

要求 JSON ファイルでは、 requests プロパティで要求を定義するために次のプロパティを使用します。

プロパティ	タイプ	説明
`requestName`	ひも	一意の要求名。テストの失敗条件を構成場合は、要求名を参照できます。
`responseVariables`	配列	応答変数の一覧。応答変数を使用して要求から値を抽出し、後続の要求でそれを参照します。応答変数の詳細についてはを参照してください。
`responseVariables.extractorType`	ひも	応答出力から値を抽出するメカニズム。サポートされている値は、`XPathExtractor`、`JSONExtractor`、および `RegularExpression` です。
`responseVariables.expression`	ひも	応答出力を取得する式。式は、エクストラクターの型の値に依存します。
`responseVariables.variableName`	ひも	一意の応答変数名。 `{$variable-name}`構文を使用して、後続の要求でこの変数を参照できます。
`queryParameters`	配列	エンドポイントに渡すクエリ文字列パラメーターの一覧。
`queryParameters.key`	ひも	クエリ文字列パラメーター名。
`queryParameters.value`	ひも	クエリ文字列パラメーター値。
`requestType`	ひも	要求の種類。サポートされる値は、 `URL` または `CURL`です。
`endpoint`	ひも	テストするアプリケーションエンドポイントの URL。
`headers`	配列	アプリケーションエンドポイントに渡す HTTP ヘッダーの一覧。各ヘッダーのキーと値のペアを指定します。
`body`	ひも	HTTP 要求の本文。 `requestBodyFormat`を使用して、本文のコンテンツの形式を指定できます。
`requestBodyFormat`	ひも	本文の内容の形式。サポートされている値は、`Text`、`JSON`、`JavaScript`、`HTML`、`XML` です。
`method`	ひも	エンドポイントを呼び出す HTTP メソッド。サポートされる値は、 `GET`、 `POST`、 `PUT`、 `DELETE`、 `PATCH`、 `HEAD`、および `OPTIONS`です。
`curlCommand`	ひも	実行する cURL コマンド。 `requestType`が`CURL`されている必要があります。

次の JSON スニペットには、要求 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
        }
    ]
}

構成の読み込み

要求 JSON ファイルでは、 testSetup プロパティで読み込み構成を定義するために、次のプロパティを使用します。

プロパティ	タイプ	負荷型	説明
`loadType`	ひも		読み込みパターンの種類。サポートされている値: `linear`、`step`、`spike`。
`scenario`	ひも		`scenarios` プロパティで指定された要求グループへの参照。
`virtualUsersPerEngine`	整数 (integer)	すべて	テストエンジンインスタンスあたりの仮想ユーザーの数。
`durationInSeconds`	整数 (integer)	すべて	ロードテストの合計期間 (秒単位)。
`rampUpTimeInSeconds`	整数 (integer)	Linear、Step	ターゲットの仮想ユーザー数まで上昇する時間 (秒単位)。
`rampUpSteps`	整数 (integer)	ステップ	ターゲットの仮想ユーザー数に到達するステップの数。
`spikeMultiplier`	整数 (integer)	スパイク	スパイク期間中にターゲットユーザーの数を乗算する係数。
`spikeHoldTimeInSeconds`	整数 (integer)	スパイク	スパイクの負荷を維持するための合計時間 (秒)。

リージョンロードテストの構成

リージョン間で負荷を分散して、実際のトラフィックパターンをより適切にシミュレートできます。負荷を生成するリージョンと、各リージョンからシミュレートする負荷の量を指定できます。そのためには、リージョン名と、そのリージョンに必要なエンジンインスタンスの数を指定します。複数のリージョンから負荷をする方法について説明します。

キー	タイプ	規定値	説明
`region`	ひも		Azure リージョンの名前。
`engineInstances`	整数 (integer)		その Azure リージョンのエンジンインスタンスの数。

リージョンロードテストの構成サンプル

次のコードスニペットは、 eastus と eastasia の 2 つの Azure リージョンと、各リージョンのエンジンインスタンスの数を指定するロードテスト構成を示しています。

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

CI/CD ワークフローで自動回帰テストをビルドする方法について説明します。
シークレットと環境変数を使用してロードテストをパラメーター化する方法について説明します。
セキュリティで保護されたエンドポイントをロードテストする方法について説明します。

次の方法で共有

YAML でのロード テストを構成する

ロード テストの YAML 構文

ロード テスト構成サンプル

failureCriteria 構成

クライアント メトリック

サーバー側のメトリック

エラー条件の構成サンプル

appComponents 構成

アプリ コンポーネントの構成サンプル

autoStop 構成

Autostop 構成サンプル

properties 構成

ユーザー プロパティ ファイルの構成サンプル

secrets 構成