IDT テストオーケストレーターを設定する

IDT v4.5.2 以降、には新しいテストオーケストレーターコンポーネントIDTが含まれています。テストオーケストレーターは、テストスイートの実行フローを制御するIDTコンポーネントであり、すべてのテストの実行IDTが終了した後にテストレポートを生成します。テストオーケストレーターは、ユーザー定義のルールに基づいて、テストの選択とテストの実行順序を決定します。

テストスイートにユーザー定義のテストオーケストレーターが含まれていない場合、 IDTはテストオーケストレーターを生成します。

デフォルトのテストオーケストレーターには以下の機能があります。

テストの実行者に、テストスイート全体ではなく、特定のテストグループを選択して実行する機能を提供する。
特定のテストグループが選択されていない場合、テストスイート内のすべてのテストグループをランダムな順序で実行する。
レポートを生成し、各テストグループおよびテストケースのテスト結果を示すコンソールサマリーを出力する。

テストオーケストレーターはIDTステートマシンを置き換えます。IDT ステートマシンの代わりにテストオーケストレーターを使用してテストスイートを開発することを強くお勧めします。テストオーケストレーターでは、以下の機能が改善されています。

IDT ステートマシンが使用する命令形式と比較した宣言形式を使用します。これにより、どのテストを実行するか、およびいつそれを実行するかを指定できます。
特定のグループ処理、レポート生成、エラー処理、結果追跡を管理し、これらのアクションを手動管理する必要がないようにします。
デフォルトではコメントをサポートする YAML形式を使用します。
同じワークフローを定義するのに必要なディスク容量が、テストオーケストレーターより 80% 少なくなります。
ワークフロー定義に誤ったテストIDsや循環依存関係が含まれていないことを確認するためのテスト前検証を追加しました。

テストオーケストレーター形式

次のテンプレートを使用して、独自の custom-test-suite-folder/suite/test_orchestrator.yaml ファイルを設定できます。


Aliases:
  string: context-expression

ConditionalTests:
  - Condition: context-expression
    Tests:
      - test-descriptor

Order:
  - - group-descriptor
    - group-descriptor

Features:
  - Name: feature-name
    Value: support-description
    Condition: context-expression
    Tests:
        - test-descriptor
    OneOfTests:
        - test-descriptor
    IsRequired: boolean

以下に説明するように、値が含まれているすべてのフィールドは必須です。

Aliases

オプション。コンテキスト式にマップするユーザー定義の文字列。エイリアスを使用すると、テストオーケストレーター設定でコンテキスト式を識別するためのフレンドリ名を生成できます。これは、複雑なコンテキスト式や、複数の場所で使用する式を作成する場合に特に便利です。

コンテキスト式を使用して、他のIDT設定からデータにアクセスできるコンテキストクエリを保存できます。詳細については、「コンテキスト内のデータにアクセスする」を参照してください。

例


Aliases:
    FizzChosen: "'{{$pool.features[?(@.name == 'Fizz')].value[0]}}' == 'yes'"    
    BuzzChosen: "'{{$pool.features[?(@.name == 'Buzz')].value[0]}}' == 'yes'"    
    FizzBuzzChosen: "'{{$aliases.FizzChosen}}' && '{{$aliases.BuzzChosen}}'"

ConditionalTests

オプション。条件と、条件が満たされたときに実行される、対応するテストケースのリスト。各条件には複数のテストケースを割り当てることができますが、特定のテストケースを割り当てることができる条件は 1 つだけです。

デフォルトでは、はこのリストの条件に割り当てられていないテストケースIDTを実行します。このセクションを指定しない場合、はテストスイート内のすべてのテストグループIDTを実行します。

ConditionalTests リストの各項目には以下のパラメータが含まれます。

Condition

ブール値に評価されるコンテキスト式。評価値が true の場合、は Testsパラメータで指定されたテストケースIDTを実行します。

Tests

テスト記述子のリスト。

各テスト記述子は、テストグループ ID と 1 つ以上のテストケースIDsを使用して、特定のテストグループから実行する個々のテストを識別します。テスト記述子は以下の形式を使用します。


GroupId: group-id
CaseIds: [test-id, test-id] # optional

例

次の例は、Aliases として定義できる汎用コンテキスト式を使用します。


ConditionalTests:
    - Condition: "{{$aliases.Condition1}}"
      Tests:
          - GroupId: A
          - GroupId: B
    - Condition: "{{$aliases.Condition2}}"
      Tests:
          - GroupId: D
    - Condition: "{{$aliases.Condition1}} || {{$aliases.Condition2}}"
      Tests:
          - GroupId: C

定義された条件に基づいて、は次のようにテストグループIDTを選択します。

Condition1 が true の場合、はテストグループ A、B、C でテストIDTを実行します。
Condition2 が true の場合、はテストグループ C と D でテストIDTを実行します。

Order

オプション。テストを実行する順序。テストの順序はテストのグループレベルで指定します。このセクションを指定しない場合、は該当するすべてのテストグループをランダムな順序でIDT実行します。Order の値は、グループ記述子リストのリストです。Order のリストに記載していないテストグループは、記載されている他のテストグループと並行して実行できます。

各グループ記述子リストには 1 つ以上のグループ記述子が含まれ、各記述子で指定されたグループを実行する順序を特定します。個別のグループ記述子を定義するには、以下の形式を使用できます。

group-id - 既存のテストグループのグループ ID。
[group-id, group-id] - 相互に任意の順序で実行できるテストグループのリスト。
"*" - ワイルドカードこれは、現在のグループ記述子リストにまだ指定されていないすべてのテストグループのリストに相当します。

Order の値は、次の要件も満たしている必要があります。

グループ記述子でIDs指定するテストグループは、テストスイートに存在する必要があります。
各グループ記述子リストには、少なくとも 1 つのテストグループが含まれている必要があります。
各グループ記述子リストには、一意のグループが含まれている必要がありますIDs。個々のグループ記述子内でテストグループ ID を繰り返すことはできません。
グループ記述子リストは、最大 1 つのワイルドカードグループ記述子を持つことができます。ワイルドカードグループ記述子は、リストの最初または最後の項目でなければなりません。

例

テストグループ A、B、C、D、E を含むテストスイートの場合、次の例のリストは、最初にテストグループ A を実行してからテストグループ B を実行してから、任意の順序でテストグループ C、D、E を実行するIDTようにを指定するさまざまな方法を示しています。


Order:
    - - A
      - B
      - [C, D, E]

```
Order:
    - - A
      - B
      - "*"
```


Order:
    - - A
      - B
    
    - - B
      - C
    
    - - B
      - D
    
    - - B
      - E

Features

オプション。awsiotdevicetester_report.xml ファイルIDTに追加する製品機能のリスト。このセクションを指定しない場合、 IDT は製品機能をレポートに追加しません。

製品機能とは、デバイスが満たしている可能性のある特定の基準に関するユーザー定義の情報です。例えば、MQTT製品機能は、デバイスがMQTTメッセージを適切に発行するように指定できます。awsiotdevicetester_report.xml では、製品機能は指定されたテストが合格したかどうかに応じて、supported、not-supported、またはカスタムのユーザー定義値に設定されます。

Features リストの各項目は以下のパラメータで設定されます。

Name

機能の名前。

Value

オプション。supported の代わりにレポートで使用するカスタム値。この値が指定されていない場合、based はテスト結果not-supportedに基づいて特徴値を supportedまたは IDTに設定します。異なる条件で同じ機能をテストする場合、Featuresリスト内のその特徴量のインスタンスごとにカスタム値を使用し、サポートされている条件の特徴量値をIDT連結できます。詳細については、以下を参照してください。

Condition

ブール値に評価されるコンテキスト式。評価値が true の場合、はテストスイートの実行が完了した後に、テストレポートに機能IDTを追加します。評価値が false の場合、テストはレポートに含まれません。

Tests

オプション。テスト記述子のリスト。機能をサポートするには、このリストで指定されるテストにすべて合格する必要があります。

このリストの各テスト記述子は、テストグループ ID と 1 つ以上のテストケースIDsを使用して、特定のテストグループから実行する個々のテストを識別します。テスト記述子は以下の形式を使用します。


GroupId: group-id
CaseIds: [test-id, test-id] # optional

Features リストの各機能について、Tests か OneOfTests のどちらかを指定する必要があります。

OneOfTests

オプション。テスト記述子のリスト。機能をサポートするには、このリストで指定されているテストのうち少なくとも 1 つに合格する必要があります。


GroupId: group-id
CaseIds: [test-id, test-id] # optional

Features リストの各機能について、Tests か OneOfTests のどちらかを指定する必要があります。

IsRequired

機能がテストレポートに必要かどうかを定義するブール値。デフォルト値は false です。

テストオーケストレーターコンテキスト

テストオーケストレーターコンテキストは、テストオーケストレーターが実行中に使用できるデータを含む読み取り専用JSONドキュメントです。テストオーケストレーターコンテキストは、テストオーケストレーターからのみアクセス可能で、テストフローを決定する情報が含まれています。例えば、テストの実行者によって userdata.json ファイルに設定された情報を使用して、特定のテストを実行する必要があるかどうかを決定できます。

テストオーケストレーターコンテキストは次の形式を使用します。


{
    "pool": {
        <device-json-pool-element>
    },
    "userData": {
        <userdata-json-content>
    },
    "config": {
        <config-json-content>
    }
}

pool: テスト実行用に選択されたデバイスプールに関する情報。選択されたデバイスプールのこの情報は、device.json ファイルで定義された、対応する最上位レベルのデバイスプール配列要素から取得されます。
userData: userdata.json ファイル内の情報。
config: config.json ファイル内の情報。

JSONPath 表記を使用してコンテキストをクエリできます。状態定義のJSONPathクエリの構文はです{{query}}。テストオーケストレーターコンテキストからデータにアクセスする場合、各値が文字列、数値、またはブール値として評価されることを確認してください。

JSONPath 表記を使用してコンテキストからデータにアクセスする方法の詳細については、「」を参照してくださいIDT コンテキストを使用する。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

IDT テストスイート設定ファイルを作成する

IDT ステートマシンを設定する