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

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