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á.
# 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.*