サポート終了通知: 2026 年 10 月 7 日、 AWS はサポートを終了します AWS IoT Greengrass Version 1。2026 年 10 月 7 日以降、 AWS IoT Greengrass V1 リソースにアクセスできなくなります。詳細については、[「 からの移行 AWS IoT Greengrass Version 1](https://docs.aws.amazon.com/greengrass/v2/developerguide/migrate-from-v1.html)」を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS IoT Device Tester for AWS IoT Greengrass V1 の使用
AWS IoT Device Tester (IDT) は、IoT デバイスを検証できるダウンロード可能なテストフレームワークです。 AWS IoT Greengrass Version 1 が[メンテナンスモード](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html)に移行されたため、IDT for は署名付き認定レポートを生成 AWS IoT Greengrass V1 しなくなりました。Device Qualification Program を通じて [AWS Partner Device Catalog](https://devices.amazonaws.com/) にリスト AWS IoT Greengrass V1 する新しいデバイスを認定できなくなります。 [AWS](https://aws.amazon.com/partners/dqp/)ただし、引き続き IDT for AWS IoT Greengrass V1 を使用して Greengrass V1 デバイスをテストできます。[IDT for AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) を使用して、Greengrass デバイスを認定し、[AWS Partner Device Catalog](https://devices.amazonaws.com/) に含めることをお勧めします。
IDT for は、テスト対象のデバイスに接続されたホストコンピュータ (Windows、macOS、または Linux) で AWS IoT Greengrass 実行されます。また、テストを実行して結果を集計します。また、テストプロセスを管理するためのコマンドラインインターフェイスも用意されています。
## AWS IoT Greengrass 認定スイート
IDT for AWS IoT Greengrass を使用して、 AWS IoT Greengrass Core ソフトウェアがハードウェア上で実行され、 と通信できることを確認します AWS クラウド。また、 を使用してend-to-endのテストも実行します AWS IoT Core。例えば、デバイスで MQTT メッセージを送受信して正しく処理できることを確認します。
![\[AWS IoT Device Tester が AWS IoT Greengrass コアソフトウェアがハードウェア上で実行され、 と通信できることを検証する方法の概要 AWS クラウド。\]](http://docs.aws.amazon.com/ja_jp/greengrass/v1/developerguide/images/devicetester_gg.png)
AWS IoT Device Tester for は、テスト*スイートとテスト**グループの*概念を使用してテストを AWS IoT Greengrass 整理します。
+ テストスイートは、デバイスが AWS IoT Greengrassの特定のバージョンで動作することを確認するために使用されるテストグループのセットです。
+ テストグループは、Greengrass グループデプロイや MQTT メッセージングなど、特定の機能に関連する個々のテストのセットです。
詳細については、「[IDT を使用して AWS IoT Greengrass 認定スイートを実行する](idt-gg-qualification.md)」を参照してください。
## カスタムテストスイート
IDT v4.0.0 以降、IDT for は標準化された設定設定と結果形式をテストスイート環境と AWS IoT Greengrass 組み合わせ、デバイスとデバイスソフトウェア用のカスタムテストスイートを開発できます。独自の内部検証用のカスタムテストを追加したり、デバイス検証のためにこれらのテストを顧客に提供したりできます。
テスト作成者がカスタムテストスイートをどのように設定するかによって、カスタムテストスイートの実行に必要な設定が変わってきます。詳細については、「[IDT を使用して独自のテストスイートを開発および実行する](idt-custom-tests.md)」を参照してください。
# AWS IoT Device Tester for AWS IoT Greengrass V1 でサポートされているバージョン
AWS IoT Greengrass Version 1 が[メンテナンスモード](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html)に移行されたため、IDT for は署名付き認定レポートを生成 AWS IoT Greengrass V1 しなくなりました。[IDT for AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) を使用することをお勧めします。
IDT for AWS IoT Greengrass V2 の詳細については、 *AWS IoT Greengrass V2 デベロッパーガイド*の「 [での AWS IoT Device Tester の使用 AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html)」を参照してください。
**注記**
IDT for が AWS IoT Greengrass 使用している のバージョンと互換性がない場合 AWS IoT Greengrass 、テストランを開始すると通知を受け取ります。
ソフトウェアをダウンロードすると、[AWS IoT Device Tester ライセンス契約](https://docs.aws.amazon.com/greengrass/latest/developerguide/idt-license.html)に同意したと見なされます。
## for でサポートされていない IDT バージョン AWS IoT Greengrass
このトピックでは、IDT for のサポートされていないバージョンを一覧表示します AWS IoT Greengrass。サポートされていないバージョンのバグ修正や更新プログラムは受けられません。詳細については、「[の AWS IoT Device Tester のサポートポリシー AWS IoT Greengrass V1](idt-support-policy.md)」を参照してください。
** AWS IoT Greengrass バージョン v1.11.6、v1.10.5 の IDT v4.4.1**
リリースノート:
+ AWS IoT Greengrass コアソフトウェア v1.11.6 および v1.10.5 を実行しているデバイスを検証および認定できます。
+ 軽微なバグ修正が含まれています。
テストスイートのバージョン:
`GGQ_1.3.1`
+ リリース日: 2021 年 12 月 20 日
** AWS IoT Greengrass バージョン v1.11.4、v1.10.4 の IDT v4.1.0**
リリースノート:
+ AWS IoT Greengrass コアソフトウェア v1.11.4 および v1.10.4 を実行しているデバイスを検証して認定できます。
+ テスト実行時に表示されるログで冗長タグが使用される問題を修正しました。
テストスイートのバージョン:
`GGQ_1.3.0`
+ リリース日: 2021 年 6 月 23 日
+ Lambda、IAM、および への API コールの再試行を追加 AWS STS し、スロットリングまたはサーバーの問題の処理を改善しました。
+ Python 3.8 に ML や Docker のテストケースへのサポートを追加します。
** AWS IoT Greengrass バージョン v1.11.1、v1.11.0、v1.10.3 の IDT v4.0.2**
リリースノート:
+ IDT でハードウェアセキュリティ統合 (HSI) のエラーを認識できない原因となった問題を修正しました。
+ AWS IoT Device Tester for を使用してカスタムテストスイートを開発および実行できます AWS IoT Greengrass。詳細については、「[IDT を使用して独自のテストスイートを開発および実行する](idt-custom-tests.md)」を参照してください。
+ macOS および Windows 用のコード署名付き IDT アプリケーションを提供します。macOS でセキュリティ警告メッセージが表示される場合は、IDT のセキュリティ例外を許可する必要が出てくる場合があります。詳細については、「[macOS でのセキュリティ例外](idt-troubleshooting.md#macos-notarization-exception)」を参照してください。
AWS IoT Greengrass は、コアソフトウェアのバージョン 1.11.1 AWS IoT Greengrass の Dockerfile または Docker イメージを提供しません。デバイスの Docker 認定をテストするには、以前のバージョンの AWS IoT Greengrass Core ソフトウェアを使用します。
** AWS IoT Greengrass バージョン v1.11.0、v1.10.1、v1.10.0 の IDT v3.2.0**
リリースノート:
+ IDT がデフォルトで実行するテストは認定に必要なものだけです。その他の機能を認定するには、[`device.json`](set-config.md#device-config) ファイルの内容を変更します。
+ `device.json` にポート番号が追加され、SSH 接続用の設定に対応しました。
+ Docker は[ストリームマネージャー](stream-manager.md)とコンテナ化を伴わない機械学習 (ML) のみをサポートしています。コンテナ、Docker、ハードウェアセキュリティ統合 (HSI) は Docker デバイスでは使用できません。
+ `device-ml.json` と `device-hsm.json` を `device.json` にまとめました。
**IDT v3.1.3 AWS IoT Greengrass バージョン: v1.10.x、v1.9.x、v1.8.x**
リリースノート:
+ v1.10.x および AWS IoT Greengrass v1.9.x の ML 機能認定のサポートが追加されました。クラウド内に保存されているトレーニング済みモデルを使用し、デバイスが ML 推論をローカルで実行できることを IDT で検証できるようになりました。
+ `run-suite` コマンドに `--stop-on-first-failure` オプションが追加されました。このオプションを使用すると、最初に失敗が発生した時点で実行を停止するように IDT を設定できます。このオプションは、テストグループレベルのデバッグ段階で使用することをお勧めします。
+ テスト対象のデバイスが正しいシステム時間を使用していることを確認するために、MQTT テストにクロックドリフトチェックが追加されました。使用するシステム時間は、許容時間範囲内に収まっている必要があります。
+ `run-suite` コマンドに `--update-idt` オプションが追加されました。このオプションを使用すると、IDT を更新するプロンプトの応答を設定できます。
+ `run-suite` コマンドに `--update-managed-policy` オプションが追加されました。このオプションを使用すると、マネージドポリシーを更新するプロンプトの応答を設定できます。
+ IDT テストスイートの各種バージョンの自動更新に関するバグ修正が追加されました。この修正によって IDT は、お使いの AWS IoT Greengrass バージョンで利用できる最新のテストスイートを実行できるようになります。
**の IDT v3.0.1 AWS IoT Greengrass**
リリースノート:
+ v1.10.1 AWS IoT Greengrass のサポートを追加しました。
+ IDT テストスイートのバージョンの自動更新。IDT は、お使いの AWS IoT Greengrass バージョンで利用可能な最新のテストスイートをダウンロードできます。この機能を使用すると、次の操作を実行できます。
+ テストスイートは、`major.minor.patch` 形式を使用してバージョン管理されます。最初のテストスイートのバージョンは `GGQ_1.0.0` です。
+ コマンドラインインターフェイスで新しいテストスイートをインタラクティブにダウンロードしたり、IDT の起動時に `upgrade-test-suite` フラグを設定したりできます。
詳細については、「[テストスイートのバージョン](idt-gg-qualification.md#idt-test-suite-versions)」を参照してください。
+ `list-supported-products` が追加されました。このコマンドを使用して、インストールされている IDT のバージョンでサポートされている AWS IoT Greengrass およびテストスイートのバージョンを一覧表示できます。
+ `list-test-cases` が追加されました。このコマンドを使用して、テストグループで使用できるテストケースを一覧表示できます。
+ `run-suite` コマンドに `test-id` オプションが追加されました。このオプションを使用して、テストグループ内の個々のテストケースを実行できます。
**IDT v2.3.0 for AWS IoT Greengrass v1.10、v1.9.x、および v1.8.x**
物理デバイスでテストする場合、 AWS IoT Greengrass v1.10、v1.9.x、および v1.8.x がサポートされています。
Docker コンテナでテストする場合、 AWS IoT Greengrass v1.10 と v1.9.x がサポートされています。
リリースノート:
+ [Docker コンテナ AWS IoT Greengrass での実行](run-gg-in-docker-container.md) のサポートが追加されました。IDT を使用して、デバイスが Docker コンテナ AWS IoT Greengrass で実行できることを認定および検証できるようになりました。
+ AWS IoT Device Tester の実行に必要なアクセス許可を定義する [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) (`AWSIoTDeviceTesterForGreengrassFullAccess`) を追加しました。新しいリリースで追加のアクセス許可が必要な場合は、IAM アクセス許可を更新する必要がないように、 がこの管理ポリシー AWS に追加します。
+ テストケースを実行する前に、環境 (デバイス接続やインターネット接続など) が正しく設定されていることを検証するためのチェックを導入しました。
+ IDT の Greengrass 依存関係チェッカーを改善し、デバイスで libc を確認する際の柔軟性を高めました。
**IDT v2.2.0 for AWS IoT Greengrass v1.10、v1.9.x、および v1.8.x**
リリースノート:
+ v1.10 AWS IoT Greengrass のサポートが追加されました。
+ [Greengrass Docker アプリケーションデプロイ](docker-app-connector.md)コネクタのサポートが追加されました。
+ AWS IoT Greengrass [ストリームマネージャー](stream-manager.md)のサポートを追加しました。
+ 中国 (北京) リージョン AWS IoT Greengrass で のサポートが追加されました。
**IDT v2.1.0 for AWS IoT Greengrass v1.9.x、v1.8.x、および v1.7.x**
リリースノート:
+ v1.9.4 AWS IoT Greengrass のサポートを追加しました。
+ Linux-ARMv6l デバイスのサポートが追加されました。
**IDT v2.0.0 for AWS IoT Greengrass v1.9.3、v1.9.2、v.1.9.1、v1.9.0、v1.8.4、v1.8.3、v1.8.2**
リリースノート:
+ テスト対象デバイスの Python への依存関係を削除しました。
+ テストスイートの実行時間が 50% 以上短縮され、適格性確認プロセスが高速化されます。
+ 実行可能なサイズが 50% 以上短縮され、ダウンロードとインストールが高速になります。
+ すべてのテストケースで[タイムアウト乗数のサポート](idt-troubleshooting.md#test-timeout)を改善しました。
+ エラーのトラブルシューティングを高速化するため、診断後のメッセージが強化されました。
+ IDT の実行に必要なアクセス許可ポリシーテンプレートを更新しました。
+ v1.9.3 AWS IoT Greengrass のサポートを追加しました。
**IDT v1.9.2、v1. AWS IoT Greengrass 9.1、v1.9.0、v1.8.3、v1.8.2 用 v1.3.3**
リリースノート:
+ Greengrass v1.9.2 および v1.8.3 のサポートが追加されました。
+ Greengrass OpenWrt のサポートが追加されました。
+ デバイスにサインインする SSH ユーザー名とパスワードを追加しました。
+ OpenWrt-ARMv7l プラットフォーム用のネイティブテストバグ修正が追加されました。
**IDT v1.2 for AWS IoT Greengrass v1.8.1**
リリースノート:
+ タイムアウトの問題 (たとえば、低帯域幅接続) に対処し、トラブルシューティングする設定可能なタイムアウト乗数が追加されました。
**IDT v1.1 for AWS IoT Greengrass v1.8.0**
リリースノート:
+ AWS IoT Greengrass ハードウェアセキュリティ統合 (HSI) のサポートが追加されました。
+ AWS IoT Greengrass コンテナのサポートが追加されました。コンテナはありません。
+ 自動 AWS IoT Greengrass サービスロールの作成を追加しました。
+ テストリソースのクリーンアップが改善されました。
+ テスト実行の要約レポートが追加されました。
**IDT v1.1 for AWS IoT Greengrass v1.7.1**
リリースノート:
+ AWS IoT Greengrass ハードウェアセキュリティ統合 (HSI) のサポートが追加されました。
+ AWS IoT Greengrass コンテナのサポートが追加されました。コンテナはありません。
+ 自動 AWS IoT Greengrass サービスロールの作成を追加しました。
+ テストリソースのクリーンアップが改善されました。
+ テスト実行の要約レポートが追加されました。
**IDT v1.0 for AWS IoT Greengrass v1.6.1**
リリースノート:
+ 将来の AWS IoT Greengrass バージョンの互換性のために OTA テストバグ修正を追加しました。
IDT v1.0 for v1.6.1 AWS IoT Greengrass を使用している場合は、[Greengrass サービスロール](service-role.md)を作成する必要があります。これより後のバージョンでは、IDT によってサービスロールが自動的に作成されます。
# IDT を使用して AWS IoT Greengrass 認定スイートを実行する
の AWS IoT Device Tester (IDT) を使用して AWS IoT Greengrass 、 AWS IoT Greengrass Core ソフトウェアがハードウェア上で実行され、 と通信できることを確認できます AWS クラウド。また、エンドツーエンドのテストが AWS IoT Coreで実行されます。例えば、デバイスで MQTT メッセージを送受信して正しく処理できることを確認します。
AWS IoT Greengrass Version 1 が[メンテナンスモード](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html)に移行されたため、IDT for は署名付き認定レポートを生成 AWS IoT Greengrass V1 しなくなりました。Device AWS Partner Catalog にハードウェアを追加する場合は、 AWS IoT Greengrass V2 認定スイートを実行して、送信できるテストレポートを生成します AWS IoT。詳細については、「[AWS デバイス認定プログラム](https://aws.amazon.com/partners/dqp/)」および「[IDT for AWS IoT Greengrass V2のサポートされているバージョン](https://docs.aws.amazon.com/greengrass/v2/developerguide/dev-test-versions.html)」を参照してください。
デバイスのテストに加えて、IDT for は にリソース ( AWS IoT モノ、 AWS IoT Greengrass グループ、Lambda 関数など) AWS IoT Greengrass を作成し、認定プロセス AWS アカウント を容易にします。
これらのリソースを作成するために、IDT for AWS IoT Greengrass は `config.json` ファイルで設定された AWS 認証情報を使用してユーザーに代わって API コールを行います。これらのリソースは、テスト中にさまざまなタイミングでプロビジョニングされます。
IDT for を使用して認定スイート AWS IoT Greengrass を実行すると、IDT AWS IoT Greengrass は次のステップを実行します。
1. デバイスおよび認証情報の設定をロードして検証します。
1. 必要なローカルリソースとクラウドリソースを使用して選択したテストを実行します。
1. ローカルリソースとクラウドリソースをクリーンアップします。
1. デバイスが資格に必要なテストに合格したかどうかを示すテストレポートを生成します。
## テストスイートのバージョン
IDT for は、テストをテストスイートとテストグループに AWS IoT Greengrass 整理します。
+ テストスイートは、デバイスが AWS IoT Greengrassの特定のバージョンで動作することを確認するために使用されるテストグループのセットです。
+ テストグループは、Greengrass グループデプロイや MQTT メッセージングなど、特定の機能に関連する個々のテストのセットです。
IDT v3.0.0 以降、テストスイートは `major.minor.patch` 形式を使用してバージョン管理されます (例: `GGQ_1.0.0`)。IDT をダウンロードすると、パッケージに最新のテストスイートのバージョンが含まれます。
**重要**
IDT では、デバイスの認定のために 3 つの最新のテストスイートバージョンをサポートしています。詳細については、「[の AWS IoT Device Tester のサポートポリシー AWS IoT Greengrass V1](idt-support-policy.md)」を参照してください。
`list-supported-products` を実行して、現在のバージョンの IDT でサポートされている AWS IoT Greengrass およびテストスイートのバージョンを一覧表示できます。サポートされていないテストスイートのバージョンからのテストは、デバイスの認定には有効ではありません。IDT では、サポートされていないバージョンの認定レポートは印刷されません。
### IDT 構成設定の更新
新しいテストでは、新しい IDT 構成設定が導入される可能性があります。
+ その設定がオプションの場合は、IDT は引き続きテストを実行します。
+ その設定が必要な場合は、IDT から通知され、実行が停止します。設定を構成したら、テストの実行を再開します。
構成設定は、`/configs` フォルダにあります。詳細については、「[認定スイートを実行するように IDT AWS IoT Greengrass 設定を構成する](set-config.md)」を参照してください。
更新されたテストスイートのバージョンによって構成設定が追加されると、IDT は `/configs` に元の設定ファイルのコピーを作成します。
## テストグループの説明
------
#### [ IDT v2.0.0 and later ]
**コア資格に必要なテストグループ**
これらのテストグループは、 AWS IoT Greengrass デバイスを AWS Partner Device Catalog に認定するために必要です。
AWS IoT Greengrass コア依存関係
デバイスが AWS IoT Greengrass Core ソフトウェアのすべてのソフトウェアおよびハードウェア要件を満たしていることを検証します。
このテストグループの `Software Packages Dependencies` テストケースは、[Docker コンテナ](docker-config-setup.md)でテストする場合は適用されません。
デプロイ
Lambda 関数をデバイスにデプロイできることを検証します。
MQTT
Greengrass コアとローカル IoT デバイスであるクライアントデバイス間のローカル通信をチェックして、 AWS IoT Greengrass メッセージルーターの機能を検証します。
無線 (OTA)
デバイスが AWS IoT Greengrass Core ソフトウェアの OTA 更新を正常に実行できることを検証します。
このテストグループは、[Docker コンテナ](docker-config-setup.md)でテストするときには適用されません。
バージョン
AWS IoT Greengrass 提供された のバージョンが、使用している AWS IoT Device Tester のバージョンと互換性があることを確認します。
**オプションのテストグループ**
これらのテストグループはオプションです。オプションテストの資格を選択した場合、デバイスは AWS Partner Device Catalog に追加機能とともに一覧表示されます。
コンテナの依存関係
デバイスが Greengrass コアのコンテナモードで Lambda 関数を実行するためのすべてのソフトウェア要件とハードウェア要件を満たしているかどうかを検証します。
このテストグループは、[Docker コンテナ](docker-config-setup.md)でテストするときには適用されません。
デプロイコンテナ
Lambda 関数をデバイスにデプロイし、Greengrass コアのコンテナモードで実行できることを検証します。
このテストグループは、[Docker コンテナ](docker-config-setup.md)でテストするときには適用されません。
Docker 依存関係 (IDT v2.2.0 以降でサポートされています)
Greengrass Docker アプリケーションデプロイコネクタを使用してコンテナを実行するために必要なすべての技術的依存関係をデバイスが満たしていることを検証します。
このテストグループは、[Docker コンテナ](docker-config-setup.md)でテストするときには適用されません。
ハードウェアセキュリティ統合 (HSI)
提供された HSI 共有ライブラリがハードウェアセキュリティモジュール (HSM) とやり取りでき、必要な PKCS\$111 API を正しく実装することを検証します。HSM および共有ライブラリは、CSR に署名し、TLS オペレーションを実行して、正しいキー長と公開キーアルゴリズムを提供できる必要があります。
ストリームマネージャーの依存関係 (IDT v2.2.0 以降でサポート)
デバイスが AWS IoT Greengrass ストリームマネージャーを実行するために必要な技術的な依存関係をすべて満たしていることを検証します。
機械学習の依存関係 (IDT v3.1.0 以降でサポート)
ML 推論をローカルで実行するために必要なすべての技術的依存関係をデバイスが満たしていることを検証します。
機械学習の推論テスト (IDT v3.1.0 以降でサポート)
テスト中の特定のデバイスで ML 推論を実行できることを検証します。詳細については、「[オプション: ML 認定のためのデバイスの設定](idt-ml-qualification.md)」を参照してください。
機械学習の推論コンテナテスト (IDT v3.1.0 以降でサポート)
テスト中の特定のデバイスで ML 推論を実行でき、Greengrass コアのコンテナモードで実行できることを検証します。詳細については、「[オプション: ML 認定のためのデバイスの設定](idt-ml-qualification.md)」を参照してください。
------
#### [ IDT v1.3.3 and earlier ]
**コア資格に必要なテストグループ**
これらのテストは、 AWS IoT Greengrass デバイスを AWS Partner Device Catalog に認定するために必要です。
AWS IoT Greengrass コア依存関係
デバイスが AWS IoT Greengrass Core ソフトウェアのすべてのソフトウェアおよびハードウェア要件を満たしていることを検証します。
コンビネーション (デバイスのセキュリティ操作)
クラウド内の Greengrass グループの接続情報を変更することで、Greengrass コアの Device Certificate Manager と IP 検出の動作を検証します。テストグループは AWS IoT Greengrass サーバー証明書をローテーションし、 が接続 AWS IoT Greengrass を許可することを確認します。
デプロイ（IDT v1.2 以前のバージョンで必要）
Lambda 関数をデバイスにデプロイできることを検証します。
Device Certificate Manager (DCM)
AWS IoT Greengrass デバイス証明書マネージャーが起動時にサーバー証明書を生成し、有効期限が近い場合は証明書をローテーションできることを確認します。
IP 検出 (IPD)
Greengrass コアデバイスでの IP アドレスの変更に応じてコア接続情報が更新されることを検証します。詳細については、「[自動 IP 検出のアクティブ化](gg-core.md#ip-auto-detect)」を参照してください。
ロギング
AWS IoT Greengrass ログ記録サービスが Python で記述されたユーザー Lambda 関数を使用してログファイルに書き込めることを確認します。
MQTT
2 つの Lambda 関数にルーティングされるトピックでメッセージを送信することで、 AWS IoT Greengrass メッセージルーターの機能を検証します。
ネイティブ
がネイティブ (コンパイル済み) Lambda 関数 AWS IoT Greengrass を実行できることを確認します。
無線 (OTA)
デバイスが AWS IoT Greengrass Core ソフトウェアの OTA 更新を正常に実行できることを検証します。
侵入
ハードリンク/ソフトリンクの保護と [seccomp](https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt) が有効になっていない場合、 AWS IoT Greengrass Core ソフトウェアが起動しないことを確認します。また、他のセキュリティ関連の機能も検証するために使用されます。
シャドウ
ローカルのシャドウとシャドウのクラウド同期機能を検証します。
スプーラー
スプーラーのデフォルト設定を使用して MQTT メッセージをキューに挿入できることを検証します。
Token Exchange Service (TES)
がコア証明書を有効な AWS 認証情報と交換 AWS IoT Greengrass できることを確認します。
バージョン
AWS IoT Greengrass 提供された のバージョンが、使用している AWS IoT Device Tester のバージョンと互換性があることを確認します。
**オプションのテストグループ**
これらのテストはオプションです。オプションテストの資格を選択した場合、デバイスは AWS Partner Device Catalog に追加機能とともに一覧表示されます。
コンテナの依存関係
コンテナモードで Lambda 関数を実行するために必要なすべての依存関係をデバイスが満たしていることを確認します。
ハードウェアセキュリティ統合 (HSI)
提供された HSI 共有ライブラリがハードウェアセキュリティモジュール (HSM) とやり取りでき、必要な PKCS\$111 API を正しく実装することを検証します。HSM および共有ライブラリは、CSR に署名し、TLS オペレーションを実行して、正しいキー長と公開キーアルゴリズムを提供できる必要があります。
ローカルリソースアクセス
さまざまな Linux ユーザーやグループが所有するローカルファイルやディレクトリへのアクセスを LRA API を介してコンテナ化された Lambda 関数に提供 AWS IoT Greengrass することで、 のローカルリソースアクセス (LRA) AWS IoT Greengrass 機能を検証します。 APIs ローカルリソースアクセスの設定に基づいて、ローカルリソースへのアクセスを Lambda 関数に許可または拒否する必要があります。
ネットワーク
Lambda 関数からソケット接続を確立できることを検証します。Greengrass コア設定に基づいて、これらのソケット接続を許可または拒否する必要があります。
------
# AWS IoT Greengrass 認定スイートを実行するための前提条件
このセクションでは、 AWS IoT Greengrass の AWS IoT Device Tester (IDT) AWS IoT Greengrass を使用して認定スイートを実行するための前提条件について説明します。
## の最新バージョンの AWS IoT Device Tester をダウンロードする AWS IoT Greengrass
IDT の[最新バージョン](dev-test-versions.md)をダウンロードし、ファイルシステム上で読み取りおよび書き込みアクセス許可を持っている場所に抽出します。
**注記**
複数のユーザーが NFS ディレクトリや Windows ネットワーク共有フォルダなどの共有場所から IDT を実行することはお勧めしません。IDT パッケージをローカルドライブに展開し、ローカルワークステーションで IDT バイナリを実行することをお勧めします。
Windows では、パスの長さは 260 文字に制限されています。Windows を使用している場合は、パスが 260 文字以内になるようにして、IDT をルートディレクトリ (`C:\ ` または `D:\` など) に展開します。
## の作成と設定 AWS アカウント
IDT for を使用する前に AWS IoT Greengrass、次の手順を実行する必要があります。
1. [を作成します AWS アカウント。]()が既にある場合は AWS アカウント、ステップ 2 に進みます。
1. [IDT 用のアクセス許可を設定する。]()
これらのアカウントのアクセス許可により、IDT はユーザーに代わって AWS サービスにアクセスし、 AWS IoT モノ、Greengrass グループ、Lambda 関数などの AWS リソースを作成できます。
これらのリソースを作成するために、IDT for AWS IoT Greengrass は `config.json` ファイルで設定された AWS 認証情報を使用してユーザーに代わって API コールを行います。これらのリソースは、テスト中にさまざまなタイミングでプロビジョニングされます。
**注記**
ほとんどのテストは[アマゾン ウェブ サービス無料利用枠](https://aws.amazon.com/free)の対象となりますが、 AWS アカウントにサインアップするときにクレジットカード情報を提供する必要があります。詳細については、「[ アカウントが無料利用枠の対象であるのに、支払い方法が必要なのはなぜですか?](https://aws.amazon.com/premiumsupport/knowledge-center/free-tier-payment-method/)」を参照してください。
### ステップ 1: を作成する AWS アカウント
このステップでは、 AWS アカウントを作成して設定します。が既にある場合は AWS アカウント、「」に進みます[ステップ 2: IDT 用のアクセス許可を設定する](#configure-idt-permissions)。
#### にサインアップする AWS アカウント
がない場合は AWS アカウント、次の手順を実行して作成します。
**にサインアップするには AWS アカウント**
1. [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup) を開きます。
1. オンラインの手順に従います。
サインアップ手順の一環として、電話またはテキストメッセージを受け取り、電話キーパッドで検証コードを入力します。
にサインアップすると AWS アカウント、 *AWS アカウントのルートユーザー* が作成されます。ルートユーザーには、アカウントのすべての AWS のサービス とリソースへのアクセス権があります。セキュリティベストプラクティスとして、ユーザーに管理アクセス権を割り当て、[ルートユーザーアクセスが必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)の実行にはルートユーザーのみを使用するようにしてください。
AWS サインアッププロセスが完了すると、 から確認メールが送信されます。[https://aws.amazon.com/](https://aws.amazon.com/) の **[マイアカウント]** をクリックして、いつでもアカウントの現在のアクティビティを表示し、アカウントを管理することができます。
#### 管理アクセスを持つユーザーを作成する
にサインアップしたら AWS アカウント、日常的なタスクにルートユーザーを使用しないように AWS アカウントのルートユーザー、 のセキュリティを確保し AWS IAM アイデンティティセンター、 を有効にして管理ユーザーを作成します。
**を保護する AWS アカウントのルートユーザー**
1. **ルートユーザー**を選択し、 AWS アカウント E メールアドレスを入力して、アカウント所有者[AWS マネジメントコンソール](https://console.aws.amazon.com/)として にサインインします。次のページでパスワードを入力します。
ルートユーザーを使用してサインインする方法については、「*AWS サインイン ユーザーガイド*」の「[ルートユーザーとしてサインインする](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial)」を参照してください。
1. ルートユーザーの多要素認証 (MFA) を有効にします。
手順については、*IAM* [ユーザーガイドの AWS アカウント 「ルートユーザー (コンソール) の仮想 MFA デバイス](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html)を有効にする」を参照してください。
**管理アクセスを持つユーザーを作成する**
1. IAM アイデンティティセンターを有効にします。
手順については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[AWS IAM アイデンティティセンターの有効化](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html)」を参照してください。
1. IAM アイデンティティセンターで、ユーザーに管理アクセスを付与します。
を ID ソース IAM アイデンティティセンターディレクトリ として使用する方法のチュートリアルについては、「 *AWS IAM アイデンティティセンター ユーザーガイド*」の[「デフォルトを使用してユーザーアクセスを設定する IAM アイデンティティセンターディレクトリ](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html)」を参照してください。
**管理アクセス権を持つユーザーとしてサインインする**
+ IAM アイデンティティセンターのユーザーとしてサインインするには、IAM アイデンティティセンターのユーザーの作成時に E メールアドレスに送信されたサインイン URL を使用します。
IAM Identity Center ユーザーを使用してサインインする方法については、*AWS サインイン 「 ユーザーガイド*[」の AWS 「 アクセスポータルにサインイン](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html)する」を参照してください。
**追加のユーザーにアクセス権を割り当てる**
1. IAM アイデンティティセンターで、最小特権のアクセス許可を適用するというベストプラクティスに従ったアクセス許可セットを作成します。
手順については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[アクセス許可セットを作成する](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html)」を参照してください。
1. グループにユーザーを割り当て、そのグループにシングルサインオンアクセス権を割り当てます。
手順については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[グループを追加する](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html)」を参照してください。
### ステップ 2: IDT 用のアクセス許可を設定する
このステップでは、IDT for がテストを実行し、IDT AWS IoT Greengrass 使用状況データを収集するために使用するアクセス許可を設定します。 AWS マネジメントコンソール または AWS Command Line Interface (AWS CLI) を使用して IDT の IAM ポリシーとテストユーザーを作成し、ユーザーにポリシーをアタッチできます。IDT 用のテストユーザーをすでに作成している場合は、「[IDT テストを実行するようにデバイスを設定する](device-config-setup.md)」または「[オプション: IDT for の Docker コンテナの設定 AWS IoT Greengrass](docker-config-setup.md)」に進みます。
+ [IDT 用のアクセス許可を設定するには (コンソール)](#configure-idt-permissions-console)
+ [IDT 用のアクセス許可を設定するには (AWS CLI)](#configure-idt-permissions-cli)
**IDT 用のアクセス許可を設定するには (コンソール)**
コンソールを使用して IDT for AWS IoT Greengrass用のアクセス許可を設定するには、次のステップに従ってください。
1. [IAM コンソール](https://console.aws.amazon.com/iam)にサインインします。
1. 特定のアクセス許可を持つロールを作成するためのアクセス許可を付与するカスタマー管理ポリシーを作成します。
1. ナビゲーションペインで **ポリシー**を選択してから **ポリシーの作成**を選択します。
1. **JSON** タブで、プレースホルダーコンテンツを以下のポリシーに置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ManageRolePoliciesForIDTGreengrass",
"Effect": "Allow",
"Action": [
"iam:DetachRolePolicy",
"iam:AttachRolePolicy"
],
"Resource": [
"arn:aws:iam::*:role/idt-*",
"arn:aws:iam::*:role/GreengrassServiceRole"
],
"Condition": {
"ArnEquals": {
"iam:PolicyARN": [
"arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy",
"arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess",
"arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
]
}
}
},
{
"Sid": "ManageRolesForIDTGreengrass",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:DeleteRole",
"iam:PassRole",
"iam:GetRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/idt-*",
"arn:aws:iam::123456789012:role/GreengrassServiceRole"
]
}
]
}
```
------
**重要**
次のポリシーは、IDT for AWS IoT Greengrassに必要なロールを作成および管理するためのアクセス許可を付与します。これには、次の AWS 管理ポリシーをアタッチするアクセス許可が含まれます。
[AWSGreengrassResourceAccessRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy)
[GreengrassOTAUpdateArtifactAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess)
[AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole)
1. [**Next: Tags (次へ: タグ)**] を選択します。
1. **[次へ: レビュー]** を選択します。
1. [**名前**] に**IDTGreengrassIAMPermissions**と入力してください。[**概要**] で、ポリシーによって付与されたアクセス許可を確認します。
1. [**Create policy**] (ポリシーの作成) を選択します。
1. IAM ユーザーを作成し、IDT for AWS IoT Greengrassに必要なアクセス許可をアタッチします。
1. IAM ユーザーを作成します。IAM ユーザーガイドの [IAM ユーザーの作成 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) のステップ 1 ～ 5 に従います。**
1. アクセス許可を IAM ユーザーにアタッチします。
1. **[Set permissions]** (許可を設定) ページで、**[Attach existing policies directly]** (既存のポリシーを直接アタッチする) を選択します。
1. 前のステップで作成した **IDTGreengrassIAMPermissions** ポリシーを検索します。チェックボックスをオンにします。
1. **AWSIoTDeviceTesterForGreengrassFullAccess** ポリシーを検索します。チェックボックスをオンにします。
**注記**
[AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess) は、IDT がテストに使用される AWS リソースを作成およびアクセスするために必要なアクセス許可を定義する AWS マネージドポリシーです。詳細については、「[AWS AWS IoT Device Tester の マネージドポリシー](#idt-managed-policy)」を参照してください。
1. [**Next: Tags**] (次へ: タグ) を選択します。
1. [**Next: Review**] (次へ: レビュー) を選択して、選択内容の概要を表示します。
1. **[ユーザーの作成]** を選択します。
1. ユーザーのアクセスキー (アクセスキー ID とシークレットアクセスキー) を表示するには、パスワードとアクセスキーの横にある [**Show (表示)**] を選択します。アクセスキーを保存するには、[**Download .csv**] を選択し、安全な場所にファイルを保存します。この情報を後で使用して、 AWS 認証情報ファイルを設定します。
1. 次のステップ: [物理デバイス](device-config-setup.md)を設定します。
**IDT 用のアクセス許可を設定するには (AWS CLI)**
を使用して IDT for のアクセス許可を設定するには AWS CLI 、次の手順に従います AWS IoT Greengrass。コンソールでアクセス許可をすでに設定している場合は、「[IDT テストを実行するようにデバイスを設定する](device-config-setup.md)」または「[オプション: IDT for の Docker コンテナの設定 AWS IoT Greengrass](docker-config-setup.md)」に進みます。
1. コンピュータで、まだインストールされていない場合 AWS CLI は、 をインストールして設定します。AWS Command Line Interface ユーザーガイドの [AWS CLIのインストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)のステップに従います。**
**注記**
AWS CLI は、コマンドラインシェルから サービスとやり取り AWS するために使用できるオープンソースツールです。
1. IDT と AWS IoT Greengrass ロールを管理するためのアクセス許可を付与するカスタマー管理ポリシーを作成します。
------
#### [ Linux, macOS, or Unix ]
```
aws iam create-policy --policy-name IDTGreengrassIAMPermissions --policy-document '{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ManageRolePoliciesForIDTGreengrass",
"Effect": "Allow",
"Action": [
"iam:DetachRolePolicy",
"iam:AttachRolePolicy"
],
"Resource": [
"arn:aws:iam::*:role/idt-*",
"arn:aws:iam::*:role/GreengrassServiceRole"
],
"Condition": {
"ArnEquals": {
"iam:PolicyARN": [
"arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy",
"arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess",
"arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
]
}
}
},
{
"Sid": "ManageRolesForIDTGreengrass",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:DeleteRole",
"iam:PassRole",
"iam:GetRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/idt-*",
"arn:aws:iam::123456789012:role/GreengrassServiceRole"
]
}
]
}'
```
------
#### [ Windows command prompt ]
```
aws iam create-policy --policy-name IDTGreengrassIAMPermissions --policy-document '{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"ManageRolePoliciesForIDTGreengrass\",\"Effect\": \"Allow\",\"Action\": [\"iam:DetachRolePolicy\", \"iam:AttachRolePolicy\"], \"Resource\": [\"arn:aws:iam::*:role/idt-*\",\"arn:aws:iam::*:role/GreengrassServiceRole\"],\"Condition\": {\"ArnEquals\": {\"iam:PolicyARN\": [\"arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy\",\"arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess\",\"arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole\"]}}},{\"Sid\": \"ManageRolesForIDTGreengrass\",\"Effect\": \"Allow\",\"Action\": [\"iam:CreateRole\",\"iam:DeleteRole\", \"iam:PassRole\", \"iam:GetRole\"],\"Resource\": [\"arn:aws:iam::*:role/idt-*\",\"arn:aws:iam::*:role/GreengrassServiceRole\"]}]}'
```
**注記**
このステップには、Linux、macOS、または Unix のターミナルコマンドとは異なる JSON 構文を使用するため、Windows コマンドプロンプトの例が含まれています。
------
1. IAM ユーザーを作成し、IDT for AWS IoT Greengrassに必要なアクセス許可をアタッチします。
1. IAM ユーザーを作成します。このセットアップ例では、ユーザーは `IDTGreengrassUser` という名前になります。
```
aws iam create-user --user-name IDTGreengrassUser
```
1. ステップ 2 で作成した `IDTGreengrassIAMPermissions` ポリシーを IAM ユーザーにアタッチします。コマンドの ** を の ID に置き換えます AWS アカウント。
```
aws iam attach-user-policy --user-name IDTGreengrassUser --policy-arn arn:aws:iam:::policy/IDTGreengrassIAMPermissions
```
1. `AWSIoTDeviceTesterForGreengrassFullAccess` ポリシーを IAM ユーザーにアタッチします。
```
aws iam attach-user-policy --user-name IDTGreengrassUser --policy-arn arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess
```
**注記**
[AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess) は、IDT がテストに使用される AWS リソースを作成およびアクセスするために必要なアクセス許可を定義する AWS マネージドポリシーです。詳細については、「[AWS AWS IoT Device Tester の マネージドポリシー](#idt-managed-policy)」を参照してください。
1. ユーザーのシークレットアクセスキーを作成します。
```
aws iam create-access-key --user-name IDTGreengrassUser
```
この出力は安全な場所に保存してください。後でこの情報を使用して認証情報 AWS ファイルを設定します。
1. 次のステップ: [物理デバイス](device-config-setup.md)を設定します。
## AWS AWS IoT Device Tester の マネージドポリシー
[AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess) 管理ポリシーにより、IDT はオペレーションを実行し、使用状況メトリクスを収集できます。このポリシーは以下の IDT アクセス許可を与えます。
+ `iot-device-tester:CheckVersion`。 AWS IoT Greengrass、テストスイート、および IDT バージョンのセットに互換性があるかどうかを確認します。
+ `iot-device-tester:DownloadTestSuite`。テストスイートをダウンロードします。
+ `iot-device-tester:LatestIdt`。ダウンロード可能な最新の IDT バージョンに関する情報を取得します。
+ `iot-device-tester:SendMetrics`。IDT がテストに関して収集する使用状況データを公開します。
+ `iot-device-tester:SupportedVersion`。 IDT でサポートされている AWS IoT Greengrass およびテストスイートのバージョンのリストを取得します。この情報は、コマンドラインウィンドウに表示されます。
# IDT テストを実行するようにデバイスを設定する
デバイスを設定するには、 AWS IoT Greengrass 依存関係をインストールし、 AWS IoT Greengrass Core ソフトウェアを設定し、デバイスにアクセスするようにホストコンピュータを設定し、デバイスに対するユーザーアクセス許可を設定する必要があります。
## テスト対象のデバイスへの AWS IoT Greengrass 依存関係を検証する
IDT for AWS IoT Greengrass がデバイスをテストする前に、[「 の開始方法 AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/latest/developerguide/gg-gs.html)」の説明に従ってデバイスをセットアップしていることを確認してください。サポートされているプラットフォームについては、「[サポートされているプラットフォーム](https://docs.aws.amazon.com/greengrass/latest/developerguide/what-is-gg.html#gg-platforms)」を参照してください。
## AWS IoT Greengrass ソフトウェアを設定する
IDT for は、特定のバージョンの との互換性についてデバイスを AWS IoT Greengrass テストします AWS IoT Greengrass。IDT には、デバイスでテストするための 2 AWS IoT Greengrass つのオプションがあります。
+ [AWS IoT Greengrass Core ソフトウェア](what-is-gg.md#gg-core-download-tab)のバージョンをダウンロードして使用します。IDT によってソフトウェアがインストールされます。
+ デバイスに既にインストールされている AWS IoT Greengrass Core ソフトウェアのバージョンを使用します。
**注記**
の各バージョンには、対応する IDT バージョン AWS IoT Greengrass があります。 AWS IoT Greengrass 使用している のバージョンに対応する IDT のバージョンをダウンロードする必要があります。
以下のセクションでは、これらについて説明します。1 度のみ実行してください。
### オプション 1: AWS IoT Greengrass Core ソフトウェアをダウンロードし、それを使用するように AWS IoT Device Tester を設定する
AWS IoT Greengrass Core ソフトウェアのダウンロードページから [AWS IoT Greengrass Core ソフトウェア](what-is-gg.md#gg-core-download-tab)をダウンロードできます。
1. 適切なアーキテクチャと Linux ディストリビューションを見つけ、[**ダウンロード**] を選択します。
1. tar.gz ファイルを `/products/greengrass/ggc` にコピーします。
**注記**
AWS IoT Greengrass tar.gz ファイルの名前を変更しないでください。同じオペレーティングシステムとアーキテクチャのこのディレクトリに複数のファイルを配置しないでください。たとえば、`greengrass-linux-armv7l-1.7.1.tar.gz` および `greengrass-linux-armv7l-1.8.1.tar.gz` のファイルをいずれもそのディレクトリに置くと、テストが失敗する原因になります。
### オプション 2: AWS IoT Device Tester AWS IoT Greengrass で の既存のインストールを使用する
`/configs` フォルダの `device.json` ファイルに `greengrassLocation` 属性を追加して、デバイスにインストールされている AWS IoT Greengrass Core ソフトウェアをテストするように IDT を設定します。例えば、次のようになります。
```
"greengrassLocation" : ""
```
`device.json` ファイルの詳細については、「[device.json の設定](set-config.md#device-config)」を参照してください。
Linux デバイスの場合、 AWS IoT Greengrass Core ソフトウェアのデフォルトの場所は です`/greengrass`。
**注記**
デバイスには、起動されていない AWS IoT Greengrass Core ソフトウェアがインストールされている必要があります。
`ggc_user` ユーザーおよび `ggc_group` がデバイスに追加されていることを確認します。詳細については、「[AWS IoT Greengrassの環境設定](https://docs.aws.amazon.com/greengrass/latest/developerguide/module1.html)」を参照してください。
## テスト対象デバイスにアクセスするようにホストコンピュータを設定する
IDT はホストコンピュータで動作し、SSH を使用してデバイスに接続できる必要があります。IDT がテスト対象のデバイスへの SSH アクセスを許可するには、2 つのオプションがあります。
1. こちらの手順に従って SSH キーペアを作成し、パスワードを指定せずにテスト対象のデバイスにサインインすることをキーに承認します。
1. `device.json` ファイルに各デバイスのユーザー名とパスワードを入力します。詳細については、「[device.json の設定](set-config.md#device-config)」を参照してください。
任意の SSL 実装を使用して SSH キーを作成できます。次の手順は、[SSH-KEYGEN](https://www.ssh.com/ssh/keygen/) または [PuTTYgen](https://www.ssh.com/ssh/putty/windows/puttygen) (Windows の場合) を使用する方法を示しています。別の SSL 実装を使用する場合は、その実装に関するドキュメントを参照してください。
テスト対象デバイスで認証するには、IDT で SSH キーを使用します。
**SSH-KEYGEN を使用して SSH キーを作成するには**
1. SSH キーを作成します。
OpenSSH **ssh-keygen** コマンドを使用して SSH キーペアを作成できます。ホストコンピュータに SSH キーペアがすでにある場合は、IDT 専用の SSH キーペアを作成することをお勧めします。こうすることで、テストを完了した後、ホストコンピュータはパスワードを入力しないとデバイスに接続できなくなります。また、リモートデバイスへのアクセスを必要なユーザーのみに制限することもできます。
**注記**
Windows に SSH クライアントがインストールされていません。Windows での SSH クライアントのインストールについては、「[SSH クライアントソフトウェアをダウンロードする](https://www.ssh.com/ssh/#sec-Download-client-software)」を参照してください。
**ssh-keygen** コマンドは、キーペアを保存する名前とパスの入力を求めます。デフォルトでは、キーペアファイルの名前は `id_rsa` (プライベートキー) と `id_rsa.pub` (パブリックキー) です。macOS および Linux の場合、これらのファイルのデフォルトの場所は `~/.ssh/` です。Windows の場合、デフォルトの場所は `C:\Users\\.ssh` です。
プロンプトが表示されたら、SSH キーを保護するキーフレーズを入力します。詳細については、「[新しい SSH キーを生成する](https://www.ssh.com/ssh/keygen/)」を参照してください。
1. テスト対象デバイスに承認済み SSH キーを追加します。
IDT で SSH プライベートキーを使用して、テスト対象デバイスにサインインする必要があります。SSH プライベートキーがテスト対象デバイスにサインインすることを承認するには、ホストコンピュータから **ssh-copy-id** コマンドを使用します。このコマンドは、テスト対象デバイスの `~/.ssh/authorized_keys` ファイルにパブリックキーを追加します。例:
**\$1 ssh-copy-id **@****
*remote-ssh-user* は、テスト対象デバイスへのサインインに使用するユーザー名です。*remote-device-ip* は、テスト対象デバイスの IP アドレスです。例:
**ssh-copy-id pi@192.168.1.5**
プロンプトが表示されたら、**ssh-copy-id** コマンドで指定したユーザー名に対応するパスワードを入力します。
**ssh-copy-id** では、パブリックキー名が `id_rsa.pub` で、デフォルトの保存先が `~/.ssh/` (macOS と Linux の場合) または `C:\Users\\.ssh` (Windows の場合) であるとみなされます。パブリックキーに別の名前や別の保存先を指定した場合は、**ssh-copy-id** で **-i** オプションを使用し、SSH 公開鍵への完全修飾パス (**ssh-copy-id -i \$1/my/path/myKey.pub** など) を指定する必要があります。SSH キーの作成とパブリックキーのコピーの詳細については、「[SSH-COPY-ID](https://www.ssh.com/ssh/copy-id)」を参照してください。
**PuTTYgen を使用して SSH キーを作成するには (Windows のみ)**
1. テスト対象デバイスに OpenSSH サーバーとクライアントがインストールされていることを確認します。詳細については、「[OpenSSH](https://www.openssh.com/)」を参照してください。
1. テスト対象のデバイスに [PuTTYgen](https://www.puttygen.com/) をインストールします。
1. PuTTYGen を開きます。
1. [**Generate**] を選択し、ボックス内にマウスカーソルを移動してプライベートキーを生成します。
1. [**Conversions**] メニューから [**Export OpenSSH key**] を選択し、プライベートキーに `.pem` ファイル拡張子を付けて保存します。
1. テスト対象デバイスの `/home//.ssh/authorized_keys` ファイルにパブリックキーを追加します。
1. PuTTYgen ウィンドウからパブリックキーテキストをコピーします。
1. PuTTY を使用して、テスト対象のデバイスでセッションを作成します。
1. コマンドプロンプトまたは Windows Powershell ウィンドウから、次のコマンドを実行します。
**C:/**/putty.exe -ssh **@****
1. プロンプトが表示されたら、デバイスのパスワードを入力します。
1. vi などのテキストエディタを使用して、テスト対象のデバイスの `/home//.ssh/authorized_keys` ファイルにパブリックキーを追加します。
1. `device.json` ファイルを、ユーザー名、IP アドレス、およびテスト対象の各デバイスのホストコンピュータに保存したプライベートキーファイルへのパスで更新します。詳細については、「[device.json の設定](set-config.md#device-config)」を参照してください。必ずプライベートキーの完全パスとファイル名を指定し、スラッシュ (「/」) を使用してください。たとえば、Windows パス `C:\DT\privatekey.pem` の場合は、`device.json` ファイルで `C:/DT/privatekey.pem` を使用します。
## デバイスに対するユーザーのアクセス許可を設定する
IDT は、テスト対象デバイスのさまざまなディレクトリやファイルに対してオペレーションを実行します。このようなオペレーションの中には、高いアクセス許可が必要な場合があります (**sudo** を使用)。これらのオペレーションを自動化するには、IDT for がパスワードの入力を求められることなく sudo でコマンドを実行できる AWS IoT Greengrass 必要があります。
パスワードの入力を求めることなく、sudo にアクセスを許可するには、テスト対象デバイスで以下の手順を実行します。
**注記**
`username` は、テスト対象デバイスにアクセスするために IDT で使用する SSH ユーザーを指します。
**ユーザーを sudo グループに追加するには**
1. テスト対象のデバイスで、`sudo usermod -aG sudo ` を実行します。
1. サインアウトし、再度サインインして、変更を反映します。
1. ユーザー名が正常に追加されたことを確認するには、**sudo echo test** を実行します。パスワードの入力を要求されない場合、ユーザーは正しく設定されています。
1. `/etc/sudoers` ファイルを開き、ファイルの末尾に次の行を追加します:
` ALL=(ALL) NOPASSWD: ALL`
## オプション機能をテストするためのデバイスの設定
以下のトピックでは、オプション機能の IDT テストを実行するようにデバイスを設定する方法について説明します。これらの機能をテストする場合のみ、以下の設定手順に従ってください。それ以外の場合は、「[認定スイートを実行するように IDT AWS IoT Greengrass 設定を構成する](set-config.md)」に進みます。
**Topics**
+ [
## テスト対象のデバイスへの AWS IoT Greengrass 依存関係を検証する
](#install-gg-dependencies)
+ [
## AWS IoT Greengrass ソフトウェアを設定する
](#config-gg)
+ [
## テスト対象デバイスにアクセスするようにホストコンピュータを設定する
](#configure-host)
+ [
## デバイスに対するユーザーのアクセス許可を設定する
](#root-access)
+ [
## オプション機能をテストするためのデバイスの設定
](#optional-feature-config)
+ [
# オプション: IDT for の Docker コンテナの設定 AWS IoT Greengrass
](docker-config-setup.md)
+ [
# オプション: ML 認定のためのデバイスの設定
](idt-ml-qualification.md)
# オプション: IDT for の Docker コンテナの設定 AWS IoT Greengrass
AWS IoT Greengrass は、Docker コンテナで AWS IoT Greengrass Core ソフトウェアを簡単に実行できるようにする Docker イメージと Dockerfile を提供します。 AWS IoT Greengrass コンテナを設定したら、IDT テストを実行できます。現在、IDT for AWS IoT Greengrassを実行するためにサポートされているアーキテクチャは x86\$164 Docker のみです。
この機能を使用するには、IDT v2.3.0 以降が必要です。
IDT テストを実行するように Docker コンテナを設定するプロセスは、 が提供する Docker イメージと Dockerfile のどちらを使用するかによって異なります AWS IoT Greengrass。
+ [Docker イメージを使用する](#docker-config-setup-docker-image)。Docker イメージには AWS IoT Greengrass Core ソフトウェアと依存関係がインストールされています。
+ [Dockerfile を使用する](#docker-config-setup-dockerfile)。Dockerfile には、カスタム AWS IoT Greengrass コンテナイメージの構築に使用できるソースコードが含まれています。イメージは、別のプラットフォームアーキテクチャで実行できるようにするため、またはイメージサイズを縮小するために変更できます。
**注記**
AWS IoT Greengrass は、 AWS IoT Greengrass コアソフトウェアバージョン 1.11.1 の Dockerfile または Docker イメージを提供しません。独自のカスタムコンテナイメージで IDT テストを実行するには、イメージに が提供する Dockerfile で定義されている依存関係が含まれている必要があります AWS IoT Greengrass。
Docker コンテナ AWS IoT Greengrass で を実行する場合、次の機能は利用できません。
+ **[Greengrass container]** (Greengrass コンテナ) モードで実行される[コネクタ](connectors.md)。Docker コンテナでコネクタを実行するには、コネクタを**コンテナなし**モードで実行する必要があります。**コンテナなし**モードをサポートするコネクタを検索するには、「[AWSが提供する Greengrass コネクタ](connectors-list.md)」を参照してください。これらのコネクタの一部では、分離モードパラメータを使用されており、[**コンテナなし**] に設定する必要があります。
+ [ローカルデバイスおよびボリュームリソース](access-local-resources.md)。Docker コンテナで実行されるユーザー定義 Lambda 関数は、コア上のデバイスとボリュームに直接アクセスする必要があります。
## が提供する Docker イメージを設定する AWS IoT Greengrass
IDT テストを実行するように AWS IoT Greengrass Docker イメージを設定するには、次の手順に従います。
**前提条件**
このチュートリアルを開始する前に、以下を実行する必要があります。
+ 選択した AWS Command Line Interface （AWS CLI) バージョンに基づいて、ホストコンピュータに次のソフトウェアとバージョンをインストールする必要があります。
------
#### [ AWS CLI version 2 ]
+ [Docker](https://docs.docker.com/install/) バージョン 18.09 以降。以前のバージョンでも動作する可能性がありますが、18.09 以降を推奨します。
+ AWS CLI バージョン 2.0.0 以降。
+ AWS CLI バージョン 2 をインストールするには、[「バージョン 2 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)のインストール」を参照してください。
+ を設定するには AWS CLI、[「 の設定 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)」を参照してください。
**注記**
Windows コンピュータで新しい AWS CLI バージョン 2 にアップグレードするには、[MSI のインストール](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-windows.html)プロセスを繰り返す必要があります。
------
#### [ AWS CLI version 1 ]
+ [Docker](https://docs.docker.com/install/) バージョン 18.09 以降。以前のバージョンでも動作する可能性がありますが、18.09 以降を推奨します。
+ [Python](https://www.python.org/downloads/) バージョン 3.6 以降。
+ [pip](https://pip.pypa.io/en/stable/installing) バージョン 18.1 以降。
+ AWS CLI バージョン 1.17.10 以降
+ AWS CLI バージョン 1 をインストールするには、[「バージョン 1 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html)のインストール」を参照してください。
+ を設定するには AWS CLI、[「 の設定 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)」を参照してください。
+ バージョン 1 AWS CLI の最新バージョンにアップグレードするには、次のコマンドを実行します。
```
pip install awscli --upgrade --user
```
**注記**
Windows で AWS CLI バージョン 1 の [MSI インストール](https://docs.aws.amazon.com/cli/latest/userguide/install-windows.html#msi-on-windows)を使用する場合は、次の点に注意してください。
AWS CLI バージョン 1 のインストールで botocore のインストールに失敗する場合は、[Python と pip のインストール](https://docs.aws.amazon.com/cli/latest/userguide/awscli-install-windows.html#awscli-install-windows-pip)を試してください。
新しい AWS CLI バージョン 1 にアップグレードするには、MSI のインストールプロセスを繰り返す必要があります。
------
+ ユーザーが Amazon Elastic Container Registry (Amazon ECR) のリソースにアクセスできるようにするには、次のアクセス権限を付与する必要があります。
+ Amazon ECR では、レジストリに対して認証し、Amazon ECR リポジトリからイメージをプッシュまたはプルする前に、 AWS Identity and Access Management (IAM) ポリシーを通じてアクセス`ecr:GetAuthorizationToken`許可を付与する必要があります。詳細については、「Amazon ECR ユーザーガイド」の「[Amazon ECR Repository Policy Examples](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policy-examples.html)」(Amazon ECR リポジトリポリシーの例) および「[1 つの Amazon ECR リポジトリにアクセスする](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-access-one-bucket)」を参照してください。
1. Docker イメージをダウンロードし、コンテナを設定します。[Docker Hub](https://hub.docker.com/r/amazon/aws-iot-greengrass) または [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) (Amazon ECR) から作成済みのイメージをダウンロードして、Windows、macOS、および Linux (x86\$164) プラットフォームで実行できます。
Amazon ECR から Docker イメージをダウンロードするには、「[ステップ 1: Amazon ECR から AWS IoT Greengrass コンテナイメージを取得する](run-gg-in-docker-container.md#docker-pull-image)」のすべてのステップを実行します。次に、このトピックに戻って設定を続行します。
1. Linux ユーザーのみ: IDT を実行するユーザーに Docker コマンドを実行するアクセス許可があることを確認してください。詳細については、Docker ドキュメントの「[Docker を非ルートユーザーとして管理する](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user)」を参照してください。
1. AWS IoT Greengrass コンテナを実行するには、オペレーティングシステムの コマンドを使用します。
------
#### [ Linux ]
```
docker run --rm --init -it -d --name aws-iot-greengrass \
-p 8883:8883 \
-v : \
:
```
+ ** はホストのカーネル設定ファイルへのパスに置き換え、** はコンテナ内でボリュームがマウントされているパスに置き換えます。
ホストのカーネル設定ファイルは、通常、`/proc/config.gz` または `/boot/config-` にあります。`uname -r` を実行して ** 値を検索できます。
**例:** 設定ファイルを `/boot/config-` からマウントするには
```
-v /boot/config-4.15.0-74-generic:/boot/config-4.15.0-74-generic \
```
**例:** 設定ファイルを `proc/config.gz` からマウントするには
```
-v /proc/config.gz:/proc/config.gz \
```
+ コマンドの **:** は、リポジトリの名前とターゲットイメージのタグに置き換えます。
**例：** AWS IoT Greengrass Core ソフトウェアの最新バージョンを参照するには
```
216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
Docker AWS IoT Greengrass イメージのリストを取得するには、次のコマンドを実行します。
```
aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass
```
------
#### [ macOS ]
```
docker run --rm --init -it -d --name aws-iot-greengrass \
-p 8883:8883 \
:
```
+ コマンドの **:** は、リポジトリの名前とターゲットイメージのタグに置き換えます。
**例：** AWS IoT Greengrass Core ソフトウェアの最新バージョンを参照するには
```
216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
Docker AWS IoT Greengrass イメージのリストを取得するには、次のコマンドを実行します。
```
aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass
```
------
#### [ Windows ]
```
docker run --rm --init -it -d --name aws-iot-greengrass \
-p 8883:8883 \
:
```
+ コマンドの **:** は、リポジトリの名前とターゲットイメージのタグに置き換えます。
**例：** AWS IoT Greengrass Core ソフトウェアの最新バージョンを参照するには
```
216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
Docker AWS IoT Greengrass イメージのリストを取得するには、次のコマンドを実行します。
```
aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass
```
------
**重要**
IDT でテストする場合は、イメージの実行に使用される `--entrypoint /greengrass-entrypoint.sh \`引数を汎用に含めないでください AWS IoT Greengrass 。
1. 次のステップ: [AWS 認証情報と `device.json` ファイル](set-config.md)を設定します。
## が提供する dockerfile を設定する AWS IoT Greengrass
IDT テストを実行するように Dockerfile から構築された Docker AWS IoT Greengrass イメージを設定するには、次の手順に従います。
1. [AWS IoT Greengrass Docker ソフトウェア](what-is-gg.md#gg-docker-download) からホストコンピュータに Dockerfile パッケージをダウンロードして解凍します。
1. `README.md` を開きます。次の 3 つのステップでは、このファイルのセクションを参照します。
1. 「**前提条件**」セクションの要件を満たしていることを確認します。
1. Linux ユーザーのみ: 「**シンボリックリンク保護とハードリンク保護を有効にする**」ステップと「**IPv4 ネットワーク転送を有効にする**」ステップを完了します。
1. Docker イメージを構築するには、**ステップ 1 のすべての手順を完了させます。Docker AWS IoT Greengrass イメージを構築します**。次に、このトピックに戻って設定を続行します。
1. AWS IoT Greengrass コンテナを実行するには、オペレーティングシステムの コマンドを使用します。
------
#### [ Linux ]
```
docker run --rm --init -it -d --name aws-iot-greengrass \
-p 8883:8883 \
-v : \
:
```
+ ** はホストのカーネル設定ファイルへのパスに置き換え、** はコンテナ内でボリュームがマウントされているパスに置き換えます。
ホストのカーネル設定ファイルは、通常、`/proc/config.gz` または `/boot/config-` にあります。`uname -r` を実行して ** 値を検索できます。
**例:** 設定ファイルを `/boot/config-` からマウントするには
```
-v /boot/config-4.15.0-74-generic:/boot/config-4.15.0-74-generic \
```
**例:** 設定ファイルを `proc/config.gz` からマウントするには
```
-v /proc/config.gz:/proc/config.gz \
```
+ コマンドの **:** は、リポジトリの名前とターゲットイメージのタグに置き換えます。
**例：** AWS IoT Greengrass Core ソフトウェアの最新バージョンを参照するには
```
216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
Docker AWS IoT Greengrass イメージのリストを取得するには、次のコマンドを実行します。
```
aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass
```
------
#### [ macOS ]
```
docker run --rm --init -it -d --name aws-iot-greengrass \
-p 8883:8883 \
:
```
+ コマンドの **:** は、リポジトリの名前とターゲットイメージのタグに置き換えます。
**例：** AWS IoT Greengrass Core ソフトウェアの最新バージョンを参照するには
```
216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
Docker AWS IoT Greengrass イメージのリストを取得するには、次のコマンドを実行します。
```
aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass
```
------
#### [ Windows ]
```
docker run --rm --init -it -d --name aws-iot-greengrass \
-p 8883:8883 \
:
```
+ コマンドの **:** は、リポジトリの名前とターゲットイメージのタグに置き換えます。
**例：** AWS IoT Greengrass Core ソフトウェアの最新バージョンを参照するには
```
216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
Docker AWS IoT Greengrass イメージのリストを取得するには、次のコマンドを実行します。
```
aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass
```
------
**重要**
IDT でテストする場合は、イメージの実行に使用される `--entrypoint /greengrass-entrypoint.sh \`引数を汎用に含めないでください AWS IoT Greengrass 。
1. 次のステップ: [AWS 認証情報と `device.json` ファイル](set-config.md)を設定します。
## IDT for の Docker コンテナ設定のトラブルシューティング AWS IoT Greengrass
以下の情報は、IDT 用の Docker コンテナを AWS IoT Greengrass テスト用に実行する際の問題のトラブルシューティングに役立ちます。
### 警告: 設定ファイルの読み込みエラー: /home/user/.docker/config.json - stat /home//.docker/config.json: アクセス許可が拒否されました
Linux で `docker` コマンドの実行中にこのエラーが発生した場合は、次のコマンドを実行します。次のコマンドの ** は、IDT を実行するユーザーに置き換えます。
```
sudo chown : /home//.docker -R
sudo chmod g+rwx /home//.docker -R
```
# オプション: ML 認定のためのデバイスの設定
IDT for AWS IoT Greengrass は、機械学習 (ML) 認定テストを提供し、デバイスがクラウドでトレーニングされたモデルを使用してローカルで ML 推論を実行できることを検証します。
ML 認定テストを実行するには、まず、「[IDT テストを実行するようにデバイスを設定する](device-config-setup.md)」の説明に従ってデバイスを設定する必要があります。次に、このトピックの手順に従って、実行する ML フレームワークの依存関係をインストールします。
ML 認定のためのテストを実行するには、IDT v3.1.0 以降が必要です。
## ML フレームワークの依存関係のインストール
ML フレームワークの依存関係はすべて、`/usr/local/lib/python3.x/site-packages` ディレクトリ以下にインストールする必要があります。確実に正しいディレクトリにインストールするには、依存関係をインストールするときに `sudo` root アクセス許可を使用することをお勧めします。仮想環境は、認定テストではサポートされていません。
**注記**
[コンテナ化](lambda-group-config.md#lambda-containerization-considerations)を使用して実行される Lambda 関数を (**Greengrass コンテナ**モードで) テストしている場合、`/usr/local/lib/python3.x` で Python ライブラリのシンボリックリンクを作成することはサポートされていません。エラーを回避するには、依存関係を正しいディレクトリにインストールする必要があります。
ターゲットフレームワークの依存関係をインストールするには、以下のステップに従います。
+ [MXNet 依存関係のインストール](#ml-qualification-mxnet-dependencies)
+ [TensorFlow の依存関係のインストール](#ml-qualification-tensorflow-dependencies)
+ [DLR 依存関係のインストール](#ml-qualification-dlr-dependencies)
## Apache MXNet 依存関係のインストール
このフレームワークの IDT 認定テストには、次の依存関係があります。
+ Python 3.6 or Python 3.7。
**注記**
Python 3.6を使用している場合は、Python 3.7 からPython 3.6 バイナリへのシンボリックリンクを作成する必要があります。これにより、 AWS IoT Greengrassの Python 要件を満たすようにデバイスが設定されます。以下に例を示します。
```
sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7
```
+ Apache MXNet v1.2.1 以降。
+ NumPy。MXNet バージョンと互換性があるバージョンのものをしようする必要があります。
### MXNet のインストール
MXNet のドキュメントの指示に従って、[MXNet をインストールします](https://mxnet.apache.org/get_started/?platform=linux&language=python&processor=cpu&environ=pip&)。
**注記**
Python 2.x と Python 3.x の両方がデバイスにインストールされている場合は、実行するコマンドで Python 3.x を使用して依存関係をインストールします。
### MXNet のインストールの検証
次のいずれかのオプションを選択して、MXNet のインストールを検証します。
#### オプション 1: デバイスに SSH 接続してスクリプトを実行する
1. デバイスに SSH 接続します。
1. 次のスクリプトを実行して、依存関係が正しくインストールされていることを確認します。
```
sudo python3.7 -c "import mxnet; print(mxnet.__version__)"
```
```
sudo python3.7 -c "import numpy; print(numpy.__version__)"
```
出力ではバージョン番号が表示されまます。スクリプトがエラーなく終了する必要があります。
#### オプション 2: IDT 依存関係テストを実行する
1. `device.json` が ML 認定用に設定されていることを確認します。詳細については、「[ML 認定のための device.json の設定](set-config.md#device-json-ml-qualification)」を参照してください。
1. フレームワークの依存関係テストを実行します。
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id mxnet_dependency_check
```
テストサマリーに、`mldependencies` の結果として `PASSED` が表示されます。
## TensorFlow の依存関係のインストール
このフレームワークの IDT 認定テストには、次の依存関係があります。
+ Python 3.6 or Python 3.7。
**注記**
Python 3.6を使用している場合は、Python 3.7 からPython 3.6 バイナリへのシンボリックリンクを作成する必要があります。これにより、 AWS IoT Greengrassの Python 要件を満たすようにデバイスが設定されます。以下に例を示します。
```
sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7
```
+ TensorFlow 1.x。
### TensorFlow のインストール
TensorFlow のドキュメントの指示に従い、[pip](https://www.tensorflow.org/install/pip) または[ソース](https://www.tensorflow.org/install/source)を使用して、TensorFlow 1.x をインストールします。
**注記**
Python 2.x と Python 3.x の両方がデバイスにインストールされている場合は、実行するコマンドで Python 3.x を使用して依存関係をインストールします。
### TensorFlow のインストールの検証
次のいずれかのオプションを選択して、TensorFlow のインストールを検証します。
#### オプション1：デバイスに SSH 接続してスクリプトを実行する
1. デバイスに SSH 接続します。
1. 次のスクリプトを実行して、依存関係が正しくインストールされていることを確認します。
```
sudo python3.7 -c "import tensorflow; print(tensorflow.__version__)"
```
出力ではバージョン番号が表示されまます。スクリプトがエラーなく終了する必要があります。
#### オプション 2: IDT 依存関係テストを実行する
1. `device.json` が ML 認定用に設定されていることを確認します。詳細については、「[ML 認定のための device.json の設定](set-config.md#device-json-ml-qualification)」を参照してください。
1. フレームワークの依存関係テストを実行します。
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id tensorflow_dependency_check
```
テストサマリーに、`mldependencies` の結果として `PASSED` が表示されます。
## Amazon SageMaker AI Neo Deep Learning Runtime (DLR) の依存関係をインストールする
このフレームワークの IDT 認定テストには、次の依存関係があります。
+ Python 3.6 or Python 3.7。
**注記**
Python 3.6を使用している場合は、Python 3.7 からPython 3.6 バイナリへのシンボリックリンクを作成する必要があります。これにより、 AWS IoT Greengrassの Python 要件を満たすようにデバイスが設定されます。以下に例を示します。
```
sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7
```
+ SageMaker AI Neo DLR。
+ numpy。
DLR テストの依存関係をインストールした後、[モデルをコンパイル](#ml-qualification-dlr-compile-model)する必要があります。
### DLR のインストール
DLR のドキュメントの指示に従って、[Neo DLR をインストールします](https://neo-ai-dlr.readthedocs.io/en/latest/install.html#building-on-linux)。
**注記**
Python 2.x と Python 3.x の両方がデバイスにインストールされている場合は、実行するコマンドで Python 3.x を使用して依存関係をインストールします。
### DLR のインストールの検証
次のいずれかのオプションを選択して、DLR のインストールを検証します。
#### オプション 1: デバイスに SSH 接続してスクリプトを実行する
1. デバイスに SSH 接続します。
1. 次のスクリプトを実行して、依存関係が正しくインストールされていることを確認します。
```
sudo python3.7 -c "import dlr; print(dlr.__version__)"
```
```
sudo python3.7 -c "import numpy; print(numpy.__version__)"
```
出力ではバージョン番号が表示されまます。スクリプトがエラーなく終了する必要があります。
#### オプション 2: IDT 依存関係テストを実行する
1. `device.json` が ML 認定用に設定されていることを確認します。詳細については、「[ML 認定のための device.json の設定](set-config.md#device-json-ml-qualification)」を参照してください。
1. フレームワークの依存関係テストを実行します。
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id dlr_dependency_check
```
テストサマリーに、`mldependencies` の結果として `PASSED` が表示されます。
## DLR モデルのコンパイル
DLR モデルは、ML 認定テストに使用する前にコンパイルする必要があります。手順については、次のいずれかのオプションを選択します。
### オプション 1: Amazon SageMaker AI を使用してモデルをコンパイルする
SageMaker AI を使用して IDT が提供する ML モデルをコンパイルするには、次の手順に従います。このモデルは Apache MXnet で事前にトレーニングされています。
1. デバイスタイプが SageMaker AI でサポートされていることを確認します。詳細については、*Amazon SageMaker AI API リファレンス*の[ターゲットデバイスオプション](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_OutputConfig.html#sagemaker-Type-OutputConfig-TargetDevice)を参照してください。デバイスタイプが現在 SageMaker AI でサポートされていない場合は、「」の手順に従ってください[オプション 2: TVM を使用して DLR をコンパイルする](#ml-qualification-compile-dlr-option-2)。
**注記**
SageMaker AI でコンパイルされたモデルで DLR テストを実行するには、4 分または 5 分かかる場合があります。この間、IDT を停止しないでください。
1. 事前トレーニング済みでコンパイルされていない DLR 用 MxNet モデルを含む tarball ファイルをダウンロードします。
+ [dlr-noncompiled-model-1.0.tar.gz](https://docs.aws.amazon.com/greengrass/latest/developerguide/download-dlr-noncompiled-model-1.0.html)
1. tarball を解凍します。このコマンドを実行すると、以下のディレクトリ構造が生成されます。
![\[resnet18 ディレクトリには 3 つのファイルが含まれています。\]](http://docs.aws.amazon.com/ja_jp/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-uncompiled.png)
1. `synset.txt` を `resnet18` ディレクトリ以外の場所に移動します。新しい場所を書き留めておきます。このファイルは、コンパイルされたモデルのディレクトリに、後でコピーします。
1. `resnet18` ディレクトリの内容を圧縮します。
```
tar cvfz model.tar.gz resnet18v1-symbol.json resnet18v1-0000.params
```
1. 圧縮ファイルを の Amazon S3 バケットにアップロードし AWS アカウント、[「モデルをコンパイルする (コンソール）](https://docs.aws.amazon.com/sagemaker/latest/dg/neo-job-compilation-console.html)」の手順に従ってコンパイルジョブを作成します。
1. [**入力設定**] では、次の値を使用します。
+ [**データ入力設定**] に `{"data": [1, 3, 224, 224]}` と入力します。
+ [**機械学習フレームワーク**] で、`MXNet` を選択します。
1. [**出力設定**] では、次の値を使用します。
+ **[S3 Output location]** (S3 出力場所) には、コンパイル済みモデルを保存する Amazon S3 バケットまたはフォルダへのパスを入力します。
+ [**ターゲットデバイス**] で、デバイスタイプを選択します。
1. 指定した出力場所からコンパイル済みモデルをダウンロードし、ファイルを解凍します。
1. コンパイル済みモデルのディレクトリに `synset.txt` をコピーします。
1. コンパイル済みモデルのディレクトリの名前を `resnet18` に変更します。
コンパイル済みモデルのディレクトリでは、次のディレクトリ構造が必要です。
![\[コンパイル済みモデルのディレクトリ resnet18 には、4 つのファイルが含まれています。\]](http://docs.aws.amazon.com/ja_jp/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-compiled-sm.png)
### オプション 2: TVM を使用して DLR をコンパイルする
TVM を使用して、IDT によって提供される ML モデルをコンパイルするには、以下のステップに従います。このモデルは Apache MXNet で事前にトレーニングされているため、モデルをコンパイルするコンピューターまたはデバイスに MXNet をインストールする必要があります。MXNet をインストールするには、[MXNet のドキュメント](https://mxnet.apache.org/get_started/?platform=linux&language=python&processor=cpu&environ=pip&)の指示に従います。
**注記**
ターゲットデバイス上でモデルをコンパイルすることをお勧めします。この方法はオプションですが、互換性を確保し、潜在的な問題を軽減するために役立ちます。
1. 事前トレーニング済みでコンパイルされていない DLR 用 MxNet モデルを含む tarball ファイルをダウンロードします。
+ [dlr-noncompiled-model-1.0.tar.gz](https://docs.aws.amazon.com/greengrass/latest/developerguide/download-dlr-noncompiled-model-1.0.html)
1. tarball を解凍します。このコマンドを実行すると、以下のディレクトリ構造が生成されます。
![\[resnet18 ディレクトリには 3 つのファイルが含まれています。\]](http://docs.aws.amazon.com/ja_jp/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-uncompiled.png)
1. TVM のドキュメントの指示に従って、[お使いのプラットフォームのソースから TVM のビルドとインストール](https://docs.tvm.ai/install/from_source.html)を行います。
1. TVM がビルドされたら、resnet18 モデルの TVM コンパイルを実行します。以下のステップは、TVM のドキュメントの「[Quick Start Tutorial for Compiling Deep Learning Models](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#sphx-glr-tutorials-get-started-relay-quick-start-py)」に基づいています。
1. クローン作成された TVM リポジトリから `relay_quick_start.py` ファイルを開きます。
1. [リレーでニューラルネットワークを定義する](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#define-neural-network-in-relay)コードを更新します。次のいずれかのオプションを使用できます。
+ オプション 1: `mxnet.gluon.model_zoo.vision.get_model` を使用してリレーモジュールとパラメータを取得します。
```
from mxnet.gluon.model_zoo.vision import get_model
block = get_model('resnet18_v1', pretrained=True)
mod, params = relay.frontend.from_mxnet(block, {"data": data_shape})
```
+ オプション 2: ステップ 1 でダウンロードしたコンパイルされていないモデルから、以下のファイルを`relay_quick_start.py` ファイルと同じディレクトリにコピーします。これらのファイルには、リレーモジュールとパラメータが含まれています。
+ `resnet18v1-symbol.json`
+ `resnet18v1-0000.params`
1. [コンパイル済みモジュールを保存してロードする](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#save-and-load-compiled-module)コードを更新し、次のコードを使用します。
```
from tvm.contrib import util
path_lib = "deploy_lib.so"
# Export the model library based on your device architecture
lib.export_library("deploy_lib.so", cc="aarch64-linux-gnu-g++")
with open("deploy_graph.json", "w") as fo:
fo.write(graph)
with open("deploy_param.params", "wb") as fo:
fo.write(relay.save_param_dict(params))
```
1. モデルをビルドします。
```
python3 tutorials/relay_quick_start.py --build-dir ./model
```
このコマンドを実行すると、以下のファイルが生成されます。
+ `deploy_graph.json`
+ `deploy_lib.so`
+ `deploy_param.params`
1. 生成されたモデルファイルを `resnet18` という名前のディレクトリにコピーします。これはコンパイル済みモデルのディレクトリです。
1. コンパイル済みモデルのディレクトリをホストコンピュータにコピーします。次に、ステップ 1 でダウンロードしたコンパイルされていないモデルから、コンパイル済みモデルのディレクトリに `synset.txt` をコピーします。
コンパイル済みモデルのディレクトリでは、次のディレクトリ構造が必要です。
![\[コンパイル済みモデルのディレクトリ resnet18 には、4 つのファイルが含まれています。\]](http://docs.aws.amazon.com/ja_jp/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-compiled-tvm.png)
次に、[AWS 認証情報と `device.json` ファイルを設定します](set-config.md)。
# 認定スイートを実行するように IDT AWS IoT Greengrass 設定を構成する
テストを実行する前に、ホストコンピュータの AWS 認証情報とデバイスの設定を構成する必要があります。
## AWS 認証情報を設定する
IAM ユーザー認証情報を ` /configs/config.json` ファイルで設定する必要があります。で作成した AWS IoT Greengrass ユーザーの IDT の認証情報を使用します[の作成と設定 AWS アカウント](dev-tst-prereqs.md#config-aws-account-for-idt)。以下のいずれかの方法で認証情報を指定できます。
+ 認証情報ファイル
+ 環境変数
### AWS 認証情報ファイルを使用して認証情報を設定する
IDT では、 AWS CLIと同じ認証情報ファイルが使用されます。詳細については、「[設定ファイルと認証情報ファイル](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html)」を参照してください。
認証情報ファイルの場所は、使用しているオペレーティングシステムによって異なります。
+ macOS、Linux: `~/.aws/credentials`
+ Windows: `C:\Users\UserName\.aws\credentials`
次の形式で AWS 認証情報を `credentials` ファイルに追加します。
```
[default]
aws_access_key_id =
aws_secret_access_key =
```
`credentials` ファイルから AWS 認証情報を使用する AWS IoT Greengrass ように IDT for を設定するには、次のように`config.json`ファイルを編集します。
```
{
"awsRegion": "us-west-2",
"auth": {
"method": "file",
"credentials": {
"profile": "default"
}
}
}
```
**注記**
`default` AWS プロファイルを使用しない場合は、 `config.json`ファイルのプロファイル名を必ず変更してください。詳細については、「[名前付きプロファイル](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html)」を参照してください。
### 環境変数を使用して AWS 認証情報を設定する
環境変数は、オペレーティングシステムによって維持され、システムコマンドによって使用される変数です。SSH セッションを閉じると、これらは保存されません。IDT for AWS IoT Greengrass は、 `AWS_ACCESS_KEY_ID`および `AWS_SECRET_ACCESS_KEY`環境変数を使用して AWS 認証情報を保存できます。
これらの変数を Linux、macOS、または Unix で設定するには、**export** を使用します。
```
export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
```
Windows でこれらの変数を設定するには、**set** を使用します。
```
set AWS_ACCESS_KEY_ID=
set AWS_SECRET_ACCESS_KEY=
```
環境変数を使用するように IDT を設定するには、`config.json` ファイルの `auth` セクションを編集します。以下がその例です。
```
{
"awsRegion": "us-west-2",
"auth": {
"method": "environment"
}
}
```
## device.json の設定
AWS 認証情報に加えて、IDT for には、テストが実行されるデバイスに関する情報 (IP アドレス、ログイン情報、オペレーティングシステム、CPU アーキテクチャなど) AWS IoT Greengrass が必要です。
これらの情報を指定するには、` /configs/device.json` にある `device.json` テンプレートを使用する必要があります。
------
#### [ Physical device ]
```
[
{
"id": "",
"sku": "",
"features": [
{
"name": "os",
"value": "linux | ubuntu | openwrt"
},
{
"name": "arch",
"value": "x86_64 | armv6l | armv7l | aarch64"
},
{
"name": "container",
"value": "yes | no"
},
{
"name": "docker",
"value": "yes | no"
},
{
"name": "streamManagement",
"value": "yes | no"
},
{
"name": "hsi",
"value": "yes | no"
},
{
"name": "ml",
"value": "mxnet | tensorflow | dlr | mxnet,dlr,tensorflow | no"
},
*********** Remove the section below if the device is not qualifying for ML **************,
{
"name": "mlLambdaContainerizationMode",
"value": "container | process | both"
},
{
"name": "processor",
"value": "cpu | gpu"
},
******************************************************************************************
],
*********** Remove the section below if the device is not qualifying for HSI ***************
"hsm": {
"p11Provider": "/path/to/pkcs11ProviderLibrary",
"slotLabel": "",
"slotUserPin": "",
"privateKeyLabel": "",
"openSSLEngine": "/path/to/openssl/engine"
},
********************************************************************************************
*********** Remove the section below if the device is not qualifying for ML ****************
"machineLearning": {
"dlrModelPath": "/path/to/compiled/dlr/model",
"environmentVariables": [
{
"key": "",
"value": ""
}
],
"deviceResources": [
{
"name": "",
"path": "",
"type": "device | volume"
}
]
},
******************************************************************************************
"kernelConfigLocation": "",
"greengrassLocation": "",
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": 22,
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
"privKeyPath": "/path/to/private/key",
"password": ""
}
}
}
}
]
}
]
```
**注記**
`method` が `pki` に設定されている場合のみ `privKeyPath` を指定します。
`method` が `password` に設定されている場合のみ `password` を指定します。
------
#### [ Docker container ]
```
[
{
"id": "",
"sku": "",
"features": [
{
"name": "os",
"value": "linux | ubuntu | openwrt"
},
{
"name": "arch",
"value": "x86_64"
},
{
"name": "container",
"value": "no"
},
{
"name": "docker",
"value": "no"
},
{
"name": "streamManagement",
"value": "yes | no"
},
{
"name": "hsi",
"value": "no"
},
{
"name": "ml",
"value": "mxnet | tensorflow | dlr | mxnet,dlr,tensorflow | no"
},
*********** Remove the section below if the device is not qualifying for ML **************,
{
"name": "mlLambdaContainerizationMode",
"value": "process"
},
{
"name": "processor",
"value": "cpu | gpu"
},
******************************************************************************************
],
*********** Remove the section below if the device is not qualifying for ML ****************
"machineLearning": {
"dlrModelPath": "/path/to/compiled/dlr/model",
"environmentVariables": [
{
"key": "",
"value": ""
}
],
"deviceResources": [
{
"name": "",
"path": "",
"type": "device | volume"
}
]
},
******************************************************************************************
"kernelConfigLocation": "",
"greengrassLocation": "",
"devices": [
{
"id": "",
"connectivity": {
"protocol": "docker",
"containerId": "",
"containerUser": ""
}
}
]
}
]
```
------
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`id`
デバイスプールと呼ばれるデバイスのコレクションを一意に識別するユーザー定義の英数字の ID。プールに属するデバイスには、同一のハードウェアが必要です。テストスイートを実行する場合、プールのデバイスを使用してワークロードを並列化します。複数のデバイスを使用して異なるテストを実行します。
`sku`
テスト対象デバイスを一意に識別する英数字の値。SKU は、適格性が確認されたボードの追跡に使用されます。
AWS Partner Device Catalog にボードを一覧表示する場合、ここで指定する SKU は、一覧表示プロセスで使用する SKU と一致する必要があります。
`features`
デバイスでサポートされている機能を含む配列。すべての機能が必要です。
`os` および `arch`
サポート対象のオペレーティングシステム (OS) とアーキテクチャの組み合わせ。
+ `linux`, `x86_64`
+ `linux`, `armv6l`
+ `linux`, `armv7l`
+ `linux`, `aarch64`
+ `ubuntu`, `x86_64`
+ `openwrt`, `armv7l`
+ `openwrt`, `aarch64`
IDT を使用して Docker コンテナで AWS IoT Greengrass の実行をテストする場合、x86\$164 Docker アーキテクチャのみがサポートされます。
`container`
デバイスが Greengrass コアのコンテナモードで Lambda 関数を実行するためのすべてのソフトウェア要件とハードウェア要件を満たしているかどうかを検証します。
有効な値は `yes` または `no` です。
`docker`
Greengrass Docker アプリケーションデプロイコネクタを使用してコンテナを実行するために必要なすべての技術的依存関係をデバイスが満たしていることを検証します。
有効な値は `yes` または `no` です。
`streamManagement`
デバイスが AWS IoT Greengrass ストリームマネージャーを実行するために必要な技術的な依存関係をすべて満たしていることを検証します。
有効な値は `yes` または `no` です。
`hsi`
提供された HSI 共有ライブラリがハードウェアセキュリティモジュール (HSM) とやり取りでき、必要な PKCS\$111 API を正しく実装することを検証します。HSM および共有ライブラリは、CSR に署名し、TLS オペレーションを実行して、正しいキー長と公開キーアルゴリズムを提供できる必要があります。
有効な値は `yes` または `no` です。
`ml`
ML 推論をローカルで実行するために必要なすべての技術的依存関係をデバイスが満たしていることを検証します。
有効な値は、`mxnet`、`tensorflow`、`dlr`、および `no` の任意の組み合わせです (例: `mxnet`、`mxnet,tensorflow`、`mxnet,tensorflow,dlr`、または `no`)。
`mlLambdaContainerizationMode`
コンテナモードの Greengrass デバイスで ML 推論を実行するための技術的依存関係要件をデバイスがすべて満たしていることを検証します。
有効な値は `container`、`process`、または `both` です。
`processor`
指定したプロセッサタイプのハードウェア要件をデバイスがすべて満たしていることを検証します。
有効な値は `cpu` または `gpu` です。
`container`、`docker`、`streamManager`、`hsi`、または `ml` 機能を使用しない場合は、対応する `value` を `no` に設定できます。
Docker は、`streamManagement` と `ml` の機能認定のみをサポートしています。
`machineLearning`
オプション。ML 認定テストの設定情報。詳細については、「[ML 認定のための device.json の設定](#device-json-ml-qualification)」を参照してください。
`hsm`
オプション。 AWS IoT Greengrass ハードウェアセキュリティモジュール (HSM) でテストするための設定情報。それ以外の場合は、`hsm` プロパティを省略する必要があります。詳細については、「[ハードウェアセキュリティ統合](hardware-security.md)」を参照してください。
このプロパティは、`connectivity.protocol` が `ssh` に設定されている場合にのみ適用されます。
`hsm.p11Provider`
PKCS\$111 実装の libdl-loadable ライブラリへの絶対パス。
`hsm.slotLabel`
ハードウェアモジュールを識別するために使用されるスロットラベル。
`hsm.slotUserPin`
モジュールへの AWS IoT Greengrass コアの認証に使用されるユーザー PIN。
`hsm.privateKeyLabel`
ハードウェアモジュールでキーを識別するために使用されるラベル。
`hsm.openSSLEngine`
OpenSSL での PKCS\$111 のサポートを有効にするための、OpenSSL エンジンの `.so` ファイルへの絶対パス。 AWS IoT Greengrass OTA 更新エージェントによって使用されます。
`devices.id`
テスト対象のデバイスのユーザー定義の一意の識別子。
`connectivity.protocol`
このデバイスと通信するために使用される通信プロトコル。現在、サポートされている値は、物理デバイス用の `ssh` と Docker コンテナ用の `docker` のみです。
`connectivity.ip`
テスト対象のデバイスの IP アドレス。
このプロパティは、`connectivity.protocol` が `ssh` に設定されている場合にのみ適用されます。
`connectivity.containerId`
テスト対象の Docker コンテナのコンテナ ID または名前。
このプロパティは、`connectivity.protocol` が `docker` に設定されている場合にのみ適用されます。
`connectivity.auth`
接続の認証情報。
このプロパティは、`connectivity.protocol` が `ssh` に設定されている場合にのみ適用されます。
`connectivity.auth.method`
指定された接続プロトコルを介してデバイスにアクセスするために使用される認証方法。
サポートされている値は以下のとおりです。
+ `pki`
+ `password`
`connectivity.auth.credentials`
認証に使用される認証情報。
`connectivity.auth.credentials.password`
テスト中のデバイスにサインインするためのパスワード。
この値は、`connectivity.auth.method` が `password` に設定されている場合にのみ適用されます。
`connectivity.auth.credentials.privKeyPath`
テスト中のデバイスにサインインするためのプライベートキーへの完全パス。
この値は、`connectivity.auth.method` が `pki` に設定されている場合にのみ適用されます。
`connectivity.auth.credentials.user`
テスト対象デバイスにサインインするためのユーザー名。
`connectivity.auth.credentials.privKeyPath`
テスト対象デバイスにサインインするためのプライベートキーへの完全パス。
`connectivity.port`
オプション。SSH 接続に使用するポート番号。
デフォルト値は 22 です。
このプロパティは、`connectivity.protocol` が `ssh` に設定されている場合にのみ適用されます。
`greengrassLocation`
デバイス上の AWS IoT Greengrass Core ソフトウェアの場所。
物理デバイスの場合、この値は既存のインストールを使用する場合にのみ使用されます AWS IoT Greengrass。この属性を使用して、デバイスにインストール済みのバージョンの AWS IoT Greengrass Core ソフトウェアを使用するよう IDT に指示します。
が提供する Docker イメージまたは Dockerfile から Docker コンテナでテストを実行する場合は AWS IoT Greengrass、この値を に設定します`/greengrass`。
`kernelConfigLocation`
オプション。カーネル設定ファイルへのパス。 AWS IoT Device Tester はこのファイルを使用して、デバイスに必要なカーネル機能が有効になっているかどうかを確認します。指定しない場合、IDT は次のパスを使用してカーネル設定ファイルを検索します: `/proc/config.gz`および `/boot/config-`。 AWS IoT Device Tester は、検出した最初のパスを使用します。
## ML 認定のための device.json の設定
このセクションでは、ML 認定に適用されるデバイス設定ファイルのオプションプロパティについて説明します。ML 認定のテストを実行する場合は、ユースケースに適したプロパティを定義する必要があります。
`device-ml.json` テンプレートを使用して、デバイスの構成設定を定義できます。このテンプレートには、オプションの ML プロパティが含まれています。また、`device.json` を使用して ML 修飾プロパティを追加することもできます。これらのファイルは `/configs` にあり、これらには ML 認定プロパティが含まれています。`device-ml.json` を使用する場合は、IDT テストを実行する前に、ファイルの名前を `device.json` に変更する必要があります。
ML 認定に適用されないデバイス設定プロパティについては、「[device.json の設定](#device-config)」を参照してください。
`features` 配列内の `ml`
ボードがサポートする ML フレームワーク。このプロパティには IDT v3.1.0 以降が必要です。
+ 対象のボードでサポートされるフレームワークが 1 つだけの場合は、そのフレームワークを指定します。例:
```
{
"name": "ml",
"value": "mxnet"
}
```
+ 対象のボードで複数のフレームワークがサポートされている場合は、フレームワークをカンマで区切って指定します。例:
```
{
"name": "ml",
"value": "mxnet,tensorflow"
}
```
`features` 配列内の `mlLambdaContainerizationMode`
テストに使用する[コンテナ化モード](lambda-group-config.md#lambda-containerization-considerations)。このプロパティには IDT v3.1.0 以降が必要です。
+ コンテナ化されていない Lambda 関数を使用して ML 推論コードを実行するには、`process` を選択します。このオプションには AWS IoT Greengrass v1.10.x 以降が必要です。
+ コンテナ化された Lambda 関数を使用して ML 推論コードを実行するには、`container` を選択します。
+ 両方のモードで ML 推論コードを実行するには、`both` を選択します。このオプションには AWS IoT Greengrass v1.10.x 以降が必要です。
`features` 配列内の `processor`
対象のボードがサポートするハードウェアアクセラレーターを示します。このプロパティには IDT v3.1.0 以降が必要です。
+ 対象のボードがプロセッサとして CPU を使用する場合は `cpu` を選択します。
+ 対象のボードがプロセッサとして GPU を使用する場合は `gpu` を選択します。
`machineLearning`
オプション。ML 認定テストの設定情報。このプロパティには IDT v3.1.0 以降が必要です。
`dlrModelPath`
`dlr` フレームワークを使用するために必要です。DLR コンパイル済みモデルディレクトリへの絶対パス。`resnet18` を指定する必要があります。詳細については、「[DLR モデルのコンパイル](idt-ml-qualification.md#ml-qualification-dlr-compile-model)」を参照してください。
macOS でのパスの例は次のとおりです: `/Users//Downloads/resnet18`
`environmentVariables`
ML 推論テストに設定を動的に渡すことができるキーと値のペアの配列。CPU デバイスの場合はオプションです。このセクションを使用して、デバイスタイプに必要なフレームワーク固有の環境変数を追加できます。これらの要件の詳細については、フレームワークまたはデバイスの公式ウェブサイトを参照してください。たとえば、一部のデバイスで MXNet 推論テストを実行するには、次のような環境変数が必要になります。
```
"environmentVariables": [
...
{
"key": "PYTHONPATH",
"value": "$MXNET_HOME/python:$PYTHONPATH"
},
{
"key": "MXNET_HOME",
"value": "$HOME/mxnet/"
},
...
]
```
`value` フィールドは、MXNet のインストールによって異なる場合があります。
GPU デバイスで[コンテナ化](lambda-group-config.md#lambda-containerization-considerations)によって実行される Lambda 関数をテストしている場合は、GPU ライブラリの環境変数を追加します。これにより、GPU が計算を実行できるようになります。異なる GPU ライブラリを使用するには、ライブラリまたはデバイスの公式ドキュメントを参照してください。
`mlLambdaContainerizationMode` 機能が `container` または `both` に設定されている場合は、次のキーを設定します。
```
"environmentVariables": [
{
"key": "PATH",
"value": ":$PATH"
},
{
"key": "LD_LIBRARY_PATH",
"value": ""
},
...
]
```
`deviceResources`
GPU デバイスの場合に必要です。Lambda 関数からアクセス可能な[ローカルリソース](access-local-resources.md#lra-resource-types)が含まれています。このセクションを使用して、ローカルデバイスとボリュームリソースを追加します。
+ デバイスリソースの場合は、`"type": "device"` を指定します。GPU デバイスの場合、デバイスリソースは、`/dev` 以下にある GPU 関連デバイスファイルである必要があります。
**注記**
`/dev/shm` ディレクトリは例外です。これは、ボリュームリソースとしてのみ設定できます。
+ ボリュームリソースの場合は、`"type": "volume"` を指定します。
# AWS IoT Greengrass 認定スイートを実行する
[必要な設定を定義したら](set-config.md)、テストを開始できます。完全なテストスイートのランタイムはハードウェアによって異なります。参考までに、Raspberry Pi 3B で完全なテストスイートを完了するには約 30 分かかります。
以下の `run-suite` コマンドの例では、デバイスプールに対して適格性確認テストを実行する方法を示します。デバイスプールは、同一のデバイスのセットです。
------
#### [ IDT v3.0.0 and later ]
指定したテストスイート内のすべてのテストグループを実行します。
```
devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1.0.0 --pool-id
```
`list-suites` コマンドを使用して、`tests` フォルダ内にあるテストスイートを一覧表示します。
テストスイートで特定のテストグループを実行します。
```
devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1.0.0 --group-id --pool-id
```
テストスイートのテストグループを一覧表示するには、`list-groups` コマンドを使用します。
テストグループ内の特定のテストケースを実行します。
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id --test-id
```
テストグループ内の複数のテストケースを実行します。
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id --test-id ,
```
テストグループ内のテストケースを一覧表示します。
```
devicetester_[linux | mac | win_x86-64] list-test-cases --group-id
```
`run-suite` コマンドのオプションは省略可能です。たとえば、`device.json` ファイルに定義されているデバイスプールが 1 つしかない場合は、`pool-id` を省略できます。または、`tests` フォルダ内の最新のテストスイートのバージョンを実行する場合は、`suite-id` を省略できます。
**注記**
IDT は、新しいテストスイートのバージョンをオンラインで入手できるかどうかを尋ねるプロンプトを表示します。詳細については、「[デフォルトの更新動作を設定する](#idt-update-behavior)」を参照してください。
`run-suite` およびその他の IDT コマンドの詳細については、「[AWS IoT Greengrass コマンドの IDT](#bk-cli)」を参照してください。
------
#### [ IDT v2.3.0 and earlier ]
指定したスイート内のすべてのテストグループを実行します。
```
devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1 --pool-id
```
特定のテストグループを実行します。
```
devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1 --group-id --pool-id
```
単一のデバイスプールで単一のテストスイートを実行している場合は、`suite-id` および `pool-id` は省略可能です。つまり、`device.json` ファイルに定義されているデバイスプールは 1 つだけです。
------
## Greengrass の依存関係を確認する
関連するテストグループを実行する前に、すべての Greengrass 依存関係がインストールされていることを確認するため、依存関係チェッカーテストグループを実行することをお勧めします。例:
+ コア資格テストグループを実行する前に `ggcdependencies` を実行します。
+ コンテナ固有のテストグループを実行する前に、`containerdependencies` を実行します。
+ Docker 固有のテストグループを実行する前に `dockerdependencies` を実行します。
+ ストリームマネージャ固有のテストグループを実行する前に `ggcstreammanagementdependencies` を実行します。
## デフォルトの更新動作を設定する
テストランを開始すると、IDT はオンラインで新しいテストスイートのバージョンを確認します。使用可能な場合、IDT は利用可能な最新バージョンに更新するよう求めるプロンプトを表示します。`upgrade-test-suite` (または `u`) フラグを設定して、デフォルトの更新動作を制御できます。次の値を指定できます:
+ `y`。IDT は、利用可能な最新バージョンをダウンロードして使用します。
+ `n` (デフォルト)。IDT は、`suite-id` オプションで指定されたバージョンを使用します。`suite-id` が指定されていない場合、IDT は `tests` フォルダにある最新バージョンを使用します。
`upgrade-test-suite` フラグを含めない場合、IDT は更新が利用可能になったときにプロンプトを表示し、入力 (`y` または `n`) まで 30 秒待ちます。何も入力されていない場合、デフォルトは `n` に設定され、テストの実行が続行されます。
次の例は、この機能の一般的ユースケースを示しています。
**テストグループで使用可能な最新のテストを自動的に使用します。**
```
devicetester_linux run-suite -u y --group-id mqtt --pool-id DevicePool1
```
**特定のテストスイートのバージョンでテストを実行します。**
```
devicetester_linux run-suite -u n --suite-id GGQ_1.0.0 --group-id mqtt --pool-id DevicePool1
```
**実行時に更新を要求します。**
```
devicetester_linux run-suite --pool-id DevicePool1
```
## AWS IoT Greengrass コマンドの IDT
IDT コマンドは、`/bin` ディレクトリにあります。これらのコマンドは次のオペレーションに使用します。
------
#### [ IDT v3.0.0 and later ]
`help`
指定されたコマンドに関する情報を一覧表示します。
`list-groups`
特定のテストスイート内のグループを一覧表示します。
`list-suites`
使用可能なテストスイートを一覧表示します。
`list-supported-products`
サポートされている製品、この場合は AWS IoT Greengrass バージョン、現在の IDT バージョンのテストスイートバージョンを一覧表示します。
`list-test-cases`
指定したテストグループのテストケースを一覧表示します。次のオプションがサポートされています。
+ `group-id`。検索するテストグループ。このオプションは必須で、1 つのグループを指定する必要があります。
`run-suite`
デバイスプールに対してテストスイートを実行します。サポートされているオプションの一部は以下のとおりです。
+ `suite-id`。実行するテストスイートのバージョン。指定しない場合、IDT は `tests` フォルダにある最新バージョンを使用します。
+ `group-id`。実行するテストグループ (カンマ区切りリストとして)。指定しない場合、IDT はテストスイートのすべてのテストグループを実行します。
+ `test-id`。実行するテストケース (カンマ区切りリストとして)。指定した場合は、`group-id` は 1 つのグループを指定する必要があります。
+ `pool-id`。テストするデバイスプール。`device.json` ファイルに複数のデバイスプールが定義されている場合は、プールを指定する必要があります。
+ `upgrade-test-suite`。テストスイートのバージョン更新の処理方法を制御します。IDT v3.0.0 以降、IDT は更新されたテストスイートのバージョンをオンラインでチェックします。詳細については、「[テストスイートのバージョン](idt-gg-qualification.md#idt-test-suite-versions)」を参照してください。
+ `stop-on-first-failure`。最初に障害が発生した時点で実行を停止するように IDT を設定します。指定されたテストグループをデバッグするには、このオプションを `group-id` とともに使用する必要があります。完全テストスイートを実行して認定レポートを生成する場合は、このオプションを使用しないでください。
+ `update-idt`。IDT を更新するプロンプトの応答を設定します。入力値が `Y` であれば、IDT が新しいバージョンを検出した場合にテストの実行を停止します。入力値が `N` であれば、テストの実行を続行します。
+ `update-managed-policy`。入力値が `Y` であれば、IDT がユーザーのマネージドポリシーが更新されていないことを検出した場合にテストの実行を停止します。入力値が `N` であれば、テストの実行を続行します。
`run-suite` オプションの詳細については、次の `help` オプションを使用してください。
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
------
#### [ IDT v2.3.0 and earlier ]
`help`
指定されたコマンドに関する情報を一覧表示します。
`list-groups`
特定のテストスイート内のグループを一覧表示します。
`list-suites`
使用可能なテストスイートを一覧表示します。
`run-suite`
デバイスプールに対してテストスイートを実行します。
`run-suite` オプションの詳細については、次の `help` オプションを使用してください。
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
------
# 結果とログを理解する
このセクションでは、IDT の結果レポートとログを表示し、解釈する方法について説明します。
## 結果の表示
実行中、IDT はコンソール、ログファイル、テストレポートにエラーを書き込みます。IDT で適格性テストスイートを実行すると、2 つのレポートが生成されます。これらのレポートは `/results//` にあります。両レポートでは、適格性確認テストスイートの実行の結果をキャプチャします。
`awsiotdevicetester_report.xml` は、 AWS Partner Device Catalog にデバイスを一覧表示 AWS するために に送信する認定テストレポートです。レポートには、次の要素が含まれます。
+ IDT バージョン。
+ テストされた AWS IoT Greengrass バージョン。
+ `device.json` ファイルで指定されている SKU とデバイスプール。
+ `device.json` ファイルで指定されているデバイスプールの機能。
+ テスト結果の概要の集計。
+ デバイスの機能 (ローカルリソースアクセス、シャドウ、MQTT など) に基づいてテストしたライブラリごとのテスト結果の内訳。
`GGQ_Result.xml` レポートは [JUnit XML 形式](https://llg.cubic.org/docs/junit/)です。[Jenkins](https://jenkins.io/)、[Bamboo](https://www.atlassian.com/software/bamboo) などのように継続的な統合 (CI) と継続的なデプロイ (CD) のプラットフォームに統合することができます。レポートには、次の要素が含まれます。
+ テスト結果の概要を集計したもの。
+ テストされた AWS IoT Greengrass 機能別のテスト結果の内訳。
## IDT レポートの解釈
`awsiotdevicetester_report.xml` または `awsiotdevicetester_report.xml` のレポートセクションには、実行されたテストとその結果が一覧表示されます。
最初の XML タグ `` には、テストの実行の概要が含まれています。例:
```
````` タグで使用される属性
`name`
テストスイートの名前。
`time`
適格性確認スイートの実行所要時間 (秒)。
`tests`
実行されたテストの数。
`failures`
実行されたテストのうち、合格しなかったものの数。
`errors`
IDT で実行できなかったテストの数。
`disabled`
この属性は使用されていないため無視できます。
`awsiotdevicetester_report.xml` ファイルには、テスト対象の製品および一連のテストの実行後に検証された製品機能に関する情報を含む `` タグが含まれています。`` タグで使用される属性
`name`
テスト対象の製品の名前。
`version`
テスト対象の製品のバージョン。
`features`
検証された機能です。`required` としてマークされている機能については、資格を得るためにボードを提出するために必要です。次のスニペットは、この情報が `awsiotdevicetester_report.xml` ファイルで表示される方法を示します。
```
```
`optional` としてマークされている機能は、資格を得るために必要ありません。次のスニペットは、オプションの機能を示しています。
```
```
必要な機能にテストの失敗やエラーがない場合、デバイスは を実行するための技術要件を満た AWS IoT Greengrass し、 AWS IoT サービスと相互運用できます。 AWS Partner Device Catalog にデバイスを一覧表示する場合は、このレポートを認定の証拠として使用できます。
テストに障害やエラーが発生した場合は、`` XML タグを確認することで、障害の生じたテストを特定できます。`` タグ内の `` XML タグは、テストグループのテスト結果の要約を示します。例:
```
```
形式は `` タグと似ていますが、使用されていないため無視できる `skipped` という属性があります。各 `` XML タグ内には、テストグループの実行されたテスト別の `` タグがあります。例:
```
>
````` タグで使用される属性
`name`
テストの名前。
`attempts`
IDT でテストケースを実行した回数。
テストに障害やエラーが発生した場合、`` タグまたは `` タグがトラブルシューティングのための情報とともに `` タグに追加されます。例:
```
Reason for the test failure
Reason for the test execution error
```
## ログの表示
IDT は、`/results//logs` のテスト実行によってログを生成します。2 組のログが生成されます。
`test_manager.log`
AWS IoT Device Tester の Test Manager コンポーネントから生成されたログ (設定、テストシーケンス、レポート生成に関連するログなど）。
`.log (for example, ota.log)`
テストされているデバイスからのログを含む、テストグループのログ。テストが失敗すると、テストのテスト対象デバイスのログを含む tar.gz ファイルが作成されます (例: `ota_prod_test_1_ggc_logs.tar.gz`)。
詳細については、「[AWS IoT Greengrass トラブルシューティング用の IDT](idt-troubleshooting.md)」を参照してください。
# IDT を使用して独自のテストスイートを開発および実行する
IDT v4.0.0 以降、IDT for は標準化された設定設定と結果形式を、デバイスとデバイスソフトウェア用のカスタムテストスイートを開発できるテストスイート環境と AWS IoT Greengrass 組み合わせます。独自の内部検証用のカスタムテストを追加したり、デバイス検証のためにこれらのテストを顧客に提供したりできます。
IDT を使用してカスタムテストスイートを開発および実行するには、次の手順を実行します。
**カスタムテストスイートを開発するには**
+ テストする Greengrass デバイス用のカスタムテストロジックを使用して、テストスイートを作成します。
+ IDT と作成したカスタムテストスイートをテストの実行者に提供します。作成したテストスイートの構成設定に関する情報も提供します。
**カスタムテストスイートを実行するには**
+ テストするデバイスをセットアップします。
+ 使用するテストスイートに必要な構成設定を実装します。
+ IDT を使用して、カスタムテストスイートを実行します。
+ IDT によって実行されたテストのテスト結果と実行ログを表示します。
## の最新バージョンの AWS IoT Device Tester をダウンロードする AWS IoT Greengrass
IDT の[最新バージョン](dev-test-versions.md)をダウンロードし、ファイルシステム上で読み取りおよび書き込みアクセス許可を持っている場所に抽出します。
**注記**
複数のユーザーが NFS ディレクトリや Windows ネットワーク共有フォルダなどの共有場所から IDT を実行することはお勧めしません。IDT パッケージをローカルドライブに展開し、ローカルワークステーションで IDT バイナリを実行することをお勧めします。
Windows では、パスの長さは 260 文字に制限されています。Windows を使用している場合は、パスが 260 文字以内になるようにして、IDT をルートディレクトリ (`C:\ ` または `D:\` など) に展開します。
## テストスイート作成ワークフロー
テストスイートは 3 つのタイプのファイルで構成されます。
+ IDT にテストスイートの実行方法に関する情報を提供する JSON 設定ファイル。
+ IDT がテストケースの実行に使用するテスト実行可能ファイル。
+ テストの実行に必要な追加のファイル。
カスタム IDT テストを作成するには、次の基本的な手順を実行します。
1. テストスイート用の [JSON 設定ファイルを作成します](idt-json-config.md)。
1. テストスイート用のテストロジックが含まれる[テストケース実行可能ファイルを作成します](test-executables.md)。
1. テストスイートを実行するために[テストの実行者に必要な設定情報](set-config-custom.md)を検証し、文書化します。
1. IDT が予想通りにテストスイートを実行し、[テスト結果](run-tests-custom.md)を生成できることを確認します。
サンプルカスタムスイートを迅速に構築して実行するには、[チュートリアル: サンプル IDT テストスイートを構築して実行する](build-sample-suite.md)の手順に従ってください。
Python でカスタムテストスイートの作成を開始するには、[チュートリアル: シンプルな IDT テストスイートの開発](create-custom-tests.md)を参照してください。
# チュートリアル: サンプル IDT テストスイートを構築して実行する
AWS IoT Device Tester のダウンロードには、サンプルテストスイートのソースコードが含まれています。このチュートリアルを完了してサンプルテストスイートを構築して実行し、 AWS IoT Device Tester for を使用してカスタムテストスイート AWS IoT Greengrass を実行する方法を理解できます。
このチュートリアルでは、次の手順を実行します。
1. [サンプルテストスイートを構築する](#build-sample)
1. [IDT を使用してサンプルテストスイートを実行する](#run-sample)
## 前提条件
このチュートリアルを完了するには、以下が必要です。
+
**ホストコンピュータの要件**
+ AWS IoT Device Tester の最新バージョン
+ [Python](https://www.python.org/downloads/) 3.7 以降
コンピュータにインストールされている Python のバージョンを確認するには、次のコマンドを実行します。
```
python3 --version
```
Windows で、このコマンドを使用してエラーが返された場合は、代わりに `python --version` を使用してください。返されたバージョン番号が 3.7 以上の場合は、Powershell ターミナルで次のコマンドを実行し、`python3` を `python` コマンドのエイリアスとして設定します。
```
Set-Alias -Name "python3" -Value "python"
```
バージョン情報が返されない場合や、バージョン番号が 3.7 未満 の場合は、[Python のダウンロード](https://wiki.python.org/moin/BeginnersGuide/Download)の手順に従って Python 3.7 以上をインストールしてください。詳細については、[Python のドキュメント](https://docs.python.org)を参照してください。
+ [urllib3](https://urllib3.readthedocs.io/en/latest/)
`urllib3` が正しくインストールされていることを確認するには、次のコマンドを実行します。
```
python3 -c 'import urllib3'
```
`urllib3` がインストールされていない場合は、次のコマンドを実行してインストールします。
```
python3 -m pip install urllib3
```
+
**デバイスの要件**
+ Linux オペレーティングシステムが搭載され、ホストコンピュータと同じネットワークにネットワーク接続するデバイス。
Raspberry Pi OS が搭載された [Raspberry Pi](https://www.raspberrypi.org/) を使用することをお勧めします。Raspberry Pi に [SSH](https://www.raspberrypi.org/documentation/remote-access/ssh/) をセットアップし、リモートから接続できることを確認します。
## IDT 用のデバイス情報を設定する
IDT がテストを実行するためのデバイス情報を設定します。次の情報を使用して、`/configs` フォルダに含まれている `device.json` テンプレートを更新する必要があります。
```
[
{
"id": "pool",
"sku": "N/A",
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
"privKeyPath": "/path/to/private/key",
"password": ""
}
}
}
}
]
}
]
```
`devices` オブジェクトで、次の情報を指定します。
`id`
自分のデバイスのユーザー定義の一意の識別子。
`connectivity.ip`
自分のデバイスの IP アドレス。
`connectivity.port`
オプション。デバイスへの SSH 接続に使用するポート番号。
`connectivity.auth`
接続の認証情報。
このプロパティは、`connectivity.protocol` が `ssh` に設定されている場合にのみ適用されます。
`connectivity.auth.method`
指定された接続プロトコルを介してデバイスにアクセスするために使用される認証方法。
サポートされている値は以下のとおりです。
+ `pki`
+ `password`
`connectivity.auth.credentials`
認証に使用される認証情報。
`connectivity.auth.credentials.user`
デバイスへのサインインに使用するユーザー名。
`connectivity.auth.credentials.privKeyPath`
デバイスへのサインインに使用するプライベートキーへの完全パス。
この値は、`connectivity.auth.method` が `pki` に設定されている場合にのみ適用されます。
`devices.connectivity.auth.credentials.password`
自分のデバイスにサインインするためのパスワード。
この値は、`connectivity.auth.method` が `password` に設定されている場合にのみ適用されます。
**注記**
`method` が `pki` に設定されている場合のみ `privKeyPath` を指定します。
`method` が `password` に設定されている場合のみ `password` を指定します。
## サンプルテストスイートを構築する
`/samples/python` フォルダには、サンプル設定ファイル、ソースコード、および提供されたビルドスクリプトを使用してテストスイートに結合できる IDT クライアント SDK が含まれています。次のディレクトリツリーは、これらのサンプルファイルの場所を示しています。
```
├── ...
├── tests
├── samples
│ ├── ...
│ └── python
│ ├── configuration
│ ├── src
│ └── build-scripts
│ ├── build.sh
│ └── build.ps1
└── sdks
├── ...
└── python
└── idt_client
```
テストスイートを構築するには、ホストコンピュータで次のコマンドを実行します。
------
#### [ Windows ]
```
cd /samples/python/build-scripts
./build.ps1
```
------
#### [ Linux, macOS, or UNIX ]
```
cd /samples/python/build-scripts
./build.sh
```
------
これにより、`/tests` フォルダ内の `IDTSampleSuitePython_1.0.0` フォルダにサンプルテストスイートが作成されます。`IDTSampleSuitePython_1.0.0` フォルダのファイルを確認して、サンプルテストスイートの構造を理解し、テストケース実行可能ファイルとテスト設定 JSON ファイルのさまざまな例を参照してください。
次のステップ: IDT を使用して、作成した[サンプルテストスイートを実行](#run-sample)します。
## IDT を使用してサンプルテストスイートを実行する
サンプルテストスイートを実行するには、ホストコンピュータで次のコマンドを実行します。
```
cd /bin
./devicetester_[linux | mac | win_x86-64] run-suite --suite-id IDTSampleSuitePython
```
IDT はサンプルテストスイートを実行し、結果をコンソールにストリーミングします。テストの実行が完了すると、次の情報が表示されます。
```
========== Test Summary ==========
Execution Time: 5s
Tests Completed: 4
Tests Passed: 4
Tests Failed: 0
Tests Skipped: 0
----------------------------------
Test Groups:
sample_group: PASSED
----------------------------------
Path to IoT Device Tester Report: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/awsiotdevicetester_report.xml
Path to Test Execution Logs: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/logs
Path to Aggregated JUnit Report: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/IDTSampleSuitePython_Report.xml
```
## トラブルシューティング
次の情報は、チュートリアルの実行に関連する問題の解決に役立ちます。
**テストケースが正常に実行されない**
テストが正常に実行されない場合、IDT はエラーログをコンソールにストリーミングします。このログはテスト実行のトラブルシューティングに役立ちます。このチュートリアルのすべての[前提条件](#prereqs-tutorial-sample)を満たしていることを確認してください。
**テスト対象のデバイスに接続できない**
以下について確認します。
+ `device.json` ファイルに、正しい IP アドレス、ポート、および認証情報が含まれている。
+ ホストコンピュータから SSH 経由でデバイスに接続できる。
# チュートリアル: シンプルな IDT テストスイートの開発
テストスイートは、以下を組み合わせたものです。
+ テストロジックが含まれるテスト実行可能ファイル
+ テストスイートが記述された JSON 設定ファイル
このチュートリアルでは、IDT for AWS IoT Greengrass を使用して、単一のテストケースを含む Python テストスイートを開発する方法を示します。このチュートリアルでは、次の手順を実行します。
1. [テストスイートディレクトリを作成する](#test-suite-dir)
1. [JSON 設定ファイルを作成する](#test-suite-json)
1. [テストケース実行可能ファイルを作成する](#test-suite-exe)
1. [テストスイートを実行する](#run-test-suite)
## 前提条件
このチュートリアルを完了するには、以下が必要です。
+
**ホストコンピュータの要件**
+ AWS IoT Device Tester の最新バージョン
+ [Python](https://www.python.org/downloads/) 3.7 以降
コンピュータにインストールされている Python のバージョンを確認するには、次のコマンドを実行します。
```
python3 --version
```
Windows で、このコマンドを使用してエラーが返された場合は、代わりに `python --version` を使用してください。返されたバージョン番号が 3.7 以上の場合は、Powershell ターミナルで次のコマンドを実行し、`python3` を `python` コマンドのエイリアスとして設定します。
```
Set-Alias -Name "python3" -Value "python"
```
バージョン情報が返されない場合や、バージョン番号が 3.7 未満 の場合は、[Python のダウンロード](https://wiki.python.org/moin/BeginnersGuide/Download)の手順に従って Python 3.7 以上をインストールしてください。詳細については、[Python のドキュメント](https://docs.python.org)を参照してください。
+ [urllib3](https://urllib3.readthedocs.io/en/latest/)
`urllib3` が正しくインストールされていることを確認するには、次のコマンドを実行します。
```
python3 -c 'import urllib3'
```
`urllib3` がインストールされていない場合は、次のコマンドを実行してインストールします。
```
python3 -m pip install urllib3
```
+
**デバイスの要件**
+ Linux オペレーティングシステムが搭載され、ホストコンピュータと同じネットワークにネットワーク接続するデバイス。
Raspberry Pi OS が搭載された [Raspberry Pi](https://www.raspberrypi.org/) を使用することをお勧めします。Raspberry Pi に [SSH](https://www.raspberrypi.org/documentation/remote-access/ssh/) をセットアップし、リモートから接続できることを確認します。
## テストスイートディレクトリを作成する
IDT は、テストケースを、各テストスイート内のテストグループに論理的に分離します。各テストケースはテストグループ内に存在する必要があります。このチュートリアルでは、`MyTestSuite_1.0.0` という名前のフォルダを作成し、このフォルダ内に次のディレクトリツリーを作成します。
```
MyTestSuite_1.0.0
└── suite
└── myTestGroup
└── myTestCase
```
## JSON 設定ファイルを作成する
テストスイートには、次の必須の[ JSON 設定ファイル](idt-json-config.md)が含まれている必要があります。必須の JSON ファイル
`suite.json`
テストスイートに関する情報が含まれています。「[suite.json を設定する](idt-json-config.md#suite-json)」を参照してください。
`group.json`
テストグループに関する情報が含まれています。テストスイート内のテストグループごとに `group.json` ファイルを作成する必要があります。「[group.json を設定する](idt-json-config.md#group-json)」を参照してください。
`test.json`
テストケースに関する情報が含まれています。テストスイート内のテストケースごとに `test.json` ファイルを作成する必要があります。「[test.json を設定する](idt-json-config.md#test-json)」を参照してください。
1. `MyTestSuite_1.0.0/suite` フォルダで、次の構造の `suite.json` ファイルを作成します。
```
{
"id": "MyTestSuite_1.0.0",
"title": "My Test Suite",
"details": "This is my test suite.",
"userDataRequired": false
}
```
1. `MyTestSuite_1.0.0/myTestGroup` フォルダで、次の構造の `group.json` ファイルを作成します。
```
{
"id": "MyTestGroup",
"title": "My Test Group",
"details": "This is my test group.",
"optional": false
}
```
1. `MyTestSuite_1.0.0/myTestGroup/myTestCase` フォルダで、次の構造の `test.json` ファイルを作成します。
```
{
"id": "MyTestCase",
"title": "My Test Case",
"details": "This is my test case.",
"execution": {
"timeout": 300000,
"linux": {
"cmd": "python3",
"args": [
"myTestCase.py"
]
},
"mac": {
"cmd": "python3",
"args": [
"myTestCase.py"
]
},
"win": {
"cmd": "python3",
"args": [
"myTestCase.py"
]
}
}
}
```
`MyTestSuite_1.0.0` フォルダのディレクトリツリーは次のようになります。
```
MyTestSuite_1.0.0
└── suite
├── suite.json
└── myTestGroup
├── group.json
└── myTestCase
└── test.json
```
## IDT クライアント SDK を入手する
IDT がテスト対象のデバイスとやり取りし、テスト結果をレポートできるようにするには、[IDT クライアント SDK](test-executables.md#idt-client-sdk) を使用します。このチュートリアルでは、Python バージョンの SDK を使用します。
`/sdks/python/` フォルダから、`idt_client` フォルダを自分の `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase` フォルダにコピーします。
SDK が正常にコピーされたことを確認するには、次のコマンドを実行します。
```
cd MyTestSuite_1.0.0/suite/myTestGroup/myTestCase
python3 -c 'import idt_client'
```
## テストケース実行可能ファイルを作成する
テストケース実行可能ファイルには、実行するテストロジックが含まれています。テストスイートには、複数のテストケース実行可能ファイルを含めることができます。このチュートリアルでは、テストケース実行可能ファイルを 1 つだけ作成します。
1. テストスイートファイルを作成します。
`MyTestSuite_1.0.0/suite/myTestGroup/myTestCase` フォルダで、次の内容の `myTestCase.py` ファイルを作成します。
```
from idt_client import *
def main():
# Use the client SDK to communicate with IDT
client = Client()
if __name__ == "__main__":
main()
```
1. クライアント SDK 関数を使用して、自分の `myTestCase.py` ファイルに次のテストロジックを追加します。
1. テスト対象のデバイスで SSH コマンドを実行します。
```
from idt_client import *
def main():
# Use the client SDK to communicate with IDT
client = Client()
# Create an execute on device request
exec_req = ExecuteOnDeviceRequest(ExecuteOnDeviceCommand("echo 'hello world'"))
# Run the command
exec_resp = client.execute_on_device(exec_req)
# Print the standard output
print(exec_resp.stdout)
if __name__ == "__main__":
main()
```
1. テスト結果を IDT に送信します。
```
from idt_client import *
def main():
# Use the client SDK to communicate with IDT
client = Client()
# Create an execute on device request
exec_req = ExecuteOnDeviceRequest(ExecuteOnDeviceCommand("echo 'hello world'"))
# Run the command
exec_resp = client.execute_on_device(exec_req)
# Print the standard output
print(exec_resp.stdout)
# Create a send result request
sr_req = SendResultRequest(TestResult(passed=True))
# Send the result
client.send_result(sr_req)
if __name__ == "__main__":
main()
```
## IDT 用のデバイス情報を設定する
IDT がテストを実行するためのデバイス情報を設定します。次の情報を使用して、`/configs` フォルダに含まれている `device.json` テンプレートを更新する必要があります。
```
[
{
"id": "pool",
"sku": "N/A",
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
"privKeyPath": "/path/to/private/key",
"password": ""
}
}
}
}
]
}
]
```
`devices` オブジェクトで、次の情報を指定します。
`id`
自分のデバイスのユーザー定義の一意の識別子。
`connectivity.ip`
自分のデバイスの IP アドレス。
`connectivity.port`
オプション。デバイスへの SSH 接続に使用するポート番号。
`connectivity.auth`
接続の認証情報。
このプロパティは、`connectivity.protocol` が `ssh` に設定されている場合にのみ適用されます。
`connectivity.auth.method`
指定された接続プロトコルを介してデバイスにアクセスするために使用される認証方法。
サポートされている値は以下のとおりです。
+ `pki`
+ `password`
`connectivity.auth.credentials`
認証に使用される認証情報。
`connectivity.auth.credentials.user`
デバイスへのサインインに使用するユーザー名。
`connectivity.auth.credentials.privKeyPath`
デバイスへのサインインに使用するプライベートキーへの完全パス。
この値は、`connectivity.auth.method` が `pki` に設定されている場合にのみ適用されます。
`devices.connectivity.auth.credentials.password`
自分のデバイスにサインインするためのパスワード。
この値は、`connectivity.auth.method` が `password` に設定されている場合にのみ適用されます。
**注記**
`method` が `pki` に設定されている場合のみ `privKeyPath` を指定します。
`method` が `password` に設定されている場合のみ `password` を指定します。
## テストスイートを実行する
テストスイートを作成したら、テストスイートが期待どおりに機能することを確認します。そのために、次の手順に従って、既存のデバイスプールを使用してテストスイートを実行します。
1. 自分の `MyTestSuite_1.0.0` フォルダを `/tests` にコピーします。
1. 以下の コマンドを実行します。
```
cd /bin
./devicetester_[linux | mac | win_x86-64] run-suite --suite-id MyTestSuite
```
IDT はテストスイートを実行し、結果をコンソールにストリーミングします。テストの実行が完了すると、次の情報が表示されます。
```
time="2020-10-19T09:24:47-07:00" level=info msg=Using pool: pool
time="2020-10-19T09:24:47-07:00" level=info msg=Using test suite "MyTestSuite_1.0.0" for execution
time="2020-10-19T09:24:47-07:00" level=info msg=b'hello world\n' suiteId=MyTestSuite groupId=myTestGroup testCaseId=myTestCase deviceId=my-device executionId=9a52f362-1227-11eb-86c9-8c8590419f30
time="2020-10-19T09:24:47-07:00" level=info msg=All tests finished. executionId=9a52f362-1227-11eb-86c9-8c8590419f30
time="2020-10-19T09:24:48-07:00" level=info msg=
========== Test Summary ==========
Execution Time: 1s
Tests Completed: 1
Tests Passed: 1
Tests Failed: 0
Tests Skipped: 0
----------------------------------
Test Groups:
myTestGroup: PASSED
----------------------------------
Path to IoT Device Tester Report: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/awsiotdevicetester_report.xml
Path to Test Execution Logs: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/logs
Path to Aggregated JUnit Report: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/MyTestSuite_Report.xml
```
## トラブルシューティング
次の情報は、チュートリアルの実行に関連する問題の解決に役立ちます。
**テストケースが正常に実行されない**
テストが正常に実行されない場合、IDT はエラーログをコンソールにストリーミングします。このログはテスト実行のトラブルシューティングに役立ちます。エラーログを確認する前に、次の点を確認してください。
+ IDT クライアント SDK が、[このステップ](#add-idt-sdk)で説明された通りの正しいフォルダにある。
+ このチュートリアルのすべての[前提条件](#prereqs-tutorial-custom)を満たしている。
**テスト対象のデバイスに接続できない**
以下について確認します。
+ `device.json` ファイルに、正しい IP アドレス、ポート、および認証情報が含まれている。
+ ホストコンピュータから SSH 経由でデバイスに接続できる。
# IDT テストスイート設定ファイルを作成する
このセクションでは、カスタムテストスイートの作成時に、スートに含める JSON 設定ファイルを作成する形式について説明します。必須の JSON ファイル
`suite.json`
テストスイートに関する情報が含まれています。「[suite.json を設定する](#suite-json)」を参照してください。
`group.json`
テストグループに関する情報が含まれています。テストスイート内のテストグループごとに `group.json` ファイルを作成する必要があります。「[group.json を設定する](#group-json)」を参照してください。
`test.json`
テストケースに関する情報が含まれています。テストスイート内のテストケースごとに `test.json` ファイルを作成する必要があります。「[test.json を設定する](#test-json)」を参照してください。オプションの JSON ファイル
`state_machine.json`
IDT がテストスイートを実行するときのテストの実行方法を定義します。「[state\$1machine.json を構成する](#state-machine-json)」を参照してください。
`userdata_schema.json`
テストの実行者が設定構成に含めることができる [`userdata.json` ファイル](set-config-custom.md#userdata-config-custom)のスキーマを定義します。`userdata.json` ファイルは、テストの実行に必要であるものの、`device.json` ファイルに含まれていない、追加の設定情報用に使用します。「[userdata\$1schema.json を構成する](#userdata-schema-json)」を参照してください。
JSON 設定ファイルは、以下に示すように `` に配置します。
```
└── suite
├── suite.json
├── state_machine.json
├── userdata_schema.json
├──
├── group.json
├──
└── test.json
```
## suite.json を設定する
`suite.json` ファイルは、環境変数を設定し、テストスイートの実行にユーザーデータが必要かどうかを決定します。以下のテンプレートを使用して、`/suite/suite.json` ファイルを設定します。
```
{
"id": "_",
"title": "",
"details": "",
"userDataRequired": true | false,
"environmentVariables": [
{
"key": "",
"value": "",
},
...
{
"key": "",
"value": "",
}
]
}
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`id`
テストスイートの一意のユーザー定義 ID。`id` の値は、`suite.json` ファイルが配置されているテストスイートフォルダ名と一致する必要があります。スイート名とスイートのバージョンは、次の要件も満たしている必要があります。
+ `` にアンダースコアを含めることはできません。
+ `` が `x.x.x` として表されている (`x` は数字)。
ID は IDT によって生成されるテストレポートに表示されます。
`title`
このテストスイートでテストされる製品または機能のユーザー定義名。この名前は、テストの実行者の IDT CLI に表示されます。
`details`
テストスイートの目的の簡単な説明。
`userDataRequired`
テストの実行者が `userdata.json` ファイルにカスタム情報を含める必要があるかどうかを定義します。この値を `true` に設定した場合は、テストスイートフォルダに [`userdata_schema.json` ファイル](#userdata-schema-json)も含める必要があります。
`environmentVariables`
オプション。このテストスイートに設定する環境変数の配列。
`environmentVariables.key`
環境変数の名前。
`environmentVariables.value`
環境変数の値。
## group.json を設定する
`group.json` ファイルは、テストグループが必須かオプションかを定義します。以下のテンプレートを使用して、`/suite//group.json` ファイルを設定します。
```
{
"id": "",
"title": "",
"details": "",
"optional": true | false,
}
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`id`
テストグループの一意のユーザー定義 ID。`id` の値は、`group.json` ファイルが配置されているテストグループフォルダの名前と一致する必要があり、アンダースコア (`_`) は使用できません。ID は IDT によって生成されるテストレポートで使用されます。
`title`
テストグループのわかりやすい名前。この名前は、テストの実行者の IDT CLI に表示されます。
`details`
テストグループの目的の簡単な説明。
`optional`
オプション。`true` に設定すると、IDT が必須テストの実行を完了した後に、このテストグループがオプショングループとして表示されます。デフォルト値は `false` です。
## test.json を設定する
`test.json` ファイルは、テストケースによって使用されるテストケース実行ファイルと環境変数を決定します。テストケース実行可能ファイルの作成の詳細については、[IDT テストケース実行可能ファイルを作成する](test-executables.md)を参照してください。
以下のテンプレートを使用して、`/suite///test.json` ファイルを設定します。
```
{
"id": "",
"title": "",
"details": "",
"requireDUT": true | false,
"requiredResources": [
{
"name": "",
"features": [
{
"name": "",
"version": "",
"jobSlots":
}
]
}
],
"execution": {
"timeout": ,
"mac": {
"cmd": "/path/to/executable",
"args": [
""
],
},
"linux": {
"cmd": "/path/to/executable",
"args": [
""
],
},
"win": {
"cmd": "/path/to/executable",
"args": [
""
]
}
},
"environmentVariables": [
{
"key": "",
"value": "",
}
]
}
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`id`
テストケースの一意のユーザー定義 ID。`id` の値は、`test.json` ファイルが配置されているテストケースフォルダの名前と一致する必要があり、アンダースコア (`_`) は使用できません。ID は IDT によって生成されるテストレポートで使用されます。
`title`
テストケースのわかりやすい名前。この名前は、テストの実行者の IDT CLI に表示されます。
`details`
テストケースの目的の簡単な説明。
`requireDUT`
オプション。このテストの実行にデバイスが必要な場合は `true` に設定します。必要ない場合は `false` に設定します。デフォルト値は `true` です。テストの実行者は、テストの実行に使用するデバイスを `device.json` ファイルに設定します。
`requiredResources`
オプション。このテストの実行に必要なリソースデバイスに関する情報を指定する配列。
`requiredResources.name`
このテストの実行時にリソースデバイスに与える一意の名前。
`requiredResources.features`
ユーザー定義のリソースデバイス機能の配列。
`requiredResources.features.name`
機能の名前。このデバイスが使用するデバイス機能。この名前は、テストの実行者によって `resource.json` ファイルに指定される機能名に対してマッチングされます。
`requiredResources.features.version`
オプション。機能のバージョン。この値は、テストの実行者によって `resource.json` ファイルに指定される機能のバージョンに対してマッチングされます。バージョンが指定されていない場合、機能はチェックされません。機能にバージョン番号が必要ない場合は、このフィールドは空白のままにしてください。
`requiredResources.features.jobSlots`
オプション。この機能がサポートできる同時テストの数。デフォルト値は `1` です。IDT が機能ごとに異なるデバイスを使用する場合は、この値を `1` に設定することをお勧めします。
`execution.timeout`
IDT がテスト実行終了まで待機する時間 (ミリ秒単位)。この値の設定の詳細については、[IDT テストケース実行可能ファイルを作成する](test-executables.md)を参照してください。
`execution.os`
IDT を実行するホストコンピュータのオペレーティングシステムに基づいて実行されるテストケースの実行可能ファイル。サポートされている値は `linux`、`mac`、`win` です。
`execution.os.cmd`
指定されたオペレーティングシステムで実行するテストケース実行可能ファイルへのパス。この場所は、システムパス内に存在する必要があります。
`execution.os.args`
オプション。テストケースの実行可能ファイルを実行するために指定する引数。
`environmentVariables`
オプション。このテストケース用に設定された環境変数の配列。
`environmentVariables.key`
環境変数の名前。
`environmentVariables.value`
環境変数の値。
`test.json` ファイルと `suite.json` ファイルに同じ環境変数を設定した場合は、`test.json` ファイルの値が優先されます。
## state\$1machine.json を構成する
ステートマシンは、テストスイートの実行フローを制御するコンストラクトです。テストスイートの開始ステートを決定し、ユーザー定義のルールに基づいてステートの移行を管理し、終了ステートに達するまでステートの移行を継続します。
テストスイートにユーザー定義のステートマシンが含まれていない場合は、IDT によってステートマシンが生成されます。デフォルトのステートマシンには、次の機能があります。
+ テストの実行者に、テストスイート全体ではなく、特定のテストグループを選択して実行する機能を提供する。
+ 特定のテストグループが選択されていない場合、テストスイート内のすべてのテストグループをランダムな順序で実行する。
+ レポートを生成し、各テストグループおよびテストケースのテスト結果を示すコンソールサマリーを出力する。
IDT ステートマシンの機能の詳細については、[IDT ステートマシンを設定する](idt-state-machine.md)を参照してください。
## userdata\$1schema.json を構成する
`userdata_schema.json` ファイルは、テストの実行者がユーザーデータを指定するスキーマを決定します。ユーザーデータは、テストスイートが `device.json` ファイルに含まれていない情報を必要とする場合に必要になります。例えば、テストを実行するために、Wi-Fi ネットワークの認証情報、特定のオープンポート、またはユーザーが提供する証明書が必要になる場合があります。この情報は、`userdata` という入力パラメータとして IDT に提供できます。これは、ユーザーが `/config` フォルダに作成する`userdata.json` ファイルの値です。`userdata.json` の形式は、テストケースに含まれている `userdata_schema.json` ファイルに基づきます。
テストの実行者が `userdata.json` ファイルを提供しなければならないことを示す方法
1. `suite.json` ファイルで、`userDataRequired` を `true` に設定します。
1. `` で、`userdata_schema.json` ファイルを作成します。
1. `userdata_schema.json` ファイルを編集して、有効な [IETF Draft v4 JSON Schema](https://json-schema.org/specification-links.html#draft-4) を作成します。
IDT は、テストスイートを実行するときに、このスキーマを自動的に読み込み、テストの実行者によって提供される `userdata.json` ファイルの検証に使用します。有効な場合、`userdata.json` ファイルのコンテンツは [IDT コンテキスト](idt-context.md)および、[ステートマシンコンテキスト](idt-state-machine.md#state-machine-context)の両方で使用可能になります。
# IDT ステートマシンを設定する
ステートマシンは、テストスイートの実行フローを制御するコンストラクトです。テストスイートの開始ステートを決定し、ユーザー定義のルールに基づいてステートの移行を管理し、終了ステートに達するまでステートの移行を継続します。
テストスイートにユーザー定義のステートマシンが含まれていない場合は、IDT によってステートマシンが生成されます。デフォルトのステートマシンには、次の機能があります。
+ テストの実行者に、テストスイート全体ではなく、特定のテストグループを選択して実行する機能を提供する。
+ 特定のテストグループが選択されていない場合、テストスイート内のすべてのテストグループをランダムな順序で実行する。
+ レポートを生成し、各テストグループおよびテストケースのテスト結果を示すコンソールサマリーを出力する。
IDT テストスイートのステートマシンは、次の基準を満たす必要があります。
+ 各ステートが、IDT が実行する各アクション (テストグループの実行、レポートファイルの生成など) に対応する。
+ ステートが移行すると、そのステートに関連付けられたアクションを実行する。
+ 各ステートが、次のステートの移行ルールを定義する。
+ 終了ステートが `Succeed` または `Fail` である。
## ステートマシンの形式
次のテンプレートを使用して、独自の `/suite/state_machine.json` ファイルを設定できます。
```
{
"Comment": "",
"StartAt": "",
"States": {
"": {
"Type": "",
// Additional state configuration
}
// Required states
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`Comment`
ステートマシンの説明。
`StartAt`
IDT がテストスイートの実行を開始するステートの名前。`StartAt` の値は、`States` オブジェクトにリストされているいずれかのステートに設定する必要があります。
`States`
ユーザー定義のステート名を有効な IDT ステートにマッピングするオブジェクト。各 States.*state-name* オブジェクトには、*state-name* にマッピングされた有効なステートの定義が含まれています。
`States` オブジェクトには、`Succeed` ステートおよび `Fail` ステートを含める必要があります。有効なステートについては、[有効なステートとステートの定義](#valid-states)を参照してください。
## 有効なステートとステートの定義
このセクションでは、IDT ステートマシンで使用可能なすべての有効なステートのステート定義について説明します。以下に示すステートの一部は、テストケースレベルでの設定をサポートしています。ただし、絶対に必要な場合を除き、テストケースレベルではなく、テストグループレベルでステート移行ルールを設定することをお勧めします。
**Topics**
+ [
### RunTask
](#state-runtask)
+ [
### 選択
](#state-choice)
+ [
### 並行
](#state-parallel)
+ [
### AddProductFeatures
](#state-addproductfeatures)
+ [
### レポートを行う
](#state-report)
+ [
### LogMessage
](#state-logmessage)
+ [
### SelectGroup
](#state-selectgroup)
+ [
### 失敗
](#state-fail)
+ [
### 成功
](#state-succeed)
### RunTask
`RunTask` ステートは、テストスイートで定義されているテストグループからテストケースを実行します。
```
{
"Type": "RunTask",
"Next": "",
"TestGroup": "",
"TestCases": [
""
],
"ResultVar": ""
}
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`Next`
現在のステートのアクションを実行した後に移行するステートの名前。
`TestGroup`
オプション。実行するテストグループの ID。この値を指定しない場合、IDT はテストの実行者が選択するテストグループを実行します。
`TestCases`
オプション。`TestGroup` に指定されたグループのテストケース ID の配列。IDT は、`TestGroup` と `TestCases` の値に基づいて、次のようにテストの実行動作を決定します。
+ `TestGroup` と `TestCases` 両方が指定されている場合、IDT はテストグループから指定されたテストケースを実行します。
+ `TestCases` が指定され、`TestGroup` が指定されていない場合、IDT は指定されたテストケースを実行します。
+ `TestGroup` が指定され、`TestCases` が指定されていない場合は、IDT は指定されたテストグループ内のすべてのテストケースを実行します。
+ `TestGroup` も `TestCases` も指定されていない場合、IDT は、テストの実行者が IDT CLI から選択したテストグループからすべてのテストケースを実行します。テストの実行者がグループを選択できるようにするには、`statemachine.json` ファイルに `RunTask` ステートと `Choice`ステート両方を含める必要があります。これを行う方法の例については、[ステートマシンの例: ユーザーが選択したテストグループを実行する](#allow-specific-groups)を参照してください。
テストの実行者向けの IDT CLI コマンドを有効にする方法については「[IDT CLI コマンドを有効にする](test-executables.md#idt-cli-coop)」を参照してください。
`ResultVar`
テスト実行の結果によって設定するコンテキスト変数の名前。`TestGroup` の値を指定しなかった場合は、この値を指定しないでください。IDT は、以下に基づいて、`ResultVar` に定義された変数を `true` または `false` に設定します。
+ 変数名の形式が `text_text_passed` の場合、この値は、最初のテストグループのすべてのテストが合格したか、スキップされたかに設定されます。
+ それ以外の場合、この値は、すべてのテストグループのすべてのテストが合格したか、スキップされたかに設定されます。
通常、`RunTask` ステートは、個々のテストケース ID を指定せずにテストグループ ID を指定するために使用されます。この指定により、IDT は指定されたテストグループ内のすべてのテストケースを実行します。このステートで実行されるすべてのテストケースは、ランダムな順序で並行して実行されます。ただし、すべてのテストケースが実行に 1 つのデバイスを必要とし、単一のデバイスしか使用できない場合は、テストケースは順次実行されます。
**エラー処理**
指定されたテストグループ ID またはテストケース ID のいずれかが有効でない場合、このステートは `RunTaskError` 実行エラーを発行します。またこのステートは、実行エラーに遭遇すると、ステートマシンコンテキスト内の `hasExecutionError` 変数を `true` に設定します。
### 選択
`Choice` ステートでは、ユーザー定義の条件に基づいて、移行先の次のステートを動的に設定できます。
```
{
"Type": "Choice",
"Default": "",
"FallthroughOnError": true | false,
"Choices": [
{
"Expression": "",
"Next": ""
}
]
}
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`Default`
`Choices` に定義されているいずれの式も `true` に評価されない場合に移行先になるデフォルトのステート。
`FallthroughOnError`
オプション。このステートが式評価エラーに遭遇したときの動作を指定します。評価結果がエラーになったときに式をスキップしたい場合は `true` に設定します。一致する式がない場合、ステートマシンは `Default` ステートに移行します。`FallthroughOnError` 値は、指定されない場合、デフォルトで `false` になります。
`Choices`
現在のステートのアクションを実行した後に移行するステートを決定する式とステートの配列。
`Choices.Expression`
ブール値に評価される式文字列。式が `true` と評価された場合、ステートマシンは `Choices.Next` に定義されているステートに移行します。式文字列は、ステートマシンコンテキストから値を取得し、オペレーションを実行してブール値に到達します。ステートマシンコンテキストへのアクセスについては、「[ステートマシンコンテキスト](#state-machine-context)」を参照してください。
`Choices.Next`
`Choices.Expression` で定義されている式が `true` に評価された場合の移行先のステート名。
**エラー処理**
以下に示すケースでは、`Choice` ステートでエラー処理が必要になることがあります。
+ choice 式の一部の変数が、ステートマシンのコンテキストに存在しない。
+ 式の結果がブール値ではない。
+ JSON 検索の結果が、文字列、数値、またはブール値ではない。
このステートのエラー処理に `Catch` ブロックを使用することはできません。ステートマシンがエラーに遭遇したときに、その実行を停止するには、`FallthroughOnError` を `false` に設定する必要があります。ただし、`FallthroughOnError` は `true` に設定し、ユースケースに応じて、次のいずれかの操作を実行することをお勧めします。
+ アクセスしている変数が一部のケースに存在しないと考えられる場合は、`Default` の値と追加の `Choices` ブロックを使用して次のステートを指定します。
+ 使用している変数が必ず存在するものである場合は、`Default` ステートを `Fail` に設定します。
### 並行
`Parallel` ステートでは、新しいステートマシンを互いに並列に定義して実行できます。
```
{
"Type": "Parallel",
"Next": "",
"Branches": [
]
}
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`Next`
現在のステートのアクションを実行した後に移行するステートの名前。
`Branches`
実行するステートマシン定義の配列。各ステートマシン定義には、それぞれの `StartAt`、`Succeed`、および `Fail` ステートを含める必要があります。この配列内のステートマシン定義は、各自の定義外のステートを参照することはできません。
各ブランチステートマシンは同じステートマシンコンテキストを共有するため、あるブランチに変数を設定し、別のブランチからそれらの変数を読み込むと、予期しない動作が発生する可能性があります。
`Parallel` ステートは、すべてのブランチステートマシンを実行してから次のステートに移行します。デバイスを必要とする各ステートは、デバイスが利用可能になるまで実行を待ちます。複数のデバイスが利用可能な場合、このステートは並行して複数のグループからテストケースを実行します。十分な数のデバイスが利用できない場合、テストケースは順次実行されます。テストケースは、並列して実行される場合、ランダムな順序で実行されるため、同じテストグループからのテストの実行に異なるデバイスが使用されることがあります。
**エラー処理**
実行エラーを処理するには、ブランチステートマシンと親ステートマシンの両方が、`Fail` ステートに移行していることを確認します。
ブランチステートマシンは親ステートマシンに実行エラーを送信しないため、ブランチステートマシンの実行エラーを処理するために `Catch` ブロックを使用することはできません。代わりに、共有ステートマシンコンテキストの `hasExecutionErrors` 値を使用します。これを行う方法の例については、[ステートマシンの例: 2 つのテストグループを並行して実行する](#run-in-parallel)を参照してください。
### AddProductFeatures
`AddProductFeatures` ステートでは、IDT によって生成される `awsiotdevicetester_report.xml` ファイルに製品機能を追加できます。
製品機能とは、デバイスが満たしている可能性のある特定の基準に関するユーザー定義の情報です。例えば、`MQTT` 製品機能には、デバイスが MQTT メッセージを適切に公開することを指定できます。レポートでは、製品機能は指定されたテストが合格したかどうかに応じて、`supported`、`not-supported`、カスタム値に設定されます。
**注記**
`AddProductFeatures` ステートだけではレポートは生成されません。レポートを生成するには、このステートが [`Report` ステート](#state-report)に移行する必要があります。
```
{
"Type": "Parallel",
"Next": "",
"Features": [
{
"Feature": "",
"Groups": [
""
],
"OneOfGroups": [
""
],
"TestCases": [
""
],
"IsRequired": true | false,
"ExecutionMethods": [
""
]
}
]
}
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`Next`
現在のステートのアクションを実行した後に移行するステートの名前。
`Features`
`awsiotdevicetester_report.xml` ファイルに表示される製品機能の配列。
`Feature`
機能の名前。
`FeatureValue`
オプション。`supported` の代わりにレポートで使用するカスタム値。この値を指定しない場合、テスト結果に基づいて、機能値は `supported` または `not-supported` に設定されます。
`FeatureValue` にカスタム値を使用する場合は、同じ機能を異なる条件でテストできます。IDT は、サポート条件の機能値を連結します。例えば、以下の抜粋は、`MyFeature` 機能と 2 つの異なる機能値を示しています。
```
...
{
"Feature": "MyFeature",
"FeatureValue": "first-feature-supported",
"Groups": ["first-feature-group"]
},
{
"Feature": "MyFeature",
"FeatureValue": "second-feature-supported",
"Groups": ["second-feature-group"]
},
...
```
両方のテストグループが合格した場合、機能値は `first-feature-supported, second-feature-supported` に設定されます。
`Groups`
オプション。テストグループ ID の配列。機能をサポートするには、指定された各テストグループ内のすべてのテストが合格である必要があります。
`OneOfGroups`
オプション。テストグループ ID の配列。機能をサポートするには、指定されたテストグループうち、少なくとも 1 つのグループに含まれるすべてのテストが合格である必要があります。
`TestCases`
オプション。テストケース ID の配列。この値を指定すると、次のことが適用されます。
+ 機能をサポートするには、指定されたすべてのテストケースが合格である必要があります。
+ `Groups` には、テストグループ ID を 1 つだけ含める必要があります。
+ `OneOfGroups` は指定できません。
`IsRequired`
オプション。この機能をレポートでオプション機能としてマークするには、`false` に設定します。デフォルト値は `true` です。
`ExecutionMethods`
オプション。`device.json` ファイルに指定された `protocol` 値と一致する実行メソッドの配列。この値を指定した場合、この機能をレポートに含めるには、テストの実行者はこの配列の値の 1 つに一致する `protocol` 値を指定する必要があります。この値を指定しない場合、この機能は常にレポートに含まれます。
`AddProductFeatures` ステートを使用するには、`RunTask` ステートの `ResultVar` の値を以下のいずれかの値に指定する必要があります。
+ 個々のテストケース ID を指定した場合は、`ResultVar` を`group-id_test-id_passed` に指定します。
+ 個々のテストケース ID を指定しなかった場合は、`ResultVar` を`group-id_passed` に指定します。
`AddProductFeatures` ステートは、次の方法でテスト結果をチェックします。
+ テストケース ID を指定しなかった場合は、各テストグループの結果は、ステートマシンコンテキスト内の `group-id_passed` 変数の値から決定されます。
+ テストケース ID を指定した場合は、各テストの結果は、ステートマシンコンテキスト内の `group-id_test-id_passed` 変数の値から決定されます。
**エラー処理**
このステートで指定されたグループ ID が有効なグループ ID でない場合、このステートで `AddProductFeaturesError` 実行エラーが発生します。またこのステートは、実行エラーに遭遇すると、ステートマシンコンテキスト内の `hasExecutionErrors` 変数を `true` に設定します。
### レポートを行う
`Report` ステートでは、`suite-name_Report.xml` ファイルと `awsiotdevicetester_report.xml` ファイルが生成されます。またこのステートでは、レポートがコンソールにストリーミングされます。
```
{
"Type": "Report",
"Next": ""
}
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`Next`
現在のステートのアクションを実行した後に移行するステートの名前。
テストの実行者がテスト結果を確認できるように、テスト実行フローの終了ステートの前に `Report` ステートに移行する必要があります。通常、このステートの次のステートは `Succeed` です。
**エラー処理**
このステートは、レポート生成時に問題に遭遇した場合、`ReportError` 実行エラーを発行します。
### LogMessage
`LogMessage` ステートでは、`test_manager.log` ファイルが生成され、ログメッセージがコンソールにストリーミングされます。
```
{
"Type": "LogMessage",
"Next": ""
"Level": "info | warn | error"
"Message": ""
}
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`Next`
現在のステートのアクションを実行した後に移行するステートの名前。
`Level`
ログメッセージを作成するエラーレベル。有効でないレベルを指定すると、エラーメッセージが生成され、そのレベルは破棄されます。
`Message`
ログに記録するメッセージ。
### SelectGroup
`SelectGroup` ステートでは、ステートマシンコンテキストを更新して選択されたグループを示します。このステートで設定した値は、後続のすべての `Choice` ステートによって使用されます。
```
{
"Type": "SelectGroup",
"Next": ""
"TestGroups": [
"
]
}
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`Next`
現在のステートのアクションを実行した後に移行するステートの名前。
`TestGroups`
選択済みとしてマークされるテストグループの配列。この配列の各テストグループ ID について、`group-id_selected` 変数がコンテキストで `true` に設定されます。IDT は、指定されたグループが存在するかどうかを検証しないため、有効なテストグループ ID を指定するようにしてください。
### 失敗
`Fail` ステートは、ステートマシンが正しく実行されなかったことを示します。これはステートマシンの終了ステートです。各ステートマシンの定義にこのステートを含める必要があります。
```
{
"Type": "Fail"
}
```
### 成功
`Succeed` ステートは、ステートマシンが正しく実行されたことを示します。これはステートマシンの終了ステートです。各ステートマシンの定義にこのステートを含める必要があります。
```
{
"Type": "Succeed"
}
```
## ステートマシンコンテキスト
ステートマシンコンテキストは、実行中のステートマシンに利用可能なデータが含まれている読み取り専用 JSON ドキュメントです。ステートマシンコンテキストは、ステートマシンからのみアクセス可能で、テストフローを決定する情報が含まれています。例えば、テストの実行者によって `userdata.json` ファイルに設定された情報を使用して、特定のテストを実行する必要があるかどうかを決定できます。
ステートマシンコンテキストでは、次の形式が使用されます。
```
{
"pool": {
},
"userData": {
},
"config": {
},
"suiteFailed": true | false,
"specificTestGroups": [
""
],
"specificTestCases": [
""
],
"hasExecutionErrors": true
}
```
`pool`
テスト実行用に選択されたデバイスプールに関する情報。選択されたデバイスプールのこの情報は、`device.json` ファイルで定義された、対応する最上位レベルのデバイスプール配列要素から取得されます。
`userData`
`userdata.json` ファイル内の情報。
`config`
`config.json` ファイル内の情報。
`suiteFailed`
この値は、ステートマシンが起動すると `false` に設定されます。テストグループが `RunTask` ステートで失敗した場合、この値はステートマシン実行の残りの時間の間 `true` に設定されます。
`specificTestGroups`
テストの実行者がテストスイート全体ではなく特定のテストグループを選択して実行する場合に、このキーが作成され、特定のテストグループ ID のリストが格納されます。
`specificTestCases`
テストの実行者がテストスイート全体ではなく特定のテストケースを選択して実行する場合に、このキーが作成され、特定のテストケース ID のリストが格納されます。
`hasExecutionErrors`
ステートマシンの起動時には存在しません。いずれかのステートが実行エラーに遭遇した場合に、この変数が作成され、ステートマシンの実行の残りの時間の間 `true` に設定されます。
コンテキストは、JSONPath 表記法を使用してクエリできます。ステート定義における JSonPath クエリの構文は `{{$.query}}` です。JSONPath クエリは、一部のステートではプレースホルダー文字列として使用できます。IDT は、プレースホルダー文字列をコンテキストから評価された JSONPath クエリの値に置き換えます。プレースホルダーは、次の値に使用できます。
+ `RunTask` ステートの `TestCases` 値。
+ `Choice` ステートの `Expression` 値。
ステートマシンコンテキストからデータにアクセスする場合は、次の条件を満たしていることを確認します。
+ JSON パスが `$.` で始まっている。
+ 各値が、文字列、数値、またはブール値として評価される。
JSONPath 表記を使用してコンテキストのデータにアクセスする方法の詳細については、[IDT コンテキストを使用する](idt-context.md)を参照してください。
## 実行エラー
実行エラーとは、ステートの実行時にステートマシンが遭遇する、ステートマシン定義内のエラーです。IDT は、各エラーに関する情報を `test_manager.log` ファイルに記録し、ログメッセージをコンソールにストリーミングします。
実行エラーは、次の方法を使用して処理できます。
+ ステート定義内に [`Catch`ブロック](#catch) を追加する。
+ ステートマシンコンテキストで [`hasExecutionErrors` 値](#context) の値を確認する。
### Catch
`Catch` を使用するには、ステート定義に以下を追加します。
```
"Catch": [
{
"ErrorEquals": [
""
]
"Next": ""
}
]
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`Catch.ErrorEquals`
キャッチするエラータイプの配列。実行エラーが指定された値のいずれかと一致する場合、ステートマシンは、`Catch.Next` に指定されているステートに移行します。生成されるエラーのタイプの詳細については、各ステート定義を参照してください。
`Catch.Next`
現在のステートが、`Catch.ErrorEquals` に指定されている値のいずれかと一致する実行エラーに遭遇した場合に、移行する次のステート。
キャッチブロックは、いずれかが一致するまで順番に処理されます。どのエラーもキャッチブロックに指定されているエラーと一致しない場合、ステートマシンは実行を継続します。実行エラーは誤ったステート定義によって発生するため、ステートが実行エラーに遭遇したときは Fail ステートに移行することをお勧めします。
### hasExecutionError
一部のステートは、実行エラーに遭遇した場合、エラーを発行するだけでなく、ステートマシンコンテキストの `hasExecutionError` 値も `true` に設定します。この値を使用して、エラーがいつ発生したかを特定してから、`Choice` ステートを使用してステートマシンを `Fail` ステートに移行することができます。
この方法には次の特徴があります。
+ ステートマシンは、`hasExecutionError` に値が割り当てられていると開始しません。またこの値は、特定のステートによって設定されるまで得られません。つまり、明示的に `FallthroughOnError` の値を `false` に設定することによって、実行エラーが発生していない場合に、この値にアクセスする `Choice` ステートがステートマシンを停止しないようにする必要があります。
+ `hasExecutionError` は、一度 `true` に設定されると、false に設定されることも、コンテキストから削除されることもありません。つまり、この値は `true` に設定された初回のみ有効であり、以降のすべてのステートに対して意味のある値を提供しないことを意味します。
+ `hasExecutionError` 値は `Parallel` ステート内のすべてのブランチステートマシンで共有されるため、アクセスされる順序によっては、予期せぬ結果が発生する可能性があります。
これらの特性から、代わりに Catch ブロックを使用できる場合は、この方法を使用することはお勧めしません。
## ステートマシンの例
このセクションでは、ステートマシンの設定の例を紹介します。
**Topics**
+ [
### ステートマシンの例: 1 つのテストグループを実行する
](#single-test-group)
+ [
### ステートマシンの例: ユーザーが選択したテストグループを実行する
](#allow-specific-groups)
+ [
### ステートマシンの例: 製品機能が含まれる 1 つのテストグループを実行する
](#run-with-product-features)
+ [
### ステートマシンの例: 2 つのテストグループを並行して実行する
](#run-in-parallel)
### ステートマシンの例: 1 つのテストグループを実行する
このステートマシンの動作:
+ ID `GroupA` のテストグループを実行します。このテストグループは、`group.json` ファイルのスイート内に存在している必要があります。
+ 実行エラーをチェックし、エラーが見つかった場合は `Fail` に移行します。
+ エラーがない場合には、レポートを生成し、`Succeed` に移行します。エラーがある場合は、`Fail` に移行します。
```
{
"Comment": "Runs a single group and then generates a report.",
"StartAt": "RunGroupA",
"States": {
"RunGroupA": {
"Type": "RunTask",
"Next": "Report",
"TestGroup": "GroupA",
"Catch": [
{
"ErrorEquals": [
"RunTaskError"
],
"Next": "Fail"
}
]
},
"Report": {
"Type": "Report",
"Next": "Succeed",
"Catch": [
{
"ErrorEquals": [
"ReportError"
],
"Next": "Fail"
}
]
},
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
```
### ステートマシンの例: ユーザーが選択したテストグループを実行する
このステートマシンの動作:
+ テストの実行者が特定のテストグループを選択したかどうかをチェックします。テストの実行者がテストケースを選択するには、テストグループも選択する必要があるため、ステートマシンは特定のテストケースはチェックしません。
+ テストグループが選択されている場合:
+ 選択されたテストグループ内のテストケースを実行します。そのために、ステートマシンは、`RunTask` ステートでは、テストグループまたはテストケースを明示的に指定しません。
+ すべてのテストを実行した後にレポートを生成し、終了します。
+ テストグループが選択されていない場合:
+ テストグループ `GroupA` のテストを実行します。
+ レポートを生成して終了します。
```
{
"Comment": "Runs specific groups if the test runner chose to do that, otherwise runs GroupA.",
"StartAt": "SpecificGroupsCheck",
"States": {
"SpecificGroupsCheck": {
"Type": "Choice",
"Default": "RunGroupA",
"FallthroughOnError": true,
"Choices": [
{
"Expression": "{{$.specificTestGroups[0]}} != ''",
"Next": "RunSpecificGroups"
}
]
},
"RunSpecificGroups": {
"Type": "RunTask",
"Next": "Report",
"Catch": [
{
"ErrorEquals": [
"RunTaskError"
],
"Next": "Fail"
}
]
},
"RunGroupA": {
"Type": "RunTask",
"Next": "Report",
"TestGroup": "GroupA",
"Catch": [
{
"ErrorEquals": [
"RunTaskError"
],
"Next": "Fail"
}
]
},
"Report": {
"Type": "Report",
"Next": "Succeed",
"Catch": [
{
"ErrorEquals": [
"ReportError"
],
"Next": "Fail"
}
]
},
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
```
### ステートマシンの例: 製品機能が含まれる 1 つのテストグループを実行する
このステートマシンの動作:
+ テストグループ `GroupA` を実行します。
+ 実行エラーをチェックし、エラーが見つかった場合は `Fail` に移行します。
+ `FeatureThatDependsOnGroupA` 機能を `awsiotdevicetester_report.xml` ファイルに追加します。
+ `GroupA` が合格である場合、機能を `supported` に設定します。
+ レポートでこの機能をオプションとしてマークしません。
+ エラーがない場合には、レポートを生成し、`Succeed` に移行します。エラーがある場合は、`Fail` に移行します。
```
{
"Comment": "Runs GroupA and adds product features based on GroupA",
"StartAt": "RunGroupA",
"States": {
"RunGroupA": {
"Type": "RunTask",
"Next": "AddProductFeatures",
"TestGroup": "GroupA",
"ResultVar": "GroupA_passed",
"Catch": [
{
"ErrorEquals": [
"RunTaskError"
],
"Next": "Fail"
}
]
},
"AddProductFeatures": {
"Type": "AddProductFeatures",
"Next": "Report",
"Features": [
{
"Feature": "FeatureThatDependsOnGroupA",
"Groups": [
"GroupA"
],
"IsRequired": true
}
]
},
"Report": {
"Type": "Report",
"Next": "Succeed",
"Catch": [
{
"ErrorEquals": [
"ReportError"
],
"Next": "Fail"
}
]
},
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
```
### ステートマシンの例: 2 つのテストグループを並行して実行する
このステートマシンの動作:
+ `GroupA` および `GroupB` テストグループを並行して実行します。ブランチステートマシンの `RunTask` ステートによってコンテキストに格納された `ResultVar` 変数が `AddProductFeatures` ステートに利用可能になります。
+ 実行エラーをチェックし、エラーが見つかった場合は `Fail` に移行します。このステートマシンは、`Catch` ブロックを使用しません。この方法では、ブランチステートマシンの実行エラーが検出されないためです。
+ 合格したグループに基づいて、`awsiotdevicetester_report.xml` ファイルに機能を追加します。
+ `GroupA` が合格である場合、機能を `supported` に設定します。
+ レポートでこの機能をオプションとしてマークしません。
+ エラーがない場合には、レポートを生成し、`Succeed` に移行します。エラーがある場合は、`Fail` に移行します。
デバイスプールに 2 つのデバイスが設定されている場合、`GroupA` と `GroupB` 両方を同時に実行できます。ただし、`GroupA` または `GroupB` のどちらかに複数のテストが含まれている場合は、両方のデバイスがそれらのテストに割り当てられることがあります。デバイスが 1 つだけ設定されている場合、テストグループは順次実行されます。
```
{
"Comment": "Runs GroupA and GroupB in parallel",
"StartAt": "RunGroupAAndB",
"States": {
"RunGroupAAndB": {
"Type": "Parallel",
"Next": "CheckForErrors",
"Branches": [
{
"Comment": "Run GroupA state machine",
"StartAt": "RunGroupA",
"States": {
"RunGroupA": {
"Type": "RunTask",
"Next": "Succeed",
"TestGroup": "GroupA",
"ResultVar": "GroupA_passed",
"Catch": [
{
"ErrorEquals": [
"RunTaskError"
],
"Next": "Fail"
}
]
},
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
},
{
"Comment": "Run GroupB state machine",
"StartAt": "RunGroupB",
"States": {
"RunGroupA": {
"Type": "RunTask",
"Next": "Succeed",
"TestGroup": "GroupB",
"ResultVar": "GroupB_passed",
"Catch": [
{
"ErrorEquals": [
"RunTaskError"
],
"Next": "Fail"
}
]
},
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
]
},
"CheckForErrors": {
"Type": "Choice",
"Default": "AddProductFeatures",
"FallthroughOnError": true,
"Choices": [
{
"Expression": "{{$.hasExecutionErrors}} == true",
"Next": "Fail"
}
]
},
"AddProductFeatures": {
"Type": "AddProductFeatures",
"Next": "Report",
"Features": [
{
"Feature": "FeatureThatDependsOnGroupA",
"Groups": [
"GroupA"
],
"IsRequired": true
},
{
"Feature": "FeatureThatDependsOnGroupB",
"Groups": [
"GroupB"
],
"IsRequired": true
}
]
},
"Report": {
"Type": "Report",
"Next": "Succeed",
"Catch": [
{
"ErrorEquals": [
"ReportError"
],
"Next": "Fail"
}
]
},
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
```
# IDT テストケース実行可能ファイルを作成する
テストケース実行可能ファイルは、次の方法でテストスイートフォルダ内に作成して配置できます。
+ `test.json` ファイル内の引数または環境変数を使用して実行するテストを決定するテストスイートの場合は、テストスイート全体に対して 1 つのテストケース実行可能ファイルを作成することも、テストスイート内のテストグループごとに 1 つのテスト実行可能ファイルを作成することもできます。
+ 指定したコマンドに基づいて特定のテストを実行するテストスイートの場合は、テストスイート内のテストケースごとに 1 つのテストケース実行可能ファイルを作成します。
テストを作成するユーザーは、ユースケースに適したアプローチを決定し、それに応じてテストケースの実行可能ファイルを構成できます。各 `test.json` ファイルに、正しいテストケース実行可能ファイルのパスを指定していること、および指定した実行可能ファイルが正常に実行されることを確認してください。
すべてのデバイスにテストケースを実行する準備が整うと、IDT は以下のファイルを読み取ります。
+ `test.json`。選択されたテストケースが、開始するプロセスと設定する環境変数を決定するために使用します。
+ `suite.json`。テストスイートが、設定する環境変数を決定するために使用します。
IDT は、`test.json` ファイルに指定されているコマンドと引数に基づいて必要なテスト実行可能ファイルプロセスを開始し、必要な環境変数をこのプロセスに渡します。
## IDT クライアント SDK を使用する
IDT クライアント SDK を使用すると、IDT とテスト対象のデバイスとのやり取りに使用できる API コマンドを使用して、テスト実行可能ファイルにテストロジックを簡単に記述できます。現在、IDT では次の SDK が用意されています。
+ IDT クライアント SDK for Python
+ IDT クライアント SDK for Go
これらの SDK は、`/sdks` フォルダにあります。新しいテストケース実行可能ファイルを作成するときは、使用する SDK をテストケース実行可能ファイルが含まれるフォルダにコピーし、コード内で SDK を参照する必要があります。このセクションでは、テストケースの実行可能ファイルで使用できる API コマンドについて簡単に説明します。
**Topics**
+ [
### デバイスとのやり取り
](#api-device-interaction)
+ [
### IDT とのやり取り
](#api-idt-interaction)
+ [
### ホストとのやり取り
](#api-host-interaction)
### デバイスとのやり取り
次のコマンドを使用すると、デバイスとのやり取りや接続管理のための追加の関数を実装せずに、テスト対象デバイスと通信することができます。
`ExecuteOnDevice`
テストスイートが、SSH または Docker シェル接続をサポートするデバイス上で、シェルコマンドを実行できるようにします。
`CopyToDevice`
テストスイートが、IDT を実行するホストマシンから、SSH または Docker シェル接続をサポートするデバイス上の指定された場所にローカルファイルをコピーできるようにします。
`ReadFromDevice`
テストスイートが、UART 接続をサポートするデバイスのシリアルポートから読み取りできるようにします。
**注記**
IDT は、コンテキストからのデバイスアクセス情報を使用して確立されたデバイスへの直接接続を管理しないため、テストケース実行可能ファイルでは、デバイスとやり取り用のこれらの API コマンドを使用することをお勧めします。ただし、これらのコマンドがテストケースの要件を満たしていない場合は、IDT コンテキストからデバイスアクセス情報を取得し、この情報を使用してテストスイートからデバイスに直接接続できます。
直接接続するには、テスト対象デバイスとリソースデバイスそれぞれの `device.connectivity` フィールドと `resource.devices.connectivity` フィールドの情報を取得します。IDT コンテキスト使用の詳細については、[IDT コンテキストを使用する](idt-context.md)を参照してください。
### IDT とのやり取り
次のコマンドを使用すると、テストスイートが IDT と通信できるようになります。
`PollForNotifications`
テストスイートが IDT からの通知をチェックできるようにします。
`GetContextValue ` および `GetContextString`
テストスイートが IDT コンテキストから値を取得できるようにします。詳細については、[IDT コンテキストを使用する](idt-context.md) を参照してください。
`SendResult`
テストスイートがテストケースの結果を IDT にレポートできるようにします。このコマンドは、テストスイートの各テストケースの最後に呼び出す必要があります。
### ホストとのやり取り
次のコマンドを使用すると、テストスイートがホストマシンと通信できるようになります。
`PollForNotifications`
テストスイートが IDT からの通知をチェックできるようにします。
`GetContextValue ` および `GetContextString`
テストスイートが IDT コンテキストから値を取得できるようにします。詳細については、[IDT コンテキストを使用する](idt-context.md) を参照してください。
`ExecuteOnHost`
テストスイートがローカルマシン上でコマンドを実行できるようにし、IDT がテストケース実行可能ファイルのライフサイクルを管理できるようにします。
## IDT CLI コマンドを有効にする
`run-suite` コマンド IDT CLI には、テストの実行者がテスト実行をカスタマイズするためのいくつかのオプションがあります。テストの実行者がこれらのオプションを使用してカスタムテストスイートを実行できるようにするには、IDT CLI のサポートを実装します。サポートを実装しなくてもテストは実行できますが、一部の CLI オプションは正しく機能しません。理想的なカスタマーエクスペリエンスを提供するために、IDT CLI で `run-suite` コマンドの次の引数のサポートを実装することをお勧めします。
`timeout-multiplier`
テストの実行中にすべてのタイムアウトに適用される 1.0 より大きい値を指定します。
テストの実行者は、この引数を使用して、実行するテストケースのタイムアウトを増やすことができます。テストの実行者が `run-suite` コマンドにこの引数を指定すると、IDT はこの値を使用して IDT\$1TEST\$1TIMEOUT 環境変数の値を計算し、IDT コンテキストの `config.timeoutMultiplier` フィールドを設定します。この引数をサポートするには、以下の手順を実行する必要があります。
+ `test.json` ファイルのタイムアウト値を直接使用する代わりに、IDT\$1TEST\$1TIMEOUT 環境変数を読み取り、正しく計算されたタイムアウト値を取得します。
+ IDT コンテキストから `config.timeoutMultiplier` 値を取得し、長時間実行されるタイムアウトに適用します。
タイムアウトイベントによる早期終了の詳細については、[終了動作を指定する](#test-exec-exiting)を参照してください。
`stop-on-first-failure`
障害が発生した場合に、IDT がすべてのテスト実行を停止するように指定します。
テストの実行者がこの引数を `run-suite` コマンドを指定すると、IDT は障害が発生するとすぐにテストの実行を停止します。ただし、テストケースが並行して実行されている場合、この設定によって予期しない結果につながる可能性があります。このサポートを実装するには、テストロジックを使用して、IDT がこのイベントに遭遇した場合に、実行中のすべてのテストケースに対して、実行を停止し、一時リソースをクリーンアップし、テスト結果を IDT にレポートするように指示します。障害発生時の早期終了の詳細については、[終了動作を指定する](#test-exec-exiting)を参照してください。
`group-id` および `test-id`
IDT が選択されたテストグループまたはテストケースのみを実行するように指定します。
テストの実行者は、`run-suite` コマンドでこれらの引数を使用して、以下のテスト実行可能ファイルの動作を指定できます。
+ 指定されたテストスイート内のすべてのテストグループを実行する。
+ 指定されたテストグループ内から選択したテストを実行する。
これらの引数をサポートするには、テストスイート用のステートマシンに、自分のステートマシンの `RunTask` ステートおよび `Choice` ステートのセットが含まれている必要があります。カスタムステートマシンを使用しない場合は、デフォルトの IDT ステートマシンに必要なステートが含まれているため、追加のアクションを行う必要はありません。ただし、カスタムステートマシンを使用している場合は、サンプルとして [ステートマシンの例: ユーザーが選択したテストグループを実行する](idt-state-machine.md#allow-specific-groups) を使用して、自分のステートマシンに必要なステートを追加してください。
IDT CLI コマンドの詳細については、[カスタムテストスイートのデバッグと実行](run-tests-custom.md)を参照してください。
## イベントログの書き込み
テストの実行中は、イベントログとエラーメッセージをコンソールに書き込むために `stdout` と `stderr` にデータを送信します。コンソールメッセージの形式の詳細については、[コンソールメッセージの形式](idt-review-results-logs.md#idt-console-format)を参照してください。
IDT がテストスイートの実行を終了すると、この情報は `/results//logs` フォルダにある `test_manager.log` ファイルでも利用可能になります。
各テストケースは、テスト実行のログ (テスト対象デバイスのログを含む) を `/results/execution-id/logs` フォルダにある `_` ファイルに書き込むように設定できます。これを行うには、`testData.logFilePath` クエリを使用して IDT コンテキストからログファイルへのパスを取得し、そのパスにファイルを作成し、必要なコンテンツをそのファイルに書き込みます。IDT は、実行中のテストケースに基づいてこのパスを自動的に更新します。テストケースのログファイルを作成しないことを選択すると、そのテストケースのファイルは生成されません。
また、必要に応じて `/logs` フォルダに追加のログファイルを作成するようにテキスト実行可能ファイルをセットアップすることもできます。ファイルが上書きされないように、ログファイル名に一意のプレフィックスを指定することをお勧めします。
## IDT に結果をレポートする
IDT は、テスト結果を `awsiotdevicetester_report.xml` ファイルと `suite-name_report.xml` ファイルに書き込みます。これらのレポートファイルは、`/results//` にあります。両レポートとも、テストスイート実行の結果をキャプチャします。IDT がこれらのレポートに使用するスキーマの詳細については、[IDT テストの結果とログを確認する](idt-review-results-logs.md)を参照してください。
`suite-name_report.xml` ファイルのコンテンツを取得するには、`SendResult` コマンドを使用して、テスト実行が終了する前に、テスト結果を IDT にレポートする必要があります。IDT は、テスト結果を見つけられない場合、テストケースのエラーを発行します。次の Python の抜粋は、テスト結果を IDT に送信するコマンドを示しています。
```
request-variable = SendResultRequest(TestResult(result))
client.send_result(request-variable)
```
API を使用して結果をレポートしない場合、IDT はテストアーティファクトフォルダでテスト結果を検索します。このフォルダのパスは、IDT コンテキストの `testData.testArtifactsPath` フィールドに格納されています。このフォルダで、IDT は、アルファベット順にソートされた最初の XML ファイルをテスト結果として使用します。
テストロジックが JUnit XML 結果を生成する場合は、結果を解析してから API を使用して IDT に送信する代わりに、アーティファクトフォルダ内の XML ファイルにテスト結果を書き込んで、直接 IDT に提供することができます。
この方法を使用する場合は、テストロジックによってテスト結果が正確に要約されていること、および `suite-name_report.xml` ファイルと同じ形式で結果ファイルがフォーマットされていることを確認してください。IDT は、次の例外を除き、提供されたデータの検証を実行しません。
+ IDT は `testsuites` タグのすべてのプロパティを無視します。代わりに、レポートされた他のテストグループ結果からタグのプロパティを計算します。
+ `testsuite` 内に少なくとも 1 つの `testsuites` タグが存在する必要があります。
IDT はすべてのテストケースで同じアーティファクトフォルダを使用し、テスト実行の終了後、次のテスト実行までに結果ファイルを削除しないため、この方法を使用すると、IDT が正しくないファイルを読み取った場合に、誤ったレポートが行われる可能性もあります。IDT が適切な結果を読み取れるように、すべてのテストケースで生成される XML 結果ファイルに同じ名前を使用して、各テストケースの結果を上書きすることをお勧めします。テストスイートのレポート作成に複合的なアプローチ (一部のテストケースには XML 結果ファイルを使用し、他のテストケースには API を使用して結果を送信する) を使用することもできますが、このアプローチはお勧めしません。
## 終了動作を指定する
テキスト実行可能ファイルは、テストケースが障害やエラー結果をレポートした場合でも、常に終了コード 0 で終了するように設定します。ゼロ以外の終了コードは、テストケースが実行されなかったこと、またはテストケース実行可能ファイルが結果を IDT に通知できなかったことを示す場合にのみ使用します。IDT は、0 以外の終了コードを受信すると、テスト実行を妨げるエラーが発生したとしてテストケースをマークします。
IDT は、以下に示すイベントが発生すると、終了前にテストケースに実行の停止を要求 (または想定) することがあります。以下の情報を使用して、テストケースから以下の各イベントを検出するようにテストケース実行可能ファイルを設定します。
**タイムアウト**
テストケースが、`test.json` ファイルで指定されたタイムアウト値よりも長く実行されたときに発生します。テストの実行者が `timeout-multiplier` 引数を使用してタイムアウト乗数を指定すると、IDT はこの乗数を使用してタイムアウト値を計算します。
このイベントを検出するには、IDT\$1TEST\$1TIMEOUT 環境変数を使用します。テストの実行者がテストを起動すると、IDT は IDT\$1TEST\$1TIMEOUT 環境変数の値を計算されたタイムアウト値 (秒単位) に設定し、その変数をテストケース実行可能ファイルに渡します。この変数の値を読み取って適切なタイマーを設定します。
**割り込み**
テストの実行者が IDT に割り込むと発生します。例えば、Ctrl\$1C を押した時です。
ターミナルはすべての子プロセスに通知を伝播するため、割り込み通知を検出する通知ハンドラをテストケースに簡単に設定できます。
または、API を定期的にポーリングして、`PollForNotifications` API 応答の `CancellationRequested` ブール値をチェックできます。IDT は割り込み通知を受信すると、`CancellationRequested` ブールの値を `true` に設定します。
**最初の失敗時に停止する**
現在のテストケースと並行して実行中のテストケースが失敗し、テストの実行者が `stop-on-first-failure` 引数を使用して、障害の発生時に IDT が実行を停止するように設定しているときに発生します。
このイベントを検出するには、`PollForNotifications` API を定期的にポーリングして、API レスポンスの `CancellationRequested` ブールの値をチェックします。IDT は、最初の障害発生時に停止するように設定されている場合、障害に遭遇すると、`CancellationRequested` ブールの値を `true` に設定します。
これらのいずれかのイベントが発生すると、IDT は現在実行中のテストケースの実行が終了するまで 5 分間待機します。実行中のすべてのテストケースが 5 分以内に終了しない場合、IDT は各プロセスを強制的に停止させます。IDT は、プロセスの終了前にテスト結果を受け取らなかった場合、テストケースをタイムアウトしたとしてマークします。ベストプラクティスとして、いずれかのイベントが発生したときは、テストケースが以下のアクションを実行するようにします。
1. 通常のテストロジックの実行を停止する。
1. テスト対象デバイスのテストアーティファクトなど、すべての一時的なリソースをクリーンアップする。
1. テスト結果 (テストの失敗やエラーなど) を IDT にレポートする。
1. 終了する。
# IDT コンテキストを使用する
IDT がテストスイートを実行するとき、テストスイートは、各テストの実行方法の決定に使用できる一連のデータにアクセスできます。このデータは IDT コンテキストと呼ばれます。例えば、テストの実行者によって `userdata.json` ファイルに提供されるユーザーデータ設定は、IDT コンテキスト内でテストスイートに提供されます。
IDT コンテキストは、読み取り専用の JSON ドキュメントと考えることができます。テストスイートは、オブジェクト、配列、数値などの標準 JSON データ型を使用して、コンテキストからデータを取得することや、コンテキストにデータを書き込むことができます。
## コンテキストスキーマ
IDT コンテキストは次の形式を使用します。
```
{
"config": {
"timeoutMultiplier": timeout-multiplier
},
"device": {
},
"devicePool": {
},
"resource": {
"devices": [
{
"name": ""
}
]
},
"testData": {
"awsCredentials": {
"awsAccessKeyId": "",
"awsSecretAccessKey": "",
"awsSessionToken": ""
},
"logFilePath": "/path/to/log/file"
},
"userData": {
}
}
```
`config`
[`config.json` ファイル](gg-core.md#config-json) からの情報。`config` フィールドには、次の追加フィールドも含まれます。
`config.timeoutMultiplier`
テストスイートによって使用される任意のタイムアウト値の乗数。この値は、IDT CLI からテストの実行者によって指定されます。デフォルト値は `1` です。
`device`
テスト実行用に選択されたデバイスに関する情報。この情報は、選択されたデバイスの [`device.json` ファイル](set-config-custom.md#device-config-custom) の `devices` 配列要素に相当します。
`devicePool`
テスト実行用に選択されたデバイスプールに関する情報。この情報は、選択されたデバイスプールの `device.json` ファイルに定義されている最上位レベルのデバイスプール配列要素に相当します。
`resource`
`resource.json` ファイルからのリソースデバイスに関する情報。
`resource.devices`
この情報は、`devices` ファイルに定義されている `resource.json` 配列に相当します。各 `devices` 要素には、以下の追加フィールドが含まれています。
`resource.device.name`
リソースデバイスの名前。この値は、`test.json` ファイルで `requiredResource.name` 値に設定されます。
`testData.awsCredentials`
AWS クラウドに接続するためにテストで使用される AWS 認証情報。この情報は、`config.json` ファイルから取得されます。
`testData.logFilePath`
テストケースがログメッセージを書き込むログファイルへのパス。このファイルは、存在しない場合、テストスイートによって作成されます。
`userData`
テストの実行者によって [`userdata.json` ファイル](set-config-custom.md#userdata-config-custom) に提供された情報。
## コンテキスト内のデータにアクセスする
コンテキストは、JSONPath 表記を使用して JSON ファイルからクエリすることも、`GetContextValue` および `GetContextString` API を使用してテキスト実行可能ファイルからクエリすることもできます。IDT コンテキストにアクセスするための JSONPath 文字列の構文は、次のように異なります。
+ `suite.json` および `test.json` では、`{{query}}` を使用します。つまり、式を開始するためにルート要素 `$.` を使用しません。
+ `statemachine.json` では `{{$.query}}` を使用します。
+ API コマンドでは、コマンドに応じて `query` または `{{$.query}}` を使用します。詳細については、SDK のインラインドキュメントを参照してください。
次の表に、一般的な JSONPath 式の演算子を示します。
| Operator | Description |
| --- |--- |
| \$1 | The root element. Because the top-level context value for IDT is an object, you will typically use \$1. to start your queries. |
| .childName | Accesses the child element with name childName from an object. If applied to an array, yields a new array with this operator applied to each element. The element name is case sensitive. For example, the query to access the awsRegion value in the config object is \$1.config.awsRegion. |
| [start:end] | Filters elements from an array, retrieving items beginning from the 開始 index and going up to the end index, both inclusive. |
| [index1, index2, ... , indexN] | Filters elements from an array, retrieving items from only the specified indices. |
| [?(expr)] | Filters elements from an array using the expr expression. This expression must evaluate to a boolean value. |
フィルター式を作成するには、次の構文を使用します。
```
| operator |
```
この構文の説明は次のとおりです。
+ `jsonpath` は、標準 JSON 構文を使用する JSONPath です。
+ `value` は、標準 JSON 構文を使用するカスタム値です。
+ `operator` は、以下のいずれかの演算子です。
+ `<` (未満)
+ `<=` (以下)
+ `==` (等しい)
式内の JSONPath または値が配列、ブール値、またはオブジェクト値である場合は、これがユーザーに使用可能な唯一の二項演算子です。
+ `>=` (以上)
+ `>` (次より大きい)
+ `=~` (正規表現の一致)。この演算子をフィルター式で使用するには、式の左側の JSONPath または値が文字列に評価される必要があり、右側が [RE2 構文](https://github.com/google/re2/wiki/Syntax) に従ったパターン値である必要があります。
\$1\$1*query*\$1\$1 形式の JSONPath クエリは、プレースホルダ文字列として、`test.json` ファイルの `args` および `environmentVariables` フィールド内と、`suite.json` ファイルの `environmentVariables` フィールド内で使用できます。IDT はコンテキスト検索を実行し、クエリの評価値をフィールドに入力します。例えば、`suite.json` ファイルでは、プレースホルダー文字列を使用して、各テストケースとともに変化する環境変数の値を指定できます。IDT は、環境変数に各テストケースの正しい値を入力します。ただし、`test.json` ファイルおよび `suite.json` ファイルでプレースホルダー文字列を使用する場合は、クエリに次の考慮事項が適用されます。
+ クエリに含まれる各 `devicePool` キーは、すべて小文字にする必要があります。つまり、代わりに `devicepool` を使用します。
+ 配列には、文字列の配列のみを使用できます。さらに、配列は非標準の `item1, item2,...,itemN` の形式を使用します。配列は、要素が 1 つしか含まれていない場合、`item` としてシリアル化され、文字列フィールドと区別がつかなくなります。
+ プレースホルダーを使用してコンテキストからオブジェクトを取得することはできません。
これらの事項を考慮して、テストロジックのコンテキストへのアクセスには、`test.json` ファイルおよび `suite.json` ファイルのプレースホルダー文字列ではなく、可能な限り API を使用することをお勧めします。ただし、環境変数として設定する単一の文字列を取得するときは、JSONPath プレースホルダーを使用する方が便利な場合があります。
# テストの実行者向けの設定の設定
カスタムテストスイートを実行するには、テストの実行者は、実行するテストスイートに基づいて設定を構成する必要があります。設定は、`/configs/` フォルダにある JSON 設定ファイルテンプレートに基づいて指定します。必要に応じて、テストランナーは IDT が AWS クラウドへの接続に使用する AWS 認証情報も設定する必要があります。
テストを作成するユーザーは、[テストスイートをデバッグする](run-tests-custom.md)ために、以下に示すファイルの設定が必要になります。また、テストスイートを実行するために必要な以下の設定を設定できるように、テストの実行者に指示を提供する必要があります。
## device.json の設定
`device.json` ファイルには、テストが実行されるデバイスに関する情報 (IP アドレス、ログイン情報、オペレーティングシステム、CPU アーキテクチャなど) が含まれています。
テストの実行者は、`/configs/` フォルダにある次のテンプレート `device.json` ファイルを使用してこの情報を指定できます。
```
[
{
"id": "",
"sku": "",
"features": [
{
"name": "",
"value": "",
"configs": [
{
"name": "",
"value": ""
}
],
}
],
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh | uart | docker",
// ssh
"ip": "