Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Case test di Device Advisor
Device Advisor fornisce test predefiniti in sei categorie.
+ [TLS](device-advisor-tests-tls.md)
+ [MQTT](device-advisor-tests-mqtt.md)
+ [Shadow](device-advisor-tests-shadow.md)
+ [Esecuzione del processo](device-advisor-tests-job-execution.md)
+ [Autorizzazioni e policy](device-advisor-tests-permissions-policies.md)
+ [Test di lunga durata](device-advisor-tests-long-duration.md)
## Casi di test di Device Advisor per qualificarsi per il AWS Device Qualification Program.
Il dispositivo deve superare i seguenti test per essere qualificato in base al [Programma AWS per la qualifica dei dispositivi](https://aws.amazon.com/partners/programs/dqp/).
**Nota**
Questo è un elenco rivisto dei test di qualifica.
+ [Collegamento TLS](device-advisor-tests-tls.md#TLS_Connect) ("TLS Connect")
+ [Certificato server nome oggetto TLS non corretto](device-advisor-tests-tls.md#TLS_Incorrect_Subject_Name) ("Nome comune soggetto non corretto (CN)/Nome alternativo soggetto (SAN)")
+ [Certificato server TLS non sicuro](device-advisor-tests-tls.md#TLS_Unsecure_Server_Cert) ("Non firmato da CA riconosciuta")
+ [Supporto per dispositivi TLS per suite di AWS IoT crittografia («Supporto dispositivi TLS AWS IoT per suite](device-advisor-tests-tls.md#TLS_DeviceSupport_For_IOT) di crittografia consigliate»)
+ [Frammenti di dimensioni massime ricezione TLS](device-advisor-tests-tls.md#TLS_MaximumSize)("Frammenti di dimensioni massime ricezione TLS")
+ [Certificato server scaduto TLS](device-advisor-tests-tls.md#TLS_Expired_Server_Cert)("Certificato server scaduto")
+ [Certificato server di grandi dimensioni TLS](device-advisor-tests-tls.md#TLS_LargeServerCert)("Certificato server di grandi dimensioni TLS")
+ [MQTT Connect](device-advisor-tests-mqtt.md#MQTT_Connect) («Dispositivo invia CONNECT a AWS IoT Core (Happy case)»)
+ [Iscriviti MQTT](device-advisor-tests-mqtt.md#MQTT_Subscribe) ("Puoi iscriverti (Happy Case)")
+ [Pubblica MQTT](device-advisor-tests-mqtt.md#MQTT_Publish) ("QoS0 (Happy Case)")
+ [Tentativi jitter di connessione MQTT](device-advisor-tests-mqtt.md#MQTT_ConnectJitterBackoff)("Tentativi di connessione dispositivo con backoff jitter - Nessuna risposta CONNACK")
# TLS
Utilizza questi test per determinare se il protocollo TLS (Transport Layer Security Protocol) tra i tuoi dispositivi AWS IoT è sicuro.
**Nota**
Device Advisor ora supporta TLS 1.3.
## Happy Path
**Connessione TLS**
Verifica se il dispositivo sottoposto a test è in grado di completare l'handshake TLS verso. AWS IoT Questo test non convalida l'implementazione MQTT del dispositivo client.
**Example Definizione del test case API:**
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Per ottenere risultati ottimali, si consiglia un valore di timeout di 2 minuti.
```
"tests":[
{
"name":"my_tls_connect_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Connect",
"version":"0.0.0"
}
}
]
```
**Example Output del test case:**
+ **Pass**: il dispositivo in test ha completato l'handshake TLS con. AWS IoT
+ **Passato con avvisi**: il dispositivo in test ha completato l'handshake TLS con AWS IoT, ma sono stati ricevuti messaggi di avviso TLS dal dispositivo o. AWS IoT
+ **Errore: il dispositivo sottoposto a test non è riuscito a completare l'handshake TLS con a causa di un errore di handshake.** AWS IoT
**TLS riceve frammenti di dimensioni massime**
Questo caso di test verifica se il dispositivo è in grado di ricevere ed elaborare frammenti di dimensioni massime TLS. Il dispositivo di test deve effettuare la sottoscrizione a un argomento preconfigurato con QoS 1 per ricevere un payload di grandi dimensioni. Il payload può essere personalizzato con la configurazione `${payload}`.
**Example Definizione del test case API:**
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Per ottenere risultati ottimali, si consiglia un valore di timeout di 2 minuti.
```
"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"
}
}
]
```
## Suite di cifratura
**Supporto per dispositivi TLS per le suite di AWS IoT crittografia consigliate**
Verifica che i pacchetti di crittografia nel messaggio TLS Client Hello dal dispositivo sottoposto a test contengano i [pacchetti di crittografia AWS IoT consigliati](transport-security.md). Fornisce ulteriori informazioni sulle suite di crittografia supportate dal dispositivo.
**Example Definizione del test case API:**
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.
```
"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 Output dei test case:**
+ **Pass**: il dispositivo sottoposto a test contiene almeno una delle suite di crittografia AWS IoT consigliate e non contiene suite di crittografia non supportate.
+ **Superato con avvisi**: i pacchetti di crittografia del dispositivo contengono almeno un pacchetto di crittografia AWS IoT ma:
1. Non contengono alcun pacchetto di crittografia consigliato
1. Contiene suite di crittografia che non sono supportate da. AWS IoT
Si consiglia di verificare che gli eventuali pacchetti di crittografia non supportati siano sicuri.
+ **Errore**: il dispositivo sottoposto a test sulle suite di crittografia non contiene nessuna delle suite di crittografia supportate AWS IoT .
## Certificato del server di grandi dimensioni
**Certificato del server di grandi dimensioni TLS**
Verifica se il dispositivo è in grado di completare l'handshake TLS con AWS IoT quando riceve ed elabora un certificato del server di grandi dimensioni. La dimensione del certificato del server (in byte) utilizzato da questo test è maggiore di 20 rispetto a quella attualmente utilizzata nel test case **TLS Connect** e IoT Core. Durante questo test case, AWS IoT verifica lo spazio di buffer del dispositivo per TLS. Se lo spazio nel buffer è sufficientemente grande, l'handshake TLS viene completato senza errori. Questo test non convalida l'implementazione MQTT del dispositivo. Il caso di test termina dopo il completamento del processo di handshake TLS.
**Example Definizione del test case API:**
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Per ottenere risultati ottimali, si consiglia un valore di timeout di 2 minuti. Se questo caso di test non va a buon fine, ma il caso di test **Connessione TLS** viene superato, si consiglia di incrementare il limite di spazio del buffer del dispositivo per TLS. L'aumento del limite di spazio del buffer garantisce che il dispositivo sia in grado di elaborare un certificato del server di dimensioni maggiori nel caso in cui le dimensioni aumentino.
```
"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 Output del test case:**
+ **Pass** (Superato) - Il dispositivo testato ha completato l'handshake TLS con AWS IoT.
+ **Passa con avvisi**: il dispositivo in test ha completato l'handshake TLS con AWS IoT, ma sono presenti messaggi di avviso TLS dal dispositivo o AWS IoT.
+ **Errore: il dispositivo sottoposto a test non è riuscito a completare l'handshake TLS a AWS IoT causa di un errore durante il processo di handshake.**
## Certificato del server non sicuro TLS
**Non firmato da CA riconosciuta**
Verifica che il dispositivo sottoposto a test chiuda la connessione se viene presentato con un certificato del server che non dispone di una firma valida dalla CA ATS. Un dispositivo deve connettersi solo a un endpoint che presenta un certificato valido.
**Example Definizione del test case API:**
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.
```
"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 Output dei test case:**
+ **Pass (Superato)** — Il dispositivo sottoposto a test ha chiuso la connessione.
+ **Fallito**: il dispositivo in test ha completato l'handshake TLS con. AWS IoT
**Certificato del server nome soggetto TLS non corretto/Nome comune soggetto non corretto (CN)/Nome alternativo soggetto (SAN)**
Convalida che il dispositivo in fase di test chiude la connessione se viene presentato con un certificato server per un nome di dominio diverso da quello richiesto.
**Example Definizione del test case API:**
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.
```
"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 Output dei test case:**
+ **Pass (Superato)** — Il dispositivo sottoposto a test ha chiuso la connessione.
+ **Fallito**: il dispositivo in test ha completato l'handshake TLS con. AWS IoT
## Certificato server scaduto TLS
**Certificato del server scaduto**
Convalida che il dispositivo in fase di test chiude la connessione se viene presentato con un certificato server scaduto.
**Example Definizione del test case API:**
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.
```
"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 Output dei test case:**
+ **Superato**: il dispositivo sottoposto al test si rifiuta di completare l'handshake TLS con. AWS IoT Il dispositivo invia un messaggio di avviso TLS prima di chiudere la connessione.
+ **Superato con avvisi**: il dispositivo sottoposto a test rifiuta di completare l'handshake TLS con AWS IoT. Tuttavia, non invia un messaggio di avviso TLS prima di chiudere la connessione.
+ **Fallito**: il dispositivo in test completa l'handshake TLS con. AWS IoT
# MQTT
## CONNETTI, SCONNETTI e RICONNETTI
**«Il dispositivo invia CONNECT a AWS IoT Core (Happy case)»**
Convalida che il dispositivo sottoposto a test invia una richiesta CONNECT.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.
```
"tests":[
{
"name":"my_mqtt_connect_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"MQTT_Connect",
"version":"0.0.0"
}
}
]
```
**"Il dispositivo può restituire PUBACK a un argomento arbitrario per QoS1"**
Questo test case verificherà se il dispositivo (client) può restituire un messaggio PUBACK se ha ricevuto un messaggio di pubblicazione dal broker dopo essersi iscritto a un argomento con QoS1.
Il contenuto e la dimensione del payload sono configurabili per questo test case. Se la dimensione del payload è configurata, Device Advisor sovrascriverà il valore del contenuto del payload e invierà un payload predefinito al dispositivo con le dimensioni desiderate. La dimensione del payload è un valore compreso tra 0 e 128 KB e non può superare i 128 KB. AWS IoT Core rifiuta le richieste di pubblicazione e di connessione superiori a 128 KB, come illustrato nella pagine [Limiti e quote del protocollo e del broker di messaggi AWS IoT Core](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits).
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti. `PAYLOAD_SIZE` può essere configurato su un valore compreso tra 0 e 128 kilobyte. La definizione della dimensione di un payload sostituisce il contenuto del payload poiché Device Advisor invierà al dispositivo un payload predefinito con le dimensioni specificate.
```
"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"
}
}
]
```
**"Riconnessione del dispositivo con backoff del jitter - Nessuna risposta CONNACK"**
Convalida che il dispositivo in fase di test utilizza il backoff jitter corretto quando si ricollega con il broker per almeno cinque volte. Il broker registra il timestamp del dispositivo sotto la richiesta CONNECT del test, esegue la convalida dei pacchetti, si interrompe senza inviare un CONNACK al dispositivo in fase di test e attende che il dispositivo sottoposto a test invii nuovamente la richiesta. Il sesto tentativo di connessione è consentito per passare attraverso e CONNACK è autorizzato a fluire di nuovo al dispositivo in prova.
Il processo precedente viene eseguito di nuovo. In totale, questo test case richiede che il dispositivo si connetta almeno 12 volte in totale. I timestamp raccolti vengono utilizzati per convalidare che il jitter backoff venga utilizzato dal dispositivo in prova. Se il dispositivo sottoposto a test ha un ritardo di backoff strettamente esponenziale, questo test case sarà superato con avvertimenti.
Raccomandiamo l'implementazione del meccanismo [Exponential Backoff And Jitter (Backoff esponenziale e jitter)](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) sul dispositivo sottoposto a test per superare questo test case.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 4 minuti.
```
"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"
}
}
]
```
**"Riconnessione del dispositivo con backoff esponenziale - Nessuna risposta CONNACK"**
Verifica che il dispositivo sottoposto a test utilizzi il backoff esponenziale appropriato durante la riconnessione con il broker per almeno cinque volte. Il broker registra il timestamp del dispositivo sotto la richiesta CONNECT del test, esegue la convalida dei pacchetti, si interrompe senza inviare un CONNACK al dispositivo client e attende che il dispositivo in fase di test invii nuovamente la richiesta. I timestamp raccolti vengono utilizzati per convalidare che il backoff esponenziale venga utilizzato dal dispositivo in prova.
Raccomandiamo l'implementazione del meccanismo [Exponential Backoff And Jitter (Backoff esponenziale e jitter)](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) sul dispositivo sottoposto a test per superare questo test case.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 4 minuti.
```
"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"
}
}
]
```
**"Riconnessione del dispositivo con jitter backoff - Dopo la disconnessione del server"**
Convalida se un dispositivo sottoposto a test utilizza il jitter e il backoff necessari durante la riconnessione dopo che è stato disconnesso dal server. Device Advisor disconnette il dispositivo dal server per almeno cinque volte e osserva il comportamento del dispositivo per la riconnessione MQTT. Device Advisor registra il timestamp della richiesta CONNECT per il dispositivo in fase di test, esegue la convalida dei pacchetti, si interrompe senza inviare un CONNACK al dispositivo client e attende che il dispositivo in fase di test invii nuovamente la richiesta. I timestamp raccolti vengono utilizzati per convalidare che il dispositivo sotttoposto a test utilizzi jitter e backoff durante la riconnessione. Se il dispositivo sottoposto a test ha un backoff strettamente esponenziale o non implementa un meccanismo jitter backoff appropriato, questo test case passerà con avvertimenti. Se il dispositivo sottoposto a test ha implementato un meccanismo di backoff lineare o un meccanismo di backoff costante, il test non andrà a buon fine.
Per superare questo test case, si consiglia di implementare il meccanismo [Exponential Backoff And Jitter (Backoff esponenziale e jitter)](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) sul dispositivo sottoposto a test.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 4 minuti.
Il numero di tentativi di riconnessione da convalidare per il backoff può essere modificato specificando il `RECONNECTION_ATTEMPTS`. Il numero deve essere compreso tra 5 e 10. Il valore predefinito è 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" (Riconnessione del dispositivo con jitter backoff - Connessione instabile)**
Convalida se un dispositivo sottoposto a test utilizza il jitter e il backoff necessari durante la riconnessione su una connessione instabile. Device Advisor disconnette il dispositivo dal server dopo cinque connessioni valide e osserva il comportamento del dispositivo per la riconnessione MQTT. Device Advisor registra il timestamp della richiesta CONNECT per il dispositivo in fase di test, esegue la convalida dei pacchetti, invia un CONNACK, si disconnette, registra il timestamp della disconnessione e attende che il dispositivo in fase di test invii nuovamente la richiesta. I timestamp raccolti vengono utilizzati per convalidare che il dispositivo sottoposto a test utilizzi jitter e backoff durante connessioni corrette ma instabili. Se il dispositivo sottoposto a test ha un backoff strettamente esponenziale o non implementa un meccanismo jitter backoff appropriato, questo test case passerà con avvertimenti. Se il dispositivo sottoposto a test ha implementato un meccanismo di backoff lineare o un meccanismo di backoff costante, il test non andrà a buon fine.
Per superare questo test case, si consiglia di implementare il meccanismo [Exponential Backoff And Jitter (Backoff esponenziale e jitter)](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) sul dispositivo sottoposto a test.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 4 minuti.
Il numero di tentativi di riconnessione da convalidare per il backoff può essere modificato specificando il `RECONNECTION_ATTEMPTS`. Il numero deve essere compreso tra 5 e 10. Il valore predefinito è 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"
}
}
]
```
## Pubblica
**"QoS0 (Happy Case)"**
Verifica che il dispositivo in test pubblichi un messaggio con QoS0 o QoS1. È inoltre possibile convalidare l'argomento del messaggio e il payload specificando il valore dell'argomento e il payload nelle impostazioni di test.
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.
```
"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 riprova pubblicazione - Nessun PUBACK"**
Convalida che il dispositivo in fase di test ripubblica un messaggio inviato con QOS1, se il broker non invia PUBACK. È inoltre possibile convalidare l'argomento del messaggio specificando questo argomento nelle impostazioni di test. Il dispositivo client non deve disconnettersi prima di ripubblicare il messaggio. Questo test conferma inoltre che il messaggio ripubblicato abbia lo stesso identificatore di pacchetto dell'originale. Durante l'esecuzione del test, se il dispositivo perde la connessione e si riconnette, il test case si ripristina senza errori e il dispositivo deve eseguire nuovamente i passaggi del test case.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. È consigliato per almeno 4 minuti.
```
"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"
}
}
]
```
**"Pubblica messaggi mantenuti"**
Convalida che il dispositivo in fase di test pubblica un messaggio `retainFlag` impostato su true. È inoltre possibile convalidare l'argomento e il payload del messaggio impostando il valore dell'argomento e il payload nelle impostazioni di test. Se il `retainFlag` inviato all'interno del pacchetto PUBLISH non è impostato su true, il test case avrà esito negativo.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti. Per eseguire questo test case, aggiungere l'azione `iot:RetainPublish` nel [ruolo del dispositivo](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-iam-role).
```
"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"
}
}
]
```
**"Pubblica con proprietà utente"**
Convalida che il dispositivo in fase di test pubblica un messaggio con la proprietà utente corretta. È possibile convalidare la proprietà utente impostando la coppia nome-valore nelle impostazioni del test. Se la proprietà utente non viene fornita o non corrisponde, il test case ha esito negativo.
*Definizione del test case API:*
Questo è un unico test case. MQTT5
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.
```
"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
**"Puoi iscriverti (Happy Case)"**
Convalida che il dispositivo sottoposto a test si sottoscriva gli argomenti MQTT. È inoltre possibile convalidare l'argomento a cui il dispositivo sottoposto a test sottoscriva specificando questo argomento nelle impostazioni di test.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.
```
"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"
}
}
]
```
**"Riprova sottoscrizione - Nessun SUBACK"**
Convalida che il dispositivo in fase di test tenta una sottoscrizione non riuscita agli argomenti MQTT. Il server attende e non invia un SUBACK. Se il dispositivo client non riprova la sottoscrizione, il test ha esito negativo. Il dispositivo client deve riprovare la sottoscrizione non riuscita con lo stesso pacchetto Id. È inoltre possibile convalidare l'argomento a cui il dispositivo sottoposto a test sottoscriva specificando questo argomento nelle impostazioni di test. Durante l'esecuzione del test, se il dispositivo perde la connessione e si riconnette, il test case si ripristina senza errori e il dispositivo deve eseguire nuovamente i passaggi del test case.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 4 minuti.
```
"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
**«Matt No Acc» PingResp**
Questo test case convalida se il dispositivo sottoposto a test si disconnette quando non riceve una risposta ping. Nell'ambito di questo test case, Device Advisor blocca le risposte inviate AWS IoT Core per le richieste di pubblicazione, sottoscrizione e ping. Convalida anche se il dispositivo sottoposto a test disconnette la connessione MQTT.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un timeout superiore a 1,5 volte il valore `keepAliveTime`.
Il massimo non `keepAliveTime` deve essere superiore a 230 secondi per questo test.
```
"tests":[
{
"name":"Mqtt No Ack PingResp",
"configuration":
//optional:
"EXECUTION_TIMEOUT":"306", // in seconds
},
"test":{
"id":"MQTT_No_Ack_PingResp",
"version":"0.0.0"
}
}
]
```
## Sessione persistente
**"Sessione persistente (happy case)"**
Questo test case convalida il comportamento del dispositivo quando viene disconnesso da una sessione persistente. Il test case verifica se il dispositivo è in grado di riconnettersi, riprendere le sottoscrizioni agli argomenti di attivazione senza sottoscriversi nuovamente in modo esplicito, ricevere i messaggi archiviati negli argomenti e funzionare come previsto durante una sessione persistente. Quando questo test case viene superato, indica che il dispositivo client è in grado di mantenere una sessione persistente con il AWS IoT Core broker nel modo previsto. Per ulteriori informazioni sulle sessioni AWS IoT persistenti, vedere [Utilizzo delle sessioni persistenti MQTT](https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions).
In questo test case, è previsto che il dispositivo client esegua una richiesta CONNECT a AWS IoT Core con un flag di sessione pulita impostato su false, quindi effettui la sottoscrizione a un argomento di attivazione. Dopo un abbonamento riuscito, il dispositivo verrà disconnesso da AWS IoT Core Device Advisor. Mentre il dispositivo si trova nello stato disconnesso, in tale argomento verrà memorizzato un payload del messaggio QoS 1. Device Advisor consentirà quindi al dispositivo client di connettersi nuovamente con l'endpoint di test. A questo punto, poiché esiste una sessione persistente, il dispositivo client riprende le sottoscrizioni degli argomenti senza inviare pacchetti SUBSCRIBE aggiuntivi e ricevere il messaggio QoS 1 dal broker. Dopo la riconnessione, se il dispositivo client si iscrive nuovamente al relativo argomento di attivazione inviando un pacchetto SUBSCRIBE aggiuntivo, and/or se il client non riesce a ricevere il messaggio memorizzato dall'argomento di attivazione, il test case avrà esito negativo.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di almeno 4 minuti. Alla prima connessione, il dispositivo client deve sottoscrivere esplicitamente un `TRIGGER_TOPIC` non sottoscritto in precedenza. Per superare il test case, il dispositivo client deve sottoscrivere correttamente `TRIGGER_TOPIC` con un QoS 1. Dopo la riconnessione, il dispositivo client comprende che esiste una sessione persistente attiva e pertanto accetta il messaggio memorizzato inviato dall'argomento di attivazione e restituisce PUBACK per il messaggio specifico.
```
"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"
}
}
]
```
**"Sessione persistente - Scadenza della sessione"**
Questo test case aiuta a convalidare il comportamento del dispositivo quando un dispositivo disconnesso si riconnette a una sessione persistente scaduta. Dopo la scadenza della sessione, è previsto che il dispositivo sottoscriva nuovamente gli argomenti precedentemente sottoscritti inviando esplicitamente un nuovo pacchetto SUBSCRIBE.
Durante la prima connessione, ci aspettiamo che il dispositivo di test si CONNETTA al broker AWS IoT, poiché il suo `CleanSession` flag è impostato su false per avviare una sessione persistente. Il dispositivo deve quindi sottoscrivere un argomento di attivazione. Quindi il dispositivo viene disconnesso da AWS IoT Core Device Advisor, dopo una sottoscrizione riuscita e l'avvio di una sessione persistente. Dopo la disconnessione, AWS IoT Core Device Advisor consente al dispositivo di test di riconnettersi all'endpoint di test. A questo punto, quando il dispositivo di test invia un altro pacchetto CONNECT, AWS IoT Core Device Advisor restituisce un pacchetto CONNACK che indica che la sessione persistente è scaduta. Il dispositivo di test deve interpretare correttamente questo pacchetto e si prevede che sottoscriva nuovamente lo stesso argomento di attivazione quando la sessione persistente viene terminata. Se il dispositivo di test non sottoscrive di nuovo l'argomento, il test case non riesce. Per superare il test, il dispositivo deve comprendere che la sessione persistente è terminata e inviare un nuovo pacchetto SUBSCRIBE per lo stesso argomento di attivazione nella seconda connessione.
Se il test case di un dispositivo di test riesce, significa che il dispositivo è in grado di gestire la riconnessione alla scadenza della sessione persistente nel modo previsto.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di almeno 4 minuti. Il dispositivo client deve sottoscrivere esplicitamente un `TRIGGER_TOPIC` non sottoscritto in precedenza. Per superare il test case, il dispositivo di test deve inviare un pacchetto CONNECT con il flag `CleanSession` impostato su false e sottoscrivere correttamente un argomento di attivazione con un QoS 1. Dopo una connessione riuscita, AWS IoT Core Device Advisor disconnette il dispositivo. Dopo la disconnessione, AWS IoT Core Device Advisor consente al dispositivo di riconnettersi e si prevede che il dispositivo si iscriva nuovamente alla stessa, `TRIGGER_TOPIC` poiché AWS IoT Core Device Advisor avrebbe interrotto la sessione persistente.
```
"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"
}
}
]
```
# Shadow
Utilizza questi test per verificare che i dispositivi in prova utilizzino correttamente il servizio AWS IoT Device Shadow. Per ulteriori informazioni, consulta [AWS IoT Servizio Device Shadow](iot-device-shadows.md). Se questi test case sono configurati nella suite di test, è necessario fornire una cosa all'avvio dell'esecuzione della suite.
Al momento l'**over MQTT** non WebSocket è supportato.
## Pubblica
***"Il dispositivo pubblica lo stato dopo la connessione (Happy case)"***
Verifica se un dispositivo può pubblicare il suo stato dopo la connessione a AWS IoT Core
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.
```
"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"
}
}
]
```
Il `REPORTED_STATE` può essere fornito per una convalida aggiuntiva sullo stato di shadow esatto del dispositivo dopo la connessione. Per impostazione predefinita, questo test case convalida lo stato di pubblicazione del dispositivo.
Se `SHADOW_NAME` non viene fornito, il test case cerca i messaggi pubblicati nei prefissi dell'argomento del tipo di shadow senza nome (classica) per impostazione predefinita. Fornisci un nome shadow se il dispositivo utilizza il tipo di shadow denominato. Per ulteriori informazioni., consulta [Utilizzo delle copie shadow nei dispositivi](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html).
## Aggiorna
***"Il dispositivo aggiorna lo stato segnalato sullo stato desiderato (Happy case)"***
Convalida se il dispositivo legge tutti i messaggi di aggiornamento ricevuti e sincronizza lo stato del dispositivo in modo che corrisponda alle proprietà dello stato desiderate. Il dispositivo dovrebbe pubblicare l'ultimo stato segnalato dopo la sincronizzazione. Se il dispositivo ha già una shadow esistente prima di eseguire il test, assicurati che lo stato desiderato configurato per il test case e lo stato segnalato esistente non corrispondano già. È possibile identificare i messaggi di aggiornamento Shadow inviati da Device Advisor esaminando il **ClientToken**campo nel documento Shadow così come sarà`DeviceAdvisorShadowTestCaseSetup`.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.
```
"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` deve avere almeno un attributo e un valore associato.
Se `SHADOW_NAME` non viene fornito, il test case cerca i messaggi pubblicati nei prefissi dell'argomento del tipo di shadow senza nome (classico) per impostazione predefinita. Fornisci un nome shadow se il dispositivo utilizza il tipo di shadow denominato. Per ulteriori informazioni, consulta [Utilizzo delle copie shadow nei dispositivi](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html).
# Esecuzione del processo
**"Il dispositivo può completare l'esecuzione di un processo"**
Questo test case consente di verificare se il dispositivo è in grado di ricevere aggiornamenti tramite AWS IoT Jobs e di pubblicare lo stato degli aggiornamenti eseguiti con successo. Per ulteriori informazioni su AWS IoT Jobs, consulta [Jobs](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html).
Per eseguire correttamente questo test case, ci sono due AWS argomenti riservati a cui devi assegnare il [ruolo del dispositivo](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-iam-role). Per effettuare la sottoscrizione ai messaggi relativi all'attività del processo, utilizza gli argomenti **notify** e **notify-next**. Il ruolo del dispositivo deve consentire l'azione PUBLISH per i seguenti argomenti:
+ \$1aws/things/**thingName**/jobs/**jobId**/get
+ \$1aws/things/**thingName**/jobs/**jobId**/update
Si consiglia di concedere le azioni SUBSCRIBE e RECEIVE per i seguenti argomenti:
+ **\$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
Si consiglia di concedere l'azione SUBSCRIBE per il seguente argomento:
+ \$1aws/things/**thingName**/jobs/notify-next
Per ulteriori informazioni su questi argomenti riservati, consulta gli argomenti riservati per [Jobs AWS IoT](https://docs.aws.amazon.com/iot/latest/developerguide/reserved-topics.html#reserved-topics-job).
Al momento l'**over WebSocket MQTT** non è supportato.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 3 minuti. A seconda del documento AWS IoT Job o della fonte forniti, modifica il valore di timeout (ad esempio, se l'esecuzione di un lavoro richiederà molto tempo, definisci un valore di timeout più lungo per il test case). Per eseguire il test, è necessario un documento AWS IoT Job valido o un ID lavoro già esistente. Un documento AWS IoT Job può essere fornito come documento JSON o collegamento S3. Se viene fornito un documento di lavoro, fornire un ID di lavoro è facoltativo. Se viene fornito un Job ID, Device Advisor utilizzerà tale ID durante la creazione del AWS IoT Job per conto dell'utente. Se il documento di lavoro non viene fornito, puoi fornire un ID esistente che si trova nella stessa regione in cui stai eseguendo il test case. In questo caso, Device Advisor utilizzerà quel AWS IoT Job durante l'esecuzione del test case.
```
"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"
}
}
]
```
Per ulteriori informazioni sulla creazione e sull'utilizzo di documenti del processo, consulta [documento del processo](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html).
# Autorizzazioni e policy
Utilizza questi test per determinare se le policy associate ai certificati dei dispositivi seguono le best practice standard.
Al momento l'**over MQTT** non WebSocket è supportato.
**"Le policy allegate al certificato del dispositivo non contengono caratteri jolly"**
Verifica se le policy di autorizzazione associate a un dispositivo seguono le procedure consigliate e non concedono al dispositivo più autorizzazioni del necessario.
*Definizione del test case API:*
`EXECUTION_TIMEOUT` dispone di un valore predefinito di 1 minuto. Si consiglia di impostare un timeout di almeno 30 secondi.
```
"tests":[
{
"name":"my_security_device_policies",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"60" // in seconds
},
"test": {
"id": "Security_Device_Policies",
"version": "0.0.0"
}
}
]
```
# Test di lunga durata
I test di lunga durata sono una nuova suite di test che monitorano il comportamento di un dispositivo quando funziona per periodi di tempo più lunghi. Rispetto all'esecuzione di singoli test che si concentrano sui comportamenti specifici di un dispositivo, il test di lunga durata esamina il comportamento del dispositivo in una varietà di scenari del mondo reale nel corso del ciclo di vita del dispositivo. Device Advisor orchestra i test nell'ordine più efficiente possibile. Il test genera risultati e log, incluso un log di riepilogo con metriche utili sulle prestazioni del dispositivo durante il test.
## Caso di test di lunga durata MQTT
Nel test case di lunga durata MQTT, il comportamento del dispositivo viene inizialmente osservato in scenari di casi di successo come MQTT Connect, Subscribe, Publish e Reconnect. Quindi, il dispositivo viene osservato in diversi scenari di errore complessi come MQTT Reconnect Backoff, Long Server Disconnect e Intermittent Connectivity.
## Flusso di esecuzione del test case di lunga durata MQTT
L'esecuzione di un test case di lunga durata MQTT comprendere tre fasi:
![\[La «Esecuzione del test MQTT a lunga durata» che mostra l'esecuzione dei test di base, l'esecuzione dei test avanzati e il tempo di esecuzione aggiuntivo.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/mqtt-execution-flow.png)
### Esecuzione di test di base
In questa fase, il test case esegue semplici test in parallelo. Il test verifica se il dispositivo dispone delle operazioni selezionate nella configurazione.
Il set di test di base può includere quanto specificato di seguito, in base alle operazioni selezionate.
#### CONNECT
Questo scenario convalida se il dispositivo è in grado di stabilire una connessione con il broker.
![\[Il flusso di connessione di base che include un dispositivo che invia un messaggio CONNECT e Broker risponde con un messaggio CONNACK con un codice di ritorno corretto.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/basic-connect.png)
#### PUBLISH
Questo scenario convalida se il dispositivo pubblica tramite il broker.
##### QoS 0
Questo test case convalida se il dispositivo invia un messaggio `PUBLISH` al broker durante una pubblicazione con QoS 0. Il test non attende che il messaggio `PUBACK` venga ricevuto dal dispositivo.
![\[Il flusso PUBLISH QoS 0 che include un dispositivo che invia un messaggio PUBLISH con livello QoS 0.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/Qos0.png)
##### QoS 1
In questo test case, si prevede che il dispositivo invii due messaggi `PUBLISH` al broker con QoS 1. Dopo il primo messaggio `PUBLISH`, il broker attende per un massimo di 15 secondi prima di rispondere. Il dispositivo deve riprovare a inviare il messaggio `PUBLISH` originale con lo stesso identificatore di pacchetto entro 15 secondi. In tal caso, il broker risponde con un messaggio `PUBACK` e il test viene convalidato. Se il dispositivo non riprova a inviare `PUBLISH`, il `PUBACK` originale viene inviato al dispositivo e il test viene contrassegnato come **Pass with warnings** (Superato con avvertenze), insieme a un messaggio di sistema. Durante l'esecuzione del test, se il dispositivo perde la connessione e si riconnette, lo scenario di test viene ripristinato senza errori e il dispositivo deve eseguire nuovamente i passaggi dello scenario di test.
![\[Il flusso PUBLISH QoS 1 che include un dispositivo che invia un messaggio PUBLISH con livello QoS 1 e interazioni multiple con il broker.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/Qos1.png)
#### SUBSCRIBE
Questo scenario convalida se il dispositivo esegue la sottoscrizione tramite il broker.
##### QoS 0
Questo test case convalida se il dispositivo invia un messaggio `SUBSCRIBE` al broker durante una sottoscrizione con QoS 0. Il test non attende che il dispositivo riceva un messaggio SUBACK.
![\[Il flusso SUBSCRIBE QoS 0 che include un dispositivo che invia un messaggio SUBSCRIBE con livello QoS 0 e un broker che risponde con un messaggio SUBACK e il codice Success Maximum QoS 0.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/subscribe-Qos0.png)
##### QoS 1
In questo test case, si prevede che il dispositivo invii due messaggi `SUBSCRIBE` al broker con QoS 1. Dopo il primo messaggio `SUBSCRIBE`, il broker attende per un massimo di 15 secondi prima di rispondere. Il dispositivo deve riprovare a inviare il messaggio `SUBSCRIBE` originale con lo stesso identificatore di pacchetto entro 15 secondi. In tal caso, il broker risponde con un messaggio `SUBACK` e il test viene convalidato. Se il dispositivo non riprova a inviare `SUBSCRIBE`, il `SUBACK` originale viene inviato al dispositivo e il test viene contrassegnato come **Pass with warnings** (Superato con avvertenze), insieme a un messaggio di sistema. Durante l'esecuzione del test, se il dispositivo perde la connessione e si riconnette, lo scenario di test viene ripristinato senza errori e il dispositivo deve eseguire nuovamente i passaggi dello scenario di test.
![\[Il flusso SUBSCRIBE QoS 1 che include un dispositivo che invia un messaggio SUBSCRIBE con livello QoS 1 e interazioni multiple con il broker.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/subscribe-Qos1.png)
#### RECONNECT
Questo scenario convalida se il dispositivo si riconnette al broker dopo che il dispositivo è stato disconnesso da una connessione. Device Advisor non disconnette il dispositivo se in precedenza si è connesso più di una volta durante la suite di test. Invece, contrassegnerà il test come **Pass** (Superato).
![\[Il flusso RECONNECT tra DUT e il broker.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/reconnect.png)
### Esecuzione di test avanzati
In questa fase, il test case esegue test più complessi in serie per verificare se il dispositivo segue le best practice. Questi test avanzati sono disponibili per la selezione e possono essere disattivati se non necessari. Ogni test avanzato dispone del proprio valore di timeout in base a ciò che lo scenario richiede.
#### RETURN PUBACK ON QoS 1 SUBSCRIPTION
**Nota**
Selezionare questo scenario solo se il dispositivo è in grado di eseguire sottoscrizioni QoS 1.
Questo scenario convalida se il dispositivo restituisce un messaggio `PUBACK` dopo che esegue la sottoscrizione a un argomento e riceve un messaggio `PUBLISH` dal broker.
![\[Il flusso RETURN PUBLACK ON QoS 1 SUBSCRIPTION tra DUT e il broker.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/return-puback.png)
#### RECEIVE LARGE PAYLOAD
**Nota**
Selezionare questo scenario se il dispositivo è in grado di eseguire sottoscrizioni QoS 1.
Questo scenario convalida se il dispositivo risponde con un messaggio `PUBACK` dopo aver ricevuto un messaggio `PUBLISH` dal broker per un argomento QoS 1 con un payload di grandi dimensioni. Il formato di payload previsto può essere configurato utilizzando l'opzione `LONG_PAYLOAD_FORMAT`.
![\[Il flusso RECEIVE LARGE PAYLOAD tra DUT e il broker.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/large-payload.png)
#### PERSISTENT SESSION
**Nota**
Selezionare questo scenario se il dispositivo è in grado di eseguire sottoscrizioni QoS 1 e mantenere una sessione persistente.
Questo scenario convalida il comportamento del dispositivo nel mantenimento di sessioni persistenti. Il test convalida quando vengono soddisfatte le seguenti condizioni:
+ Il dispositivo si connette al broker con una sottoscrizione QoS 1 attivo e sessioni persistenti abilitate.
+ Il dispositivo si disconnette dal broker durante la sessione.
+ Il dispositivo si riconnette al broker e riprende le sottoscrizioni agli argomenti trigger senza effettuare nuovamente la sottoscrizione a questi argomenti in maniera esplicita.
+ Il dispositivo riceve i messaggi archiviati dal broker per gli argomenti sottoscritti e funziona come previsto.
Per ulteriori informazioni sulle sessioni AWS IoT persistenti, vedere [Utilizzo delle sessioni persistenti MQTT](https://docs.aws.amazon.com//iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions).
![\[Il flusso PERSISTENT SESSION tra DUT e il broker.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/persistent-session.png)
#### KEEP ALIVE
Questo scenario cpmvalida se il dispositivo si disconnette dopo che non riceve una risposta ping dal broker. È necessario che nella connessione sia configurato timer keep-alive valido. Come parte di questo test, il broker blocca tutte le risposte inviate per i messaggi `PUBLISH`, `SUBSCRIBE` e `PINGREQ`. Convalida anche se il dispositivo sottoposto a test disconnette la connessione MQTT.
![\[Il flusso KEEP ALIVE tra DUT e il broker.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/keep-alive.png)
#### INTERMITTENT CONNECTIVITY
Questo scenario convalida se il dispositivo può riconnettersi al broker dopo che scollega il dispositivo a intervalli casuali per un periodo di tempo casuale.
![\[Il flusso di CONNETTIVITÀ INTERMITTENTE tra DUT e il broker.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/intermittent.png)
#### RECONNECT BACKOFF
Questo scenario convalida se il dispositivo dispone di un meccanismo di backoff implementato quando il broker si disconnette più volte. Device Advisor segnala il tipo di backoff come esponenziale, jitter, lineare o costante. Il numero di tentativi di backoff è configurabile utilizzando l'opzione `BACKOFF_CONNECTION_ATTEMPTS`. Il valore predefinito è 5. Il valore è configurabile tra 5 e 10.
Per superare questo test, si consiglia di implementare il meccanismo [Exponential Backoff And Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) (Backoff esponenziale e jitter) sul dispositivo in fase di test.
![\[Il flusso RECONNECT BACKOFF tra DUT e il broker.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/reconnect-backoff.png)
#### LONG SERVER DISCONNECT
Questo scenario convalida se il dispositivo può riconnettersi dopo che il broker scollega il dispositivo per un lungo periodo di tempo (fino a 120 minuti). L'ora di disconnessione del server può essere configurata utilizzando l'opzione `LONG_SERVER_DISCONNECT_TIME`. Il valore predefinito è di 120 minuti. Questo valore è configurabile da 30 a 120 minuti.
![\[Il flusso LONG SERVER DISCONNECT tra DUT e il broker.\]](http://docs.aws.amazon.com/it_it/iot/latest/developerguide/images/longserver-disconnect.png)
### Tempo di esecuzione aggiuntivo
Il tempo di esecuzione aggiuntivo è il tempo che il test attende dopo il completamento di tutti i test precedenti e prima di terminare il test case. I clienti utilizzano questo periodo di tempo aggiuntivo per monitorare e registrare tutte le comunicazioni tra il dispositivo e il broker. Il tempo di esecuzione aggiuntivo può essere configurato utilizzando l'opzione `ADDITIONAL_EXECUTION_TIME`. Per impostazione predefinita, questa opzione è impostata su 0 minuti e può essere compresa tra 0 e 120 minuti.
## Opzioni di configurazione del test di lunga durata MQTT
Tutte le opzioni di configurazione fornite per il test di lunga durata MQTT sono opzionali. Sono disponibili le seguenti opzioni:
**OPERAZIONI**
L'elenco delle operazioni eseguite dal dispositivo, ad esempio `CONNECT`, `PUBLISH` e `SUBSCRIBE`. Il test case esegue scenari in base alle operazioni specificate. Le operazioni non specificate sono considerate valide.
```
{
"OPERATIONS": ["PUBLISH", "SUBSCRIBE"]
//by default the test assumes device can CONNECT
}
```
**SCENARI**
In base alle operazioni selezionate, il test case esegue scenari per convalidare il comportamento del dispositivo. Esistono due tipi di scenari:
+ Gli **scenari di base** sono semplici test che verificano se il dispositivo è in grado di eseguire le operazioni selezionate in precedenza come parte della configurazione. Questi sono preselezionati in base alle operazioni specificate nella configurazione. Non è richiesto alcun ulteriore input nella configurazione.
+ Gli **scenari avanzati** sono scenari più complessi che vengono eseguiti rispetto al dispositivo per convalidare se il dispositivo segue le best practice quando soddisfa le condizioni del mondo reale. Questi sono opzionali e possono essere superati come una serie di scenari per l'input di configurazione della suite di test.
```
{
"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:**
Il periodo di tempo massimo che il test case attende per il completamento di tutti i test di base. Il valore predefinito è di 60 minuti. Questo valore è configurabile da 30 a 120 minuti.
**LONG\$1SERVER\$1DISCONNECT\$1TIME:**
Il tempo richiesto dal test case per scollegare e ricollegare il dispositivo durante il test Disconnessione server di lunga durata. Il valore predefinito è di 60 minuti. Questo valore è configurabile da 30 a 120 minuti.
**ADDITIONAL\$1EXECUTION\$1TIME:**
La configurazione di questa opzione fornisce una finestra temporale dopo il completamento di tutti i test, per monitorare gli eventi tra il dispositivo e il broker. Il valore predefinito è di 0 minuti. Questo valore è configurabile da 0 a 120 minuti.
**BACKOFF\$1CONNECTION\$1ATTEMPTS:**
Questa opzione configura il numero di volte in cui il dispositivo viene disconnesso dal test case. Viene utilizzato dal test Riconnessione backoff. Il valore predefinito è 5. Questo valore è configurabile da 5 a 10.
**LONG\$1PAYLOAD\$1FORMAT:**
Il formato del payload del messaggio atteso dal dispositivo quando il test case viene pubblicato in un argomento QoS 1 sottoscritto dal dispositivo.
**Definizione del test case 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"
}
}
]
}
```
## Log di riepilogo del test case di lunga durata MQTT
Il test case di lunga durata MQTT viene eseguito più a lungo rispetto ai normali test case. Durante l'esecuzione, viene fornito un log di riepilogo separato, contenente eventi importanti come connessioni dispositivo, pubblicazione e sottoscrizione. I dettagli includono l'oggetto del test, gli elementi esclusi dal test e gli eventuali errori. Alla fine del log, il test include un riepilogo di tutti gli eventi che si sono verificati durante l'esecuzione del test case. Questo include:
+ *Timer Keep Alive configurato sul dispositivo.*
+ *Flag sessione persistente configurato sul dispositivo.*
+ *Il numero di connessioni del dispositivo durante l'esecuzione del test.*
+ *Il tipo di riconnessione backoff del dispositivo, se convalidato per il test di riconnessione backoff.*
+ *Gli argomenti su cui il dispositivo ha pubblicato durante l'esecuzione del test case.*
+ *Gli argomenti sottoscritti dal dispositivo, durante l'esecuzione del test case.*