Crie executáveis de casos de teste do IDT - AWS IoT Greengrass
Use o SDK do cliente IDTHabilitar comandos da IDT CLI CLI CLIEscrever registros de eventosReportar 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 executáveis de casos de teste do IDT

Você pode criar e colocar executáveis de casos de teste em uma pasta de suíte de testes das seguintes formas:

  • Para suítes de teste que usam argumentos ou variáveis de ambiente dostest.json arquivos para determinar quais testes devem ser executados, você pode criar um único caso de teste executável para toda a suíte de testes ou um executável de teste para cada grupo de testes na suíte de testes.

  • Para uma suíte de testes 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 na suíte de testes.

Como redator de testes, você pode determinar qual abordagem é apropriada para seu caso de uso e estruturar seu executável de caso de teste de acordo. Certifique-se de fornecer o caminho executável correto do caso de teste em cadatest.json arquivo 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:

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

  • Osuite.json para o conjunto de testes 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 notest.json arquivo e passa as variáveis de ambiente necessárias para o processo.

Use o SDK do cliente IDT

Os SDKs do cliente IDT permitem que você simplifique a forma como você escreve a lógica de teste em seu executável de teste com comandos de API que você pode usar para interagir com o IDT e seus dispositivos em teste. Atualmente, o IDT fornece os seguintes SDKs:

  • SDK do cliente IDT SDK para Python thon thon SDK do cliente

  • SDK do cliente IDT SDK for Go SDK do IDT

  • SDK do cliente IDT SDK for Java Java SDT SDK

Esses SDKs estão localizados na<device-tester-extract-location>/sdks pasta. Ao criar um novo executável de caso de teste, você deve 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 entre dispositivos:

Os comandos a seguir permitem que você se comunique com o dispositivo em teste sem precisar implementar nenhuma função adicional de gerenciamento de conectividade e interação com o dispositivo.

ExecuteOnDevice

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

CopyToDevice

Permite que as suítes de teste copiem um arquivo local da máquina host que executa o IDT para um local especificado em um dispositivo que suporta conexões SSH ou Docker shell.

ReadFromDevice

Permite que as suítes de teste leiam a partir da porta serial de dispositivos que suportam conexões UART.

nota

Como o IDT não gerencia conexões diretas com dispositivos que são feitas usando informações de acesso a dispositivos do contexto, recomendamos usar esses comandos da API de interação de dispositivos em seus executáveis de caso de teste. No entanto, se esses comandos não atenderem aos requisitos do seu 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 a partir da suíte de testes.

Para fazer uma conexão direta, recupere as informações nosresource.devices.connectivity camposdevice.connectivity e do dispositivo em teste e dos dispositivos de recursos, respectivamente. Para obter mais informações sobre como usar o contexto do IDT, consulteUsar o contexto IDT.

Interação com o IDT,

Os comandos a seguir permitem que suas suítes de teste se comuniquem com o IDT.

PollForNotifications

Permite que as suítes de teste verifiquem as notificações do IDT.

GetContextValue e GetContextString

Permite que os conjuntos de testes recuperem valores do contexto do IDT. Para obter mais informações, consulte Usar o contexto IDT.

SendResult

Permite que as suítes de teste relatem os resultados dos casos de teste ao IDT. Esse comando deve ser chamado no final de cada caso de teste em uma suíte de testes.

Interação do anfitrião

O comando a seguir permite que suas suítes de teste se comuniquem com a máquina host.

PollForNotifications

Permite que as suítes de teste verifiquem as notificações do IDT.

GetContextValue e GetContextString

Permite que os conjuntos de testes recuperem valores do contexto do IDT. Para obter mais informações, consulte Usar o contexto IDT.

ExecuteOnHost

Permite que as suítes de teste executem comandos na máquina local e permite que o IDT gerencie o ciclo de vida executável do caso de teste.

Habilitar comandos da IDT CLI CLI CLI

Orun-suite comando IDT CLI fornece várias opções que permitem que o executor de testes personalize a execução do teste. Para permitir que os executores de teste usem essas opções para executar sua suíte de testes personalizada, você implementa o suporte para o IDT CLI. Se você 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 orun-suite comando 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 seurun-suite comando, o IDT o usa para calcular o valor da variável de ambiente IDT_TEST_TIMEOUT e define oconfig.timeoutMultiplier campo no contexto do IDT. Para apoiar esse argumento, você deve fazer o seguinte:

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

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

Para obter mais informações sobre como sair mais cedo devido a eventos de tempo limite, consulteEspecifique 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 em seurun-suite comando, o IDT interrompe a execução dos testes assim que encontrar uma falha. No entanto, se os casos de teste estiverem sendo executados em parallel, 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 como sair em caso de falhas, consulteEspecifique 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 seusrun-suite comandos 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, o orquestrador de teste do seu conjunto de testes deve incluir um conjuntoRunTask eChoice estados específicos em seu orquestrador de teste. Se você não estiver usando uma máquina de estado personalizada, o orquestrador de teste padrão do IDT inclui os estados necessários para você e você não precisa realizar nenhuma ação adicional. No entanto, se você estiver usando um orquestrador de teste personalizado, useExemplo de máquina de estado do: Execute grupos de teste selecionados pelo usuário como exemplo para adicionar os estados necessários em seu orquestrador de teste.

Para obter mais informações sobre comandos da IDT CLI, consulteDepure e execute conjuntos de teste personalizados.

Escrever registros de eventos

Enquanto o teste está sendo executado, você envia dados parastdout estderr para gravar registros de eventos e mensagens de erro no console. Para obter mais informações sobre o formato das mensagens do console, consulteFormato de mensagens do console.

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

Você pode configurar cada caso de teste para gravar os registros de sua execução de teste, incluindo registros do dispositivo em teste, no<group-id>_<test-id> arquivo localizado na<device-tester-extract-location>/results/execution-id/logs pasta. Para fazer isso, recupere o caminho para o arquivo de log do contexto do IDT com atestData.logFilePath consulta, crie um arquivo nesse caminho e grave o conteúdo desejado 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.

Você também pode configurar seu executável de texto para criar arquivos de log adicionais, conforme necessário, na<device-tester-extract-location>/logs pasta. Recomendamos que você especifique prefixos exclusivos para nomes de arquivos de log para que seus arquivos não sejam substituídos.

Reportar resultados ao IDT

O IDT grava os resultados do teste nossuite-name_report.xml arquivosawsiotdevicetester_report.xml e. Esses arquivos do relatório estão localizados em<device-tester-extract-location>/results/<execution-id>/. Ambos os relatórios capturam os resultados da execução da suíte de testes. Para obter mais informações sobre os esquemas que o IDT usa para esses relatórios, consulteRevise os resultados e os registros do teste IDT

Para preencher o conteúdo dosuite-name_report.xml arquivo, você deve usar oSendResult comando para relatar os resultados do teste ao IDT antes que a execução do teste termine. Se o IDT não conseguir localizar os resultados de um teste, ele emitirá um erro para o caso de teste. O seguinte trecho do Python mostra os comandos para enviar um resultado de teste para o IDT:

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

Se você não relatar os resultados por meio da API, o IDT procura os resultados do teste na pasta de artefatos de teste. O caminho para essa pasta é armazenado notestData.testArtifactsPath campo no contexto do IDT. Nessa pasta, o IDT usa o primeiro arquivo XML classificado em ordem alfabética que ele localiza como resultado do teste.

Se sua lógica de teste produzir resultados XML do JUnit, você poderá gravar os resultados do teste em um arquivo XML na pasta de artefatos para fornecer os resultados diretamente ao IDT, em vez de analisar os resultados e usar a API para enviá-los ao IDT.

Se você usar esse método, certifique-se de que sua lógica de teste resuma com precisão os resultados do teste e formate seu arquivo de resultados no mesmo formato dosuite-name_report.xml arquivo. O IDT não realiza nenhuma validação dos dados que você fornece, com as seguintes exceções:

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

  • Pelo menos umatestsuite tag deve existir dentro delatestsuites.

Como o IDT usa a mesma pasta de artefatos para todos os casos de teste e não exclui arquivos de resultados entre as execuções de teste, esse método também pode levar a relatórios errôneos se o IDT ler o arquivo incorreto. Recomendamos que você use o 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 uso do IDT. Embora você possa usar uma abordagem mista para gerar relatórios em sua suíte de testes, ou seja, usar um arquivo de resultados XML para alguns casos de teste e enviar resultados por meio da API para outros, 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 de 0, mesmo que um caso de teste reporte 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 se o executável do caso de teste não conseguiu comunicar nenhum resultado ao IDT. Quando o IDT recebe um código de saída diferente de zero, ele marca que o caso de teste encontrou um erro que o impediu de ser executado.

O IDT pode solicitar ou esperar que um caso de teste pare de ser executado antes de ser concluído nos seguintes eventos. Use essas 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 notest.json arquivo. Se o executor do teste usou otimeout-multiplier argumento para especificar um multiplicador de tempo limite, o IDT calculará o valor do tempo limite com o multiplicador.

Para detectar esse evento, use a variável de ambiente IDT_TEST_TIMEOUT. Quando um executor de teste inicia 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. Você pode ler o valor da variável para definir um cronômetro apropriado.

Interromper

Ocorre quando o executor de teste interrompe o IDT. Por exemplo, pressionandoCtrl+C.

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

Como alternativa, você pode pesquisar periodicamente a API para verificar o valor doCancellationRequested booleano na resposta daPollForNotifications API. Quando o IDT recebe um sinal de interrupção, ele define o valor doCancellationRequested booleano comotrue.

Pare na primeira falha

Ocorre quando um caso de teste que está sendo executado em parallel com o caso de teste atual falha e o executor do teste usa ostop-on-first-failure argumento para especificar que o IDT deve parar quando encontrar alguma falha.

Para detectar esse evento, você pode pesquisar periodicamente a API para verificar o valor doCancellationRequested booleano na resposta daPollForNotifications API. Quando o IDT encontra uma falha e é configurado para parar na primeira falha, ele define o valor doCancellationRequested booleano comotrue.

Quando qualquer um desses eventos ocorre, o IDT espera 5 minutos para que qualquer caso de teste atualmente em execução termine de ser executado. Se todos os casos de teste em execução não saírem em 5 minutos, o IDT forçará a interrupção de cada um de seus processos. Se o IDT não tiver recebido os resultados do teste antes do término dos processos, ele marcará o tempo limite dos casos de teste. Como melhor prática, você deve garantir que seus casos de teste realizem as seguintes ações quando encontrarem um dos eventos:

  1. Pare de executar a lógica de teste normal.

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

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

  4. Saída.