本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Device Advisor 测试使用案例
<a name="device-advisor-tests"></a>

Device Advisor 提供六个类别的预构建测试。
+ [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)

## 符合设备资格认证计划的 AWS 设备顾问测试用例。
<a name="qualifiying-test-cases"></a>

根据 [AWS 设备资格认证计划](https://aws.amazon.com/partners/programs/dqp/)，您的设备必须通过以下测试才符合资格。

**注意**  
这是一份经修订的资格认证测试列表。
+ [TLS 连接](device-advisor-tests-tls.md#TLS_Connect)（“TLS 连接”）
+ [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 设备支持（“ AWS IoT 推荐密码套件](device-advisor-tests-tls.md#TLS_DeviceSupport_For_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)（“设备发送连接到 AWS IoT Core （Happy case）”）
+ [MQTT 订阅](device-advisor-tests-mqtt.md#MQTT_Subscribe) [“可以订阅（快乐使用案例）”]
+ [MQTT 发布](device-advisor-tests-mqtt.md#MQTT_Publish) [“QoS0（快乐使用案例）”]
+ [MQTT 连接抖动重试次数](device-advisor-tests-mqtt.md#MQTT_ConnectJitterBackoff)（“使用抖动退避功能重试设备连接 - 无 CONNACK 响应”）

# TLS
<a name="device-advisor-tests-tls"></a>

使用这些测试来确定您的设备和之间的传输层安全协议 (TLS) AWS IoT 是否安全。

**注意**  
Device Advisor 现在支持 TLS 1.3。

## 满意路径
<a name="happy-path"></a>

**TLS 连接**  <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，但设备或 AWS IoT发来了 TLS 警告消息。
+ **失败** — 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 Device Support**  <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 测试用例输出：**  
+ **通过** — 被测设备密码套件至少包含一个推荐的 AWS IoT 密码套件，并且不包含任何不支持的密码套件。
+ **通过但带有警告** - 设备密码套件至少包含一个 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 在此测试用例中，请 AWS IoT 测试设备的 TLS 缓冲空间如果缓冲空间足够大，TLS 握手将顺利完成。此测试不验证设备的 MQTT 实施。测试使用案例在 TLS 握手过程完成后结束。  

**Example API 测试用例定义：**  
`EXECUTION_TIMEOUT` 的默认值为 5 分钟。为了获得最佳效果，我们建议超时值为 2 分钟。如果此测试使用案例失败但 **TLS 连接**测试使用案例通过，我们建议您提高设备的 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，但设备或 AWS IoT TLS 警告消息来自该设备。
+ **失败** — 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 （Happy case）”**  <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"
      }
   }
]
```

**“设备可以将 PUBACK 返回到 QoS1 的任意主题”**  
如果客户端在使用 QoS1 订阅到主题后收到来自代理的发布消息，则此测试案例将检查设备（客户端）是否能够返回 PUBACK 消息。  
可针对此测试使用案例配置有效载荷内容和有效载荷大小。如果配置了有效载荷大小，Device Advisor 将覆盖有效载荷内容的值，并将预定义的具有所需大小的有效载荷发送到设备。有效载荷大小的值介于 0 到 128 之间，不能超过 128KB。 AWS IoT Core 拒绝大于 128KB 的发布和连接请求，如 [AWS IoT Core 消息代理及协议限制和限额](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits)页面所示。  
*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 响应”**  <a name="MQTT_ConnectJitterBackoff"></a>
验证被测设备与代理重新连接至少五次时是否使用了正确的抖动退避。代理记录被测设备的 CONNECT 请求时间戳，执行数据包验证，暂停而不向被测设备发送 CONNACK，并等待被测设备重新发送请求。允许第六次连接尝试通过，并允许 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 响应”**  
验证被测设备与代理重新连接至少五次时是否使用了正确的指数退避。代理记录被测设备的 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 至少将设备与服务器断开五次，并观察设备的 MQTT 重新连接的行为。Device Advisor 记录被测设备的连接请求的时间戳，执行数据包验证，暂停而不向客户端设备发送连接，并等待被测设备重新发送请求。收集的时间戳用于验证被测设备在重新连接时是否使用抖动和退避。如果被测设备具有严格的指数退避或未实现适当的抖动退避机制，此测试用例将通过但是带有警告。如果被测设备实施了线性退避或恒定退避机制，测试将失败。  
要通过此测试用例，我们建议在所测试设备上实施[指数退避和抖动](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 在五次成功连接后将设备与服务器断开连接，并观察设备的 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（快乐使用案例）”**  <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 发送的消息。您还可以通过在测试设置中指定此主题来验证消息的主题。在重新发布消息之前，客户端设备不得断开连接。此测试还验证重新发布的消息与原始消息是否具有相同的数据包标识符。在测试执行期间，如果设备丢失连接并重新连接，则测试用例将顺利重置，并且设备必须重新执行测试用例步骤。  
*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 分钟。要运行此测试使用案例，请在您的 [device role](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>

**“可以订阅（快乐使用案例）”**  <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>

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

## 持久会话
<a name="persistent-session"></a>

**“持久会话（快乐使用案例）”**  
此测试使用案例验证设备在与持久会话断开连接时的行为。该测试使用案例检查设备是否可以重新连接，恢复对其触发器主题的订阅而无需显式重新订阅，接收主题中存储的消息以及在持久会话期间按预期工作。当此测试用例通过时，它表明客户端设备能够以预期的方式与 AWS IoT Core 代理保持持续会话。有关 AWS IoT 持久会话的更多信息，请参阅[使用 MQTT 持久会话](https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions)。  
在此测试使用案例中，客户端设备应该与 AWS IoT Core 进行连接 [clean session（清理会话）标志设置为 false]，然后订阅一个触发器主题。成功订阅后，设备顾问将断开 AWS IoT Core 设备连接。当设备处于断开连接状态时，该主题中将存储 QoS 1 消息有效载荷。然后，Device Advisor 将允许客户端设备与测试端点重新连接。此时，由于存在持久会话，客户端设备应该恢复其主题订阅而不发送任何其他 SUBSCRIBE 数据包，然后接收来自代理的 QoS 1 消息。重新连接后，如果客户端设备未能从触发主题接收存储的消息，通过发送额外的 SUBSCRIBE 数据包再次订阅其触发主题， and/or 则测试用例将失败。  
*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"
      }
   }
]
```

**“持久会话 - 会话到期”**  
此测试使用案例有助于验证断开连接的设备重新连接到过期的持久会话时的设备行为。会话过期后，我们希望设备通过显式发送新的 SUBSUBE 数据包来重新订阅之前订阅的主题。  
在第一次连接期间，我们希望测试设备与 AWS 物联网代理连接，因为其`CleanSession`标志设置为 false 即可启动持续会话。然后，设备应该订阅触发器主题。然后，在成功订阅并启动持续会话后， AWS IoT Core 设备顾问将断开设备的连接。断开连接后， AWS IoT Core 设备顾问允许测试设备与测试端点重新连接。此时，当测试设备发送另一个 CONNECT 数据包时， AWS IoT Core 设备顾问会发回一个 CONNACK 数据包，表示持续会话已过期。测试设备需要正确地解释此数据包，并且在持久会话终止时，它应该会再次重新订阅同一触发器主题。如果测试设备不再重新订阅其主题触发器，测试使用案例将失败。要通过测试，设备需要了解持久会话已经结束，然后为第二个连接中的相同触发器主题发回一个新的 SUBSCRIBE 数据包。  
如果测试设备的此测试使用案例获得通过，则表示该设备能够按照预期方式在持久会话到期时进行重新连接。  
*API 测试用例定义：*  
`EXECUTION_TIMEOUT` 的默认值为 5 分钟。我们建议将超时值设置为至少 4 分钟。测试设备需要显式订阅之前没有订阅的 `TRIGGER_TOPIC`。要通过测试使用案例，测试设备必须发送 CONNECT 数据包（`CleanSession` 标志设置为 false），并使用 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"
      }
   }
]
```

# 影子
<a name="device-advisor-tests-shadow"></a>

使用这些测试来验证您的被测设备是否正确使用 AWS IoT 了 Device Shadow 服务。请参阅[AWS IoT Device Shadow 服务](iot-device-shadows.md)了解更多信息。如果在测试套件中配置了这些测试使用案例，则在启动套件运行时需要提供一个事物。

 WebSocket目前不支持 **MQTT** 版本。

## 发布
<a name="publish"></a>

***“设备连接后发布状态（快乐使用案例）”***  
验证设备连接后能否发布其状态 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`，则测试使用案例将默认查找发布到 Unnamed（经典）影子类型的主题前缀的消息。如果您的设备使用命名的影子类型，请提供影子名称。请参阅[在设备中使用影子](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html)，了解更多信息。

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

***“设备更新报告状态为理想状态（快乐使用案例）”***  
验证设备是否读取所有收到的更新消息，并同步设备的状态以与所需的状态属性匹配。您的设备应在同步后发布其最新报告状态。如果您的设备在运行测试之前已存在影子，请确保为测试使用案例配置的所需状态与现有报告状态不匹配。您可以通过查看 Shadow 文档中的**ClientToken**字段来识别 Device Advisor 发送的 Shadow 更新消息`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` 应具有至少一个属性和关联的值。  
如果未提供 `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 任务接收更新，并发布成功更新的状态。有关 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 主题。要订阅与消息相关的任务活动，请使用 **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)的保留主题。  
 WebSocket目前不支持 **MQTT** 版本。  
*API 测试用例定义：*  
`EXECUTION_TIMEOUT` 的默认值为 5 分钟。我们建议将超时值设置为 3 分钟。根据所提供的 Jo AWS IoT b 文档或来源，调整超时值（例如，如果作业需要很长时间才能运行，请为测试用例定义更长的超时值）。要运行测试，需要有效的 AWS IoT Job 文档或已经存在的作业 ID。 AWS IoT Job 文档可以以 JSON 文档或 S3 链接的形式提供。如果已提供任务文档，则可以选择提供任务 ID。如果提供了任务 ID，Device Advisor 将在代表您创建 AWS IoT 任务时使用该ID。如果未提供任务文档，您可以提供用于运行测试使用案例的同一区域中的现有 ID。在这种情况下，设备顾问将在运行测试用例时使用该 AWS IoT Job。

```
"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>

您可以使用下列测试来确定附加到设备证书的策略是否符合下列标准最佳实践。

 WebSocket目前不支持 **MQTT** 版本。

**“设备证书附加策略不包含通配符”**  
 验证与设备关联的权限策略是否遵循最佳实践，并且未向设备授予除所需权限以外的其它权限。  
*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 连接、订阅、发布和重新连接之类的快乐使用案例场景中观察的。然后，在多种复杂的故障场景中观察该设备，例如 MQTT 重新连接回退、长时间服务器断开连接和间歇性连接。

## MQTT 长时间测试使用案例执行流程
<a name="long-duration-test-case-execution-flow"></a>

MQTT 长时间测试使用案例的执行分为三个阶段：

![\[显示基本测试执行、高级测试执行和额外执行时间的“MQTT 长时间测试执行”。\]](http://docs.aws.amazon.com/zh_cn/iot/latest/developerguide/images/mqtt-execution-flow.png)


### 执行基本测试
<a name="basic-tests-execution"></a>

在此阶段，测试使用案例并行运行多项简单测试。该测试验证设备是否在配置中选择了这些操作。

根据所选操作，基本测试集可以包括以下内容：

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

此场景验证设备是否能够成功与代理建立连接。

![\[基本连接流程，其中包括发送 CONNECT 消息的设备，以及以 CONNACK 消息及成功返回代码进行响应的代理。\]](http://docs.aws.amazon.com/zh_cn/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` 消息。

![\[PUBLISH QoS 0 流程，其中包括发送 QoS 0 级别的 PUBLISH 消息的设备。\]](http://docs.aws.amazon.com/zh_cn/iot/latest/developerguide/images/Qos0.png)


##### QoS 1
<a name="publish-qos1"></a>

在此测试用例中，设备应使用 QoS 1 向代理发送两条 `PUBLISH` 消息。在收到第一条 `PUBLISH` 消息后，代理最多等待 15 秒钟就会做出响应。设备必须在 15 秒的期限内使用相同的数据包标识符重试原始 `PUBLISH` 消息。如果是这样，代理会回复一条 `PUBACK` 消息，测试将进行验证。如果设备不重试 `PUBLISH`，会将原始 `PUBACK` 发送到设备，测试将被标记为**通过但带有警告**，并会显示系统消息。在测试执行期间，如果设备丢失连接并重新连接，则测试场景将顺利重置，并且设备必须重新执行测试场景步骤。

![\[PUBLISH QoS 1 流程，其中包括发送 QoS 1 级别的 PUBLISH 消息的设备，以及与代理的多次互动。\]](http://docs.aws.amazon.com/zh_cn/iot/latest/developerguide/images/Qos1.png)


#### 订阅
<a name="basic-tests-execution-subscribe"></a>

此场景验证设备是否能够成功向代理订阅。

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

此测试使用案例验证设备在使用 QoS 0 订阅期间是否能够成功向代理发送 `SUBSCRIBE` 消息。测试不会等待设备收到 SUBACK 消息。

![\[SUBSCRIBE QoS 0 流程，其中包括发送 QoS 0 级别的 SUBSCRIBE 消息的设备，以及用 SUBACK 消息和“成功 - 最大 QoS 为 0”代码进行响应的代理。\]](http://docs.aws.amazon.com/zh_cn/iot/latest/developerguide/images/subscribe-Qos0.png)


##### QoS 1
<a name="subscribe-qos1"></a>

在此测试用例中，设备应使用 QoS 1 向代理发送两条 `SUBSCRIBE` 消息。在收到第一条 `SUBSCRIBE` 消息后，代理最多等待 15 秒钟就会做出响应。设备必须在 15 秒的期限内使用相同的数据包标识符重试原始 `SUBSCRIBE` 消息。如果是这样，代理会回复一条 `SUBACK` 消息，测试将进行验证。如果设备不重试 `SUBSCRIBE`，会将原始 `SUBACK` 发送到设备，测试将被标记为**通过但带有警告**，并会显示系统消息。在测试执行期间，如果设备丢失连接并重新连接，则测试场景将顺利重置，并且设备必须重新执行测试场景步骤。

![\[SUBSCRIBE QoS 1 流程，其中包括发送 QoS 1 级别的 SUBSCRIBE 消息的设备，以及与代理的多次互动。\]](http://docs.aws.amazon.com/zh_cn/iot/latest/developerguide/images/subscribe-Qos1.png)


#### 重新连接
<a name="basic-tests-execution-reconnect"></a>

此场景验证在设备从成功连接断开连接后，是否能够成功与代理重新连接。如果在之前的测试套件期间多次连接设备，Device Advisor 不会断开设备此连接。相反，它会将测试标记为 **Pass**（通过）。

![\[DUT 和代理之间的 RECONNECT 流程。\]](http://docs.aws.amazon.com/zh_cn/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/zh_cn/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/zh_cn/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/zh_cn/iot/latest/developerguide/images/persistent-session.png)


#### 保持活动
<a name="advanced-tests-execution-keep-alive"></a>

此场景验证设备在未收到来自代理的 ping 响应后是否成功断开连接。连接必须配置有效的保持活动计时器。作为此测试的一部分，代理会阻止针对 `PUBLISH`、`SUBSCRIBE` 和 `PINGREQ` 消息发送的所有响应。它还验证正在测试的设备是否断开了 MQTT 连接。

![\[DUT 和代理之间的 KEEP ALIVE 流程。\]](http://docs.aws.amazon.com/zh_cn/iot/latest/developerguide/images/keep-alive.png)


#### 间歇性连接
<a name="advanced-tests-execution-intermittent-connectivity"></a>

此场景验证在代理以随机间隔断开设备连接一段随机时间后，设备是否可以连接回代理。

![\[DUT 和代理之间的 INTERMITTENT CONNECTIVITY 流程。\]](http://docs.aws.amazon.com/zh_cn/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/zh_cn/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/zh_cn/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   
}
```

**场景**  
测试使用案例根据所选操作运行场景来验证设备的行为。有两种类型的场景：  
+ **基本场景**是一些简单的测试，用于验证设备是否可以执行上面作为配置的一部分选择的操作。这些场景是根据配置中指定的操作预先选择的。配置中不需要输入更多内容。
+ **高级场景**是对设备执行的更为复杂的场景，用于验证设备在满足现实条件时是否遵循了最佳实践。这些场景是可选的，可以作为场景数组传递给测试套件的配置输入。

```
{                                
    "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：**  
配置此选项可在所有测试完成后提供一个时间范围，用于监控设备和代理之间的事件。默认值为 5 分钟。此值可配置为 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 长时间测试使用案例的运行时间比常规测试使用案例长。提供了单独的摘要日志，其中列出了运行期间的重要事件，例如设备连接、发布和订阅。详细信息包括测试的内容、未测试的内容和失败的内容。测试会在日志的末尾包含测试使用案例运行期间发生的所有事件的摘要。摘要包括：
+ *设备上配置的“保持活动”计时器。*
+ *设备上配置的持久会话标志。*
+ *测试运行期间的设备连接数。*
+ *设备重新连接回退类型（如果已通过重新连接回退测试验证）。*
+ *在测试使用案例运行期间，设备发布到的主题。*
+ *在测试用例运行期间，设备订阅的主题。*