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á.
# 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"
}
}
]
```