翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS IoT Device Tester FreeRTOS 用
IDT for FreeRTOS は、FreeRTOS オペレーティングシステムでのデータスループットレートを評価するためのツールです。デバイステスター (IDT) は、最初にデバイスへの USB 接続または UART 接続を開きます。次に、さまざまな条件下でデバイスの機能をテストするように設定された FreeRTOS のイメージをフラッシュします。 AWS IoT Device Tester スイートは拡張可能で、IDT はお客様の AWS IoT テストオーケストレーションに使用されます。
IDT for FreeRTOS は、テスト対象のデバイスに接続されているホストコンピュータ (Windows、macOS、または Linux) 上で動作します。IDT はテストケースの設定とオーケストレーションを行い、結果を集計します。また、テストの実行を管理するためのコマンドラインインターフェイスも用意されています。
## FreeRTOS 認定スイート
IDT for FreeRTOS は、マイクロコントローラー上の FreeRTOS のポートと、信頼性が高く安全な方法で AWS IoT と効果的に通信できるかどうかを検証します。具体的には、FreeRTOS ライブラリの移植レイヤーインターフェイスが正しく実装されているかを検証します。また、 を使用してend-to-endテストも実行します AWS IoT Core。例えば、ボードで MQTT メッセージを送受信して正しく処理できるかを検証します。
FreeRTOS 認定 (FRQ) 2.0 スイートでは、「[FreeRTOS Qualification Guide](https://docs.aws.amazon.com/freertos/latest/qualificationguide/freertos-qualification.html#qualifying-your-device-idt)」で定義されている FreeRTOS-Libraries-Integration-Tests と Device Advisor のテストケースを使用します。
IDT for FreeRTOS は、FreeRTOS デバイスを AWS Partner Device Catalog に含めるために AWS Partner Network (APN) FreeRTOS に送信できるテストレポートを生成します。詳細については、[AWS デバイス認定プログラム](https://aws.amazon.com/partners/dqp/)を参照してください。
次の図に、FreeRTOS 認定のテストインフラストラクチャのセットアップを示します。
![\[がコンピュータとマイクロコントローラーと AWS IoT Core やり取りする方法を示すフローチャート。\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/images/devicetester_afr.png)
IDT for FreeRTOS は、テストリソースをテストスイートとテストグループに整理します。
+ テストスイートは、デバイスが FreeRTOS の特定のバージョンで動作することを確認するために使用されるテストグループのセットです。
+ テストグループは、BLE や MQTT メッセージングなど、特定の機能に関連する個々のテストケースのセットです。
詳細については、[テストスイートのバージョン](idt-test-suite-versions.md)を参照してください。
## カスタムテストスイートを理解する
IDT for FreeRTOS では、標準化された構成設定および結果形式とテストスイート環境が統合されています。この環境では、ご使用のデバイスやデバイスソフトウェア用にカスタムテストスイートを開発できます。独自の内部検証用のカスタムテストを追加したり、デバイス検証のためにこれらのテストを顧客に提供したりできます。
カスタムテストスイートの設定方法によって、カスタムテストスイートを実行するためにユーザーに提供する必要がある設定構成が決まります。詳細については、「[独自の IDT テストスイートを開発および実行する](idt-custom-tests.md)」を参照してください。
# AWS IoT Device Tester のサポートされているバージョン:
このトピックでは、AWS IoT Device Tester for FreeRTOS のサポートされているバージョンを示します。ベストプラクティスとして、FreeRTOS のターゲットバージョンをサポートする IDT for FreeRTOS の最新バージョンを使用することをお勧めします。IDT for FreeRTOS の各バージョンには、サポートする FreeRTOS の対応するバージョンが 1 つ以上あります。IDT for FreeRTOS の新しいバージョンのリリース時には、IDT for FreeRTOS の新しいバージョンのダウンロードをお勧めします。
ソフトウェアをダウンロードすると、ダウンロードアーカイブに含まれている AWS IoT Device Tester ライセンス契約に同意したと見なされます。
**注記**
AWS IoT Device Tester for FreeRTOS を使用する際は、最新の FreeRTOS-LTS バージョンの最新のパッチリリースに更新することをお勧めします。
**重要**
2022 年 10 月現在、AWS IoT Device Tester for AWS IoT FreeRTOS Qualification (FRQ) 1.0 では、署名付きの認定レポートは生成されません。IDT FRQ 1.0 バージョンを使用する [AWS デバイス認定プログラム](https://aws.amazon.com/partners/programs/dqp/)を通じて、[AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices) にリストする新しい AWS IoT FreeRTOS デバイスを認定することはできません。IDT FRQ 1.0 を使用して FreeRTOS デバイスを認定することはできませんが、引き続き FRQ 1.0 を使用して FreeRTOS デバイスをテストすることはできます。FreeRTOS デバイスを認定し、[AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices) にリストする際には、[IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) を使用することが推奨されます。
## AWS IoT Device Tester for FreeRTOS の最新バージョン
最新バージョンの IDT for FreeRTOS をダウンロードするには、以下のリンクを使用します。
**AWS IoT Device Tester for FreeRTOS の最新バージョン**
| **AWS IoT Device Tester バージョン** | **テストスイートのバージョン** | **サポートされている FreeRTOS バージョン** | **ダウンロードリンク** | **リリース日** | **リリースノート**: 。 |
| --- | --- | --- | --- | --- | --- |
| IDT v4.9.0 | FRQ\$12.5.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dev-test-versions-afr.html) | 2023 年 4 月 4 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dev-test-versions-afr.html) |
**注記**
複数のユーザーが NFS ディレクトリや Windows ネットワーク共有フォルダなどの共有場所から IDT を実行することはお勧めしません。このように実行すると、クラッシュまたはデータの破損が発生する可能性があります。IDT パッケージをローカルドライブに展開し、ローカルワークステーションで IDT バイナリを実行することをお勧めします。
## IDT for FreeRTOS の以前のバージョン
以下の IDT for FreeRTOS の以前のバージョンもサポートされます。
**AWS IoT Device Tester for FreeRTOS の以前のバージョン**
| **AWS IoT Device Tester バージョン** | **テストスイートのバージョン** | **サポートされている FreeRTOS バージョン** | **ダウンロードリンク** | **リリース日** | **リリースノート**: 。 |
| --- | --- | --- | --- | --- | --- |
| IDT v4.8.1 | FRQ\$12.4.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dev-test-versions-afr.html) | 2023 年 1 月 23 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dev-test-versions-afr.html) |
| IDT v4.6.0 | FRQ\$12.3.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dev-test-versions-afr.html) | 2022 年 11 月 16 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dev-test-versions-afr.html) |
| IDT v4.5.11 | FRQ\$12.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dev-test-versions-afr.html) | 2022 年 10 月 14 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dev-test-versions-afr.html) |
詳細については、[のサポートポリシーを理解する AWS IoT Device Tester](idt-support-policy.md) を参照してください。
# IDT for FreeRTOS のサポートされていないバージョン
このセクションでは、IDT for FreeRTOS のサポートされていないバージョンを示します。サポートされていないバージョンのバグ修正や更新プログラムは受けられません。詳細については、[のサポートポリシーを理解する AWS IoT Device Tester](idt-support-policy.md) を参照してください。
IDT-FreeRTOS の以下のバージョンはサポートされなくなりました。
**AWS IoT Device Tester for FreeRTOS のサポート対象外のバージョン**
| **AWS IoT Device Tester バージョン** | **テストスイートのバージョン** | **サポートされている FreeRTOS バージョン** | **リリース日** | **リリースノート**: 。 |
| --- | --- | --- | --- | --- |
| IDT v4.5.10 | FRQ\$12.1.4 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022 年 9 月 2 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.9 | FRQ\$12.1.3 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022 年 8 月 17 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.6 | FRQ\$12.1.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022 年 6 月 29 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.5 | FRQ\$12.1.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022 年 6 月 6 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.5 | FRQ\$12.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022 年 5 月 31 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.4 | FRQ\$12.0.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022 年 5 月 9 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.2 | FRQ\$11.6.2 | 202107.00 | 2022 年 1 月 25 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.0.3 | FRQ\$11.5.1 | 202012.00 | 2021 年 7 月 30 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.3.0 | FRQ\$11.6.1 | 202107.00 | 2021 年 7 月 26 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.1.0 | FRQ\$11.6.0 | 202107.00 | 2021 年 7 月 21 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.0.1 | FRQ\$11.4.1 | 202012.00 | 2021 年 1 月 19 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.4.0 | FRQ\$11.3.0 | 202011.01 | 2020 年 11 月 5 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.3.0 | FRQ\$11.2.0 | 202007.00 | 2020 年 9 月 17 日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.0.2 | FRQ\$11.0.1 | 202002.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.7.1 | FRQ\$11.0.0 | 202002.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.6.2 | FRQ\$11.0.0 | 202002.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.5.2 | FRQ\$11.0.0 | 201910.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.4.1 | FRQ\$11.0.0 | 201908.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.3.2 | FRQ\$11.0.0 | 201906.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT-FreeRTOS v1.2 | FRQ\$11.0.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/idt-unsupported-versions-afr.html) | | CMAKE ビルドシステムで FreeRTOS デバイスをテストするためのサポートが追加されました。 |
| IDT-FreeRTOS v1.1 | FRQ\$11.0.0 | | | |
| IDT-FreeRTOS v1.0 | FRQ\$11.0.0 | | | |
# IDT for FreeRTOS のダウンロード
このトピックでは、IDT for FreeRTOS をダウンロードする際のオプションについて説明します。次のいずれかのソフトウェアダウンロードリンクを使用するか、指示に従ってプログラムで IDT をダウンロードできます。
**重要**
2022 年 10 月現在、AWS IoT Device Tester for AWS IoT FreeRTOS Qualification (FRQ) 1.0 では、署名付きの認定レポートは生成されません。IDT FRQ 1.0 バージョンを使用する [AWS デバイス認定プログラム](https://aws.amazon.com/partners/programs/dqp/)を通じて、[AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices) にリストする新しい AWS IoT FreeRTOS デバイスを認定することはできません。IDT FRQ 1.0 を使用して FreeRTOS デバイスを認定することはできませんが、引き続き FRQ 1.0 を使用して FreeRTOS デバイスをテストすることはできます。FreeRTOS デバイスを認定し、[AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices) にリストする際には、[IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) を使用することが推奨されます。
**Topics**
+ [IDT を手動でダウンロードする](#idt-download-options)
+ [IDT をプログラムでダウンロード](idt-programmatic-download-process.md)
ソフトウェアをダウンロードすると、ダウンロードアーカイブに含まれている AWS IoT Device Tester ライセンス契約に同意したと見なされます。
**注記**
複数のユーザーが NFS ディレクトリや Windows ネットワーク共有フォルダなどの共有場所から IDT を実行することはお勧めしません。IDT パッケージをローカルドライブに展開し、ローカルワークステーションで IDT バイナリを実行することをお勧めします。
## IDT を手動でダウンロードする
このトピックでは、IDT for FreeRTOS のサポートされているバージョンを示します。ベストプラクティスとして、FreeRTOS のターゲットバージョンをサポートする最新バージョンの AWS IoT Device Tester を使用することをお勧めします。FreeRTOS の新しいリリースでは、AWS IoT Device Tester の新しいバージョンのダウンロードが必要になる場合があります。AWS IoT Device Tester と使用している FreeRTOS のバージョンの間に互換性がない場合、テストランの開始時に通知を受け取ります。
「[AWS IoT Device Tester のサポートされているバージョン:](dev-test-versions-afr.md)」を参照してください。
# IDT をプログラムでダウンロード
IDT には、プログラムで IDT をダウンロードできる URL の取得に使用できる API オペレーションが用意されています。この API オペレーションを使用して、IDT が最新バージョンであることを確認することもできます。この API オペレーションには、以下のエンドポイントがあります。
```
https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt
```
この API オペレーションを呼び出すには、**iot-device-tester:LatestIdt** アクションを実行するための権限が必要です。`iot-device-tester` をサービス名として指定し、AWS 署名を含めます。
## API リクエスト
HostOS - ホストマシンのオペレーティングシステム。次のオプションから選択します。
+ `mac`
+ `linux`
+ `windows`
testSuiteType - テストスイートのタイプ。次のオプションを選択します。
`FR` – IDT for FreeRTOS
ProductVersion
(オプション) FreeRTOS のバージョン。サービスは、そのバージョンの FreeRTOS と互換性のある IDT のバージョンのうち、最新のバージョンを返します。このオプションを指定しない場合、サービスは最新バージョンの IDT を返します。
## API レスポンス
API レスポンスの形式は次のとおりです。`DownloadURL` には zip ファイルが付属しています。
```
{
"Success": True or False,
"Message": Message,
"LatestBk": {
"Version": The version of the IDT binary,
"TestSuiteVersion": The version of the test suite,
"DownloadURL": The URL to download the IDT Bundle, valid for one hour
}
}
```
## 例
プログラムで IDT をダウンロードするには、以下の例を参照してください。これらの例では、`AWS_ACCESS_KEY_ID` に保存した認証情報および `AWS_SECRET_ACCESS_KEY` 環境変数が使用されます。セキュリティのベストプラクティスに従い、認証情報はコードに保存しないでください。
**Example**
**例: cURL バージョン 7.75.0 以降を使用したダウンロード (Mac および Linux)**
cURL バージョン 7.75.0 以降の場合、`aws-sigv4` フラグを使用して API リクエストに署名できます。この例では、レスポンスからのダウンロード URL の解析に [jq](https://stedolan.github.io/jq/) を使用します。
`aws-sigv4` フラグでは、curl GET リクエストのクエリパラメータが **HostOs/ProductVersion/TestSuiteType** または **HostOs/TestSuiteType** の順序である必要があります。注文が一致しない場合、API ゲートウェイから正規文字列の署名が一致しないというエラーが発生します。
オプションのパラメータ **ProductVersion** が含まれている場合、「[AWS IoT Device Tester for FreeRTOS のサポートされているバージョン](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html)」に記載されている、サポートされている製品バージョンを使用する必要があります。
+ *us-west-2* をユーザーの AWS リージョン に置き換えます。リージョンコードの一覧については、「[リージョンエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints)」を参照してください。
+ *linux* をホストマシンのオペレーティングシステムに置き換えます。
+ *202107.00* は、ご使用の FreeRTOS のバージョンに置き換えてください。
```
url=$(curl --request GET "https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt?HostOs=linux&ProductVersion=202107.00&TestSuiteType=FR" \
--user $AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY \
--aws-sigv4 "aws:amz:us-west-2:iot-device-tester" \
| jq -r '.LatestBk["DownloadURL"]')
curl $url --output devicetester.zip
```
**Example**
**例: 以前のバージョンの cURL を使用したダウンロード (Mac および Linux)**
以下の cURL コマンドを、ユーザーが署名および計算する AWS 署名とともに使用できます。AWS 署名の署名および計算方法の詳細については、「[AWS API リクエストの署名](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
+ *linux* をホストマシンのオペレーティングシステムに置き換えます。
+ *タイムスタンプ*を **20220210T004606Z** などの日付と時刻に置き換えます。
+ *日付*を **20220210** などの日付に置き換えます。
+ *AWSRegion* をユーザーの AWS リージョン に置き換えます。リージョンコードの一覧については、「[リージョンエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html)」を参照してください。
+ *AWSSignature* を、ユーザーが生成する [AWS 署名](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv-create-signed-request.html)に置き換えます。
```
curl --location --request GET 'https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt?HostOs=linux&TestSuiteType=FR' \
--header 'X-Amz-Date: Timestamp \
--header 'Authorization: AWS4-HMAC-SHA256 Credential=$AWS_ACCESS_KEY_ID/Date/AWSRegion/iot-device-tester/aws4_request, SignedHeaders=host;x-amz-date, Signature=AWSSignature'
```
**Example**
**例: Python スクリプトを使用したダウンロード**
この例では Python [リクエスト](https://pypi.org/project/requests/)ライブラリを使用しています。これは「*AWS 全般リファレンス*」の「[AWS API リクエストに対する署名](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」の Python の例から適用した例です。
+ *us-west-2* を、ご利用のリージョンに置き換えます。リージョンコードの一覧については、「[リージョンエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html)」を参照してください。
+ *linux* をホストマシンのオペレーティングシステムに置き換えます。
```
# Copyright 2010-2022 Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# This file is licensed under the Apache License, Version 2.0 (the "License").
# You may not use this file except in compliance with the License. A copy of the
#License is located at
#
# http://aws.amazon.com/apache2.0/
#
# This file is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS
# OF ANY KIND, either express or implied. See the License for the specific
# language governing permissions and limitations under the License.
# See: http://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html
# This version makes a GET request and passes the signature
# in the Authorization header.
import sys, os, base64, datetime, hashlib, hmac
import requests # pip install requests
# ************* REQUEST VALUES *************
method = 'GET'
service = 'iot-device-tester'
host = 'download.devicetester.iotdevicesecosystem.amazonaws.com'
region = 'us-west-2'
endpoint = 'https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt'
request_parameters = 'HostOs=linux&TestSuiteType=FR'
# Key derivation functions. See:
# http://docs.aws.amazon.com/general/latest/gr/signature-v4-examples.html#signature-v4-examples-python
def sign(key, msg):
return hmac.new(key, msg.encode('utf-8'), hashlib.sha256).digest()
def getSignatureKey(key, dateStamp, regionName, serviceName):
kDate = sign(('AWS4' + key).encode('utf-8'), dateStamp)
kRegion = sign(kDate, regionName)
kService = sign(kRegion, serviceName)
kSigning = sign(kService, 'aws4_request')
return kSigning
# Read AWS access key from env. variables or configuration file. Best practice is NOT
# to embed credentials in code.
access_key = os.environ.get('AWS_ACCESS_KEY_ID')
secret_key = os.environ.get('AWS_SECRET_ACCESS_KEY')
if access_key is None or secret_key is None:
print('No access key is available.')
sys.exit()
# Create a date for headers and the credential string
t = datetime.datetime.utcnow()
amzdate = t.strftime('%Y%m%dT%H%M%SZ')
datestamp = t.strftime('%Y%m%d') # Date w/o time, used in credential scope
# ************* TASK 1: CREATE A CANONICAL REQUEST *************
# http://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html
# Step 1 is to define the verb (GET, POST, etc.)--already done.
# Step 2: Create canonical URI--the part of the URI from domain to query
# string (use '/' if no path)
canonical_uri = '/latestidt'
# Step 3: Create the canonical query string. In this example (a GET request),
# request parameters are in the query string. Query string values must
# be URL-encoded (space=%20). The parameters must be sorted by name.
# For this example, the query string is pre-formatted in the request_parameters variable.
canonical_querystring = request_parameters
# Step 4: Create the canonical headers and signed headers. Header names
# must be trimmed and lowercase, and sorted in code point order from
# low to high. Note that there is a trailing \n.
canonical_headers = 'host:' + host + '\n' + 'x-amz-date:' + amzdate + '\n'
# Step 5: Create the list of signed headers. This lists the headers
# in the canonical_headers list, delimited with ";" and in alpha order.
# Note: The request can include any headers; canonical_headers and
# signed_headers lists those that you want to be included in the
# hash of the request. "Host" and "x-amz-date" are always required.
signed_headers = 'host;x-amz-date'
# Step 6: Create payload hash (hash of the request body content). For GET
# requests, the payload is an empty string ("").
payload_hash = hashlib.sha256(('').encode('utf-8')).hexdigest()
# Step 7: Combine elements to create canonical request
canonical_request = method + '\n' + canonical_uri + '\n' + canonical_querystring + '\n' + canonical_headers + '\n' + signed_headers + '\n' + payload_hash
# ************* TASK 2: CREATE THE STRING TO SIGN*************
# Match the algorithm to the hashing algorithm you use, either SHA-1 or
# SHA-256 (recommended)
algorithm = 'AWS4-HMAC-SHA256'
credential_scope = datestamp + '/' + region + '/' + service + '/' + 'aws4_request'
string_to_sign = algorithm + '\n' + amzdate + '\n' + credential_scope + '\n' + hashlib.sha256(canonical_request.encode('utf-8')).hexdigest()
# ************* TASK 3: CALCULATE THE SIGNATURE *************
# Create the signing key using the function defined above.
signing_key = getSignatureKey(secret_key, datestamp, region, service)
# Sign the string_to_sign using the signing_key
signature = hmac.new(signing_key, (string_to_sign).encode('utf-8'), hashlib.sha256).hexdigest()
# ************* TASK 4: ADD SIGNING INFORMATION TO THE REQUEST *************
# The signing information can be either in a query string value or in
# a header named Authorization. This code shows how to use a header.
# Create authorization header and add to request headers
authorization_header = algorithm + ' ' + 'Credential=' + access_key + '/' + credential_scope + ', ' + 'SignedHeaders=' + signed_headers + ', ' + 'Signature=' + signature
# The request can include any headers, but MUST include "host", "x-amz-date",
# and (for this scenario) "Authorization". "host" and "x-amz-date" must
# be included in the canonical_headers and signed_headers, as noted
# earlier. Order here is not significant.
# Python note: The 'host' header is added automatically by the Python 'requests' library.
headers = {'x-amz-date':amzdate, 'Authorization':authorization_header}
# ************* SEND THE REQUEST *************
request_url = endpoint + '?' + canonical_querystring
print('\nBEGIN REQUEST++++++++++++++++++++++++++++++++++++')
print('Request URL = ' + request_url)
response = requests.get(request_url, headers=headers)
print('\nRESPONSE++++++++++++++++++++++++++++++++++++')
print('Response code: %d\n' % response.status_code)
print(response.text)
download_url = response.json()["LatestBk"]["DownloadURL"]
r = requests.get(download_url)
open('devicetester.zip', 'wb').write(r.content)
```
# IDT と FreeRTOS 認定スイート 2.0 (FRQ 2.0)
FreeRTOS 認定スイート 2.0 は FreeRTOS 認定スイートの更新バージョンです。開発者は FRQ 2.0 を使用することをお勧めします。FRQ 2.0 は、FreeRTOS 長期サポート (LTS) ライブラリを実行するデバイスを認定するための関連テストケースで構成されているためです。
IDT for FreeRTOS は、マイクロコントローラー上の FreeRTOS のポートと、それが効果的に通信するかどうかを検証します AWS IoT。具体的には、移植レイヤーインターフェイスが FreeRTOS ライブラリと連動していることを検証し、FreeRTOS テストリポジトリが正しく実装されているかを検証します。また、 を使用してend-to-endテストも実行します AWS IoT Core。IDT for FreeRTOS で実行されるテストは、[FreeRTOS GitHub リポジトリ](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests)で定義されています。
IDT for FreeRTOS は、テスト対象のマイクロコントローラーデバイス上でフラッシュする組み込みアプリケーションとしてテストを実行します。アプリケーションのバイナリイメージには、FreeRTOS、移植される FreeRTOS インターフェイス、およびボードデバイスドライバーが含まれています。テストの目的は、移植された FreeRTOS インターフェイスがデバイスドライバー上で正しく機能するかどうかを検証することです。
IDT for FreeRTOS はテストレポートを生成し、 に送信 AWS IoT して AWS Partner Device Catalog にハードウェアを一覧表示できます。詳細については、[AWS デバイス認定プログラム](https://aws.amazon.com/partners/dqp/)を参照してください。
IDT for FreeRTOS は、テスト対象のデバイスに接続されているホストコンピュータ (Windows、macOS、または Linux) 上で動作します。IDT はテストケースの設定とオーケストレーションを行い、結果を集計します。また、テストの実行を管理するためのコマンドラインインターフェイスも用意されています。
デバイスをテストするために、IDT for FreeRTOS は AWS IoT things、FreeRTOS グループ、Lambda 関数などのリソースを作成します。これらのリソースを作成するために、IDT for FreeRTOS は で設定された AWS 認証情報`config.json`を使用してユーザーに代わって API コールを行います。これらのリソースは、テスト中にさまざまなタイミングでプロビジョニングされます。
IDT for FreeRTOS をホストコンピュータで実行すると、次のステップが実行されます。
1. デバイスおよび認証情報の設定をロードして検証します。
1. 必要なローカルリソースとクラウドリソースを使用して選択したテストを実行します。
1. ローカルリソースとクラウドリソースをクリーンアップします。
1. ボードが資格に必要なテストに合格したかどうかを示すテストレポートを生成します。
# LTS 認定の前提条件を設定する
このセクションでは、 でマイクロコントローラーをテストするための前提条件について説明します AWS IoT Device Tester。
## FreeRTOS 認定の準備をする
**注記**
AWS IoT Device Tester for FreeRTOS では、最新の FreeRTOS-LTS バージョンの最新のパッチリリースを使用することを強くお勧めします。
IDT for FRQ 2.0 は FreeRTOS の認定です。IDT FRQ 2.0 を実行して認定を行う前に、「*FreeRTOS 認定ガイド*」の「[ボードを資格認定する](https://docs.aws.amazon.com/freertos/latest/qualificationguide/freertos-qualification.html)」を完了する必要があります。ライブラリの移植、テスト、および `manifest.yml` のセットアップについては、「*FreeRTOS 移植ガイド*」の「[FreeRTOS ライブラリの移植](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting.html)」を参照してください。FRQ 2.0 には、認定のためのさまざまなプロセスが含まれています。詳細については、「FreeRTOS 認定ガイド」で[認定に関する最新の変更内容](https://docs.aws.amazon.com/freertos/latest/qualificationguide/latest-changes.html)を参照してください。
IDT を実行するには、[FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests) リポジトリが存在している必要があります。このリポジトリを複製してソースプロジェクトに移植する方法については、「[README.md](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests/blob/main/README.md)」を参照してください。FreeRTOS-Libraries-Integration-Tests には、IDT を実行するために、プロジェクトのルートに `manifest.yml` が含まれている必要があります。
**注記**
IDT は、テストリポジトリでの `UNITY_OUTPUT_CHAR` の実装に依存しています。テスト出力ログとデバイスログは、相互にインターリーブしないようにする必要があります。詳細については、「*FreeRTOS 移植ガイド*」の「[ライブラリロギングマクロの実装](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-library-logging-macros.html)」セクションを参照してください。
## IDT for FreeRTOS のダウンロード
どのバージョンの FreeRTOS にも、認定テストの実行に対応する IDT for FreeRTOS のバージョンがあります。IDT for FreeRTOS の適切なバージョンを [AWS IoT Device Tester for FreeRTOS のサポートされているバージョンからダウンロードします](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html)。
IDT for FreeRTOS を、ファイルシステム上で読み取りおよび書き込みアクセス許可を持っている場所に抽出します。Microsoft Windows ではパスの長さに文字数の制限があるため、IDT for FreeRTOS は、`C:\` や `D:\` などのルートディレクトリに抽出してください。
**注記**
NFS ディレクトリや Windows ネットワーク共有フォルダなどの共有場所から複数のユーザーが IDT を実行しないようにする必要があります。そうしないと、クラッシュやデータ破損が発生します。IDT パッケージをローカルドライブに抽出することをお勧めします。
## Git のダウンロード
IDT では、ソースコードの整合性を確保するための前提条件として、Git がインストールされている必要があります。
Git をインストールするには、[GitHub](https://github.com/git-guides/install-git) ガイドの手順を実行します。現在インストールされている Git のバージョンを確認するには、ターミナルで `git --version` コマンドを入力します。
**警告**
IDT は Git を使用して、ディレクトリのステータスがクリーンであるかダーティであるかに沿って動作します。Git がインストールされていない場合、`FreeRTOSIntegrity` テストグループは失敗するか、正常に実行されません。IDT が `git executable not found` や `git command not found` などのエラーを返す場合は、Git をインストールまたは再インストールしてから再試行してください。
**Topics**
+ [FreeRTOS 認定の準備をする](#idt-preparing-qualification)
+ [IDT for FreeRTOS のダウンロード](#idt-download-dev-tester-afr)
+ [Git のダウンロード](#idt-download-git)
+ [AWS アカウントを作成する](#lts-config-aws-account)
+ [AWS IoT Device Tester マネージドポリシー](#managed-policy)
+ [(オプション) をインストールする AWS Command Line Interface](#install-cli)
## AWS アカウントを作成する
**注記**
IDT 認定スイートは、以下でのみサポートされています。 AWS リージョン
米国東部 (バージニア北部)
米国西部 (オレゴン)
アジアパシフィック (東京)
欧州 (アイルランド)
デバイスをテストするために、IDT for FreeRTOS は AWS IoT モノ、FreeRTOS グループ、Lambda 関数などのリソースを作成します。これらのリソースを作成するには、IDT for FreeRTOS では、 AWS アカウントと、テストの実行中にユーザーに代わってリソースにアクセスするアクセス許可を IDT for FreeRTOS に付与する IAM ポリシーを作成して設定する必要があります。
次の手順では、 AWS アカウントを作成して設定します。
1. AWS アカウントが既にある場合は、次のステップに進みます。それ以外の場合は、[AWS アカウント](https://aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/)を作成します。
1. 「[IAM ロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)」のステップを実行します。この時点では、アクセス許可やポリシーを追加しないでください。
1. OTA 認定テストを実行するには、ステップ 4 に進みます。それ以外の場合は、ステップ 5 に進みます。
1. OTA IAM アクセス許可インラインポリシーを IAM ロールにアタッチします。
1.
**重要**
次のポリシーテンプレートは、ロールの作成、ポリシーの作成、およびロールへのポリシーのアタッチを行うアクセス許可を IDT に付与します。IDT for FreeRTOS は、ロールを作成するテストに、これらのアクセス許可を使用します。ポリシーテンプレートはユーザーに管理者権限を提供しませんが、アクセス権限を使用して AWS アカウントへの管理者アクセスを取得できます。
1. 以下のステップを実行して、必要なアクセス許可を IAM ロールにアタッチします。
1. **[アクセス許可]** ページで、**[アクセス許可の追加]** を選択します。
1. **[インラインポリシーを作成]** を選択します。
1. [**JSON**] タブを選択し、次のアクセス許可を [**JSON**] テキストボックスにコピーします。中国リージョン以外の場合は、**[ほとんどのリージョン]** のテンプレートを使用します。中国リージョンの場合は、**[北京および寧夏リージョン]** のテンプレートを使用します。
------
#### [ Most Regions ]
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iotdeviceadvisor:*",
"Resource": [
"arn:aws:iotdeviceadvisor:*:*:suiterun/*/*",
"arn:aws:iotdeviceadvisor:*:*:suitedefinition/*"
]
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/idt*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "iotdeviceadvisor.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke*",
"iam:ListRoles",
"iot:Connect",
"iot:CreateJob",
"iot:DeleteJob",
"iot:DescribeCertificate",
"iot:DescribeEndpoint",
"iot:DescribeJobExecution",
"iot:DescribeJob",
"iot:DescribeThing",
"iot:GetPolicy",
"iot:ListAttachedPolicies",
"iot:ListCertificates",
"iot:ListPrincipalPolicies",
"iot:ListThingPrincipals",
"iot:ListThings",
"iot:Publish",
"iot:UpdateThingShadow",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:PutLogEvents",
"logs:PutRetentionPolicy"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iotdeviceadvisor:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "logs:DeleteLogGroup",
"Resource": "arn:aws:logs:*:*:log-group:/aws/iot/deviceadvisor/*"
},
{
"Effect": "Allow",
"Action": "logs:GetLogEvents",
"Resource": "arn:aws:logs:*:*:log-group:/aws/iot/deviceadvisor/*:log-stream:*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreatePolicy",
"iam:DetachRolePolicy",
"iam:DeleteRolePolicy",
"iam:DeletePolicy",
"iam:CreateRole",
"iam:DeleteRole",
"iam:AttachRolePolicy"
],
"Resource": [
"arn:aws:iam::*:policy/idt*",
"arn:aws:iam::*:role/idt*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameters"
],
"Resource": [
"arn:aws:ssm:*::parameter/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:RunInstances",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateKeyPair",
"ec2:DeleteKeyPair"
],
"Resource": [
"arn:aws:ec2:*:*:key-pair/idt-ec2-ssh-key-*"
]
},
{
"Effect": "Allow",
"Condition": {
"StringEqualsIgnoreCase": {
"aws:ResourceTag/Owner": "IoTDeviceTester"
}
},
"Action": [
"ec2:TerminateInstances",
"ec2:DeleteSecurityGroup",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupIngress"
],
"Resource": [
"*"
]
}
]
}
```
------
------
#### [ Beijing and Ningxia Regions ]
次のポリシーテンプレートは、北京および寧夏リージョンで使用できます。
------
1. 完了したら、[**ポリシーの確認**] を選択します。
1. ポリシー名として **IDTFreeRTOSIAMPermissions** と入力します。
1. [**Create policy**] (ポリシーの作成) を選択します。
1. **AWSIoTDeviceTesterForFreeRTOSFullAccess** を IAM ロールにアタッチします。
1. 必要なアクセス許可を IAM ロールにアタッチするには、次の手順を実行します。
1. **[アクセス許可]** ページで、**[アクセス許可の追加]** を選択します。
1. **ポリシーのアタッチ** を選択します。
1. **AWSIoTDeviceTesterForFreeRTOSFullAccess** ポリシーを見つけます。チェックボックスをオンにします。
1. [**Add permissions (許可の追加)**] を選択します。
1. IDT の認証情報をエクスポートします。詳細については、「[Getting IAM role credentials for CLI access](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtogetcredentials.html)」を参照してください。
## AWS IoT Device Tester マネージドポリシー
`AWSIoTDeviceTesterForFreeRTOSFullAccess` 管理ポリシーには、バージョンチェック、自動更新機能、メトリクスの収集に関する以下の AWS IoT Device Tester アクセス許可が含まれています。
+ `iot-device-tester:SupportedVersion`
サポートされている製品、テストスイート、IDT バージョンのリストを取得する AWS IoT Device Tester アクセス許可を付与します。
+ `iot-device-tester:LatestIdt`
ダウンロード可能な最新の IDT バージョンを取得する AWS IoT Device Tester アクセス許可を付与します。
+ `iot-device-tester:CheckVersion`
IDT、テストスイート、製品のバージョンの互換性をチェックする AWS IoT Device Tester アクセス許可を付与します。
+ `iot-device-tester:DownloadTestSuite`
テストスイートの更新をダウンロードする AWS IoT Device Tester アクセス許可を付与します。
+ `iot-device-tester:SendMetrics`
AWS IoT Device Tester 内部使用状況に関するメトリクスを収集する AWS アクセス許可を付与します。
## (オプション) をインストールする AWS Command Line Interface
一部のオペレーションを実行する AWS CLI には、 を使用することをお勧めします。 AWS CLI がインストールされていない場合は、「[AWS CLIのインストール](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)」の手順を実行します。
コマンドライン**aws configure**から を実行して、使用する AWS CLI AWS リージョンの を設定します。IDT for FreeRTOS をサポートする AWS リージョンについては、[AWS 「リージョンとエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html#amazon-freertos-ota-control)」を参照してください。**aws configure** の詳細については、[**aws configure** を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)を参照してください。
# マイクロコントローラーボードの最初のテスト
IDT for FreeRTOS を使用して、FreeRTOS ライブラリの実装をテストできます。ボードのデバイスドライバー用に FreeRTOS ライブラリを移植したら、 AWS IoT Device Tester を使用してマイクロコントローラーボードで認定テストを実行します。
## ライブラリ移植レイヤーを追加する
デバイス用に FreeRTOS を移植するには、「[FreeRTOS 移植ガイド](https://docs.aws.amazon.com/freertos/latest/portingguide/porting-guide.html)」を参照してください。FreeRTOS テストリポジトリを実装して FreeRTOS レイヤーを移植する際には、テストリポジトリを含む各ライブラリへのパスを指定した `manifest.yml` を提供する必要があります。このファイルは、ソースコードのルートディレクトリにあります。詳細については、「[マニフェストファイルの手順](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist-manifest-instr.html)」を参照してください。
## AWS クラウドと通信 AWS IoT Device Tester するように の AWS 認証情報を設定する
クラウドと AWS 通信 AWS IoT Device Tester するには、 の AWS 認証情報を設定する必要があります。詳細については、[開発用の AWS 認証情報とリージョンのセットアップ](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html)を参照してください。有効な AWS 認証情報は`devicetester_extract_location/devicetester_freertos_[win|mac|linux]/configs/config.json`設定ファイルで指定されます。
```
"auth": {
"method": "environment"
}
"auth": {
"method": "file",
"credentials": {
"profile": ""
}
}
```
`config.json` ファイルの `auth` 属性には、 AWS 認証を制御するメソッドフィールドがあり、ファイルまたは環境として宣言できます。フィールドを環境に設定すると、ホストマシンの環境変数から AWS 認証情報が取得されます。このフィールドを file に設定すると、指定されたプロファイルが `.aws/credentials` 設定ファイルからインポートされます。
**Topics**
+ [ライブラリ移植レイヤーを追加する](#lts-add-port-layer)
+ [AWS クラウドと通信 AWS IoT Device Tester するように の AWS 認証情報を設定する](#lts-cfg-aws-afr)
+ [IDT for FreeRTOS でデバイスプールを作成する](lts-cfg-dt-dp.md)
+ [ビルド、フラッシュ、テスト設定を設定する](lts-cfg-dt-ud.md)
# IDT for FreeRTOS でデバイスプールを作成する
テストするデバイスは、デバイスプールにまとめられます。各デバイスプールは、1 つ以上の同一デバイスで構成されます。IDT for FreeRTOS を設定して、プール内の 1 つのデバイスまたは複数のデバイスをテストすることもがきます。認定プロセスを迅速化するために、IDT for FreeRTOS は、同じ仕様を持つデバイスを並行してテストできます。その際、ラウンドロビンメソッドを使用し、デバイスプール内の各デバイスで異なるテストグループが実行されます。
`device.json` ファイルの最上位には配列があります。各配列属性は新しいデバイスプールです。各デバイスプールにはデバイス配列属性があり、複数のデバイスが宣言されています。テンプレートには 1 つのデバイスプールがあり、そのデバイスプールにはデバイスが 1 つしかありません。1 つ以上のデバイスをデバイスプールに追加するには、`configs` フォルダにある `device.json` テンプレートの `devices` セクションを編集します。
**注記**
同じプール内のすべてのデバイスの技術仕様と SKU は同じでなければなりません。IDT for FreeRTOS は、異なるテストグループに対してソースコードの並列ビルドを可能にするため、ソースコードを IDT for FreeRTOS の抽出されたフォルダにある結果フォルダにコピーします。ビルドコマンドまたはフラッシュコマンドでは、`testdata.sourcePath` 変数を使用してソースコードパスを参照する必要があります。IDT for FreeRTOS は、この変数を、コピーしたソースコードの一時パスで置き換えます。詳細については、「[IDT for FreeRTOS 変数](lts-dt-vars.md)」を参照してください。
次の例では、`device.json` ファイルを使用して、複数のデバイスが含まれるデバイスプールを作成しました。
```
[
{
"id": "pool-id",
"sku": "sku",
"features": [
{
"name": "Wifi",
"value": "Yes | No"
},
{
"name": "Cellular",
"value": "Yes | No"
},
{
"name": "BLE",
"value": "Yes | No"
},
{
"name": "PKCS11",
"value": "RSA | ECC | Both"
},
{
"name": "OTA",
"value": "Yes | No",
"configs": [
{
"name": "OTADataPlaneProtocol",
"value": "MQTT | HTTP | None"
}
]
},
{
"name": "KeyProvisioning",
"value": "Onboard | Import | Both | No"
}
],
"devices": [
{
"id": "device-id",
"connectivity": {
"protocol": "uart",
"serialPort": "/dev/tty*"
},
"secureElementConfig" : {
"publicKeyAsciiHexFilePath": "absolute-path-to/public-key-txt-file: contains-the-hex-bytes-public-key-extracted-from-onboard-private-key",
"publiDeviceCertificateArn": "arn:partition:iot:region:account-id:resourcetype:resource:qualifier",
"secureElementSerialNumber": "secure-element-serialNo-value",
"preProvisioned" : "Yes | No",
"pkcs11JITPCodeVerifyRootCertSupport": "Yes | No"
},
"identifiers": [
{
"name": "serialNo",
"value": "serialNo-value"
}
]
}
]
}
]
```
次の属性は、`device.json` ファイルで使用されます。
** `id` **
デバイスのプールを一意に識別するユーザー定義の英数字の ID。プールに属するデバイスは同じタイプであることが必要です。テストスイートを実行するとき、プールのデバイスを使用してワークロードが並列化されます。
** `sku` **
テスト対象であるボードを一意に識別する英数字の値。SKU は、適格性が確認されたボードの追跡に使用されます。
AWS Partner Device Catalog でボードを一覧表示する場合、ここで指定する SKU は、一覧表示プロセスで使用する SKU と一致する必要があります。
** `features` **
デバイスのサポートされている機能を含む配列。 はこの情報 AWS IoT Device Tester を使用して、実行する認定テストを選択します。
サポートされている値は以下のとおりです。
** `Wifi` **
ボードが Wi-Fi 機能を備えているかどうかを示します。
** `Cellular` **
ボードがセルラー機能を備えているかどうかを示します。
** `PKCS11` **
ボードがサポートする公開鍵暗号化アルゴリズムを指定します。資格認定には PKCS11 が必要です。サポートされている値は、`ECC`、`RSA`、および `Both` です。`Both` は、ボードが `ECC` と `RSA` の両方をサポートしていることを示します。
** `KeyProvisioning` **
信頼された X.509 クライアント証明書をボードに書き込む方法を指定します。
有効な値は、`Import`、`Onboard`、`Both`、および `No` です。認定には、`Onboard`、`Both`、または `No` キープロビジョニングが必要です。`Import` 単独では認定に有効なオプションではありません。
+ `Import` は、ボードがプライベートキーのインポートを許可している場合にのみ使用します。`Import` の選択は認定には有効な構成ではないため、テスト目的、特に PKCS11 テストケースでのみ使用してください。`Onboard`、`Both` または `No` は認定に必須です。
+ ボードがオンボードプライベートキーをサポートしている場合 (例えば、デバイスに安全な要素がある場合、または独自のデバイスのキーペアと証明書を生成する場合) は、`Onboard` を使用します。各デバイスセクションに `secureElementConfig` 要素を追加し、`publicKeyAsciiHexFilePath` フィールドにパブリックキーファイルへの絶対パスを入力していることを確認します。
+ `Both` は、ボードがキープロビジョニングのためにプライベートキーのインポートとオンボードキーの生成の両方をサポートしている場合に使用します。
+ `No` は、ボードがキープロビジョニングをサポートしていない場合に使用します。`No` は、デバイスも事前プロビジョニングされている場合のにみ有効なオプションです。
** `OTA` **
ボードが無線 (OTA) による更新機能をサポートしているかどうかを示します。`OtaDataPlaneProtocol` 属性は、デバイスがサポートする OTA データプレーンプロトコルを示します。認定には、HTTP または MQTT データプレーンプロトコルのいずれかを使用する OTA が必要です。テスト中に OTA テストの実行をスキップするには、OTA 機能を `No` に、`OtaDataPlaneProtocol` 属性を `None` に設定します。これは認定の実行にはなりません。
** `BLE` **
ボードが Bluetooth Low Energy (BLE) をサポートしているかどうかを示します。
** `devices.id` **
テスト対象のデバイスのユーザー定義の一意の識別子。
** `devices.connectivity.serialPort` **
テスト対象であるデバイスへの接続に使用される、ホストコンピュータのシリアルポート。
** `devices.secureElementConfig.PublicKeyAsciiHexFilePath` **
ボードが `pre-provisioned` ではない場合、または `PublicDeviceCertificateArn` が指定されていない場合は必須です。`Onboard` はキープロビジョニングの必須タイプであるため、現在 FullTransportInterfaceTLS テストグループでは、このフィールドは必須です。デバイスが `pre-provisioned` の場合、`PublicKeyAsciiHexFilePath` はオプションであり、含める必要はありません。
次のブロックは、`Onboard` プライベートキーから抽出された 16 進バイトのパブリックキーを含むファイルへの絶対パスです。
```
3059 3013 0607 2a86 48ce 3d02 0106 082a
8648 ce3d 0301 0703 4200 04cd 6569 ceb8
1bb9 1e72 339f e8cf 60ef 0f9f b473 33ac
6f19 1813 6999 3fa0 c293 5fae 08f1 1ad0
41b7 345c e746 1046 228e 5a5f d787 d571
dcb2 4e8d 75b3 2586 e2cc 0c
```
パブリックキーが .der 形式の場合は、パブリックキーを直接 16 進エンコードして 16 進ファイルを生成できます。
.der パブリックキーから 16 進ファイルを生成するには、次の **xxd** コマンドを入力します。
```
xxd -p pubkey.der > outFile
```
パブリックキーが.pem 形式の場合、base64 でエンコードされたヘッダーとフッターを抽出し、それをバイナリ形式にデコードできます。その後、バイナリ文字列を 16 進エンコードして 16 進ファイルを生成します。
.pem パブリックキーの 16 進ファイルを生成するには、以下を行います。
1. 次の **base64** コマンドを実行して、パブリックキーから base64 ヘッダーとフッターを削除します。その後、`base64key` という名前のデコードされたキーが、ファイル `pubkey.der` に出力されます。
```
base64 —decode base64key > pubkey.der
```
1. 次の **xxd** コマンドを実行して、`pubkey.der` を 16 進形式に変換します。結果として生成されたキーは、`outFile` として保存されます。
```
xxd -p pubkey.der > outFile
```
** `devices.secureElementConfig.PublicDeviceCertificateArn` **
アップロード先のセキュア要素からの証明書の ARN AWS IoT Core。証明書を にアップロードする方法については AWS IoT Core、「 *AWS IoT デベロッパーガイド*」の[「X.509 クライアント証明書](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html)」を参照してください。
** `devices.secureElementConfig.SecureElementSerialNumber` **
(オプション) 安全なエレメントのシリアル番号。シリアル番号は、オプションで JITR キープロビジョニング用のデバイス証明書を作成するために使用されます。
** `devices.secureElementConfig.preProvisioned` **
(オプション) デバイスにロックダウンされた認証情報を持つ事前プロビジョニングされたセキュア要素があり、オブジェクトをインポート、作成、または破棄できない場合は、「Yes」に設定します。この属性が **Yes** に設定されている場合は、対応する pkcs11 ラベルを指定する必要があります。
** `devices.secureElementConfig.pkcs11JITPCodeVerifyRootCertSupport` **
(オプション) デバイスの corePKCS11 実装が JITP 用のストレージをサポートしている場合は **Yes** に設定します。これにより、コア PKCS 11 をテストするときに JITP `codeverify` テストが可能になり、コード検証キー、JITP 証明書、およびルート証明書 PKCS 11 ラベルを指定する必要があります。
** `identifiers` **
(オプション) 任意の名前と値のペアの配列。これらの値は、次のセクションで説明されているビルドコマンドやフラッシュコマンドで使用できます。
# ビルド、フラッシュ、テスト設定を設定する
IDT for FreeRTOS は、自動的にテストをビルドしてボードにフラッシュします。これを有効にするには、ハードウェアに対してビルドコマンドとフラッシュコマンドを実行するように IDT を設定する必要があります。ビルドとフラッシュのコマンド設定は、`config` フォルダにある `userdata.json` テンプレートファイルで設定されています。
# デバイスをテストするための設定
ビルド、フラッシュ、およびテストの設定は、`configs/userdata.json` ファイルで行います。次の JSON の例は、複数のデバイスをテストするために IDT for FreeRTOS を設定する方法を示します。
```
{
"sourcePath": "",
"retainModifiedSourceDirectories": true | false,
"freeRTOSVersion": "",
"freeRTOSTestParamConfigPath": "{{testData.sourcePath}}/path/from/source/path/to/test_param_config.h",
"freeRTOSTestExecutionConfigPath": "{{testData.sourcePath}}/path/from/source/path/to/test_execution_config.h",
"buildTool": {
"name": "your-build-tool-name",
"version": "your-build-tool-version",
"command": [
" -any-additional-flags {{testData.sourcePath}}"
]
},
"flashTool": {
"name": "your-flash-tool-name",
"version": "your-flash-tool-version",
"command": [
" -any-additional-flags {{testData.sourcePath}} -any-additional-flags"
]
},
"testStartDelayms": 0,
"echoServerConfiguration": {
"keyGenerationMethod": "EC | RSA",
"serverPort": 9000
},
"otaConfiguration": {
"otaE2EFirmwarePath": "{{testData.sourcePath}}/relative-path-to/ota-image-generated-in-build-process",
"otaPALCertificatePath": "/path/to/ota/pal/certificate/on/device",
"deviceFirmwarePath" : "/path/to/firmware/image/name/on/device",
"codeSigningConfiguration": {
"signingMethod": "AWS | Custom",
"signerHashingAlgorithm": "SHA1 | SHA256",
"signerSigningAlgorithm": "RSA | ECDSA",
"signerCertificate": "arn:partition:service:region:account-id:resource:qualifier | /absolute-path-to/signer-certificate-file",
"untrustedSignerCertificate": "arn:partition:service:region:account-id:resourcetype:resource:qualifier",
"signerCertificateFileName": "signerCertificate-file-name",
"compileSignerCertificate": true | false,
// ***********Use signerPlatform if you choose AWS for signingMethod***************
"signerPlatform": "AmazonFreeRTOS-Default | AmazonFreeRTOS-TI-CC3220SF"
]
}
},
**********
This section is used for PKCS #11 labels of private key, public key, device certificate, code verification key, JITP certificate, and root certificate.
When configuring PKCS11, you set up labels and you must provide the labels of the device certificate, public key,
and private key for the key generation type (EC or RSA) it was created with. If your device supports PKCS11 storage of JITP certificate,
code verification key, and root certificate, set 'pkcs11JITPCodeVerifyRootCertSupport' to 'Yes' in device.json and provide the corresponding labels.
**********
"pkcs11LabelConfiguration":{
"pkcs11LabelDevicePrivateKeyForTLS": "",
"pkcs11LabelDevicePublicKeyForTLS": "",
"pkcs11LabelDeviceCertificateForTLS": "",
"pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS": "",
"pkcs11LabelPreProvisionedECDevicePublicKeyForTLS": "",
"pkcs11LabelPreProvisionedECDeviceCertificateForTLS": "",
"pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS": "",
"pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS": "",
"pkcs11LabelPreProvisionedRSADeviceCertificateForTLS": "",
"pkcs11LabelCodeVerifyKey": "",
"pkcs11LabelJITPCertificate": "",
"pkcs11LabelRootCertificate": ""
}
}
```
次のリストは、`userdata.json` で使用される属性です。
** `sourcePath` **
移植された FreeRTOS ソースコードのルートへのパス。
** `retainModifiedSourceDirectories` **
(オプション) ビルド時やフラッシュ時に使用した変更後のソースディレクトリをデバッグ用に保持するかどうかをチェックします。`true` に設定すると、変更されたソースディレクトリは retainedSrc という名前になり、実行された各テストグループの結果ログフォルダに保存されます。含まれない場合、このフィールドはデフォルトで `false` になります。
** `freeRTOSTestParamConfigPath` **
FreeRTOS-Libraries-Integration-Tests 統合用の `test_param_config.h` ファイルへのパス。このファイルは、プレース`{{testData.sourcePath}}`ホルダー変数を使用してソースコード root を基準にする必要があります。 は、このファイルのパラメータ AWS IoT Device Tester を使用してテストを設定します。
** `freeRTOSTestExecutionConfigPath` **
FreeRTOS-Libraries-Integration-Tests 統合用の `test_execution_config.h` ファイルへのパス。このファイルは、 `{{testData.sourcePath}}` プレースホルダー変数を使用してリポジトリの root を基準にする必要があります。 はこのファイル AWS IoT Device Tester を使用して、実行するテストを制御します。
** `freeRTOSVersion` **
実装で使用されているパッチバージョンを含む FreeRTOS のバージョン。[AWS IoT Device Tester for FreeRTOS と互換性のある FreeRTOS バージョンについては、「サポートされている](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html)バージョンの AWS IoT Device Tester for FreeRTOS」を参照してください。 FreeRTOS
** `buildTool` **
ソースコードをビルドするコマンド。ビルドコマンドのソースコードパスへのすべての参照は、 AWS IoT Device Tester 変数 に置き換える必要があります`{{testData.sourcePath}}`。`{{config.idtRootPath}}` プレースホルダーを使用して、 AWS IoT Device Tester ルートパスを基準にしてビルドスクリプトを参照します。
** `flashTool` **
イメージをデバイスにフラッシュするコマンド。フラッシュコマンドのソースコードパスへのすべての参照は、 AWS IoT Device Tester 変数 に置き換える必要があります`{{testData.sourcePath}}`。`{{config.idtRootPath}}` プレースホルダーを使用して、 AWS IoT Device Tester ルートパスを基準にしてフラッシュスクリプトを参照します。
FRQ 2.0 を使用した新しい統合テスト構造では、`{{enableTests}}` や `{{buildImageName}}` などのパス変数は必要ありません。OTA エンドツーエンドテストは、[FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests/blob/main/config_template/) GitHub リポジトリで提供されている設定テンプレートを使用して実行されます。GitHub リポジトリ内のファイルが親ソースプロジェクトに存在する場合、ソースコードはテスト間で変更されません。OTA エンドツーエンド用に別のビルドイメージが必要な場合は、このイメージをビルドスクリプトでビルドし、`otaConfiguration` で指定した `userdata.json` ファイルでそのイメージを指定する必要があります。
** `testStartDelayms` **
FreeRTOS test runner がテストの実行を開始する前に待機するミリ秒数を指定します。これは、ネットワークやその他の遅延が原因で、IDT が接続してロギングを開始する前にテスト対象のデバイスが重要なテスト情報の出力を開始した場合に役立ちます。この値は FreeRTOS テストグループにのみ適用され、FreeRTOS test runner を使用しない他のテストグループ (OTA テストなど) には適用されません。**[expected 10 but received 5]** のようなエラーが表示された場合は、このフィールドを 5000 に設定する必要があります。
** `echoServerConfiguration` **
TLS テスト用のエコーサーバーをセットアップするための設定。このフィールドは必須です。
** `keyGenerationMethod` **
エコーサーバーはこのオプションで設定されます。オプションは EC または RSA です。
** `serverPort` **
エコーサーバーが稼働するポート番号。
** `otaConfiguration` **
OTA PAL テストと OTA E2E テストの設定。このフィールドは必須です。
**`otaE2EFirmwarePath`**
IDT が OTA エンドツーエンドテストに使用する OTA バイナリイメージへのパス。
** `otaPALCertificatePath` **
デバイス上の OTA PAL テストの証明書へのパス。これは署名の検証に使用されます。例えば、**ecdsa-sha256-signer.crt.pem** などです。
** `deviceFirmwarePath` **
起動するファームウェアイメージのハードコード名へのパス。デバイスがファームウェアの起動にファイルシステムを使用しない場合は、このフィールドを `'NA'` として指定します。デバイスがファームウェアブートにファイルシステムを使用する場合は、ファームウェアブートイメージのパスまたは名前を指定します。
** `codeSigningConfiguration` **
** `signingMethod` **
コード署名の方法。指定できる値は AWS または Custom です。
北京および寧夏リージョンでは、Custom. AWS code 署名の使用はそのリージョンではサポートされていません。
** `signerHashingAlgorithm` **
デバイスでサポートされているハッシュアルゴリズム。想定される値は、`SHA1` または `SHA256` です。
** `signerSigningAlgorithm` **
デバイスでサポートされている署名アルゴリズム。想定される値は、`RSA` または `ECDSA` です。
** `signerCertificate` **
OTA 用の信頼された証明書。 AWS コード署名方法では、 AWS Certificate Manager にアップロードされた信頼された証明書の Amazon リソースネーム (ARN) を使用します。カスタムコード署名方法では、署名者の証明書ファイルへの絶対パスを使用します。信頼された証明書を作成する方法については、「[コード署名証明書の作成](https://docs.aws.amazon.com/freertos/latest/userguide/ota-code-sign-cert.html)」を参照してください。
** `untrustedSignerCertificate` **
一部の OTA テストで信頼できない証明書として使用される 2 番目の証明書の ARN またはファイルパス。証明書を作成する方法については、「[コード署名証明書の作成](https://docs.aws.amazon.com//freertos/latest/userguide/ota-code-sign-cert.html)」を参照してください。
** `signerCertificateFileName` **
デバイスのコード署名証明書のファイル名。この値は、`aws acm import-certificate` コマンド実行時に指定したファイル名と一致する必要があります。
** `compileSignerCertificate` **
署名検証証明書のステータスを決定するブール値。有効な値は、`true` および `false` です。
コード署名者の署名検証証明書がプロビジョニングまたはフラッシュされていない場合は、この値を **true** に設定します。プロジェクトにコンパイルする必要があります。 は信頼できる証明書 AWS IoT Device Tester を取得し、 にコンパイルします`aws_codesigner_certificate.h`。
** `signerPlatform` **
OTA 更新ジョブの作成時に AWS Code Signer が使用する署名およびハッシュアルゴリズム。現在、このフィールドで可能な値は、`AmazonFreeRTOS-TI-CC3220SF` と `AmazonFreeRTOS-Default` です。
+ `SHA1` および `RSA` の場合は、`AmazonFreeRTOS-TI-CC3220SF` を選択します。
+ `SHA256` および `ECDSA` の場合は、`AmazonFreeRTOS-Default` を選択します。
+ 設定に `SHA256` \$1 `RSA` または `SHA1` \$1 `ECDSA` が必要な場合は、当社に追加のサポートを依頼してください。
+ `signingMethod` として `Custom` を選択した場合は、`signCommand` を設定します。
** `signCommand` **
このコマンドには `{{inputImageFilePath}}` と `{{outputSignatureFilePath}}` の 2 つのプレースホルダーが必要です。`{{inputImageFilePath}}` は、IDT によって構築される署名対象のイメージのファイルパスです。`{{outputSignatureFilePath}} ` は、スクリプトによって生成される署名のファイルパスです。
** `pkcs11LabelConfiguration` **
PKCS11 ラベル設定には、PKCS11 テストグループを実行するために、デバイス証明書ラベル、公開鍵ラベル、秘密鍵ラベルのラベルセットが少なくとも 1 セット必要です。必要な PKCS11 ラベルは、`device.json` ファイル内のデバイス設定に基づきます。事前プロビジョニングが `device.json` で **Yes** に設定されている場合、必要なラベルは PKCS11 機能に対して選択された内容に応じて、以下のいずれかになります。
+ `PreProvisionedEC`
+ `PreProvisionedRSA`
事前プロビジョニングが `device.json` で **No** に設定されている場合、必要なラベルは以下のとおりです。
+ `pkcs11LabelDevicePrivateKeyForTLS`
+ `pkcs11LabelDevicePublicKeyForTLS`
+ `pkcs11LabelDeviceCertificateForTLS`
次の 3 つのラベルは、`device.json` ファイルで `pkcs11JITPCodeVerifyRootCertSupport` に対して **Yes** を選択した場合にのみ必要です。
+ `pkcs11LabelCodeVerifyKey`
+ `pkcs11LabelRootCertificate`
+ `pkcs11LabelJITPCertificate`
これらのフィールドの値は、「[FreeRTOS 移植ガイド](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-pkcs.html)」で定義されている値と一致する必要があります。
** `pkcs11LabelDevicePrivateKeyForTLS` **
(オプション) このラベルはプライベートキーの PKCS \$111 ラベルに使用されます。キープロビジョニングのオンボードサポートとインポートサポートがあるデバイスの場合、このラベルがテストに使用されます。このラベルは、事前プロビジョニングされたケースで定義されたラベルとは異なる場合があります。`device.json` でキープロビジョニングを **No** に設定し、事前プロビジョニングを **Yes** に設定した場合、これは未定義になります。
** `pkcs11LabelDevicePublicKeyForTLS` **
(オプション) このラベルはパブリックキーの PKCS \$111 ラベルに使用されます。キープロビジョニングのオンボードサポートとインポートサポートがあるデバイスの場合、このラベルがテストに使用されます。このラベルは、事前プロビジョニングされたケースで定義されたラベルとは異なる場合があります。`device.json` でキープロビジョニングを **No** に設定し、事前プロビジョニングを **Yes** に設定した場合、これは未定義になります。
** `pkcs11LabelDeviceCertificateForTLS` **
(オプション) このラベルはデバイス証明書の PKCS \$111 ラベルに使用されます。キープロビジョニングのオンボードサポートとインポートサポートがあるデバイスの場合、このラベルがテストに使用されます。このラベルは、事前プロビジョニングされたケースで定義されたラベルとは異なる場合があります。`device.json` でキープロビジョニングを **No** に設定し、事前プロビジョニングを **Yes** に設定した場合、これは未定義になります。
** `pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS` **
(オプション) このラベルはプライベートキーの PKCS \$111 ラベルに使用されます。安全な要素またはハードウェアの制限があるデバイスの場合、 AWS IoT 認証情報を保持するためのラベルは異なります。デバイスが EC キーによる事前プロビジョニングをサポートしている場合は、このラベルを指定します。`device.json` で事前プロビジョニングが **Yes** に設定されている場合は、このラベルまたは `pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS`、あるいはその両方を指定する必要があります。このラベルは、オンボードおよびインポートのケースで定義されたラベルとは異なる場合があります。
** `pkcs11LabelPreProvisionedECDevicePublicKeyForTLS` **
(オプション) このラベルはパブリックキーの PKCS \$111 ラベルに使用されます。安全な要素またはハードウェアの制限があるデバイスの場合、 AWS IoT 認証情報を保持するためのラベルは異なります。デバイスが EC キーによる事前プロビジョニングをサポートしている場合は、このラベルを指定します。`device.json` で事前プロビジョニングが **Yes** に設定されている場合は、このラベルまたは `pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS`、あるいはその両方を指定する必要があります。このラベルは、オンボードおよびインポートのケースで定義されたラベルとは異なる場合があります。
** `pkcs11LabelPreProvisionedECDeviceCertificateForTLS` **
(オプション) このラベルはデバイス証明書の PKCS \$111 ラベルに使用されます。安全な要素またはハードウェアの制限があるデバイスの場合、 AWS IoT 認証情報を保持するためのラベルは異なります。デバイスが EC キーによる事前プロビジョニングをサポートしている場合は、このラベルを指定します。`device.json` で事前プロビジョニングが **Yes** に設定されている場合は、このラベルまたは `pkcs11LabelPreProvisionedRSADeviceCertificateForTLS`、あるいはその両方を指定する必要があります。このラベルは、オンボードおよびインポートのケースで定義されたラベルとは異なる場合があります。
** `pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS` **
(オプション) このラベルはプライベートキーの PKCS \$111 ラベルに使用されます。安全な要素またはハードウェアの制限があるデバイスの場合、 AWS IoT 認証情報を保持するためのラベルは異なります。デバイスが RSA キーによる事前プロビジョニングをサポートしている場合は、このラベルを指定します。`device.json` で事前プロビジョニングが **Yes** に設定されている場合は、このラベルまたは `pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS`、あるいはその両方を指定する必要があります。
** `pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS` **
(オプション) このラベルはパブリックキーの PKCS \$111 ラベルに使用されます。安全な要素またはハードウェアの制限があるデバイスの場合、 AWS IoT 認証情報を保持するためのラベルは異なります。デバイスが RSA キーによる事前プロビジョニングをサポートしている場合は、このラベルを指定します。`device.json` で事前プロビジョニングが **Yes** に設定されている場合は、このラベルまたは `pkcs11LabelPreProvisionedECDevicePublicKeyForTLS`、あるいはその両方を指定する必要があります。
** `pkcs11LabelPreProvisionedRSADeviceCertificateForTLS` **
(オプション) このラベルはデバイス証明書の PKCS \$111 ラベルに使用されます。安全な要素またはハードウェアの制限があるデバイスの場合、 AWS IoT 認証情報を保持するためのラベルは異なります。デバイスが RSA キーによる事前プロビジョニングをサポートしている場合は、このラベルを指定します。`device.json` で事前プロビジョニングが **Yes** に設定されている場合は、このラベルまたは `pkcs11LabelPreProvisionedECDeviceCertificateForTLS`、あるいはその両方を指定する必要があります。
** `pkcs11LabelCodeVerifyKey` **
(オプション) このラベルはコード検証キーの PKCS \$111 ラベルに使用されます。デバイスが JITP 証明書、コード検証キー、ルート証明書の PKCS \$111 ストレージをサポートしている場合は、このラベルを指定します。`device.json` で `pkcs11JITPCodeVerifyRootCertSupport` が **Yes** に設定されている場合は、このラベルを指定する必要があります。
** `pkcs11LabelJITPCertificate` **
(オプション) このラベルは JITP 証明書の PKCS \$111 ラベルに使用されます。デバイスが JITP 証明書、コード検証キー、ルート証明書の PKCS \$111 ストレージをサポートしている場合は、このラベルを指定します。`device.json` で `pkcs11JITPCodeVerifyRootCertSupport` が **Yes** に設定されている場合は、このラベルを指定する必要があります。
# IDT for FreeRTOS 変数
コードを構築してデバイスをフラッシュするコマンドでは、正常に実行するために接続やデバイスに関するその他の情報が必要になる場合があります。 AWS IoT Device Tester を使用すると、フラッシュでデバイス情報を参照し、[JsonPath](https://goessner.net/articles/JsonPath/) を使用してコマンドを構築できます。単純な JsonPath 式を使用して、`device.json` ファイルで指定されている情報を取得することができます。
## パス変数
IDT for FreeRTOS は、コマンドラインと設定ファイルで使用できる次のようなパス変数を定義します。
** `{{testData.sourcePath}}` **
ソースコードパスに拡張されます。この変数を使用する場合は、フラッシュコマンドとビルドコマンドの両方で使用する必要があります。
** `{{device.connectivity.serialPort}}` **
シリアルポートに拡張されます。
** `{{device.identifiers[?(@.name == 'serialNo')].value[0]}}` **
デバイスのシリアル番号に拡張されます。
** `{{config.idtRootPath}}` **
AWS IoT Device Tester ルートパスに展開します。
# IDT for FreeRTOS 認定スイート 2.0 (FRQ 2.0) の UI
AWS IoT Device Tester for FreeRTOS (IDT for FreeRTOS) には、IDT コマンドラインアプリケーションと関連する設定ファイルを操作できるウェブベースのユーザーインターフェイス (UI) が含まれています。IDT for FreeRTOS UI を使用して、デバイスの新しい設定を作成したり、既存の設定を変更したりします。この UI を使用して、IDT アプリケーションを呼び出し、デバイスに対して FreeRTOS テストを実行することもできます。
コマンドラインを使用して認定テストを実行する方法については、「[マイクロコントローラーボードの最初のテスト](lts-qual-steps.md)」を参照してください。
このセクションでは、IDT for FreeRTOS UI の前提条件と、UI から認定テストを実行する方法について説明します。
**Topics**
+ [IDT 前提条件の設定](#lts-dev-tester-ui-prereqs)
+ [IDT UI を使用するように AWS 認証情報を設定する](lts-configure-aws-credentials.md)
+ [IDT for FreeRTOS UI を開く](lts-open-idt-ui.md)
+ [新しい設定を作成する](lts-create-new-configuration.md)
+ [既存の設定を変更する](lts-modify-existing-configuration.md)
+ [認定テストを実行する](lts-run-tests-from-ui.md)
## IDT 前提条件の設定
FreeRTOS UI の AWS IoT Device Tester (IDT) を使用してテストを実行するには、IDT FreeRTOS 認定 (FRQ) 2.x の[LTS 認定の前提条件を設定する](lts-idt-dev-tester-prereqs.md)ページの前提条件を満たす必要があります。
# IDT UI を使用するように AWS 認証情報を設定する
で作成したユーザーの IAM AWS ユーザー認証情報を設定する必要があります[AWS アカウントを作成する](lts-idt-dev-tester-prereqs.md#lts-config-aws-account)。以下のいずれかの方法で認証情報を指定できます。
+ 認証情報ファイルを使用する
+ 環境変数を使用する
## 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 = your_access_key_id
aws_secret_access_key = your_secret_access_key
```
**注記**
`default` AWS プロファイルを使用しない場合は、IDT for FreeRTOS UI でプロファイル名を指定する必要があります。プロファイルの詳細については、「[設定ファイルと認証情報ファイルの設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)」を参照してください。
## 環境変数を使用して AWS 認証情報を設定する
環境変数は、オペレーティングシステムによって維持され、システムコマンドによって使用される変数です。SSH セッションを閉じると、これらは保存されません。IDT for FreeRTOS UI は、 `AWS_ACCESS_KEY_ID`および `AWS_SECRET_ACCESS_KEY`環境変数を使用して AWS 認証情報を保存します。
これらの変数を Linux、macOS、または Unix で設定するには、**export** を使用します。
```
export AWS_ACCESS_KEY_ID=your_access_key_id
export AWS_SECRET_ACCESS_KEY=your_secret_access_key
```
Windows でこれらの変数を設定するには、**set** を使用します。
```
set AWS_ACCESS_KEY_ID=your_access_key_id
set AWS_SECRET_ACCESS_KEY=your_secret_access_key
```
# IDT for FreeRTOS UI を開く
このトピックでは、IDT for FreeRTOS UI を開いて FreeRTOS 認定スイートを使用する方法について説明します。
**IDT for FreeRTOS UI を開く方法**
1. サポートされるバージョンの IDT for FreeRTOS をダウンロードします。次に、ダウンロードしたアーカイブを、読み取りおよび書き込みアクセス許可を持っているディレクトリに抽出します。
1. IDT for FreeRTOS のインストールディレクトリに移動します。
```
cd devicetester-extract-location/bin
```
1. 次のコマンドを実行して IDT for FreeRTOS UI を開きます。
------
#### [ Linux ]
```
.devicetester_ui_linux_x86-64
```
------
#### [ Windows ]
```
./devicetester_ui_win_x64-64
```
------
#### [ macOS ]
```
./devicetester_ui_mac_x86-64
```
**注記**
macOS でシステムが UI を実行できるようにするには、**[システム環境設定] -> [セキュリティとプライバシー]** に移動します。テストを実行するときは、これをさらに 3 回行う必要がある場合があります。
------
IDT for FreeRTOS UI がデフォルトのブラウザで開きます。以下のブラウザの最新の 3 つのメジャーバージョンは UI をサポートしています。
+ Google Chrome
+ Mozilla Firefox
+ Microsoft Edge
+ MacOS 版 Apple Safari
**注記**
エクスペリエンスの向上のために、Google Chrome または Mozilla Firefox で IDT for FreeRTOS UI にアクセスすることをお勧めします。Microsoft Internet Explorer は UI ではサポートされていません。
**重要**
UI を開く前に、 AWS 認証情報を設定する必要があります。認証情報を設定していない場合は、IDT for FreeRTOS UI ブラウザウィンドウを閉じて、「[IDT UI を使用するように AWS 認証情報を設定する](lts-configure-aws-credentials.md)」の手順に従います。その後に IDT for FreeRTOS UI を再度開きます。
# 新しい設定を作成する
初めて使用する場合、IDT for FreeRTOS がテストを実行するのに必要な JSON 設定ファイルをセットアップするための新しい設定を作成する必要があります。これにより、テストを実行したり、作成した設定を変更できます。
`config.json`、`device.json`、および `userdata.json` ファイルの例については、[マイクロコントローラーボードの最初のテスト](lts-qual-steps.md)を参照してください。
**新しい設定を作成するには**
1. IDT for FreeRTOS UI でナビゲーションメニューを開いて、**[新しい設定を作成]** を選択します。
![\[Device Tester for FreeRTOS には「Create new configuration」ボタンと、マイクロコントローラーの自動セルフテストに関する情報が含まれています。\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/images/gsg-create-configuration.png)
1. 設定ウィザードに従って、認定テストの実行に使用される IDT 構成設定を入力します。このウィザードで `devicetester-extract-location/config` ディレクトリにある JSON 設定ファイル内の次の設定を行います。
+ **[デバイス設定]**: テスト対象のデバイス用のデバイスプール設定。これらの設定は、`config.json` ファイルのデバイスプールに関する `id` および `sku` フィールドと **[デバイス]** ブロックで行われます。
![\[Device Tester for FreeRTOS 設定画面では、デバイスプールを設定するための識別子フィールドと SKU フィールド、接続方法などのデバイス設定オプション、キープロビジョニング、PKCS #11 設定、デバイスの詳細入力フィールド、デバイスまたは識別子を追加するコントロールがあります。\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/images/gsg-device-settings.png)
+ **AWS アカウント設定** – IDT for FreeRTOS AWS アカウント がテスト実行中に AWS リソースを作成するために使用する情報。これらの設定は `config.json` ファイルで行われます。
![\[AWS アカウント アカウントリージョン、ファイルまたは環境としての認証情報の場所、プロファイル名のフィールドを含む設定ページ\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/images/gsg-account-settings.png)
+ **[FreeRTOS 実装]**: FreeRTOS リポジトリと移植されたコードへの絶対パス、および IDT FRQ を実行したい FreeRTOS バージョン。`FreeRTOS-Libraries-Integration-Tests` GitHub リポジトリからの実行およびパラメータ設定ヘッダーファイルへのパス。IDT がボード上でテストを自動的にビルドおよびフラッシュできるようにする、ハードウェア用のビルドコマンドとフラッシュコマンド。これらの設定は `userdata.json` ファイルで行われます。
![\[FreeRTOS 実装設定セクションには、リポジトリパス、テスト実行パス、FreeRTOS バージョン、ビルドツールの詳細、フラッシュツールの設定があります。\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/images/gsg-implementation-settings.png)
+ **[PKCS \$111 ラベルと Echo サーバー]**: キー機能とキープロビジョニング方法に基づいてハードウェアにプロビジョニングされたキーに対応する [PKCS \$111](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-pkcs.html) ラベル。トランスポートインターフェイステスト用のエコーサーバー構成設定。これらの設定は `userdata.json` および `device.json` ファイルで行われます。
![\[PKCS #11 ラベルと Echo サーバー設定には、キーラベル、キー生成方法、サーバーポート番号の入力フィールドが含まれています。\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/images/gsg-pkcs11-settings.png)
+ **[OTA (Over-The-Air) 更新]** — OTA 機能テストを制御する設定。これらの設定は、`device.json` および `userdata.json` ファイルの `features` ブロックで行われます。
![\[OTA 更新設定オプション: テストのスキップ、データプロトコル、ファームウェアパス、PAL 証明書パス、コード署名、ハッシュ/署名アルゴリズム、信頼済み/信頼されていない署名者の証明書、署名者の証明書ファイル、コンパイルの署名者の証明書、署名者のプラットフォーム。\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/images/gsg-ota-settings.png)
1. **[Review]** (確認) ページで、設定情報を確認します。
![\[Device Tester for FreeRTOS 向けに作成された設定ダイアログで、新しいテスト設定の作成に関する詳細と、テストを編集または実行するオプションが表示されます。\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/images/gsg-configuration-created.png)
設定の確認が完了したら、**[Run tests]** (テストの実行) を選択して、認定テストを実行します。
# 既存の設定を変更する
IDT for FreeRTOS の設定ファイルを既にセットアップしている場合は、IDT for FreeRTOS UI を使用して既存の設定を変更できます。既存の設定ファイルは `devicetester-extract-location/config` ディレクトリにある必要があります。
**設定を変更するには**
1. IDT for FreeRTOS UI でナビゲーションメニューを開いて、**[既存の設定の編集]** を選択します。
設定ダッシュボードには、既存の構成設定に関する情報が表示されます。設定が正しくない、または使用できない場合、設定のステータスは `Error validating configuration` です。
![\[デバイス、 AWS アカウント FreeRTOS 実装、PKCS ラベルとエコーサーバー、over-the-airの更新、有効なステータスを示すテスト実行設定セクションを含む設定画面。\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/images/modify-existing-configuration.png)
1. 既存の設定を変更するには、以下のステップを実行します。
1. 構成設定の名前を選択して、設定ページを開きます。
1. 設定を変更し、**[Save]** (保存) を選択して、対応する設定ファイルを再生成します。
1. IDT for FreeRTOS のテスト実行設定を変更するには、編集ビューで **[IDT テスト実行設定]** を選択します。
![\[IDT テスト実行設定ダイアログには、テスト選択、テストグループのスキップ、タイムアウト乗数、初回失敗時の停止のオプションがあります。\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/images/idt-testrun-settings.png)
設定の変更が完了したら、すべての構成設定が検証に合格することを確認します。各構成設定のステータスが `Valid` の場合、この設定を使用して認定テストを実行できます。
# 認定テストを実行する
IDT for FreeRTOS UI の設定を作成したら、認定テストを実行できます。
**認定テストを実行するには**
1. ナビゲーションメニューで、**[Run tests]** (テストの実行) を選択します。
1. テストの実行を開始するには、**[テストの開始]** を選択します。デフォルトでは、該当するすべてのテストがデバイス構成に合わせて実行されます。IDT for FreeRTOS は、すべてのテストが終了すると認定レポートを生成します。
![\[Device Tester for FreeRTOS インターフェイスには、テストが未実行であることが示されており、新しい設定の作成、既存の設定の編集、テストの実行のオプションがあります。\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/images/idt-run-tests.png)
IDT for FreeRTOS が認定テストを実施します。次に、テスト実行の概要とエラーを **[テストランナー]** コンソールに表示します。テストの実行が完了したら、次の場所でテスト結果とログを確認できます。
+ テスト結果は、`devicetester-extract-location/results/execution-id` ディレクトリにあります。
+ テストのログは `devicetester-extract-location/results/execution-id/logs` ディレクトリにあります。
テスト結果とログの詳細については、「[IDT for FreeRTOSresults を表示する](view-results-lts.md)」および「[IDT for FreeRTOSlogs を表示する](view-logs-lts.md)」を参照してください。
![\[Device Tester for FreeRTOS 実行ログには、合格したテスト、テストグループ、ログとレポートのファイルパスが表示されます。\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/images/idt-results.png)
# FreeRTOS 認定 2.0 スイートの実行
AWS IoT Device Tester for FreeRTOS 実行可能ファイルを使用して、IDT for FreeRTOS とやり取りします。以下のコマンドラインの例では、デバイスプール (同一デバイスの集合) に対して適格性確認テストを実行する方法を示します。
------
#### [ IDT v4.5.2 and later ]
```
devicetester_[linux | mac | win] run-suite \
--suite-id suite-id \
--group-id group-id \
--pool-id your-device-pool \
--test-id test-id \
--userdata userdata.json
```
デバイスプールに対してテストスイートを実行します。`userdata.json` ファイルは、`devicetester_extract_location/devicetester_freertos_[win|mac|linux]/configs/` ディレクトリに置く必要があります。
**注記**
Windows 上で IDT for FreeRTOS を実行する場合、スラッシュ (/) を使用して `userdata.json` ファイルへのパスを指定します。
特定のテストグループを実行するには、次のコマンドを使用します。
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1.99.0 \
--group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
1 つのデバイスプールに対して 1 つのスイートを実行する場合 (`device.json` ファイルで定義したデバイスプールが 1 つしかない場合)、`suite-id` パラメータと `pool-id` パラメータは省略可能です。
テストグループの特定のテストケースを実行するには、次のコマンドを使用します。
```
devicetester_[linux | mac | win_x86-64] run-suite \
--group-id group-id \
--test-id test-id
```
`list-test-cases` コマンドを使用して、テストグループのテストケースを一覧表示できます。
**IDT for FreeRTOS のコマンドラインオプション**
**group-id**
(オプション) 実行するテストグループ (カンマ区切りリストとして)。指定しない場合、IDT はテストスイートのすべてのテストグループを実行します。
**pool-id**
(オプション) テストするデバイスプール。これは、`device.json` で複数のデバイスプールを定義する場合に必要です。デバイスプールが 1 つしかない場合は、このオプションを省略できます。
**suite-id**
(オプション) 実行するテストスイートのバージョン。指定しない場合、IDT はシステムの tests ディレクトリにある最新バージョンを使用します。
**test-id**
(オプション) 実行するテスト (カンマ区切りリストとして)。指定した場合、`group-id` は 1 つのグループを指定する必要があります。
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id FreeRTOSVersion --test-id FreeRTOSVersion
```
**h**
`run-suite` オプションの詳細を確認するには、ヘルプオプションを使用します。
**Example**
**例**
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
------
## IDT for FreeRTOS コマンド
IDT for FreeRTOS のコマンドは次のオペレーションをサポートしています。
------
#### [ IDT v4.5.2 and later ]
** `help` **
指定されたコマンドに関する情報を一覧表示します。
** `list-groups` **
特定のスイート内のグループを一覧表示します。
** `list-suites` **
使用可能なスイートを一覧表示します。
** `list-supported-products` **
サポートされている製品とテストスイートのバージョンを一覧表示します。
** `list-supported-versions` **
現在の IDT バージョンでサポートされている FreeRTOS およびテストスイートのバージョンを一覧表示します。
** `list-test-cases` **
指定したグループのテストケースを一覧表示します。
** `run-suite` **
デバイスプールに対してテストスイートを実行します。
`--suite-id` オプションを使用してテストスイートのバージョンを指定するか、そのオプションを省略してシステムの最新バージョンを使用します。
個々のテストケースを実行するには、`--test-id` を使用します。
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id FreeRTOSVersion --test-id FreeRTOSVersion
```
IDT v3.0.0 以降、IDT は新しいテストスイートをオンラインでチェックします。詳細については、「[テストスイートのバージョン](idt-test-suite-versions.md)」を参照してください。
------
# IDT for FreeRTOSresults を表示する
実行中、IDT はコンソール、ログファイル、テストレポートにエラーを書き込みます。IDT で適格性テストスイートを実行すると、テスト実行の概要がコンソールに書き込まれ、2 つのレポートが生成されます。これらのレポートは `devicetester-extract-location/results/execution-id/` にあります。両レポートでは、適格性確認テストスイートの実行の結果をキャプチャします。
`awsiotdevicetester_report.xml` は、 AWS Partner Device Catalog にデバイスを一覧表示 AWS するために に送信する認定テストレポートです。レポートには、次の要素が含まれます。
+ IDT for FreeRTOS のバージョン。
+ テスト済みの FreeRTOS のバージョン。
+ 合格したテストに基づいてデバイスでサポートされる FreeRTOS の機能。
+ `device.json` ファイルに記載されている SKU とデバイス名。
+ `device.json` ファイルに記載されているデバイスの機能。
+ テストケース結果の要約を集計したもの。
+ デバイスの機能に基づいてテストしたライブラリごとのテストケース結果の内訳。
`FRQ_Report.xml` は、標準 [JUnit XML 形式](https://llg.cubic.org/docs/junit/)のレポートです。[Jenkins](https://jenkins.io/)、[Bamboo](https://www.atlassian.com/software/bamboo) など CI/CD プラットフォームに統合することができます。レポートには、次の要素が含まれます。
+ テストケース結果の要約を集計したもの。
+ デバイスの機能に基づいてテストしたライブラリごとのテストケース結果の内訳。
# IDT for FreeRTOS の結果の解釈
`awsiotdevicetester_report.xml` または `FRQ_Report.xml` のレポートセクションには、実行したテストの結果が一覧表示されます。
最初の XML タグ `` は、テストの実行の概要を含みます。例:
``
**`` タグで使用される属性**
** `name` **
テストスイートの名前。
** `time` **
適格性確認スイートの実行所要時間 (秒)。
** `tests` **
実行されたテストケースの数。
** `failures` **
実行されたテストケースのうち、合格しなかったものの数。
** `errors` **
IDT for FreeRTOS が実行できなかったテストケースの数。
** `disabled` **
この属性は使用されていないため無視できます。
テストケースの障害やエラーがない場合、デバイスは FreeRTOS を実行するための技術要件を満たし、 AWS IoT サービスと相互運用できます。 AWS Partner Device Catalog にデバイスを一覧表示することを選択した場合は、このレポートを認定の証拠として使用できます。
テストケースに障害やエラーが発生した場合は、`` XML タグを確認することで、障害の生じたテストケースを特定できます。`` タグ内の `` XML タグは、テストグループのテストケース結果の要約を示します。
``
形式は `` タグと似ていますが、`skipped` という属性があります。この属性は使用されていないため無視できます。`` XML タグの内側には、テストグループに対して実行されたそれぞれのテストケースの `` タグがあります。例:
``
**`` タグで使用される属性**
** `name` **
テスト対象の製品の名前。
** `version` **
テスト対象の製品のバージョン。
** `features` **
検証された機能です。`required` としてマークされている機能については、資格を得るためにボードを提出するために必要です。次のスニペットは、この情報が `awsiotdevicetester_report.xml` ファイルで表示される方法を示します。
```
```
`optional` としてマークされている機能は、資格を得るために必要ありません。次のスニペットは、オプションの機能を示しています。
```
```
必要な機能のテストに障害やエラーがない場合、そのデバイスは FreeRTOS を実行するための技術的要件を満たしており、 AWS IoT サービスとの相互運用が可能です。[AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices) にデバイスを出品する場合は、認定の証拠としてこのレポートを使用できます。
テストに障害やエラーが発生した場合は、`` XML タグを確認することで、障害の生じたテストを特定できます。`` タグ内の `` XML タグは、テストグループのテスト結果の要約を示します。例:
```
```
形式は `` タグと似ていますが、使用されていないため無視できる `skipped` という属性があります。各 `` XML タグ内には、テストグループの実行されたテスト別の `` タグがあります。例:
```
```
**`` タグで使用される属性**
** `name` **
テストケースの名前。
** `attempts` **
IDT for FreeRTOS がテストケースを実行した回数。
テストに障害やエラーが発生した場合、`` タグまたは `` タグがトラブルシューティングのための情報とともに `` タグに追加されます。例:
```
Reason for the test case failure
Reason for the test case execution error
```
詳細については、「[エラーのトラブルシューティング](dt-afr-troubleshooting.md)」を参照してください。
# IDT for FreeRTOSlogs を表示する
テストの実行中に IDT for FreeRTOS によって生成されるログは、`devicetester-extract-location/results/execution-id/logs` にあります。2 組のログが生成されます。
+ `test_manager.log`
IDT for FreeRTOS から生成されるログ (設定とレポート生成に関連するログなど) を含みます。
+ `test_group_id/test_case_id/test_case_id.log`
テスト対象のデバイスからの出力を含む、テストケースのログファイル。ログファイルには、実行されたテストグループとテストケースに従って名前が付けられます。
# IDT と FreeRTOS 認定スイート 1.0 (FRQ 1.0)
**重要**
2022 年 10 月現在、 AWS IoT Device Tester for AWS IoT FreeRTOS Qualification (FRQ) 1.0 は署名付き認定レポートを生成しません。IDT FRQ 1.0 バージョンを使用してデバイス[AWS 認定プログラム](https://aws.amazon.com/partners/programs/dqp/)を通じて、新しい AWS IoT FreeRTOS デバイスを [AWS Partner Device Catalog ](https://partners.amazonaws.com/qualified-devices)に一覧表示することはできません。IDT FRQ 1.0 を使用して FreeRTOS デバイスを認定することはできませんが、引き続き FRQ 1.0 を使用して FreeRTOS デバイスをテストすることはできます。FreeRTOS デバイスを認定し、[AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices) にリストする際には、[IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) を使用することが推奨されます。
IDT for FreeRTOS 認定を使用して、FreeRTOS オペレーティングシステムがデバイス上でローカルに動作し、 と通信できることを確認できます AWS IoT。具体的には、FreeRTOS ライブラリの移植レイヤーインターフェイスが正しく実装されていることを検証します。また、 を使用してend-to-endテストも実行します AWS IoT Core。たとえば、ボードで MQTT メッセージを送受信して正しく処理できることを確認します。IDT for FreeRTOS で実行されるテストは、[FreeRTOS GitHub リポジトリ](https://github.com/aws/amazon-freertos)で定義されています。
テストは、ボードにフラッシュされる埋め込みアプリケーションとして実行されます。アプリケーションのバイナリイメージには、FreeRTOS、半導体ベンダーの移植 FreeRTOS インターフェイス、およびボードデバイスドライバーが含まれています。テストの目的は、移植された FreeRTOS インターフェイスがデバイスドライバーとの組み合わせで正しく機能するかどうかを検証することです。
IDT for FreeRTOS は、 AWS パートナーデバイスカタログにハードウェアを追加 AWS IoT するために に送信できるテストレポートを生成します。詳細については、[AWS デバイス認定プログラム](https://aws.amazon.com/partners/dqp/)を参照してください。
IDT for FreeRTOS は、テスト対象のボードに接続されているホストコンピュータ (Windows、macOS、または Linux) 上で動作します。IDT は、テストケースを実行して結果を集計します。また、テストの実行を管理するためのコマンドラインインターフェイスも用意されています。
IDT for FreeRTOS は、テストデバイスに加えて、認定プロセスを容易にするためにリソース ( AWS IoT モノ、FreeRTOS グループ、Lambda 関数など) を作成します。これらのリソースを作成するために、IDT for FreeRTOS は で設定された AWS 認証情報`config.json`を使用してユーザーに代わって API コールを行います。これらのリソースは、テスト中にさまざまなタイミングでプロビジョニングされます。
IDT for FreeRTOS をホストコンピュータで実行すると、次のステップが実行されます。
1. デバイスおよび認証情報の設定をロードして検証します。
1. 必要なローカルリソースとクラウドリソースを使用して選択したテストを実行します。
1. ローカルリソースとクラウドリソースをクリーンアップします。
1. ボードが資格に必要なテストに合格したかどうかを示すテストレポートを生成します。
**Topics**
+ [1.0 認定の前提条件を設定する](dev-tester-prereqs.md)
+ [マイクロコントローラーボードの最初のテスト](qual-steps.md)
+ [IDT ユーザーインターフェイスを使用して FreeRTOS 認定スイートを実行する](device-tester-ui.md)
+ [Bluetooth Low Energy テストを実行する](afr-bridgekeeper-dt-bt.md)
+ [FreeRTOS 認定スイートの実行](run-tests.md)
+ [IDT for FreeRTOS の結果を表示する](view-results-frq.md)
+ [IDT for FreeRTOS の結果の解釈](interpreting-results-frq.md)
+ [IDT for FreeRTOS ログを表示する](view-logs-frq.md)
# 1.0 認定の前提条件を設定する
このセクションでは、 でマイクロコントローラーをテストするための前提条件について説明します AWS IoT Device Tester。
## FreeRTOS をダウンロードする
次のコマンドを使用して、[GitHub](https://github.com/aws/amazon-freertos) から FreeRTOS のリリースをダウンロードできます。
```
git clone --branch --recurse-submodules https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
ここで、 は、[AWS IoT Device Tester のサポートされているバージョン:](dev-test-versions-afr.md)に記載された IDT バージョンに対応する FreeRTOS のバージョン (202007.00 など) です。これにより、サブモジュールを含むすべてのソースコードを入手でき、FreeRTOS と IDT が相互に対応するバージョンを使用できます。
Windows では、パスの長さは 260 文字に制限されています。FreeRTOS のパス構造は、レベルが多く、深いため、 Windows を使用している場合は、ファイルパスを 260 文字に抑えてください。例えば、`C:\Users\username\programs\projects\myproj\FreeRTOS\` ではなく、`C:\FreeRTOS` に FreeRTOS のクローンを作成します。
### LTS ライブラリを使用した FreeRTOS 認定
+ マイクロコントローラーを AWS Partner Device Catalog の FreeRTOS の長期サポート (LTS) ベースのバージョンをサポートするように指定するには、マニフェストファイルを指定する必要があります。詳細については、*FreeRTOS 資格ガイド*の [FreeRTOS 資格チェックリスト](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist.html)を参照してください。
+ マイクロコントローラーが FreeRTOS の LTS ベースのバージョンをサポートしていることを検証し、それを AWS Partner Device Catalog に送信するための認定を受けるには、FreeRTOS 認定 AWS IoT Device Tester (FRQ) テストスイートバージョン v1.4.x で (IDT) を使用する必要があります。
+ LTS ベースのバージョンの FreeRTOS がサポートされるのは、FreeRTOS のバージョン 202012.xx のみです。
## IDT for FreeRTOS のダウンロード
どのバージョンの FreeRTOS にも、認定テストの実行に対応する IDT for FreeRTOS のバージョンがあります。[AWS IoT Device Tester のサポートされているバージョン:](dev-test-versions-afr.md) から適切なバージョンの IDT for FreeRTOS をダウンロードします。
IDT for FreeRTOS を、ファイルシステム上で読み取りおよび書き込みアクセス許可を持っている場所に抽出します。Microsoft Windows ではパスの長さに文字数の制限があるため、IDT for FreeRTOS は `C:\` や `D:\` などのルートディレクトリに抽出します。
**注記**
複数のユーザーが NFS ディレクトリや Windows ネットワーク共有フォルダなどの共有場所から IDT を実行することはお勧めしません。このように実行すると、クラッシュまたはデータの破損が発生する可能性があります。IDT パッケージをローカルドライブに抽出することをお勧めします。
## AWS アカウントの作成と設定
### にサインアップする 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)」を参照してください。
## AWS IoT Device Tester マネージドポリシー
`AWSIoTDeviceTesterForFreeRTOSFullAccess` 管理ポリシーには、バージョンチェック、自動更新機能、メトリクスの収集に関する以下の AWS IoT Device Tester アクセス許可が含まれています。
+ `iot-device-tester:SupportedVersion`
サポートされている製品、テストスイート、IDT バージョンのリストを取得する AWS IoT Device Tester アクセス許可を付与します。
+ `iot-device-tester:LatestIdt`
ダウンロード可能な最新の IDT バージョンを取得する AWS IoT Device Tester アクセス許可を付与します。
+ `iot-device-tester:CheckVersion`
IDT、テストスイート、製品のバージョンの互換性をチェックする AWS IoT Device Tester アクセス許可を付与します。
+ `iot-device-tester:DownloadTestSuite`
テストスイートの更新をダウンロードする AWS IoT Device Tester アクセス許可を付与します。
+ `iot-device-tester:SendMetrics`
AWS IoT Device Tester 内部使用状況に関するメトリクスを収集する AWS アクセス許可を付与します。
## (オプション) をインストールする AWS Command Line Interface
一部のオペレーションを実行する AWS CLI には、 を使用することをお勧めします。 AWS CLI がインストールされていない場合は、「[AWS CLIのインストール](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)」の手順を実行します。
コマンドライン**aws configure**から を実行して、使用する AWS CLI AWS リージョンの を設定します。IDT for FreeRTOS をサポートする AWS リージョンについては、[AWS 「リージョンとエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html#amazon-freertos-ota-control)」を参照してください。**aws configure** の詳細については、[**aws configure** を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)を参照してください。
# マイクロコントローラーボードの最初のテスト
FreeRTOS インターフェイスを移植する際、IDT for FreeRTOS を使用してテストできます。ボードのデバイスドライバーに FreeRTOS インターフェイスを移植したら、 AWS IoT Device Tester を使用してマイクロコントローラーボードで認定テストを実行します。
## ライブラリ移植レイヤーを追加する
デバイス用に FreeRTOS を移植するには、[FreeRTOS 移植ガイド](https://docs.aws.amazon.com/freertos/latest/portingguide/)の手順に従います。
## AWS 認証情報を設定する
クラウドと AWS 通信 AWS IoT Device Tester するには、 の AWS 認証情報を設定する必要があります。詳細については、[開発用の AWS 認証情報とリージョンのセットアップ](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html)を参照してください。有効な AWS 認証情報は、`devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/config.json`設定ファイルで指定する必要があります。
**Topics**
+ [ライブラリ移植レイヤーを追加する](#add-port-layer)
+ [AWS 認証情報を設定する](#cfg-aws-afr)
+ [IDT for FreeRTOS でデバイスプールを作成する](cfg-dt-dp.md)
+ [ビルド、フラッシュ、テスト設定を設定する](cfg-dt-ud.md)
# IDT for FreeRTOS でデバイスプールを作成する
テストするデバイスは、デバイスプールにまとめられます。各デバイスプールは、1 つ以上の同一デバイスで構成されます。IDT for FreeRTOS の設定次第で、プール内の 1 つのデバイスをテストすることも、複数のデバイスをテストすることもできます。認定プロセスを迅速化するために、IDT for FreeRTOS は、同じ仕様を持つデバイスを並行してテストできます。その際、ラウンドロビンメソッドを使用し、デバイスプール内の各デバイスで異なるテストグループが実行されます。
1 つ以上のデバイスをデバイスプールに追加するには、`configs` フォルダにある `device.json` テンプレートの `devices` セクションを編集します。
**注記**
同じプールにあるデバイスは、すべて同じ技術仕様と同じ SKU を持たなければなりません。
IDT for FreeRTOS は、異なるテストグループに対してソースコードの並列ビルドを可能にするため、ソースコードを IDT for FreeRTOS の抽出されたフォルダにある結果フォルダにコピーします。ビルドコマンドまたはフラッシュコマンドのソースコードパスは、`testdata.sourcePath` または `sdkPath` 変数を使用して参照する必要があります。IDT for FreeRTOS は、この変数を、コピーしたソースコードの一時パスで置き換えます。詳細については、[IDT for FreeRTOS 変数](dt-vars.md)を参照してください。
次の例では、`device.json` ファイルを使って複数のデバイスを含んだデバイスプールを作成します。
```
[
{
"id": "pool-id",
"sku": "sku",
"features": [
{
"name": "WIFI",
"value": "Yes | No"
},
{
"name": "Cellular",
"value": "Yes | No"
},
{
"name": "OTA",
"value": "Yes | No",
"configs": [
{
"name": "OTADataPlaneProtocol",
"value": "HTTP | MQTT"
}
]
},
{
"name": "BLE",
"value": "Yes | No"
},
{
"name": "TCP/IP",
"value": "On-chip | Offloaded | No"
},
{
"name": "TLS",
"value": "Yes | No"
},
{
"name": "PKCS11",
"value": "RSA | ECC | Both | No"
},
{
"name": "KeyProvisioning",
"value": "Import | Onboard | No"
}
],
"devices": [
{
"id": "device-id",
"connectivity": {
"protocol": "uart",
"serialPort": "/dev/tty*"
},
***********Remove the section below if the device does not support onboard key generation***************
"secureElementConfig" : {
"publicKeyAsciiHexFilePath": "absolute-path-to/public-key-txt-file: contains-the-hex-bytes-public-key-extracted-from-onboard-private-key",
"secureElementSerialNumber": "secure-element-serialNo-value",
"preProvisioned" : "Yes | No"
},
**********************************************************************************************************
"identifiers": [
{
"name": "serialNo",
"value": "serialNo-value"
}
]
}
]
}
]
```
次の属性は、`device.json` ファイルで使用されます。
**`id`**
デバイスのプールを一意に識別するユーザー定義の英数字の ID。プールに属するデバイスは同じタイプであることが必要です。テストスイートを実行するとき、プールのデバイスを使用してワークロードが並列化されます。
**`sku`**
テスト対象であるボードを一意に識別する英数字の値。SKU は、適格性が確認されたボードの追跡に使用されます。
AWS Partner Device Catalog でボードを一覧表示する場合、ここで指定する SKU は、一覧表示プロセスで使用する SKU と一致する必要があります。
**`features`**
デバイスのサポートされている機能を含む配列。 は、この情報 AWS IoT Device Tester を使用して、実行する認定テストを選択します。
サポートされている値は以下のとおりです。
**`TCP/IP`**
ボードが TCP/IP スタックをサポートしているかどうか、オンチップ (MCU) でサポートされるのか別のモジュールにオフロードされるのかを示します。資格確認には TCP/IP が必要です。
**`WIFI`**
ボードが Wi-Fi 機能を備えているかどうかを示します。`Cellular` が `Yes` に設定されている場合は `No` に設定します。
**`Cellular`**
ボードがセルラー機能を備えているかどうかを示します。`WIFI` が `Yes` に設定されている場合は `No` に設定します。この機能が に設定されている場合`Yes`、FullSecureSockets テストは AWS t2.micro EC2 インスタンスを使用して実行され、アカウントに追加のコストが発生する可能性があります。詳細については、[Amazon EC2 料金表](https://aws.amazon.com/ec2/pricing/)を参照してください。
**`TLS`**
ボードが TLS をサポートしているかどうかを示します。資格確認には TLS が必要です。
**`PKCS11`**
ボードがサポートする公開鍵暗号化アルゴリズムを指定します。資格認定には PKCS11 が必要です。サポートされている値は、`ECC`、`RSA`、`Both`、`No` です。`Both` は、ボードが `ECC` と `RSA` の両方のアルゴリズムをサポートしていることを示します。
**`KeyProvisioning`**
信頼された X.509 クライアント証明書をボードに書き込む方法を指定します。有効な値は、`Import`、`Onboard`、`No` です。資格認定にはキーのプロビジョニングが必要です。
+ ボードがプライベートキーのインポートを許可している場合は、`Import` を使用します。IDT は、プライベートキーを作成し、これを FreeRTOS ソースコードに構築します。
+ ボードがオンボードプライベートキーの生成をサポートしている場合 (たとえば、デバイスに安全な要素がある場合、または独自のデバイスのキーペアと証明書を生成する場合) は、`Onboard` を使用します。各デバイスセクションに `secureElementConfig` 要素を追加し、`publicKeyAsciiHexFilePath` フィールドにパブリックキーファイルへの絶対パスを入力していることを確認します。
+ ボードがキーのプロビジョニングをサポートしていない場合は、`No` を使用します。
**`OTA`**
ボードが無線 (OTA) による更新機能をサポートしているかどうかを示します。`OtaDataPlaneProtocol` 属性は、デバイスがサポートする OTA データプレーンプロトコルを示します。OTA 機能がデバイスでサポートされていない場合、この属性は無視されます。`"Both"` を選択すると、MQTT、HTTP の両方と混合テストを実行するため、OTA テストの実行時間が長くなります。
IDT v4.1.0 以降、`OtaDataPlaneProtocol` の値には `HTTP` と `MQTT` のみが使用可能です。
**`BLE`**
ボードが Bluetooth Low Energy (BLE) をサポートしているかどうかを示します。
**`devices.id`**
テスト対象のデバイスのユーザー定義の一意の識別子。
**`devices.connectivity.protocol`**
このデバイスと通信するために使用される通信プロトコル。サポートされている値は `uart` です。
**`devices.connectivity.serialPort`**
テスト対象であるデバイスへの接続に使用される、ホストコンピュータのシリアルポート。
**`devices.secureElementConfig.PublicKeyAsciiHexFilePath`**
オンボードプライベートキーから抽出された 16 進バイトのパブリックキーを含むファイルへの絶対パス。
形式の例:
```
3059 3013 0607 2a86 48ce 3d02 0106 082a
8648 ce3d 0301 0703 4200 04cd 6569 ceb8
1bb9 1e72 339f e8cf 60ef 0f9f b473 33ac
6f19 1813 6999 3fa0 c293 5fae 08f1 1ad0
41b7 345c e746 1046 228e 5a5f d787 d571
dcb2 4e8d 75b3 2586 e2cc 0c
```
パブリックキーが .der 形式の場合は、パブリックキーを直接 16 進エンコードして 16 進ファイルを生成できます。
16 進ファイルを生成する .der パブリックキーのコマンド例:
```
xxd -p pubkey.der > outFile
```
パブリックキーが .pem 形式の場合、base64 でエンコードされた部分を抽出してバイナリ形式にデコードし、16 進エンコードして 16 進ファイルを生成できます。
例えば、次のコマンドを使用して、.pem パブリックキーの 16 進ファイルを生成します。
1. キーの base64 でエンコードされた部分を取り出し (ヘッダーとフッターを取り除く)、ファイルに保存し、`base64key` などの名前を付けて、次のコマンドを使用し .der 形式に変換します。
```
base64 —decode base64key > pubkey.der
```
1. `xxd` コマンドを実行して、16 進形式に変換します。
```
xxd -p pubkey.der > outFile
```
**`devices.secureElementConfig.SecureElementSerialNumber`**
(オプション) 安全なエレメントのシリアル番号。FreeRTOS デモ/テストプロジェクトを実行するときにデバイスのパブリックキーと共にシリアル番号が出力される場合、このフィールドを指定します。
**`devices.secureElementConfig.preProvisioned`**
(オプション) デバイスにロックダウンされた認証情報を持つ事前プロビジョニングされたセキュア要素があり、オブジェクトをインポート、作成、または破棄できない場合は、「Yes」に設定します。この設定は、`features` で `KeyProvisioning` が「Onboard」に設定され、`PKCS11` が「ECC」に設定されている場合のみ有効です。
**`identifiers`**
(オプション) 任意の名前と値のペアの配列。これらの値は、次のセクションで説明されているビルドコマンドやフラッシュコマンドで使用できます。
# ビルド、フラッシュ、テスト設定を設定する
IDT for FreeRTOS でテストのビルドとボードへのフラッシュが自動的に実行されるようにするには、ハードウェアでビルドコマンドとフラッシュコマンドを実行するように IDT を設定する必要があります。ビルドとフラッシュのコマンド設定は、`config` フォルダにある `userdata.json` テンプレートファイルで設定されています。
# デバイスをテストするための設定
ビルド、フラッシュ、およびテストの設定は、`configs/userdata.json` ファイルで行います。エコーサーバー設定は、`customPath` のクライアントとサーバーの証明書とキーの両方をロードすることによってサポートされます。詳細については、[FreeRTOS 移植ガイド](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html)の*エコーサーバーのセットアップ*を参照してください。次の JSON の例は、複数のデバイスをテストするために IDT for FreeRTOS を設定する方法を示します。
```
{
"sourcePath": "/absolute-path-to/freertos",
"vendorPath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name",
// ***********The sdkConfiguration block below is needed if you are not using the default, unmodified FreeRTOS repo.
// In other words, if you are using the default, unmodified FreeRTOS repo then remove this block***************
"sdkConfiguration": {
"name": "sdk-name",
"version": "sdk-version",
"path": "/absolute-path-to/sdk"
},
"buildTool": {
"name": "your-build-tool-name",
"version": "your-build-tool-version",
"command": [
"{{config.idtRootPath}}/relative-path-to/build-parallel.sh {{testData.sourcePath}} {{enableTests}}"
]
},
"flashTool": {
"name": "your-flash-tool-name",
"version": "your-flash-tool-version",
"command": [
"/{{config.idtRootPath}}/relative-path-to/flash-parallel.sh {{testData.sourcePath}} {{device.connectivity.serialPort}} {{buildImageName}}"
],
"buildImageInfo" : {
"testsImageName": "tests-image-name",
"demosImageName": "demos-image-name"
}
},
"testStartDelayms": 0,
"clientWifiConfig": {
"wifiSSID": "ssid",
"wifiPassword": "password",
"wifiSecurityType": "eWiFiSecurityOpen | eWiFiSecurityWEP | eWiFiSecurityWPA | eWiFiSecurityWPA2 | eWiFiSecurityWPA3"
},
"testWifiConfig": {
"wifiSSID": "ssid",
"wifiPassword": "password",
"wifiSecurityType": "eWiFiSecurityOpen | eWiFiSecurityWEP | eWiFiSecurityWPA | eWiFiSecurityWPA2 | eWiFiSecurityWPA3"
},
//**********
//This section is used to start echo server based on server certificate generation method,
//When certificateGenerationMethod is set as Automatic specify the eccCurveFormat to generate certifcate and key based on curve format,
//When certificateGenerationMethod is set as Custom specify the certificatePath and PrivateKeyPath to be used to start echo server
//**********
"echoServerCertificateConfiguration": {
"certificateGenerationMethod": "Automatic | Custom",
"customPath": {
"clientCertificatePath":"/path/to/clientCertificate",
"clientPrivateKeyPath": "/path/to/clientPrivateKey",
"serverCertificatePath":"/path/to/serverCertificate",
"serverPrivateKeyPath": "/path/to/serverPrivateKey"
},
"eccCurveFormat": "P224 | P256 | P384 | P521"
},
"echoServerConfiguration": {
"securePortForSecureSocket": 33333, // Secure tcp port used by SecureSocket test. Default value is 33333. Ensure that the port configured isn't blocked by the firewall or your corporate network
"insecurePortForSecureSocket": 33334, // Insecure tcp port used by SecureSocket test. Default value is 33334. Ensure that the port configured isn't blocked by the firewall or your corporate network
"insecurePortForWiFi": 33335 // Insecure tcp port used by Wi-Fi test. Default value is 33335. Ensure that the port configured isn't blocked by the firewall or your corporate network
},
"otaConfiguration": {
"otaFirmwareFilePath": "{{testData.sourcePath}}/relative-path-to/ota-image-generated-in-build-process",
"deviceFirmwareFileName": "ota-image-name-on-device",
"otaDemoConfigFilePath": "{{testData.sourcePath}}/relative-path-to/ota-demo-config-header-file",
"codeSigningConfiguration": {
"signingMethod": "AWS | Custom",
"signerHashingAlgorithm": "SHA1 | SHA256",
"signerSigningAlgorithm": "RSA | ECDSA",
"signerCertificate": "arn:partition:service:region:account-id:resource:qualifier | /absolute-path-to/signer-certificate-file",
"signerCertificateFileName": "signerCertificate-file-name",
"compileSignerCertificate": boolean,
// ***********Use signerPlatform if you choose aws for signingMethod***************
"signerPlatform": "AmazonFreeRTOS-Default | AmazonFreeRTOS-TI-CC3220SF",
"untrustedSignerCertificate": "arn:partition:service:region:account-id:resourcetype:resource:qualifier",
// ***********Use signCommand if you choose custom for signingMethod***************
"signCommand": [
"/absolute-path-to/sign.sh {{inputImageFilePath}} {{outputSignatureFilePath}}"
]
}
},
// ***********Remove the section below if you're not configuring CMake***************
"cmakeConfiguration": {
"boardName": "board-name",
"vendorName": "vendor-name",
"compilerName": "compiler-name",
"frToolchainPath": "/path/to/freertos/toolchain",
"cmakeToolchainPath": "/path/to/cmake/toolchain"
},
"freertosFileConfiguration": {
"required": [
{
"configName": "pkcs11Config",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/core_pkcs11_config.h"
},
{
"configName": "pkcs11TestConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/iot_test_pkcs11_config.h"
}
],
"optional": [
{
"configName": "otaAgentTestsConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/ota_config.h"
},
{
"configName": "otaAgentDemosConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_demos/config_files/ota_config.h"
},
{
"configName": "otaDemosConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_demos/config_files/ota_demo_config.h"
}
]
}
}
```
次のリストは、`userdata.json` で使用される属性です。
**`sourcePath`**
移植された FreeRTOS ソースコードのルートへのパス。SDK を使用する並行テストの場合、`sourcePath` は `{{userData.sdkConfiguration.path}}` プレースホルダーを使用して設定できます。例:
```
{ "sourcePath":"{{userData.sdkConfiguration.path}}/freertos" }
```
**`vendorPath`**
ベンダー固有の FreeRTOS コードへのパス。シリアルテストでは、`vendorPath` を絶対パスとして設定できます。例:
```
{ "vendorPath":"C:/path-to-freertos/vendors/espressif/boards/esp32" }
```
並行テストの場合、`vendorPath` は `{{testData.sourcePath}}` プレースホルダーを使用して設定できます。例:
```
{ "vendorPath":"{{testData.sourcePath}}/vendors/espressif/boards/esp32" }
```
`vendorPath` 変数は SDK なしで実行している場合にのみ必要で、それ以外の場合は削除できます。
SDK なしでテストを並行して実行する場合、`vendorPath`、`buildTool`、および `flashTool` フィールドで `{{testData.sourcePath}}` プレースホルダーを使用する必要があります。1 つのデバイスでテストを実行するときは、`vendorPath`、`buildTool`、および `flashTool` フィールドで絶対パスを使用する必要があります。SDK を使用して実行する場合、`{{sdkPath}}` プレースホルダーを `sourcePath`、`buildTool`、および `flashTool` コマンドで使用する必要があります。
**`sdkConfiguration`**
移植に必要な範囲を超えてファイルやフォルダの構造を変更して FreeRTOS を認定する場合は、このブロックで SDK 情報を設定する必要があります。SDK 内で移植された FreeRTOS を認定しない場合は、このブロックを完全に省略する必要があります。
**`sdkConfiguration.name`**
FreeRTOS で使用する SDK の名前。SDK を使用しない場合は、`sdkConfiguration` ブロック全体を省略する必要があります。
**`sdkConfiguration.version`**
FreeRTOS で使用する SDK のバージョン。SDK を使用しない場合は、`sdkConfiguration` ブロック全体を省略する必要があります。
**`sdkConfiguration.path`**
FreeRTOS コードがある SDK ディレクトリへの絶対パス。SDK を使用しない場合は、`sdkConfiguration` ブロック全体を省略する必要があります。
**`buildTool`**
ソースコードをビルドするためのコマンドを含むビルドスクリプト (.bat または .sh) の完全パス。ビルドコマンドのソースコードパスへの参照はすべて AWS IoT Device Tester 変数に置き換え、SDK パスへの`{{testdata.sourcePath}}`参照は に置き換える必要があります`{{sdkPath}}`。IDT の絶対パスまたは相対パスを参照するには、`{{config.idtRootPath}}` プレースホルダーを使用します。
**`testStartDelayms`**
FreeRTOS test runner がテストの実行を開始する前に待機するミリ秒数を指定します。これは、ネットワークやその他の遅延が原因でテスト対象のデバイスが重要なテスト情報の出力を開始してから、IDT が接続してロギングを開始する場合に役立ちます。最大許容値は 30000 ms (30 秒) です。この値は FreeRTOS テストグループにのみ適用され、OTA テストなど FreeRTOS test runner を使用しない他のテストグループには適用されません。
**`flashTool`**
デバイス用のフラッシュコマンドを含むフラッシュスクリプト (.sh または .bat) の完全パス。フラッシュコマンドのソースコードパスへの参照はすべて IDT for FreeRTOS 変数 `{{testdata.sourcePath}}` に置き換え、SDK パスへ参照はすべて IDT for FreeRTOS 変数 `{{sdkPath}}` に置き換える必要があります。IDT の絶対パスまたは相対パスを参照するには、`{{config.idtRootPath}}` プレースホルダーを使用します。
**`buildImageInfo`**
**`testsImageName`**
`freertos-source/tests` フォルダからテストを構築するときにビルドコマンドによって生成されるファイルの名前。
**`demosImageName`**
`freertos-source/demos` フォルダからテストを構築するときにビルドコマンドによって生成されるファイルの名前。
**`clientWifiConfig`**
クライアント側の Wi-Fi 設定。Wi-Fi ライブラリテストは、MCU ボードに対し、2 つのアクセスポイントへの接続を要求します。(2 つのアクセスポイントは同じにすることができます)。この属性は、最初のアクセスポイントの Wi-Fi を設定します。一部の Wi-Fi テストケースでは、アクセスポイントにセキュリティが設定されていて、オープンでないことが求められます。両方のアクセスポイントが IDT を実行しているホストコンピュータと同じサブネット上にあることを確認してください。
**`wifi_ssid`**
Wi-Fi の SSID。
**`wifi_password`**
Wi-Fi のパスワード。
**`wifiSecurityType`**
使用されている Wi-Fi セキュリティの種類。次のいずれかの値です。
+ `eWiFiSecurityOpen`
+ `eWiFiSecurityWEP`
+ `eWiFiSecurityWPA`
+ `eWiFiSecurityWPA2`
+ `eWiFiSecurityWPA3`
ボードが Wi-Fi をサポートしていない場合でも、`device.json` ファイルに `clientWifiConfig` セクションを含める必要がありますが、属性の値は省略してかまいません。
**`testWifiConfig`**
テストの Wi-Fi 設定。Wi-Fi ライブラリテストは、MCU ボードに対し、2 つのアクセスポイントへの接続を要求します。(2 つのアクセスポイントは同じにすることができます)。この属性は、2 番目のアクセスポイントの Wi-Fi を設定します。一部の Wi-Fi テストケースでは、アクセスポイントにセキュリティが設定されていて、オープンでないことが求められます。両方のアクセスポイントが IDT を実行しているホストコンピュータと同じサブネット上にあることを確認してください。
**`wifiSSID`**
Wi-Fi の SSID。
**`wifiPassword`**
Wi-Fi のパスワード。
**`wifiSecurityType`**
使用されている Wi-Fi セキュリティの種類。次のいずれかの値です。
+ `eWiFiSecurityOpen`
+ `eWiFiSecurityWEP`
+ `eWiFiSecurityWPA`
+ `eWiFiSecurityWPA2`
+ `eWiFiSecurityWPA3`
ボードが Wi-Fi をサポートしていない場合でも、`device.json` ファイルに `testWifiConfig` セクションを含める必要がありますが、属性の値は省略してかまいません。
**`echoServerCertificateConfiguration`**
セキュアソケットテスト用に設定可能なエコーサーバー証明書生成プレースホルダー。このフィールドは必須です。
**`certificateGenerationMethod`**
サーバー証明書を自動的に生成するか、手動で生成するかを指定します。
**`customPath`**
`certificateGenerationMethod` が「Custom」の場合は、`certificatePath` と `privateKeyPath` が必要です。
**`certificatePath`**
サーバー証明書のファイルパスを指定します。
**`privateKeyPath`**
プライベートキーのファイルパスを指定します。
**`eccCurveFormat`**
ボードがサポートする曲線形式を指定します。`PKCS11` が `device.json` で「ecc」に設定されている場合に必要です。有効な値は「P224」、「P256」、「P384」、または「P521」です。
**`echoServerConfiguration`**
WiFi およびセキュアソケットテスト用の設定可能なエコーサーバーポート。このフィールドはオプションです。
**`securePortForSecureSocket`**
セキュアソケットテスト用に TLS ありでエコーサーバーをセットアップするために使用されるポート。デフォルト値は 33333 です。設定するポートがファイアウォールまたは社内ネットワークによってブロックされていないことを確認します。
**`insecurePortForSecureSocket`**
セキュアソケットテスト用に TLS なしでエコーサーバーをセットアップするために使用されるポート。テストで使用されるデフォルト値は 33334 です。設定するポートがファイアウォールまたは社内ネットワークによってブロックされていないことを確認します。
**`insecurePortForWiFi`**
WiFi テスト用に TLS なしでエコーサーバーをセットアップするために使用されるポート。テストで使用されるデフォルト値は 33335 です。設定するポートがファイアウォールまたは社内ネットワークによってブロックされていないことを確認します。
**`otaConfiguration`**
OTA 設定。[オプション]
**`otaFirmwareFilePath`**
ビルドの後に作成された OTA イメージの完全パス。例えば、`{{testData.sourcePath}}/relative-path/to/ota/image/from/source/root`。
**`deviceFirmwareFileName`**
MCU デバイスで、OTA ファームウェアがある場所を示す完全ファイルパス。このフィールドを使用しないデバイスもありますが、値は指定しなければなりません。
**`otaDemoConfigFilePath`**
`afr-source/vendors/vendor/boards/board/aws_demos/config_files/` 内にある `aws_demo_config.h` への完全パス。これらのファイルは、FreeRTOS が提供する移植コードテンプレートに含まれています。
**`codeSigningConfiguration`**
コード署名の設定。
**`signingMethod`**
コード署名の方法。想定される値は、`AWS` または `Custom` です。
北京および寧夏リージョンでは、`Custom` を使用します。`AWS` コード署名は、これらのリージョンではサポートされていません。
**`signerHashingAlgorithm`**
デバイスでサポートされているハッシュアルゴリズム。想定される値は、`SHA1` または `SHA256` です。
**`signerSigningAlgorithm`**
デバイスでサポートされている署名アルゴリズム。想定される値は、`RSA` または `ECDSA` です。
**`signerCertificate`**
OTA 用の信頼された証明書。
AWS コード署名方法では、 にアップロードされた信頼された証明書の Amazon リソースネーム (ARN) を使用します AWS Certificate Manager。
カスタムコード署名方法としては、署名者の証明書ファイルへの絶対パスを使用します。
信頼された証明書の作成の詳細については、「[コード署名証明書の作成](ota-code-sign-cert.md)」を参照してください。
**`signerCertificateFileName`**
デバイスのコード署名証明書のファイル名。この値は、`aws acm import-certificate` コマンド実行時に指定したファイル名と一致する必要があります。
詳細については、「[コード署名証明書の作成](ota-code-sign-cert.md)」を参照してください。
**`compileSignerCertificate`**
`true` コード署名者署名検証証明書がプロビジョニングまたはフラッシュされていない場合、 に設定するため、プロジェクトにコンパイルする必要があります。 は信頼できる証明書 AWS IoT Device Tester を取得し、 にコンパイルします`aws_codesigner_certifiate.h`。
**`untrustedSignerCertificate`**
一部の OTA テストで信頼できない証明書として使用される 2 番目の証明書の ARN またはファイルパス。証明書を作成する方法の詳細については、「[コード署名証明書の作成](https://docs.aws.amazon.com/freertos/latest/userguide/ota-code-sign-cert.html)」を参照してください。
**`signerPlatform`**
OTA 更新ジョブの作成時に AWS Code Signer が使用する署名およびハッシュアルゴリズム。現在、このフィールドで可能な値は、`AmazonFreeRTOS-TI-CC3220SF` と `AmazonFreeRTOS-Default` です。
+ `SHA1` および `RSA` の場合は、`AmazonFreeRTOS-TI-CC3220SF` を選択します。
+ `SHA256` および `ECDSA` の場合は、`AmazonFreeRTOS-Default` を選択します。
設定に `SHA256` \$1 `RSA` または `SHA1` \$1 `ECDSA` が必要な場合は、当社に追加のサポートを依頼してください。
`signingMethod` として `Custom` を選択した場合は、`signCommand` を設定します。
**`signCommand`**
カスタムコード署名を実行するために使用するコマンド。テンプレートは `/configs/script_templates` ディレクトリにあります。
このコマンドには `{{inputImageFilePath}}` と `{{outputSignatureFilePath}}` の 2 つのプレースホルダーが必要です。`{{inputImageFilePath}}` は、IDT によって構築される署名対象のイメージのファイルパスです。`{{outputSignatureFilePath}}` は、スクリプトによって生成される署名のファイルパスです。
**`cmakeConfiguration`**
CMake の設定 [オプション]
CMake テストケースを実行するには、ベンダー名、ボード名、および `frToolchainPath` または `compilerName` を指定する必要があります。CMake ツールチェーンへのカスタムパスがある場合は、`cmakeToolchainPath` を指定することもできます。
**`boardName`**
テスト対象ボードの名前。ボード名は、`path/to/afr/source/code/vendors/vendor/boards/board` のフォルダ名と同じにする必要があります。
**`vendorName`**
テスト対象ボードのベンダー名。ベンダー名は、`path/to/afr/source/code/vendors/vendor` のフォルダ名と同じにする必要があります。
**`compilerName`**
コンパイラ名。
**`frToolchainPath`**
コンパイラツールチェーンへの完全修飾パス。
**`cmakeToolchainPath` **
CMake ツールチェーンへの完全修飾パス。このフィールドはオプションです
**`freertosFileConfiguration`**
IDT がテストを実行する前に変更する FreeRTOS ファイルの設定。
**`required`**
このセクションでは、設定ファイルを移動済みの必須テストを指定します (PKCS11、TLS など)。
**`configName`**
設定対象のテストの名前。
**`filePath`**
`freertos` リポジトリ内の設定ファイルの絶対パス。`{{testData.sourcePath}}` 変数を使用してパスを定義します。
**`optional`**
このセクションでは、設定ファイルを移動済みの必須テストを指定します (OTA、WiFi など)。
**`configName`**
設定対象のテストの名前。
**`filePath`**
`freertos` リポジトリ内の設定ファイルの絶対パス。`{{testData.sourcePath}}` 変数を使用してパスを定義します。
**注記**
CMake テストケースを実行するには、ベンダー名、ボード名、および `afrToolchainPath` または `compilerName` を指定する必要があります。CMake ツールチェーンへのカスタムパスがある場合は、`cmakeToolchainPath` を指定することもできます。
# IDT for FreeRTOS 変数
コードを構築してデバイスをフラッシュするコマンドでは、正常に実行するために接続やデバイスに関するその他の情報が必要になる場合があります。 AWS IoT Device Tester を使用すると、[JsonPath](https://goessner.net/articles/JsonPath/) を使用してフラッシュおよびビルドコマンドでデバイス情報を参照できます。単純な JsonPath 式を使用して、`device.json` ファイルで指定されている情報を取得することができます。
## パス変数
IDT for FreeRTOS は、コマンドラインと設定ファイルで使用できる次のようなパス変数を定義します。
**`{{testData.sourcePath}}`**
ソースコードパスに拡張されます。この変数を使用する場合は、フラッシュコマンドとビルドコマンドの両方で使用する必要があります。
**`{{sdkPath}}`**
ビルドコマンドとフラッシュコマンドで使用する場合、`userData.sdkConfiguration.path` で値に拡張されます。
**`{{device.connectivity.serialPort}}`**
シリアルポートに拡張されます。
**`{{device.identifiers[?(@.name == 'serialNo')].value[0]}}`**
デバイスのシリアル番号に拡張されます。
**`{{enableTests}}`**
ビルドがテスト用 (値 1) であるか、デモ (値 0) であるかを示す整数値。
**`{{buildImageName}}`**
ビルドコマンドによってビルドされたイメージのファイル名。
**`{{otaCodeSignerPemFile}}`**
OTA Code Signer の PEM ファイル。
**`{{config.idtRootPath}}`**
AWS IoT Device Tester ルートパスに展開します。この変数は、ビルドコマンドとフラッシュコマンドで使用される場合、IDT の絶対パスを置き換えます。
# IDT ユーザーインターフェイスを使用して FreeRTOS 認定スイートを実行する
IDT v4.3.0 以降、 AWS IoT Device Tester for FreeRTOS (IDT-FreeRTOS) には、IDT コマンドライン実行可能ファイルおよび関連する設定ファイルを操作できるウェブベースのユーザーインターフェイスが含まれています。IDT-FreeRTOS UI を使用して新しい設定を作成すると、IDT テストの実行や既存の設定の変更ができます。UI を使用して IDT 実行可能ファイルを呼び出してテストを実行することもできます。
IDT-FreeRTOS UI には次の機能があります。
+ IDT-FreeRTOS テストの設定ファイルを簡単にセットアップできます。
+ IDT-FreeRTOS を使用して認定テストを簡単に実行できます。
コマンドラインを使用して認定テストを実行する方法については、[マイクロコントローラーボードの最初のテスト](qual-steps.md)を参照してください。
このセクションでは、IDT-FreeRTOS UI を使用するための前提条件と、UI で認定テストの実行を開始する方法について説明します。
**Topics**
+ [FreeRTOS 認定スイートを実行するための前提条件を設定する](dev-tester-ui-prereqs.md)
+ [IDT-FreeRTOS UI を開始する](dev-tester-ui-getting-started.md)
# FreeRTOS 認定スイートを実行するための前提条件を設定する
このセクションでは、 AWS IoT Device Testerでマイクロコントローラーをテストするための前提条件について説明します。
**Topics**
+ [サポートされているウェブブラウザを使用する](#idt-ui-supported-web-browser)
+ [FreeRTOS をダウンロードする](#ui-download-afr)
+ [IDT for FreeRTOS のダウンロード](#ui-download-dev-tester-afr)
+ [AWS アカウントの作成と設定](#ui-config-aws-account)
+ [AWS IoT Device Tester マネージドポリシー](#ui-managed-policy)
## サポートされているウェブブラウザを使用する
IDT-FreeRTOS UI では以下のウェブブラウザがサポートされています。
| ブラウザ | バージョン |
| --- | --- |
| Google Chrome | 最新の 3 つのメジャーバージョン |
| Mozilla Firefox | 最新の 3 つのメジャーバージョン |
| Microsoft Edge | 最新の 3 つのメジャーバージョン |
| MacOS 版 Apple Safari | 最新の 3 つのメジャーバージョン |
より良いエクスペリエンスを得るには、Google Chrome または Mozilla Firefox を使用することをお勧めします。
**注記**
IDT-FreeRTOS UI は Microsoft Internet Explorer をサポートしていません。
## FreeRTOS をダウンロードする
次のコマンドを使用して、[GitHub](https://github.com/aws/amazon-freertos) から FreeRTOS のリリースをダウンロードできます。
```
git clone --branch --recurse-submodules https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
ここで、 は、[AWS IoT Device Tester のサポートされているバージョン:](dev-test-versions-afr.md)に記載された IDT バージョンに対応する FreeRTOS のバージョン (202007.00 など) です。これにより、サブモジュールを含むすべてのソースコードを入手でき、FreeRTOS と IDT が相互に対応するバージョンを使用できます。
Windows では、パスの長さは 260 文字に制限されています。FreeRTOS のパスの構造は、レベルが多く、深いため、 Windows を使用している場合は、ファイルパスを 260 文字に抑えてください。例えば、`C:\Users\username\programs\projects\myproj\FreeRTOS\` ではなく、`C:\FreeRTOS` に FreeRTOS のクローンを作成します。
### LTS 認定 (LTS ライブラリを使用する FreeRTOS の認定) に関する考慮事項
+ マイクロコントローラーを AWS Partner Device Catalog の FreeRTOS の長期サポート (LTS) ベースのバージョンをサポートするように指定するには、マニフェストファイルを指定する必要があります。詳細については、*FreeRTOS 資格ガイド*の [FreeRTOS 資格チェックリスト](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist.html)を参照してください。
+ マイクロコントローラーが FreeRTOS の LTS ベースのバージョンをサポートし、 AWS それを Partner Device Catalog に送信するための認定を受けるには、 AWS IoT Device Tester FreeRTOS 認定 (FRQ) テストスイートバージョン v1.4.x で (IDT) を使用する必要があります。
+ LTS ベースのバージョンの FreeRTOS がサポートされるのは、FreeRTOS のバージョン 202012.xx のみです。
## IDT for FreeRTOS のダウンロード
どのバージョンの FreeRTOS にも、認定テストの実行に対応する IDT for FreeRTOS の対応バージョンがあります。[AWS IoT Device Tester のサポートされているバージョン:](dev-test-versions-afr.md) から適切なバージョンの IDT for FreeRTOS をダウンロードします。
IDT for FreeRTOS を、ファイルシステム上で読み取りおよび書き込みアクセス許可を持っている場所に抽出します。Microsoft Windows ではパスの長さに文字数の制限があるため、IDT for FreeRTOS は `C:\` や `D:\` などのルートディレクトリに抽出します。
**注記**
IDT パッケージをローカルドライブに抽出することをお勧めします。複数のユーザーが NFS ディレクトリや Windows ネットワーク共有フォルダなどの共有場所から IDT を実行できるようにすると、システムが応答しないか、データが破損する可能性があります。
## AWS アカウントの作成と設定
### にサインアップする 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)」を参照してください。
## AWS IoT Device Tester マネージドポリシー
`AWSIoTDeviceTesterForFreeRTOSFullAccess` マネージドポリシーには、デバイステスターがメトリクスを実行および収集できるように、次のアクセス許可が含まれています。
+ `iot-device-tester:SupportedVersion`
IDT でサポートされている FreeRTOS のバージョンとテストスイートのバージョンのリストを取得するアクセス許可を付与し、それらのバージョンを AWS CLIから使用できるようにします。
+ `iot-device-tester:LatestIdt`
ダウンロード可能な AWS IoT Device Tester 最新バージョンを取得するアクセス許可を付与します。
+ `iot-device-tester:CheckVersion`
製品、テストスイート、および AWS IoT Device Tester バージョンの組み合わせに互換性があることを確認するアクセス許可を付与します。
+ `iot-device-tester:DownloadTestSuite`
テストスイートをダウンロードするアクセス許可を付与 AWS IoT Device Tester します。
+ `iot-device-tester:SendMetrics`
AWS IoT Device Tester 使用状況メトリクスデータを公開するアクセス許可を付与します。
# IDT-FreeRTOS UI を開始する
このセクションでは、IDT-FreeRTOS UI を使用して設定を作成または変更する方法と、テストの実行方法について説明します。
**Topics**
+ [AWS 認証情報を設定する](#configure-aws-credentials)
+ [IDT-FreeRTOS UI を開く](#open-idt-ui)
+ [新しい設定を作成する](#create-new-configuration)
+ [既存の設定を変更する](#modify-existing-configuration)
+ [認定テストを実行する](#run-tests-from-ui)
## AWS 認証情報を設定する
で作成した AWS ユーザーの認証情報を設定する必要があります[AWS アカウントの作成と設定](dev-tester-ui-prereqs.md#ui-config-aws-account)。以下のいずれかの方法で認証情報を指定できます。
+ 認証情報ファイルを使用する
+ 環境変数を使用する
### 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 =
```
**注記**
`default` AWS プロファイルを使用しない場合は、必ず IDT-FreeRTOS UI でプロファイル名を指定してください。プロファイルの詳細については、「[設定ファイルと認証情報ファイルの設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html)」を参照してください。
### 環境変数を使用して AWS 認証情報を設定する
環境変数は、オペレーティングシステムによって維持され、システムコマンドによって使用される変数です。SSH セッションを閉じると、これらは保存されません。IDT-FreeRTOS UI は、環境変数の `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-FreeRTOS UI を開く
**IDT-FreeRTOS UI を開くには**
1. サポートされているバージョンの IDT-FreeRTOS をダウンロードし、ダウンロードしたアーカイブを、ファイルシステム上で読み取りおよび書き込みアクセス許可を持っている場所に抽出します。
1. 次のコマンドを実行して IDT-FreeRTOS インストールディレクトリに移動します。
```
cd devicetester-extract-location/bin
```
1. 次のコマンドを実行して IDT-FreeRTOS UI を開きます。
------
#### [ Linux ]
```
.devicetestergui_linux_x86-64.exe
```
------
#### [ Windows ]
```
./devicetestergui_win_x64-64
```
------
#### [ macOS ]
```
./devicetestergui_mac_x86-64
```
**注記**
Mac では、システムで UI を実行できるようにするには、**[システム環境設定 > セキュリティとプライバシー]** に移動します。テストを実行するときは、これをさらに 3 回実行することが必要になる場合があります。
------
IDT-FreeRTOS UI がデフォルトのブラウザで開きます。サポートされるブラウザの詳細については、[サポートされているウェブブラウザを使用する](dev-tester-ui-prereqs.md#idt-ui-supported-web-browser)を参照してください。
## 新しい設定を作成する
初めて使用する場合、IDT-FreeRTOS がテストを実行するのに必要な JSON 設定ファイルをセットアップするための新しい設定を作成する必要があります。これにより、テストを実行したり、作成した設定を変更できます。
`config.json`、`device.json`、および `userdata.json` ファイルの例については、[マイクロコントローラーボードの最初のテスト](qual-steps.md)を参照してください。Bluetooth Low Energy (BLE) テストにのみ使用する `resource.json` ファイルの例については、[Bluetooth Low Energy テストを実行する](afr-bridgekeeper-dt-bt.md)を参照してください。
**新しい設定を作成するには**
1. IDT-FreeRTOS UI でナビゲーションメニューを開いて、**[Create new configuration]** (新しい設定の作成) を選択します。
**重要**
UI を開く前に、 AWS 認証情報を設定する必要があります。認証情報を設定していない場合は、IDT-FreeRTOS UI ブラウザウィンドウを閉じて、[AWS 認証情報を設定する](#configure-aws-credentials)の手順に従います。その後に IDT-FreeRTOS UI を再度開きます。
1. 設定ウィザードに従って、認定テストの実行に使用される IDT 構成設定を入力します。このウィザードで `devicetester-extract-location/config` ディレクトリにある JSON 設定ファイル内の次の設定を行います。
+ **AWS 設定** — IDT-FreeRTOS AWS アカウント がテスト実行中に AWS リソースを作成するために使用する情報。これらの設定は `config.json` ファイルで行われます。
+ **[FreeRTOS repository]** (FreeRTOS リポジトリ): FreeRTOS のリポジトリと移植されたコードへの絶対パス、および実行する認定のタイプ。これらの設定は `userdata.json` ファイルで行われます。
認定テストを実行するには、デバイス用に FreeRTOS を移植する必要があります。詳細については、[FreeRTOS 移植ガイド](https://docs.aws.amazon.com/freertos/latest/portingguide/)を参照してください。
+ **[Build and flash]** (ビルドとフラッシュ): IDT がボード上でテストを自動的にビルドおよびフラッシュできるようにする、ハードウェア用のビルドコマンドとフラッシュコマンド。これらの設定は `userdata.json` ファイルで行われます。
+ **[Devices]** (デバイス): テスト対象のデバイス用のデバイスプール設定。これらの設定は、`device.json` ファイルのデバイスプールに関する `id` および `sku` フィールドと `devices` ブロックで行われます。
+ **[Networking]** (ネットワーク): デバイスのネットワーク通信サポートをテストするための設定。これらの設定は、`device.json` ファイルの `features` ブロックと `userdata.json` ファイルの `clientWifiConfig` および `testWifiConfig` ブロックで行われます。
+ **[Echo server]** (エコーサーバー): セキュアソケットテスト用のエコーサーバー設定。これらの設定は `userdata.json` ファイルで行われます。
エコーサーバー設定の詳細については、[https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html)を参照してください。
+ **[CMake]**: (オプション) CMake ビルド機能テストを実行するための設定。この設定は、CMake をビルドシステムとして使用する場合にのみ必要です。これらの設定は `userdata.json` ファイルで行われます。
+ **[BLE]**: Bluetooth Low Energy 機能テストを実行するための設定。これらの設定は、`device.json` ファイルの `features` ブロックおよび `resource.json` ファイルで行われます。
+ **[OTA]**: OTA 機能テストを実行するための設定。これらの設定は、`device.json` ファイルの `features` ブロックおよび `userdata.json` ファイルで行われます。
1. **[Review]** (確認) ページで、設定情報を確認します。
設定の確認が完了したら、**[Run tests]** (テストの実行) を選択して、認定テストを実行します。
## 既存の設定を変更する
IDT の設定ファイルを既にセットアップしている場合は、IDT-FreeRTOS UI を使用して既存の設定を変更できます。既存の設定ファイルが `devicetester-extract-location/config` ディレクトリにあることを確認します。
**新しい設定を変更するには**
1. IDT-FreeRTOS UI でナビゲーションメニューを開いて、**[Edit existing configuration]** (既存の設定の編集) を選択します。
設定ダッシュボードには、既存の構成設定に関する情報が表示されます。設定が正しくない、または使用できない場合、設定のステータスは `Error validating configuration` です。
1. 既存の設定を変更するには、以下のステップを実行します。
1. 構成設定の名前を選択して、設定ページを開きます。
1. 設定を変更し、**[Save]** (保存) を選択して、対応する設定ファイルを再生成します。
設定の変更が完了したら、すべての構成設定が検証に合格することを確認します。各構成設定のステータスが `Valid` の場合、この設定を使用して認定テストを実行できます。
## 認定テストを実行する
IDT-FreeRTOS の設定を作成したら、認定テストを実行できます。
**認定テストを実行するには**
1. 設定を確認します。
1. ナビゲーションメニューで、**[Run tests]** (テストの実行) を選択します。
1. テストの実行を開始するには、**[Start tests]** (テストの開始) を選択します。
IDT-FreeRTOS は認定テストを実行し、テスト実行の概要とエラーを **Test runner** コンソールに表示します。テストの実行が完了したら、次の場所でテスト結果とログを確認できます。
+ テスト結果は、`devicetester-extract-location/results/execution-id` ディレクトリにあります。
+ テストのログは `devicetester-extract-location/results/execution-id/logs` ディレクトリにあります。
テスト結果とログの詳細については、「[IDT for FreeRTOS の結果を表示する](view-results-frq.md)」および「[IDT for FreeRTOS ログを表示する](view-logs-frq.md)」を参照してください。
# Bluetooth Low Energy テストを実行する
このセクションでは、 AWS IoT Device Tester for FreeRTOS を使用して Bluetooth Low Energy テストをセットアップして実行する方法について説明します。
コア資格には Bluetooth テストの必要はありません。FreeRTOS Bluetooth サポートを使用してデバイスをテストしない場合はこのセットアップをスキップできますが、device.json の BLE 機能を `No` に設定していることを確認してください。
## 前提条件
+ 「[マイクロコントローラーボードの最初のテスト](qual-steps.md)」の手順に従います。
+ Raspberry Pi 4B または 3B\$1。(Raspberry Pi BLE コンパニオンアプリケーションを実行するために必要)
+ Raspberry Pi のソフトウェア用のマイクロ SD カードおよび SD カードアダプタ。
## Raspberry Pi のセットアップ
テスト対象デバイス (DUT) の BLE 機能をテストするには、Raspberry Pi Model 4B または 3B\$1 を保有している必要があります。
**BLE テストを実行するように Raspberry Pi をセットアップするには**
1. テストの実行に必要なソフトウェアが含まれているカスタム Yocto イメージのいずれかをダウンロードします。
+ [Raspberry Pi 4B 用のイメージ](https://docs.aws.amazon.com/freertos/latest/userguide/freertos/IDTFR_BLE_RaspberryPi4B_1.0.0_2021-04-13.rpi-sd.img)
+ [Raspberry Pi 3B\$1 用のイメージ](https://docs.aws.amazon.com/freertos/latest/userguide/freertos/IDTFR_BLE_RaspberryPi3Bplus_1.0.0_2021-04-13.rpi-sd.img)
**注記**
Yocto イメージは AWS IoT Device Tester 、 for FreeRTOS でのテストにのみ使用し、他の目的では使用しないでください。
1. Raspberry Pi 用の SD カードに yocto イメージをフラッシュします。
1. [Etcher](https://www.balena.io/etcher) などの SD カード書き込みツールを使用して、ダウンロードした `image-name.rpi-sd.img` ファイルを SD カードにフラッシュします。オペレーティングシステムイメージが大きいため、このステップに時間がかかることがあります。次に、SD カードをコンピュータから取り出し、microSD カードを Raspberry Pi に挿入します。
1. Raspberry Pi を設定します。
1. 最初の起動では、Raspberry Pi をモニター、キーボード、およびマウスに接続することをお勧めします。
1. Raspberry Pi をマイクロ USB 電源に接続します。
1. デフォルトの認証情報を使用してサインインします。ユーザー ID には **root** と入力します。パスワードには **idtafr** と入力します。
1. イーサネットまたは Wi-Fi 接続を使用して、Raspberry Pi をネットワークに接続します。
1. Wi-Fi 経由で Raspberry Pi を接続するには、Raspberry Pi 上で `/etc/wpa_supplicant.conf` を開き、`Network` 接続に Wi-Fi 接続を追加します。
```
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
update_config=1
network={
scan_ssid=1
ssid="your-wifi-ssid"
psk="your-wifi-password"
}
```
1. `ifup wlan0` を実行して Wi-Fi 接続を開始します。Wi-Fi ネットワークに接続するには 1 分かかる場合があります。
1. イーサネット接続の場合は、`ifconfig eth0` を実行します。Wi-Fi 接続の場合は、`ifconfig wlan0` を実行します。コマンドの出力に `inet addr` として表示される IP アドレスを書き留めます。この手順の後半でこの IP アドレスが必要になります。
1. (オプション) このテストは、yocto イメージ用のデフォルトの認証情報を使用して SSH を介して Raspberry Pi 上でコマンドを実行します。より高度なセキュリティには、SSH にパブリックキー認証を設定し、パスワードベースの SSH を無効にすることが推奨されます。
1. OpenSSL `ssh-keygen` コマンドを使用して SSH キーを作成します。ホストコンピュータに SSK キーペアがすでにある場合は、 AWS IoT Device Tester FreeRTOS が Raspberry Pi にサインインできるように新しいキーペアを作成するのがベストプラクティスです。
**注記**
Windows にはインストール済みの SSH クライアントがありません。Windows に SSH クライアントをインストールする方法については、「[Windows に SSH ソフトウェアをダウンロードする](https://www.ssh.com/ssh/#sec-Download-client-software)」を参照してください。
1. `ssh-keygen` コマンドは、キーペアを保存する名前とパスの入力を求めます。デフォルトでは、キーペアファイルの名前は `id_rsa` (プライベートキー) と `id_rsa.pub` (パブリックキー) です。macOS および Linux の場合、これらのファイルのデフォルトの場所は `~/.ssh/` です。Windows の場合、デフォルトの場所は `C:\Users\user-name` です。
1. キーフレーズの入力を求められたら、単にエンターキーを押します。
1. AWS IoT Device Tester for FreeRTOS がデバイスにサインインできるように Raspberry Pi に SSH キーを追加するには、ホストコンピュータから `ssh-copy-id` コマンドを使用します。このコマンドは、Raspberry Pi の `~/.ssh/authorized_keys` ファイルにパブリックキーを追加します。
`ssh-copy-id root@raspberry-pi-ip-address`
1. パスワードの入力を求められたら、「**idtafr**」と入力します。これは yocto イメージのデフォルトのパスワードです。
**注記**
`ssh-copy-id` コマンドが引き受けるパブリックキーの名前は `id_rsa.pub` です。macOS および Linux では、デフォルトの場所は ` ~/.ssh/` になります。Windows の場合、デフォルトの場所は `C:\Users\user-name\.ssh` です。パブリックキーに別の名前や別の保存先を指定した場合は、`ssh-copy-id` で `-i` オプションを使用し、SSH 公開鍵への完全修飾パス (`ssh-copy-id -i ~/my/path/myKey.pub` など) を指定する必要があります。SSH キーの作成とパブリックキーのコピーの詳細については、「[SSH-COPY-ID](https://www.ssh.com/ssh/copy-id)」を参照してください。
1. パブリックキー認証が動作していることをテストするには、`ssh -i /my/path/myKey root@raspberry-pi-device-ip` を実行します。
パスワードの入力を求められない場合、パブリックキー認証が動作しています。
1. パブリックキーを使用して Raspberry Pi にサインインできることを確認したら、パスワードベースの SSH を無効にします。
1. Raspberry Pi で `/etc/ssh/sshd_config` ファイルを編集します。
1. `PasswordAuthentication` 属性を `no` に設定します。
1. `sshd_config` ファイルを保存して閉じます。
1. `/etc/init.d/sshd reload` を実行して SSH サーバーを再ロードします。
1. `resource.json` ファイルを作成します。
1. AWS IoT Device Tester を抽出したディレクトリで、 という名前のファイルを作成します`resource.json`。
1. Raspberry Pi に関する次の情報をこのファイルに追加し、*rasp-pi-ip-address* を Raspberry Pi の IP アドレスで置き換えます。
```
[
{
"id": "ble-test-raspberry-pi",
"features": [
{"name":"ble", "version":"4.2"}
],
"devices": [
{
"id": "ble-test-raspberry-pi-1",
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address"
}
}
]
}
]
```
1. SSH にパブリックキー認証の使用を選択しなかった場合、`resource.json` ファイルの `connectivity` セクションに以下を追加します。
```
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address",
"auth": {
"method": "password",
"credentials": {
"user": "root",
"password": "idtafr"
}
}
}
```
1. (オプション) SSH にパブリックキーの使用を選択した場合、`resource.json` ファイルの `connectivity` セクションに以下を追加します。
```
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address",
"auth": {
"method": "pki",
"credentials": {
"user": "root",
"privKeyPath": "location-of-private-key"
}
}
}
```
## FreeRTOS デバイスのセットアップ
`device.json` ファイルで、`BLE` 機能を `Yes` に設定します。Bluetooth テストが利用可能になる前に `device.json` ファイルを開始した場合、BLE 用の機能を `features` 配列に追加する必要があります。
```
{
...
"features": [
{
"name": "BLE",
"value": "Yes"
},
...
}
```
## BLE テストを実行する
`device.json` で BLE 機能を有効にすると、グループ ID を指定せずに `devicetester_[linux | mac | win_x86-64] run-suite` を実行したときに BLE テストが実行されます。* *
BLE テストを個別に実行する場合、次のように BLE の グループ ID を指定できます。`devicetester_[linux | mac | win_x86-64] run-suite --userdata path-to-userdata/userdata.json --group-id FullBLE`。
より高い信頼性のあるパフォーマンスには、Raspberry Pi をテスト対象のデバイス (DUT) に近い位置に配置します。
## BLE テストのトラブルシューティング
「[マイクロコントローラーボードの最初のテスト](qual-steps.md)」のステップを実行したことを確認します。BLE 以外のテストが失敗した場合、Bluetooth 設定がこの問題の原因である可能性はほとんどありません。
# FreeRTOS 認定スイートの実行
AWS IoT Device Tester for FreeRTOS 実行可能ファイルを使用して IDT for FreeRTOS とやり取りします。以下のコマンドラインの例では、デバイスプール (同一デバイスの集合) に対して適格性確認テストを実行する方法を示します。
------
#### [ IDT v3.0.0 and later ]
```
devicetester_[linux | mac | win] run-suite \
--suite-id suite-id \
--group-id group-id \
--pool-id your-device-pool \
--test-id test-id \
--upgrade-test-suite y|n \
--update-idt y|n \
--update-managed-policy y|n \
--userdata userdata.json
```
デバイスプールに対してテストスイートを実行します。`userdata.json` ファイルは、`devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/` ディレクトリに置く必要があります。
**注記**
Windows 上で IDT for FreeRTOS を実行する場合、スラッシュ (/) を使用して `userdata.json` ファイルへのパスを指定します。
特定のテストグループを実行するには、次のコマンドを使用します。
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1.0.1 \
--group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
1 つのデバイスプールに対して 1 つのスイートを実行する場合 (`device.json` ファイルで定義したデバイスプールが 1 つしかない場合)、`suite-id` パラメータと `pool-id` パラメータは省略可能です。
テストグループの特定のテストケースを実行するには、次のコマンドを使用します。
```
devicetester_[linux | mac | win_x86-64] run-suite \
--group-id group-id \
--test-id test-id
```
`list-test-cases` コマンドを使用して、テストグループのテストケースを一覧表示できます。IDT for FreeRTOS のコマンドラインオプション
**group-id**
(オプション) 実行するテストグループ (カンマ区切りリストとして)。指定しない場合、IDT はテストスイートのすべてのテストグループを実行します。
**pool-id**
(オプション) テストするデバイスプール。これは、`device.json` で複数のデバイスプールを定義する場合に必要です。デバイスプールが 1 つしかない場合は、このオプションを省略できます。
**suite-id**
(オプション) 実行するテストスイートのバージョン。指定しない場合、IDT はシステムの tests ディレクトリにある最新バージョンを使用します。
IDT v3.0.0 以降、IDT は新しいテストスイートをオンラインでチェックします。詳細については、[テストスイートのバージョン](idt-test-suite-versions.md) を参照してください。
**test-id**
(オプション) 実行するテスト (カンマ区切りリストとして)。指定した場合、`group-id` は 1 つのグループを指定する必要があります。
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id mqtt --test-id mqtt_test
```
**update-idt**
(オプション) このパラメータが設定されておらず、新しい IDT バージョンが使用可能な場合は、IDT の更新を求められます。このパラメータが `Y` に設定されている場合、IDT は利用可能な新しいバージョンを検出すると、テストの実行を停止します。このパラメータが `N` に設定されている場合、IDT はテストの実行を継続します。
**update-managed-policy**
(オプション) このパラメータを使用せず、IDT がマネージドポリシーが最新でないことを検出すると、マネージドポリシーの更新を求められます。このパラメータが `Y` に設定されている場合、IDT はマネージドポリシーが最新でないことを検出すると、テストの実行を停止します。このパラメータが `N` に設定されている場合、IDT はテストの実行を継続します。
**upgrade-test-suite**
(オプション) これを使用なくても、新しいテストスイートのバージョンが使用可能な場合は、ダウンロードするよう求められます。プロンプトを非表示にするには、`n` を指定して常に最新のテストスイートをダウンロードするか、`y` を指定して指定したテストスイートまたはシステム上の最新バージョンを使用します 。
**Example**
**例**
常に最新のテストスイートをダウンロードして使用するには、次のコマンドを使用します。
```
devicetester_[linux | mac | win_x86-64] run-suite --userdata userdata file --group-id group ID --upgrade-test-suite y
```
システムで最新のテストスイートを使用するには、次のコマンドを使用します。
```
devicetester_[linux | mac | win_x86-64] run-suite --userdata userdata file --group-id group ID --upgrade-test-suite n
```
**h**
`run-suite` オプションの詳細を確認するには、ヘルプオプションを使用します。
**Example**
**例**
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
------
#### [ IDT v1.7.0 and earlier ]
```
devicetester_[linux | mac | win] run-suite \
--suite-id suite-id \
--pool-id your-device-pool \
--userdata userdata.json
```
`userdata.json` ファイルは、`devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/` ディレクトリになければなりません。
**注記**
Windows 上で IDT for FreeRTOS を実行する場合、スラッシュ (/) を使用して `userdata.json` ファイルへのパスを指定します。
特定のテストグループを実行するには、次のコマンドを使用します。
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1 --group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
1 つのデバイスプールに対して 1 つのスイートを実行する場合 (`device.json` ファイルで定義したデバイスプールが 1 つしかない場合)、`suite-id` と `pool-id` は省略可能です。IDT for FreeRTOS のコマンドラインオプション
**group-id**
(オプション) テストグループを指定します。
**pool-id**
テストするデバイスプールを指定します。デバイスプールが 1 つしかない場合は、このオプションを省略できます。
**suite-id**
(オプション) 実行するテストスイートを指定します。
------
## IDT for FreeRTOS コマンド
IDT for FreeRTOS のコマンドは次のオペレーションをサポートしています。
------
#### [ IDT v3.0.0 and later ]
**`help`**
指定されたコマンドに関する情報を一覧表示します。
**`list-groups`**
特定のスイート内のグループを一覧表示します。
**`list-suites`**
使用可能なスイートを一覧表示します。
**`list-supported-products`**
サポートされている製品とテストスイートのバージョンを一覧表示します。
**`list-supported-versions`**
現在の IDT バージョンでサポートされている FreeRTOS およびテストスイートのバージョンを一覧表示します。
**`list-test-cases`**
指定したグループのテストケースを一覧表示します。
**`run-suite`**
デバイスプールに対してテストスイートを実行します。
`--suite-id` オプションを使用してテストスイートのバージョンを指定するか、そのオプションを省略してシステムの最新バージョンを使用します。
個々のテストケースを実行するには、`--test-id` を使用します。
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id mqtt --test-id mqtt_test
```
オプションの完全な一覧については、「[FreeRTOS 認定スイートの実行](#run-tests)」を参照してください。
IDT v3.0.0 以降、IDT は新しいテストスイートをオンラインでチェックします。詳細については、[テストスイートのバージョン](idt-test-suite-versions.md) を参照してください。
------
#### [ IDT v1.7.0 and earlier ]
**`help`**
指定されたコマンドに関する情報を一覧表示します。
**`list-groups`**
特定のスイート内のグループを一覧表示します。
**`list-suites`**
使用可能なスイートを一覧表示します。
**`run-suite`**
デバイスプールに対してテストスイートを実行します。
------
## 再資格のテスト
IDT for FreeRTOS 認定テストの新しいバージョンがリリースされた場合や、ボード固有のパッケージまたはデバイスドライバーを更新した場合は、IDT for FreeRTOS を使用してマイクロコントローラーボードをテストできます。その後の認定テストでは、最新バージョンの FreeRTOS と IDT for FreeRTOS を使用してテストを再実行してください。
# IDT for FreeRTOS の結果を表示する
実行中、IDT はコンソール、ログファイル、テストレポートにエラーを書き込みます。IDT で適格性テストスイートを実行すると、テスト実行の概要がコンソールに書き込まれ、2 つのレポートが生成されます。これらのレポートは `devicetester-extract-location/results/execution-id/` にあります。両レポートでは、適格性確認テストスイートの実行の結果をキャプチャします。
`awsiotdevicetester_report.xml` は、 AWS Partner Device Catalog にデバイスを一覧表示 AWS するために に送信する認定テストレポートです。レポートには、次の要素が含まれます。
+ IDT for FreeRTOS のバージョン。
+ テスト済みの FreeRTOS のバージョン。
+ 合格したテストに基づいてデバイスでサポートされる FreeRTOS の機能。
+ `device.json` ファイルに記載されている SKU とデバイス名。
+ `device.json` ファイルに記載されているデバイスの機能。
+ テストケース結果の要約を集計したもの。
+ デバイスの機能 (FullWiFi、FullMQTT など) に基づいてテストしたライブラリごとのテストケース結果の内訳。
+ この FreeRTOS の認定が LTS ライブラリを使用するバージョン 202012.00 を対象としているかどうか。
`FRQ_Report.xml` は、標準 [JUnit XML 形式](https://llg.cubic.org/docs/junit/)のレポートです。[Jenkins](https://jenkins.io/)、[Bamboo](https://www.atlassian.com/software/bamboo) など CI/CD プラットフォームに統合することができます。レポートには、次の要素が含まれます。
+ テストケース結果の要約を集計したもの。
+ デバイスの機能に基づいてテストしたライブラリごとのテストケース結果の内訳。
# IDT for FreeRTOS の結果の解釈
`awsiotdevicetester_report.xml` または `FRQ_Report.xml` のレポートセクションには、実行したテストの結果が一覧表示されます。
最初の XML タグ `` は、テストの実行の概要を含みます。例:
``
**`` タグで使用される属性**
**`name`**
テストスイートの名前。
**`time`**
適格性確認スイートの実行所要時間 (秒)。
**`tests`**
実行されたテストケースの数。
**`failures`**
実行されたテストケースのうち、合格しなかったものの数。
**`errors`**
IDT for FreeRTOS が実行できなかったテストケースの数。
**`disabled`**
この属性は使用されていないため無視できます。
テストケースの障害やエラーがない場合、デバイスは FreeRTOS を実行するための技術要件を満たし、 AWS IoT サービスと相互運用できます。 AWS Partner Device Catalog にデバイスを一覧表示することを選択した場合は、このレポートを認定の証拠として使用できます。
テストケースに障害やエラーが発生した場合は、`` XML タグを確認することで、障害の生じたテストケースを特定できます。`` タグ内の `` XML タグは、テストグループのテストケース結果の要約を示します。
``
形式は `` タグと似ていますが、`skipped` という属性があります。この属性は使用されていないため無視できます。`` XML タグの内側には、テストグループに対して実行されたそれぞれのテストケースの `` タグがあります。例:
``
**`` タグで使用される属性**
**`name`**
テスト対象の製品の名前。
**`version`**
テスト対象の製品のバージョン。
**`sdk`**
SDK で IDT を実行した場合、このブロックには SDK の名前とバージョンが含まれます。SDK で IDT を実行しなかった場合、このブロックには以下が含まれます。
```
N/A
N/A
```
**`features`**
検証された機能です。`required` としてマークされている機能については、資格を得るためにボードを提出するために必要です。次のスニペットは、この情報が `awsiotdevicetester_report.xml` ファイルで表示される方法を示します。
```
```
`optional` としてマークされている機能は、資格を得るために必要ありません。次のスニペットは、オプションの機能を示しています。
```
```
必要な機能のテストに障害やエラーがない場合、そのデバイスは FreeRTOS を実行するための技術的要件を満たしており、 AWS IoT サービスとの相互運用が可能です。[AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices) にデバイスを出品する場合は、認定の証拠としてこのレポートを使用できます。
テストに障害やエラーが発生した場合は、`` XML タグを確認することで、障害の生じたテストを特定できます。`` タグ内の `` XML タグは、テストグループのテスト結果の要約を示します。例:
```
```
形式は `` タグと似ていますが、使用されていないため無視できる `skipped` という属性があります。各 `` XML タグ内には、テストグループの実行されたテスト別の `` タグがあります。例:
```
```
**`lts`**
LTS ライブラリを使用する FreeRTOS のバージョンを対象とする場合は true、それ以外の場合は false。
**`` タグで使用される属性**
**`name`**
テストケースの名前。
**`attempts`**
IDT for FreeRTOS がテストケースを実行した回数。
テストに障害やエラーが発生した場合、`` タグまたは `` タグがトラブルシューティングのための情報とともに `` タグに追加されます。例:
```
Reason for the test case failure
Reason for the test case execution error
```
詳細については、「[エラーのトラブルシューティング](dt-afr-troubleshooting.md)」を参照してください。
# IDT for FreeRTOS ログを表示する
テストの実行中に IDT for FreeRTOS によって生成されるログは、`devicetester-extract-location/results/execution-id/logs` にあります。2 組のログが生成されます。
**`test_manager.log`**
IDT for FreeRTOS から生成されるログ (設定とレポート生成に関連するログなど) を含みます。
**`test_group_id__test_case_id.log` (`FullMQTT__Full_MQTT.log` など)**
テスト対象のデバイスからの出力を含む、テストケースのログファイル。ログファイルには、実行されたテストグループとテストケースに従って名前が付けられます。
# 独自の IDT テストスイートを開発および実行する
IDT v4.0.0 以降、IDT for FreeRTOS では、標準化された構成設定および結果形式と、デバイスやデバイスソフトウェア用のカスタムテストスイートを開発できるテストスイート環境が統合されています。独自の内部検証用のカスタムテストを追加したり、デバイス検証のためにこれらのテストを顧客に提供したりできます。
IDT を使用してカスタムテストスイートを開発および実行するには、次の手順を実行します。
****カスタムテストスイートを開発するには****
+ テストするデバイス用のカスタムテストロジックを使用して、テストスイートを作成します。
+ IDT と作成したカスタムテストスイートをテストの実行者に提供します。作成したテストスイートの構成設定に関する情報も提供します。
****カスタムテストスイートを実行するには****
+ テストするデバイスをセットアップします。
+ 使用するテストスイートに必要な構成設定を実装します。
+ IDT を使用して、カスタムテストスイートを実行します。
+ IDT によって実行されたテストのテスト結果と実行ログを表示します。
## AWS IoT Device Tester for FreeRTOS の最新バージョンをダウンロードする
IDT の[最新バージョン](dev-test-versions-afr.md#idt-latest-version-afr)をダウンロードし、ファイルシステム上で読み取りおよび書き込みアクセス許可を持っている場所に抽出します。
**注記**
複数のユーザーが NFS ディレクトリや Windows ネットワーク共有フォルダなどの共有場所から IDT を実行することはお勧めしません。IDT パッケージをローカルドライブに展開し、ローカルワークステーションで IDT バイナリを実行することをお勧めします。
Windows では、パスの長さは 260 文字に制限されています。Windows を使用している場合は、パスが 260 文字以内になるようにして、IDT をルートディレクトリ (`C:\ ` または `D:\` など) に展開します。
## テストスイートワークフロー
テストスイートは 3 つのタイプのファイルで設定されます。
+ IDT にテストスイートの実行方法に関する情報を提供する設定ファイル。
+ IDT がテストケースの実行に使用するテスト実行可能ファイル。
+ テストの実行に必要な追加のファイル。
カスタム IDT テストを作成するには、次の基本的な手順を実行します。
1. テストスイート用の[設定ファイルを作成します](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 FreeRTOS を使用してカスタムテストスイートを実行する方法を理解できます。このチュートリアルでは SSH を使用しますが、 AWS IoT Device Tester FreeRTOS デバイスで を使用する方法を学ぶと便利です。
このチュートリアルでは、次の手順を実行します。
1. [サンプルテストスイートを構築する](build-sample.md)
1. [IDT を使用してサンプルテストスイートを実行する](run-sample.md)
**Topics**
+ [サンプルテストスイートの前提条件を設定する](prereqs-tutorial-sample.md)
+ [IDT 用のデバイス情報を設定する](configure-idt-sample.md)
+ [サンプルテストスイートを構築する](build-sample.md)
+ [IDT を使用してサンプルテストスイートを実行する](run-sample.md)
+ [エラーのトラブルシューティング](tutorial-troubleshooting-custom.md)
# サンプルテストスイートの前提条件を設定する
このチュートリアルを完了するには、以下が必要です。
+
**ホストコンピュータの要件**
+ の最新バージョン AWS IoT Device Tester
+ [Python](https://docs.python.org/3/) 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/3/)を参照してください。
+ [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.com/documentation/computers/remote-access.html) をセットアップし、リモートから接続できることを確認します。
# 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` フォルダ内のファイルを確認して、サンプルテストスイートの構造を理解し、テストケース実行可能ファイルとテスト設定ファイルのさまざまな例を参照してください。
**注記**
サンプルテストスイートには python ソースコードが含まれます。テストスイートのコードには機密情報を入力しないでください。
次のステップ: IDT を使用して、作成した[サンプルテストスイートを実行](run-sample.md)します。
# 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 AWS 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.md)を満たしていることを確認してください。
**テスト対象のデバイスに接続できない**
以下について確認します。
+ `device.json` ファイルに、正しい IP アドレス、ポート、および認証情報が含まれている。
+ ホストコンピュータから SSH 経由でデバイスに接続できる。
# チュートリアル: シンプルな IDT テストスイートの開発
テストスイートは、以下を組み合わせたものです。
+ テストロジックが含まれるテスト実行可能ファイル
+ テストスイートについて記述する設定ファイル
このチュートリアルでは、IDT for FreeRTOS を使用して、単一のテストケースを含む Python テストスイートを開発する方法を説明します。このチュートリアルでは SSH を使用しますが、 AWS IoT Device Tester FreeRTOS デバイスで を使用する方法を学ぶと便利です。
このチュートリアルでは、次の手順を実行します。
1. [テストスイートディレクトリを作成する](test-suite-dir.md)
1. [設定ファイルを作成する](test-suite-json.md)
1. [テストケース実行可能ファイルを作成する](test-suite-exe.md)
1. [テストスイートを実行する](run-test-suite.md)
以下のステップに従って、シンプルな IDT テストスイートを開発するためのチュートリアルを完了します。
**Topics**
+ [シンプルな IDT テストスイートの前提条件を設定する](prereqs-tutorial-custom.md)
+ [テストスイートディレクトリを作成する](test-suite-dir.md)
+ [設定ファイルを作成する](test-suite-json.md)
+ [IDT クライアント SDK を入手する](add-idt-sdk.md)
+ [テストケース実行可能ファイルを作成する](test-suite-exe.md)
+ [IDT 用のデバイス情報を設定する](configure-idt-sample2.md)
+ [テストスイートを実行する](run-test-suite.md)
+ [エラーのトラブルシューティング](tutorial-troubleshooting.md)
+ [IDT テストスイート設定ファイルを作成する](idt-json-config.md)
+ [IDT テストオーケストレーターを設定する](idt-test-orchestrator.md)
+ [IDT ステートマシンを設定する](idt-state-machine.md)
+ [IDT テストケース実行可能ファイルを作成する](test-executables.md)
+ [IDT コンテキストを使用する](idt-context.md)
+ [テストの実行者向けの設定の構成](set-config-custom.md)
+ [カスタムテストスイートのデバッグと実行](run-tests-custom.md)
+ [IDT テストの結果とログを確認する](idt-review-results-logs.md)
+ [IDT 使用状況メトリクスを送信する](idt-usage-metrics.md)
# シンプルな IDT テストスイートの前提条件を設定する
このチュートリアルを完了するには、以下が必要です。
+
**ホストコンピュータの要件**
+ の最新バージョン 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/3/)を参照してください。
+ [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.com/documentation/computers/remote-access.html) をセットアップし、リモートから接続できることを確認します。
# テストスイートディレクトリを作成する
IDT は、テストケースを、各テストスイート内のテストグループに論理的に分離します。各テストケースはテストグループ内に存在する必要があります。このチュートリアルでは、`MyTestSuite_1.0.0` という名前のフォルダを作成し、このフォルダ内に次のディレクトリツリーを作成します。
```
MyTestSuite_1.0.0
└── suite
└── myTestGroup
└── myTestCase
```
# 設定ファイルを作成する
テストスイートには、次の必須の[設定ファイル](idt-json-config.md)が含まれている必要があります。
**必要なファイル**
**`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 AWS 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 が、「[IDT クライアント SDK を入手する](add-idt-sdk.md)」で説明されたとおりの正しいフォルダにある。
+ このチュートリアルのすべての前提条件を満たしている。詳細については、「[シンプルな IDT テストスイートの前提条件を設定する](prereqs-tutorial-custom.md)」を参照してください。
**テスト対象のデバイスに接続できない**
以下について確認します。
+ `device.json` ファイルに、正しい IP アドレス、ポート、および認証情報が含まれている。
+ ホストコンピュータから SSH 経由でデバイスに接続できる。
# IDT テストスイート設定ファイルを作成する
このセクションでは、カスタムテストスイートの作成時、これに含める設定ファイルを作成する際の形式について説明します。
**必要な設定ファイル**
**`suite.json`**
テストスイートに関する情報が含まれています。「[suite.json を設定する](#suite-json)」を参照してください。
**`group.json`**
テストグループに関する情報が含まれています。テストスイート内のテストグループごとに `group.json` ファイルを作成する必要があります。「[group.json を設定する](#group-json)」を参照してください。
**`test.json`**
テストケースに関する情報が含まれています。テストスイート内のテストケースごとに `test.json` ファイルを作成する必要があります。「[test.json を設定する](#test-json)」を参照してください。
**オプションの設定ファイル**
**`test_orchestrator.yaml`、または `state_machine.json`**
IDT がテストスイートを実行するときのテストの実行方法を定義します。「[test\$1orchestrator.yaml を設定する](#test-orchestrator-config)」を参照してください。
IDT v4.5.2 以降では、テストワークフローの定義に `test_orchestrator.yaml` ファイルを使用します。IDT のそれより前のバージョンでは、`state_machine.json`ファイルを開きます。ステートマシンの詳細については、「[IDT ステートマシンを設定する](idt-state-machine.md)」を参照してください。
**`userdata_schema.json`**
テストの実行者が構成設定に含めることができる [`userdata.json` ファイル](set-config-custom.md#userdata-config-custom)のスキーマを定義します。`userdata.json` ファイルは、テストの実行に必要であるものの、`device.json` ファイルに含まれていない、追加の設定情報用に使用します。「[userdata\$1schema.json を設定する](#userdata-schema-json)」を参照してください。
設定ファイルは、以下に示すように `` に配置します。
```
└── suite
├── suite.json
├── test_orchestrator.yaml
├── 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` ファイルの値が優先されます。
## test\$1orchestrator.yaml を設定する
テストオーケストレーターは、テストスイートの実行フローを制御するコンストラクトです。テストスイートの開始ステートを決定し、ユーザー定義のルールに基づいてステートの移行を管理し、終了ステートに達するまでステートの移行を継続します。
テストスイートにユーザー定義のテストオーケストレーターが含まれていない場合は、IDT によってテストオーケストレーターが生成されます。
デフォルトのテストオーケストレーターには以下の機能があります。
+ テストの実行者に、テストスイート全体ではなく、特定のテストグループを選択して実行する機能を提供する。
+ 特定のテストグループが選択されていない場合、テストスイート内のすべてのテストグループをランダムな順序で実行する。
+ レポートを生成し、各テストグループおよびテストケースのテスト結果を示すコンソールサマリーを出力する。
IDT テストオーケストレーターの機能の詳細については、「[IDT テストオーケストレーターを設定する](idt-test-orchestrator.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#draft-4) を作成します。
IDT は、テストスイートを実行するときに、このスキーマを自動的に読み込み、テストの実行者によって提供される `userdata.json` ファイルの検証に使用します。有効な場合、`userdata.json` ファイルのコンテンツは [IDT コンテキスト](idt-context.md)および、[テストオーケストレーターコンテキスト](idt-test-orchestrator.md#idt-test-orchestrator-context)の両方で利用可能になります。
# IDT テストオーケストレーターを設定する
IDT v4.5.2 以降、IDT には新しい*テストオーケストレーター*コンポーネントが追加されています。テストオーケストレーターは、テストスイートの実行フローを制御する IDT コンポーネントで、IDT がすべてのテストを実行した後にテストレポートを生成します。テストオーケストレーターは、ユーザー定義のルールに基づいて、テストの選択とテストの実行順序を決定します。
テストスイートにユーザー定義のテストオーケストレーターが含まれていない場合は、IDT によってテストオーケストレーターが生成されます。
デフォルトのテストオーケストレーターには以下の機能があります。
+ テストの実行者に、テストスイート全体ではなく、特定のテストグループを選択して実行する機能を提供する。
+ 特定のテストグループが選択されていない場合、テストスイート内のすべてのテストグループをランダムな順序で実行する。
+ レポートを生成し、各テストグループおよびテストケースのテスト結果を示すコンソールサマリーを出力する。
IDT ステートマシンは、テストオーケストレーターに置き換えられます。テストスイートの開発には、IDT ステートマシンではなくテストオーケストレーターを使用することを強くお勧めします。テストオーケストレーターでは、以下の機能が改善されています。
+ IDT ステートマシンが命令型を使用するのに対し、宣言型を使用します。これにより、どのテストを実行するか、およびいつそれを実行するかを指定できます。
+ 特定のグループ処理、レポート生成、エラー処理、結果追跡を管理し、これらのアクションを手動管理する必要がないようにします。
+ デフォルトでコメントをサポートする YAML 形式を使用します。
+ 同じワークフローを定義するのに必要なディスク容量が、テストオーケストレーターより 80% 少なくなります。
+ テスト前検証を追加し、誤ったテスト ID や依存関係の循環がワークフロー定義に含まれていないことを検証します。
## テストオーケストレーター形式
次のテンプレートを使用して、独自の `custom-test-suite-folder/suite/test_orchestrator.yaml` ファイルを設定できます。
```
Aliases:
string: context-expression
ConditionalTests:
- Condition: context-expression
Tests:
- test-descriptor
Order:
- - group-descriptor
- group-descriptor
Features:
- Name: feature-name
Value: support-description
Condition: context-expression
Tests:
- test-descriptor
OneOfTests:
- test-descriptor
IsRequired: boolean
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
`Aliases`
オプション。コンテキスト式にマップするユーザー定義の文字列。エイリアスを使用すると、テストオーケストレーター設定でコンテキスト式を識別するためのフレンドリ名を生成できます。これは、複雑なコンテキスト式や、複数の場所で使用する式を作成する場合に特に便利です。
コンテキスト式を使用するとコンテキストクエリを保存でき、これにより他の IDT 設定からデータにアクセスできるようになります。詳細については、「[コンテキスト内のデータにアクセスする](idt-context.md#accessing-context-data)」を参照してください。
**Example**
**例**
```
Aliases:
FizzChosen: "'{{$pool.features[?(@.name == 'Fizz')].value[0]}}' == 'yes'"
BuzzChosen: "'{{$pool.features[?(@.name == 'Buzz')].value[0]}}' == 'yes'"
FizzBuzzChosen: "'{{$aliases.FizzChosen}}' && '{{$aliases.BuzzChosen}}'"
```
`ConditionalTests`
オプション。条件と、条件が満たされたときに実行される、対応するテストケースのリスト。各条件には複数のテストケースを割り当てることができますが、特定のテストケースを割り当てることができる条件は 1 つだけです。
デフォルトでは、IDT はこのリストの条件に割り当てられていないテストケースをすべて実行します。このセクションを指定しない場合、IDT はテストスイートのすべてのテストグループを実行します。
`ConditionalTests` リストの各項目には以下のパラメータが含まれます。
`Condition`
ブール値に評価されるコンテキスト式。評価値が true の場合、IDT は `Tests` パラメータで指定されたテストケースを実行します。
`Tests`
テスト記述子のリスト。
各テスト記述子は、テストグループ ID と 1 つ以上のテストケース ID を使用して、特定のテストグループから実行する個々のテストを識別します。テスト記述子は以下の形式を使用します。
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
**Example**
**例**
次の例は、`Aliases` として定義できる汎用コンテキスト式を使用します。
```
ConditionalTests:
- Condition: "{{$aliases.Condition1}}"
Tests:
- GroupId: A
- GroupId: B
- Condition: "{{$aliases.Condition2}}"
Tests:
- GroupId: D
- Condition: "{{$aliases.Condition1}} || {{$aliases.Condition2}}"
Tests:
- GroupId: C
```
定義された条件に基づき、IDT は次のようにテストグループを選択します。
+ `Condition1` が真の場合、IDT はテストグループ A、B、C のテストを実行します。
+ `Condition2` が真の場合、IDT はテストグループ C と D のテストを実行します。
`Order`
オプション。テストを実行する順序。テストの順序はテストのグループレベルで指定します。このセクションを指定しない場合、IDT はすべての適用可能なテストグループをランダムな順序で実行します。`Order` の値は、グループ記述子リストのリストです。`Order` のリストに記載していないテストグループは、記載されている他のテストグループと並行して実行できます。
各グループ記述子リストには 1 つ以上のグループ記述子が含まれ、各記述子で指定されたグループを実行する順序を特定します。個別のグループ記述子を定義するには、以下の形式を使用できます。
+ `group-id` - 既存のテストグループのグループ ID。
+ `[group-id, group-id]` - 相互に任意の順序で実行できるテストグループのリスト。
+ `"*"` - ワイルドカード これは、現在のグループ記述子リストにまだ指定されていないすべてのテストグループのリストに相当します。
`Order` の値は、次の要件も満たしている必要があります。
+ グループ記述子で指定するテストグループ ID は、テストスイートに存在する必要があります。
+ 各グループ記述子リストには、少なくとも 1 つのテストグループが含まれている必要があります。
+ 各グループ記述子リストには一意のグループ ID を含める必要があります。個々のグループ記述子内でテストグループ ID を繰り返すことはできません。
+ グループ記述子リストは、最大 1 つのワイルドカードグループ記述子を持つことができます。ワイルドカードグループ記述子は、リストの最初または最後の項目でなければなりません。
**Example**
**例**
テストグループ A、B、C、D、E を含むテストスイートについて、次の例のリストに、IDT が最初にテストグループ A を実行し、次にテストグループ B を実行し、次いで C、D、E を任意の順序で実行するよう指定するためのさまざまな方法を示します。
+
```
Order:
- - A
- B
- [C, D, E]
```
+
```
Order:
- - A
- B
- "*"
```
+
```
Order:
- - A
- B
- - B
- C
- - B
- D
- - B
- E
```
`Features`
オプション。IDT に `awsiotdevicetester_report.xml` ファイルに追加させる製品機能のリスト。このセクションを指定しない場合、IDT はレポートに製品機能を追加しません。
製品機能とは、デバイスが満たしている可能性のある特定の基準に関するユーザー定義の情報です。例えば、MQTT 製品機能には、デバイスが MQTT メッセージを適切に公開することを指定できます。`awsiotdevicetester_report.xml` では、製品機能は指定されたテストが合格したかどうかに応じて、`supported`、`not-supported`、またはカスタムのユーザー定義値に設定されます。
`Features` リストの各項目は以下のパラメータで設定されます。
`Name`
機能の名前。
`Value`
オプション。`supported` の代わりにレポートで使用するカスタム値。この値を指定しない場合、テスト結果に基づいて、IDT により機能値が `supported` または `not-supported` に設定されます。同じ機能を異なる条件でテストする場合、`Features` リストにおけるその機能のインスタンスごとにカスタム値を使用できます。IDT は、サポート条件の機能値を連結します。詳細については、以下を参照してください。
`Condition`
ブール値に評価されるコンテキスト式。評価値が true の場合、IDT はテストスイートを実行後、その機能をテストレポートに追加します。評価値が false の場合、テストはレポートに含まれません。
`Tests`
オプション。テスト記述子のリスト。機能をサポートするには、このリストで指定されるテストにすべて合格する必要があります。
このリストの各テスト記述子は、テストグループ ID と 1 つ以上のテストケース ID を使用して、特定のテストグループから実行する個々のテストを識別します。テスト記述子は以下の形式を使用します。
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
`Features` リストの各機能について、`Tests` か `OneOfTests` のどちらかを指定する必要があります。
`OneOfTests`
オプション。テスト記述子のリスト。機能をサポートするには、このリストで指定されているテストのうち少なくとも 1 つに合格する必要があります。
このリストの各テスト記述子は、テストグループ ID と 1 つ以上のテストケース ID を使用して、特定のテストグループから実行する個々のテストを識別します。テスト記述子は以下の形式を使用します。
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
`Features` リストの各機能について、`Tests` か `OneOfTests` のどちらかを指定する必要があります。
`IsRequired`
機能がテストレポートに必要かどうかを定義するブール値。デフォルト値は `false` です。
## テストオーケストレーターコンテキスト
テストオーケストレーターコンテキストは、実行中のテストオーケストレーターに利用可能なデータが含まれている読み取り専用 JSON ドキュメントです。テストオーケストレーターコンテキストは、テストオーケストレーターからのみアクセス可能で、テストフローを決定する情報が含まれています。例えば、テストの実行者によって `userdata.json` ファイルに設定された情報を使用して、特定のテストを実行する必要があるかどうかを決定できます。
テストオーケストレーターコンテキストは次の形式を使用します。
```
{
"pool": {
},
"userData": {
},
"config": {
}
}
```
`pool`
テスト実行用に選択されたデバイスプールに関する情報。選択されたデバイスプールのこの情報は、`device.json` ファイルで定義された、対応する最上位レベルのデバイスプール配列要素から取得されます。
`userData`
`userdata.json` ファイル内の情報。
`config`
`config.json` ファイル内の情報。
コンテキストは、JSONPath 表記法を使用してクエリできます。ステート定義における JSonPath クエリの構文は `{{query}}` です。テストオーケストレーターコンテキストからデータにアクセスする場合、各値が文字列、数値、またはブール値として評価されることを確認してください。
JSONPath 表記を使用してコンテキストのデータにアクセスする方法の詳細については、[IDT コンテキストを使用する](idt-context.md)を参照してください。
# IDT ステートマシンを設定する
**重要**
IDT v4.5.2 以降、このステートマシンは非推奨です。新しいテストオーケストレーターを使用することを強くお勧めします。詳細については、「[IDT テストオーケストレーターを設定する](idt-test-orchestrator.md)」を参照してください。
ステートマシンは、テストスイートの実行フローを制御するコンストラクトです。テストスイートの開始ステートを決定し、ユーザー定義のルールに基づいてステートの移行を管理し、終了ステートに達するまでステートの移行を継続します。
テストスイートにユーザー定義のステートマシンが含まれていない場合は、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
+ IDT Client SDK for Java
これらの 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,
"idtRootPath":
},
"device": {
},
"devicePool": {
},
"resource": {
"devices": [
{
"name": ""
}
]
},
"testData": {
"awsCredentials": {
"awsAccessKeyId": "",
"awsSecretAccessKey": "",
"awsSessionToken": ""
},
"logFilePath": "/path/to/log/file"
},
"userData": {
}
}
```
**`config`**
[`config.json` ファイル](set-config-custom.md#config-json-custom) からの情報。`config` フィールドには、次の追加フィールドも含まれます。
**`config.timeoutMultiplier`**
テストスイートによって使用される任意のタイムアウト値の乗数。この値は、IDT CLI からテストの実行者によって指定されます。デフォルト値は `1` です。
**`config.idRootPath`**
この値は、`userdata.json` ファイルを設定する際の IDT の絶対パス値のプレースホルダーです。この値はビルドコマンドとフラッシュコマンドで使用されます。
**`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 表記を使用して設定ファイルからクエリすることも、`GetContextValue` および `GetContextString` API を使用してテキスト実行可能ファイルからクエリすることもできます。IDT コンテキストにアクセスするための JSONPath 文字列の構文は、次のように異なります。
+ `suite.json` および `test.json` では、`{{query}}` を使用します。つまり、式を開始するためにルート要素 `$.` を使用しません。
+ `statemachine.json` では `{{$.query}}` を使用します。
+ API コマンドでは、コマンドに応じて `query` または `{{$.query}}` を使用します。詳細については、SDK のインラインドキュメントを参照してください。
次の表に、一般的な foobar JSONPath 式の演算子を示します。
| 演算子 | 説明 |
| --- | --- |
| \$1 | ルート要素。IDT の最上位レベルのコンテキスト値はオブジェクトであるため、通常は \$1. を使用してクエリを開始します。 |
| .childName | オブジェクトから、名前 childName を使用して子要素にアクセスします。配列に適用されると、この演算子が各要素に適用された新しい配列が生成されます。この要素名は、大文字と小文字が区別されます。例えば、config オブジェクトの awsRegion 値にアクセスするクエリは \$1.config.awsRegion です。 |
| [start:end] | 配列から要素をフィルターし、start インデックスから end インデックスまでの項目を取得します (ともに境界値を含む)。 |
| [index1, index2, ... , indexN] | 配列から要素をフィルターし、指定されたインデックスのみから項目を取得します。 |
| [?(expr)] | expr 式を使用して配列から要素をフィルターします。この式は、ブール値に評価される必要があります。 |
フィルター式を作成するには、次の構文を使用します。
```
| 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/` フォルダにある設定ファイルテンプレートに基づいて指定します。必要に応じて、テストランナーは 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": "",
"pairedResource": "", //used for no-op protocol
"connectivity": {
"protocol": "ssh | uart | docker | no-op",
// ssh
"ip": "",
"port": ,
"publicKeyPath": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
// pki
"privKeyPath": "/path/to/private/key",
// password
"password": "",
}
},
// uart
"serialPort": "",
// docker
"containerId": "",
"containerUser": "",
}
}
]
}
]
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
**`id`**
デバイスプールと呼ばれるデバイスのコレクションを一意に識別するユーザー定義の英数字の ID。プールに属するデバイスには、同一のハードウェアが必要です。テストスイートを実行する場合、プールのデバイスを使用してワークロードを並列化します。複数のデバイスを使用して異なるテストを実行します。
**`sku`**
テスト対象デバイスを一意に識別する英数字の値。SKU は、認定されたデバイスの追跡に使用されます。
AWS Partner Device Catalog にボードを一覧表示する場合、ここで指定する SKU は、一覧表示プロセスで使用する SKU と一致する必要があります。
**`features`**
オプション。デバイスでサポートされている機能を含む配列。デバイス機能は、テストスイートに設定するユーザー定義の値です。テストの実行者に、`device.json` ファイルに含める機能名および値に関する情報を提供する必要があります。例えば、他のデバイスの MQTT サーバーとして機能するデバイスをテストする場合は、`MQTT_QoS` という名前の機能に対する特定のサポートレベルを検証するようにテストロジックを設定します。テストの実行者は、この機能名を指定し、デバイスによってサポートされる QoS レベルにその機能値を設定します。指定された情報は、`devicePool.features` クエリを使用して [IDT コンテキスト](idt-context.md)から、または `pool.features` クエリを使用して[ステートマシンコンテキスト](idt-state-machine.md#state-machine-context)から取得できます。
**`features.name`**
機能の名前。
**`features.value`**
サポートされている機能値。
**`features.configs`**
機能の構成設定 (必要な場合)。
**`features.config.name`**
構成設定の名前。
**`features.config.value`**
サポートされている設定値。
**`devices`**
テスト対象のプール内のデバイスの配列。少なくとも 1 つのデバイスが必要です。
**`devices.id`**
テスト対象のデバイスのユーザー定義の一意の識別子。
**`devices.pairedResource`**
リソースデバイスに対してユーザーが定義した一意の識別子。この値は、`no-op` 接続プロトコルを使用してデバイスをテストする場合に必要です。
**`connectivity.protocol`**
このデバイスと通信するために使用される通信プロトコル。プール内の各デバイスは、同じプロトコルを使用する必要があります。
現在、サポートされている値は、物理デバイスの場合は `ssh` と `uart`、Docker コンテナの場合は `docker`、IDT ホストマシンと直接接続されていないが、ホストマシンと通信するための物理ミドルウェアとしてリソースデバイスを必要とするデバイスの場合は `no-op` だけです。
no-op デバイスの場合は、`devices.pairedResource` でリソースデバイス ID を設定します。この ID も `resource.json` ファイルで指定する必要があります。ペアリングするデバイスは、テスト対象のデバイスと物理的にペアリングされているデバイスである必要があります。IDT は、ペアリングされたリソースデバイスを識別して接続した後は、`test.json` ファイルに記述されている機能に従って他のリソースデバイスに接続することはありません。
**`connectivity.ip`**
テスト対象のデバイスの IP アドレス。
このプロパティは、`connectivity.protocol` が `ssh` に設定されている場合にのみ適用されます。
**`connectivity.port`**
オプション。SSH 接続に使用するポート番号。
デフォルト値は 22 です。
このプロパティは、`connectivity.protocol` が `ssh` に設定されている場合にのみ適用されます。
**`connectivity.publicKeyPath`**
オプション。テスト対象のデバイスへの接続を認証するために使用される公開キーへのフルパス。`publicKeyPath` を指定すると、IDT がテスト対象のデバイスへの SSH 接続を確立するときに、デバイスの公開キーを検証します。この値が指定されていない場合、IDT は SSH 接続を作成しますが、デバイスのパブリックキーは検証しません。
公開キーへのパスを指定し、安全な方法を使用して、この公開キーをフェッチすることを強くお勧めします。標準のコマンドラインベースの SSH クライアントの場合、パブリックキーは `known_hosts` ファイルで提供されます。別の公開キーファイルを指定する場合、このファイルは `known_hosts` ファイルと同じ形式、つまり (`ip-address key-type public-key`) を使用する必要があります。
**`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.serialPort`**
オプション。デバイスが接続されているシリアルポート。
このプロパティは、`connectivity.protocol` が `uart` に設定されている場合にのみ適用されます。
**`connectivity.containerId`**
テスト対象の Docker コンテナのコンテナ ID または名前。
このプロパティは、`connectivity.protocol` が `docker` に設定されている場合にのみ適用されます。
**`connectivity.containerUser`**
オプション。コンテナ内のユーザー名。デフォルト値は Dockerfile で指定されたユーザーです。
デフォルト値は 22 です。
このプロパティは、`connectivity.protocol` が `docker` に設定されている場合にのみ適用されます。
テストの実行者がテストに対して誤ったデバイス接続を構成しているかどうかを確認するには、ステートマシンコンテキストから `pool.Devices[0].Connectivity.Protocol` を取得し、この値を `Choice` ステート内の予想値と比較します。正しくないプロトコルが使用されている場合は、`LogMessage` ステートを使用してメッセージを出力し、`Fail` ステートに移行します。
または、エラー処理コードを使用して、誤ったデバイスタイプによるテスト失敗をレポートすることもできます。
## (オプション) userdata.json の設定
`userdata.json` ファイルには、`device.json` ファイルには指定されていない、テストスイートに必要とされる追加情報が含まれています。このファイルの形式は、テストスイートに定義されている [`userdata_scheme.json` ファイル](idt-json-config.md#userdata-schema-json)によって異なります。テストを作成するユーザーは、作成したテストスイートを実行するユーザーにこの情報を提供してください。
## (オプション) resource.json の設定
`resource.json` ファイルには、リソースデバイスとして使用されるすべてのデバイスに関する情報が含まれています。リソースデバイスは、テスト対象のデバイスの特定の機能をテストするために必要なデバイスです。例えば、デバイスの Bluetooth 機能をテストするには、リソースデバイスを使用して、デバイスがリソースデバイスに正常に接続できるかどうかをテストできます。リソースデバイスはオプションで、必要な数だけリソースデバイスを要求できます。テストを作成するユーザーは、[test.json ファイル](idt-json-config.md#test-json) を使用して、テストに必要なリソースデバイスの機能を定義します。テストの実行者は、`resource.json` ファイルを使用して、必要な機能を持つリソースデバイスのプールを指定します。作成したテストスイートを実行するユーザーに、以下の情報を提供してください。
テストの実行者は、`/configs/` フォルダにある次のテンプレート `resource.json` ファイルを使用してこの情報を指定できます。
```
[
{
"id": "",
"features": [
{
"name": "",
"version": "",
"jobSlots":
}
],
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh | uart | docker",
// ssh
"ip": "",
"port": ,
"publicKeyPath": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
// pki
"privKeyPath": "/path/to/private/key",
// password
"password": "",
}
},
// uart
"serialPort": "",
// docker
"containerId": "",
"containerUser": "",
}
}
]
}
]
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
**`id`**
デバイスプールと呼ばれるデバイスのコレクションを一意に識別するユーザー定義の英数字の ID。プールに属するデバイスには、同一のハードウェアが必要です。テストスイートを実行する場合、プールのデバイスを使用してワークロードを並列化します。複数のデバイスを使用して異なるテストを実行します。
**`features`**
オプション。デバイスでサポートされている機能を含む配列。このフィールドに必要な情報は、テストスイートの [test.json ファイル](idt-json-config.md#test-json) に定義されています。この情報によって、実行するテストと、テストの実行方法が決まります。テストスイートに機能が必要ない場合は、このフィールドは必須ではありません。
**`features.name`**
機能の名前。
**`features.version`**
機能バージョン。
**`features.jobSlots`**
デバイスを同時に使用できるテストの数を示すための設定。デフォルト値は `1` です。
**`devices`**
テスト対象のプール内のデバイスの配列。少なくとも 1 つのデバイスが必要です。
**`devices.id`**
テスト対象のデバイスのユーザー定義の一意の識別子。
**`connectivity.protocol`**
このデバイスと通信するために使用される通信プロトコル。プール内の各デバイスは、同じプロトコルを使用する必要があります。
現在、サポートされている値は、物理デバイス用の `ssh` および `uart` と、Docker コンテナ用の `docker` のみです。
**`connectivity.ip`**
テスト対象のデバイスの IP アドレス。
このプロパティは、`connectivity.protocol` が `ssh` に設定されている場合にのみ適用されます。
**`connectivity.port`**
オプション。SSH 接続に使用するポート番号。
デフォルト値は 22 です。
このプロパティは、`connectivity.protocol` が `ssh` に設定されている場合にのみ適用されます。
**`connectivity.publicKeyPath`**
オプション。テスト対象のデバイスへの接続を認証するために使用される公開キーへのフルパス。`publicKeyPath` を指定すると、IDT がテスト対象のデバイスへの SSH 接続を確立するときに、デバイスの公開キーを検証します。この値が指定されていない場合、IDT は SSH 接続を作成しますが、デバイスのパブリックキーは検証しません。
公開キーへのパスを指定し、安全な方法を使用して、この公開キーをフェッチすることを強くお勧めします。標準のコマンドラインベースの SSH クライアントの場合、パブリックキーは `known_hosts` ファイルで提供されます。別の公開キーファイルを指定する場合、このファイルは `known_hosts` ファイルと同じ形式、つまり (`ip-address key-type public-key`) を使用する必要があります。
**`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.serialPort`**
オプション。デバイスが接続されているシリアルポート。
このプロパティは、`connectivity.protocol` が `uart` に設定されている場合にのみ適用されます。
**`connectivity.containerId`**
テスト対象の Docker コンテナのコンテナ ID または名前。
このプロパティは、`connectivity.protocol` が `docker` に設定されている場合にのみ適用されます。
**`connectivity.containerUser`**
オプション。コンテナ内のユーザー名。デフォルト値は Dockerfile で指定されたユーザーです。
デフォルト値は 22 です。
このプロパティは、`connectivity.protocol` が `docker` に設定されている場合にのみ適用されます。
## (オプション) config.json の設定
`config.json` ファイルには、IDT 向けの設定情報が含まれています。通常、テストランナーは、IDT、およびオプションで AWS リージョンの AWS ユーザー認証情報を提供する場合を除き、このファイルを変更する必要はありません。必要なアクセス許可を持つ認証情報が提供されている場合、 AWS は使用状況メトリクスを AWS IoT Device Tester 収集して送信します AWS。これはオプトイン機能で、IDT 機能を改善するために使用されます。詳細については、「[IDT 使用状況メトリクスを送信する](idt-usage-metrics.md)」を参照してください。
テストランナーは、次のいずれかの方法で 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`
+ **環境変数**
環境変数は、オペレーティングシステムによって維持され、システムコマンドによって使用される変数です。SSH セッション中に定義された変数は、そのセッションの終了後は使用できません。IDT は、環境変数の `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 の AWS 認証情報を設定するには、テストランナーは `/configs/`フォルダにある `config.json`ファイルの `auth`セクションを編集します。
```
{
"log": {
"location": "logs"
},
"configFiles": {
"root": "configs",
"device": "configs/device.json"
},
"testPath": "tests",
"reportPath": "results",
"awsRegion": "",
"auth": {
"method": "file | environment",
"credentials": {
"profile": ""
}
}
}
]
```
以下に説明するように、値が含まれているすべてのフィールドは必須です。
**注記**
このファイル内のすべてのパスは、** に関連して定義されています。
**`log.location`**
** のログフォルダへのパス。
**`configFiles.root`**
設定ファイルが含まれるフォルダへのパス。
**`configFiles.device`**
`device.json` ファイルへのパス。
**`testPath`**
テストスイートが含まれるフォルダへのパス。
**`reportPath`**
IDT がテストスイートを実行した後にテスト結果が含まれるフォルダへのパス。
**`awsRegion`**
オプション。テストスイートが使用する AWS リージョン。設定されない場合、テストスイートは各テストスイートに指定されているデフォルトのリージョンを使用します。
**`auth.method`**
IDT が AWS 認証情報を取得するために使用するメソッド。サポートされる値は、`file` (認証情報ファイルから認証情報を取得) と `environment` (環境変数を使用して認証情報を取得) です。
**`auth.credentials.profile`**
認証情報ファイルから使用する認証情報プロファイル。このプロパティは、`auth.method` が `file` に設定されている場合にのみ適用されます。
# カスタムテストスイートのデバッグと実行
[必要な設定](set-config-custom.md) を終了すると、IDT はテストスイートを実行することができます。完全なテストスイートの実行時間は、ハードウェアとテストスイートの構成によって異なります。参考までに、Raspberry Pi 3B で完全な FreeRTOS 認定テストスイートを完了するには約 30 分かかります。
テストスイートの作成中に、IDT を使用してテストスイートをデバッグモードで実行すると、テストスイートを実行する前やテストの実行者に提供する前に、コードをチェックすることができます。
## IDT をデバッグモードで実行する
テストスイートは、IDT に依存してデバイスとやり取りし、コンテキストを提供し、結果を受け取るため、IDT と通信しないと、IDE でテストスイートを簡単にデバッグすることはできません。そのために、IDT CLI は IDT をデバッグモードで実行できるようにする `debug-test-suite` コマンドを提供します。`debug-test-suite` で使用可能なオプションを表示するには、次のコマンドを実行します。
```
devicetester_[linux | mac | win_x86-64] debug-test-suite -h
```
IDT をデバッグモードで実行するとき、IDT は実際にテストスイートを起動したり、テストオーケストレーターを実行したりしません。代わりに、IDE と対話して IDE で実行されているテストスイートによるリクエストに応答して、コンソールにログを出力します。IDT はタイムアウトせず、手動で中断されるまで待機してから終了します。デバッグモードでは、IDT はテストオーケストレーターも実行せず、レポートファイルも生成しません。テストスイートをデバッグするには、通常は IDT が設定ファイルから取得する情報を、IDE を使用して提供する必要があります。以下の情報を提供してください。
+ 各テストの環境変数と引数。IDT はこの情報を `test.json` または `suite.json` から読み込みません。
+ リソースデバイスを選択するための引数。IDT はこの情報を `test.json` から読み込みません。
テストスイートをデバッグするには、次の手順を実行します。
1. テストスイートの実行に必要な構成設定ファイルを作成します。例えば、テストスイートが `device.json`、`resource.json`、および `user data.json` を必要とする場合は、必要に応じてこれらすべてを設定してください。
1. 次のコマンドを実行して IDT をデバッグモードにし、テストの実行に必要なデバイスを選択します。
```
devicetester_[linux | mac | win_x86-64] debug-test-suite [options]
```
このコマンドを実行すると、IDT はテストスイートからのリクエストを待機し、それらのリクエストに応答します。IDT は、IDT クライアント SDK がケースを処理するために必要な環境変数も生成します。
1. IDE で、`run` または `debug` 設定を使用して次の手順を実行します。
1. IDT で生成された環境変数の値を設定します。
1. `test.json` ファイルと `suite.json` ファイルに指定したすべての環境変数または引数の値を設定します。
1. 必要に応じてブレークポイントを設定します。
1. IDE でテストスイートを実行します。
テストスイートは、必要に応じて何度でもデバッグして再実行できます。IDT はデバッグモードではタイムアウトしません。
1. デバッグが完了したら、IDT を中断してデバッグモードを終了します。
## テストを実行する IDT CLI コマンド
次のセクションでは、IDT CLI コマンドについて説明します。
------
#### [ IDT v4.0.0 ]
**`help`**
指定されたコマンドに関する情報を一覧表示します。
**`list-groups`**
特定のテストスイート内のグループを一覧表示します。
**`list-suites`**
使用可能なテストスイートを一覧表示します。
**`list-supported-products`**
お使いの IDT バージョン (この場合は FreeRTOS バージョン) のサポート対象製品と、現在の IDT バージョンで利用可能な FreeRTOS 認定テストスイートのバージョンを一覧表示します。
**`list-test-cases`**
指定したテストグループのテストケースを一覧表示します。次のオプションがサポートされています。
+ `group-id`。検索するテストグループ。このオプションは必須で、1 つのグループを指定する必要があります。
**`run-suite`**
デバイスプールに対してテストスイートを実行します。以下に、一般的に使用されるオプションの一部を示します。
+ `suite-id`。実行するテストスイートのバージョン。指定しない場合、IDT は `tests` フォルダにある最新バージョンを使用します。
+ `group-id`。実行するテストグループ (カンマ区切りリストとして)。指定しない場合、IDT はテストスイートのすべてのテストグループを実行します。
+ `test-id`。実行するテストケース (カンマ区切りリストとして)。指定した場合は、`group-id` は 1 つのグループを指定する必要があります。
+ `pool-id`。テストするデバイスプール。`device.json` ファイルに複数のデバイスプールが定義されている場合、テストの実行者は 1 つのプールを指定する必要があります。
+ `timeout-multiplier`。テスト用の `test.json` ファイルに指定されているテスト実行タイムアウトを、ユーザー定義乗数を使用して変更するように IDT を設定します。
+ `stop-on-first-failure`。最初に障害が発生した時点で実行を停止するように IDT を設定します。指定されたテストグループをデバッグするには、このオプションを `group-id` とともに使用する必要があります。
+ `userdata`。テストスイートの実行に必要なユーザーデータ情報を含むファイルを設定します。テストスイートの `suite.json` ファイルで、`userdataRequired` が true に設定されている場合にのみ必要です。
`run-suite` オプションの詳細については、次の `help` オプションを使用してください。
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
**`debug-test-suite`**
デバッグモードでテストスイートを実行します。詳細については、[IDT をデバッグモードで実行する](#idt-debug-mode) を参照してください。
------
# IDT テストの結果とログを確認する
このセクションでは、IDT がコンソールログとテストレポートを生成する形式について説明します。
## コンソールメッセージの形式
AWS IoT Device Tester は、テストスイートの開始時にコンソールにメッセージを印刷するための標準形式を使用します。以下の抜粋は、IDT によって生成されるコンソールメッセージの例を示しています。
```
[INFO] [2000-01-02 03:04:05]: Using suite: MyTestSuite_1.0.0 executionId=9a52f362-1227-11eb-86c9-8c8590419f30
```
コンソールメッセージの大半は、次のフィールドで設定されます。
**`time`**
ログに記録されたイベントの完全な ISO 8601 タイムスタンプ。
**`level`**
ログに記録されたイベントのメッセージレベル。通常、ログに記録されるメッセージレベルは、`info`、`warn`、または `error` のいずれかです。IDT は、早期終了の原因となる予期されるイベントが発生した場合は、`fatal` または `panic` メッセージを発行します。
**`msg`**
ログに記録されたメッセージ。
**`executionId`**
現在の IDT プロセスの一意の ID 文字列。この ID は、個々の IDT 実行を区別するために使用されます。
テストスイートから生成されたコンソールメッセージは、テスト対象のデバイスとテストスイート、テストグループ、IDT が実行するテストケースに関する追加情報を提供します。次の抜粋は、テストスイートから生成されたコンソールメッセージの例を示しています。
```
[INFO] [2000-01-02 03:04:05]: Hello world! suiteId=MyTestSuitegroupId=myTestGroup testCaseId=myTestCase deviceId=my-deviceexecutionId=9a52f362-1227-11eb-86c9-8c8590419f30
```
コンソールメッセージのテストスイート固有の部分には、次のフィールドが含まれています。
**`suiteId`**
現在実行中のテストスイートの名前。
**`groupId`**
現在実行中のテストグループの ID。
**`testCaseId`**
現在実行中のテストケースの ID。
**`deviceId`**
現在のテストケースが使用しているテスト対象デバイスの ID。
テストサマリーには、テストスイート、実行された各グループのテスト結果、生成されたログファイルとレポートファイルの場所に関する情報が含まれています。次の例は、テストサマリーメッセージを示しています。
```
========== Test Summary ==========
Execution Time: 5m00s
Tests Completed: 4
Tests Passed: 3
Tests Failed: 1
Tests Skipped: 0
----------------------------------
Test Groups:
GroupA: PASSED
GroupB: FAILED
----------------------------------
Failed Tests:
Group Name: GroupB
Test Name: TestB1
Reason: Something bad happened
----------------------------------
Path to AWS IoT Device Tester Report: /path/to/awsiotdevicetester_report.xml
Path to Test Execution Logs: /path/to/logs
Path to Aggregated JUnit Report: /path/to/MyTestSuite_Report.xml
```
## AWS IoT Device Tester レポートスキーマ
`awsiotdevicetester_report.xml` は、次の情報が含まれる署名済みレポートです。
+ IDT バージョン。
+ テストスイートのバージョン。
+ レポートの署名に使用されるレポートの署名とキー。
+ `device.json` ファイルで指定されているデバイス SKU とデバイスプール。
+ テストされた製品のバージョンとデバイスの機能。
+ テスト結果の概要の集計。この情報は、`suite-name_report.xml` ファイルに含まれている情報と同じです。
```
idt-version
test-suite-version
signature
keyname
execution-id
start-time
end-time
product-name
product-version
device-sku
device-name
ssh | uart | docker
```
`awsiotdevicetester_report.xml` ファイルには、テスト対象の製品および一連のテストの実行後に検証された製品機能に関する情報を含む `` タグが含まれています。
**`` タグで使用される属性**
**`name`**
テスト対象の製品の名前。
**`version`**
テスト対象の製品のバージョン。
**`features`**
検証された機能です。`required` としてマークされている機能は、テストスイートがデバイスを検証するために必要です。次のスニペットは、この情報が `awsiotdevicetester_report.xml` ファイルで表示される方法を示します。
```
```
`optional` としてマークされている機能は、検証に必須ではありません。次のスニペットは、オプションの機能を示しています。
```
```
## テストスイートのレポートスキーマ
`suite-name_Result.xml` レポートは [JUnit XML 形式](https://llg.cubic.org/docs/junit/)です。[Jenkins](https://jenkins.io/)、[Bamboo](https://www.atlassian.com/software/bamboo) などのように継続的な統合 (CI) と継続的なデプロイ (CD) のプラットフォームに統合することができます。このレポートには、テスト結果の概要の集計が含まれています。
```
reason
reason
reason
```
`awsiotdevicetester_report.xml` と `suite-name_report.xml` 両方のレポートセクションには、実行されたテストとその結果が一覧表示されます。
最初の XML タグ `` には、テストの実行の概要が含まれています。例:
```
```
**`` タグで使用される属性**
**`name`**
テストスイートの名前。
**`time`**
スイートの実行所要時間 (秒)。
**`tests`**
実行されたテストの数。
**`failures`**
実行されたテストのうち、合格しなかったものの数。
**`errors`**
IDT で実行できなかったテストの数。
**`disabled`**
この属性は使用されていないため無視できます。
テストに障害やエラーが発生した場合は、`` XML タグを確認することで、障害の生じたテストを特定できます。`` タグ内の `` XML タグは、テストグループのテスト結果の要約を示します。例:
```
```
形式は `` タグと似ていますが、使用されていないため無視できる `skipped` という属性があります。各 `` XML タグ内には、テストグループの実行されたテスト別の `` タグがあります。例:
```
```
**`` タグで使用される属性**
**`name`**
テストの名前。
**`attempts`**
IDT でテストケースを実行した回数。
テストに障害やエラーが発生した場合、`` タグまたは `` タグがトラブルシューティングのための情報とともに `` タグに追加されます。例えば、次のようになります。
```
Reason for the test failure
Reason for the test execution error
```
# IDT 使用状況メトリクスを送信する
必要なアクセス許可を持つ AWS 認証情報を提供すると、 は使用状況メトリクスを AWS IoT Device Tester 収集して送信します AWS。これはオプトイン機能で、IDT 機能を改善するために使用されます。IDT は次のような情報を収集します。
+ IDT の実行に使用される AWS アカウント ID
+ テストの実行に使用される IDT CLI コマンド
+ 実行されるテストスイート
+ ** フォルダにあるテストスイート
+ デバイスプール内に設定されているデバイスの数
+ テストケース名と実行時間
+ テストに合格したか、失敗したか、エラーが発生したか、スキップされたかなどのテスト結果情報
+ テストされた製品の機能
+ 予期せぬ終了、早期終了などの IDT 終了動作
IDT が送信するすべての情報は、`/results//` フォルダの `metrics.log` ファイルにもログが記録されます。ログファイルを表示すると、テスト実行中に収集された情報を確認できます。このファイルは、使用状況メトリックを収集することを選択した場合にのみ生成されます。
メトリクスの収集を無効にするために、追加のアクションを実行する必要はありません。単に AWS 認証情報を保存せず、 AWS 認証情報を保存している場合は、それらにアクセスするように `config.json` ファイルを設定しないでください。
## にサインアップする 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)」を参照してください。
アクセスを提供するには、ユーザー、グループ、またはロールにアクセス許可を追加します。
+ 以下のユーザーとグループ AWS IAM アイデンティティセンター:
アクセス許可セットを作成します。「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[アクセス許可セットを作成する](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html)」の手順に従ってください。
+ IAM 内で、ID プロバイダーによって管理されているユーザー:
ID フェデレーションのロールを作成します。詳細については *IAM ユーザーガイド* の [サードパーティー ID プロバイダー (フェデレーション) 用のロールを作成する](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) を参照してください。
+ IAM ユーザー:
+ ユーザーが担当できるロールを作成します。手順については *IAM ユーザーガイド* の [IAM ユーザーのロールの作成](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) を参照してください。
+ (お奨めできない方法) ポリシーをユーザーに直接アタッチするか、ユーザーをユーザーグループに追加します。*IAM ユーザーガイド* の [ユーザー (コンソール) へのアクセス許可の追加](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) の指示に従います。
## IDT に AWS 認証情報を提供する
IDT が AWS 認証情報にアクセスしてメトリクスを送信できるようにするには AWS、以下を実行します。
1. IAM ユーザーの AWS 認証情報を環境変数として、または認証情報ファイルに保存します。
1. 環境変数を使用するには、次のコマンドを実行します。
```
AWS_ACCESS_KEY_ID=access-key
AWS_SECRET_ACCESS_KEY=secret-access-key
```
1. 認証情報ファイルを使用するには、`.aws/credentials file:` に次の情報を追加します。
```
[profile-name]
aws_access_key_id=access-key
aws_secret_access_key=secret-access-key
```
1. `config.json` ファイルの `auth` セクションを設定します。詳細については、「[(オプション) config.json の設定](set-config-custom.md#config-json-custom)」を参照してください。
# テストスイートのバージョンを維持する
IDT for FreeRTOS は、テストリソースをテストスイートとテストグループに整理します。
+ テストスイートは、デバイスが FreeRTOS の特定のバージョンで動作することを確認するために使用されるテストグループのセットです。
+ テストグループは、BLE や MQTT メッセージングなど、特定の機能に関連する個々のテストのセットです。
IDT v3.0.0 以降、テストスイートは、1.0.0 から始まる `major`.`minor`.`patch` 形式でバージョン管理されます。IDT をダウンロードすると、パッケージに最新のテストスイートのバージョンが含まれます。
コマンドラインインターフェイスで IDT を起動すると、IDT は新しいテストスイートのバージョンが使用可能かどうかをチェックします。使用可能である場合は、新しいバージョンに更新するよう求められます。現在のテストを更新するか、続行するかを選択できます。
**注記**
IDT では、認定のために 3 つの最新のテストスイートバージョンをサポートしています。詳細については、[のサポートポリシーを理解する AWS IoT Device Tester](idt-support-policy.md) を参照してください。
`upgrade-test-suite` コマンドを使用して、テストスイートをダウンロードできます。または、IDT の起動時にオプションのパラメータ `-upgrade-test-suite flag` を使用できます。常に最新のバージョンをダウンロードするには *flag* を「`y`」にし、既存のバージョンを使用するには「`n`」にします。
また、`list-supported-versions` コマンドを使用して、現在のバージョンの IDT でサポートされている FreeRTOS およびテストスイートのバージョンを一覧表示することもできます。
新しいテストでは、新しい IDT 構成設定が導入される可能性があります。その設定がオプションの場合は、IDT から通知され、テストの実行が続行されます。その設定が必要な場合は、IDT から通知され、実行が停止します。その設定を構成したら、テストの実行を続行できます。
# エラーのトラブルシューティング
各テストスイートの実行には一意の実行 ID があります。この ID を使用して、`results` ディレクトリに `results/execution-id` という名前のフォルダを作成します。テストグループ別のログは `results/execution-id/logs` ディレクトリにあります。IDT for FreeRTOS コンソールの出力を使用して、失敗したテストケースの実行 ID、テストケース ID、およびテストグループ ID を検索し、そのテストケースの `results/execution-id/logs/test_group_id__test_case_id.log` という名前のログファイルを開きます。このファイルの情報には以下が含まれます。
+ すべてのビルドおよびフラッシュコマンド出力。
+ テスト実行出力。
+ 詳細な IDT for FreeRTOS コンソール出力。
トラブルシューティングに次のワークフローをお勧めします。
1. 「*user/role* is not authorized to access this resource (user/role にこのリソースにアクセスする権限がありません)」というエラーが表示された場合、[AWS アカウントの作成と設定](dev-tester-prereqs.md#config-aws-account) で指定したようにアクセス許可を設定していることを確認します。
1. コンソール出力を読み取り、実行 UUID や現在実行中のタスクなどの情報を確認します。
1. 各テストのエラーステートメントについて `FRQ_Report.xml` ファイルを確認します。このディレクトリには、各テストグループの実行ログが含まれています。
1. `/results/execution-id/logs` にあるログファイルを確認します。
1. 以下の問題領域のいずれかを調べてください。
+ `/configs/` フォルダの JSON 設定ファイルなどのデバイス設定。
+ デバイスインターフェイス。ログを確認して、どのインターフェイスが失敗しているかを判断します。
+ デバイスツール。デバイスをビルドおよびフラッシュするためのツールチェーンがインストールされ、正しく設定されていることを確認します。
+ FRQ 1.x.x では、FreeRTOS ソースコードのクローンされたクリーンなバージョンが使用可能であることを確認します。FreeRTOS リリースは FreeRTOS バージョンに従ってタグ付けされます。そのコードの特定のバージョンのクローンを作成するには、次のコマンドを使用します。
```
git clone --branch version-number https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
## デバイス設定のトラブルシューティング
IDT for FreeRTOS を使用するときは、バイナリを実行する前に正しい設定ファイルを所定の場所に配置する必要があります。解析エラーや設定エラーが発生する場合は、まず環境に適した設定テンプレートを見つけて使用してください。これらのテンプレートは、`IDT_ROOT/configs` ディレクトリにあります。
それでも問題が解決されない場合は、次のデバッグプロセスを参照してください。
### どこを見ればよいか
まず、コンソール出力を読み取って、このドキュメントで `execution-id` として参照される実行 UUID などの情報を見つけます。
次に、`/results/execution-id` ディレクトリにある `FRQ_Report.xml` ファイルを確認します。このファイルには、実行されたすべてのテストケースと、各障害のエラースニペットがあります。すべての実行ログを取得するには、各テストケースの `/results/execution-id/logs/test_group_id__test_case_id.log` ファイルを探します。
### IDT エラーコード
IDT for FreeRTOS によって生成されるエラーコードを次の表に示します。
| エラーコード | エラーコード名 | 考えられる根本原因 | トラブルシューティング |
| --- | --- | --- | --- |
| 201 | InvalidInputError | `device.json`、`config.json`、または `userdata.json` のフィールドがないか、正しくない形式です。 | 必須フィールドが欠落していないこと、およびリストされたファイルで必須の形式であることを確認します。詳細については、[マイクロコントローラーボードの最初のテスト](qual-steps.md) を参照してください。 |
| 202 | ValidationError | `device.json`、`config.json`、または `userdata.json` のフィールドに無効な値が含まれています。 | レポートのエラーコードの右側にあるエラーメッセージを確認します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 203 | CopySourceCodeError | 指定されたディレクトリに FreeRTOS ソースコードをコピーできません。 | 以下の項目について確認してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 204 | BuildSourceError | FreeRTOS ソースコードをコンパイルできません。 | 以下の項目について確認してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 205 | FlashOrRunTestError | IDT FreeRTOS が DUT で FreeRTOS をフラッシュまたは実行できません。 | `userdata.json` ファイルの下にある `flashTool` 情報が正しいことを確認します。詳細については、[ビルド、フラッシュ、テスト設定を設定する](cfg-dt-ud.md) を参照してください。 |
| 2.0.6 | StartEchoServerError | IDT FreeRTOS が、Wi-Fi またはセキュアソケットテストでエコーサーバーを起動できません。 | `userdata.json` ファイルの `echoServerConfiguration` で設定されたポートが使用中でないこと、ファイアウォールまたはネットワーク設定によってブロックされていないことを確認します。 |
### 設定ファイルの解析エラーのデバッグ
場合によっては、JSON 設定のタイプミスが解析エラーにつながることがあります。ほとんどの場合、JSON ファイルで括弧やカンマ、引用符を忘れたことが原因です。IDT for FreeRTOS は、JSON 検証を行い、デバッグ情報を出力します。エラーが発生した行、構文エラーの行番号と列番号が出力されます。この情報だけでエラーの修正が可能なはずですが、それでもエラーを特定できない場合は、IDE、テキストエディタ (Atom、Sublime など)、またはオンラインツール (JSONLint など) を使って手動で検証を行います。
### テスト結果の解析エラーのデバッグ
[FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests) からのテストグループ (**FullTransportInterfaceTLS, FullPKCS11\$1Core、FullPKCS11\$1Onboard\$1ECC、FullPKCS11\$1Onboard\$1RSA、FullPKCS11\$1PreProvisioned\$1ECC、FullPKCS11\$1PreProvisioned\$1RSA**、**OTACore** など) を実行している間、IDT for FreeRTOS はシリアル接続を使用してテストデバイスからのテスト結果を解析します。場合によっては、デバイス上の余分なシリアル出力がテスト結果の解析を妨げることがあります。
上記のケースでは、関係のないデバイス出力から派生した文字列など、テストケースの失敗に関する奇妙な理由が出力されます。IDT for FreeRTOS テストケースのログファイル (IDT for FreeRTOS がテスト中に受信したすべてのシリアル出力を含む) には、次の内容が表示される場合があります。
```
TEST(Full_PKCS11_Capabilities, PKCS11_Capabilities)
PASS
```
上記の例では、関連のないデバイス出力により、IDT for FreeRTOS はテスト結果である **PASS** を検出できません。
次の点を確認して、最適なテストを行ってください。
+ デバイスで使用されているロギングマクロがスレッドセーフであることを確認してください。詳細については、「[Implementing the library logging macros](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-library-logging-macros.html)」を参照してください。
+ テスト中は、シリアル接続への出力が最小限になるようにしてください。ロギングマクロが適切にスレッドセーフであっても、テスト結果はテスト中に別々の呼び出しで出力されるため、他のデバイス出力は問題になる可能性があります。
IDT for FreeRTOS のテストケースログでは、次のような中断のないテスト結果出力が表示されることが理想的です。
```
---------STARTING TESTS---------
TEST(Full_OTA_PAL, otaPal_CloseFile_ValidSignature) PASS
TEST(Full_OTA_PAL, otaPal_CloseFile_InvalidSignatureBlockWritten) PASS
-----------------------
2 Tests 0 Failures 0 Ignored
```
### 整合性チェック失敗のデバッグ
FRQ 1.x.x バージョンの FreeRTOS を使用している場合は、以下の整合性チェックが適用されます。
FreeRTOSIntegrity テストグループを実行して失敗した場合は、まず、`freertos` ディレクトリのファイルのいずれかを変更していないか確認します。変更しておらず、問題が解消しない場合は、正しいブランチを使用していることを確認してください。IDT の `list-supported-products` コマンドを実行すると、使用する必要のある `freertos` リポジトリのタグ付きブランチを検索できます。
`freertos` リポジトリの正しいタグ付きブランチのクローンを作成しても問題が解消しない場合は、`submodule update` コマンドも実行したかどうかを確認します。`freertos` リポジトリのクローンワークフローは次のとおりです。
```
git clone --branch version-number https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout —init —recursive
```
整合性チェッカーが検索するファイルのリストは、`freertos` ディレクトリの `checksums.json` ファイルにあります。FreeRTOS の移植でファイルやフォルダの構造が変更されていないか確認するには、`checksums.json` ファイルの「`exhaustive`」と「`minimal`」セクションに記載されているファイルが変更されていないことを確認します。SDK を設定して実行するには、「`minimal`」セクションのファイルが変更されていないことを確認します。
SDK で IDT を実行する場合で、`freertos` ディレクトリ内のファイルを変更した場合、`userdata` ファイルの SDK が正しく設定されていることを確認します。それ以外の場合、整合性チェッカーは `freertos` ディレクトリ内のすべてのファイルを検証します。
### FullWiFi テストグループ失敗のデバッグ
FRQ 1.x.x を使用していて FullWiFi テストグループでエラーが発生し、「`AFQP_WiFiConnectMultipleAP`」テストで失敗する場合、両方のアクセスポイントが IDT を実行するホストコンピュータと同じサブネット内にない可能性があります。両方のアクセスポイントが IDT を実行するホストコンピュータと同じサブネット内にあることを確認してください。
### 「必須パラメータが見つからない」エラーのデバッグ
IDT for FreeRTOS には新機能が追加されているため、設定ファイルに変更が生じる可能性があります。古い設定ファイルを使用すると、設定が破損する可能性があります。このような場合は、`results/execution-id/logs` ディレクトリにある `test_group_id__test_case_id.log` ファイルに、すべての不足しているパラメータが明示的に一覧表示されます。IDT for FreeRTOS では、JSON 設定ファイルのスキーマを検証し、最新のサポートされているバージョンが使用されていることを確認します。
### 「テストを開始できなかった」エラー
テストの開始中の障害を示唆するエラーが生じることがあります。原因はいくつか考えられるため、以下が正しいことを確認してください。
+ 実行コマンドに含めたプール名が実際に存在することを確認します。この名前は、`device.json` ファイルから直接参照されます。
+ プール内のデバイスの設定パラメータが正しいことを確認します。
### 「テスト結果の開始が見つからない」エラーのデバッグ
IDT がテスト対象のデバイスによって出力された結果を解析しようとすると、エラーが発生する場合があります。原因はいくつか考えられるため、以下の事項を確認して修正してください。
+ テスト対象のデバイスがホストマシンに安定して接続していることを確認します。これらのエラーが発生するテストのログファイルで IDT が何を受信しているかを確認できます。
+ FRQ 1.x.x を使用しており、テスト対象のデバイスが低速なネットワークまたはその他のインターフェイスを介して接続されている場合、または FreeRTOS テストグループのログで「---------STARTING TESTS---------」フラグと他の FreeRTOS テストグループの出力が見つからない場合は、userdata 設定で `testStartDelayms` の値を増やしてみてください。詳細については、「[ビルド、フラッシュ、テスト設定を設定する](cfg-dt-ud.md)」を参照してください。
### 「Test failure:expected \$1\$1 results but saw \$1\$1\$1」エラーのデバッグ
テスト中に、テストの失敗を示すエラーが表示される場合があります。テストで一定数の結果が期待されているにもかかわらず、テスト中にその結果を確認できません。一部の FreeRTOS テストが、IDT がデバイスからの出力を確認する前に実行されています。このエラーが表示された場合は、*userdata* 設定の `testStartDelayms` 値を増やしてみてください。詳細については、「[ビルド、フラッシュ、テスト設定を設定する](lts-cfg-dt-ud.md)」を参照してください。
### 「\$1\$1\$1\$1\$1\$1\$1\$1 was unselected due to ConditionalTests constraints」エラーのデバッグ
これは、テストと互換性のないデバイスプールでテストを実行していることを意味します。これは、OTA E2E テストで発生することがあります。例えば、`OTADataplaneMQTT` テストグループを実行する際に、`device.json` 設定ファイルで OTA に **No** を選択したり、`OTADataPlaneProtocol` に **HTTP** を選択したりした場合などです。実行するテストグループは、`device.json` で選択した機能と一致している必要があります。
### デバイス出力のモニタリング中の IDT タイムアウトのデバッグ
IDT は、さまざまな理由でタイムアウトすることがあります。テストのデバイス出力モニタリングフェーズ中にタイムアウトが発生し、その結果を IDT のテストケースログ内で確認できる場合は、結果が IDT によって誤って解析されたことを意味します。その理由の 1 つとして、テスト結果の途中にインターリーブされたログメッセージが入っていることが考えられます。このような場合は、「[FreeRTOS 移植ガイド](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-ota.html)」を参照して、UNITY ログの設定方法の詳細を確認してください。
デバイス出力モニタリング中にタイムアウトになるもう 1 つの理由として、TLS テストケースが 1 回失敗するとデバイスが再起動されることが考えられます。その後、デバイスはフラッシュされたイメージを実行し、これによって無限ループが発生します。これはログで確認できます。これが発生した場合は、テストに失敗した後にデバイスが再起動しないようにしてください。
### 「リソースにアクセスする権限がない」エラー
「*ユーザー/ロール*には、このリソースにアクセスする権限がありません」エラーがターミナル出力または `/results/execution-id/logs` の下の `test_manager.log` ファイルに表示される場合があります。この問題を解決するには、`AWS IoTDeviceTesterForFreeRTOSFullAccess` 管理ポリシーをテストユーザーにアタッチします。詳細については、「[AWS アカウントの作成と設定](dev-tester-prereqs.md#config-aws-account)」を参照してください。
### ネットワークテストエラーのデバッグ
ネットワークベースのテストの場合、IDT は、ホストマシン上の予約されていないポートに結合するエコーサーバーを起動します。WiFi またはセキュアソケットテストでタイムアウトまたは接続不可のためにエラーが発生した場合は、1024 〜 49151 の範囲の設定済みポートへのトラフィックを許可するようにネットワークが設定されていることを確認します。
セキュアソケットテストでは、デフォルトでポート 33333 および 33334 が使用されます。WiFi テストでは、デフォルトでポート 33335 が使用されます。これら 3 つのポートが使用中であるか、ファイアウォールまたはネットワークによってブロックされている場合は、userdata.json でテスト用に異なるポートを使用することを選択できます。詳細については、[ビルド、フラッシュ、テスト設定を設定する](cfg-dt-ud.md) を参照してください。以下のコマンドを使用して、特定のポートが使用中であるかどうかを確認できます。
+ Windows: `netsh advfirewall firewall show rule name=all | grep port`
+ Linux: `sudo netstat -pan | grep port`
+ macOS: `netstat -nat | grep port`
### 同じバージョンのペイロードによる OTA 更新の失敗
OTA が実行された後にデバイス上に同じバージョンが存在するために OTA テストケースが失敗する場合、ビルドシステム (cmake など) が IDT の FreeRTOS ソースコード変更を認識せず、更新されたバイナリを構築していないことが原因である可能性があります。これにより、現在デバイス上にあるバイナリと同じバイナリで OTA が実行され、テストは失敗します。OTA 更新失敗のトラブルシューティングを行うには、まずサポートされている最新バージョンのビルドシステムを使用しているかを確認します。
### `PresignedUrlExpired` テストケースの OTA テスト失敗
このテストの前提条件の 1 つは、OTA の更新時間が 60 秒を超えていることです。そうしないと、テストは失敗します。この問題が発生した場合、次のエラーメッセージがログに検出されます。「テストには 60 秒 (url の有効期限) 未満かかります。お気軽にご連絡ください。」
### デバイスインターフェイスとポートのエラーのデバッグ
このセクションでは、IDT がデバイスとの接続に使用するデバイスインターフェイスについて説明します。
#### サポートされているプラットフォーム
IDT は、Linux、macOS、Windows をサポートしています。これら 3 つのプラットフォームは、アタッチされるシリアルデバイスに対して異なる命名スキームを設けています。
+ Linux: `/dev/tty*`
+ macOS: `/dev/tty.*` または `/dev/cu.*`
+ Windows: COM\$1
デバイスポートを確認するには:
+ Linux/macOS の場合は、ターミナルを開き、`ls /dev/tty*` を実行します。
+ macOS の場合は、ターミナルを開き、`ls /dev/tty.*` または `ls /dev/cu.*` を実行します。
+ Windows の場合は、デバイスマネージャを開き、シリアルデバイスグループを展開します。
どのデバイスがポートに接続されているかを確認するには:
+ Linux の場合、`udev` パッケージがインストールされていることを確認してから、`udevadm info –name=PORT` を実行します。このユーティリティにより、正しいポートを使用していることを確認するのに役立つではデバイスドライバー情報が出力されます。
+ macOS の場合、Launchpad を開いて **System Information** を検索します。
+ Windows の場合は、デバイスマネージャを開き、シリアルデバイスグループを展開します。
#### デバイスインターフェイス
組み込みデバイスはそれぞれに異なり、シリアルポートを 1 つ持つものもあれば、複数持つものもあります。一般的に、マシンへの接続時に次の 2 つのポートがデバイスに割り当てられます。
+ デバイスをフラッシュするためのデータポート。
+ 出力を読み取る読み取りポート。
`device.json` ファイルで適切な読み取りポートを設定する必要があります。そのように設定しない場合は、デバイスからの出力の読み取りが失敗する可能性があります。
複数のポートがある場合、必ず `device.json` ファイルにあるデバイスの読み取りポートを使用してください。たとえば、Espressif WRover デバイスを接続し、デバイスに `/dev/ttyUSB0` と `/dev/ttyUSB1` の 2 つのポートが割り当てられている場合、`device.json` ファイルでは `/dev/ttyUSB1` を使用します。
Windows の場合は、同じロジックに従います。
#### デバイスデータの読み取り
IDT for FreeRTOS は、個々のデバイスのビルドおよびフラッシュツールを使用してポート設定を指定します。デバイスをテストしていて、出力が取得できない場合は、次のようなデフォルト設定を試してみてください。
+ ボーレート: 115200
+ データビット: 8
+ パリティ: なし
+ ストップビット: 1
+ フロー制御: なし
これらの設定は、IDT for FreeRTOS によって処理されます。それらを設定する必要はありません。ただし、同じ方法を使用して手動でデバイス出力を読み取ることができます。Linux または macOS では、`screen` コマンドを使用して行います。Windows では、TeraTerm などのプログラムを使用します。
`Screen: screen /dev/cu.usbserial 115200`
`TeraTerm: Use the above-provided settings to set the fields explicitly in the GUI.`
### 開発ツールチェーンの問題
このセクションでは、ツールチェーンで生じる可能性のある問題を取り上げます。
#### Ubuntu での Code Composer Studio
それより新しいバージョンの Ubuntu (17.10 と 18.04) だと、`glibc` パッケージのバージョンに Code Composer Studio 7.*x* バージョンとの互換性がありません。Code Composer Studio version 8.2 以降をインストールすることをお勧めします。
互換性がない場合、次のような症状が現れます。
+ FreeRTOS がビルドやデバイスへのフラッシュに失敗する。
+ Code Composer Studio インストーラがフリーズする。
+ ビルドまたはフラッシュ中に、コンソールにログ出力が表示されない。
+ ヘッドレスとして呼び出したビルドコマンドが GUI モードで起動しようとする。
### ログ記録
IDT for FreeRTOS のログは 1 箇所に配置されます。ルート IDT ディレクトリから、`results/execution-id/` の以下のファイルにアクセスできます。
+ `FRQ_Report.xml`
+ `awsiotdevicetester_report.xml`
+ `logs/test_group_id__test_case_id.log`
`FRQ_Report.xml` と `logs/test_group_id__test_case_id.log` は、調査すべき最も重要なログです。`FRQ_Report.xml` には、特定のエラーメッセージで失敗したテストケースに関する情報が含まれています。次に、`logs/test_group_id__test_case_id.log` を使用して問題の詳細を確認し、状況を把握します。
#### コンソールエラー
AWS IoT Device Tester を実行すると、障害は短いメッセージとともにコンソールに報告されます。`results/execution-id/logs/test_group_id__test_case_id.log` でエラーの詳細を確認します。
#### ログエラー
各テストスイートの実行には一意の実行 ID があり、これを使用して `results/execution-id` という名前のフォルダを作成します。テストケース別のログは `results/execution-id/logs` ディレクトリにあります。IDT for FreeRTOS コンソールの出力を使用して、失敗したテストケースの実行 ID、テストケース ID、およびテストグループ ID を検索します。次に、この情報を使用して、 という名前のテストケースのログファイルを検索して開きます`results/execution-id/logs/test_group_id__test_case_id.log`。このファイルの情報には、完全なビルドおよびフラッシュコマンド出力、テスト実行出力、およびより詳細な AWS IoT Device Tester コンソール出力が含まれます。
#### S3 バケットの問題
IDT の実行中に CTRL\$1C を押すと、クリーンアッププロセスが開始されます。このクリーンアップには、IDT テストの一部として作成された Amazon S3 リソースの削除が含まれます。クリーンアップを完了できない場合、Amazon S3 バケットが過剰に作成される問題が発生することがあります。つまり、次回 IDT を実行したときにテストが失敗し始めます。
IDT を停止するために CTRL\$1C を押す場合、この問題を回避するためにクリーンアッププロセスを完了させる必要があります。アカウントから手動で作成された Amazon S3 バケットを削除することもできます。
## タイムアウトエラーのトラブルシューティング
テストスイートの実行中にタイムアウトエラーが発生した場合は、タイムアウト乗数を指定してタイムアウトを増やします。この乗数は、デフォルトのタイムアウト値に適用されます。このフラグに設定された値はすべて、1.0 以上である必要があります。タイムアウトの乗数を使用するには、テストスイートの実行時に `--timeout-multiplier` フラグを使用します。
**Example**
```
./devicetester_linux run-suite --suite-id FRQ_1.0.1 --pool-id DevicePool1 --timeout-multiplier 2.5
```
```
./devicetester_linux run-suite --suite-id FRQ_1 --pool-id DevicePool1 --timeout-multiplier 2.5
```
## セルラー機能と AWS 料金
`device.JSON` ファイル`Yes`で`Cellular`この機能を に設定すると、FullSecureSockets はテストの実行に t.micro EC2 インスタンスを使用するため、 AWS アカウントに追加料金が発生する可能性があります。詳細については「[Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/)」を参照してください。
## 認定レポート生成ポリシー
資格レポートは、過去 2 年間にリリースされた FreeRTOS バージョンをサポートする AWS IoT Device Tester (IDT) バージョンによってのみ生成されます。サポートポリシーについてご質問がある場合は、 [AWS サポート](https://aws.amazon.com/contact-us/) までお問い合わせください。
# の AWS 管理ポリシーを理解する AWS IoT Device Tester
AWS 管理ポリシーは、 によって作成および管理されるスタンドアロンポリシーです AWS。 AWS 管理ポリシーは、ユーザー、グループ、ロールにアクセス許可の割り当てを開始できるように、多くの一般的なユースケースにアクセス許可を付与するように設計されています。
AWS 管理ポリシーは、すべての AWS お客様が使用できるため、特定のユースケースに対して最小特権のアクセス許可を付与しない場合があることに注意してください。ユースケースに固有の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義して、アクセス許可を絞り込むことをお勧めします。
AWS 管理ポリシーで定義されているアクセス許可は変更できません。が AWS マネージドポリシーで定義されたアクセス許可 AWS を更新すると、ポリシーがアタッチされているすべてのプリンシパル ID (ユーザー、グループ、ロール) に影響します。 AWS は、新しい が起動されるか、新しい API オペレーション AWS のサービス が既存のサービスで使用できるようになったときに、 AWS マネージドポリシーを更新する可能性が高くなります。
詳細については、「**IAM ユーザーガイド」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
**Topics**
+ [AWS マネージドポリシー: AWS IoTDeviceTesterForFreeRTOSFullAccess](#aws-managed-policies-AWSIoTDT)
+ [AWS 管理ポリシーの更新](#aws-managed-policy-updates)
## AWS マネージドポリシー: AWS IoTDeviceTesterForFreeRTOSFullAccess
`AWSIoTDeviceTesterForFreeRTOSFullAccess` 管理ポリシーには、バージョンチェック、自動更新機能、メトリクスの収集に関する以下の AWS IoT Device Tester アクセス許可が含まれています。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `iot-device-tester:SupportedVersion`
サポートされている製品、テストスイート、IDT バージョンのリストを取得する AWS IoT Device Tester アクセス許可を付与します。
+ `iot-device-tester:LatestIdt`
ダウンロード可能な最新の IDT バージョンを取得する AWS IoT Device Tester アクセス許可を付与します。
+ `iot-device-tester:CheckVersion`
IDT、テストスイート、製品のバージョンの互換性をチェックする AWS IoT Device Tester アクセス許可を付与します。
+ `iot-device-tester:DownloadTestSuite`
テストスイートの更新をダウンロードする AWS IoT Device Tester アクセス許可を付与します。
+ `iot-device-tester:SendMetrics`
AWS IoT Device Tester 内部使用状況に関するメトリクスを収集する AWS アクセス許可を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/idt-*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "iot.amazonaws.com"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"iot:DeleteThing",
"iot:AttachThingPrincipal",
"iot:DeleteCertificate",
"iot:GetRegistrationCode",
"iot:CreatePolicy",
"iot:UpdateCACertificate",
"s3:ListBucket",
"iot:DescribeEndpoint",
"iot:CreateOTAUpdate",
"iot:CreateStream",
"signer:ListSigningJobs",
"acm:ListCertificates",
"iot:CreateKeysAndCertificate",
"iot:UpdateCertificate",
"iot:CreateCertificateFromCsr",
"iot:DetachThingPrincipal",
"iot:RegisterCACertificate",
"iot:CreateThing",
"iam:ListRoles",
"iot:RegisterCertificate",
"iot:DeleteCACertificate",
"signer:PutSigningProfile",
"s3:ListAllMyBuckets",
"signer:ListSigningPlatforms",
"iot-device-tester:SendMetrics",
"iot-device-tester:SupportedVersion",
"iot-device-tester:LatestIdt",
"iot-device-tester:CheckVersion",
"iot-device-tester:DownloadTestSuite"
],
"Resource": "*"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"iam:GetRole",
"signer:StartSigningJob",
"acm:GetCertificate",
"signer:DescribeSigningJob",
"s3:CreateBucket",
"execute-api:Invoke",
"s3:DeleteBucket",
"s3:PutBucketVersioning",
"signer:CancelSigningProfile"
],
"Resource": [
"arn:aws:execute-api:us-east-1:098862408343:9xpmnvs5h4/prod/POST/metrics",
"arn:aws:signer:*:*:/signing-profiles/*",
"arn:aws:signer:*:*:/signing-jobs/*",
"arn:aws:iam::*:role/idt-*",
"arn:aws:acm:*:*:certificate/*",
"arn:aws:s3:::idt-*",
"arn:aws:s3:::afr-ota*"
]
},
{
"Sid": "VisualEditor3",
"Effect": "Allow",
"Action": [
"iot:DeleteStream",
"iot:DeleteCertificate",
"iot:AttachPolicy",
"iot:DetachPolicy",
"iot:DeletePolicy",
"s3:ListBucketVersions",
"iot:UpdateCertificate",
"iot:GetOTAUpdate",
"iot:DeleteOTAUpdate",
"iot:DescribeJobExecution"
],
"Resource": [
"arn:aws:s3:::afr-ota*",
"arn:aws:iot:*:*:thinggroup/idt*",
"arn:aws:iam::*:role/idt-*"
]
},
{
"Sid": "VisualEditor4",
"Effect": "Allow",
"Action": [
"iot:DeleteCertificate",
"iot:AttachPolicy",
"iot:DetachPolicy",
"s3:DeleteObjectVersion",
"iot:DeleteOTAUpdate",
"s3:PutObject",
"s3:GetObject",
"iot:DeleteStream",
"iot:DeletePolicy",
"s3:DeleteObject",
"iot:UpdateCertificate",
"iot:GetOTAUpdate",
"s3:GetObjectVersion",
"iot:DescribeJobExecution"
],
"Resource": [
"arn:aws:s3:::afr-ota*/*",
"arn:aws:s3:::idt-*/*",
"arn:aws:iot:*:*:policy/idt*",
"arn:aws:iam::*:role/idt-*",
"arn:aws:iot:*:*:otaupdate/idt*",
"arn:aws:iot:*:*:thing/idt*",
"arn:aws:iot:*:*:cert/*",
"arn:aws:iot:*:*:job/*",
"arn:aws:iot:*:*:stream/*"
]
},
{
"Sid": "VisualEditor5",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::afr-ota*/*",
"arn:aws:s3:::idt-*/*"
]
},
{
"Sid": "VisualEditor6",
"Effect": "Allow",
"Action": [
"iot:CancelJobExecution"
],
"Resource": [
"arn:aws:iot:*:*:job/*",
"arn:aws:iot:*:*:thing/idt*"
]
},
{
"Sid": "VisualEditor7",
"Effect": "Allow",
"Action": [
"ec2:TerminateInstances"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor8",
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:DeleteSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor9",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor10",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:image/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:placement-group/*",
"arn:aws:ec2:*:*:snapshot/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:subnet/*"
]
},
{
"Sid": "VisualEditor11",
"Effect": "Allow",
"Action": [
"ec2:CreateSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor12",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeSecurityGroups",
"ssm:DescribeParameters",
"ssm:GetParameters"
],
"Resource": "*"
},
{
"Sid": "VisualEditor13",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"Owner"
]
},
"StringEquals": {
"ec2:CreateAction": [
"RunInstances",
"CreateSecurityGroup"
]
}
}
}
]
}
```
------
## AWS 管理ポリシーの更新
このサービスがこれらの変更の追跡を開始した時点 AWS IoT Device Tester からの の AWS マネージドポリシーの更新に関する詳細を表示できます。
| バージョン | 変更 | 説明 | 日付 |
| --- | --- | --- | --- |
| 7 (最新) | `ec2:CreateTags` 条件を再構築しました。 | `ForAnyValues` の使用法を削除しました。 | 6/14/2023 |
| 6 | ポリシーから `freertos:ListHardwarePlatforms` が削除されました。 | このアクションは 2023 年 3 月 1 日に廃止されたため、権限を削除します。 | 6/2/2023 |
| 5 | EC2 を使用してエコーサーバーテストを実行する権限を追加しました。 | これは、顧客の AWS アカウントで EC2 インスタンスを起動および停止するためのものです。 | 12/15/2020 |
| 4 | `iot:CancelJobExecution` が追加されました。 | この権限は OTA ジョブをキャンセルします。 | 7/17/2020 |
| 3 | 以下の権限を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/security-iam-aws-managed-policies.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/security-iam-aws-managed-policies.html) | 3/23/2020 |
| 2 | `iot-device-tester:SendMetrics` 権限を追加しました。 | AWS IoT Device Tester 内部使用状況に関するメトリクスを収集する AWS アクセス許可を付与します。 | 2/18/2020 |
| 1 | 当初のバージョン | | 2/12/2020 |
# のサポートポリシーを理解する AWS IoT Device Tester
**重要**
2022 年 10 月現在、 AWS IoT Device Tester for AWS IoT FreeRTOS Qualification (FRQ) 1.0 は署名付き認定レポートを生成しません。IDT FRQ 1.0 バージョンを使用してデバイス[AWS 認定プログラム](https://aws.amazon.com/partners/programs/dqp/)を通じて、新しい AWS IoT FreeRTOS デバイスを [AWS Partner Device Catalog ](https://partners.amazonaws.com/qualified-devices)に一覧表示することはできません。IDT FRQ 1.0 を使用して FreeRTOS デバイスを認定することはできませんが、引き続き FRQ 1.0 を使用して FreeRTOS デバイスをテストすることはできます。FreeRTOS デバイスを認定し、[AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices) にリストする際には、[IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) を使用することが推奨されます。
AWS IoT Device Tester for FreeRTOS は、デバイスへの FreeRTOS ポートを検証するためのテスト自動化ツールです。さらに、FreeRTOS デバイスを[認定](https://aws.amazon.com/partners/programs/dqp/)し、[AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices) にリストすることもできます。 AWS IoT Device Tester for FreeRTOS は、GitHub の FreeRTOS[/FreeRTOS-LTS で利用可能な FreeRTOS 長期サポート (LTS) ](https://github.com/FreeRTOS/FreeRTOS-LTS)ライブラリの検証と認定、および FreeRTOS[/FreeRTOS で利用可能な FreeRTOS](https://github.com/FreeRTOS/FreeRTOS) メインラインをサポートしています。FreeRTOS と AWS IoT Device Tester for FreeRTOS の両方の最新バージョンを使用して、デバイスを検証および認定することをお勧めします。
FreeRTOS-LTS については、IDT は FreeRTOS 202210 LTS バージョンの検証と認定をサポートしています。[FreeRTOS LTS のリリース](https://www.freertos.org/lts-libraries.html)とメンテナンスのタイムラインの詳細については、こちらを参照してください。これらの LTS リリースのサポート期間が終了しても検証を継続することはできますが、IDT はデバイスの認定を依頼するために必要なレポートを生成しません。
[FreeRTOS/FreeRTOS](https://github.com/FreeRTOS/FreeRTOS) で入手可能なメインラインの FreeRTOS については、過去 6 か月にリリースされたすべてのバージョン、またはリリースの間隔が 6 か月以上空いている場合は過去 2 つのバージョンの FreeRTOS の検証と認定をサポートしています。[現在サポートされているバージョン]( https://docs.aws.amazon.com//freertos/latest/userguide/dev-test-versions-afr.html)については、こちらを参照してください。サポート対象外のバージョンの FreeRTOS の場合、検証を継続することはできますが、IDT はデバイスの認定を依頼するために必要なレポートを生成しません。
サポートされている IDT および FreeRTOS のバージョンの最新情報については、「[AWS IoT Device Tester のサポートされているバージョン:](dev-test-versions-afr.md)」を参照してください。FreeRTOS の対応するバージョン AWS IoT Device Tester でサポートされている のバージョンのいずれかを使用して、デバイスをテストまたは認定できます。引き続き [IDT for FreeRTOS のサポートされていないバージョン](idt-unsupported-versions-afr.md) を使用する場合は、これらのバージョンのバグ修正や更新プログラムは受け取れません。
サポートポリシーについてご質問がある場合は、[AWS カスタマーサポート](https://aws.amazon.com/contact-us/)までお問い合わせください。