IDT テストオーケストレーターを設定する - AWS IoT Greengrass

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

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

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

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

  • テストの実行者に、テストスイート全体ではなく、特定のテストグループを選択して実行する機能を提供する。

  • 特定のテストグループが選択されていない場合、テストスイート内のすべてのテストグループをランダムな順序で実行する。

  • レポートを生成し、各テストグループおよびテストケースのテスト結果を示すコンソールサマリーを出力する。

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

  • IDT ステートマシンが命令型を使用するのに対し、宣言型を使用します。これにより、どのテストを実行するか、およびいつそれを実行するかを指定できます。

  • 特定のグループ処理、レポート生成、エラー処理、結果追跡を管理し、これらのアクションを手動管理する必要がないようにします。

  • デフォルトでコメントをサポートする YAML 形式を使用します。

  • 同じワークフローを定義するのに必要なディスク容量が、テストオーケストレーターより 80% 少なくなります。

  • テスト前検証を追加し、誤ったテスト ID や依存関係の循環がワークフロー定義に含まれていないことを検証します。

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

次のテンプレートを使用して、独自の <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 の場合、IDT は Tests パラメータで指定されたテストケースを実行します。

Tests

テスト記述子のリスト。

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

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 が真の場合、IDT はテストグループ A、B、C のテストを実行します。

  • Condition2 が真の場合、IDT はテストグループ C と D のテストを実行します。

Order

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

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

  • group-id—既存のテストグループのグループ ID。

  • [group-id, group-id]—相互に任意の順序で実行できるテストグループのリスト。

  • "*"—ワイルドカード これは、現在のグループ記述子リストにまだ指定されていないすべてのテストグループのリストに相当します。

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

  • グループ記述子で指定するテストグループ ID は、テストスイートに存在する必要があります。

  • 各グループ記述子リストには、少なくとも 1 つのテストグループが含まれている必要があります。

  • 各グループ記述子リストには一意のグループ ID を含める必要があります。個々のグループ記述子内でテストグループ ID を繰り返すことはできません。

  • グループ記述子リストは、最大 1 つのワイルドカードグループ記述子を持つことができます。ワイルドカードグループ記述子は、リストの最初または最後の項目でなければなりません。

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

  • Order: - - A - B - [C, D, E]
  • Order: - - A - B - "*"
  • Order: - - A - B - - B - C - - B - D - - B - E
Features

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

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

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

Name

機能の名前。

Value

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

Condition

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

Tests

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

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

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

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

OneOfTests

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

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

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

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

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 コンテキストを使用するを参照してください。