As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Casos de teste do Device Advisor
O Device Advisor fornece testes pré-criados em seis categorias.
+ [TLS](device-advisor-tests-tls.md)
+ [MQTT](device-advisor-tests-mqtt.md)
+ [Shadow](device-advisor-tests-shadow.md)
+ [Execução de trabalho](device-advisor-tests-job-execution.md)
+ [Políticas e permissões](device-advisor-tests-permissions-policies.md)
+ [Testes de longa duração](device-advisor-tests-long-duration.md)
## Casos de teste do Device Advisor para se qualificar para o Programa de Qualificação de AWS Dispositivos.
O dispositivo deve passar nos testes a seguir para se qualificar conforme o [Programa de Qualificação de Dispositivos da AWS](https://aws.amazon.com/partners/programs/dqp/).
**nota**
Esta é uma lista revisada dos testes de qualificação.
+ [TLS Connect](device-advisor-tests-tls.md#TLS_Connect) ("TLS Connect")
+ [Certificado de servidor de nome de assunto incorreto do TLS](device-advisor-tests-tls.md#TLS_Incorrect_Subject_Name)(“Nome comum do assunto incorreto [CN]/Nome alternativo do assunto [SAN]”)
+ [TLS Unsecure Server Cert](device-advisor-tests-tls.md#TLS_Unsecure_Server_Cert) ("Not Signed By Recognized CA")
+ [Suporte de dispositivo TLS para pacotes de AWS IoT criptografia (“Suporte de dispositivo TLS AWS IoT para conjuntos](device-advisor-tests-tls.md#TLS_DeviceSupport_For_IOT) de criptografia recomendados”)
+ [TLS Receive Maximum Size Fragments](device-advisor-tests-tls.md#TLS_MaximumSize)("TLS Receive Maximum Size Fragments")
+ [TLS Expired Server Cert](device-advisor-tests-tls.md#TLS_Expired_Server_Cert)("Expired server certificate")
+ [TLS Large Size Server Cert](device-advisor-tests-tls.md#TLS_LargeServerCert)("TLS large Size Server Certificate")
+ [MQTT Connect](device-advisor-tests-mqtt.md#MQTT_Connect) (“Dispositivo envie CONNECT para AWS IoT Core (Happy case)”)
+ [MQTT Subscribe](device-advisor-tests-mqtt.md#MQTT_Subscribe) ("Can Subscribe (Happy Case)")
+ [MQTT Publish](device-advisor-tests-mqtt.md#MQTT_Publish) ("QoS0 (Happy Case)")
+ [MQTT Connect Jitter Retries](device-advisor-tests-mqtt.md#MQTT_ConnectJitterBackoff) (“Device connect retries with jitter backoff - No CONNACK response”)
# TLS
Use esses testes para determinar se o protocolo de segurança da camada de transporte (TLS) entre seus dispositivos AWS IoT é seguro.
**nota**
O Device Advisor agora é compatível com o TLS 1.3.
## Happy Path
**TLS Connect**
Valida se o dispositivo em teste pode concluir o handshake TLS para. AWS IoT Esse teste não valida a implementação do MQTT do dispositivo cliente.
**Example Definição do caso de teste da API:**
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Para obter melhores resultados, recomendamos um valor de tempo limite de dois minutos.
```
"tests":[
{
"name":"my_tls_connect_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Connect",
"version":"0.0.0"
}
}
]
```
**Example Saídas do caso de teste:**
+ **Aprovação** — O dispositivo em teste concluiu o handshake TLS com. AWS IoT
+ **Passe com avisos** — O dispositivo em teste concluiu o handshake TLS com AWS IoT, mas houve mensagens de aviso de TLS do dispositivo ou. AWS IoT
+ **Falha** — O dispositivo em teste falhou ao concluir o handshake TLS AWS IoT devido a um erro de handshake.
**O TLS recebe fragmentos de tamanho máximo**
Esse caso de teste valida que o dispositivo pode receber e processar fragmentos de tamanho máximo do TLS. O dispositivo de teste deve assinar um tópico pré-configurado com QoS 1 para receber uma grande carga. É possível personalizar a carga com a configuração `${payload}`.
**Example Definição do caso de teste da API:**
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Para obter melhores resultados, recomendamos um valor de tempo limite de dois minutos.
```
"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"
}
}
]
```
## Pacotes de criptografia
**Suporte a dispositivos TLS para pacotes de AWS IoT criptografia recomendados**
Valida se os conjuntos de cifras na mensagem Hello do Cliente TLS do dispositivo em teste contêm os [conjuntos de cifras do AWS IoT](transport-security.md) recomendados. Fornece mais informações sobre os conjuntos de cifras compatíveis com o dispositivo.
**Example Definição do caso de teste da API:**
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 2 minutos.
```
"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 Saídas do caso de teste:**
+ **Aprovado** — O dispositivo em conjuntos de cifras de teste contém pelo menos um dos conjuntos de AWS IoT cifras recomendados e não contém nenhum conjunto de cifras não suportado.
+ **Passe com avisos** — Os conjuntos de cifras do dispositivo contêm pelo menos um conjunto de cifras da AWS IoT , mas:
1. Ele não contém nenhum dos conjuntos de cifras recomendados
1. Ele contém pacotes de criptografia que não são suportados pelo. AWS IoT
Sugerimos que você verifique se todos os conjuntos de cifras não compatíveis são seguros.
+ **Falha** — O dispositivo em conjuntos de criptografia de teste não contém nenhum dos conjuntos de criptografia AWS IoT compatíveis.
## Certificado de servidor de tamanho maior
**Certificado de servidor de tamanho maior do TLS**
Valida se o dispositivo pode concluir o handshake TLS com AWS IoT quando recebe e processa um certificado de servidor de tamanho maior. O tamanho do certificado do servidor (em bytes) usado por esse teste é maior do que o usado atualmente no caso de teste do **TLS Connect** e do IoT Core em 20. Durante esse caso de teste AWS IoT , testa o espaço do buffer do seu dispositivo para TLS. Se o espaço do buffer for grande o suficiente, o handshake TLS será concluído sem erros. Esse teste não valida a implementação do MQTT do dispositivo. O caso de teste ocorre após a conclusão do processo de handshake do TLS.
**Example Definição do caso de teste da API:**
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Para obter melhores resultados, recomendamos um valor de tempo limite de dois minutos. Se esse caso de teste falhar, mas o caso de teste do **TLS Connect** for aprovado, recomendamos que você aumente o limite de espaço de buffer do dispositivo para TLS. Aumentar os limites de espaço de buffer garante que o dispositivo possa processar um certificado de servidor de tamanho maior caso o tamanho aumente.
```
"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 Saídas do caso de teste:**
+ **Aprovação** — O dispositivo em teste concluiu o handshake TLS com AWS IoT.
+ **Passe com avisos** — O dispositivo em teste concluiu o handshake TLS com AWS IoT, mas há mensagens de aviso de TLS do dispositivo ou. AWS IoT
+ **Falha — O dispositivo em teste falhou ao concluir o handshake TLS AWS IoT devido a um erro durante o processo de handshake.**
## Certificado de servidor TLS desprotegido
**Não assinado por uma CA reconhecida**
Valida que o dispositivo em teste fecha a conexão se for apresentado um certificado de servidor sem uma assinatura válida da CA ATS. Um dispositivo só deve se conectar a um endpoint que apresente um certificado válido.
**Example Definição do caso de teste da API:**
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 2 minutos.
```
"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 Saídas do caso de teste:**
+ **Passe** — O dispositivo em teste fechou a conexão.
+ **Falha** — O dispositivo em teste concluiu o handshake TLS com. AWS IoT
**Certificado de servidor de nome de assunto incorreto do TLS/Nome comum do assunto incorreto (CN)/Nome alternativo do assunto (SAN)**
Valida se o dispositivo em teste fecha a conexão se for apresentado um certificado de servidor para um nome de domínio diferente do solicitado.
**Example Definição do caso de teste da API:**
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 2 minutos.
```
"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 Saídas do caso de teste:**
+ **Passe** — O dispositivo em teste fechou a conexão.
+ **Falha** — O dispositivo em teste concluiu o handshake TLS com. AWS IoT
## Certificado de servidor TLS expirado
**Certificado de servidor expirado**
Valida que o dispositivo em teste fecha a conexão se for apresentado um certificado de servidor expirado.
**Example Definição do caso de teste da API:**
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 2 minutos.
```
"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 Saídas do caso de teste:**
+ **Aprovação** — O dispositivo em teste se recusa a concluir o handshake TLS com. AWS IoT O dispositivo envia uma mensagem de alerta do TLS antes de fechar a conexão.
+ **Passe com avisos** — O dispositivo em teste se recusa a concluir o handshake TLS com AWS IoT. No entanto, ele não envia uma mensagem de alerta do TLS antes de fechar a conexão.
+ **Falha** — O dispositivo em teste conclui o handshake TLS com. AWS IoT
# MQTT
## CONECTAR, DESCONECTAR e RECONECTAR
**“Dispositivo envie CONNECT para AWS IoT Core (Happy case)”**
Valida se o dispositivo em teste envia uma solicitação CONNECT.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 2 minutos.
```
"tests":[
{
"name":"my_mqtt_connect_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"MQTT_Connect",
"version":"0.0.0"
}
}
]
```
**“O dispositivo pode retornar o PUBACK a um tópico arbitrário para QoS1”**
Esse caso de teste verificará se o dispositivo (cliente) pode retornar uma mensagem PUBACK se tiver recebido uma mensagem de publicação do agente após assinar um tópico com QoS1.
O conteúdo e o tamanho da carga são configuráveis para esse caso de teste. Se o tamanho da carga estiver configurado, o Device Advisor substituirá o valor do conteúdo da carga e enviará uma carga predefinida para o dispositivo com o tamanho desejado. O tamanho da carga é um valor entre 0 e 128 e não pode exceder 128 KB. O AWS IoT Core rejeita solicitações de publicação e conexão maiores que 128 KB, conforme visto na página de [limites e cotas do protocolo e do agente de mensagens do AWS IoT Core](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits).
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 2 minutos. `PAYLOAD_SIZE` pode ser configurado para um valor entre 0 e 128 kilobytes. A definição de um tamanho de carga substitui o conteúdo da carga, pois o Device Advisor enviará uma carga predefinida com o tamanho determinado de volta ao dispositivo.
```
"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"
}
}
]
```
**“Tentativas de conexão do dispositivo com recuo de variação de sinal - Sem resposta de CONNACK”**
Valida se o dispositivo em teste usa o recuo de variação de sinal adequado ao se reconectar com o agente por pelo menos cinco vezes. O agente registra a data e hora do dispositivo sob a solicitação CONNECT do teste, realiza a validação do pacote, faz uma pausa sem enviar um CONNACK para o dispositivo em teste e espera que o dispositivo em teste reenvie a solicitação. A sexta tentativa de conexão tem permissão para passar, e o CONNACK tem permissão para fluir de volta para o dispositivo em teste.
O processo anterior é executado novamente. No total, esse caso de teste exige que o dispositivo se conecte pelo menos 12 vezes no total. Os registros de data e hora coletados são usados para validar se o recuo de variação de sinal é usado pelo dispositivo em teste. Se o dispositivo em teste tiver um atraso de recuo estritamente exponencial, esse caso de teste será aprovado com avisos.
Recomendamos a implementação do mecanismo [Recuo exponencial e variação de sinal](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) no dispositivo em teste para passar neste caso de teste.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 4 minutos.
```
"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"
}
}
]
```
**“Tentativas de conexão do dispositivo com recuo exponencial - Sem resposta de CONNACK”**
Valida se o dispositivo em teste usa o recuo exponencial adequado ao se reconectar com o agente por pelo menos cinco vezes. O agente registra a data e a hora do dispositivo sob a solicitação CONNECT do teste, realiza a validação do pacote, faz uma pausa sem enviar um CONNACK para o dispositivo cliente e espera que o dispositivo em teste reenvie a solicitação. Os registros de data e hora coletados são usados para validar se um recuo exponencial é usado pelo dispositivo em teste.
Recomendamos a implementação do mecanismo [Recuo exponencial e variação de sinal](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) no dispositivo em teste para passar neste caso de teste.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 4 minutos.
```
"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"
}
}
]
```
**“Reconexão do dispositivo com recuo de variação de sinal - Após a desconexão do servidor”**
Valida se um dispositivo em teste usa a variação de sinal e o recuo necessários ao se reconectar após ser desconectado do servidor. O Device Advisor desconecta o dispositivo do servidor por pelo menos cinco vezes e observa o comportamento do dispositivo na reconexão do MQTT. O Device Advisor registra a data e a hora da solicitação CONNECT para o dispositivo em teste, realiza a validação do pacote, faz uma pausa sem enviar um CONNACK para o dispositivo cliente e espera que o dispositivo em teste reenvie a solicitação. Os registros de data e hora coletados são usados para validar se o dispositivo em teste usa variação de sinal e recuo ao se reconectar. Se o dispositivo em teste tiver um recuo estritamente exponencial ou não implementar um mecanismo de recuo exponencial de variação de sinal adequado, esse caso de teste será aprovado com avisos. Se o dispositivo em teste tiver implementado um mecanismo de recuo linear ou um mecanismo de recuo constante, o teste falhará.
Para passar nesse caso de teste, recomendamos a implementação do mecanismo [Recuo exponencial e variação de sinal](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) no dispositivo em teste.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 4 minutos.
O número de tentativas de reconexão a serem validadas para recuo pode ser alterado especificando `RECONNECTION_ATTEMPTS`. O número deve estar entre 5 e 10. O valor padrão é 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"
}
}
]
```
**“Reconexão do dispositivo com recuo de variação de sinal - Em conexão instável”**
Valida se um dispositivo em teste usa a variação de sinal e o recuo necessários ao se reconectar em uma conexão instável. O Device Advisor desconecta o dispositivo do servidor após cinco conexões bem-sucedidas e observa o comportamento do dispositivo na reconexão do MQTT. O Device Advisor registra a data e a hora da solicitação CONNECT para o dispositivo em teste, realiza a validação do pacote, envia de volta um CONNACK, desconecta-se, registra a data e a hora da desconexão e espera que o dispositivo em teste reenvie a solicitação. Os registros de data e hora coletados são usados para validar se o dispositivo em teste usa variação de sinal e recuo ao se reconectar após conexões bem-sucedidas, mas instáveis. Se o dispositivo em teste tiver um recuo estritamente exponencial ou não implementar um mecanismo de recuo exponencial de variação de sinal adequado, esse caso de teste será aprovado com avisos. Se o dispositivo em teste tiver implementado um mecanismo de recuo linear ou um mecanismo de recuo constante, o teste falhará.
Para passar nesse caso de teste, recomendamos a implementação do mecanismo [Recuo exponencial e variação de sinal](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) no dispositivo em teste.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 4 minutos.
O número de tentativas de reconexão a serem validadas para recuo pode ser alterado especificando `RECONNECTION_ATTEMPTS`. O número deve estar entre 5 e 10. O valor padrão é 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"
}
}
]
```
## Publicar
**“QoS0 (Happy Case)”**
Valida se o dispositivo em teste publica uma mensagem com QoS0 ou QoS1. Você também pode validar o tópico da mensagem e da carga especificando o valor do tópico e a carga nas configurações de teste.
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 2 minutos.
```
"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"
}
}
]
```
**“Tentativa de publicação de QoS1 - Sem PUBACK”**
Valida que o dispositivo em teste republica uma mensagem enviada com QoS1, se o agente não enviar PUBACK. Você também pode validar o tópico da mensagem especificando esse tópico nas configurações de teste. O dispositivo cliente não deve se desconectar antes de republicar a mensagem. Esse teste também valida se a mensagem republicada tem o mesmo identificador de pacote que a original. Durante a execução do teste, se o dispositivo perder a conexão e se reconectar, o caso de teste será reiniciado sem falhas, e o dispositivo deverá executar as etapas do caso de teste novamente.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. É recomendado por pelo menos 4 minutos.
```
"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"
}
}
]
```
**“Publicar mensagens retidas”**
Valida se o dispositivo em teste publica uma mensagem com `retainFlag` definida como true. Você também pode validar o tópico e a carga da mensagem definindo o valor do tópico e a carga nas configurações de teste. Se o `retainFlag` enviado dentro do pacote PUBLICAR não estiver definido como true, o caso de teste falhará.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 2 minutos. Para executar esse caso de teste, adicione a ação `iot:RetainPublish` no [perfil do 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"
}
}
]
```
**“Publicar com propriedade do usuário”**
Valida se o dispositivo em teste publica uma mensagem com a propriedade de usuário correta. Você pode validar a propriedade do usuário definindo o par nome-valor nas configurações de teste. Se a propriedade do usuário não for fornecida ou não corresponder, o caso de teste falhará.
*Definição do caso de teste da API:*
Esse é o MQTT5 único caso de teste.
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 2 minutos.
```
"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"
}
}
]
```
## Assinar
**“Pode assinar (Happy Case)”**
Valida se o dispositivo em teste assina os tópicos do MQTT. Você também pode validar o tópico que o dispositivo em teste assina especificando esse tópico nas configurações de teste.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 2 minutos.
```
"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"
}
}
]
```
**“Nova tentativa de assinar - Sem SUBACK”**
Valida se o dispositivo em teste tenta novamente uma assinatura com falha dos tópicos do MQTT. O servidor, então, espera e não envia um SUBACK. Se o dispositivo cliente não repetir a assinatura, o teste falhará. O dispositivo cliente deve tentar novamente a assinatura com falha com o mesmo ID de pacote. Você também pode validar o tópico que o dispositivo em teste assina especificando esse tópico nas configurações de teste. Durante a execução do teste, se o dispositivo perder a conexão e se reconectar, o caso de teste será reiniciado sem falhas, e o dispositivo deverá executar as etapas do caso de teste novamente.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 4 minutos.
```
"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 Ack PingResp”**
Este caso de teste valida se o dispositivo em teste se desconecta quando não recebe uma resposta de ping. Como parte desse caso de teste, o Device Advisor bloqueia respostas enviadas AWS IoT Core para solicitações de publicação, assinatura e ping. Também valida se o dispositivo em teste desconecta a conexão do MQTT.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um tempo limite maior que 1,5 vezes o valor `keepAliveTime`.
O máximo `keepAliveTime` não deve ser maior que 230 segundos para este teste.
```
"tests":[
{
"name":"Mqtt No Ack PingResp",
"configuration":
//optional:
"EXECUTION_TIMEOUT":"306", // in seconds
},
"test":{
"id":"MQTT_No_Ack_PingResp",
"version":"0.0.0"
}
}
]
```
## Sessão persistente
**“Sessão persistente (Happy Case)”**
Este caso de teste valida o comportamento do dispositivo quando desconectado de uma sessão persistente. O caso de teste verifica se o dispositivo pode se reconectar, retomar as assinaturas dos tópicos acionadores sem assinar de novo explicitamente, receber as mensagens armazenadas nos tópicos e funcionar conforme o esperado durante uma sessão persistente. Quando esse caso de teste é aprovado, ele indica que o dispositivo cliente é capaz de manter uma sessão persistente com o AWS IoT Core broker da maneira esperada. Para obter mais informações sobre sessões AWS IoT persistentes, consulte [Usando sessões persistentes do MQTT](https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions).
Nesse caso de teste, espera-se que o dispositivo cliente faça CONNECT com o AWS IoT Core com o sinalizador de sessão limpa definido como false e, em seguida, assine um tópico acionador. Após uma assinatura bem-sucedida, o dispositivo será desconectado pelo AWS IoT Core Device Advisor. Enquanto o dispositivo estiver em um estado desconectado, uma carga de mensagem de QoS 1 será armazenada nesse tópico. O Device Advisor permitirá então que o dispositivo cliente se reconecte ao endpoint de teste. Nesse ponto, como há uma sessão persistente, espera-se que o dispositivo cliente retome assinaturas de tópicos sem enviar nenhum pacote SUBSCRIBE adicional e receba a mensagem de QoS 1 do agente. Após a reconexão, se o dispositivo cliente se inscrever novamente em seu tópico acionador enviando um pacote SUBSCRIBE adicional, and/or se o cliente não receber a mensagem armazenada do tópico acionador, o caso de teste falhará.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de pelo menos 4 minutos. Na primeira conexão, o dispositivo cliente precisa assinar explicitamente um `TRIGGER_TOPIC` que não estava assinado antes. Para passar no caso de teste, o dispositivo cliente deve assinar com sucesso o `TRIGGER_TOPIC` com um QoS 1. Depois de se reconectar, espera-se que o dispositivo cliente entenda que há uma sessão persistente ativa; portanto, ele deve aceitar a mensagem armazenada enviada pelo tópico acionador e retornar PUBACK para essa mensagem específica.
```
"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"
}
}
]
```
**“Sessão persistente - Expiração da sessão”**
Este caso de teste ajuda a validar o comportamento do dispositivo quando um dispositivo desconectado se reconecta a uma sessão persistente expirada. Depois que a sessão expirar, esperamos que o dispositivo assine novamente os tópicos assinados anteriormente, enviando explicitamente um novo pacote SUBSCRIBE.
Durante a primeira conexão, esperamos que o dispositivo de teste SE CONECTE ao agente de AWS IoT, pois seu `CleanSession` sinalizador está definido como falso para iniciar uma sessão persistente. O dispositivo deve então assinar um tópico acionador. Em seguida, o dispositivo é desconectado pelo AWS IoT Core Device Advisor, após uma assinatura bem-sucedida e o início de uma sessão persistente. Após a desconexão, o AWS IoT Core Device Advisor permite que o dispositivo de teste se reconecte ao endpoint de teste. Nesse ponto, quando o dispositivo de teste envia outro pacote CONNECT, o AWS IoT Core Device Advisor envia de volta um pacote CONNACK que indica que a sessão persistente expirou. O dispositivo de teste precisa interpretar esse pacote corretamente e espera-se que ele assine novamente o mesmo tópico acionador quando a sessão persistente for encerrada. Se o dispositivo de teste não assinar novamente o tópico acionador, o caso de teste falhará. Para que o teste seja aprovado, o dispositivo precisa entender que a sessão persistente acabou e enviar de volta um novo pacote SUBSCRIBE para o mesmo tópico acionador na segunda conexão.
Se esse caso de teste for aprovado em um dispositivo de teste, isso indicará que o dispositivo é capaz de lidar com a reconexão após a expiração da sessão persistente de uma forma esperada.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de pelo menos 4 minutos. O dispositivo de teste precisa assinar explicitamente um `TRIGGER_TOPIC`, o qual não assinava antes. Para passar no caso de teste, o dispositivo de teste deve enviar um pacote CONNECT com o sinalizador `CleanSession` definido como false e assinar com êxito um tópico acionador com um QoS 1. Depois de uma conexão bem-sucedida, AWS IoT Core o Device Advisor desconecta o dispositivo. Após a desconexão, o AWS IoT Core Device Advisor permite que o dispositivo se reconecte, e espera-se que o dispositivo se inscreva novamente, `TRIGGER_TOPIC` pois o AWS IoT Core Device Advisor teria encerrado a sessão 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
Use esses testes para verificar se seus dispositivos em teste usam o serviço AWS IoT Device Shadow corretamente. Consulte [AWS IoT Serviço Device Shadow](iot-device-shadows.md) para obter mais informações. Se esses casos de teste estiverem configurados no conjunto de testes, será necessário fornecer um objeto ao iniciar a execução do conjunto.
**O MQTT over** não WebSocket é suportado no momento.
## Publicar
***“O dispositivo publica o estado após a conexão (Happy Case)”***
Valida se um dispositivo pode publicar seu estado depois de se conectar ao AWS IoT Core
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 2 minutos.
```
"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"
}
}
]
```
Os `REPORTED_STATE` podem ser fornecidos para validação adicional do estado exato da sombra do dispositivo, após a conexão. Por padrão, esse caso de teste valida o estado de publicação do dispositivo.
Se `SHADOW_NAME` não for fornecido, o caso de teste procurará mensagens publicadas em prefixos de tópicos do tipo de sombra Sem nome (clássico) por padrão. Forneça um nome de sombra se o dispositivo usar o tipo de sombra nomeado. Consulte [Como usar sombras em dispositivos](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html) para obter mais informações.
## Atualizar
***“O dispositivo atualiza o estado reportado para o estado desejado (Happy Case)”***
Valida se o dispositivo lê todas as mensagens de atualização recebidas e sincroniza o estado do dispositivo para corresponder às propriedades de estado desejadas. O dispositivo deve publicar o último estado relatado após a sincronização. Se o dispositivo já tiver uma sombra existente antes de executar o teste, certifique-se de que o estado desejado configurado para o caso de teste e o estado relatado existente ainda não correspondam. Você pode identificar as mensagens de atualização do Shadow enviadas pelo Device Advisor examinando o **ClientToken**campo no documento Shadow como ele será`DeviceAdvisorShadowTestCaseSetup`.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 2 minutos.
```
"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"
}
}
]
```
O `DESIRED_STATE` deve ter pelo menos um atributo e um valor associado.
Se `SHADOW_NAME` não for fornecido, o caso de teste procurará mensagens publicadas em prefixos de tópicos do tipo de sombra Sem nome (clássico) por padrão. Forneça um nome de sombra se o dispositivo usar o tipo de sombra nomeado. Consulte [Como usar sombras em dispositivos](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html) para obter mais informações.
# Execução de trabalho
**“O dispositivo pode concluir a execução de um trabalho”**
Esse caso de teste ajuda você a validar se seu dispositivo é capaz de receber atualizações usando o AWS IoT Jobs e publicar o status de atualizações bem-sucedidas. Para obter mais informações sobre AWS IoT trabalhos, consulte [Trabalhos](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html).
Para executar esse caso de teste com êxito, há dois tópicos da AWS reservados que você precisa conceder ao [Perfil de dispositivo](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-iam-role). Para assinar mensagens relacionadas a atividades de trabalhos, use os tópicos **notify** e **notify-next**. O perfil de dispositivo deve conceder a ação PUBLICAR para os seguintes tópicos:
+ \$1aws/things/**thingName**/jobs/**jobId**/get
+ \$1aws/things/**thingName**/jobs/**jobId**/update
É recomendável conceder ações de SUBSCRIBE e RECEIVE para os seguintes tópicos:
+ **\$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
É recomendável conceder ações de SUBSCRIBE para o seguinte tópico:
+ \$1aws/things/**thingName**/jobs/notify-next
Para obter mais informações sobre esses tópicos reservados, consulte tópicos reservados para [Trabalhos de AWS IoT](https://docs.aws.amazon.com/iot/latest/developerguide/reserved-topics.html#reserved-topics-job).
**O MQTT over** não WebSocket é suportado no momento.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de cinco minutos. Recomendamos um valor de tempo limite de 3 minutos. Dependendo do documento do AWS IoT Job ou da fonte fornecida, ajuste o valor do tempo limite (por exemplo, se um trabalho levar muito tempo para ser executado, defina um valor de tempo limite maior para o caso de teste). Para executar o teste, é necessário um documento de AWS IoT trabalho válido ou uma ID de trabalho já existente. Um documento AWS IoT Job pode ser fornecido como um documento JSON ou um link S3. Se um documento de trabalho for fornecido, fornecer um ID de trabalho é opcional. Se um ID de trabalho for fornecido, o Device Advisor usará esse ID ao criar o AWS IoT Job em seu nome. Se o documento do trabalho não for fornecido, você poderá fornecer um ID existente que esteja na mesma região em que você está executando o caso de teste. Nesse caso, o Device Advisor usará esse AWS IoT Job ao executar o caso de teste.
```
"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"
}
}
]
```
Para obter mais informações sobre como criar e usar documentos de trabalho, consulte o [documento de trabalho](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html).
# Políticas e permissões
Você pode usar os testes a seguir para determinar se as políticas anexadas aos certificados dos dispositivos seguem as melhores práticas padrão.
**O MQTT over** não WebSocket é suportado no momento.
**“As políticas anexadas ao certificado do dispositivo não contêm curingas”**
Valida se as políticas de permissão associadas a um dispositivo seguem as melhores práticas e não concedem ao dispositivo mais permissões do que o necessário.
*Definição do caso de teste da API:*
`EXECUTION_TIMEOUT` tem um valor padrão de 1 minuto. Recomendamos definir um tempo limite de pelo menos 30 segundos.
```
"tests":[
{
"name":"my_security_device_policies",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"60" // in seconds
},
"test": {
"id": "Security_Device_Policies",
"version": "0.0.0"
}
}
]
```
# Testes de longa duração
Os testes de longa duração são um novo conjunto de testes que monitora o comportamento de um dispositivo quando ele opera por longos períodos de tempo. Em comparação com a execução de testes individuais que se concentram em comportamentos específicos de um dispositivo, o teste de longa duração examina o comportamento do dispositivo em uma variedade de cenários do mundo real ao longo da vida útil do dispositivo. O Device Advisor organiza os testes na ordem mais eficiente possível. O teste gera resultados e logs, incluindo um log de resumo com métricas úteis sobre o desempenho do dispositivo durante o teste.
## Caso de teste de longa duração do MQTT
No caso de teste de longa duração do MQTT, o comportamento do dispositivo é observado inicialmente em cenários felizes, como MQTT Connect, Subscribe, Publish e Reconnect. Em seguida, o dispositivo é observado em vários cenários de falha complexos, como MQTT Reconnect Backoff, Long Server Disconnect e Intermittent Connectivity.
## Fluxo de execução de casos de teste de longa duração do MQTT
Há três fases na execução de um caso de teste de longa duração do MQTT:
![\[A “Execução de teste de longa duração do MQTT” que mostra a execução do teste básico, a execução dos testes avançados e o tempo de execução adicional.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/mqtt-execution-flow.png)
### Execução de testes básicos
Nesta fase, o caso de teste executa testes simples em paralelo. O teste valida se o dispositivo tem as operações selecionadas na configuração.
O conjunto de testes básicos pode incluir o seguinte, com base nas operações selecionadas:
#### CONECTAR
Esse cenário valida se o dispositivo é capaz de fazer uma conexão bem-sucedida com o agente.
![\[O fluxo de conexão básico que inclui um dispositivo enviar uma mensagem CONNECT e o Broker responde com uma mensagem CONNACK com um código de retorno bem-sucedido.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/basic-connect.png)
#### PUBLICAR
Este cenário valida se o dispositivo publica com êxito no agente.
##### QoS 0
Este caso de teste valida se o dispositivo envia com êxito uma mensagem `PUBLISH` ao agente durante uma publicação com QoS 0. O teste não espera que a mensagem `PUBACK` seja recebida pelo dispositivo.
![\[O fluxo PUBLISH QoS 0 que inclui um dispositivo enviando uma mensagem PUBLISH com nível de QoS 0.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/Qos0.png)
##### QoS 1
Neste caso de teste, espera-se que o dispositivo envie duas mensagens `PUBLISH` ao agente com QoS 1. Após a primeira mensagem `PUBLISH`, o agente espera por até 15 segundos antes de responder. O dispositivo deve repetir a mensagem `PUBLISH` original com o mesmo identificador de pacote dentro da janela de 15 segundos. Se isso acontecer, o agente responde com uma mensagem `PUBACK`, e o teste é validado. Se o dispositivo não tentar novamente a `PUBLISH`, a `PUBACK` original será enviada ao dispositivo, e o teste será marcado como **Aprovado com avisos**, junto com uma mensagem do sistema. Durante a execução do teste, se o dispositivo perder a conexão e se reconectar, o caso de teste será reiniciado sem falhas, e o dispositivo deverá executar as etapas do cenário de teste novamente.
![\[O fluxo PUBLISH QoS 1 que inclui um dispositivo enviando uma mensagem PUBLISH com nível de QoS 1 e várias interações com o agente.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/Qos1.png)
#### ASSINAR
Este cenário valida se o dispositivo assina com êxito o agente.
##### QoS 0
Este caso de teste valida se o dispositivo envia com êxito uma mensagem `SUBSCRIBE` ao agente durante uma assinatura com QoS 0. O teste não espera que o dispositivo receba uma mensagem SUBACK.
![\[O fluxo SUBSCRIBE QoS 0 que inclui um dispositivo enviando uma mensagem SUBSCRIBE com nível de QoS 0 e um agente respondendo com uma mensagem SUBACK e o código Success Maximum QoS 0.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/subscribe-Qos0.png)
##### QoS 1
Neste caso de teste, espera-se que o dispositivo envie duas mensagens `SUBSCRIBE` ao agente com QoS 1. Após a primeira mensagem `SUBSCRIBE`, o agente espera por até 15 segundos antes de responder. O dispositivo deve repetir a mensagem `SUBSCRIBE` original com o mesmo identificador de pacote dentro da janela de 15 segundos. Se isso acontecer, o agente responde com uma mensagem `SUBACK`, e o teste é validado. Se o dispositivo não tentar novamente a `SUBSCRIBE`, a `SUBACK` original será enviada ao dispositivo, e o teste será marcado como **Aprovado com avisos**, junto com uma mensagem do sistema. Durante a execução do teste, se o dispositivo perder a conexão e se reconectar, o caso de teste será reiniciado sem falhas, e o dispositivo deverá executar as etapas do cenário de teste novamente.
![\[O fluxo SUBSCRIBE QoS 1 que inclui um dispositivo enviando uma mensagem SUBSCRIBE com nível de QoS 1 e várias interações com o agente.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/subscribe-Qos1.png)
#### RECONECTAR
Este cenário valida se o dispositivo se reconecta com êxito ao agente após o dispositivo ser desconectado de uma conexão bem-sucedida. O Device Advisor não desconectará o dispositivo se ele estiver conectado mais de uma vez anteriormente durante o conjunto de testes. Em vez disso, ele marcará o teste como **Aprovado**.
![\[O fluxo RECONNECT entre o DUT e o agente.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/reconnect.png)
### Execução de testes avançados
Nesta fase, o caso de teste executa testes mais complexos em série para validar se o dispositivo segue as melhores práticas. Esses testes avançados estão disponíveis para seleção e podem ser excluídos se não forem necessários. Cada teste avançado tem o próprio valor de tempo limite com base no que o cenário exige.
#### RETURN PUBACK ON QoS 1 SUBSCRIPTION
**nota**
Selecione este cenário somente se o dispositivo for capaz de realizar assinaturas de QoS 1.
Esse cenário valida se, depois que o dispositivo assina um tópico e recebe uma mensagem `PUBLISH` do agente, ele retorna uma mensagem `PUBACK`.
![\[O fluxo RETURN PUBACK ON QoS 1 SUBSCTIPTION entre DUT e o agente.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/return-puback.png)
#### RECEIVE LARGE PAYLOAD
**nota**
Selecione este cenário somente se o dispositivo for capaz de realizar assinaturas de QoS 1.
Esse cenário valida se o dispositivo responde com uma mensagem `PUBACK` após receber uma mensagem `PUBLISH` do agente para um tópico de QoS 1 com uma grande carga. O formato da carga esperada pode ser configurado usando a opção `LONG_PAYLOAD_FORMAT`.
![\[O fluxo RECEIVE LARGE PAYLOAD entre o DUT e o agente.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/large-payload.png)
#### SESSÃO PERSISTENTE
**nota**
Selecione este cenário somente se o dispositivo for capaz de realizar assinaturas de QoS 1 e puder manter uma sessão persistente.
Esse cenário valida o comportamento do dispositivo na manutenção de sessões persistentes. O teste é validado quando as seguintes condições são atendidas:
+ O dispositivo se conecta ao agente com uma assinatura ativa de QoS 1 e sessões persistentes ativadas.
+ O dispositivo se desconecta com sucesso do agente durante a sessão.
+ O dispositivo se reconecta ao agente e retoma as assinaturas dos tópicos acionadores sem assinar de novo esses tópicos explicitamente.
+ O dispositivo recebe com sucesso as mensagens armazenadas pelo agente para os tópicos assinados e funciona conforme o esperado.
Para obter mais informações sobre sessões AWS IoT persistentes, consulte [Usando sessões persistentes do MQTT](https://docs.aws.amazon.com//iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions).
![\[O fluxo PERSISTENT SESSION entre o DUT e o agente.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/persistent-session.png)
#### KEEP ALIVE
Este cenário valida se o dispositivo se desconecta com sucesso depois de não receber uma resposta de ping do agente. A conexão deve ter um cronômetro de keep-alive válido configurado. Como parte desse teste, o agente bloqueia todas as respostas enviadas para mensagens `PUBLISH`, `SUBSCRIBE` e `PINGREQ`. Também valida se o dispositivo em teste desconecta a conexão do MQTT.
![\[O fluxo KEEP ALIVE entre o DUT e o agente.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/keep-alive.png)
#### CONECTIVIDADE INTERMITENTE
Este cenário valida se o dispositivo pode se conectar novamente ao agente depois que ele desconecta o dispositivo em intervalos aleatórios por um período de tempo aleatório.
![\[O fluxo INTERMITTENT CONNECTIVITY entre o DUT e o agente.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/intermittent.png)
#### RECONNECT BACKOFF
Este cenário valida se o dispositivo tem um mecanismo de recuo implementado quando o agente se desconecta dele várias vezes. O Device Advisor relata o tipo de recuo como exponencial, variação de sinal, linear ou constante. O número de tentativas de recuo é configurável usando a opção `BACKOFF_CONNECTION_ATTEMPTS`. O valor padrão é 5. O valor é configurável entre 5 e 10.
Para passar nesse teste, recomendamos a implementação do mecanismo [Recuo exponencial e variação de sinal](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) no dispositivo em teste.
![\[O fluxo RECONNECT BACKOFF entre o DUT e o agente.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/reconnect-backoff.png)
#### DESCONEXÃO LONGA DO SERVIDOR
Este cenário valida se o dispositivo pode se reconectar com êxito após o agente desconectar o dispositivo por um longo período de tempo (até 120 minutos). A hora da desconexão do servidor pode ser configurada usando a opção `LONG_SERVER_DISCONNECT_TIME`. O valor padrão são 120 minutos. Esse valor é configurável de 30 a 120 minutos.
![\[O fluxo LONG SERVER DISCONNECT entre o DUT e o agente.\]](http://docs.aws.amazon.com/pt_br/iot/latest/developerguide/images/longserver-disconnect.png)
### Tempo de execução adicional
O tempo de execução adicional é o tempo que o teste espera após concluir todos os testes acima e antes de encerrar o caso de teste. Os clientes usam esse período adicional para monitorar e registrar todas as comunicações entre o dispositivo e o agente. O tempo de execução adicional pode ser configurado usando a opção `ADDITIONAL_EXECUTION_TIME`. Por padrão, essa opção é definida como 0 minutos e pode ser de 0 a 120 minutos.
## Opções de configuração de teste de longa duração do MQTT
Todas as opções de configuração fornecidas para o teste de longa duração do MQTT são opcionais. As seguintes opções estão disponíveis:
**OPERATIONS**
A lista de operações que o dispositivo executa, como `CONNECT`, `PUBLISH` e `SUBSCRIBE`. O caso de teste executa cenários com base nas operações especificadas. As operações que não são especificadas são consideradas válidas.
```
{
"OPERATIONS": ["PUBLISH", "SUBSCRIBE"]
//by default the test assumes device can CONNECT
}
```
**SCENARIOS**
Com base nas operações selecionadas, o caso de teste executa cenários para validar o comportamento do dispositivo. Há dois tipos de cenários:
+ Os **Cenários básicos** são testes simples que validam se o dispositivo pode realizar as operações selecionadas acima como parte da configuração. Eles são pré-selecionados com base nas operações especificadas na configuração. Mais nenhuma entrada é necessária na configuração.
+ **Cenários avançados** são cenários mais complexos que são executados em relação ao dispositivo para validar se ele segue as práticas recomendadas quando se depara com as condições do mundo real. Eles são opcionais e podem ser passados como uma matriz de cenários para a entrada de configuração do conjunto de testes.
```
{
"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:**
O tempo máximo que o caso de teste aguardará até que todos os testes básicos sejam concluídos. O valor padrão são 60 minutos. Esse valor é configurável de 30 a 120 minutos.
**LONG\$1SERVER\$1DISCONNECT\$1TIME:**
O tempo necessário para que o caso de teste se desconecte e reconecte o dispositivo durante o teste de Desconexão longa do servidor. O valor padrão são 60 minutos. Esse valor é configurável de 30 a 120 minutos.
**ADDITIONAL\$1EXECUTION\$1TIME:**
A configuração dessa opção fornece uma janela de tempo após a conclusão de todos os testes, para monitorar eventos entre o dispositivo e o agente. O valor padrão é 0 minutos. Esse valor é configurável de 0 a 120 minutos.
**BACKOFF\$1CONNECTION\$1ATTEMPTS:**
Essa opção configura o número de vezes que o dispositivo é desconectado pelo caso de teste. Isso é usado pelo teste Recuo de reconexão. O valor padrão é 5 tentativas. Esse valor é configurável de 5 a 10.
**LONG\$1PAYLOAD\$1FORMAT:**
O formato da carga da mensagem que o dispositivo espera quando o caso de teste é publicado em um tópico de QoS 1 assinado pelo dispositivo.
**Definição do caso de teste da 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 de resumo do caso de teste de longa duração do MQTT
O caso de teste de longa duração do MQTT é executado por mais tempo do que os casos de teste normais. É fornecido um log de resumo separado, que lista eventos importantes, como conexões de dispositivos, publicação e assinatura durante a execução. Os detalhes incluem o que foi testado, o que não foi testado e o que falhou. No final do log, o teste inclui um resumo de todos os eventos que aconteceram durante a execução do caso de teste. Isso inclui:
+ *O temporizador Keep Alive está configurado no dispositivo.*
+ *Sinalizador de sessão persistente configurado no dispositivo.*
+ *O número de conexões do dispositivo durante a execução do teste.*
+ *O tipo de recuo de reconexão do dispositivo, se validado para o teste de recuo de reconexão.*
+ *Os tópicos nos quais o dispositivo publicou durante a execução do caso de teste.*
+ *Os tópicos que o dispositivo assinou durante a execução do caso de teste.*