本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 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)

## Device Advisor 測試案例以符合 AWS Device Qualification Program 的資格。
<a name="qualifiying-test-cases"></a>

根據 [AWS 裝置資格計畫](https://aws.amazon.com/partners/programs/dqp/)，您的裝置必須通過下列測試才能符合資格。

**注意**  
這是資格測試修訂清單。
+ [TLS Connect](device-advisor-tests-tls.md#TLS_Connect) (TLS 連接) (「TLS 連接」)
+ [TLS Incorrect Subject Name Server Cert](device-advisor-tests-tls.md#TLS_Incorrect_Subject_Name) (TLS 不正確的主體名稱伺服器憑證) (「不正確的主體通用名稱 (CN) / 主體別名 (SAN)」)
+ [TLS Unsecure Server Cert](device-advisor-tests-tls.md#TLS_Unsecure_Server_Cert) (TLS 不安全的伺服器憑證) (「未由認可的 CA 簽署」)
+ [TLS 裝置支援 AWS IoT 加密套件](device-advisor-tests-tls.md#TLS_DeviceSupport_For_IOT) (「TLS 裝置支援 AWS IoT 建議的加密套件」)
+ [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) ("Device send CONNECT to AWS IoT Core (Happy case)")
+ [MQTT Subscribe](device-advisor-tests-mqtt.md#MQTT_Subscribe) (MQTT 訂閱) (「可訂閱 (Happy 案例)」)
+ [MQTT Publish](device-advisor-tests-mqtt.md#MQTT_Publish) (MQTT 發佈) (「QOS0 (Happy 案例)」)
+ [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。

## 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>

**TLS 裝置支援 AWS IoT 建議的密碼套件**  <a name="TLS_DeviceSupport_For_IOT"></a>
驗證來自待測裝置的 TLS 用戶端 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 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。
+ **失敗** — 測試中的裝置無法完成 TLS 交握， AWS IoT 因為交握過程中發生錯誤。

## 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 之間的值，且不能超過 128 KB。 AWS IoT Core 會拒絕發佈和連接大於 128 KB 的請求，如 [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 到 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>
驗證測試下的裝置在與代理程式重新連線至少五次時，是否使用適當的抖動退避。代理程式記錄測試下裝置的 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 記錄待測裝置的 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 案例)」**  <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"
      }
   }
]
```

## 訂閱
<a name="subscribe"></a>

**「可以訂閱 (Happy 案例)」**  <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 會封鎖從 傳送的回應， 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>

**「持久性階段作業 (Happy 案例)」**  
此測試案例會驗證裝置與持久性階段作業中斷連結時的行為。此測試案例會檢查裝置是否可以重新連接、恢復其觸發程序主題訂閱而不需明確重新訂閱、接收儲存於主題中的訊息，以及在持久性階段作業期間如預期運作。當此測試案例通過時，表示用戶端裝置能夠以預期的方式與 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 將允許用戶端裝置與測試端點重新連結。此時由於有持久性工作階段，用戶端裝置應恢復其主題訂閱，而不需傳送任何額外的訂閱封包，並從代理程式接收 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 封包，指出持久性工作階段已過期。測試裝置需要正確解譯此封包，並且在持久性工作階段終止時，應再次重新訂閱相同的觸發程序主題。如果測試裝置未重新訂閱其主題觸發程序，則測試案例失敗。為了通過測試，裝置需要了解持久性工作階段已經結束，並在第二次連線對同一個觸發程序主題回傳一個新的 SUBSCRIBE 封包。  
如果此測試案例對於某測試裝置通過，表示該裝置能在持久性工作階段過期時以預期的方式處理重新連線。  
*API 測試案例定義：*  
`EXECUTION_TIMEOUT` 的預設值為 5 分鐘。我們建議的逾時值為至少 4 分鐘。測試裝置需要明確訂閱之前沒有訂閱的 `TRIGGER_TOPIC`。要通過測試案例，測試裝置必須在 `CleanSession` 旗標設為 false 下傳送 CONNECT 封包，並成功訂閱具有 QoS 1 的觸發程序主題。成功連線後， AWS IoT Core Device Advisor 會中斷裝置連線。中斷連線後， AWS IoT Core Device Advisor 允許裝置重新連線，且裝置預期會重新訂閱相同的 ，`TRIGGER_TOPIC`因為 AWS IoT Core Device Advisor 會終止持久性工作階段。

```
"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 案例)」***  
驗證裝置是否可以在連線至 後發佈其狀態 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 案例)」***  
驗證您的裝置是否讀取所有收到的更新訊息，並同步處理裝置的狀態以符合所需的狀態屬性。您的裝置應該在同步處理之後發佈其最新回報狀態。如果您的裝置在執行測試之前已有現有影子，請確定針對測試案例設定的所需狀態，以及現有回報狀態並未符合。您可以識別 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` 應該至少有一個屬性和相關聯的值。  
如果未提供 `SHADOW_NAME`，則測試案例會依預設尋找發佈至未具名 (傳統) 影子類型之主題字首的訊息。如果您的裝置使用具名影子類型，請提供影子名稱。如需詳細資訊，請參閱[在裝置中使用影子](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 Job](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 連結的形式提供。如果提供 Job 文件，則可選擇性提供作業 ID。如果提供任務 ID，Device Advisor 將在代表您建立 AWS IoT 任務時使用該 ID。如果未提供 Job 文件，您可以提供與執行測試案例位於相同區域的現有 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 長時間測試案例的執行分為三個階段：

![\[顯示基本測試執行、進階測試執行和其他執行時間的「MQTT 長期測試執行」。\]](http://docs.aws.amazon.com/zh_tw/iot/latest/developerguide/images/mqtt-execution-flow.png)


### 基本測試執行
<a name="basic-tests-execution"></a>

此階段的測試案例會以並行方式執行簡易測試。測試將驗證裝置是否依據在組態中所做的選擇進行操作。

根據所選操作，一組基本測試可以包括以下內容：

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

此案例會驗證裝置是否能夠與代理程式成功建立連線。

![\[基本連線流程，其中包含傳送 CONNECT 訊息的裝置，而 Broker 會以成功的傳回碼回應 CONNACK 訊息。\]](http://docs.aws.amazon.com/zh_tw/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_tw/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_tw/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_tw/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_tw/iot/latest/developerguide/images/subscribe-Qos1.png)


#### 重新連線
<a name="basic-tests-execution-reconnect"></a>

此案例會驗證裝置在從成功的連線中斷之後，是否成功與代理程式重新連線。如果先前已在測試套件期間連線多次，則 Device Advisor 不會中斷裝置連線。相反，它會將測試標記為**通過**。

![\[DUT 與代理程式之間的 RECONNECT 流程。\]](http://docs.aws.amazon.com/zh_tw/iot/latest/developerguide/images/reconnect.png)


### 進階測試執行
<a name="advanced-tests-execution"></a>

此階段的測試案例會以序列方式執行較複雜的測試，以驗證裝置是否遵循最佳實務。這些進階測試可供選擇，若無需要可以選擇不執行。根據案例需求，每項進階測試都各有專屬的逾期值。

#### RETURN PUBACK ON QoS 1 SUBSCRIPTION
<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_tw/iot/latest/developerguide/images/return-puback.png)


#### RECEIVE LARGE PAYLOAD
<a name="advanced-tests-execution-receive-large-payload"></a>

**注意**  
只有當您的裝置能夠執行 QoS 1 訂閱時，才可選取此案例。

此案例會驗證裝置在收到具有大型承載的 QoS 1 主題的代理程式發出的 `PUBLISH` 訊息後，是否會以 `PUBACK` 訊息進行回應。可以使用 `LONG_PAYLOAD_FORMAT` 選項設定預期承載的格式。

![\[DUT 與代理程式之間的接收大型 PAYLOAD 流程。\]](http://docs.aws.amazon.com/zh_tw/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_tw/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/zh_tw/iot/latest/developerguide/images/keep-alive.png)


#### INTERMITTENT CONNECTIVITY
<a name="advanced-tests-execution-intermittent-connectivity"></a>

此案例會驗證代理程式在隨機間隔內與裝置中斷連線之後，裝置是否可以恢復與代理程式的連線。

![\[DUT 與代理程式之間的 INTERMITTENT CONNECTIVITY 流程。\]](http://docs.aws.amazon.com/zh_tw/iot/latest/developerguide/images/intermittent.png)


#### RECONNECT BACKOFF
<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_tw/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_tw/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:**  
若設定此選項，系統會在完成所有測試後提供一個時段，用以監控裝置與代理程式之間的事件。預設值為 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 長時間測試案例的執行時間較常規測試案例更長。會提供個別摘要日誌，其中列出執行期間的裝置連線、發佈和訂閱等重要事件。詳細資訊包括已測試的項目、未測試的項目以及失敗的項目。測試功能會在日誌結尾列出測試案例執行期間所發生全部事件的摘要。其中包含：
+ *在裝置上設定的保持連線計時器。*
+ *裝置上設定的持久性工作階段旗標。*
+ *裝置在測試執行期間的連線次數。*
+ *裝置重新連線退避類型 (若已通過重新連線退避測試的驗證)。*
+ *在測試案例執行期間作為裝置發佈目標的主題。*
+ *裝置在測試案例執行期間訂閱的主題。 *