翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Device Advisor
[Device Advisor](https://aws.amazon.com/iot-core/features/) は、デバイスソフトウェア開発中に IoT デバイスを検証するための、クラウドベースのフルマネージドテスト機能です。Device Advisor は、デバイスを本番環境にデプロイする前に AWS IoT Core、IoT デバイスとの信頼性と安全性を検証するために使用できる事前構築されたテストを提供します。Device Advisor の事前構築されたテストにより、デバイスソフトウェアを[TLS](https://docs.aws.amazon.com//iot/latest/developerguide/protocols.html),[MQTT](https://docs.aws.amazon.com//iot/latest/developerguide/protocols.html),[デバイスシャドウ](https://docs.aws.amazon.com//iot/latest/developerguide/iot-device-shadows.html), および[IoT ジョブズ](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html)の使用のベストプラクティスに照らして検証できます。また、署名された認定レポートをダウンロードして AWS パートナーネットワークに提出し、デバイスを送付してテストを待つことなく、[AWS Partner Device Catalog](https://devices.amazonaws.com/) の認定を受けることもできます。
**注記**
Device Advisor は、us-east-1、us-west-2、ap-northeast-1、および eu-west-1 リージョンでサポートされています。
Device Advisor は、MQTT および MQTT over WebSocket Secure (WSS) プロトコルを使用してメッセージを発行およびサブスクライブするデバイスとクライアントをサポートします。すべてのプロトコルでは、IPv4 および IPv6 がサポートされています。
デバイスアドバイザーは RSA サーバー証明書をサポートしています。
に接続するために構築されたデバイスは、Device Advisor を活用 AWS IoT Core できます。Device Advisor には、[AWS IoT コンソール](https://us-east-1.console.aws.amazon.com/iot/home?region=us-east-1#/deviceadvisor/intro)から、または AWS CLI または SDK を使用してアクセスできます。デバイスをテストする準備ができたら、 に登録 AWS IoT Core し、Device Advisor エンドポイントでデバイスソフトウェアを設定します。その後、事前に構築されたテストを選択して設定し、デバイスでテストを実行して、詳細なログまたは認定レポートとともにテスト結果を取得します。
Device Advisor はクラウド内のテストエンドポイントです AWS 。Device Advisor が提供するテストエンドポイントに接続するようにデバイスを設定することで、デバイスをテストできます。デバイスがテストエンドポイントに接続するように設定されたら、Device Advisor のコンソールにアクセスするか、 AWS SDK を使用してデバイスで実行するテストを選択できます。その後、Device Advisor は、リソースのプロビジョニング、テストプロセスのスケジューリング、ステートマシンの管理、デバイスの動作の記録、結果の記録、テストレポートの形式での最終結果の提供など、テストのライフサイクル全体を管理します。
**TLS プロトコル**
Transport Layer Security (TLS) プロトコルは、インターネットなどの安全性が低いネットワークでの機密データの暗号化に使用されます。TLS プロトコルは、Secure Sockets Layer (SSL) プロトコルの後継です。
Device Advisor は以下の TLS プロトコルをサポートしています。
+ TLS1.3 (推奨)
+ TLS 1.2
**プロトコル、ポートマッピング、認証**
デバイス通信プロトコルは、デバイスまたはクライアントがデバイスエンドポイントを使用してメッセージブローカーに接続するために使用されます。次の表は、Device Advisor エンドポイントがサポートするプロトコルと、それらが使用する認証方法とポートを示しています。
**プロトコル、認証、ポートマッピング**
| プロトコル | サポートされているオペレーション | 認証 | ポート | ALPN プロトコル名 |
| --- | --- | --- | --- | --- |
| MQTT over WebSocket | 発行、サブスクライブ | 署名バージョン 4 | 443 | 該当なし |
| MQTT | 発行、サブスクライブ | X.509 クライアント証明書 | 8883 | `x-amzn-mqtt-ca` |
| MQTT | 発行、サブスクライブ | X.509 クライアント証明書 | 443 | 該当なし |
**Topics**
+ [設定](device-advisor-setting-up.md)
+ [コンソールでの Device Advisor の開始方法](da-console-guide.md)
+ [Device Advisor ワークフロー](device-advisor-workflow.md)
+ [Device Advisor の詳細コンソールワークフロー](device-advisor-console-tutorial.md)
+ [長期テストコンソールのワークフロー](device-advisor-long-duration-console-tutorial.md)
+ [デバイスアドバイザー VPC エンドポイント (AWS PrivateLink)](device-advisor-vpc-endpoint.md)
+ [Device Advisor テストケース](device-advisor-tests.md)
# 設定
Device Advisor を初めて使用する場合は、事前に以下のタスクをすべて実行してください。
## IoT モノの作成
まず、IoT モノを作成し、モノに証明書をアタッチします。モノの作成方法のチュートリアルについては、「[モノのオブジェクトを作成する](https://docs.aws.amazon.com/iot/latest/developerguide/create-iot-resources.html#create-aws-thing)」を参照してください。
## デバイスロールとして使用する IAM ロールを作成する
**注記**
Device Advisor コンソールを使用して、デバイスロールをすばやく作成できます。Device Advisor コンソールを使用してデバイスロールを設定する手順については、「[コンソールでの Device Advisor の開始方法](https://docs.aws.amazon.com/iot/latest/developerguide/da-console-guide.html)」を参照してください。
1. [AWS Identity and Access Management コンソール](https://console.aws.amazon.com/iam/home?region=us-west-2#/home)に移動し、Device Advisor テスト AWS アカウント に使用する にログインします。
1. 左側のナビゲーションペインで、**[Policies]** (ポリシー) を選択します。
1. [**Create policy**] (ポリシーの作成) を選択します。
1. **[Create policy]** (ポリシーの作成) で、次の操作を実行します。
1. **[Service]** (サービス) で、**[IoT]** を選択します。
1. **[アクション]** で、次のいずれかを実行します。
+ (推奨) IoT Thing に添付されているポリシーまたは前のセクションで作成した証明書に基づいてアクションを選択します。
+ **[フィルターアクション]** ボックスで次のアクションを検索して選択します。
+ `Connect`
+ `Publish`
+ `Subscribe`
+ `Receive`
+ `RetainPublish`
1. **[リソース]** で、クライアント、トピック、およびトピックのリソースを制限します。これらのリソースを制限することは、セキュリティのベストプラクティスです。リソースを制限するには、次の手順を実行します。
1. Connect アクションの [**Specify client resource ARN**] (クライアントリソース ARN を指定) を選択します。
1. **[ARN の追加]** を選択し、次のいずれかを実行します。
**注記**
*clientId* は、デバイスが Device Advisor とやり取りするために使用する MQTT クライアント ID です。
+ ビジュアル ARN エディタで、**[リージョン]**、**[accountID]**、および **[clientID]** を指定します。
+ テストケースを実行する IoT トピックの Amazon リソースネーム (ARN) を手動で入力します。
1. **[追加]** を選択します。
1. **[受信およびさらに 1 つのアクションのためにトピックリソース ARN を指定]** を選択します。
1. **[ARN の追加]** を選択し、次のいずれかを実行します。
**注記**
*トピック名*は、デバイスがメッセージを発行する MQTT トピックです。
+ ビジュアル ARN エディタで、**[リージョン]**、**[accountID]**、および **[トピック名]** を指定します。
+ テストケースを実行する IoT トピックの ARN を手動で入力します。
1. [**Add**] (追加) をクリックします。
1. **[サブスクライブアクションのトピックフィルターリソース ARN を指定]** を選択します。
1. **[ARN の追加]** を選択し、次のいずれかを実行します。
**注記**
*トピック名*は、デバイスがサブスクライブする MQTT トピックです。
+ ビジュアル ARN エディタで、**[リージョン]**、**[accountID]**、および **[トピック名]** を指定します。
+ テストケースを実行する IoT トピックの ARN を手動で入力します。
1. **[Add]** (追加) を選択します。
1. [**Next: Tags (次へ: タグ)**] を選択します。
1. **[次へ: レビュー]** を選択します。
1. **[ポリシーの確認]** でポリシーの **[名前]** を入力します。
1. [**Create policy**] (ポリシーの作成) を選択します。
1. 左のナビゲーションペインで、[**Roles**] (ロール) を選択します。
1. [**ロールの作成**] を選択します。
1. **[信頼されたエンティティの選択]** で、**[カスタム信頼ポリシー]** を選択します。
1. 次の信頼ポリシーを **[カスタム信頼ポリシー]** ボックスに入力します。混乱した代理問題から保護するために、グローバル条件コンテキストキー `[aws:SourceArn](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` と `[aws:SourceAccount](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` をポリシーに追加します。
**重要**
`aws:SourceArn` は、`format: arn:aws:iotdeviceadvisor:region:account-id:*.` と一致する必要があります。`region` がお客様の AWS IoT リージョンと一致し、`account-id` がお客様のカスタマーアカウント ID と一致することを確認してください。詳細については、[クロスサービスでの混乱した代理処理を防止する](https://docs.aws.amazon.com/iot/latest/developerguide/security-best-practices.html#cross-service-confused-deputy-prevention-DA)を参照してください。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAwsIoTCoreDeviceAdvisor",
"Effect": "Allow",
"Principal": {
"Service": "iotdeviceadvisor.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:iotdeviceadvisor:*:123456789012:suitedefinition/*"
}
}
}
]
}
```
1. [**次へ**] を選択します。
1. ステップ 4 で作成したポリシーを選択します。
1. (オプション) **[アクセス許可の境界の設定]** で、**[アクセス許可の境界を使用してロールのアクセス許可の上限を設定する]** を選択し、作成したポリシーを選択します。
1. [**次へ**] を選択します。
1. [**Role name**] (ロール名) と [**Role description**] (ロールの説明) を入力します。
1. [**ロールの作成**] を選択します。
## IAM ユーザーが Device Advisor を使用するためのカスタムマネージドポリシーを作成する
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) に移動します。プロンプトが表示されたら、 AWS 認証情報を入力してサインインします。
1. 左のナビゲーションペインの [**Policies (ポリシー)**] を選択します。
1. [**Create Policy**] (ポリシーの作成) を選択し、[**JSON**] タブを選択します。
1. Device Advisor を使用するために必要なアクセス許可を追加します。ポリシードキュメントは、トピック [[Security best practices]](https://docs.aws.amazon.com/iot/latest/developerguide/security-best-practices.html#device-advisor-perms) (セキュリティのベストプラクティス) にあります。
1. **ポリシーのレビュー** を選択します。
1. [**Name (名前)**] と [**Description (説明)**] を入力します。
1. [**Create Policy (ポリシーの作成)**] を選択します。
## Device Advisor のテストの実行に使用する IAM ユーザーを作成する
**注記**
Device Advisor テストを実行するときに使用する IAM ユーザーを作成することをお勧めします。管理者ユーザーから Device Advisor のテストを実行すると、セキュリティ上のリスクが生じる可能性があるため、お勧めしません。
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) に移動します。プロンプトが表示されたら、 AWS 認証情報を入力してサインインします。
1. 左のナビゲーションペインで、[**Users**] (ユーザー) を選択します。
1. [**Add User**] を選択します。
1. **ユーザー名**を入力します。
1. ユーザーが の AWS 外部で を操作する場合は、プログラムによるアクセスが必要です AWS マネジメントコンソール。プログラムによるアクセスを許可する方法は、 がアクセスするユーザーのタイプによって異なります AWS。
ユーザーにプログラムによるアクセス権を付与するには、以下のいずれかのオプションを選択します。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/device-advisor-setting-up.html)
1. **[Next: Permissions]** (次のステップ: 許可) を選択します。
1. アクセスを提供するには、ユーザー、グループ、またはロールにアクセス許可を追加します。
+ 以下のユーザーとグループ 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) の指示に従います。
1. 作成したカスタム管理ポリシーの名前を検索ボックスに入力します。次に、**[ポリシー名]** のチェックボックスをオンにします。
1. [**Next: Tags (次へ: タグ)**] を選択します。
1. [**Next: Review**] を選択します。
1. [**Create user**] を選択します。
1. [**閉じる**] を選択します。
Device Advisor では、ユーザーに代わって AWS リソース (モノ、証明書、エンドポイント) にアクセスする必要があります。IAM ユーザーは必要なアクセス許可を備えている必要があります。また、必要なアクセス許可ポリシーを IAM ユーザーにアタッチすると、Device Advisor は Amazon CloudWatch にログを発行します。
## デバイスを設定する
Device Advisor は、サーバー名表示 (SNI) TLS 拡張を使用して TLS 設定を適用します。デバイスは、接続時にこの拡張を使用し、Device Advisor のテストエンドポイントと同じサーバー名を渡す必要があります。
Device Advisor は、テストが `Running` のステータスにあるときに TLS 接続を許可します。Device Advisor は、各テストの実行前と実行後に TLS 接続を拒否します。このため、Device Advisor で完全に自動化されたテストを行うために、デバイス接続の再試行メカニズムを使用することをお勧めします。TLS 接続、MQTT 接続、MQTT パブリッシュなど、複数のテストケースを含むテストスイートを実行できます。複数のテストケースを実行する場合、デバイスが 5 秒ごとにテストエンドポイントに接続することを推奨します。その後、自動化された方法で順番に複数のテストケースを実行できます。
**注記**
テスト用にデバイスソフトウェアを準備するには、 AWS IoT Coreに接続できる SDK を使用することをお勧めします。次に、 AWS アカウント用に提供された Device Advisor テストエンドポイントで SDK を更新する必要があります。
Device Advisor が、アカウントレベルのエンドポイントとデバイスレベルのエンドポイントの 2 種類のエンドポイントをサポートします。ユースケースに最も適したエンドポイントを選択します。異なるデバイスを使用して複数のテストスイートを同時に実行するには、デバイスレベルのエンドポイントを使用します。
次のコマンドを実行して、デバイスレベルのエンドポイントを取得します。
X.509 クライアント証明書を使用する MQTT のお客様の場合:
```
aws iotdeviceadvisor get-endpoint --thing-arn your-thing-arn
```
または
```
aws iotdeviceadvisor get-endpoint --certificate-arn your-certificate-arn
```
シグネチャバージョン 4 を使用している MQTT over WebSocket のお客様の場合:
```
aws iotdeviceadvisor get-endpoint --device-role-arn your-device-role-arn --authentication-method SignatureVersion4
```
一度に 1 つのテストスイートを実行するには、アカウントレベルのエンドポイントを選択します。次のコマンドを実行して、アカウントレベルのエンドポイントを取得します。
```
aws iotdeviceadvisor get-endpoint
```
# コンソールでの Device Advisor の開始方法
このチュートリアルは、 コンソール AWS IoT Core Device Advisor で の使用を開始するのに役立ちます。Device Advisor は、必要なテストや署名済み認定レポートなどの機能を提供します。これらのテストとレポートを使用して、[AWS IoT Core 認定プログラム](https://aws.amazon.com/partners/dqp/)で詳述されているように、[AWS Partner Device Catalog](https://devices.amazonaws.com/) でデバイスを認定して一覧表示できます。
Device Advisor の使用の詳細については、[Device Advisor ワークフロー](device-advisor-workflow.md) および [Device Advisor の詳細コンソールワークフロー](device-advisor-console-tutorial.md) を参照してください。
このチュートリアルを完了するには、[設定](device-advisor-setting-up.md) で概説されている手順に従います。
**注記**
Device Advisor は、以下でサポートされています AWS リージョン。
米国東部 (バージニア北部)
米国西部 (オレゴン)
アジアパシフィック (東京)
欧州 (アイルランド)
**開始方法**
1. [AWS IoT コンソール](https://console.aws.amazon.com//iot)のナビゲーションペインの **[テスト]** の下で、**[Device Advisor]** を選択します。次に、コンソールの **[チュートリアルの開始]** ボタンを選択します。
![\[Device Advisor は、 IoT デバイスが との安全なやり取りを検証し AWS IoT Core、ソフトウェアの問題を特定し、テスト結果を取得するためのフルマネージド型のテスト機能です。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-gs.png)
1. **[Device Advisor の開始方法]** ページでは、テストスイートを作成し、デバイスに対してテストを実行するために必要な手順の概要を説明しています。アカウントの Device Advisor テストエンドポイントもここで見つけることができます。このテストエンドポイントに接続するには、テストに使用するデバイスのファームウェアまたはソフトウェアを設定する必要があります。
このチュートリアルを完了するには、まず[モノと証明書を作成し](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-create-thing-certificate)ます。**[仕組み]** の情報を確認したら、**[次へ]** を選択します。
![\[IoT デバイスの接続をテストする手順: プロトコルの選択、テストスイートの作成、デバイス設定の設定。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-gs1.png)
1. **[ステップ 1: プロトコルの選択]** で、表示されるオプションからプロトコルを選択します。その後、**[Next]** を選択します。
![\[IoT デバイスをテストするための通信プロトコル (MQTT 3.1.1、MQTT 3.1.1 over WebSocket 、MQTT 5、MQTT 5 over WebSocket) を選択するオプションを示す Device Advisor インターフェイス。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-protocol.png)
1. **ステップ 2** では、カスタムテストスイートの作成および設定を行います。カスタムテストスイートには少なくとも 1 つのテストグループがなければならず、各テストグループには少なくとも 1 つのテストケースが必要です。使用を開始できるように、**MQTT Connect** テストケースを追加しました。
[**Test suite properties**] (テストスイートのプロパティ) を選択します。
![\[Device Advisor の「テストスイートの作成」画面。ユーザーは、MQTT プロトコルを使用して IoT デバイスをテストするためのテストグループとケースを作成および設定できます。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-test-suite-create.png)
テストスイートを作成するときは、テストスイートのプロパティを指定します。設定できるスイートレベルのプロパティは次の通りです。
+ **テストスイート名**: テストスイートの名前を入力します。
+ **[タイムアウト]** (オプション): 現在のテストスイートの各テストケースの秒単位でのタイムアウト。タイムアウト値を指定しない場合、デフォルト値を使用します。
+ **[Tags]** (タグ) (オプション): テストスイートにタグを追加します。
完了したら、**[Update properties]** (プロパティの更新) を選択します。
![\[名前、タイムアウト、タグを追加する機能など、テストスイートのプロパティを更新するフォーム。「プロパティの更新」ボタンが含まれています。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-test-suite-properties.png)
1. (オプション) テストスイートグループの設定を更新するには、テストグループ名の横にある **[編集]** ボタンを選択します。
+ **名前**: テストスイートグループのカスタム名を入力します。
+ **[タイムアウト]** (オプション): 現在のテストスイートの各テストケースの秒単位でのタイムアウト。タイムアウト値を指定しない場合、デフォルト値を使用します。
終了したら、**[完了]** を選択して続行します。
![\[「テストグループ 1」という名前のテストグループが表示され、タイムアウトを設定し、テストグループを追加するオプションが表示されます。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-test-suite-config.png)
1. (オプション) テストケースの設定を更新するには、テストケース名の横にある **[編集]** ボタンを選択します。
+ **名前**: テストスイートグループのカスタム名を入力します。
+ **[タイムアウト]** (オプション): 選択したテストケースのタイムアウト (秒)。タイムアウト値を指定しない場合、デフォルト値を使用します。
終了したら、**[完了]** を選択して続行します。
![\[IoT デバイスをテストするためのテストスイート、テストグループ、個々のテストケースを設定するオプションを示す「テストスイートの作成」インターフェイス。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-test-case-config.png)
1. (オプション) テストスイートにさらにテストグループを追加するには、**[テストグループの追加]** を選択し、ステップ 5 の手順に従います。
1. (オプション) テストケースをさらに追加するには、**[テストケース]** セクションのテストケースを、任意のテストグループにドラッグします。
![\[IoT デバイスの MQTT プロトコルテストのテストグループとテストケースをユーザーが設定できる「テストスイートの作成」インターフェイス。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-drag.png)
1. テストグループとテストケースの順序を変更できます。変更するには、リストされているテストケースをリストの上または下にドラッグします。Device Advisor は、リストされている順序でテストを実行します。
テストスイートを設定したら、[**Next**] (次へ) を選択します。
1. **ステップ 3 **で、Device Advisor を使用してテストする AWS IoT モノまたは証明書を選択します。既存のモノまたは証明書がない場合は、[セットアップ](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html) を参照してください。
![\[プロトコルの選択、テストスイートの作成、デバイス設定の設定、テストの実行と結果の確認を含む設定オプション。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-device-settings.png)
1. Device Advisor がテストデバイスに代わって AWS IoT MQTT アクションを実行するために使用するデバイスロールを設定できます。**[MQTT Connect]** テストケースの場合のみ、**[接続]** アクションが自動的に選択されます。これは、デバイスロールがテストスイートを実行するためにこの権限を必要とするためです。他のテストケースでは、対応するアクションが選択されます。
選択した各アクションのリソース値を指定します。例えば、**[接続]** アクションでは、デバイスと Device Advisor エンドポイントの接続に使用するクライアント ID を指定します。カンマ区切りの値を使用して複数の値を指定したり、値のプレフィックスにワイルドカード (\$1) 文字を使用したりできます。例えば、`MyTopic` で始まる任意のトピックで発行するためのアクセス許可を付与する場合は、リソース値として「**MyTopic\$1**」を指定できます。
![\[デバイスロールを選択し、MQTT トピックとクライアント ID を接続、公開、サブスクライブ、および管理するためのアクセス許可を定義できる Device Advisor インターフェイス。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-device-role.png)
[セットアップ](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html)で以前に作成したデバイスロールを使用するには、**[既存のロールを選択]** を選択します。次に、**[ロールの選択]** でデバイスロールを選択します。
![\[デバイスロールを選択するためのウェブフォームインターフェイス。新しいロールを作成するか、「DeviceAdvisorServiceRole」という名前の既存のロールを選択するオプションがあります。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-select-device-role.png)
提供されている 2 つのオプションのいずれかを使用してデバイスロールを設定し、**[次へ]** を選択します。
1. **[テストエンドポイント]** セクションで、ユースケースに最適なエンドポイントを選択します。同じ で複数のテストスイートを同時に実行するには AWS アカウント、**デバイスレベルのエンドポイント**を選択します。一度に 1 つのテストスイートを実行する場合、**[アカウントレベルのエンドポイント]** を選択します。
![\[エンドポイント URL を指定し、次へボタンを使用して、テストするアカウントレベルまたはデバイスレベルのエンドポイントを選択するオプション。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-endpoint.png)
1. **[ステップ 4]** では、選択したテストデバイス、テストエンドポイント、テストスイート、および設定したテストデバイスロール設定の概要が表示されます。セクションに変更を加える場合は、編集するセクションの **[編集]** ボタンを選択します。テスト構成を確認したら、**[実行]** を選択してテストスイートを作成し、テストを実行します。
**注記**
最良の結果を得るために、テストスイートの実行を開始する前に、選択したテストデバイスを Device Advisor テストエンドポイントに接続できます。1～2 分間、デバイスが 5 秒ごとにテストエンドポイントへの接続を試行するメカニズムを構築することをお勧めします。
![\[デバイスロールの詳細、テストエンドポイント、キャンセル、戻る、または実行するオプションを表示するデバイス設定コンソール。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-device-review.png)
![\[デバイスロールの詳細、テストエンドポイント、キャンセル、戻る、または実行するオプションを表示するデバイス設定コンソール。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-device-review-contd.png)
1. ナビゲーションペインの **[テスト]** の下で、**[Device Advisor]**、**[テストの実行と結果]** の順に選択します。実行の詳細とログを表示するには、実行を開始したテストスイートを選択します。
![\[MQTT 3.1.1 テストがデバイス「MyThing」に対して進行中であることを示すテストスイートインターフェイス。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-console-runs-results.png)
1. スイート実行の Amazon CloudWatch ログにアクセスするには:
+ [**Test suite log**] (テストスイートのログ) を選択して、テストスイートの実行の CloudWatch ログを表示します。
+ テストケース固有の CloudWatch ログを表示するには、テストケースの [**Test case log**] (テストケースログ) を選択します。
1. テスト結果に基づいて、すべてのテストに合格するまでデバイスの[トラブルシューティング](https://docs.aws.amazon.com/iot/latest/developerguide/iot_troubleshooting.html#device-advisor-troubleshooting)を行います。
# Device Advisor ワークフロー
このチュートリアルでは、カスタムテストスイートを作成し、コンソールでテストするデバイスに対してテストを実行する方法について説明します。テストが完了したら、テスト結果と詳細ログを表示できます。
## 前提条件
このチュートリアルを開始する前に、「[設定](device-advisor-setting-up.md)」で説明されている手順を完了してください。
## テストスイート定義を作成する
まず、 [AWS SDK をインストールします](https://docs.aws.amazon.com/iot/latest/developerguide/iot-connect-service.html#iot-service-sdks)。
### `rootGroup` の構文
ルートグループは、テストスイートに含めるテストケースを指定する JSON 文字列です。また、これらのテストケースに必要な構成も指定します。ルートグループを使用して、テストスイートを任意の態様で構造化し、順序付けます。テストスイートの階層は次のとおりです。
```
test suite → test group(s) → test case(s)
```
テストスイートには少なくとも 1 つのテストグループがなければならず、各テストグループには少なくとも 1 つのテストケースが必要です。Device Advisor は、テストグループとテストケースを定義する順序でテストを実行します。
各ルートグループは、次の基本的な構造に従います。
```
{
"configuration": { // for all tests in the test suite
"": ""
}
"tests": [{
"name": ""
"configuration": { // for all sub-groups in this test group
"": ""
},
"tests": [{
"name": ""
"configuration": { // for all test cases in this test group
"": ""
},
"test": {
"id": ""
"version": ""
}
}]
}]
}
```
ルートグループでは、グループに含まれる `name`、`configuration`、および `tests` を使用してテストスイートを定義します。`tests` グループには、個々のテストの定義が含まれています。各テストは、`name`、`configuration` およびそのテストのテストケースを定義する `test` ブロックを使用して定義します。最後に、各テストケースは `id` と `version` で定義されます。
各テストケース (`test` ブロック) の `"id"` フィールドと `"version"` フィールドの使用方法については、「[Device Advisor テストケース](device-advisor-tests.md)」を参照してください。そのセクションには、使用可能な `configuration` 設定に関する情報も含まれています。
次のブロックは、ルートグループ設定の例です。この設定では、設定フィールドについての説明とともに、*MQTT Connect Happy Case* および *MQTT Connect Exponential Backoff Retries* テストケースを指定します。
```
{
"configuration": {}, // Suite-level configuration
"tests": [ // Group definitions should be provided here
{
"name": "My_MQTT_Connect_Group", // Group definition name
"configuration": {} // Group definition-level configuration,
"tests": [ // Test case definitions should be provided here
{
"name": "My_MQTT_Connect_Happy_Case", // Test case definition name
"configuration": {
"EXECUTION_TIMEOUT": 300 // Test case definition-level configuration, in seconds
},
"test": {
"id": "MQTT_Connect", // test case id
"version": "0.0.0" // test case version
}
},
{
"name": "My_MQTT_Connect_Jitter_Backoff_Retries", // Test case definition name
"configuration": {
"EXECUTION_TIMEOUT": 600 // Test case definition-level configuration, in seconds
},
"test": {
"id": "MQTT_Connect_Jitter_Backoff_Retries", // test case id
"version": "0.0.0" // test case version
}
}]
}]
}
```
テストスイート定義を作成するときに、ルートグループ設定を指定する必要があります。応答オブジェクトで返された `suiteDefinitionId` を保存します。この ID を使用して、テストスイートの定義情報を取得し、テストスイートを実行できます。
Java SDK の例を次に示します。
```
response = iotDeviceAdvisorClient.createSuiteDefinition(
CreateSuiteDefinitionRequest.builder()
.suiteDefinitionConfiguration(SuiteDefinitionConfiguration.builder()
.suiteDefinitionName("your-suite-definition-name")
.devices(
DeviceUnderTest.builder()
.thingArn("your-test-device-thing-arn")
.certificateArn("your-test-device-certificate-arn")
.deviceRoleArn("your-device-role-arn") //if using SigV4 for MQTT over WebSocket
.build()
)
.rootGroup("your-root-group-configuration")
.devicePermissionRoleArn("your-device-permission-role-arn")
.protocol("MqttV3_1_1 || MqttV5 || MqttV3_1_1_OverWebSocket || MqttV5_OverWebSocket")
.build()
)
.build()
)
```
## テストスイート定義を取得する
テストスイート定義を作成した後、`CreateSuiteDefinition` API オペレーションの応答オブジェクトで `suiteDefinitionId` を受け取ります。
オペレーションが `suiteDefinitionId` を返すと、各グループ内に新しい `id` フィールドが表示され、ルートグループ内にテストケース定義が表示される場合があります。これらの ID を使用してテストスイート定義のサブセットを実行できます。
Java SDK の例:
```
response = iotDeviceAdvisorClient.GetSuiteDefinition(
GetSuiteDefinitionRequest.builder()
.suiteDefinitionId("your-suite-definition-id")
.build()
)
```
## テストエンドポイントを取得する
`GetEndpoint` API オペレーションを使用して、デバイスで使用されるテストエンドポイントを取得できます。テストに最適なエンドポイントを選択します。複数のテストスイートを同時に実行する場合は、`thing ARN`、`certificate ARN`、または `device role ARN` を指定してデバイスレベルのエンドポイントを使用します。単一のテストスイートを実行するには、GetEndpoint オペレーションに引数を指定せずに、アカウントレベルのエンドポイントを選択します。
SDK の例:
```
response = iotDeviceAdvisorClient.getEndpoint(GetEndpointRequest.builder()
.certificateArn("your-test-device-certificate-arn")
.thingArn("your-test-device-thing-arn")
.deviceRoleArn("your-device-role-arn") //if using SigV4 for MQTT over WebSocket
.build())
```
## テストスイートの実行を開始する
テストスイートの定義を作成し、Device Advisor のテストエンドポイントに接続するためにテストデバイスを設定したら、`StartSuiteRun` API を使用してテストスイートを実行します。
MQTT のお客様は、`certificateArn` または `thingArn` を使用してテストスイートを実行します。両方が設定されている場合、証明書がモノに属している場合は証明書が使用されます。
MQTT over WebSocket をご利用のお客様は、`deviceRoleArn` を使用してテストスイートを実行してください。指定されたロールがテストスイート定義で指定されたロールと異なる場合、指定されたロールは定義されたロールよりも優先されます。
`.parallelRun()` の場合、デバイスレベルのエンドポイントを使用して、1 つの AWS アカウントアカウントで複数のテストスイートを並列して実行する場合、`true` を使用します。
SDK の例:
```
response = iotDeviceAdvisorClient.startSuiteRun(StartSuiteRunRequest.builder()
.suiteDefinitionId("your-suite-definition-id")
.suiteRunConfiguration(SuiteRunConfiguration.builder()
.primaryDevice(DeviceUnderTest.builder()
.certificateArn("your-test-device-certificate-arn")
.thingArn("your-test-device-thing-arn")
.deviceRoleArn("your-device-role-arn") //if using SigV4 for MQTT over WebSocket
.build())
.parallelRun(true | false)
.build())
.build())
```
レスポンスから `suiteRunId` を保存します。これを使用して、このテストスイートの実行の結果を取得します。
## テストスイートの実行を取得する
テストスイートの実行を開始したら、その進行状況を確認し、`GetSuiteRun` API を使用してその結果を確認できます。
SDK の例:
```
// Using the SDK, call the GetSuiteRun API.
response = iotDeviceAdvisorClient.GetSuiteRun(
GetSuiteRunRequest.builder()
.suiteDefinitionId("your-suite-definition-id")
.suiteRunId("your-suite-run-id")
.build())
```
## テストスイートの実行を停止する
まだ進行中のテストスイートの実行を停止する場合は、`StopSuiteRun` API オペレーションを呼び出します。`StopSuiteRun` オペレーションを呼び出すと、サービスはクリーンアッププロセスを開始します。サービスがクリーンアップ処理を実行している間、テストスイートの実行ステータスが `Stopping` に更新されます。このクリーンアッププロセスには、数分以上かかることがあります。プロセスが完了すると、テストスイートの実行ステータスが `Stopped` に更新されます。テストの実行が完全に停止したら、別のテストスイートの実行を開始できます。前のセクションの説明どおりに `GetSuiteRun` API オペレーションを使用して、スイートの実行ステータスを定期的にチェックすることができます。
SDK の例:
```
// Using the SDK, call the StopSuiteRun API.
response = iotDeviceAdvisorClient.StopSuiteRun(
StopSuiteRun.builder()
.suiteDefinitionId("your-suite-definition-id")
.suiteRunId("your-suite-run-id")
.build())
```
## 成功した認定テストスイートの実行の認定レポートを取得する
正常に完了した認定テストスイートを実行すると、`GetSuiteRunReport` API オペレーションを使用して認定レポートを取得できます。この認定レポートを使用して、 AWS IoT Core 認定プログラムでデバイスを認定します。テストスイートが認定テストスイートであるかどうかを判断するには、`intendedForQualification` パラメータが `true` に設定されているかどうかを確認します。`GetSuiteRunReport` API オペレーションを呼び出した後、返された URL からレポートを最大 90 秒間ダウンロードできます。`GetSuiteRunReport` API オペレーションを最後に呼び出してから 90 秒を超える時間が経過した場合は、そのオペレーションを再度呼び出して有効な URL を取得します。
SDK の例:
```
// Using the SDK, call the getSuiteRunReport API.
response = iotDeviceAdvisorClient.getSuiteRunReport(
GetSuiteRunReportRequest.builder()
.suiteDefinitionId("your-suite-definition-id")
.suiteRunId("your-suite-run-id")
.build()
)
```
# Device Advisor の詳細コンソールワークフロー
このチュートリアルでは、カスタムテストスイートを作成し、コンソールでテストするデバイスに対してテストを実行します。テストが完了したら、テスト結果と詳細ログを表示できます。
**Topics**
+ [前提条件](#da-detailed-prereqs)
+ [テストスイート定義を作成する](#device-advisor-console-create-suite)
+ [テストスイートの実行を開始する](#device-advisor-console-run-test-suite)
+ [テストスイートの実行を停止する (オプション)](#device-advisor-stop-test-run)
+ [テストスイートの実行の詳細とログを表示する](#device-advisor-console-view-logs)
+ [AWS IoT 認定レポートをダウンロードする](#device-advisor-console-qualification-report)
## 前提条件
このチュートリアルを完了するには、[モノや証明書を作成する](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-create-thing-certificate)必要があります。
## テストスイート定義を作成する
テストスイートスイートを作成して、デバイス用に実行して検証を実行できるようにします。
1. [AWS IoT コンソール](https://console.aws.amazon.com//iot)のナビゲーションペインで、[**Test**] (テスト)、[**Device Advisor**] の順に展開し、[**Test suites**] (テストスイート) を選択します。
![\[Device Advisor インターフェイスには、対象デバイス、長時間テストの実行、カスタムテストスイート用のテストスイートを作成するオプションがあります。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-testsuite.png)
**[Create test suite]** (テストスイートの作成) を選択します。
1. [`Use the AWS Qualification test suite`] または [`Create a new test suite`] のいずれかを選択します。
プロトコルについては、**[MQTT 3.1.1]** または **[MQTT 5]** のいずれかを選択します。
![\[テストスイートタイプ (AWS IoT Core 認定、長期、またはカスタム) とプロトコル (MQTT 3.1.1 または MQTT 5) を選択するオプションを含む「テストスイートの作成」。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-create-test-suite.png)
`Use the AWS Qualification test suite` を選択してデバイスを認定し、 AWS Partner Device Catalog に一覧表示します。このオプションを選択すると、 AWS IoT Core 認定プログラムへのデバイスの認定に必要なテストケースが事前に選択されます。テストグループおよびテストケースを追加または削除することはできません。テストスイートのプロパティを設定する必要があります。
`Create a new test suite` を選択して、カスタムテストスイートを作成および設定します。最初のテストとトラブルシューティングを行う場合は、このオプションから始めることをお勧めします。カスタムテストスイートには少なくとも 1 つのテストグループがなければならず、各テストグループには少なくとも 1 つのテストケースが必要です。このチュートリアルでは、このオプションを選択し、[**Next**] (次へ) を選択します。
![\[IoT デバイスをテストするためのテストグループとケースを含むテストスイートを作成する手順を示すテストスイートページを設定します。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-configure-test-suite.png)
1. [**Test suite properties**] (テストスイートのプロパティ) を選択します。テストスイートを作成するときに、テストスイートのプロパティを作成する必要があります。
![\[IoT デバイス機能をテストするためのテストグループを作成し、テストケースを追加するオプションを示す「テストスイートの設定」インターフェイス。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-test-suite-properties.png)
**[Test suite properties]** (テストスイートのプロパティ) で、次の情報を入力します。
+ **テストスイートの名前**: カスタム名を使用してスイートを作成できます。
+ **タイムアウト** (オプション): 現在のテストスイートの各テストケースの秒単位でのタイムアウト 。タイムアウト値を指定しない場合、デフォルト値を使用します。
+ **[Tags]** (タグ) (オプション): テストスイートにタグを追加します。
![\[Device Advisor デモスイートのテストスイート名、タイムアウト、カスタムタグを指定するフィールドを示す「テストスイートプロパティ」というタイトルのウィンドウ。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-test-suite-properties-1.png)
完了したら、[**Update properties**] (プロパティの更新) を選択します。
1. グループレベルの設定を変更するには、`Test group 1` で [**Edit**] (編集) を選択します。その後、**名前**を入力して、グループにカスタム名を付けます。
オプションで、選択したテストグループの下に秒単位で [**Timeout**] (タイムアウト) 値を入力することもできます。タイムアウト値を指定しない場合、デフォルト値を使用します。
![\[IoT デバイス機能を検証するためのテストグループとケースを作成するための「テストスイートの設定」インターフェイス。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-edit-test-group.png)
[**Done**] を選択します。
1. 使用可能ないずれかのテストケースを [**Test cases**] (テストケース) からテストグループにドラッグします。
![\[Device Advisor でテストスイートを作成するための設定インターフェイス。IoT デバイスをテストするためのテストグループとテストケースを追加するオプションがあります。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-configure-test-suite-step5.png)
1. テストグループに追加したテストケースのテストケースレベルの設定を変更するには、**[Edit]** (編集) を選択します。その後、**名前**を入力して、グループにカスタム名を付けます。
オプションで、選択したテストグループの下に秒単位で [**Timeout**] (タイムアウト) 値を入力することもできます。タイムアウト値を指定しない場合、デフォルト値を使用します。
![\[テストスイート実行のテストグループ、テストケース、タイムアウト設定、開始ポイントを設定するオプションを備えたテストスイート設定インターフェイス。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-edit-test-case.png)
[**Done**] を選択します。
**注記**
テストスイートにさらにテストグループを追加するには、[**Add test group**] (テストグループの追加) を選択します。前の手順に従って、さらにテストグループを作成して設定するか、1 つ以上のテストグループにテストケースを追加します。テストケースを選択し、目的の位置にドラッグすることによって、テストグループとテストケースを並べ替えることができます。Device Advisor は、テストグループとテストケースを定義する順序でテストを実行します。
1. [**次へ**] を選択します。
1. **ステップ 3 **で、Device Advisor がテストデバイスに代わって AWS IoT MQTT アクションを実行するために使用するデバイスロールを設定します。
**ステップ 2** で **MQTT Connect** テストケースのみを選択した場合、**[Connect]** (接続) アクションが自動的にチェックされます。このテストスイートを実行するために、デバイスロールに対してそのアクセス許可が必要になるためです。他のテストケースを選択した場合、対応する必須アクションがチェックされます。各アクションのリソース値が提供されていることを確認します。例えば、**[Connect]** (接続) アクションでは、デバイスと Device Advisor エンドポイントの接続に使用するクライアント ID を指定します。カンマを使用して値を区切ることで、複数の値を指定できます。また、ワイルドカード (\$1) 文字を使用して、プレフィックス値を指定することもできます。例えば、`MyTopic` で始まる任意のトピックで発行するためのアクセス許可を付与する場合は、リソース値として「`MyTopic*`」を指定できます。
![\[Device Advisor でテストスイートを作成するための「デバイスロールの選択」ステップ。新しいロールを作成するか、既存のロールを選択するオプションと、ロール名、アクセス許可、リソースの詳細を指定するフィールドがあります。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-connect-role.png)
以前にデバイスロールを作成していて、そのロールを使用する場合は、**[Select an existing role]** (既存のロールを選択) を選択し、**[Select role]** (ロールを選択) でデバイスロールを選択します。
![\[Device Advisor テスト用のデバイスロールを選択するページ。新しいロールを作成するか、既存のロールを選択するオプションがあります。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-existing-role.png)
提供されている 2 つのオプションのいずれかを使用してデバイスロールを設定し、**[Next]** (次へ) をクリックします。
1. **ステップ 4** では、各ステップで指定した設定が正確であることを確認します。特定のステップの指定した設定を編集するには、対応するステップの **[Edit]** (編集) を選択します。
設定を確認したら、**[Create Test Suite]** (テストスイートの作成) を選択します。
テストスイートが正常に作成され、作成されたすべてのテストスイートを表示できる [**Test suites**] (テストスイート) ページにリダイレクトされます。
テストスイートの作成に失敗した場合は、テストスイート、テストグループ、テストケース、およびデバイスロールが、前述の指示に従って設定されていることを確認します。
## テストスイートの実行を開始する
1. [AWS IoT コンソール](https://console.aws.amazon.com//iot)のナビゲーションペインで、[**Test**] (テスト)、[**Device Advisor**] の順に展開し、[**Test suites**] (テストスイート) を選択します。
1. テストスイートの詳細を表示するテストスイートを選択します。
![\[2021 年 5 月 11 日に作成された「デバイスアドバイザーデモスイート」という名前の単一のテストスイートを示すコンソール。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-test-suites.png)
テストスイートの詳細ページには、テストスイートに関連するすべての情報が表示されます。
1. [**Actions**] (アクション)、[**Run test suite**] (テストスイートの実行) の順に選択します。
![\[[テストスイートを実行する] ボタンと、以前のテストスイートの実行がないことを示す空のアクティビティログを含むデモスイートページ。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-run-test-suites.png)
1. **実行設定**で、Device Advisor を使用してテストする AWS IoT モノまたは証明書を選択する必要があります。既存のモノや証明書がない場合は、まず[AWS IoT Core リソースを作成します](device-advisor-setting-up.md)。
**[Test endpoint]** (テストエンドポイント) セクションで、ケースに最適なエンドポイントを選択します。将来、同じ AWS アカウントを使用して複数のテストスイートを同時に実行する予定がある場合は、**デバイスレベルのエンドポイント**を選択します。別の方法として、一度に 1 つのテストスイートのみを実行する場合は、**[Account-level endpoint]** (アカウントレベルのエンドポイント) を選択します。
選択した Device Advisor のテストエンドポイントでテストデバイスを設定します。
モノまたは証明書を選択し、Device Advisor エンドポイントを選択したら、**[Run test]** (テストの実行) を選択します。
![\[でテストスイートを実行するための設定。テストデバイス (モノまたは証明書) の選択 AWS IoT Core、テストエンドポイント (アカウントレベルまたはデバイスレベル) の選択、オプションでタグの追加ができます。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-choose-thing-certificate.png)
1. テスト実行の詳細を表示するには、上部にあるバナーの [**Go to results**] (結果に移動) を選択します。
![\[ステータスが「保留中」で進行中の「デバイスアドバイザーデモスイート」というタイトルのカスタムテストスイートの詳細。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-test-run-results.png)
## テストスイートの実行を停止する (オプション)
1. [AWS IoT コンソール](https://console.aws.amazon.com//iot)のナビゲーションペインで、[**Test**] (テスト)、[**Device Advisor**] の順に展開し、[**Test runs and results**] (テストの実行と結果) を選択します。
1. 停止する進行中のテストスイートを選択します。
![\[Device Advisor コンソールでのテスト実行の結果。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-test-suite-to-stop.PNG)
1. [**Actions**] (アクション)、[**Stop test suite**] (テストスイートを停止) の順に選択します。
![\[Device Advisor コンソールでのテスト実行の結果。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-stop-test-suite.PNG)
1. このクリーンアップ処理は完了までに数分かかります。クリーンアップ処理の実行中、テストの実行ステータスは `STOPPING` になります。クリーンアップ処理が完了し、テストスイートのステータスが `STOPPED` ステータスに変わった後に、新しいスイートの実行を開始します。
![\[Device Advisor コンソールでのテスト実行の停止結果。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-stopped-test-suite.PNG)
## テストスイートの実行の詳細とログを表示する
1. [AWS IoT コンソール](https://console.aws.amazon.com//iot)のナビゲーションペインで、[**Test**] (テスト)、[**Device Advisor**] の順に展開し、[**Test runs and results**.] (テストの実行と結果) を選択します。
このページが表示されます。
+ IoT モノの数
+ IoT 証明書の数
+ 現在実行中のテストスイートの数
+ 作成されたすべてのテストスイートの実行
1. 実行の詳細とログを表示するテストスイートを選択します。
![\[テスト実行と結果セクションには、現在進行中の「Device Advisor でもスイート」という名前のテストスイートの詳細が表示されます。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-test-suite-run.png)
実行の概要のページには、現在のテストスイート実行のステータスが表示されます。このページは 10 秒ごとに自動更新されます。1～2 分間、デバイスが 5 秒ごとにテストエンドポイントへの接続を試行するメカニズムを構築することをお勧めします。その後、自動化された方法で順番に複数のテストケースを実行できます。
![\[システムメッセージが表示されずに MQTT Connect テストが成功したことを示すテストケースログ。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-run-summary.png)
1. テストスイート実行の CloudWatch ログにアクセスするには、[**Test suite log**] (テストスイートログ) を選択します。
テストケースの CloudWatch ログにアクセスするには、[**Test case log**] (テストケースログ) を選択します。
1. テスト結果に基づいて、すべてのテストに合格するまでデバイスの[トラブルシューティング](https://docs.aws.amazon.com/iot/latest/developerguide/iot_troubleshooting.html#device-advisor-troubleshooting)を行います。
## AWS IoT 認定レポートをダウンロードする
テスト**スイートの作成時に AWS IoT 認定テストスイートの使用**オプションを選択し、認定テストスイートを実行できた場合は、テスト実行の概要ページで認定レポート**のダウンロードを選択して認定レポートを**ダウンロードできます。
![\[MQTT、TLS、およびその他のコンポーネントのテストに合格したことを示す認定プログラムテスト結果。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/da-qualification-report.png)
# 長期テストコンソールのワークフロー
このチュートリアルは、コンソールを使用して Device Advisor で長時間テストを開始するのに役立ちます。このチュートリアルを完了するには、[設定](device-advisor-setting-up.md) のステップに従ってください。
1. [AWS IoT コンソール](https://console.aws.amazon.com/iot) のナビゲーションペインで、**[Test]** (テスト)、**[Device Advisor**] の順に展開し、[**Test suites**] (テストスイート) を選択します。ページで、**[Create long duration test suite]** (長期テストスイートの作成) を選択します。
![\[Device Advisor コンソールの長期間のテストスイートを作成セクション。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/create-ld-ts.png)
1. **[Create test suite]** (テストスイートの作成) ページで、**[Long duration test suite]** (長期テストスイート) を選択し、**[Next]** (次へ) を選択します。
プロトコルについては、**[MQTT 3.1.1]** または **[MQTT 5]** のいずれかを選択します。
![\[Device Advisor コンソールのテストスイートの作成ステップ。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/choose-ld-ts.png)
1. **[Configure test event]** (テストイベントの設定) ページで、以下の操作を行います。
1. **テストスイート名**フィールドを更新します。
1. **テストグループ名**フィールドを更新します。
1. デバイスが実行できる**デバイスオペレーション**を選択します。これにより、実行するテストが選択されます。
1. **[Settings]** (設定) オプションを選択します。
![\[Device Advisor コンソールのテストスイートの作成ステップ。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/configure-ld-ts.png)
1. (オプション) Device Advisor が基本テストを完了するまで待機する必要のある最大時間を入力します。**[保存]** を選択します。
![\[Device Advisor コンソールの「基本テスト」の「タイムアウトオプション」ボックス。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/timeout-ld-ts.png)
1. **[Advanced tests]** (詳細テスト) セクションと **[Additional settings]** (追加設定) セクションで次の操作を行います。
1. このテストの一部として実行する**[Advanced tests]** (詳細テスト) を選択または選択解除します。
1. 必要に応じて、テストの設定を**編集します**。
1. **[Additional settings]** (追加設定) セクションで **[Additional execution time]** (追加実行時間) を設定します。
1. **[Next]** (次へ) を選択して、次のステップに進みます。
![\[IoT デバイスでテストを設定および実行できる Device Advisor インターフェイス。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/additional-ld-ts.png)
1. このステップでは、**新しいロールを作成するか**、**既存のロールを選択します**。詳細については、「[デバイスロールとして使用する IAM ロールを作成する](device-advisor-setting-up.md#da-iam-role)」を参照してください。
![\[テスト対象のデバイスの新しいロールを作成したり、既存のロールを選択できるデバイスロールステップ。このロールは、テストデバイスに代わって Device Advisor が接続、パブリッシュ、サブスクライブなどの MQTT アクションを実行するアクセス許可を付与します。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/devicerole-ld-ts.png)
1. このステップまでに作成したすべての設定を確認し、**[Create test suite]** (テストスイートの作成) を選択します。
![\[Device Advisor 設定のすべての詳細を確認できる「レビュー」ページ。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/finalconfigure1-ld-ts.png)
![\[Device Advisor の詳細をすべて表示できる設定ページ。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/finalconfigure2-ld-ts.png)
1. 作成されたテストスイートは、**[Test suites]** (テストスイート) セクションにあります。スイートを選択すると、詳細を表示できます。
![\[Device Advisor に「長期デモ」という名前の新しいテストスイートが正常に作成されました。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/finalts-ld-ts.png)
1. 作成したテストスイートを実行するには、**[Actions]** (アクション) を選択し、**[Run test suite]** (テストスイートを実行) を選択します。
![\[Device Advisor インターフェイスの「長期デモ」という名前の新しいテストスイートのアクションドロップダウンメニュー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/runts-ld-ts.png)
1. **[Run configuration]** (実行設定) ページで設定オプションを選択します。
1. テストを実行する対象の **[Things]** (モノ) または **[Certificate]** (証明書) を選択します。
1. **[Account-level endpoint]** (アカウントレベルのエンドポイント) または **[Device-level endpoint]** (デバイスレベルのエンドポイント) を選択します。
1. **[Run test]** (テストの実行) を選択して、テストを実行します。
![\[Device Advisor インターフェイスの設定を実行するページ。このページには、[テストデバイスを選択する]、[モノ]、[テストエンドポイント]、[タグ]が表示されます。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/runconfiguration-ld-ts.png)
1. テストスイートの実行結果を表示するには、左側のナビゲーションペインで **[Test runs and results]** (テストの実行と結果) を選択します。実行したテストスイートを選択すると、結果の詳細が表示されます。
![\[[テストの実行と結果] ページの「長期デモ」テストケース。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/results-ld-ts.png)
1. 前のステップでは、テストの概要ページが表示されます。テスト実行の詳細はすべてこのページに表示されます。コンソールにデバイス接続の開始を求めるメッセージが表示されたら、デバイスを指定されたエンドポイントに接続します。テストの進捗状況はこのページに表示されます。
![\[作成した「長期デモ」テストの概要ページ。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/summary-ld-ts.png)
1. 長時間テストでは、サイドパネルに**テストログの概要**が追加され、デバイスとブローカーの間で発生するすべての重要なイベントがほぼリアルタイムで表示されます。より詳細なログを表示するには、**[Test case log]** (テストケースログ) をクリックします。
![\[「長時間デモ」テストのページの [テストログの概要] セクション。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/log-ld-ts.png)
# デバイスアドバイザー VPC エンドポイント (AWS PrivateLink)
*インターフェイス* VPC エンドポイントを作成することで、VPC と AWS IoT Core Device Advisor テストエンドポイント (データプレーン) の間にプライベート接続を確立できます。このエンドポイントを使用して、 AWS IoT デバイスを本番環境にデプロイ AWS IoT Core する前に、 との信頼性の高い安全な接続についてデバイスを検証できます。Device Advisor の事前構築されたテストにより、デバイスソフトウェアを [TLS](https://docs.aws.amazon.com/iot/latest/developerguide/protocols.html)、[MQTT](https://docs.aws.amazon.com/iot/latest/developerguide/protocols.html)、[デバイスシャドウ](https://docs.aws.amazon.com/iot/latest/developerguide/iot-device-shadows.html)、および [AWS IoT Jobs](https://docs.aws.amazon.com/iot/latest/developerguide/iot-jobs.html) の使用に関するベストプラクティスに照らして検証できます。
[AWS PrivateLink](https://aws.amazon.com/privatelink) は、IoT デバイスで使用されるインターフェイスエンドポイントを強化します。このサービスにより、インターネットゲートウェイ、NAT デバイス、VPN 接続、または Direct Connect 接続なしで、 AWS IoT Core Device Advisor テストエンドポイントにプライベートにアクセスできます。TCP パケットと MQTT パケットを送信する VPC 内のインスタンスは、 AWS IoT Core Device Advisor テストエンドポイントと通信するためにパブリック IP アドレスを必要としません。VPC と AWS IoT Core Device Advisor の間のトラフィックは離れません AWS クラウド。IoT デバイスと Device Advisor テストケース間の TLS および MQTT 通信はすべて、 AWS アカウントのリソース内にとどまります。
各インターフェイスエンドポイントは、サブネット内の 1 つ以上の [Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) によって表されます。
インターフェイス VPC エンドポイントの使用の詳細については、*Amazon VPC ユーザーガイド*の「[インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html)」を参照してください。
## AWS IoT Core Device Advisor VPC エンドポイントに関する考慮事項
インターフェイス VPC エンドポイントを設定する前に、*Amazon VPC ユーザーガイド*の「[インターフェイスエンドポイントのプロパティと制限](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations)」を確認してください。次に進む前に、以下を検討してください。
+ AWS IoT Core Device Advisor は現在、VPC からの Device Advisor テストエンドポイント (データプレーン) への呼び出しをサポートしています。メッセージブローカーは、データプレーン通信を使用してデータを送受信します。これは TLS と MQTT パケットの助けを借りて行われます。 AWS IoT デバイスを Device Advisor テストエンドポイント AWS IoT Core Device Advisor に接続するための VPC エンドポイント。[コントロールプレーン API アクション](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iotdeviceadvisor/index.html)は、この VPC エンドポイントでは使用されません。テストスイートやその他のコントロールプレーン API を作成または実行するには、コンソール、 AWS SDK、またはパブリックインターネット上の AWS コマンドラインインターフェイスを使用します。
+ 次の は VPC エンドポイント AWS リージョン をサポートしています AWS IoT Core Device Advisor。
+ 米国東部 (バージニア北部)
+ 米国西部 (オレゴン)
+ アジアパシフィック (東京)
+ 欧州 (アイルランド)
+ Device Advisor は、X.509 クライアント証明書と RSA サーバー証明書による MQTT をサポートします。
+ [VPC エンドポイントポリシー](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)は、今のところサポートされていません。
+ VPC エンドポイントを接続する[リソースの作成](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)方法については、VPC エンドポイントの[前提条件](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#prerequisites-interface-endpoints)を確認してください。VPC エンドポイントを使用するには、 AWS IoT Core Device Advisor VPC とプライベートサブネットを作成する必要があります。
+ AWS PrivateLink リソースにはクォータがあります。詳細については、[AWS PrivateLink クォータ](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-limits-endpoints.html)を参照してください。
+ VPC エンドポイントは IPv4 トラフィックのみをサポートします。
## のインターフェイス VPC エンドポイントを作成する AWS IoT Core Device Advisor
VPC エンドポイントの使用を開始するには、[インターフェイス VPC エンドポイントを作成します](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)。次に、 AWS IoT Core Device Advisor として を選択します AWS のサービス。を使用している場合は AWS CLI、[describe-vpc-endpoint-services](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpc-endpoint-services.html) を呼び出して、 AWS IoT Core Device Advisor が のアベイラビリティーゾーンに存在することを確認します AWS リージョン。エンドポイントに接続されているセキュリティグループが MQTT および TLS トラフィックの [TCP プロトコル通信](https://docs.aws.amazon.com/iot/latest/developerguide/protocols.html)を許可していることを確認します。例えば、米国東部 (バージニア北部) リージョンでは、以下のコマンドを使用します。
```
aws ec2 describe-vpc-endpoint-services --service-name com.amazonaws.us-east-1.deviceadvisor.iot
```
次のサービス名 AWS IoT Core を使用して、 の VPC エンドポイントを作成できます。
+ com.amazonaws.*region*.deviceadvisor.iot
デフォルトでは、エンドポイントのプライベート DNS は有効になっています。これにより、デフォルトのテストエンドポイントの使用がプライベートサブネット内にとどまることが保証されます。アカウントまたはデバイスレベルのエンドポイントを取得するには、 コンソール AWS CLI または AWS SDK を使用します。例えば、パブリックサブネット内またはパブリックインターネット上で [get-endpoint](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iotdeviceadvisor/get-endpoint.html) を実行する場合、エンドポイントを取得し、それを使用して Device Advisor に接続できます。詳細については、「Amazon VPC ユーザーガイド**」の「[インターフェイスエンドポイントを介したサービスへのアクセス](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint)」を参照してください。
MQTT クライアントを VPC エンドポイントインターフェイスに接続するために、 AWS PrivateLink サービスは VPC にアタッチされたプライベートホストゾーンに DNS レコードを作成します。これらの DNS レコードは、 AWS IoT デバイスのリクエストを VPC エンドポイントに転送します。
## VPC エンドポイント AWS IoT Core Device Advisor を介した へのアクセスの制御
VPC [条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を使用して、VPC エンドポイントを介してのみデバイスアクセスを制限 AWS IoT Core Device Advisor し、アクセスを許可できます。 は、次の VPC 関連のコンテキストキー AWS IoT Core をサポートしています。
+ [SourceVpc](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcevpc)
+ [SourceVpce](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcevpce)
+ [VPCSourcelp](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-vpcsourceip)
**注記**
AWS IoT Core Device Advisor は現在、[VPC エンドポイントポリシー](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html#vpc-endpoint-policies)をサポートしていません。
次のポリシーは、モノの名前に一致するクライアント ID AWS IoT Core Device Advisor を使用して に接続するアクセス許可を付与します。また、モノ名のプレフィックスが付いた任意のトピックにも公開されます。このポリシーは、デバイスが特定の VPC エンドポイント ID を持つ VPC エンドポイントに接続することを条件としています。このポリシーでは、パブリック AWS IoT Core Device Advisor テストエンドポイントへの接続試行が拒否されます。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iot:Connect"
],
"Resource": [
"arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"
],
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-1a2b3c4d"
}
}
},
{
"Effect": "Allow",
"Action": [
"iot:Publish"
],
"Resource": [
"arn:aws:iot:us-east-1:123456789012:topic/${iot:Connection.Thing.ThingName}/*"
]
}
]
}
```
# Device Advisor テストケース
Device Advisor は、6 つのカテゴリの事前構築済みテストを提供します。
+ [TLS](device-advisor-tests-tls.md)
+ [MQTT](device-advisor-tests-mqtt.md)
+ [シャドウ](device-advisor-tests-shadow.md)
+ [ジョブの実行](device-advisor-tests-job-execution.md)
+ [アクセス許可とポリシー](device-advisor-tests-permissions-policies.md)
+ [長期テスト](device-advisor-tests-long-duration.md)
## Device Qualification Program の対象となる AWS Device Advisor テストケース。
お使いのデバイスが認定を受けるには、[AWS デバイス認定プログラム](https://aws.amazon.com/partners/programs/dqp/)に従って、次のテストに合格する必要があります。
**注記**
これは資格試験の改訂されたリストです。
+ [TLS Connect](device-advisor-tests-tls.md#TLS_Connect) (「TLSConnect」)
+ [TLS 不正なサブジェクト名サーバー証明書](device-advisor-tests-tls.md#TLS_Incorrect_Subject_Name) (「サブジェクトの共通名 (CN)/サブジェクトの別名 (SAN) が正しくありません」)
+ [TLS 非セキュアサーバー証明書](device-advisor-tests-tls.md#TLS_Unsecure_Server_Cert) (「認識された CA によって署名されていません」)
+ [暗号スイートの AWS IoT TLS デバイスサポート](device-advisor-tests-tls.md#TLS_DeviceSupport_For_IOT) ( AWS IoT 「推奨暗号スイートの TLS デバイスサポート」)
+ [TLS が受信する最大サイズのフラグメント](device-advisor-tests-tls.md#TLS_MaximumSize) (「TLS が受信する最大サイズのフラグメント」)
+ [TLS 期限切れサーバー証明書](device-advisor-tests-tls.md#TLS_Expired_Server_Cert) (「期限切れサーバー証明書」)
+ [TLS 大きなサイズのサーバー証明書](device-advisor-tests-tls.md#TLS_LargeServerCert) (「TLS 大きなサイズのサーバー証明書」)
+ [MQTT Connect](device-advisor-tests-mqtt.md#MQTT_Connect) (「デバイスが CONNECT を AWS IoT Core (ハッピーケース) に送信する」)
+ [MQTT Subscribe](device-advisor-tests-mqtt.md#MQTT_Subscribe) (「Can Subscribe (Happy Case)」)
+ [MQTT Publish](device-advisor-tests-mqtt.md#MQTT_Publish) (「QoS0 (Happy Case)」)
+ [MQTT 接続ジッター再試行](device-advisor-tests-mqtt.md#MQTT_ConnectJitterBackoff) (「ジッターバックオフを使用したデバイス接続再試行 - CONNACK 応答なし」)
# TLS
これらのテストを使用して、デバイスと 間のトランスポートレイヤーセキュリティプロトコル (TLS) AWS IoT が安全かどうかを判断します。
**注記**
Device Advisor が TLS1.3 をサポートするようになりました。
## Happy Path
**TLS Connect**
テスト対象のデバイスが TLS ハンドシェイクを完了できるかどうかを検証します AWS IoT。このテストでは、クライアントデバイスの MQTT 実装は検証されません。
**Example API テストケースの定義:**
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。最良の結果を得るには、タイムアウト値 を 2 分とすることをお勧めします。
```
"tests":[
{
"name":"my_tls_connect_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Connect",
"version":"0.0.0"
}
}
]
```
**Example テストケースの出力:**
+ **合格** — テスト対象のデバイスが TLS ハンドシェイクを完了しました AWS IoT。
+ **警告付きで合格** — テスト対象のデバイスは TLS ハンドシェイクを完了しましたが AWS IoT、デバイスまたは からの TLS 警告メッセージがありました AWS IoT。
+ **失敗** — ハンドシェイクエラー AWS IoT により、テスト対象のデバイスが との TLS ハンドシェイクを完了できませんでした。
**TLS が受信する最大サイズのフラグメント**
このテストケースは、デバイスが TLS 最大サイズのフラグメントを受信して処理できることを検証します。大きなペイロードを受信するには、テストデバイスが QoS 1 で事前設定されたトピックをサブスクライブする必要があります。`${payload}` 設定を使用して、ペイロードをカスタマイズできます。
**Example API テストケースの定義:**
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。最良の結果を得るには、タイムアウト値 を 2 分とすることをお勧めします。
```
"tests":[
{
"name":"TLS Receive Maximum Size Fragments",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
"PAYLOAD_FORMAT":"{"message":"${payload}"}", // A string with a placeholder ${payload}, or leave it empty to receive a plain string.
"TRIGGER_TOPIC": "test_1" // A topic to which a device will subscribe, and to which a test case will publish a large payload.
},
"test":{
"id":"TLS_Receive_Maximum_Size_Fragments",
"version":"0.0.0"
}
}
]
```
## 暗号スイート
** AWS IoT 推奨される暗号スイートの TLS デバイスサポート**
テスト対象デバイスからの TLS Client Hello メッセージの暗号スイートに、推奨される [AWS IoT 暗号スイート](transport-security.md)が含まれていることを検証します。デバイスでサポートされている暗号スイートに関するさらなる洞察を提供します。
**Example API テストケースの定義:**
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。
```
"tests":[
{
"name":"my_tls_support_aws_iot_cipher_suites_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"TLS_Support_AWS_IoT_Cipher_Suites",
"version":"0.0.0"
}
}
]
```
**Example テストケースの出力:**
+ **合格** — テスト対象のデバイス暗号スイートには、推奨される暗号スイートが少なくとも 1 AWS IoT つ含まれており、サポートされていない暗号スイートは含まれていません。
+ **警告付きで合格** – デバイス暗号スイートには少なくとも 1 つの AWS IoT 暗号スイートが含まれていますが、次の点に注意してください。
1. 推奨される暗号スイートは含まれていません
1. これには、 でサポートされていない暗号スイートが含まれています AWS IoT。
サポートされていない暗号スイートが安全であることを確認することをお勧めします。
+ **失敗** — テスト対象のデバイス暗号スイートには、 AWS IoT サポートされている暗号スイートは含まれていません。
## より大きなサイズのサーバー証明書
**TLS 大きなサイズのサーバー証明書**
お使いのデバイスが、より大きなサイズのサーバー証明書を受け取って処理する場合に、 AWS IoT との TLS ハンドシェイクを完了できるかどうかを検証します。このテストで使用されるサーバー証明書のサイズ (バイト単位) は、**TLS Connect** テストケースおよび IoT Core で現在使用されているサイズよりも大きく、20 倍です。このテストケースでは、 は TLS のデバイスのバッファスペースを AWS IoT テストします。バッファスペースが十分に大きい場合、TLS ハンドシェイクはエラーなしで枯渇します。このテストでは、デバイスの MQTT 実装は検証されません。テストケースは、TLS ハンドシェイクプロセスが完了した後に終了します。
**Example API テストケースの定義:**
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。最良の結果を得るには、タイムアウト値 を 2 分とすることをお勧めします。このテストケースが失敗し、**TLS Connect** テストケースが成功した場合、お使いのデバイスの TLS 用バッファ領域の制限を増やすことをお勧めします。バッファ領域の制限を増やすと、サイズが大きくなった場合にデバイスがより大きなサイズのサーバー証明書を処理できるようになります。
```
"tests":[
{
"name":"my_tls_large_size_server_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"TLS_Large_Size_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example テストケースの出力:**
+ **合格** – テスト対象のデバイスが AWS IoTとの TLS ハンドシェイクを完了しました。
+ **警告付きで合格** — テスト対象のデバイスは TLS ハンドシェイクを完了しましたが AWS IoT、デバイスまたは からの TLS 警告メッセージがあります AWS IoT。
+ **失敗** — ハンドシェイクプロセス中にエラーが発生した AWS IoT ため、テスト対象のデバイスが との TLS ハンドシェイクを完了できませんでした。
## TLS 非セキュアサーバー証明書
**認識された CA によって署名されていません**
ATS CA からの有効な署名がないサーバー証明書が提示された場合にテスト対象のデバイスが接続を閉じることを検証します。デバイスは、有効な証明書を提示するエンドポイントにのみ接続する必要があります。
**Example API テストケースの定義:**
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。
```
"tests":[
{
"name":"my_tls_unsecure_server_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Unsecure_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example テストケースの出力:**
+ **合格** – テスト対象のデバイスは接続を閉じました。
+ **失敗** — テスト対象のデバイスが TLS ハンドシェイクを完了しました AWS IoT。
**TLS 不正なサブジェクト名サーバー証明書/不正なサブジェクトの共通名 (CN)/サブジェクトの別名 (SAN)**
リクエストされたものとは異なるドメイン名のサーバー証明書が提示された場合にテスト対象のデバイスが接続を閉じることを検証します。
**Example API テストケースの定義:**
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。
```
"tests":[
{
"name":"my_tls_incorrect_subject_name_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"TLS_Incorrect_Subject_Name_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example テストケースの出力:**
+ **合格** – テスト対象のデバイスは接続を閉じました。
+ **失敗** — テスト対象のデバイスが TLS ハンドシェイクを完了しました AWS IoT。
## TLS 期限切れサーバー証明書
**期限切れサーバー証明書**
期限切れサーバー証明書が提示された場合にテスト対象のデバイスが接続を閉じることを検証します。
**Example API テストケースの定義:**
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。
```
"tests":[
{
"name":"my_tls_expired_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Expired_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example テストケースの出力:**
+ **合格** — テスト対象のデバイスは TLS ハンドシェイクの完了を拒否します AWS IoT。デバイスは、接続を閉じる前に TLS アラートメッセージを送信します。
+ **警告付きで合格** – テスト対象のデバイスが AWS IoTとの TLS ハンドシェイクを完了することを拒否します。ただし、接続を閉じる前に TLS 警告メッセージは送信されません。
+ **失敗** — テスト対象のデバイスは TLS ハンドシェイクを完了します AWS IoT。
# MQTT
## CONNECT、DISCONNECT、および RECONNECT
**「デバイスが CONNECT を AWS IoT Core (ハッピーケース) に送信する」**
テスト対象のデバイスが CONNECT リクエストを送信することを検証します。
*API テストケースの定義:*
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。
```
"tests":[
{
"name":"my_mqtt_connect_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"MQTT_Connect",
"version":"0.0.0"
}
}
]
```
**「デバイスは、QoS1 のための任意のトピックに PUBACK を返すことができます」**
このテストケースでは、デバイス (クライアント) が QoS1 でトピックにサブスクライブした後にブローカーから発行メッセージを受信した場合、PUBACK メッセージを返すことができるかどうかをチェックします。
このテストケースでは、ペイロードコンテンツとペイロードサイズを設定できます。ペイロードサイズが設定されている場合、Device Advisor はペイロードコンテンツの値を上書きし、事前定義済みのペイロードを目的のサイズでデバイスに送信します。ペイロードサイズは 0 から 128 までの値で、128 KB を超えることはできません。[AWS IoT Core メッセージブローカーとプロトコルの制限とクォータ](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits)のページで示されているように、 AWS IoT Core では、128 KB を超えるリクエストの発行および接続は拒否されます。
*API テストケースの定義:*
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 2 分を推奨します。`PAYLOAD_SIZE` は 0～128 KB の値に設定できます。ペイロードサイズを定義すると、Device Advisor が指定されたサイズの事前定義されたペイロードをデバイスに送り返すため、ペイロードコンテンツが上書きされます。
```
"tests":[
{
"name":"my_mqtt_client_puback_qos1",
"configuration": {
// optional:"TRIGGER_TOPIC": "myTopic",
"EXECUTION_TIMEOUT":"300", // in seconds
"PAYLOAD_FOR_PUBLISH_VALIDATION":"custom payload",
"PAYLOAD_SIZE":"100" // in kilobytes
},
"test": {
"id": "MQTT_Client_Puback_QoS1",
"version": "0.0.0"
}
}
]
```
**「ジッターバックオフを使用したデバイス接続再試行 - CONNACK 応答なし」**
ブローカーに少なくとも 5 回再接続するときに、テスト対象のデバイスが適切なジッターバックオフを使用することを検証します。ブローカーは、テスト対象のデバイスの CONNECT リクエストのタイムスタンプを記録し、パケット検証を実行し、テスト対象デバイスに CONNACK を送信せずに一時停止し、テスト対象デバイスがリクエストを再送信するのを待機します。6 回目の接続試行はパススルーでき、CONNACK はテスト対象のデバイスにフローバックできます。
上記のプロセスが再び実行されます。合計で、このテストケースでは、デバイスが合計で少なくとも 12 回接続する必要があります。収集されたタイムスタンプは、ジッターバックオフがテスト対象デバイスによって使用されていることを検証するために使用されます。テスト対象のデバイスにエクスポネンシャルバックオフ遅延のみがある場合、警告付きでこのテストケースに合格します。
このテストケースに合格するには、テスト対象のデバイスに[エクスポネンシャルバックオフとジッター](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/)メカニズムを実装することをお勧めします。
*API テストケースの定義:*
`EXECUTION_TIMEOUT` のデフォルト値は 5 分です。タイムアウト値は 4 分であることを推奨します。
```
"tests":[
{
"name":"my_mqtt_jitter_backoff_retries_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"MQTT_Connect_Jitter_Backoff_Retries",
"version":"0.0.0"
}
}
]
```
**「エクスポネンシャルバックオフを使用したデバイス接続再試行 - CONNACK 応答なし」**
ブローカーに少なくとも 5 回再接続するときに、テスト対象のデバイスが適切なエクスポネンシャルバックオフを使用することを検証します。ブローカーは、テスト対象のデバイスの CONNECT リクエストのタイムスタンプを記録し、パケット検証を実行し、クライアントデバイスに CONNACK を送信せずに一時停止し、テスト対象デバイスがリクエストを再送信するのを待機します。収集されたタイムスタンプは、エクスポネンシャルバックオフがテスト対象のデバイスによって使用されていることを検証するために使用されます。
このテストケースに合格するには、テスト対象のデバイスに[エクスポネンシャルバックオフとジッター](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/)メカニズムを実装することをお勧めします。
*API テストケースの定義:*
`EXECUTION_TIMEOUT` のデフォルト値は 5 分です。タイムアウト値は 4 分であることを推奨します。
```
"tests":[
{
"name":"my_mqtt_exponential_backoff_retries_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"600", // in seconds
},
"test":{
"id":"MQTT_Connect_Exponential_Backoff_Retries",
"version":"0.0.0"
}
}
]
```
**「デバイスはジッターバックオフを使用して再接続します-サーバーの切断後」**
テスト対象のデバイスが、サーバーから切断された後の再接続時に必要なジッターとバックオフを使用しているかどうかを検証します。Device Advisor が、デバイスをサーバーから少なくとも 5 回切断し、MQTT 再接続のためにデバイスの動作を監視します。Device Advisor は、テスト対象デバイスの CONNECT リクエストのタイムスタンプをログに記録し、パケット検証を実行し、クライアントデバイスに CONNACK を送信せずに一時停止して、テスト対象デバイスがリクエストを再送信するのを待ちます。収集されたタイムスタンプは、テスト対象デバイスが再接続中にジッターとバックオフを使用することを検証するために使用されます。テスト対象のデバイスがエクスポネンシャルバックオフのみを使用している、または適切なジッターバックオフメカニズムを実装していない場合は、警告付きでこのテストケースに合格します。テスト対象のデバイスが、線形バックオフまたは固定バックオフメカニズムを実装している場合、テストは失敗します。
このテストケースに合格するには、テスト対象のデバイスに、[エクスポネンシャルバックオフとジッター](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/)メカニズムを実装することをお勧めします。
*API テストケースの定義:*
`EXECUTION_TIMEOUT` のデフォルト値は 5 分です。タイムアウト値は 4 分であることを推奨します。
バックオフを検証する再接続試行回数は、`RECONNECTION_ATTEMPTS` を指定する事によって変更できます。その数は 5～10 の間である必要があります。デフォルト値は 5 です。
```
"tests":[
{
"name":"my_mqtt_reconnect_backoff_retries_on_server_disconnect",
"configuration":{
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"RECONNECTION_ATTEMPTS": 5
},
"test":{
"id":"MQTT_Reconnect_Backoff_Retries_On_Server_Disconnect",
"version":"0.0.0"
}
}
]
```
**「ジッターバックオフを使用したデバイスの再接続 - 不安定な接続時」**
不安定な接続での再接続中に、テスト対象のデバイスが必要なジッターとバックオフを使用するかどうかを検証します。Device Advisor は、5 回接続に成功するとサーバーからデバイスを切断し、MQTT 再接続のためにデバイスの動作を監視します。Device Advisor は、テスト対象デバイスの CONNECT リクエストのタイムスタンプをログに記録し、パケット検証を実行し、CONNACK を返し、切断し、切断のタイムスタンプをログに記録し、テスト対象デバイスがリクエストを再送信するのを待ちます。収集されたタイムスタンプは、テスト対象デバイスが、接続は成功したが不安定になった後の再接続中にジッターとバックオフを使用していることを検証するために使用されます。テスト対象のデバイスがエクスポネンシャルバックオフのみを使用している、または適切なジッターバックオフメカニズムを実装していない場合は、警告付きでこのテストケースに合格します。テスト対象のデバイスが、線形バックオフまたは固定バックオフメカニズムを実装している場合、テストは失敗します。
このテストケースに合格するには、テスト対象のデバイスに、[エクスポネンシャルバックオフとジッター](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/)メカニズムを実装することをお勧めします。
*API テストケースの定義:*
`EXECUTION_TIMEOUT` のデフォルト値は 5 分です。タイムアウト値は 4 分であることを推奨します。
バックオフを検証する再接続試行回数は、`RECONNECTION_ATTEMPTS` を指定する事によって変更できます。その数は 5～10 の間である必要があります。デフォルト値は 5 です。
```
"tests":[
{
"name":"my_mqtt_reconnect_backoff_retries_on_unstable_connection",
"configuration":{
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"RECONNECTION_ATTEMPTS": 5
},
"test":{
"id":"MQTT_Reconnect_Backoff_Retries_On_Unstable_Connection",
"version":"0.0.0"
}
}
]
```
## 発行
**「QoS0 (Happy Case)」**
テスト対象デバイスが QoS0 または QoS1 でメッセージを発行することを検証します。テスト設定でトピック値とペイロードを指定することで、メッセージとペイロードのトピックを検証することもできます。
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。
```
"tests":[
{
"name":"my_mqtt_publish_test",
"configuration":{
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION",
"PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION",
},
"test":{
"id":"MQTT_Publish",
"version":"0.0.0"
}
}
]
```
**「QoS1 発行の再試行 - PUBACK なし」**
ブローカーが PUBACK を送信しない場合、テスト対象のデバイスが QoS1 で送信されたメッセージを再発行することを検証します。また、テスト設定でこのトピックを指定することで、メッセージのトピックを検証することもできます。メッセージを再発行する前に、クライアントデバイスを切断しないでください。このテストでは、再発行されたメッセージが、元のメッセージと同じパケット ID を持つことも検証されます。テスト実行中にデバイスが接続を失って再接続した場合、テストケースは失敗することなくリセットされます。そのため、デバイスはテストケースのステップを再実行する必要があります。
*API テストケースの定義:*
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。少なくとも 4 分間お勧めします。
```
"tests":[
{
"name":"my_mqtt_publish_retry_test",
"configuration":{
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION",
"PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION",
},
"test":{
"id":"MQTT_Publish_Retry_No_Puback",
"version":"0.0.0"
}
}
]
```
**「保持されたメッセージの発行」**
テスト対象のデバイスが、`retainFlag` が true に設定されたメッセージを発行することを検証します。テスト設定でトピック値とペイロードを設定することで、メッセージのトピックとペイロードを検証できます。PUBLISH パケット内で送信された `retainFlag` が true に設定されていない場合、テストケースは失敗します。
*API テストケースの定義:*
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。このテストケースを実行するには、[デバイスロール](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-iam-role)に `iot:RetainPublish` アクションを追加します。
```
"tests":[
{
"name":"my_mqtt_publish_retained_messages_test",
"configuration":{
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"TOPIC_FOR_PUBLISH_RETAINED_VALIDATION": "my_TOPIC_FOR_PUBLISH_RETAINED_VALIDATION",
"PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION",
},
"test":{
"id":"MQTT_Publish_Retained_Messages",
"version":"0.0.0"
}
}
]
```
**「ユーザープロパティを使用して発行」**
テスト対象デバイスが正しいユーザープロパティでメッセージを発行することを検証します。テスト設定で名前と値のペアを設定することで、ユーザープロパティを検証できます。ユーザープロパティが指定されていないか、一致しない場合、テストケースは失敗します。
*API テストケースの定義:*
これは MQTT5 のみのテストケースです。
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。
```
"tests":[
{
"name":"my_mqtt_user_property_test",
"test":{
"USER_PROPERTIES": [
{"name": "name1", "value":"value1"},
{"name": "name2", "value":"value2"}
],
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"MQTT_Publish_User_Property",
"version":"0.0.0"
}
}
]
```
## Subscribe
**「Can Subscribe (Happy Case)」**
テスト対象のデバイスが MQTT トピックにサブスクライブしていることを検証します。テスト設定でこのトピックを指定することで、テスト対象のデバイスがサブスクライブするトピックを検証することもできます。
*API テストケースの定義:*
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。
```
"tests":[
{
"name":"my_mqtt_subscribe_test",
"configuration":{
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["my_TOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"]
},
"test":{
"id":"MQTT_Subscribe",
"version":"0.0.0"
}
}
]
```
**「サブスクライブ再試行 - SUBACK なし」**
テスト対象のデバイスが MQTT トピックへの失敗したサブスクリプションを再試行することを検証します。サーバーは待機し、SUBACK を送信しません。クライアントデバイスがサブスクリプションを再試行しない場合、テストは失敗します。クライアントデバイスは、失敗したサブスクリプションを同じパケット ID で再試行する必要があります。テスト設定でこのトピックを指定することで、テスト対象のデバイスがサブスクライブするトピックを検証することもできます。テスト実行中にデバイスが接続を失って再接続した場合、テストケースは失敗することなくリセットされます。そのため、デバイスはテストケースのステップを再実行する必要があります。
*API テストケースの定義:*
`EXECUTION_TIMEOUT` のデフォルト値は 5 分です。タイムアウト値は 4 分であることを推奨します。
```
"tests":[
{
"name":"my_mqtt_subscribe_retry_test",
"configuration":{
"EXECUTION_TIMEOUT":"300", // in seconds
// optional:
"TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["myTOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"]
},
"test":{
"id":"MQTT_Subscribe_Retry_No_Suback",
"version":"0.0.0"
}
}
]
```
## Keep-Alive
**「Mqtt No Ack PingResp」**
このテストケースでは、テスト対象のデバイスが ping 応答を受信しないときに切断されるかどうかを検証します。このテストケースの一環として、Device Advisor は発行、サブスクライブ、および ping リクエスト AWS IoT Core のために から送信されたレスポンスをブロックします。テスト対象のデバイスが、MQTT 接続を切断しているかどうかも検証します。
*API テストケースの定義:*
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウトは `keepAliveTime` 値の 1.5 倍超とすることをお勧めします。
このテストでは、最大値 `keepAliveTime` は 230 秒以下にする必要があります。
```
"tests":[
{
"name":"Mqtt No Ack PingResp",
"configuration":
//optional:
"EXECUTION_TIMEOUT":"306", // in seconds
},
"test":{
"id":"MQTT_No_Ack_PingResp",
"version":"0.0.0"
}
}
]
```
## 永続セッション
**「永続セッション (Happy Case)」**
このテストケースは、永続セッションから切断されたときのデバイスの動作を検証します。テストケースは、デバイスの再接続、明示的な再サブスクライブなしでのトリガートピックへのサブスクライブの再開、トピックに保存済みのメッセージの受信、および永続セッション中に期待どおりの動作が可能かどうかをチェックします。このテストケースに合格すると、クライアントデバイスが予想される方法で AWS IoT Core ブローカーとの永続的セッションを維持できることを示します。永 AWS IoT 続セッションの詳細については、[「MQTT 永続セッションの使用](https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions)」を参照してください。
このテストケースでは、クライアントデバイスは、クリーンセッションのフラグを false に設定して AWS IoT Core で接続し、トリガートピックにサブスクライブすることが予期されます。サブスクリプションが成功すると、デバイスは AWS IoT Core Device Advisor によって切断されます。デバイスが切断状態の間、そのトピックに QoS 1 メッセージペイロードが保存されます。その後、Device Advisor は、クライアントデバイスがテストエンドポイントとの再接続を許可します。この時点で、クライアントデバイスは、永続セッションが存在するため、追加の SUBSCRIBE パケットを送信せずに、トピックサブスクリプションを再開し、ブローカーから QoS 1 メッセージを受信することが予期されます。再接続後、クライアントデバイスが追加の SUBSCRIBE パケットを送信することでトリガートピックに再サブスクライブした場合、および/またはクライアントがトリガートピックから保存済みメッセージを受信できなかった場合、テストケースは失敗します。
*API テストケースの定義:*
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 4 分以上にすることを推奨します。最初の接続で、クライアントデバイスは、以前サブスクライブされていなかった `TRIGGER_TOPIC` に明示的にサブスクライブする必要があります。テストケースに合格するには、クライアントデバイスが QoS 1 で `TRIGGER_TOPIC` に正常にサブスクライブする必要があります。再接続後、クライアントデバイスは、アクティブな永続セッションがあると認識することが予期されます。そのため、トリガートピックによって送信された保存済みメッセージを受け入れ、その特定のメッセージに対して PUBACK を返します。
```
"tests":[
{
"name":"my_mqtt_persistent_session_happy_case",
"configuration":{
//required:
"TRIGGER_TOPIC": "myTrigger/topic",
// optional:
// if Payload not provided, a string will be stored in the trigger topic to be sent back to the client device
"PAYLOAD": "The message which should be received from AWS IoT Broker after re-connecting to a persistent session from the specified trigger topic.",
"EXECUTION_TIMEOUT":"300" // in seconds
},
"test":{
"id":"MQTT_Persistent_Session_Happy_Case",
"version":"0.0.0"
}
}
]
```
**「永続セッション - セッションの有効期限」**
このテストケースは、切断されたデバイスが期限切れの永続セッションに再接続するときのデバイスの動作を検証するのに役立ちます。セッションが期限切れになると、デバイスは新しい SUBSCRIBE パケットを明示的に送信して、以前にサブスクライブしたトピックに再サブスクライブすることが予想されます。
最初の接続中、テストデバイスは AWS IoT ブローカーに接続することを想定しています。これは、永続セッションを開始するために`CleanSession`フラグが false に設定されているためです。その後、デバイスはトリガートピックをサブスクライブする必要があります。その後、サブスクリプションが成功し、永続セッションが開始されると、デバイスは AWS IoT Core Device Advisor によって切断されます。切断後、 AWS IoT Core Device Advisor はテストデバイスがテストエンドポイントに再接続できるようにします。この時点で、テストデバイスが別の CONNECT パケットを送信すると、 AWS IoT Core Device Advisor は永続セッションの有効期限が切れていることを示す CONNACK パケットを返します。テストデバイスはこのパケットを適切に解釈する必要があり、永続セッションが終了すると、同じトリガートピックに再サブスクライブすることが予期されます。テストデバイスがトピックトリガーに再サブスクライブしない場合、テストケースは失敗します。テストに合格するには、デバイスは永続セッションが終了したことを認識し、2 番目の接続で同じトリガートピックに対して新しい SUBSCRIBE パケットを送り返す必要があります。
テストデバイスでこのテストケースに合格した場合、永続セッションの期限が切れる際に、デバイスが予期された方法で再接続を処理できることを示しています。
*API テストケースの定義:*
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 4 分以上にすることを推奨します。クライアントデバイスは、以前サブスクライブされていなかった `TRIGGER_TOPIC` に明示的にサブスクライブする必要があります。テストケースに合格するには、テストデバイスで `CleanSession` フラグを false に設定して CONNECT パケットを送信し、QoS 1 でトリガートピックに正常にサブスクライブする必要があります。接続が成功すると、 AWS IoT Core Device Advisor はデバイスを切断します。切断後、 AWS IoT Core Device Advisor はデバイスの再接続を許可し、 AWS IoT Core Device Advisor が永続セッションを終了する`TRIGGER_TOPIC`ため、デバイスは同じ に再サブスクライブすることが期待されます。
```
"tests":[
{
"name":"my_expired_persistent_session_test",
"configuration":{
//required:
"TRIGGER_TOPIC": "myTrigger/topic",
// optional:
"EXECUTION_TIMEOUT":"300" // in seconds
},
"test":{
"id":"MQTT_Expired_Persistent_Session",
"version":"0.0.0"
}
}
]
```
# シャドウ
これらのテストを使用して、テスト対象のデバイスが AWS IoT Device Shadow サービスを正しく使用していることを確認します。詳細については、「[AWS IoT Device Shadow サービス](iot-device-shadows.md)」を参照してください。これらのテストケースがテストスイートで設定されている場合は、スイートの実行を開始するときにモノを指定する必要があります。
現時点では、**MQTT over WebSocket** はサポートされていません。
## 発行
***「デバイスは接続後に状態を発行します (Happy case)」***
デバイスが接続後にその状態を発行できるかどうかを検証します AWS IoT Core
*API テストケースの定義:*
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。
```
"tests":[
{
"name":"my_shadow_publish_reported_state",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"SHADOW_NAME": "SHADOW_NAME",
"REPORTED_STATE": {
"STATE_ATTRIBUTE": "STATE_VALUE"
}
},
"test":{
"id":"Shadow_Publish_Reported_State",
"version":"0.0.0"
}
}
]
```
`REPORTED_STATE` は、接続後に、デバイスの正確なシャドウ状態をさらに検証するために提供できます。デフォルトでは、このテストケースはデバイスの発行状態を検証します。
`SHADOW_NAME` が指定されていない場合、テストケースはデフォルトで名前なし (クラシック) シャドウタイプのトピックプレフィックスに発行されたメッセージを検索します。デバイスで名前の付いたシャドウタイプを使用する場合は、シャドウの名前を指定します。詳細については、[デバイスでのシャドウの使用](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html)を参照してください。
## 更新
***「デバイスは報告された状態を望ましい状態に更新します (Happy case)」***
デバイスが受信したすべての更新メッセージを読み取ったかどうかを検証し、デバイスの状態を同期して、必要な状態のプロパティと一致させます。デバイスは、同期後に最新の報告された状態を発行します。テストを実行する前に、デバイスに既にシャドウが存在する場合は、テストケースに設定された目的の状態と、報告された既存の状態がまだ一致していないことを確認します。Device Advisor から送信されたシャドウ更新メッセージは、シャドウドキュメントの **ClientToken** フィールドが `DeviceAdvisorShadowTestCaseSetup` になるのを確認することで識別できます。
*API テストケースの定義:*
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。
```
"tests":[
{
"name":"my_shadow_update_reported_state",
"configuration": {
"DESIRED_STATE": {
"STATE_ATTRIBUTE": "STATE_VALUE"
},
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"SHADOW_NAME": "SHADOW_NAME"
},
"test":{
"id":"Shadow_Update_Reported_State",
"version":"0.0.0"
}
}
]
```
`DESIRED_STATE` には、少なくとも 1 つの属性と関連付けられた値が必要です。
`SHADOW_NAME` が指定されていない場合、テストケースはデフォルトで [Unnamed] (無名) (クラシック) シャドウタイプのトピックプレフィックスに発行されたメッセージを検索します。デバイスで名前の付いたシャドウタイプを使用する場合は、シャドウの名前を指定します。詳細については、[デバイスでのシャドウの使用](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html)を参照してください。
# ジョブの実行
**「デバイスはジョブの実行を完了できます」**
このテストケースは、デバイスが AWS IoT Jobs を使用して更新を受信できるかどうかを検証し、成功した更新のステータスを発行するのに役立ちます。 AWS IoT ジョブの詳細については、[「 ジョブ](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html)」を参照してください。
このテストケースを正常に実行するには、[[デバイスロール]](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-iam-role) を付与する必要がある予約済みの AWS トピックが 2 つあります。ジョブアクティビティ関連のメッセージをサブスクライブするには、**notify** および **notify-next** トピックを使用します。デバイスロールは、次のトピックで PUBLISH アクションを付与する必要があります。
+ \$1aws/things/**thingName**/jobs/**jobId**/get
+ \$1aws/things/**thingName**/jobs/**jobId**/update
次のトピックで SUBSCRIBE アクションと RECEIVE アクションを付与することをお勧めします。
+ \$1aws/things/**thingName**/jobs/get/accepted
+ \$1aws/things/**thingName**/jobs/**jobId**/get/rejected
+ \$1aws/things/**thingName**/jobs/**jobId**/update/accepted
+ \$1aws/things/**thingName**/jobs/**jobId**/update/rejected
次のトピックについては、SUBSCRIBE アクションを許可することをお勧めします。
+ \$1aws/things/**thingName**/jobs/notify-next
これらの予約トピックの詳細については、「[AWS IoT ジョブ](https://docs.aws.amazon.com/iot/latest/developerguide/reserved-topics.html#reserved-topics-job)」で予約トピックについて参照してください。
現時点では、**MQTT over WebSocket** はサポートされていません。
*API テストケースの定義:*
`EXECUTION_TIMEOUT`のデフォルト値は 5 分です。タイムアウト値は 3 分とすることを推奨します。提供された AWS IoT ジョブドキュメントまたはソースに応じて、タイムアウト値を調整します (たとえば、ジョブの実行に時間がかかる場合は、テストケースのより長いタイムアウト値を定義します）。テストを実行するには、有効な AWS IoT ジョブドキュメントまたは既存のジョブ ID が必要です。 AWS IoT ジョブドキュメントは、JSON ドキュメントまたは S3 リンクとして提供できます。ジョブドキュメントが提供されている場合、ジョブ ID の提供は任意です。ジョブ ID が指定されている場合、Device Advisor はユーザーに代わって AWS IoT ジョブを作成するときにその ID を使用します。ジョブドキュメントが提供されていない場合は、テストケースを実行しているのと同じリージョンにある既存の ID を提供できます。この場合、Device Advisor はテストケースの実行中にその AWS IoT ジョブを使用します。
```
"tests": [
{
"name":"my_job_execution",
"configuration": {
// optional:
// Test case will create a job task by using either JOB_DOCUMENT or JOB_DOCUMENT_SOURCE.
// If you manage the job task on your own, leave it empty and provide the JOB_JOBID (self-managed job task).
// JOB_DOCUMENT is a JSON formatted string
"JOB_DOCUMENT": "{
\"operation\":\"reboot\",
\"files\" : {
\"fileName\" : \"install.py\",
\"url\" : \"${aws:iot:s3-presigned-url:https://s3.amazonaws.com/bucket-name/key}\"
}
}",
// JOB_DOCUMENT_SOURCE is an S3 link to the job document. It will be used only if JOB_DOCUMENT is not provided.
"JOB_DOCUMENT_SOURCE": "https://s3.amazonaws.com/bucket-name/key",
// JOB_JOBID is mandatory, only if neither document nor document source is provided. (Test case needs to know the self-managed job task id).
"JOB_JOBID": "String",
// JOB_PRESIGN_ROLE_ARN is used for the presign Url, which will replace the placeholder in the JOB_DOCUMENT field
"JOB_PRESIGN_ROLE_ARN": "String",
// Presigned Url expiration time. It must be between 60 and 3600 seconds, with the default value being 3600.
"JOB_PRESIGN_EXPIRES_IN_SEC": "Long"
"EXECUTION_TIMEOUT": "300", // in seconds
},
"test": {
"id": "Job_Execution",
"version": "0.0.0"
}
}
]
```
ジョブドキュメントの作成および使用の詳細については、「[ジョブドキュメント](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html)」を参照してください。
# アクセス許可とポリシー
次のテストを使用して、デバイスの証明書にアタッチされたポリシーがスタンダードベストプラクティスに従っているかどうかを判断します。
現時点では、**MQTT over WebSocket** はサポートされていません。
**「デバイス証明書にアタッチされたポリシーにはワイルドカードが含まれていません」**
デバイスに関連付けられたアクセス許可ポリシーがベストプラクティスに従っており、必要以上のアクセス許可をデバイスに付与していないかどうかを検証します。
*API テストケースの定義:*
`EXECUTION_TIMEOUT` のデフォルト値は 1 分です。タイムアウトは 30 秒以上で設定することをお勧めします。
```
"tests":[
{
"name":"my_security_device_policies",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"60" // in seconds
},
"test": {
"id": "Security_Device_Policies",
"version": "0.0.0"
}
}
]
```
# 長期テスト
長期テストは、デバイスが長期間動作しているときの動作を監視する新しいテストスイートです。デバイスの特定の動作に焦点を当てた個別のテストを実行する場合と比較して、長期テストでは、デバイスの寿命全体にわたるさまざまな現実世界のシナリオにおけるデバイスの動作を調べます。Device Advisor は、可能な限り効率的な順序でテストを調整します。テストでは、テスト中のデバイスのパフォーマンスに関する有用なメトリクスを含む概要ログを含む結果とログが生成されます。
## MQTT 長期テストケース
MQTT の長期テストケースでは、MQTT Connect、サブスクライブ、発行、再接続などのハッピーケースシナリオでデバイスの動作が最初に確認されます。次に、デバイスが MQTT 再接続バックオフ、長期のサーバー切断、断続的な接続など、複数の複雑な障害シナリオに見舞われます。
## MQTT 長期テストケース実行フロー
MQTT 長期テストケースの実行には、次の 3 つのフェーズがあります。
![\[基本テストの実行、高度なテストの実行、追加の実行時間を示す「MQTT 長時間テストの実行」。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/mqtt-execution-flow.png)
### 基本テストの実行
このフェーズでは、テストケースは簡単なテストを並行して実行します。このテストでは、設定で選択したオペレーションがデバイスにあるかどうかを検証します。
基本テストのセットには、選択したオペレーションに基づいて次の内容が含まれる場合があります。
#### CONNECT
このシナリオでは、デバイスがブローカーと正常に接続できるかどうかを検証します。
![\[デバイスが CONNECT メッセージを送信し、ブローカーが正常なリターンコードを含む CONNACK メッセージで応答する基本的な接続フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/basic-connect.png)
#### 発行
このシナリオでは、デバイスがブローカーに対して正常に発行されているかどうかを検証します。
##### QoS 0
このテストケースは、QoS 0 での発行中に、デバイスがブローカーに `PUBLISH` メッセージを正常に送信するかどうかを検証します。このテストでは、デバイスが `PUBACK` メッセージを受信するまで待ちません。
![\[デバイスが QoS 0 レベルで PUBLISH メッセージを送信するの PUBLISH QoS 0 フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/Qos0.png)
##### QoS 1
このテストケースでは、デバイスは QoS 1 で 2 つの `PUBLISH` メッセージをブローカーに送信することが想定されます。最初の `PUBLISH` メッセージの後、ブローカーは最大 15 秒待ってから、応答します。デバイスは、15 秒以内に同じパケット ID を使用して元の `PUBLISH` メッセージを再試行する必要があります。その場合、ブローカーは `PUBACK` メッセージを返し、テストが検証します。デバイスが `PUBLISH` を再試行しない場合、元の `PUBACK` がデバイスに送信され、テストはシステムメッセージとともに**警告付きで合格**とマークされます。テスト実行中にデバイスが接続を失って再接続した場合、テストシナリオは失敗することなくリセットされます。そのため、デバイスはテストシナリオのステップを再実行する必要があります。
![\[デバイスが QoS 1 レベルとブローカーとの複数のインタラクションで PUBLISH メッセージを送信する PUBLISH QoS 1 フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/Qos1.png)
#### サブスクライブ
このシナリオでは、デバイスがブローカーに対して正常にサブスクライブしているかどうかを検証します。
##### QoS 0
このテストケースは、QoS 0 でのサブスクライブ中にデバイスがブローカーに `SUBSCRIBE` メッセージを正常に送信するかどうかを検証します。このテストでは、デバイスが SUBACK メッセージを受信するまで待ちません。
![\[デバイスが QoS 0 レベルの SUBSCRIBE メッセージを送信し、ブローカーが SUBACK メッセージと Success Maximum QoS 0 コードで応答する SUBSCRIBE QoS 0 フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/subscribe-Qos0.png)
##### QoS 1
このテストケースでは、デバイスは QoS 1 で 2 つの `SUBSCRIBE` メッセージをブローカーに送信することが想定されます。最初の `SUBSCRIBE` メッセージの後、ブローカーは最大 15 秒待ってから、応答します。デバイスは、15 秒以内に同じパケット ID を使用して元の `SUBSCRIBE` メッセージを再試行する必要があります。その場合、ブローカーは `SUBACK` メッセージを返し、テストが検証します。デバイスが `SUBSCRIBE` を再試行しない場合、元の `SUBACK` がデバイスに送信され、テストはシステムメッセージとともに**警告付きで合格**とマークされます。テスト実行中にデバイスが接続を失って再接続した場合、テストシナリオは失敗することなくリセットされます。そのため、デバイスはテストシナリオのステップを再実行する必要があります。
![\[デバイスが QoS 1 レベルとブローカーとの複数のインタラクションで SUBSCRIBE メッセージを送信する SUBSCRIBE QoS 1 フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/subscribe-Qos1.png)
#### 再接続
このシナリオでは、デバイスが正常に接続から切断された後に、デバイスがブローカーと正常に再接続するかどうかを検証します。テストスイート中にデバイスを複数回接続しても、Device Advisor はデバイスを切断しません。代わりに、テストを **[Pass]** (合格) としてマークします。
![\[DUT とブローカー間の RECONNECT フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/reconnect.png)
### 高度なテストの実行
このフェーズでは、テストケースはより複雑なテストを連続して実行し、デバイスがベストプラクティスに従っているかどうかを検証します。これらの高度なテストは選択可能で、必要ない場合はオプトアウトできます。それぞれの高度なテストには、シナリオの要求に応じて独自のタイムアウト値があります。
#### QoS 1 サブスクリプションで PUBACK を返す
**注記**
このシナリオは、デバイスが QoS 1 サブスクリプションを実行できる場合にのみ選択してください。
このシナリオでは、デバイスがトピックをサブスクライブしてブローカーから `PUBLISH` メッセージを受信した後に `PUBACK` メッセージを返すかどうかを検証します。
![\[DUT とブローカー間の RETURN PUBACK ON QoS 1 SUBSCTIPTION。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/return-puback.png)
#### 大きなペイロードを受け取る
**注記**
このシナリオは、デバイスが QoS 1 サブスクリプションを実行できる場合にのみ選択してください。
このシナリオでは、ペイロードが大きい QoS 1 トピックの `PUBLISH` メッセージをブローカーから受信した後、デバイスが `PUBACK` メッセージで応答するかどうかを検証します。想定されるペイロードの形式は、`LONG_PAYLOAD_FORMAT` オプションを使用して設定できます。
![\[DUT とブローカー間の RECEIVE LARGE PAYLOAD フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/large-payload.png)
#### 永続セッション
**注記**
このシナリオは、デバイスが QoS 1 サブスクリプションを実行でき、永続セッションを維持できる場合にのみ選択してください。
このシナリオは、永続セッションを維持する際のデバイスの動作を検証します。以下の条件が満たされると、テストは検証されます。
+ デバイスは、アクティブな QoS 1 サブスクリプションと永続セッションが有効になっているブローカーに接続します。
+ デバイスはセッション中にブローカーから正常に切断されます。
+ デバイスはブローカーに再接続し、そのトリガートピックへのサブスクリプションを再開します。これらのトピックを明示的に再サブスクライブする必要はありません。
+ デバイスは、サブスクライブされたトピックについてブローカーに保存されたメッセージを正常に受信し、想定どおりに動作します。
永 AWS IoT 続セッションの詳細については、[「MQTT 永続セッションの使用](https://docs.aws.amazon.com//iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions)」を参照してください。
![\[DUT とブローカー間の PERSISTENT SESSION フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/persistent-session.png)
#### KEEP ALIVE
このシナリオでは、デバイスがブローカーから ping 応答を受信しない後に正常に切断されるかどうかを検証します。接続には有効なキープアライブタイマーが設定されている必要があります。このテストの一環として、ブローカーは、`PUBLISH`、`SUBSCRIBE`、および `PINGREQ` メッセージに送信されるすべての応答をブロックします。テスト対象のデバイスが、MQTT 接続を切断しているかどうかも検証します。
![\[DUT とブローカー間の KEEP ALIVE フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/keep-alive.png)
#### 断続的な接続
このシナリオでは、ブローカーがデバイスをランダムな間隔で一定時間切断した後に、デバイスがブローカーに再び接続できるかどうかを検証します。
![\[DUT とブローカー間の INTERMITTENT CONNECTIVITY フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/intermittent.png)
#### 再接続のバックオフ
このシナリオでは、ブローカーが複数回接続を切断したときに、デバイスにバックオフメカニズムが実装されているかどうかを検証します。Device Advisor は、バックオフタイプを指数関数、ジッター、線形、または定数として報告します。バックオフの試行回数は、`BACKOFF_CONNECTION_ATTEMPTS` オプションを使用して設定できます。デフォルト値は 5 です。この値は 5～10 の間で設定できます。
このテストに合格するには、テスト対象のデバイスに、[エクスポネンシャルバックオフとジッター](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)メカニズムを実装することをお勧めします。
![\[DUT とブローカー間の RECONNECT BACKOFF フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/reconnect-backoff.png)
#### 長期のサーバー切断
このシナリオでは、ブローカーがデバイスを長時間 (最大 120 分) 切断した後に、デバイスが正常に再接続できるかどうかを検証します。サーバーを切断する時間は、`LONG_SERVER_DISCONNECT_TIME` オプションを使用して設定できます。デフォルト値は 120 分です。この値は 30 分から 120 分まで設定できます。
![\[DUT とブローカー間の LONG SERVER DISCONNECT フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/longserver-disconnect.png)
### 追加実行時間
追加実行時間は、上記のすべてのテストを完了してからテストケースを終了するまでにテストが待機する時間です。顧客はこの追加時間を利用して、デバイスとブローカーとの間のすべての通信を監視および記録します。追加実行時間は、`ADDITIONAL_EXECUTION_TIME` オプションを使用して設定できます。デフォルトでは、このオプションは 0 分に設定されており、0～120 分に設定できます。
## MQTT 長期テスト設定オプション
MQTT 長期テストで提供される設定オプションはすべてオプションです。以下のオプションが利用できます。
**オペレーション**
デバイスが実行するオペレーションのリスト (`CONNECT`、`PUBLISH` および `SUBSCRIBE` など)。テストケースは、指定されたオペレーションに基づいてシナリオを実行します。指定されていないオペレーションは有効とみなされます。
```
{
"OPERATIONS": ["PUBLISH", "SUBSCRIBE"]
//by default the test assumes device can CONNECT
}
```
**シナリオ**
選択したオペレーションに基づいて、テストケースはシナリオを実行してデバイスの動作を検証します。シナリオには、次の 2 つのタイプがあります。
+ **基本シナリオ**は、デバイスが設定の一部として上記で選択したオペレーションを実行できるかどうかを検証する簡単なテストです。これらは、構成で指定されたオペレーションに基づいて事前に選択されています。設定に追加の入力は必要ありません。
+ **高度なシナリオ**は、デバイスに対して実行されるより複雑なシナリオで、デバイスが実際の条件を満たしたときにベストプラクティスに従っているかどうかを検証します。これらはオプションで、シナリオの配列としてテストスイートの設定入力に渡すことができます。
```
{
"SCENARIOS": [ // list of advanced scenarios
"PUBACK_QOS_1",
"RECEIVE_LARGE_PAYLOAD",
"PERSISTENT_SESSION",
"KEEP_ALIVE",
"INTERMITTENT_CONNECTIVITY",
"RECONNECT_BACK_OFF",
"LONG_SERVER_DISCONNECT"
]
}
```
**BASIC\$1TESTS\$1EXECUTION\$1TIME\$1OUT:**
すべての基本テストが完了するまでのテストケースの最大待機時間。デフォルト値は 60 分です。この値は 30 分から 120 分まで設定できます。
**LONG\$1SERVER\$1DISCONNECT\$1TIME:**
長期のサーバー切断テスト中に、テストケースがデバイスを切断して再接続するまでにかかった時間。デフォルト値は 60 分です。この値は 30 分から 120 分まで設定できます。
**ADDITIONAL\$1EXECUTION\$1TIME:**
このオプションを設定すると、すべてのテストが完了した後、デバイスとブローカー間のイベントを監視するための時間ウィンドウが設けられます。デフォルト値は 0 分です。この値は 0 から 120 分まで設定できます。
**BACKOFF\$1CONNECTION\$1ATTEMPTS:**
このオプションは、テストケースによってデバイスが切断される回数を設定します。これは再接続バックオフテストで使用されます。デフォルト値は 5 回です。この値は 5～10 の間で設定できます。
**LONG\$1PAYLOAD\$1FORMAT:**
デバイスがサブスクライブしている QoS 1 トピックにテストケースを発行するときにデバイス想定するメッセージペイロードの形式。
**API テストケースの定義:**
```
{
"tests":[
{
"name":"my_mqtt_long_duration_test",
"configuration": {
// optional
"OPERATIONS": ["PUBLISH", "SUBSCRIBE"],
"SCENARIOS": [
"LONG_SERVER_DISCONNECT",
"RECONNECT_BACK_OFF",
"KEEP_ALIVE",
"RECEIVE_LARGE_PAYLOAD",
"INTERMITTENT_CONNECTIVITY",
"PERSISTENT_SESSION",
],
"BASIC_TESTS_EXECUTION_TIMEOUT": 60, // in minutes (60 minutes by default)
"LONG_SERVER_DISCONNECT_TIME": 60, // in minutes (120 minutes by default)
"ADDITIONAL_EXECUTION_TIME": 60, // in minutes (0 minutes by default)
"BACKOFF_CONNECTION_ATTEMPTS": "5",
"LONG_PAYLOAD_FORMAT":"{"message":"${payload}"}"
},
"test":{
"id":"MQTT_Long_Duration",
"version":"0.0.0"
}
}
]
}
```
## MQTT 長期テストケース概要ログ
MQTT 長期テストケースは、通常のテストケースよりも長時間実行されます。実行中のデバイス接続、発行、サブスクライブなどの重要なイベントを一覧表示する概要ログが別途提供されます。詳細には、テストされた内容、テストされなかったもの、失敗したものが含まれます。ログの最後には、テストケースの実行中に発生したすべてのイベントの概要がテストに含まれます。これには、以下が含まれます。
+ *デバイスに設定されているキープアライブタイマー。*
+ *デバイスに設定された永続セッションフラグ。*
+ *テスト実行中のデバイス接続数。*
+ *デバイス再接続バックオフタイプ (再接続バックオフテストで検証された場合)。*
+ *テストケースの実行中にデバイスが発行したトピック。*
+ *テストケースの実行中にデバイスがサブスクライブしたトピック。*