Crie um executável de caso de teste do IDT - Gratuito RTOS
Use o SDK do cliente do IDTHabilitar comandos da CLI no IDTGravar logs de eventosRelatar resultados ao IDTEspecifique o comportamento de saída

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

Crie um executável de caso de teste do IDT

É possível criar e colocar o executável do caso de teste em uma pasta do pacote de teste das seguintes maneiras:

  • Para pacotes de testes que usam argumentos ou variáveis de ambiente dos arquivos test.json para determinar quais testes executar, você pode criar um único caso de teste executável para todo o pacote de teste ou um executável de teste para cada grupo de teste no pacote de teste.

  • Para um pacote de teste em que você deseja executar testes específicos com base em comandos especificados, você cria um caso de teste executável para cada caso de teste no pacote de teste.

Como redator de teste, é possível determinar qual abordagem é apropriada para seu caso de uso e estruturar o executável do caso de teste de acordo. Certifique-se de fornecer o caminho correto do executável do caso de teste em cada arquivo test.json e de que o executável especificado seja executado corretamente.

Quando todos os dispositivos estiverem prontos para a execução de um caso de teste, o IDT lê os seguintes arquivos:

  • O test.json para o caso de teste selecionado determina os processos a serem iniciados e as variáveis de ambiente a serem definidas.

  • O suite.json para o pacote de teste determina as variáveis de ambiente a serem definidas.

O IDT inicia o processo executável de teste necessário com base nos comandos e argumentos especificados no arquivo test.json e passa as variáveis de ambiente necessárias para o processo.

Use o SDK do cliente do IDT

Os SDKs do IDT Client permitem simplificar a forma como a lógica de teste é escrita em seu executável de teste com comandos de API que podem ser usados para interagir com o IDT e seus dispositivos em teste. No momento, o IDT fornece os seguintes SDKs:

  • SDK do cliente IDT para Python

  • SDK do cliente IDT para Go

  • SDK do cliente IDT para Java

Estes SDKs estão localizados na pasta <device-tester-extract-location>/sdks. Ao criar um novo executável de caso de teste, é preciso copiar o SDK que deseja usar para a pasta que contém o executável do caso de teste e referenciar o SDK em seu código. Esta seção fornece uma breve descrição dos comandos de API disponíveis que você pode usar nos executáveis do seu caso de teste.

Interação do dispositivo

Os comandos a seguir permitem que a comunicação com o dispositivo em teste sem precisar implementar nenhuma interação adicional com o dispositivo e as funções de gerenciamento de conectividade.

ExecuteOnDevice

Permite que pacotes de teste executem comandos shell em um dispositivo compatível com conexões SSH ou Docker shell.

CopyToDevice

Permite que os pacotes de teste copiem um arquivo local da máquina host que executa o IDT para um local especificado em um dispositivo que suporte conexões SSH ou Docker shell.

ReadFromDevice

Permite que os pacotes de teste leiam a partir da porta serial de dispositivos compatíveis com conexões UART.

nota

Como o IDT não gerencia conexões diretas com dispositivos que são feitas usando as informações de acesso a dispositivos do contexto, recomendamos usar esses comandos da API de interação de dispositivos em seus executáveis de casos de teste. No entanto, se esses comandos não atenderem aos requisitos do caso de teste, você poderá recuperar as informações de acesso ao dispositivo do contexto do IDT e usá-las para fazer uma conexão direta com o dispositivo do pacote de teste.

Para fazer uma conexão direta, recupere as informações nos campos device.connectivity e resource.devices.connectivity do dispositivo em teste e dos dispositivos de recursos, respectivamente. Para obter mais informações sobre como usar contexto do IDT, consulte Use o contexto do IDT.

Interação do IDT

Os comandos a seguir permitem que os conjuntos de teste se comuniquem com o IDT.

PollForNotifications

Permite que os pacotes de teste verifiquem as notificações do IDT.

GetContextValue e GetContextString

Permite que os pacotes de teste recuperem valores do contexto do IDT. Para ter mais informações, consulte Use o contexto do IDT.

SendResult

Permite que os pacotes de teste relatem os resultados dos casos de teste ao IDT. Este comando deve ser chamado no final de cada caso de teste em um pacote de teste.

Interação do host

O comando a seguir permite que seus pacotes de teste se comuniquem com a máquina host.

PollForNotifications

Permite que os pacotes de teste verifiquem as notificações do IDT.

GetContextValue e GetContextString

Permite que os pacotes de teste recuperem valores do contexto do IDT. Para ter mais informações, consulte Use o contexto do IDT.

ExecuteOnHost

Permite que os pacotes de teste executem comandos na máquina local e permite que o IDT gerencie o ciclo de vida do executável do caso de teste.

Habilitar comandos da CLI no IDT

O comando run-suite da CLI do IDT fornece várias opções que permitem que o executor de teste personalize a execução do teste. Para permitir que os executores de teste usem estas opções para executar seu pacote de teste personalizado, você implementa o suporte para a CLI do IDT. Se não implementar o suporte, os executores de teste ainda poderão executar testes, mas algumas opções da CLI não funcionarão corretamente. Para fornecer uma experiência ideal ao cliente, recomendamos que você implemente o suporte para os seguintes argumentos para o comando run-suite na CLI do IDT:

timeout-multiplier

Especifica um valor maior que 1,0 que será aplicado a todos os tempos limite durante a execução dos testes.

Os executores de teste podem usar esse argumento para aumentar o tempo limite dos casos de teste que desejam executar. Quando um executor de teste especifica esse argumento em seu comando run-suite, o IDT o usa para calcular o valor da variável de ambiente IDT_TEST_TIMEOUT e define o campo config.timeoutMultiplier no contexto do IDT. Para apoiar este argumento, você deve fazer o seguinte:

  • Em vez de usar diretamente o valor de tempo limite do arquivo test.json, leia a variável de ambiente IDT_TEST_TIMEOUT para obter o valor de tempo limite calculado corretamente.

  • Recupere o valor config.timeoutMultiplier do contexto do IDT e aplique-o a tempos limite de execução prolongados.

Para obter mais informações sobre como sair mais cedo por conta de eventos de tempo limite, consulte Especifique o comportamento de saída.

stop-on-first-failure

Especifica que o IDT deve parar de executar todos os testes se encontrar uma falha.

Quando um executor de teste especifica esse argumento no comando run-suite, o IDT interrompe a execução dos testes assim que encontrar uma falha. No entanto, se os casos de teste estiverem sendo executados em paralelo, isso poderá levar a resultados inesperados. Para implementar o suporte, certifique-se de que, se o IDT encontrar esse evento, sua lógica de teste instrua todos os casos de teste em execução a parar, limpar recursos temporários e relatar o resultado do teste ao IDT. Para obter mais informações sobre sair antecipadamente em falhas, consulte Especifique o comportamento de saída.

group-id e test-id

Especifica que o IDT deve executar somente os grupos de teste ou casos de teste selecionados.

Os executores de teste podem usar esses argumentos com os comandos run-suite para especificar o seguinte comportamento de execução do teste:

  • Execute todos os testes dentro dos grupos de teste especificados.

  • Execute uma seleção de testes de dentro de um grupo de teste especificado.

Para apoiar esses argumentos, a máquina de estados do seu pacote de teste deve incluir um conjunto específico de estados RunTask e Choice em sua máquina de estado. Se não estiver usando uma máquina de estado personalizada, a máquina de estado IDT padrão incluirá os estados necessários e você não precisará realizar nenhuma ação adicional. No entanto, se estiver usando uma máquina de estado personalizada, use Exemplo de máquina de estado: execute grupos de teste selecionados pelo usuário como amostra para adicionar os estados necessários à sua máquina de estado.

Para obter mais informações sobre os comandos da CLI no IDT, consulte Depure e execute pacotes de teste personalizados.

Gravar logs de eventos

Enquanto o teste está sendo executado, você envia dados para stdout e stderr e grava logs de eventos e mensagens de erro no console. Para obter informações sobre o formato das mensagens do console, consulte Formato de mensagem do console.

Quando o IDT terminar de executar o pacote de teste, essas informações também estarão disponíveis no arquivo test_manager.log localizado na pasta <devicetester-extract-location>/results/<execution-id>/logs.

É possível configurar cada caso de teste para gravar os logs de sua execução de teste, incluindo logs do dispositivo em teste, no arquivo <group-id>_<test-id> localizado na pasta <device-tester-extract-location>/results/execution-id/logs. Para fazer isso, recupere o caminho para o arquivo de log do contexto do IDT com a consulta testData.logFilePath, crie um arquivo nesse caminho e grave o conteúdo deseja nele. O IDT atualiza automaticamente o caminho com base no caso de teste que está sendo executado. Se você optar por não criar o arquivo de log para um caso de teste, nenhum arquivo será gerado para esse caso de teste.

É possível configurar seu executável de texto para criar arquivos de log adicionais, conforme necessário, na pasta <device-tester-extract-location>/logs. É recomendado especificar prefixos exclusivos para nomes de arquivos de log para que seus arquivos não sejam substituídos.

Relatar resultados ao IDT

O IDT grava os resultados do teste nos arquivos awsiotdevicetester_report.xml e suite-name_report.xml. Estes arquivos de relatório estão localizados em <device-tester-extract-location>/results/<execution-id>/. Ambos os relatórios capturam os resultados da execução do pacote de teste. Para obter mais informações sobre os esquemas que o IDT usa para esses relatórios, consulte Analise os resultados e logs dos testes do IDT

Para preencher o conteúdo do arquivo suite-name_report.xml, o comando SendResult deve ser usado para relatar os resultados do teste ao IDT antes da conclusão da execução do teste. Se o IDT não conseguir localizar os resultados de um teste, ele emitirá um erro para o caso de teste. O seguinte trecho em Python mostra os comandos para enviar um resultado de teste para o IDT:

request-variable = SendResultRequest(TestResult(result))
client.send_result(request-variable)

Se não reportar os resultados por meio da API, o IDT procurará os resultados do teste na pasta de artefatos de teste. O caminho para essa pasta é armazenado no campo testData.testArtifactsPath no contexto do IDT. Nesta pasta, o IDT usa o primeiro arquivo XML classificado em ordem alfabética localizado como resultado do teste.

Se sua lógica de teste produzir resultados XML JUnit, será possível gravar os resultados do teste em um arquivo XML na pasta de artefatos para fornecer os resultados diretamente ao IDT em vez de analisá-los e depois usar a API para enviá-los ao IDT.

Se usar este método, a lógica de teste deverá resumir com precisão os resultados do teste e formatar o arquivo de resultados no mesmo formato do arquivo suite-name_report.xml. O IDT não realiza nenhuma validação dos dados fornecidos, com as seguintes exceções:

  • O IDT ignora todas as propriedades da tag testsuites. Em vez disso, ele calcula as propriedades da tag a partir dos resultados de outros grupos de teste relatados.

  • Pelo menos uma tag testsuite deve existir nos testsuites.

Como o IDT usa a mesma pasta de artefatos para todos os casos de teste e não exclui os arquivos de resultados entre as execuções de teste, esse método também pode gerar relatórios incorretos, caso o IDT leia o arquivo incorreto. É recomendado o uso do mesmo nome para o arquivo de resultados XML gerado em todos os casos de teste para sobrescrever os resultados de cada caso de teste e garantir que os resultados corretos estejam disponíveis para o IDT usar. Embora seja possível usar uma abordagem mista para gerar relatórios em pacotes de teste, ou seja, usar um arquivo de resultados XML para alguns casos de teste e enviar resultados por meio da API em outros casos, não recomendamos essa abordagem.

Especifique o comportamento de saída

Configure seu executável de texto para sempre sair com um código de saída 0, mesmo se um caso de teste relatar uma falha ou um resultado de erro. Use códigos de saída diferentes de zero somente para indicar que um caso de teste não foi executado ou caso o executável do caso de teste não tenha comunicado nenhum resultado ao IDT. Quando o IDT recebe um código de saída diferente de zero, ele marca que o caso de teste se deparou com um erro que o impediu de ser executado.

O IDT pode solicitar ou esperar a interrupção da execução de um caso de teste antes de concluir os eventos a seguir. Use estas informações para configurar o executável do caso de teste para detectar cada um desses eventos do caso de teste:

Timeout (Tempo limite)

Ocorre quando um caso de teste é executado por mais tempo do que o valor de tempo limite especificado no arquivo test.json. Se o executor do teste usou o argumento timeout-multiplier para especificar um multiplicador de tempo limite, o IDT calcula o valor do tempo limite com o multiplicador.

Para detectar este evento, use a variável de ambiente IDT_TEST_TIMEOUT. Quando um executor de teste inicializa um teste, o IDT define o valor da variável de ambiente IDT_TEST_TIMEOUT como o valor de tempo limite calculado (em segundos) e passa a variável para o executável do caso de teste. É possível ler o valor da variável para definir um cronômetro apropriado.

Interromper

Ocorre quando o executor do teste interrompe o IDT. Por exemplo, ao pressionar Ctrl+C.

Como os terminais propagam sinais para todos os processos secundários, você pode simplesmente configurar um manipulador de sinais em seus casos de teste para detectar sinais de interrupção.

Como alternativa, é possível sondar periodicamente a API para verificar o valor da CancellationRequested booleana na resposta da API PollForNotifications. Quando o IDT recebe um sinal de interrupção, ele define o valor do CancellationRequested booleano como true.

Interrompa na primeira falha

Ocorre quando um caso de teste executado paralelamente ao caso de teste atual falha e o executor de teste usa o argumento stop-on-first-failure para especificar que o IDT deve interromper ao se deparar com uma falha.

Para detectar esse evento, é possível pesquisar periodicamente a API para verificar o valor CancellationRequested do booleano na resposta da API PollForNotifications. Quando o IDT encontra uma falha e é configurado para interromper a primeira falha, ele define o valor do CancellationRequested booleano como true.

Quando um desses eventos ocorre, o IDT espera cinco minutos para que os casos de teste em execução no momento concluam a execução. Se todos os casos de teste em execução não saírem em cinco minutos, o IDT forçará a interrupção de cada um dos processos deles. Se o IDT não tiver recebido os resultados do teste antes da conclusão dos processos, ele marcará os casos de teste como expirados. Como prática recomendada, os seus casos de teste devem executar as seguintes ações quando encontrarem um dos eventos:

  1. Interrompa a execução da lógica de teste normal.

  2. Limpar todos os recursos temporários, como artefatos de teste no dispositivo em teste.

  3. Relate um resultado de teste ao IDT, como uma falha ou erro no teste.

  4. Sair.