Crie um executável IDT de caso de teste - Gratuito RTOS
Use o IDT cliente SDKHabilitar IDT CLI comandosGravar logs de eventosRelate os resultados para 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 IDT de caso de teste

É 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, 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.

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

Use o IDT cliente SDK

O IDT Client SDKs permite simplificar a forma como você escreve a lógica de teste em seu executável de teste com API comandos com os quais você pode interagir IDT e com seus dispositivos em teste. IDTatualmente fornece o seguinteSDKs:

  • IDTCliente SDK para Python

  • IDTCliente SDK para Go

  • IDTCliente SDK para Java

Eles 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 referenciá-lo SDK em seu código. Esta seção fornece uma breve descrição dos API comandos 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 suítes de teste executem comandos shell em um dispositivo compatível com conexões SSH de shell do Docker.

CopyToDevice

Permite que as suítes de teste copiem um arquivo local da máquina host que é executado IDT em um local especificado em um dispositivo compatível com conexões SSH de shell do Docker.

ReadFromDevice

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

nota

Como IDT não gerencia conexões diretas com dispositivos que são feitas usando informações de acesso ao dispositivo do contexto, recomendamos usar esses API comandos de interação do dispositivo nos executáveis do seu caso de teste. No entanto, se esses comandos não atenderem aos requisitos do caso de teste, você poderá recuperar as informações de acesso do dispositivo a partir do IDT contexto 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 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 o IDT contexto, consulteUse o IDT contexto.

IDTinteração

Os comandos a seguir permitem que suas suítes de teste se comuniquem comIDT.

PollForNotifications

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

GetContextValue e GetContextString

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

SendResult

Permite que as suítes de teste relatem os resultados dos casos de teste paraIDT. 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 as suítes de teste verifiquem as notificações deIDT.

GetContextValue e GetContextString

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

ExecuteOnHost

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

Habilitar IDT CLI comandos

O run-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 suporte para o. IDT CLI Se você não implementar o suporte, os executores de teste ainda poderão executar testes, mas algumas CLI opções não funcionarão corretamente. Para fornecer uma experiência ideal ao cliente, recomendamos que você implemente o suporte para os seguintes argumentos do run-suite comando no IDTCLI:

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 run-suite comando, o IDT usa para calcular o valor da variável de TIMEOUT ambiente IDT TEST _ _ e define o config.timeoutMultiplier campo no contexto. IDT Para apoiar este argumento, você deve fazer o seguinte:

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

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

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 IDT deve interromper a execução de todos os testes se houver uma falha.

Quando um executor de teste especifica esse argumento em seu run-suite IDT comando, ele 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 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 para. 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 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 você não estiver usando uma máquina de estado personalizada, a máquina de IDT estado padrão incluirá os estados necessários para você 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 IDT CLI comandos, consulteDepure 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 IDT terminar de executar a suíte de testes, essas informações também estarão disponíveis no test_manager.log arquivo localizado na <devicetester-extract-location>/results/<execution-id>/logs pasta.

É 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 IDT contexto com a testData.logFilePath consulta, crie um arquivo nesse caminho e grave o conteúdo que você deseja nele. IDTatualiza 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.

Relate os resultados para IDT

IDTgrava os resultados do teste no awsiotdevicetester_report.xml e nos suite-name_report.xml arquivos. 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 IDT usados para esses relatórios, consulte Analise os IDT resultados e registros dos testes

Para preencher o conteúdo do suite-name_report.xml arquivo, você deve usar o SendResult comando para relatar os resultados do teste IDT antes que a execução do teste termine. Se 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 os quais enviar o resultado do teste: IDT

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

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

Se sua lógica de teste produzir JUnit XML resultados, você poderá gravar os resultados do teste em um XML arquivo na pasta de artefatos para fornecer os resultados diretamente, IDT em vez de analisá-los e depois usá-los API para enviá-los. 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. IDTnão realiza nenhuma validação dos dados que você fornece, com as seguintes exceções:

  • IDTignora todas as propriedades da testsuites tag. 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 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 incorretos se IDT ler o arquivo incorreto. Recomendamos que você use o mesmo nome para o arquivo de XML resultados 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 IDT para uso. Embora você possa usar uma abordagem mista para gerar relatórios em sua suíte de testes, ou seja, usar um arquivo de XML resultados para alguns casos de teste e enviar resultados por meio do arquivo 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 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 se o executável do caso de teste não conseguiu comunicar nenhum resultado. IDT Quando 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.

IDTpode solicitar ou esperar que um caso de teste pare de ser executado antes de ser concluído nos seguintes eventos. 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 de teste usou o timeout-multiplier argumento para especificar um multiplicador de tempo limite, IDT calcula o valor do tempo limite com o multiplicador.

Para detectar esse evento, use a variável de TIMEOUT ambiente IDT TEST _ _. Quando um executor de teste inicia um teste, IDT define o valor da variável de TIMEOUT ambiente IDT _ TEST _ para 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 é interrompidoIDT. 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, você pode pesquisar periodicamente o API para verificar o valor do CancellationRequested booleano na PollForNotifications API resposta. Quando 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 stop-on-first-failure argumento para especificar que ele IDT deve parar quando encontra alguma falha.

Para detectar esse evento, você pode pesquisar periodicamente o API para verificar o valor do CancellationRequested booleano na PollForNotifications API resposta. Quando IDT encontra uma falha e é configurado para parar na primeira falha, ele define o valor do CancellationRequested booleano como. true

Quando qualquer um desses eventos ocorrer, IDT aguarda 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, IDT força cada um de seus processos a parar. Se não IDT tiver recebido os resultados do teste antes do término dos processos, ele marcará os casos de teste como tendo expirado. 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 paraIDT, como uma falha ou erro no teste.

  4. Sair.