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

# Device Advisor テストケース
<a name="device-advisor-tests"></a>

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 テストケース。
<a name="qualifiying-test-cases"></a>

お使いのデバイスが認定を受けるには、[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
<a name="device-advisor-tests-tls"></a>

これらのテストを使用して、デバイスと 間のトランスポートレイヤーセキュリティプロトコル (TLS) AWS IoT が安全かどうかを判断します。

**注記**  
Device Advisor が TLS1.3 をサポートするようになりました。

## Happy Path
<a name="happy-path"></a>

**TLS Connect**  <a name="TLS_Connect"></a>
テスト対象のデバイスが 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 が受信する最大サイズのフラグメント**  <a name="TLS_MaximumSize"></a>
このテストケースは、デバイスが 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"
      }
   }
]
```

## 暗号スイート
<a name="cipher-suites"></a>

** AWS IoT 推奨される暗号スイートの TLS デバイスサポート**  <a name="TLS_DeviceSupport_For_IOT"></a>
テスト対象デバイスからの 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 サポートされている暗号スイートは含まれていません。

## より大きなサイズのサーバー証明書
<a name="larger-size"></a>

**TLS 大きなサイズのサーバー証明書**  <a name="TLS_LargeServerCert"></a>
お使いのデバイスが、より大きなサイズのサーバー証明書を受け取って処理する場合に、 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 非セキュアサーバー証明書
<a name="unsecure-server"></a>

**認識された CA によって署名されていません**  <a name="TLS_Unsecure_Server_Cert"></a>
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)**  <a name="TLS_Incorrect_Subject_Name"></a>
リクエストされたものとは異なるドメイン名のサーバー証明書が提示された場合にテスト対象のデバイスが接続を閉じることを検証します。  

**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 期限切れサーバー証明書
<a name="expired-server"></a>

**期限切れサーバー証明書**  <a name="TLS_Expired_Server_Cert"></a>
期限切れサーバー証明書が提示された場合にテスト対象のデバイスが接続を閉じることを検証します。  

**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
<a name="device-advisor-tests-mqtt"></a>

## CONNECT、DISCONNECT、および RECONNECT
<a name="connect"></a>

**「デバイスが CONNECT を AWS IoT Core (ハッピーケース) に送信する」**  <a name="MQTT_Connect"></a>
テスト対象のデバイスが 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 応答なし」**  <a name="MQTT_ConnectJitterBackoff"></a>
ブローカーに少なくとも 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"
      }
   }
]
```

## 発行
<a name="publish"></a>

**「QoS0 (Happy Case)」**  <a name="MQTT_Publish"></a>
テスト対象デバイスが 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
<a name="subscribe"></a>

**「Can Subscribe (Happy Case)」**  <a name="MQTT_Subscribe"></a>
テスト対象のデバイスが 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
<a name="keep-alive"></a>

**「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"
       }
    }
]
```

## 永続セッション
<a name="persistent-session"></a>

**「永続セッション (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"
      }
   }
]
```

# シャドウ
<a name="device-advisor-tests-shadow"></a>

これらのテストを使用して、テスト対象のデバイスが AWS IoT Device Shadow サービスを正しく使用していることを確認します。詳細については、「[AWS IoT Device Shadow サービス](iot-device-shadows.md)」を参照してください。これらのテストケースがテストスイートで設定されている場合は、スイートの実行を開始するときにモノを指定する必要があります。

現時点では、**MQTT over WebSocket** はサポートされていません。

## 発行
<a name="publish"></a>

***「デバイスは接続後に状態を発行します (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)を参照してください。

## 更新
<a name="update"></a>

***「デバイスは報告された状態を望ましい状態に更新します (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)を参照してください。

# ジョブの実行
<a name="device-advisor-tests-job-execution"></a>

**「デバイスはジョブの実行を完了できます」**  
 このテストケースは、デバイスが 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)」を参照してください。

# アクセス許可とポリシー
<a name="device-advisor-tests-permissions-policies"></a>

次のテストを使用して、デバイスの証明書にアタッチされたポリシーがスタンダードベストプラクティスに従っているかどうかを判断します。

現時点では、**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"
        }
    }
]
```

# 長期テスト
<a name="device-advisor-tests-long-duration"></a>

長期テストは、デバイスが長期間動作しているときの動作を監視する新しいテストスイートです。デバイスの特定の動作に焦点を当てた個別のテストを実行する場合と比較して、長期テストでは、デバイスの寿命全体にわたるさまざまな現実世界のシナリオにおけるデバイスの動作を調べます。Device Advisor は、可能な限り効率的な順序でテストを調整します。テストでは、テスト中のデバイスのパフォーマンスに関する有用なメトリクスを含む概要ログを含む結果とログが生成されます。

## MQTT 長期テストケース
<a name="long-duration-test-case"></a>

MQTT の長期テストケースでは、MQTT Connect、サブスクライブ、発行、再接続などのハッピーケースシナリオでデバイスの動作が最初に確認されます。次に、デバイスが MQTT 再接続バックオフ、長期のサーバー切断、断続的な接続など、複数の複雑な障害シナリオに見舞われます。

## MQTT 長期テストケース実行フロー
<a name="long-duration-test-case-execution-flow"></a>

MQTT 長期テストケースの実行には、次の 3 つのフェーズがあります。

![\[基本テストの実行、高度なテストの実行、追加の実行時間を示す「MQTT 長時間テストの実行」。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/mqtt-execution-flow.png)


### 基本テストの実行
<a name="basic-tests-execution"></a>

このフェーズでは、テストケースは簡単なテストを並行して実行します。このテストでは、設定で選択したオペレーションがデバイスにあるかどうかを検証します。

基本テストのセットには、選択したオペレーションに基づいて次の内容が含まれる場合があります。

#### CONNECT
<a name="basic-tests-execution-connect"></a>

このシナリオでは、デバイスがブローカーと正常に接続できるかどうかを検証します。

![\[デバイスが CONNECT メッセージを送信し、ブローカーが正常なリターンコードを含む CONNACK メッセージで応答する基本的な接続フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/basic-connect.png)


#### 発行
<a name="basic-tests-execution-publish"></a>

このシナリオでは、デバイスがブローカーに対して正常に発行されているかどうかを検証します。

##### QoS 0
<a name="publish-qos0"></a>

このテストケースは、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
<a name="publish-qos1"></a>

このテストケースでは、デバイスは 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)


#### サブスクライブ
<a name="basic-tests-execution-subscribe"></a>

このシナリオでは、デバイスがブローカーに対して正常にサブスクライブしているかどうかを検証します。

##### QoS 0
<a name="subscribe-qos0"></a>

このテストケースは、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
<a name="subscribe-qos1"></a>

このテストケースでは、デバイスは 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)


#### 再接続
<a name="basic-tests-execution-reconnect"></a>

このシナリオでは、デバイスが正常に接続から切断された後に、デバイスがブローカーと正常に再接続するかどうかを検証します。テストスイート中にデバイスを複数回接続しても、Device Advisor はデバイスを切断しません。代わりに、テストを **[Pass]** (合格) としてマークします。

![\[DUT とブローカー間の RECONNECT フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/reconnect.png)


### 高度なテストの実行
<a name="advanced-tests-execution"></a>

このフェーズでは、テストケースはより複雑なテストを連続して実行し、デバイスがベストプラクティスに従っているかどうかを検証します。これらの高度なテストは選択可能で、必要ない場合はオプトアウトできます。それぞれの高度なテストには、シナリオの要求に応じて独自のタイムアウト値があります。

#### QoS 1 サブスクリプションで PUBACK を返す
<a name="advanced-tests-execution-return-puback"></a>

**注記**  
このシナリオは、デバイスが 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)


#### 大きなペイロードを受け取る
<a name="advanced-tests-execution-receive-large-payload"></a>

**注記**  
このシナリオは、デバイスが 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)


#### 永続セッション
<a name="advanced-tests-execution-persistent-session"></a>

**注記**  
このシナリオは、デバイスが 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
<a name="advanced-tests-execution-keep-alive"></a>

このシナリオでは、デバイスがブローカーから ping 応答を受信しない後に正常に切断されるかどうかを検証します。接続には有効なキープアライブタイマーが設定されている必要があります。このテストの一環として、ブローカーは、`PUBLISH`、`SUBSCRIBE`、および `PINGREQ` メッセージに送信されるすべての応答をブロックします。テスト対象のデバイスが、MQTT 接続を切断しているかどうかも検証します。

![\[DUT とブローカー間の KEEP ALIVE フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/keep-alive.png)


#### 断続的な接続
<a name="advanced-tests-execution-intermittent-connectivity"></a>

このシナリオでは、ブローカーがデバイスをランダムな間隔で一定時間切断した後に、デバイスがブローカーに再び接続できるかどうかを検証します。

![\[DUT とブローカー間の INTERMITTENT CONNECTIVITY フロー。\]](http://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/images/intermittent.png)


#### 再接続のバックオフ
<a name="advanced-tests-execution-reconnect-backoff"></a>

このシナリオでは、ブローカーが複数回接続を切断したときに、デバイスにバックオフメカニズムが実装されているかどうかを検証します。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)


#### 長期のサーバー切断
<a name="advanced-tests-execution-longserver-disconnect"></a>

このシナリオでは、ブローカーがデバイスを長時間 (最大 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)


### 追加実行時間
<a name="additional-execution-time"></a>

追加実行時間は、上記のすべてのテストを完了してからテストケースを終了するまでにテストが待機する時間です。顧客はこの追加時間を利用して、デバイスとブローカーとの間のすべての通信を監視および記録します。追加実行時間は、`ADDITIONAL_EXECUTION_TIME` オプションを使用して設定できます。デフォルトでは、このオプションは 0 分に設定されており、0～120 分に設定できます。

## MQTT 長期テスト設定オプション
<a name="long-duration-test-case-config-options"></a>

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 長期テストケース概要ログ
<a name="long-duration-test-case-summary-log"></a>

MQTT 長期テストケースは、通常のテストケースよりも長時間実行されます。実行中のデバイス接続、発行、サブスクライブなどの重要なイベントを一覧表示する概要ログが別途提供されます。詳細には、テストされた内容、テストされなかったもの、失敗したものが含まれます。ログの最後には、テストケースの実行中に発生したすべてのイベントの概要がテストに含まれます。これには、以下が含まれます。
+ *デバイスに設定されているキープアライブタイマー。*
+ *デバイスに設定された永続セッションフラグ。*
+ *テスト実行中のデバイス接続数。*
+ *デバイス再接続バックオフタイプ (再接続バックオフテストで検証された場合)。*
+ *テストケースの実行中にデバイスが発行したトピック。*
+ *テストケースの実行中にデバイスがサブスクライブしたトピック。*