MQTT

“设备发送CONNECT到 AWS IoT Core （Happy case）”

验证被测设备是否发送了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"
      }
   }
]

“设备可以返回 Q PUBACK oS1 的任意话题”

此测试用例将检查如果设备（客户端）在通过 QoS1 订阅主题后收到来自代理的发布消息，它是否可以返回消息。PUBACK

可针对此测试用例配置负载内容和负载大小。如果配置了负载大小，Device Advisor 将覆盖负载内容的值，并将预定义的具有所需大小的负载发送到设备。负载大小的值介于 0 到 128 之间，不能超过 128KB。 AWS IoT Core 拒绝大于 128KB 的发布和连接请求，如 AWS IoT Core 消息代理及协议限制和限额页面所示。

API测试用例定义：

注意

EXECUTION_TIMEOUT 的默认值为 5 分钟。我们建议超时值为 2 分钟。PAYLOAD_SIZE 可以配置为 0 到 128KB 之间的值。定义负载大小会覆盖负载内容，因为 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

验证被测设备与代理重新连接至少五次时是否使用了正确的抖动退避。代理记录被测设备CONNECT请求的时间戳，执行数据包验证，暂停而不向被测设备发送，然后等待被测设备重新发送请求。CONNACK允许第六次连接尝试通过CONNACK，并允许其流回被测设备。

将再次执行上述过程。总体而言，此测试用例要求设备总共至少连接 12 次。收集的时间戳用于验证被测设备是否使用了抖动退避。如果被测设备具有严格的指数退避延迟，则此测试用例将通过但带有警告。

我们建议实施指数退避和抖动在所测试设备上的机制通过此测试案例。

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

验证被测设备与代理重新连接至少五次时是否使用了正确的指数退避。代理记录被测设备CONNECT请求的时间戳，执行数据包验证，暂停而不向客户端设备发送，然后等待被测设备重新发送请求。CONNACK收集的时间戳用于验证被测设备是否使用了指数退避。

我们建议实施指数退避和抖动在所测试设备上的机制通过此测试案例。

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 将设备与服务器断开连接至少五次，并观察设备的行为以进行MQTT重新连接。Device Advisor 记录被测设备CONNECT请求的时间戳，执行数据包验证，暂停而不向客户端设备发送，然后等待被测设备重新发送请求。CONNACK收集的时间戳用于验证被测设备在重新连接时是否使用抖动和退避。如果被测设备具有严格的指数退避或未实现适当的抖动退避机制，此测试用例将通过但是带有警告。如果被测设备实施了线性退避或恒定退避机制，测试将失败。

要通过此测试用例，我们建议在所测试设备上实施指数退避和抖动机制。

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 re-connect with jitter backoff - On unstable connection"（“设备以抖动退避功能重新连接 - 连接不稳定”）

验证被测设备在不稳定连接上重新连接时是否使用了必要的抖动和退避。成功连接五次后，Device Advisor 会断开设备与服务器的连接，并观察设备的行为以进行MQTT重新连接。Device Advisor 记录被测设备CONNECT请求的时间戳、执行数据包验证CONNACK、发回、断开连接、记录断开连接的时间戳，然后等待被测设备重新发送请求。收集的时间戳用于验证被测设备在成功但不稳定的连接后重新连接时，是否使用抖动和退避。如果被测设备具有严格的指数退避或未实现适当的抖动退避机制，此测试用例将通过但是带有警告。如果被测设备实施了线性退避或恒定退避机制，测试将失败。

要通过此测试用例，我们建议在所测试设备上实施指数退避和抖动机制。

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（快乐用例）”）

验证测试设备是使用 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

如果代理未发送，则验证被测设备是否重新发布了通过 QoS1 发送的消息。PUBACK您还可以通过在测试设置中指定此主题来验证消息的主题。在重新发布消息之前，客户端设备不得断开连接。此测试还验证重新发布的消息与原始消息是否具有相同的数据包标识符。在测试执行期间，如果设备丢失连接并重新连接，则测试用例将顺利重置，并且设备必须重新执行测试用例步骤。

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

"Publish Retained messages"（“发布保留消息”）

验证被测设备是否发布 retainFlag 设置为 true 的消息。您可以通过在测试设置中设置主题值和有效负载来验证消息的主题和有效负载。如果PUBLISH数据包内retainFlag发送的未设置为 true，则测试用例将失败。

API测试用例定义：

注意

EXECUTION_TIMEOUT 的默认值为 5 分钟。我们建议将超时值设置为 2 分钟。要运行此测试用例，请在您的 device 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"
      }
   }
]

"Publish with User Property"（“使用用户属性发布”）

验证被测设备是否使用正确的用户属性发布消息。您可以通过在测试设置中设置名称-值对来验证用户属性。如果未提供用户属性或用户属性不匹配，则测试用例将失败。

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

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

“Mattt No Ack PingResp”

此测试用例验证被测设备在未收到 ping 响应时是否断开连接。作为此测试用例的一部分，设备顾问会屏蔽来自 AWS IoT Core 的发布、订阅和 ping 请求的响应。它还会验证被测设备是否断开了连接。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"
       }
    }
]

“持久会话（快乐用例）”

此测试用例验证设备在与持久会话断开连接时的行为。该测试用例检查设备是否可以重新连接，恢复对其触发器主题的订阅而无需显式重新订阅，接收主题中存储的消息以及在持久会话期间按预期工作。当此测试用例通过时，它表明客户端设备能够以预期的方式与 AWS IoT Core 代理保持持续会话。有关 AWS IoT 持久会话的更多信息，请参阅使用MQTT持久会话。

在此测试CONNECT用例中，客户端设备应将 clean sess AWS IoT Core ion 标志设置为 false，然后订阅触发器主题。成功订阅后，设备顾问将断开 AWS IoT Core 设备连接。当设备处于断开连接状态时，该主题中将存储 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数据包来重新订阅之前订阅的主题。

在第一次连接期间，我们希望测试设备CONNECT与 AWS 物联网代理连接，因为其CleanSession标志设置为 false 以启动持续会话。然后，设备应该订阅触发器主题。然后，在成功订阅并启动持续会话后， AWS IoT Core 设备顾问将断开设备的连接。断开连接后， AWS IoT Core 设备顾问允许测试设备与测试端点重新连接。此时，当测试设备发送另一个CONNECT数据包时， AWS IoT Core Device Advisor 会发回一个指示持续会话已过期CONNACK的数据包。测试设备需要正确地解释此数据包，并且在持久会话终止时，它应该会再次重新订阅同一触发器主题。如果测试设备不再重新订阅其主题触发器，测试用例将失败。为了使测试通过，设备需要知道持续会话已经结束，并在第二次连接中针对同一触发主题发送一个新的SUBSCRIBE数据包。

如果测试设备的此测试用例获得通过，则表示该设备能够按照预期方式在持久会话到期时进行重新连接。

API测试用例定义：

注意

EXECUTION_TIMEOUT 的默认值为 5 分钟。我们建议将超时值设置为至少 4 分钟。测试设备需要显式订阅之前没有订阅的 TRIGGER_TOPIC。要通过测试用例，测试设备必须发送CleanSession标记设置为 false CONNECT 的数据包，并成功订阅 QoS 为 1 的触发主题。成功连接后， AWS IoT Core 设备顾问会断开设备的连接。断开连接后， AWS IoT Core Device Advisor 允许设备重新连接，并且设备应该重新订阅相同的连接，TRIGGER_TOPIC因为 AWS IoT Core 设备顾问本来会终止持续会话。


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

CONNECTDISCONNECT、和 RECONNECT

注意

注意

注意

注意

注意

注意

Publish

注意

注意

注意

注意

注意

注意

Keep-Alive

注意

持久会话

注意

注意