Aviso de fim do suporte: em 7 de outubro de 2026, AWS o suporte para o. AWS IoT Greengrass Version 1 Depois de 7 de outubro de 2026, você não poderá mais acessar os AWS IoT Greengrass V1 recursos. Para obter mais informações, visite [Migrar de AWS IoT Greengrass Version 1](https://docs.aws.amazon.com/greengrass/v2/developerguide/migrate-from-v1.html). 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á. # Usando o AWS IoT Device Tester para AWS IoT Greengrass V1 AWS IoT O Device Tester (IDT) é uma estrutura de teste disponível para download que permite validar dispositivos de IoT. Como AWS IoT Greengrass Version 1 foi movido para o [modo de manutenção](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html), o IDT AWS IoT Greengrass V1 não gera mais relatórios de qualificação assinados. Você não poderá mais qualificar novos AWS IoT Greengrass V1 dispositivos para serem listados no [Catálogo de AWS Partner Dispositivos](https://devices.amazonaws.com/) por meio do [Programa de Qualificação de AWS Dispositivos](https://aws.amazon.com/partners/dqp/). No entanto, você pode continuar usando o IDT AWS IoT Greengrass V1 para testar seus dispositivos Greengrass V1. Recomendamos que você use o [IDT para AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) para qualificar e listar dispositivos Greengrass no [AWS Partner Catálogo de dispositivos](https://devices.amazonaws.com/). O IDT for AWS IoT Greengrass executado em seu computador host (Windows, macOS ou Linux) conectado ao dispositivo a ser testado. Ele executa testes e agrega resultados. Ele também fornece uma interface de linha de comando para gerenciar o processo de teste. ## AWS IoT Greengrass suíte de qualificação Use o IDT AWS IoT Greengrass para verificar se o software AWS IoT Greengrass Core é executado em seu hardware e pode se comunicar com o. Nuvem AWS Ele também realiza end-to-end testes com AWS IoT Core. Por exemplo, ele verifica que o dispositivo pode enviar e receber mensagens MQTT e processá-las corretamente. ![\[Uma visão geral de como o AWS IoT Device Tester verifica se o software AWS IoT Greengrass principal é executado em seu hardware e pode se comunicar com o. Nuvem AWS\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/images/devicetester_gg.png) AWS IoT Device Tester para AWS IoT Greengrass organizar testes usando os conceitos de *suítes de testes e grupos* de *testes*. + Um conjunto de testes é o conjunto de grupos de teste usado para verificar se um dispositivo funciona com versões específicas do AWS IoT Greengrass. + Um grupo de teste é o conjunto de testes individuais relacionados a um atributo, como implantações de grupo do Greengrass e mensagens MQTT. Para obter mais informações, consulte [Use o IDT para executar o pacote de AWS IoT Greengrass qualificação](idt-gg-qualification.md). ## Conjuntos de teste personalizados A partir do IDT v4.0.0, o IDT for AWS IoT Greengrass combina uma configuração padronizada e um formato de resultado com um ambiente de suíte de testes que permite desenvolver suítes de testes personalizadas para seus dispositivos e software de dispositivos. É possível adicionar testes personalizados para sua própria validação interna ou fornecê-los aos seus clientes para verificação de dispositivo. A forma como um gravador de testes configura um pacote de testes personalizado determina as configurações necessárias para executar conjuntos de testes personalizados. Para obter mais informações, consulte [Usar o IDT para desenvolver e executar os próprios pacotes de testes](idt-custom-tests.md). # Versões compatíveis do AWS IoT Device Tester for AWS IoT Greengrass V1 Como AWS IoT Greengrass Version 1 foi movido para o [modo de manutenção](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html), o IDT AWS IoT Greengrass V1 não gera mais relatórios de qualificação assinados. Recomendamos usar o [IDT para AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html). *Para obter informações sobre o IDT para AWS IoT Greengrass V2, consulte [Usando o AWS IoT Device Tester for AWS IoT Greengrass V2 no Guia](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) do AWS IoT Greengrass V2 desenvolvedor.* **nota** Você recebe uma notificação ao iniciar um teste se o IDT for não AWS IoT Greengrass for compatível com a versão AWS IoT Greengrass que você está usando. Ao fazer download do software, você concorda com o [AWS IoT Acordo de licença do Device Tester](https://docs.aws.amazon.com/greengrass/latest/developerguide/idt-license.html). ## Versões IDT não suportadas para for AWS IoT Greengrass Este tópico lista as versões não suportadas do IDT para. AWS IoT Greengrass Versões não compatíveis não recebem correções de bugs ou atualizações. Para obter mais informações, consulte [Política de suporte para AWS IoT Device Tester for AWS IoT Greengrass V1](idt-support-policy.md). **IDT v4.4.1 para as AWS IoT Greengrass versões v1.11.6, v1.10.5** Notas de release: + Permite validar e qualificar dispositivos que executam o software AWS IoT Greengrass principal v1.11.6 e v1.10.5. + Contém pequenas correções de erros. Versão do conjunto de testes: `GGQ_1.3.1` + Lançado em 20/12/2021 **IDT v4.1.0 para as AWS IoT Greengrass versões v1.11.4, v1.10.4** Notas de release: + Permite validar e qualificar dispositivos que executam o software AWS IoT Greengrass principal v1.11.4 e v1.10.4. + Correção de um problema que fazia com que os registros exibidos durante uma execução de teste usassem tags redundantes. Versão do conjunto de testes: `GGQ_1.3.0` + Lançado em 23/06/2021 + Adiciona novas tentativas para chamadas de API para Lambda, IAM AWS STS e para melhorar o tratamento de problemas de limitação ou de servidor. + Adição de suporte para o Python 3.8 aos casos de teste do ML e Docker. **IDT v4.0.2 para as AWS IoT Greengrass versões v1.11.1, v1.11.0, v1.10.3** Notas de release: + Correção de um problema que fazia com que o IDT mascarasse erros de integração de segurança de hardware (HSI). + Permite que você desenvolva e execute suas suítes de teste personalizadas usando o AWS IoT Device Tester for AWS IoT Greengrass. Para obter mais informações, consulte [Usar o IDT para desenvolver e executar os próprios pacotes de testes](idt-custom-tests.md). + Fornece aplicativos do IDT assinados por código para macOS e Windows. No macOS, se uma mensagem de aviso de segurança for exibida, talvez seja necessário conceder uma exceção de segurança para o IDT. Para obter mais informações, consulte [Exceção de segurança no macOS](idt-troubleshooting.md#macos-notarization-exception). AWS IoT Greengrass não fornece um Dockerfile ou uma imagem Docker para a versão 1.11.1 do software principal. AWS IoT Greengrass Para testar a qualificação do Docker em seu dispositivo, use uma versão anterior do software Core AWS IoT Greengrass .   **IDT v3.2.0 para as AWS IoT Greengrass versões v1.11.0, v1.10.1, v1.10.0** Notas de release: + Por padrão, o IDT só executa os testes necessários para qualificação. Para se qualificar para atributos adicionais, você pode modificar o arquivo [`device.json`](set-config.md#device-config). + Adição de um número de porta em `device.json` que você pode configurar para conexões SSH. + O Docker só oferece suporte ao [gerenciador de fluxo](stream-manager.md) e ao machine learning (ML) sem conteinerização. Os contêineres, o Docker e a integração de segurança de hardware (HSI) não estão disponíveis para os dispositivos Docker. + Nós fundimos `device-ml.json` e `device-hsm.json` no `device.json`.   **IDT v3.1.3 para AWS IoT Greengrass versões: v1.10.x, v1.9.x, v1.8.x** Notas de release: + Foi adicionado suporte para qualificação de recursos de ML para AWS IoT Greengrass v1.10.x e v1.9.x. Agora você pode usar o IDT para validar que seus dispositivos podem realizar inferência de ML localmente com modelos armazenados e treinados na nuvem. + `--stop-on-first-failure` adicionado para o comando `run-suite`. Você pode usar essa opção para configurar o IDT a fim de interromper a execução na primeira falha. Recomendamos usar essa opção durante o estágio de depuração no nível de grupos de teste. + Adição de uma verificação de desvio de relógio para testes MQTT a fim de garantir que o dispositivo em teste use a hora correta do sistema. O tempo usado deve estar dentro de um intervalo de tempo aceitável. + `--update-idt` adicionado para o comando `run-suite`. Você pode usar essa opção para definir a resposta do prompt para atualização do IDT. + `--update-managed-policy` adicionado para o comando `run-suite`. Você pode usar essa opção para definir a resposta do prompt para atualização da política gerenciada. + Adição de uma correção de bug para atualizações automáticas das versões do pacote de testes do IDT. A correção garante que o IDT possa executar os conjuntos de testes mais recentes disponíveis para sua versão do AWS IoT Greengrass .   **IDT v3.0.1 para AWS IoT Greengrass** Notas de release: + Foi adicionado suporte para AWS IoT Greengrass v1.10.1. + Atualizações automáticas das versões do conjunto de testes do IDT. O IDT pode baixar as suítes de teste mais recentes que estão disponíveis para sua AWS IoT Greengrass versão. Com este atributo: + Os conjuntos de testes são versionados usando um formato `major.minor.patch`. A versão inicial do conjunto de testes é `GGQ_1.0.0`. + Você pode baixar novos conjuntos de testes interativamente na interface de linha de comando ou definir o sinalizador `upgrade-test-suite` ao iniciar o IDT. Para obter mais informações, consulte [Versões do pacote de testes](idt-gg-qualification.md#idt-test-suite-versions). + Adição do `list-supported-products`. Você pode usar esse comando para listar o AWS IoT Greengrass e as versões do conjunto de testes compatíveis com a versão instalada do IDT. + Adição do `list-test-cases`. Você pode usar esse comando para listar os casos de teste que estão disponíveis em um grupo de teste. + `test-id` adicionado para o comando `run-suite`. Você pode usar essa opção para executar casos de teste individuais em um grupo de teste.   **IDT v2.3.0 para AWS IoT Greengrass v1.10, v1.9.x e v1.8.x** Ao testar em um dispositivo físico, há suporte para AWS IoT Greengrass v1.10, v1.9.x e v1.8.x. Ao testar em um contêiner Docker, as versões AWS IoT Greengrass v1.10 e v1.9.x são suportadas. Notas de release: + O suporte adicionado para [Executando AWS IoT Greengrass em um contêiner Docker](run-gg-in-docker-container.md). Agora você pode usar o IDT para qualificar e validar se seus dispositivos podem ser executados AWS IoT Greengrass em um contêiner Docker. + Foi adicionada uma [política AWS gerenciada](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) (`AWSIoTDeviceTesterForGreengrassFullAccess`) que define as permissões necessárias para executar o AWS IoT Device Tester. Se novas versões exigirem permissões adicionais, AWS adicione-as a essa política gerenciada para que você não precise atualizar suas permissões do IAM. + Verificações introduzidas para validar se o ambiente (por exemplo, conectividade do dispositivo e conectividade com a Internet) está configurado corretamente antes de executar os casos de teste. + Melhoria do verificador de dependência do Greengrass no IDT para torná-lo mais flexível durante a verificação de libc em dispositivos.   **IDT v2.2.0 para AWS IoT Greengrass v1.10, v1.9.x e v1.8.x** Notas de release: + Foi adicionado suporte para AWS IoT Greengrass v1.10. + Suporte adicionado para o conector de [implantação do aplicativo Docker do Greengrass](docker-app-connector.md) . + Foi adicionado suporte para o [gerenciador de AWS IoT Greengrass streams](stream-manager.md). + Foi adicionado suporte para AWS IoT Greengrass na região da China (Pequim).   **IDT v2.1.0 para AWS IoT Greengrass v1.9.x, v1.8.x e v1.7.x** Notas de release: + Foi adicionado suporte para AWS IoT Greengrass v1.9.4. + Foi adicionado suporte para ARMv6l dispositivos Linux.   **IDT v2.0.0 para AWS IoT Greengrass v1.9.3, v1.9.2, v.1.9.1, v1.9.0, v1.8.4, v1.8.3 e v1.8.2** Notas de release: + Remoção da dependência do Python para o dispositivo em teste. + O tempo de execução do pacote de testes foi reduzido em mais de 50%, agilizando o processo de qualificação. + Tamanho do executável reduzido em mais de 50%, agilizando o download e a instalação. + Aprimoramento do [suporte para multiplicador de tempo limite](idt-troubleshooting.md#test-timeout) para todos os casos de teste. + Mensagens de pós-diagnóstico aprimoradas para agilizar a solução de problemas de erros. + Atualização do modelo de política de permissões necessário para executar o IDT. + Foi adicionado suporte para AWS IoT Greengrass v1.9.3.   **IDT v1.3.3 para v1.9.2, v1.9.1, AWS IoT Greengrass v1.9.0, v1.8.3 e v1.8.2** Notas de release: + Suporte para Greengrass v1.9.2 e v1.8.3 adicionado. + Foi adicionado suporte para o Greengrass OpenWrt. + Adição de login ao dispositivo com nome de usuário e senha SSH. + Foi adicionada uma correção de bug de teste nativa para OpenWrt - ARMv7l plataforma.   **IDT v1.2 para v1.8.1 AWS IoT Greengrass ** Notas de release: + Adição de um multiplicador de tempo limite configurável para abordar e solucionar problemas de tempo limite (por exemplo, conexões de largura de banda baixa).   **IDT v1.1 para v1.8.0 AWS IoT Greengrass ** Notas de release: + Foi adicionado suporte para AWS IoT Greengrass Hardware Security Integration (HSI). + Foi adicionado suporte para AWS IoT Greengrass contêiner e sem contêiner. + Foi adicionada a criação automatizada de funções de AWS IoT Greengrass serviço. + Melhoria na limpeza de recursos de teste. + Adição do relatório de resumo de execução de teste.   **IDT v1.1 para v1.7.1 AWS IoT Greengrass ** Notas de release: + Foi adicionado suporte para AWS IoT Greengrass Hardware Security Integration (HSI). + Foi adicionado suporte para AWS IoT Greengrass contêiner e sem contêiner. + Foi adicionada a criação automatizada de funções de AWS IoT Greengrass serviço. + Melhoria na limpeza de recursos de teste. + Adição do relatório de resumo de execução de teste.   **IDT v1.0 para v1.6.1 AWS IoT Greengrass ** Notas de release: + Foi adicionada uma correção de bug de teste OTA para compatibilidade de AWS IoT Greengrass versões futuras. [Se você estiver usando o IDT v1.0 para AWS IoT Greengrass v1.6.1, deverá criar uma função de serviço do Greengrass.](service-role.md) Em versões posteriores, o IDT cria o perfil de serviço para você. # Use o IDT para executar o pacote de AWS IoT Greengrass qualificação Você pode usar o AWS IoT Device Tester (IDT) AWS IoT Greengrass para verificar se o software AWS IoT Greengrass Core é executado em seu hardware e pode se comunicar com o. Nuvem AWS Ele também realiza end-to-end testes com AWS IoT Core. Por exemplo, ele verifica que o dispositivo pode enviar e receber mensagens MQTT e processá-las corretamente. Como AWS IoT Greengrass Version 1 foi movido para o [modo de manutenção](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html), o IDT AWS IoT Greengrass V1 não gera mais relatórios de qualificação assinados. Se você quiser adicionar seu hardware ao Catálogo de AWS Partner dispositivos, execute o pacote de AWS IoT Greengrass V2 qualificação para gerar relatórios de teste para os quais você possa enviar AWS IoT. Para obter mais informações, consulte [Programa de qualificação de dispositivos do AWS](https://aws.amazon.com/partners/dqp/) e [Versões compatíveis do IDT para AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/dev-test-versions.html). Além de testar dispositivos, o IDT for AWS IoT Greengrass cria recursos (por exemplo, AWS IoT coisas, AWS IoT Greengrass grupos, funções Lambda e assim por diante) em Conta da AWS você para facilitar o processo de qualificação. Para criar esses recursos, o IDT for AWS IoT Greengrass usa AWS as credenciais configuradas no `config.json` arquivo para fazer chamadas de API em seu nome. Esses recursos são provisionados em vários momentos durante o teste. Quando você usa o IDT AWS IoT Greengrass para executar o conjunto de AWS IoT Greengrass qualificação, o IDT executa as seguintes etapas: 1. Carrega e valida o dispositivo e as configuração de credencial. 1. Executa testes selecionados com os recursos locais e de nuvem necessários. 1. Remove recursos locais e de nuvem. 1. Gera relatórios de testes que indicam se o dispositivo passou nos testes necessários para a qualificação. ## Versões do pacote de testes O IDT for AWS IoT Greengrass organiza testes em suítes de testes e grupos de teste. + Um conjunto de testes é o conjunto de grupos de teste usado para verificar se um dispositivo funciona com versões específicas do AWS IoT Greengrass. + Um grupo de teste é o conjunto de testes individuais relacionados a um atributo, como implantações de grupo do Greengrass e mensagens MQTT. Começando com o IDT v3.0.0, os conjuntos de testes são versionados usando um formato `major.minor.patch`, por exemplo `GGQ_1.0.0`. Quando você faz download do IDT, o pacote inclui a versão mais recente do conjunto de testes. **Importante** O IDT é compatível com as três versões mais recentes do conjunto de testes para qualificação do dispositivo. Para obter mais informações, consulte [Política de suporte para AWS IoT Device Tester for AWS IoT Greengrass V1](idt-support-policy.md). Você pode executar `list-supported-products` para listar as versões AWS IoT Greengrass e os conjuntos de testes compatíveis com sua versão atual do IDT. Os testes de versões do conjunto de testes não compatíveis não são válidos para qualificação do dispositivo. O IDT não imprime relatórios de qualificação para versões não compatíveis. ### Atualizações para definições de configuração do IDT Novos testes podem apresentar novas definições de configuração do IDT. + Se as configurações forem opcionais, o IDT continuará executando os testes. + Se as configurações forem necessárias, o IDT notificará você e interromperá a execução. Depois de definir as configurações, reinicie a execução de teste. As definições de configuração estão localizadas na pasta `/configs`. Para obter mais informações, consulte [Defina as configurações de IDT para executar o pacote de AWS IoT Greengrass qualificação](set-config.md). Se uma versão atualizada do conjunto de testes adicionar definições de configuração, o IDT criará uma cópia do arquivo de configuração original em `/configs`. ## Descrições dos grupos de testes ------ #### [ IDT v2.0.0 and later ] **Grupos de teste necessários para a qualificação de núcleo** Esses grupos de teste são necessários para qualificar seu AWS IoT Greengrass dispositivo para o Catálogo de AWS Partner dispositivos. AWS IoT Greengrass Dependências principais Valida se seu dispositivo atende a todos os requisitos de software e hardware do software AWS IoT Greengrass Core. O caso de teste `Software Packages Dependencies` nesse grupo de teste não é aplicável ao testar em um [contêiner do Docker](docker-config-setup.md). Implantação Valida que as funções do Lambda podem ser implantadas no dispositivo. MQTT Verifica a funcionalidade do roteador de AWS IoT Greengrass mensagens verificando a comunicação local entre os dispositivos principais e clientes do Greengrass, que são dispositivos IoT locais. Over-the-Air (OTA) Valida que seu dispositivo pode realizar com êxito uma atualização OTA do software AWS IoT Greengrass Core. Esse grupo de teste não é aplicável ao testar em um [contêiner do Docker](docker-config-setup.md). Versão Verifica se a versão AWS IoT Greengrass fornecida é compatível com a versão do AWS IoT Device Tester que você está usando. **Grupos de testes opcionais** Esses grupos de teste são opcionais. Se você optar por se qualificar para testes opcionais, seu dispositivo será listado com recursos adicionais no Catálogo de AWS Partner dispositivos. Dependências de contêiner Verifica se o dispositivo atende a todos os requisitos de software e hardware para executar as funções do Lambda no modo de contêiner em um núcleo do Greengrass. Esse grupo de teste não é aplicável ao testar em um [contêiner do Docker](docker-config-setup.md). Contêiner de implantação Valida que as funções do Lambda podem ser implantadas no dispositivo e executadas no modo de contêiner em um núcleo do Greengrass. Esse grupo de teste não é aplicável ao testar em um [contêiner do Docker](docker-config-setup.md). Dependências do Docker (compatíveis com IDT v2.2.0 e versões posteriores) Valida que o dispositivo atende a todas as dependências técnicas necessárias para usar o conector de implantação do aplicativo Docker do Greengrass a fim de executar contêineres. Esse grupo de teste não é aplicável ao testar em um [contêiner do Docker](docker-config-setup.md). Integração de segurança de hardware (HSI) Verifica se a biblioteca compartilhada HSI fornecida pode interagir com o módulo de segurança de hardware (HSM) e implementa corretamente o PKCS \$111 necessário. APIs A biblioteca do HSM e compartilhada deve assinar uma CSR, executar operações TLS e fornecer os tamanhos de chaves e o algoritmo de chave pública corretos. Dependências do gerenciador de fluxo (compatíveis com IDT v2.2.0 e versões posteriores) Valida se o dispositivo atende a todas as dependências técnicas necessárias para executar o gerenciador de AWS IoT Greengrass streams. Dependências de Machine Learning (compatíveis com a versão 3.1.0 e posterior do IDT) Valida que o dispositivo atende a todas as dependências técnicas necessárias para executar a inferência de ML localmente. Testes de inferência de Machine Learning (compatíveis com a versão 3.1.0 e posterior do IDT) Valida que a inferência de ML pode ser realizada no dispositivo em teste determinado. Para obter mais informações, consulte [Opcional: configurar o dispositivo para qualificação de ML](idt-ml-qualification.md). Testes de contêiner de inferência de Machine Learning (compatíveis com a versão 3.1.0 e posterior do IDT) Valida que a inferência de ML pode ser realizada no dispositivo em teste determinado e executada em modo de contêiner em um núcleo do Greengrass. Para obter mais informações, consulte [Opcional: configurar o dispositivo para qualificação de ML](idt-ml-qualification.md). ------ #### [ IDT v1.3.3 and earlier ] **Grupos de teste necessários para a qualificação de núcleo** Esses testes são necessários para qualificar seu AWS IoT Greengrass dispositivo para o Catálogo de AWS Partner dispositivos. AWS IoT Greengrass Dependências principais Valida se seu dispositivo atende a todos os requisitos de software e hardware do software AWS IoT Greengrass Core. Combinação (interação de segurança de dispositivo) Verifica a funcionalidade do gerenciador de certificados do dispositivo e a detecção de IP no dispositivo de núcleo do Greengrass alterando as informações de conectividade no grupo do Greengrass na nuvem. O grupo de teste alterna o certificado do AWS IoT Greengrass servidor e verifica se ele AWS IoT Greengrass permite conexões. Implantação (necessária para IDT v1.2 e anterior) Valida que as funções do Lambda podem ser implantadas no dispositivo. Device Certificate Manager (DCM) Verifica se o gerenciador de certificados do AWS IoT Greengrass dispositivo pode gerar um certificado de servidor na inicialização e alternar os certificados se eles estiverem prestes a expirar. Detecção de IP (IPD) Verifica se as informações de conectividade do núcleo estão atualizadas quando há alterações de endereço IP em um dispositivo de núcleo do Greengrass. Para obter mais informações, consulte [Ativar detecção automática de IP](gg-core.md#ip-auto-detect). Registro em log Verifica se o serviço de AWS IoT Greengrass registro pode gravar em um arquivo de log usando uma função Lambda do usuário escrita em Python. MQTT Verifica a AWS IoT Greengrass funcionalidade do roteador de mensagens enviando mensagens sobre um tópico que é roteado para duas funções Lambda. Nativo Verifica se é AWS IoT Greengrass possível executar funções Lambda nativas (compiladas). Over-the-Air (OTA) Valida que seu dispositivo pode realizar com êxito uma atualização OTA do software AWS IoT Greengrass Core. Penetração Valida que o software AWS IoT Greengrass Core falhará ao iniciar se a proteção de link rígido/soft link e o [seccomp](https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt) não estiverem habilitados. Ele também é usado para verificar outros atributos relacionados à segurança. Shadow Verifica a funcionalidade de sombra local e de sincronização de nuvem de sombra. Spooler Valida se as mensagens MQTT são colocadas em fila com a configuração padrão de spooler. Token Exchange Service (TES) Verifica se AWS IoT Greengrass pode trocar seu certificado principal por AWS credenciais válidas. Versão Verifica se a versão AWS IoT Greengrass fornecida é compatível com a versão do AWS IoT Device Tester que você está usando. **Grupos de testes opcionais** Estes testes são opcionais. Se você optar por se qualificar para testes opcionais, seu dispositivo será listado com recursos adicionais no Catálogo de AWS Partner dispositivos. Dependências de contêiner Verifica se o dispositivo atende a todas as dependências necessárias para executar funções do Lambda no modo de contêiner. Integração de segurança de hardware (HSI) Verifica se a biblioteca compartilhada HSI fornecida pode interagir com o módulo de segurança de hardware (HSM) e implementa corretamente o PKCS \$111 necessário. APIs A biblioteca do HSM e compartilhada deve assinar uma CSR, executar operações TLS e fornecer os tamanhos de chaves e o algoritmo de chave pública corretos. Acesso aos recursos locais Verifica o recurso de acesso a recursos locais (LRA) AWS IoT Greengrass fornecendo acesso a arquivos e diretórios locais de propriedade de vários usuários e grupos Linux para funções Lambda em contêineres por meio do LRA. AWS IoT Greengrass APIs As funções do Lambdas devem ter acesso permitido ou negado a recursos locais com base na configuração do acesso aos recurso locais. Rede Verifica se as conexões de soquete podem ser estabelecidas a partir de uma função do Lambda. Essas conexões de soquete devem ser permitidas ou negadas com base na configuração do núcleo do Greengrass. ------ # Pré-requisitos para executar o pacote de qualificação AWS IoT Greengrass Esta seção descreve os pré-requisitos para usar o AWS IoT Device Tester (IDT) AWS IoT Greengrass para executar o pacote de qualificação. AWS IoT Greengrass ## Baixe a versão mais recente do AWS IoT Device Tester para AWS IoT Greengrass Baixe a [versão mais recente](dev-test-versions.md) do IDT e extraia o software em um local no seu sistema de arquivos onde você tenha permissões de leitura e gravação. **nota** O IDT não oferece suporte a execução por vários usuários em um local compartilhado, como um diretório NFS ou uma pasta compartilhada de rede do Windows. Recomendamos extrair o pacote do IDT para uma unidade local e executar o binário do IDT na estação de trabalho local. O Windows tem uma limitação de comprimento de caminho de 260 caracteres. Se você estiver usando o Windows, extraia o IDT para um diretório raiz como `C:\ ` ou `D:\` para manter os caminhos abaixo do limite de 260 caracteres. ## Crie e configure um Conta da AWS Antes de usar o IDT para AWS IoT Greengrass, você deve executar as seguintes etapas: 1. [Crie um Conta da AWS.]() Se você já tem um Conta da AWS, vá para a etapa 2. 1. [Configure permissões para o IDT.]() Essas permissões de conta permitem que a IDT acesse AWS serviços e crie AWS recursos, como AWS IoT coisas, grupos do Greengrass e funções do Lambda, em seu nome. Para criar esses recursos, o IDT for AWS IoT Greengrass usa AWS as credenciais configuradas no `config.json` arquivo para fazer chamadas de API em seu nome. Esses recursos são provisionados em vários momentos durante o teste. **nota** Embora a maioria dos testes se qualifique para o [nível gratuito da Amazon Web Services](https://aws.amazon.com/free), é necessário fornecer um cartão de crédito ao se cadastrar em uma conta da Conta da AWS. Para obter mais informações, consulte [Por que preciso de uma forma de pagamento se minha conta está coberta pelo nível gratuito?](https://aws.amazon.com/premiumsupport/knowledge-center/free-tier-payment-method/). ### Etapa 1: criar um Conta da AWS Nesta etapa, crie e configure uma Conta da AWS. Se você já tem um Conta da AWS, vá para[Etapa 2: Configurar permissões para o IDT](#configure-idt-permissions). #### Inscreva-se para um Conta da AWS Se você não tiver um Conta da AWS, conclua as etapas a seguir para criar um. **Para se inscrever em um Conta da AWS** 1. Abra a [https://portal.aws.amazon.com/billing/inscrição.](https://portal.aws.amazon.com/billing/signup) 1. Siga as instruções online. Parte do procedimento de inscrição envolve receber uma chamada telefônica ou uma mensagem de texto e inserir um código de verificação pelo teclado do telefone. Quando você se inscreve em um Conta da AWS, um *Usuário raiz da conta da AWS*é criado. O usuário-raiz tem acesso a todos os Serviços da AWS e recursos na conta. Como prática recomendada de segurança, atribua o acesso administrativo a um usuário e use somente o usuário-raiz para executar [tarefas que exigem acesso de usuário-raiz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks). AWS envia um e-mail de confirmação após a conclusão do processo de inscrição. A qualquer momento, você pode visualizar a atividade atual da sua conta e gerenciar sua conta acessando [https://aws.amazon.com/e](https://aws.amazon.com/) escolhendo **Minha conta**. #### Criar um usuário com acesso administrativo Depois de se inscrever em um Conta da AWS, proteja seu Usuário raiz da conta da AWS Centro de Identidade do AWS IAM, habilite e crie um usuário administrativo para que você não use o usuário root nas tarefas diárias. **Proteja seu Usuário raiz da conta da AWS** 1. Faça login [Console de gerenciamento da AWS](https://console.aws.amazon.com/)como proprietário da conta escolhendo **Usuário raiz** e inserindo seu endereço de Conta da AWS e-mail. Na próxima página, insira a senha. Para obter ajuda ao fazer login usando o usuário-raiz, consulte [Fazer login como usuário-raiz](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) no *Guia do usuário do Início de Sessão da AWS *. 1. Habilite a autenticação multifator (MFA) para o usuário-raiz. Para obter instruções, consulte [Habilitar um dispositivo de MFA virtual para seu usuário Conta da AWS raiz (console) no Guia](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) do *usuário do IAM*. **Criar um usuário com acesso administrativo** 1. Habilita o Centro de Identidade do IAM. Para obter instruções, consulte [Habilitar o Centro de Identidade do AWS IAM](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) no *Guia do usuário do Centro de Identidade do AWS IAM *. 1. No Centro de Identidade do IAM, conceda o acesso administrativo a um usuário. Para ver um tutorial sobre como usar o Diretório do Centro de Identidade do IAM como fonte de identidade, consulte [Configurar o acesso do usuário com o padrão Diretório do Centro de Identidade do IAM](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) no *Guia Centro de Identidade do AWS IAM do usuário*. **Iniciar sessão como o usuário com acesso administrativo** + Para fazer login com o seu usuário do Centro de Identidade do IAM, use o URL de login enviado ao seu endereço de e-mail quando o usuário do Centro de Identidade do IAM foi criado. Para obter ajuda para fazer login usando um usuário do IAM Identity Center, consulte Como [fazer login no portal de AWS acesso](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) no *Guia Início de Sessão da AWS do usuário*. **Atribuir acesso a usuários adicionais** 1. No Centro de Identidade do IAM, crie um conjunto de permissões que siga as práticas recomendadas de aplicação de permissões com privilégio mínimo. Para obter instruções, consulte [Criar um conjunto de permissões](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) no *Guia do usuário do Centro de Identidade do AWS IAM *. 1. Atribua usuários a um grupo e, em seguida, atribua o acesso de logon único ao grupo. Para obter instruções, consulte [Adicionar grupos](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) no *Guia do usuário do Centro de Identidade do AWS IAM *. ### Etapa 2: Configurar permissões para o IDT Nesta etapa, configure as permissões que o IDT for AWS IoT Greengrass usa para executar testes e coletar dados de uso do IDT. Você pode usar o Console de gerenciamento da AWS or AWS Command Line Interface (AWS CLI) para criar uma política do IAM e um usuário de teste para o IDT e, em seguida, anexar políticas ao usuário. Se você já criou um usuário de teste para IDT, vá para [Configure seu dispositivo para executar testes de IDT](device-config-setup.md) ou [Opcional: Configurando seu contêiner Docker para IDT para AWS IoT Greengrass](docker-config-setup.md). + [Para configurar permissões para IDT (Console)](#configure-idt-permissions-console) + [Para configurar permissões para o IDT (AWS CLI)](#configure-idt-permissions-cli) **Como configurar permissões para o IDT (console)** Siga estas etapas para usar o console para configurar permissões para IDT para AWS IoT Greengrass. 1. [Faça login no console do IAM](https://console.aws.amazon.com/iam). 1. Crie uma política gerenciada pelo cliente que conceda permissões para criar funções com permissões específicas. 1. No painel de navegação, selecione **Políticas** e, em seguida, **Criar política**. 1. Na guia **JSON**, substitua o conteúdo do espaço reservado pela política a seguir. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ManageRolePoliciesForIDTGreengrass", "Effect": "Allow", "Action": [ "iam:DetachRolePolicy", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::*:role/idt-*", "arn:aws:iam::*:role/GreengrassServiceRole" ], "Condition": { "ArnEquals": { "iam:PolicyARN": [ "arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy", "arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess", "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole" ] } } }, { "Sid": "ManageRolesForIDTGreengrass", "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:DeleteRole", "iam:PassRole", "iam:GetRole" ], "Resource": [ "arn:aws:iam::123456789012:role/idt-*", "arn:aws:iam::123456789012:role/GreengrassServiceRole" ] } ] } ``` ------ **Importante** A política a seguir concede permissão para criar e gerenciar funções exigidas pelo IDT para o AWS IoT Greengrass. Isso inclui permissões para anexar as seguintes políticas AWS gerenciadas: [AWSGreengrassResourceAccessRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy) [Greengrass OTAUpdate ArtifactAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess) [AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole) 1. Escolha **Próximo: tags**. 1. Selecione **Next: Review** (Próximo: revisar). 1. Em **Name (Nome)**, insira **IDTGreengrassIAMPermissions**. Em **Summary (Resumo)**, revise as permissões concedidas pela política. 1. Selecione **Create policy** (Criar política). 1. Crie um usuário do IAM e anexe as permissões exigidas pelo IDT para o AWS IoT Greengrass. 1. Criar um usuário do IAM. Siga as etapas de 1 a 5 em [Criando usuários do IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) no *Guia do usuário do IAM*. 1. Anexe as permissões ao usuário do IAM: 1. Na página **Definir permissões**, selecione **Anexar políticas existentes diretamente**. 1. Procure a **IDTGreengrassIAMPermissions**política que você criou na etapa anterior. Marque a caixa de seleção. 1. Pesquise a **AWSIoTDeviceTesterForGreengrassFullAccess**política. Marque a caixa de seleção. **nota** [AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess)É uma política AWS gerenciada que define as permissões que o IDT exige para criar e acessar AWS recursos usados para testes. Para obter mais informações, consulte [AWS política gerenciada para AWS IoT Device Tester](#idt-managed-policy). 1. Selecione **Next: Tags (Próximo: tags)**. 1. Selecione **Next: Review (Próximo: revisar)** para exibir um resumo das suas escolhas. 1. Selecione **Criar usuário**. 1. Para visualizar as chaves de acesso do usuário (chave de acesso IDs e chaves de acesso secretas), escolha **Mostrar** ao lado da senha e da chave de acesso. Para salvar as chaves de acesso, selecione **Download.csv (Fazer download do .csv)** e salve o arquivo em um local seguro. Use essas informações posteriormente para configurar o arquivo de credenciais da AWS . 1. Próxima etapa: configure o [dispositivo físico](device-config-setup.md).   **Como configurar permissões para o IDT (AWS CLI)** Siga estas etapas para usar o AWS CLI para configurar as permissões do IDT para AWS IoT Greengrass. Se você já configurou permissões no console, vá para [Configure seu dispositivo para executar testes de IDT](device-config-setup.md) ou [Opcional: Configurando seu contêiner Docker para IDT para AWS IoT Greengrass](docker-config-setup.md). 1. No seu computador, instale e configure o, AWS CLI se ainda não estiver instalado. Siga as etapas em [Installing the (Instalando a) AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) no *Guia do usuário do AWS Command Line Interface *. **nota** AWS CLI É uma ferramenta de código aberto que você pode usar para interagir com AWS serviços do seu shell de linha de comando. 1. Crie uma política gerenciada pelo cliente que conceda permissões para gerenciar IDT e funções do AWS IoT Greengrass . ------ #### [ Linux, macOS, or Unix ] ``` aws iam create-policy --policy-name IDTGreengrassIAMPermissions --policy-document '{ "Version":"2012-10-17", "Statement": [ { "Sid": "ManageRolePoliciesForIDTGreengrass", "Effect": "Allow", "Action": [ "iam:DetachRolePolicy", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::*:role/idt-*", "arn:aws:iam::*:role/GreengrassServiceRole" ], "Condition": { "ArnEquals": { "iam:PolicyARN": [ "arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy", "arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess", "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole" ] } } }, { "Sid": "ManageRolesForIDTGreengrass", "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:DeleteRole", "iam:PassRole", "iam:GetRole" ], "Resource": [ "arn:aws:iam::123456789012:role/idt-*", "arn:aws:iam::123456789012:role/GreengrassServiceRole" ] } ] }' ``` ------ #### [ Windows command prompt ] ``` aws iam create-policy --policy-name IDTGreengrassIAMPermissions --policy-document '{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"ManageRolePoliciesForIDTGreengrass\",\"Effect\": \"Allow\",\"Action\": [\"iam:DetachRolePolicy\", \"iam:AttachRolePolicy\"], \"Resource\": [\"arn:aws:iam::*:role/idt-*\",\"arn:aws:iam::*:role/GreengrassServiceRole\"],\"Condition\": {\"ArnEquals\": {\"iam:PolicyARN\": [\"arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy\",\"arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess\",\"arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole\"]}}},{\"Sid\": \"ManageRolesForIDTGreengrass\",\"Effect\": \"Allow\",\"Action\": [\"iam:CreateRole\",\"iam:DeleteRole\", \"iam:PassRole\", \"iam:GetRole\"],\"Resource\": [\"arn:aws:iam::*:role/idt-*\",\"arn:aws:iam::*:role/GreengrassServiceRole\"]}]}' ``` **nota** Esta etapa inclui um exemplo de prompt de comando do Windows porque ele usa uma sintaxe JSON diferente dos comandos de terminal Linux, macOS ou Unix. ------ 1. Crie um usuário do IAM e anexe as permissões exigidas pelo IDT para o AWS IoT Greengrass. 1. Criar um usuário do IAM. Neste exemplo de configuração, o usuário é nomeado `IDTGreengrassUser`. ``` aws iam create-user --user-name IDTGreengrassUser ``` 1. Anexe a política `IDTGreengrassIAMPermissions` criada na etapa 2 ao seu usuário do IAM. **Substitua o comando pelo ID do seu Conta da AWS. ``` aws iam attach-user-policy --user-name IDTGreengrassUser --policy-arn arn:aws:iam:::policy/IDTGreengrassIAMPermissions ``` 1. Anexe a política `AWSIoTDeviceTesterForGreengrassFullAccess` ao seu usuário do IAM. ``` aws iam attach-user-policy --user-name IDTGreengrassUser --policy-arn arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess ``` **nota** [AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess)É uma política AWS gerenciada que define as permissões que o IDT exige para criar e acessar AWS recursos usados para testes. Para obter mais informações, consulte [AWS política gerenciada para AWS IoT Device Tester](#idt-managed-policy). 1. Crie uma chave de acesso secreta para o usuário. ``` aws iam create-access-key --user-name IDTGreengrassUser ``` Armazene a saída em um local seguro. Você usa essas informações posteriormente para configurar seu arquivo de AWS credenciais. 1. Próxima etapa: configure o [dispositivo físico](device-config-setup.md). ## AWS política gerenciada para AWS IoT Device Tester A política [AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess)gerenciada permite que a IDT execute operações e colete métricas de uso. Essa política concede as seguintes permissões de IDT: + `iot-device-tester:CheckVersion`. Verifique se um conjunto de versões AWS IoT Greengrass, suíte de testes e IDT são compatíveis. + `iot-device-tester:DownloadTestSuite`. Fazer download dos conjuntos de testes. + `iot-device-tester:LatestIdt`. Obter informações sobre a versão mais recente do IDT disponível para download. + `iot-device-tester:SendMetrics`. Publicar dados de uso que o IDT coleta sobre seus testes. + `iot-device-tester:SupportedVersion`. Obtenha a lista AWS IoT Greengrass e as versões do pacote de testes compatíveis com o IDT. Essas informações são exibidas na janela da linha de comando. # Configure seu dispositivo para executar testes de IDT Para configurar seu dispositivo, você deve instalar AWS IoT Greengrass dependências, configurar o software AWS IoT Greengrass Core, configurar seu computador host para acessar seu dispositivo e configurar as permissões de usuário em seu dispositivo. ## Verifique AWS IoT Greengrass as dependências no dispositivo em teste Antes que o IDT for AWS IoT Greengrass possa testar seus dispositivos, verifique se você configurou seu dispositivo conforme descrito em [Introdução ao AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/latest/developerguide/gg-gs.html). Para obter mais informações sobre as plataformas compatíveis, consulte [Plataformas compatíveis](https://docs.aws.amazon.com/greengrass/latest/developerguide/what-is-gg.html#gg-platforms). ## Configurar o AWS IoT Greengrass software O IDT for AWS IoT Greengrass testa a compatibilidade de seu dispositivo com uma versão específica do AWS IoT Greengrass. O IDT oferece duas opções para testes AWS IoT Greengrass em seus dispositivos: + Faça download e use uma versão do [software de núcleo do AWS IoT Greengrass](what-is-gg.md#gg-core-download-tab). O IDT instala o software para você. + Use uma versão do software AWS IoT Greengrass Core já instalada em seu dispositivo. **nota** Cada versão do AWS IoT Greengrass tem uma versão IDT correspondente. Você deve baixar a versão do IDT que corresponde à versão que AWS IoT Greengrass você está usando. As seções a seguir descrevem essas opções. Você só precisa fazer uma delas. ### Opção 1: baixar o software AWS IoT Greengrass principal e configurar o AWS IoT Device Tester para usá-lo Você pode baixar o software AWS IoT Greengrass principal na página de downloads do [software AWS IoT Greengrass principal](what-is-gg.md#gg-core-download-tab). 1. Localize a arquitetura correta e distribuição do Linux e, em seguida selecione **Download (Fazer download)**. 1. Copie o arquivo tar.gz para `/products/greengrass/ggc`. **nota** Não altere o nome do arquivo AWS IoT Greengrass tar.gz. Não coloque vários arquivos nesse diretório para o mesmo sistema operacional e arquitetura. Por exemplo, a presença dos arquivos `greengrass-linux-armv7l-1.7.1.tar.gz` e `greengrass-linux-armv7l-1.8.1.tar.gz` nesse diretório fará com que os testes falhem. ### Opção 2: usar uma instalação existente do AWS IoT Greengrass com o AWS IoT Device Tester Configure o IDT para testar o software AWS IoT Greengrass Core instalado em seu dispositivo adicionando o `greengrassLocation` atributo ao `device.json` arquivo na `/configs` pasta. Por exemplo: ``` "greengrassLocation" : "" ``` Para obter mais informações sobre o arquivo `device.json`, consulte [Configurar device.json](set-config.md#device-config). Em dispositivos Linux, a localização padrão do software AWS IoT Greengrass Core é`/greengrass`. **nota** Seu dispositivo deve ter uma instalação do software AWS IoT Greengrass Core que não tenha sido iniciada. Certifique-se de ter adicionado o usuário `ggc_user` e `ggc_group` no seu dispositivo. Para obter mais informações, consulte [Configuração de ambiente para o AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/latest/developerguide/module1.html). ## Configurar o computador host para acessar o dispositivo em teste O ITD é executado em seu computador host e deve ser capaz de usar o SSH para se conectar ao seu dispositivo. Há duas opções para permitir que o IDT obtenha acesso SSH aos dispositivos em teste: 1. Siga as instruções aqui para criar um par de chaves SSH e autorizar sua chave a fazer login no dispositivo em teste sem especificar uma senha. 1. Forneça um nome de usuário e uma senha para cada dispositivo no arquivo `device.json`. Para obter mais informações, consulte [Configurar device.json](set-config.md#device-config). Você pode usar qualquer implementação SSL para criar uma chave SSH. As instruções a seguir mostram como usar o [SSH-KEYGEN ou o](https://www.ssh.com/ssh/keygen/) [Pu TTYgen](https://www.ssh.com/ssh/putty/windows/puttygen) (para Windows). Se você estiver usando outra implementação de SSL, consulte a documentação para essa implementação. O IDT usa chaves SSH para autenticar com o dispositivo em teste. **Para criar uma chave SSH com SSH-KEYGEN** 1. Crie uma chave SSH. Você pode usar o comando **ssh-keygen** Open SSH para criar um par de chaves SSH. Se você já tem um par de chaves SSH em seu computador host, é uma prática recomendada criar um par de chaves SSH especificamente para IDT. Dessa forma, depois de concluir o teste, o computador host não poderá mais se conectar ao dispositivo sem inserir uma senha. Ele também permite que você restrinja o acesso ao dispositivo remoto apenas para aqueles que precisam. **nota** O Windows não tem um cliente SSH instalado. Para obter informações sobre como instalar um cliente SSH no Windows, consulte [Fazer download do software cliente SSH](https://www.ssh.com/ssh/#sec-Download-client-software). O comando **ssh-keygen** solicita que você informe um nome e caminho para armazenar o par de chaves. Por padrão, os arquivos de pares de chaves são nomeados como `id_rsa` (chave privada) e `id_rsa.pub` (chave pública). No macOS e no Linux, o local padrão desses arquivos é `~/.ssh/`. No Windows, o local padrão é `C:\Users\\.ssh`. Quando solicitado, insira uma frase-chave para proteger sua chave SSH. Para obter mais informações, consulte [Gerar uma chave SSH](https://www.ssh.com/ssh/keygen/). 1. Adição de chaves SSH autorizadas ao seu dispositivo em teste. O ITD deve usar sua chave privada SSH para fazer login no seu dispositivo em teste. Para autorizar sua chave privada SSH a fazer login no seu dispositivo em teste, use o comando **ssh-copy-id** do seu computador host. Esse comando adiciona sua chave pública ao arquivo `~/.ssh/authorized_keys` no seu dispositivo em teste. Por exemplo: **\$1 ssh-copy-id **@**** Onde *remote-ssh-user* está o nome de usuário usado para fazer login no seu dispositivo em teste e *remote-device-ip* é o endereço IP do dispositivo em teste para executar testes. Por exemplo: **ssh-copy-id pi@192.168.1.5** Quando solicitado, insira a senha para o nome de usuário especificado no comando **ssh-copy-id**. **ssh-copy-id** supõe que a chave pública chama-se `id_rsa.pub` e está armazenada no local padrão (`~/.ssh/` no macOS e no Linux, e `C:\Users\\.ssh` no Windows). Se você atribuiu à chave pública um nome diferente ou armazenou em um local diferente, você deve especificar o caminho para sua chave pública SSH usando a opção **-i** para **ssh-copy-id** (por exemplo, **ssh-copy-id -i \$1/my/path/myKey.pub**). Para obter mais informações sobre a criação de chaves SSH e a cópia de chaves públicas, consulte [SSH-COPY-ID](https://www.ssh.com/ssh/copy-id). **Para criar uma chave SSH usando Pu TTYgen (somente Windows)** 1. Verifique se o servidor e o cliente OpenSSH estão instalados no dispositivo em teste. Para obter mais informações, consulte [OpenSSH](https://www.openssh.com/). 1. Instale o [Pu TTYgen](https://www.puttygen.com/) no seu dispositivo em teste. 1. Abra o PuTTYgen. 1. Selecione **Generate (Gerar)** e mova o cursor do mouse dentro da caixa para gerar uma chave privada. 1. No menu **Conversions (Conversões)**, selecione **Export OpenSSH key (Exportar chave OpenSSH)** e salve a chave privada com uma extensão de arquivo `.pem`. 1. Adicione a chave pública ao arquivo `/home//.ssh/authorized_keys` no dispositivo em teste. 1. Copie o texto da chave pública da TTYgen janela Pu. 1. Use o PuTTY para criar uma sessão no dispositivo em teste. 1. Em um prompt de comando ou janela Windows Powershell, execute o seguinte comando: **C:/**/putty.exe -ssh **@**** 1. Quando solicitado, insira a senha do dispositivo. 1. Use vi ou outro editor de texto para anexar a chave pública ao arquivo `/home//.ssh/authorized_keys` no dispositivo em teste. 1. Atualize o arquivo `device.json` com o nome de usuário, o endereço IP e o caminho para o arquivo da chave privada que você acabou de salvar no computador host para cada dispositivo em teste. Para obter mais informações, consulte [Configurar device.json](set-config.md#device-config). Você deve fornecer o caminho completo e o nome do arquivo para a chave privada e usar barras ('/'). Por exemplo, para o caminho do Windows `C:\DT\privatekey.pem`, use `C:/DT/privatekey.pem` no arquivo `device.json`. ## Configurar permissões de usuário no dispositivo O ITD executa operações em vários diretórios e arquivos em um dispositivo em teste. Algumas dessas operações exigem permissões elevadas (usando **sudo**). Para automatizar essas operações, o IDT for AWS IoT Greengrass deve ser capaz de executar comandos com sudo sem ser solicitado a fornecer uma senha. Siga estas etapas no dispositivo em teste para permitir o acesso ao sudo sem receber uma solicitação de senha. **nota** `username` refere-se ao usuário SSH usado pelo IDT para acessar o dispositivo em teste. **Para adicionar o usuário ao grupo sudo** 1. No dispositivo em teste, execute `sudo usermod -aG sudo `. 1. Saia e faça login novamente para que as alterações entrem em vigor. 1. Para verificar se o nome de usuário foi adicionado com êxito, execute **sudo echo test**. Se você não receber uma solicitação de senha, o usuário foi configurado corretamente. 1. Abra o arquivo `/etc/sudoers` e adicione a linha a seguir ao final do arquivo: ` ALL=(ALL) NOPASSWD: ALL` ## Configurar seu dispositivo para testar atributos opcionais Os tópicos a seguir descrevem como configurar seus dispositivos de modo a executar testes IDT para atributos opcionais. Siga os passos de configuração a seguir apenas se você quiser testar estes recursos. Caso contrário, avance para [Defina as configurações de IDT para executar o pacote de AWS IoT Greengrass qualificação](set-config.md). **Topics** + [Verifique AWS IoT Greengrass as dependências no dispositivo em teste](#install-gg-dependencies) + [Configurar o AWS IoT Greengrass software](#config-gg) + [Configurar o computador host para acessar o dispositivo em teste](#configure-host) + [Configurar permissões de usuário no dispositivo](#root-access) + [Configurar seu dispositivo para testar atributos opcionais](#optional-feature-config) + [Opcional: Configurando seu contêiner Docker para IDT para AWS IoT Greengrass](docker-config-setup.md) + [Opcional: configurar o dispositivo para qualificação de ML](idt-ml-qualification.md) # Opcional: Configurando seu contêiner Docker para IDT para AWS IoT Greengrass AWS IoT Greengrass fornece uma imagem do Docker e um Dockerfile que facilitam a execução do software AWS IoT Greengrass Core em um contêiner do Docker. Depois de configurar o AWS IoT Greengrass contêiner, você pode executar testes de IDT. No momento, somente arquiteturas x86\$164 do Docker são compatíveis com a execução do IDT para o AWS IoT Greengrass. Esse atributo exige o IDT v2.3.0 ou posterior. O processo de configuração do contêiner Docker para executar testes de IDT depende se você usa a imagem do Docker ou o Dockerfile fornecido pelo. AWS IoT Greengrass + [Use a imagem do Docker](#docker-config-setup-docker-image). A imagem do Docker tem o software AWS IoT Greengrass principal e as dependências instalados. + [Use o arquivo do Docker](#docker-config-setup-dockerfile). O Dockerfile contém o código-fonte que você pode usar para criar imagens de AWS IoT Greengrass contêiner personalizadas. A imagem pode ser modificada para funcionar com diferentes arquiteturas de plataforma ou para reduzir o tamanho da imagem. **nota** AWS IoT Greengrass não fornece Dockerfiles ou imagens Docker para a versão 1.11.1 AWS IoT Greengrass do software principal. Para executar testes de IDT em suas próprias imagens de contêiner personalizadas, sua imagem deve incluir as dependências definidas no Dockerfile fornecido pela. AWS IoT Greengrass Os seguintes recursos não estão disponíveis quando você executa AWS IoT Greengrass em um contêiner do Docker: + [Conectores](connectors.md) executados no modo de **contêiner do Greengrass**. Para executar um conector em um contêiner do Docker, o conector deve ser executado no modo **Sem contêiner**. Para localizar conectores compatíveis com o modo **Sem contêiner** consulte [Conectores do Greengrass fornecidos pela AWS](connectors-list.md). Alguns desses conectores têm um parâmetro de modo de isolamento que você deve definir como **Sem contêiner**. + [Recursos de volume e dispositivo locais](access-local-resources.md). Suas funções do Lambda definidas pelo usuário executadas no contêiner do Docker devem acessar dispositivos e volumes diretamente no núcleo. ## Configure a imagem do Docker fornecida pelo AWS IoT Greengrass Siga estas etapas para configurar a imagem do AWS IoT Greengrass Docker para executar testes de IDT. **Pré-requisitos** Antes de começar este tutorial, você deve fazer o seguinte. + Você deve instalar o software e as versões a seguir em seu computador host com base na versão AWS Command Line Interface (AWS CLI) que você escolher. ------ #### [ AWS CLI version 2 ] + [Docker](https://docs.docker.com/install/), versão 18.09 ou posterior. Versões anteriores também podem funcionar, mas recomendamos a versão 18.09 ou posterior. + AWS CLI versão 2.0.0 ou posterior. + Para instalar a AWS CLI versão 2, consulte [Instalando a AWS CLI versão 2](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html). + Para configurar o AWS CLI, consulte [Configurando o. AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) **nota** Para atualizar para uma AWS CLI versão posterior 2 em um computador Windows, você deve repetir o processo de [instalação do MSI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-windows.html). ------ #### [ AWS CLI version 1 ] + [Docker](https://docs.docker.com/install/), versão 18.09 ou posterior. Versões anteriores também podem funcionar, mas recomendamos a versão 18.09 ou posterior. + [Python](https://www.python.org/downloads/), versão 3.6 ou posterior. + [pip](https://pip.pypa.io/en/stable/installing) versão 18.1 ou posterior. + AWS CLI versão 1.17.10 ou posterior + Para instalar a AWS CLI versão 1, consulte [Instalando a AWS CLI versão 1](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html). + Para configurar o AWS CLI, consulte [Configurando o. AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) + Para atualizar para a versão mais recente da AWS CLI versão 1, execute o comando a seguir. ``` pip install awscli --upgrade --user ``` **nota** Se você usa a [instalação MSI](https://docs.aws.amazon.com/cli/latest/userguide/install-windows.html#msi-on-windows) da AWS CLI versão 1 no Windows, esteja ciente do seguinte: Se a instalação da AWS CLI versão 1 falhar ao instalar o botocore, tente usar a instalação do [Python](https://docs.aws.amazon.com/cli/latest/userguide/awscli-install-windows.html#awscli-install-windows-pip) e do pip. Para atualizar para uma AWS CLI versão posterior 1, você deve repetir o processo de instalação do MSI. ------ + Para acessar os recursos do Amazon Elastic Container Registry (Amazon ECR), você deve conceder a seguinte permissão. + O Amazon ECR exige que os usuários concedam a `ecr:GetAuthorizationToken` permissão por meio de uma política AWS Identity and Access Management (IAM) antes de poderem se autenticar em um registro e enviar ou extrair imagens de um repositório do Amazon ECR. Para obter mais informações, consulte [Exemplos de políticas do repositório do Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policy-examples.html) e [Acessando um repositório do Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-access-one-bucket) no *Guia do usuário do Amazon Elastic Container Registry*.   1. Faça download da imagem do Docker e configure o contêiner. Você pode fazer download da imagem pré-criada no [Hub do Docker](https://hub.docker.com/r/amazon/aws-iot-greengrass) ou no [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) (Amazon ECR) e executá-la em plataformas do Windows, macOS e Linux (x86\$164). Para fazer download da imagem do Docker do Amazon ECR, conclua todas as etapas em [Etapa 1: Obtenha a imagem do AWS IoT Greengrass contêiner do Amazon ECR](run-gg-in-docker-container.md#docker-pull-image). Depois, retorne a este tópico para continuar a configuração. 1. Somente usuários do Linux: verifique se o usuário que executa o IDT tem permissão para executar comandos do Docker. Para obter mais informações, consulte [Manage Docker as a non-root user](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user) na documentação do Docker. 1. Para executar o AWS IoT Greengrass contêiner, use o comando para seu sistema operacional: ------ #### [ Linux ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ -v : \ : ``` + **Substitua pelo caminho para o arquivo de configuração do kernel no host e ** pelo caminho em que o volume está montado no contêiner. O arquivo de configuração do kernel no host geralmente está localizado em `/proc/config.gz` ou em `/boot/config-`. Você pode correr `uname -r` para encontrar o ** valor. **Exemplo:** para montar o arquivo de configuração de `/boot/config-` ``` -v /boot/config-4.15.0-74-generic:/boot/config-4.15.0-74-generic \ ``` **Exemplo:** para montar o arquivo de configuração de `proc/config.gz` ``` -v /proc/config.gz:/proc/config.gz \ ``` + Substitua**: ** no comando pelo nome do repositório e pela tag da imagem de destino. **Exemplo:** Para apontar para a versão mais recente do software AWS IoT Greengrass Core ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Para obter a lista de imagens do AWS IoT Greengrass Docker, execute o comando a seguir. ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ #### [ macOS ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ : ``` + Substitua**: ** no comando pelo nome do repositório e pela tag da imagem de destino. **Exemplo:** Para apontar para a versão mais recente do software AWS IoT Greengrass Core ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Para obter a lista de imagens do AWS IoT Greengrass Docker, execute o seguinte comando: ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ #### [ Windows ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ : ``` + Substitua**: ** no comando pelo nome do repositório e pela tag da imagem de destino. **Exemplo:** Para apontar para a versão mais recente do software AWS IoT Greengrass Core ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Para obter a lista de imagens do AWS IoT Greengrass Docker, execute o seguinte comando: ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ **Importante** Ao testar com o IDT, não inclua o `--entrypoint /greengrass-entrypoint.sh \` argumento usado para executar a imagem para AWS IoT Greengrass uso geral. 1. Próxima etapa: [configure suas AWS credenciais e seu `device.json` arquivo](set-config.md). ## Configure o dockerfile fornecido pelo AWS IoT Greengrass Siga estas etapas para configurar a imagem do Docker criada a partir do AWS IoT Greengrass Dockerfile para executar testes de IDT. 1. Em [AWS IoT Greengrass Software Docker](what-is-gg.md#gg-docker-download), faça download do pacote do arquivo do Docker para o computador host e extraia-o. 1. Abra o `README.md`. As próximas três etapas se referem a seções desse arquivo. 1. Verifique se você atende aos requisitos na seção **Pré-requisitos**. 1. Somente para usuários Linux: conclua as etapas **Ativar proteção de links simbólicos e hardlinks** e **Ativar encaminhamento IPv4 de rede**. 1. Para criar a imagem do Docker, conclua todas as etapas na **Etapa 1. Crie a imagem do AWS IoT Greengrass Docker**. Depois, retorne a este tópico para continuar a configuração. 1. Para executar o AWS IoT Greengrass contêiner, use o comando para seu sistema operacional: ------ #### [ Linux ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ -v : \ : ``` + **Substitua pelo caminho para o arquivo de configuração do kernel no host e ** pelo caminho em que o volume está montado no contêiner. O arquivo de configuração do kernel no host geralmente está localizado em `/proc/config.gz` ou em `/boot/config-`. Você pode correr `uname -r` para encontrar o ** valor. **Exemplo:** para montar o arquivo de configuração de `/boot/config-` ``` -v /boot/config-4.15.0-74-generic:/boot/config-4.15.0-74-generic \ ``` **Exemplo:** para montar o arquivo de configuração de `proc/config.gz` ``` -v /proc/config.gz:/proc/config.gz \ ``` + Substitua**: ** no comando pelo nome do repositório e pela tag da imagem de destino. **Exemplo:** Para apontar para a versão mais recente do software AWS IoT Greengrass Core ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Para obter a lista de imagens do AWS IoT Greengrass Docker, execute o comando a seguir. ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ #### [ macOS ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ : ``` + Substitua**: ** no comando pelo nome do repositório e pela tag da imagem de destino. **Exemplo:** Para apontar para a versão mais recente do software AWS IoT Greengrass Core ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Para obter a lista de imagens do AWS IoT Greengrass Docker, execute o seguinte comando: ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ #### [ Windows ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ : ``` + Substitua**: ** no comando pelo nome do repositório e pela tag da imagem de destino. **Exemplo:** Para apontar para a versão mais recente do software AWS IoT Greengrass Core ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Para obter a lista de imagens do AWS IoT Greengrass Docker, execute o seguinte comando: ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ **Importante** Ao testar com o IDT, não inclua o `--entrypoint /greengrass-entrypoint.sh \` argumento usado para executar a imagem para AWS IoT Greengrass uso geral. 1. Próxima etapa: [configure suas AWS credenciais e seu `device.json` arquivo](set-config.md). ## Solução de problemas na configuração do contêiner Docker para o IDT para AWS IoT Greengrass Use as informações a seguir para ajudar a solucionar problemas com a execução de um contêiner Docker para IDT para testes. AWS IoT Greengrass ### AVISO: Erro ao carregar configfile:/home/user/.docker/config.json - stat /home//.docker/config.json: permissão negada Se você receber esse erro ao executar comandos `docker` no Linux, execute o comando a seguir. **Substitua o comando a seguir pelo usuário que executa o IDT. ``` sudo chown : /home//.docker -R sudo chmod g+rwx /home//.docker -R ``` # Opcional: configurar o dispositivo para qualificação de ML O IDT for AWS IoT Greengrass fornece testes de qualificação de aprendizado de máquina (ML) para validar se seus dispositivos podem realizar inferência de ML localmente usando modelos treinados na nuvem. Para executar testes de qualificação de ML, primeiro é preciso configurar os dispositivos conforme descrito em [Configure seu dispositivo para executar testes de IDT](device-config-setup.md). Depois, siga as etapas deste tópico para instalar dependências para as estruturas de ML que você deseja executar. É necessária a versão 3.1.0 ou posterior do IDT para executar testes de qualificação de ML. ## Instalar dependências de estrutura do ML Todas as dependências de estrutura do ML devem ser instaladas no diretório `/usr/local/lib/python3.x/site-packages`. Para certificar-se de que estão instaladas no diretório correto, é recomendado usar permissões raiz `sudo` ao instalar as dependências. Os ambientes virtuais não oferecem suporte a testes de qualificação. **nota** Se você estiver testando funções do Lambda executadas com [conteinerização](lambda-group-config.md#lambda-containerization-considerations) (no modo de **Contêiner do Greengrass**, a criação de symlinks para bibliotecas Python em `/usr/local/lib/python3.x` não é compatível. Para evitar erros, instale as dependências no diretório correto. Siga as etapas para instalar as dependências na estrutura de destino: + [Instalar MXNet dependências](#ml-qualification-mxnet-dependencies) + [Instalar TensorFlow dependências](#ml-qualification-tensorflow-dependencies) + [Instalar dependências do DLR](#ml-qualification-dlr-dependencies)   ## Instalar dependências do Apache MXNet Os testes de qualificação do IDT para esta estrutura têm as seguintes dependências: + Python 3.6 ou Python 3.7. **nota** Se estiver usando Python 3.6, você deve criar um symblink de Python 3.7 para binários Python 3.6. Isso configura seu dispositivo para atender ao requisito Python para AWS IoT Greengrass. Por exemplo: ``` sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7 ``` + Apache MXNet v1.2.1 ou posterior. + NumPy. A versão deve ser compatível com a sua MXNet versão. ### Instalando MXNet Siga as instruções na MXNet documentação para [instalar MXNet](https://mxnet.apache.org/get_started/?platform=linux&language=python&processor=cpu&environ=pip&). **nota** Se o Python 2.x e o Python 3.x estiverem instalados no seu dispositivo, use o Python 3.x nos comandos executados para instalar as dependências. ### Validando a instalação MXNet Escolha uma das opções a seguir para validar a MXNet instalação. #### Opção 1: usar SSH para o seu dispositivo e executar scripts 1. SSH para o seu dispositivo. 1. Execute o script a seguir para verificar se as dependências estão instaladas corretamente. ``` sudo python3.7 -c "import mxnet; print(mxnet.__version__)" ``` ``` sudo python3.7 -c "import numpy; print(numpy.__version__)" ``` A saída imprime o número da versão e o script deve sair sem erro. #### Opção 2: executar o teste de dependência de IDT 1. Certifique-se de que `device.json` esteja configurado para qualificação de ML. Para obter mais informações, consulte [Configurar device.json para qualificação de ML](set-config.md#device-json-ml-qualification). 1. Execute o teste de dependências para a estrutura. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id mxnet_dependency_check ``` O resumo do teste exibe um resultado `PASSED` para `mldependencies`.   ## Instalar TensorFlow dependências Os testes de qualificação do IDT para esta estrutura têm as seguintes dependências: + Python 3.6 ou Python 3.7. **nota** Se estiver usando Python 3.6, você deve criar um symblink de Python 3.7 para binários Python 3.6. Isso configura seu dispositivo para atender ao requisito Python para AWS IoT Greengrass. Por exemplo: ``` sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7 ``` + TensorFlow 1.x. ### Instalando TensorFlow Siga as instruções na TensorFlow documentação para instalar o TensorFlow 1.x [com pip](https://www.tensorflow.org/install/pip) ou a [partir da](https://www.tensorflow.org/install/source) fonte. **nota** Se o Python 2.x e o Python 3.x estiverem instalados no seu dispositivo, use o Python 3.x nos comandos executados para instalar as dependências. ### Validando a instalação TensorFlow Escolha uma das opções a seguir para validar a TensorFlow instalação. #### Opção 1: usar SSH para o seu dispositivo e executar um script 1. SSH para o seu dispositivo. 1. Execute o script a seguir para verificar se a dependência está instalada corretamente. ``` sudo python3.7 -c "import tensorflow; print(tensorflow.__version__)" ``` A saída imprime o número da versão e o script deve sair sem erro. #### Opção 2: executar o teste de dependência de IDT 1. Certifique-se de que `device.json` esteja configurado para qualificação de ML. Para obter mais informações, consulte [Configurar device.json para qualificação de ML](set-config.md#device-json-ml-qualification). 1. Execute o teste de dependências para a estrutura. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id tensorflow_dependency_check ``` O resumo do teste exibe um resultado `PASSED` para `mldependencies`.   ## Instale dependências do Amazon SageMaker AI Neo Deep Learning Runtime (DLR) Os testes de qualificação do IDT para esta estrutura têm as seguintes dependências: + Python 3.6 ou Python 3.7. **nota** Se estiver usando Python 3.6, você deve criar um symblink de Python 3.7 para binários Python 3.6. Isso configura seu dispositivo para atender ao requisito Python para AWS IoT Greengrass. Por exemplo: ``` sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7 ``` + SageMaker AI Neo DLR. + numpy. Depois de instalar as dependências de teste do DLR, é preciso [compilar o modelo](#ml-qualification-dlr-compile-model). ### Instalar o DLR Siga as instruções na documentação do DLR para [instalar o Neo DLR](https://neo-ai-dlr.readthedocs.io/en/latest/install.html#building-on-linux). **nota** Se o Python 2.x e o Python 3.x estiverem instalados no seu dispositivo, use o Python 3.x nos comandos executados para instalar as dependências. ### Validar a instalação do DLR Selecione uma das opções a seguir para validar a instalação do DLR. #### Opção 1: usar SSH para o seu dispositivo e executar scripts 1. SSH para o seu dispositivo. 1. Execute o script a seguir para verificar se as dependências estão instaladas corretamente. ``` sudo python3.7 -c "import dlr; print(dlr.__version__)" ``` ``` sudo python3.7 -c "import numpy; print(numpy.__version__)" ``` A saída imprime o número da versão e o script deve sair sem erro. #### Opção 2: executar o teste de dependência de IDT 1. Certifique-se de que `device.json` esteja configurado para qualificação de ML. Para obter mais informações, consulte [Configurar device.json para qualificação de ML](set-config.md#device-json-ml-qualification). 1. Execute o teste de dependências para a estrutura. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id dlr_dependency_check ``` O resumo do teste exibe um resultado `PASSED` para `mldependencies`. ## Compilar o modelo de DLR Você deve compilar o modelo de DLR antes de usá-lo para testes de qualificação de ML. Selecione uma das seguintes opções para saber mais detalhes: ### Opção 1: usar o Amazon SageMaker AI para compilar o modelo Siga estas etapas para usar a SageMaker IA para compilar o modelo de ML fornecido pelo IDT. Este modelo é pré-treinado com o MXNet Apache. 1. Verifique se seu tipo de dispositivo é compatível com SageMaker IA. Para obter mais informações, consulte as [opções do dispositivo de destino](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_OutputConfig.html#sagemaker-Type-OutputConfig-TargetDevice) na *Amazon SageMaker AI API Reference*. Se o seu tipo de dispositivo não for compatível atualmente com SageMaker IA, siga as etapas em[Opção 2: usar o TVM para compilar o modelo de DLR](#ml-qualification-compile-dlr-option-2). **nota** A execução do teste DLR com um modelo compilado pela SageMaker IA pode levar de 4 a 5 minutos. Não interrompa o IDT durante esse período. 1. Baixe o arquivo tarball que contém o MXNet modelo pré-treinado e não compilado para DLR: + [dlr-noncompiled-model-1.0.tar.gz](https://docs.aws.amazon.com/greengrass/latest/developerguide/download-dlr-noncompiled-model-1.0.html) 1. Descompacte o tarball. Esse comando gera a seguinte estrutura de diretório. ![\[O diretório resnet18 contém três arquivos.\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-uncompiled.png) 1. Mova o arquivo `synset.txt` do diretório `resnet18` para outro local. Anote o novo local. Posteriormente, copie este arquivo para o diretório do modelo compilado. 1. Compacte o conteúdo do diretório `resnet18`. ``` tar cvfz model.tar.gz resnet18v1-symbol.json resnet18v1-0000.params ``` 1. Faça o upload do arquivo compactado em um bucket do Amazon S3 no Conta da AWS seu e, em seguida, siga as etapas [em Compilar um modelo (console) para criar um trabalho de compilação](https://docs.aws.amazon.com/sagemaker/latest/dg/neo-job-compilation-console.html). 1. Em **Configuração de entrada**, use os seguintes valores: + Em **Configuração de dados de entrada**, digite `{"data": [1, 3, 224, 224]}`. + Em **Estrutura de machine learning**, selecione `MXNet`. 1. Em **Configuração de saída**, use os seguintes valores: + Em **Local de saída do S3**, insira o caminho para o bucket do Amazon S3 ou a pasta onde deseja armazenar o modelo compilado. + Em **Dispositivo de destino**, selecione o tipo de dispositivo. 1. Faça download do modelo compilado do local de saída especificado e descompacte o arquivo. 1. Copie `synset.txt` para o diretório do modelo compilado. 1. Altere o nome do diretório do modelo compilado para `resnet18`. O diretório do modelo compilado deve ter a seguinte estrutura de diretório. ![\[O diretório do modelo compilado resnet18 contém quatro arquivos.\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-compiled-sm.png) ### Opção 2: usar o TVM para compilar o modelo de DLR Siga estas etapas para usar o TVM para compilar o modelo de ML fornecido pelo IDT. Esse modelo é pré-treinado com o Apache MXNet, portanto, você deve instalá-lo MXNet no computador ou dispositivo em que você compila o modelo. Para instalar MXNet, siga as instruções na [ MXNet documentação](https://mxnet.apache.org/get_started/?platform=linux&language=python&processor=cpu&environ=pip&). **nota** Recomendamos que você compile o modelo no dispositivo de destino. Essa prática é opcional, mas pode ajudar a garantir a compatibilidade e mitigar possíveis problemas.   1. Baixe o arquivo tarball que contém o MXNet modelo pré-treinado e não compilado para DLR: + [dlr-noncompiled-model-1.0.tar.gz](https://docs.aws.amazon.com/greengrass/latest/developerguide/download-dlr-noncompiled-model-1.0.html) 1. Descompacte o tarball. Esse comando gera a seguinte estrutura de diretório. ![\[O diretório resnet18 contém três arquivos.\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-uncompiled.png) 1. Siga as instruções na documentação do TVM para [criar e instalar o TVM da origem para a sua plataforma](https://docs.tvm.ai/install/from_source.html). 1. Depois de criar o TVM, execute a compilação do TVM para o modelo resnet18. As etapas a seguir são baseadas no [Quick Start Tutorial for Compiling Deep Learning Models](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#sphx-glr-tutorials-get-started-relay-quick-start-py) na documentação do TVM. 1. Abra o arquivo `relay_quick_start.py` a partir do repositório do TVM clonado. 1. Atualize o código que [define uma rede neural em retransmissão](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#define-neural-network-in-relay). Você pode usar uma das opções a seguir: + Opção 1: usar `mxnet.gluon.model_zoo.vision.get_model` para obter o módulo e os parâmetros de retransmissão: ``` from mxnet.gluon.model_zoo.vision import get_model block = get_model('resnet18_v1', pretrained=True) mod, params = relay.frontend.from_mxnet(block, {"data": data_shape}) ``` + Opção 2: copiar os seguintes arquivos do modelo não compilado que você baixou na etapa 1 para o mesmo diretório que o arquivo `relay_quick_start.py`. Esses arquivos contêm o módulo e os parâmetros de retransmissão. + `resnet18v1-symbol.json` + `resnet18v1-0000.params` 1. Atualize o código que [salva e carrega o módulo compilado](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#save-and-load-compiled-module) para usar o código a seguir. ``` from tvm.contrib import util path_lib = "deploy_lib.so" # Export the model library based on your device architecture lib.export_library("deploy_lib.so", cc="aarch64-linux-gnu-g++") with open("deploy_graph.json", "w") as fo: fo.write(graph) with open("deploy_param.params", "wb") as fo: fo.write(relay.save_param_dict(params)) ``` 1. Crie o modelo: ``` python3 tutorials/relay_quick_start.py --build-dir ./model ``` Este comando gera os seguintes arquivos. + `deploy_graph.json` + `deploy_lib.so` + `deploy_param.params` 1. Copie os arquivos de modelo gerados em um diretório chamado `resnet18`. Este é o diretório do modelo compilado. 1. Copie o diretório do modelo compilado para o computador host. Depois, copie o arquivo `synset.txt` do modelo não compilado que você baixou na etapa 1 para o diretório do modelo compilado. O diretório do modelo compilado deve ter a seguinte estrutura de diretório. ![\[O diretório do modelo compilado resnet18 contém quatro arquivos.\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-compiled-tvm.png) Em seguida, [configure suas AWS credenciais e seu `device.json` arquivo](set-config.md). # Defina as configurações de IDT para executar o pacote de AWS IoT Greengrass qualificação Antes de executar os testes, você deve definir as configurações de AWS credenciais e dispositivos no computador host. ## Configure suas AWS credenciais Você deve configurar suas credenciais de usuário do IAM no arquivo ` /configs/config.json`. Use as credenciais do IDT para o AWS IoT Greengrass usuário criado em. [Crie e configure um Conta da AWS](dev-tst-prereqs.md#config-aws-account-for-idt) Você pode especificar suas credenciais de uma das seguintes formas: + Arquivo de credenciais + Variáveis de ambiente ### Configurar AWS credenciais com um arquivo de credenciais O IDT usa o mesmo arquivo de credenciais que a AWS CLI. Para obter mais informações, consulte [Arquivos de configuração e credenciais](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html). O local do arquivo de credenciais varia de acordo com o sistema operacional que você está usando: + macOS, Linux: `~/.aws/credentials` + Windows: `C:\Users\UserName\.aws\credentials` Adicione suas AWS credenciais ao `credentials` arquivo no seguinte formato: ``` [default] aws_access_key_id = aws_secret_access_key = ``` Para configurar o IDT AWS IoT Greengrass para usar AWS as credenciais do seu `credentials` arquivo, edite seu `config.json` arquivo da seguinte forma: ``` { "awsRegion": "us-west-2", "auth": { "method": "file", "credentials": { "profile": "default" } } } ``` **nota** Se você não usar o `default` AWS perfil, não se esqueça de alterar o nome do perfil no seu `config.json` arquivo. Para obter mais informações, consulte [Perfis nomeados](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html). ### Configurar AWS credenciais com variáveis de ambiente As variáveis de ambiente são variáveis mantidas pelo sistema operacional e usadas pelos comandos do sistema. Elas não serão salvas se você fechar a sessão SSH. O IDT for AWS IoT Greengrass pode usar as variáveis de `AWS_SECRET_ACCESS_KEY` ambiente `AWS_ACCESS_KEY_ID` e para armazenar suas AWS credenciais. Para definir essas variáveis no Linux, macOS ou Unix, use :**export** ``` export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY= ``` Para definir essas variáveis no Windows, use :**set** ``` set AWS_ACCESS_KEY_ID= set AWS_SECRET_ACCESS_KEY= ``` Para configurar o IDT para usar as variáveis de ambiente, edite a seção `auth` no seu arquivo `config.json`. Exemplo: ``` { "awsRegion": "us-west-2", "auth": { "method": "environment" } } ``` ## Configurar device.json Além das AWS credenciais, o IDT for AWS IoT Greengrass precisa de informações sobre os dispositivos nos quais os testes são executados (por exemplo, endereço IP, informações de login, sistema operacional e arquitetura da CPU). Você deve fornecer essas informações usando o modelo `device.json` localizado em ` /configs/device.json`: ------ #### [ Physical device ] ``` [ { "id": "", "sku": "", "features": [ { "name": "os", "value": "linux | ubuntu | openwrt" }, { "name": "arch", "value": "x86_64 | armv6l | armv7l | aarch64" }, { "name": "container", "value": "yes | no" }, { "name": "docker", "value": "yes | no" }, { "name": "streamManagement", "value": "yes | no" }, { "name": "hsi", "value": "yes | no" }, { "name": "ml", "value": "mxnet | tensorflow | dlr | mxnet,dlr,tensorflow | no" }, *********** Remove the section below if the device is not qualifying for ML **************, { "name": "mlLambdaContainerizationMode", "value": "container | process | both" }, { "name": "processor", "value": "cpu | gpu" }, ****************************************************************************************** ], *********** Remove the section below if the device is not qualifying for HSI *************** "hsm": { "p11Provider": "/path/to/pkcs11ProviderLibrary", "slotLabel": "", "slotUserPin": "", "privateKeyLabel": "", "openSSLEngine": "/path/to/openssl/engine" }, ******************************************************************************************** *********** Remove the section below if the device is not qualifying for ML **************** "machineLearning": { "dlrModelPath": "/path/to/compiled/dlr/model", "environmentVariables": [ { "key": "", "value": "" } ], "deviceResources": [ { "name": "", "path": "", "type": "device | volume" } ] }, ****************************************************************************************** "kernelConfigLocation": "", "greengrassLocation": "", "devices": [ { "id": "", "connectivity": { "protocol": "ssh", "ip": "", "port": 22, "auth": { "method": "pki | password", "credentials": { "user": "", "privKeyPath": "/path/to/private/key", "password": "" } } } } ] } ] ``` **nota** Especifique `privKeyPath` somente se `method` estiver definido como `pki`. Especifique `password` somente se `method` estiver definido como `password`. ------ #### [ Docker container ] ``` [ { "id": "", "sku": "", "features": [ { "name": "os", "value": "linux | ubuntu | openwrt" }, { "name": "arch", "value": "x86_64" }, { "name": "container", "value": "no" }, { "name": "docker", "value": "no" }, { "name": "streamManagement", "value": "yes | no" }, { "name": "hsi", "value": "no" }, { "name": "ml", "value": "mxnet | tensorflow | dlr | mxnet,dlr,tensorflow | no" }, *********** Remove the section below if the device is not qualifying for ML **************, { "name": "mlLambdaContainerizationMode", "value": "process" }, { "name": "processor", "value": "cpu | gpu" }, ****************************************************************************************** ], *********** Remove the section below if the device is not qualifying for ML **************** "machineLearning": { "dlrModelPath": "/path/to/compiled/dlr/model", "environmentVariables": [ { "key": "", "value": "" } ], "deviceResources": [ { "name": "", "path": "", "type": "device | volume" } ] }, ****************************************************************************************** "kernelConfigLocation": "", "greengrassLocation": "", "devices": [ { "id": "", "connectivity": { "protocol": "docker", "containerId": "", "containerUser": "" } } ] } ] ``` ------ Todos os campos que contêm valores são necessários, conforme descrito aqui: `id` Um ID alfanumérico definido pelo usuário que identifica uma coleção de dispositivos chamada de *grupo de dispositivos*. Os dispositivos que pertencem a um grupo devem ter hardware idêntico. Quando um conjunto de testes é executado, os dispositivos do grupo são usados para paralelizar a workload. Vários dispositivos são usados para executar testes diferentes. `sku` Um valor alfanumérico que identifica exclusivamente o dispositivo em teste. A SKU é usada para rastrear as placas qualificadas. Se você quiser listar sua placa no Catálogo de AWS Partner dispositivos, o SKU especificado aqui deve corresponder ao SKU que você usa no processo de listagem. `features` Uma matriz que contém atributos compatíveis com o dispositivo. Todos os atributos são obrigatórios. `os` e `arch` Combinações de sistema operacional (SO) e arquitetura compatíveis: + `linux`, `x86_64` + `linux`, `armv6l` + `linux`, `armv7l` + `linux`, `aarch64` + `ubuntu`, `x86_64` + `openwrt`, `armv7l` + `openwrt`, `aarch64` Se você usa o IDT para testar a AWS IoT Greengrass execução em um contêiner Docker, somente a arquitetura x86\$164 Docker é suportada. `container` Verifica se o dispositivo atende a todos os requisitos de software e hardware para executar as funções do Lambda no modo de contêiner em um núcleo do Greengrass. O valor válido é `yes` ou `no`. `docker` Valida que o dispositivo atende a todas as dependências técnicas necessárias para usar o conector de implantação do aplicativo Docker do Greengrass a fim de executar contêineres. O valor válido é `yes` ou `no`. `streamManagement` Valida se o dispositivo atende a todas as dependências técnicas necessárias para executar o gerenciador de AWS IoT Greengrass streams. O valor válido é `yes` ou `no`. `hsi` Verifica se a biblioteca compartilhada HSI fornecida pode interagir com o módulo de segurança de hardware (HSM) e implementa corretamente o PKCS \$111 necessário. APIs A biblioteca do HSM e compartilhada deve assinar uma CSR, executar operações TLS e fornecer os tamanhos de chaves e o algoritmo de chave pública corretos. O valor válido é `yes` ou `no`. `ml` Valida que o dispositivo atende a todas as dependências técnicas necessárias para executar a inferência de ML localmente. O valor válido pode ser qualquer combinação de `mxnet`, `tensorflow`, `dlr` e `no` (por exemplo, `mxnet`, `mxnet,tensorflow`, `mxnet,tensorflow,dlr` ou `no`). `mlLambdaContainerizationMode` Verifica se o dispositivo atende a todas as dependências técnicas necessárias para executar a inferência de ML em modo contêiner em um dispositivo do Greengrass. O valor válido é `container`, `process` ou `both`. `processor` Verifica se o dispositivo atende a todos os requisitos de hardware do tipo de processador especificado. O valor válido é `cpu` ou `gpu`. Se você não quiser usar o atributo `container`, `docker`, `streamManager`, `hsi` ou `ml`, você pode definir o correspondente `value` a `no`. O Docker só oferece suporte à qualificação de atributos para `streamManagement` e `ml`. `machineLearning` Opcional. Informações de configuração para testes de qualificação de ML. Para obter mais informações, consulte [Configurar device.json para qualificação de ML](#device-json-ml-qualification). `hsm` Opcional. Informações de configuração para testes com um módulo AWS IoT Greengrass de segurança de hardware (HSM). Caso contrário, a propriedade `hsm` deve ser omitida. Para obter mais informações, consulte [Integração de segurança de hardware](hardware-security.md). Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `ssh`. `hsm.p11Provider` O caminho absoluto para a biblioteca carregável libdl da implementação PKCS\$111. `hsm.slotLabel` O rótulo de slot usado para identificar o módulo de hardware. `hsm.slotUserPin` O PIN do usuário usado para autenticar o AWS IoT Greengrass núcleo no módulo. `hsm.privateKeyLabel` O rótulo usado para identificar a chave no módulo de hardware. `hsm.openSSLEngine` O caminho absoluto para o arquivo `.so` do mecanismo OpenSSL para habilitar o suporte ao PKCS\$111 no OpenSSL. Usado pelo agente de atualização AWS IoT Greengrass OTA. `devices.id` Um identificador exclusivo, definido pelo usuário, para o dispositivo que está sendo testado. `connectivity.protocol` O protocolo de comunicação usado para se comunicar com esse dispositivo. No momento, os únicos valores compatíveis são `ssh` para dispositivos físicos e `docker` para contêineres do Docker. `connectivity.ip` O endereço IP do dispositivo que está sendo testado. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `ssh`. `connectivity.containerId` O ID do contêiner ou o nome do contêiner do Docker que está sendo testado. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `docker`. `connectivity.auth` Informações de autenticação da conexão. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `ssh`. `connectivity.auth.method` O método de autenticação usado para acessar um dispositivo pelo protocolo de conectividade indicado. Os valores compatíveis são: + `pki` + `password` `connectivity.auth.credentials` As credenciais usadas para autenticação. `connectivity.auth.credentials.password` A senha usada para fazer login no dispositivo que está sendo testado. Esse valor se aplica somente se `connectivity.auth.method` estiver definido como `password`. `connectivity.auth.credentials.privKeyPath` O caminho completo para a chave privada usada para fazer login no dispositivo que está sendo testado. Esse valor se aplica somente se `connectivity.auth.method` estiver definido como `pki`. `connectivity.auth.credentials.user` O nome de usuário para fazer login no dispositivo que está sendo testado. `connectivity.auth.credentials.privKeyPath` O caminho completo para a chave privada usada para fazer login no dispositivo que está sendo testado. `connectivity.port` Opcional. O número da porta usada nas conexões SSH. O valor padrão é 22. Essa propriedade só se aplica se `connectivity.protocol` estiver definido como `ssh`. `greengrassLocation` A localização do software AWS IoT Greengrass Core em seus dispositivos. Para dispositivos físicos, esse valor é usado somente quando você usa uma instalação existente do AWS IoT Greengrass. Use esse atributo para instruir o IDT a usar a versão do software do núcleo do AWS IoT Greengrass instalada nos dispositivos. Ao executar testes em um contêiner do Docker a partir da imagem do Docker ou do Dockerfile fornecido por AWS IoT Greengrass, defina esse valor como. `/greengrass` `kernelConfigLocation` Opcional. O caminho para o arquivo de configuração do kernel. AWS IoT O Device Tester usa esse arquivo para verificar se os dispositivos têm os recursos necessários do kernel habilitados. Se não for especificado, o IDT usa os seguintes caminhos para pesquisar o arquivo de configuração do kernel: e. `/proc/config.gz` `/boot/config-` AWS IoT O Device Tester usará o primeiro caminho que encontrar. ## Configurar device.json para qualificação de ML Esta seção descreve as propriedades opcionais no arquivo de configuração do dispositivo que se aplicam à qualificação de ML. Se você planeja executar testes para qualificação de ML, é necessário definir as propriedades que se aplicam ao caso de uso. Você pode usar o modelo `device-ml.json` para definir as configurações do dispositivo. Este modelo contém as propriedades de ML opcionais. Você também pode usar `device.json` e adicionar as propriedades de qualificação de ML. Esses arquivos estão localizados em `/configs` e incluem propriedades de qualificação de ML. Se usar `device-ml.json`, você deve renomear o arquivo como `device.json` antes de executar testes do IDT. Para obter informações sobre propriedades de configuração de dispositivo que não se aplicam à qualificação de ML, consulte [Configurar device.json](#device-config).   `ml` na matriz `features` As estruturas de ML compatíveis com a sua placa. Esta propriedade requer a versão 3.1.0 ou posterior do IDT. + Caso a sua placa seja compatível com uma estrutura somente, especifique a estrutura. Por exemplo: ``` { "name": "ml", "value": "mxnet" } ``` + Caso a sua placa seja compatível com várias estruturas, especifique as estruturas como uma lista separada por vírgulas. Por exemplo: ``` { "name": "ml", "value": "mxnet,tensorflow" } ``` `mlLambdaContainerizationMode` na matriz `features` O [modo de conteinerização](lambda-group-config.md#lambda-containerization-considerations) com o qual você deseja testar. Esta propriedade requer a versão 3.1.0 ou posterior do IDT. + Selecione `process` para executar o código de inferência de ML com uma função do Lambda sem contêineres. Essa opção requer a AWS IoT Greengrass versão v1.10.x ou posterior. + Selecione `container` para executar o código de inferência de ML com uma função do Lambda em contêineres. + Selecione `both` para executar o código de inferência de ML com ambos os modos. Essa opção requer a AWS IoT Greengrass versão v1.10.x ou posterior. `processor` na matriz `features` Indica o acelerador de hardware compatível com a placa. Esta propriedade requer a versão 3.1.0 ou posterior do IDT. + Selecione `cpu` se sua placa usa uma CPU como processador. + Selecione `gpu` se a sua placa usa uma GPU como processador. `machineLearning` Opcional. Informações de configuração para testes de qualificação de ML. Esta propriedade requer a versão 3.1.0 ou posterior do IDT. `dlrModelPath` É necessário usar a estrutura do `dlr`. O caminho absoluto para o diretório de modelo compilado do DLR, que deve ser chamado de `resnet18`. Para obter mais informações, consulte [Compilar o modelo de DLR](idt-ml-qualification.md#ml-qualification-dlr-compile-model). Veja a seguir um exemplo de caminho no macOS: `/Users//Downloads/resnet18`. `environmentVariables` Uma matriz de pares de chave/valor que pode passar dinamicamente configurações para testes de inferência de ML. Opcional para dispositivos de CPU. Você pode usar esta seção para adicionar variáveis de ambiente específicas da estrutura exigidas pelo tipo de dispositivo. Para obter informações sobre esses requisitos, consulte o site oficial da estrutura ou do dispositivo. Por exemplo, para executar testes de MXNet inferência em alguns dispositivos, as seguintes variáveis de ambiente podem ser necessárias. ``` "environmentVariables": [ ... { "key": "PYTHONPATH", "value": "$MXNET_HOME/python:$PYTHONPATH" }, { "key": "MXNET_HOME", "value": "$HOME/mxnet/" }, ... ] ``` O `value` campo pode variar de acordo com sua MXNet instalação. Se você estiver testando funções do Lambda executadas com [conteinerização](lambda-group-config.md#lambda-containerization-considerations) em dispositivos de GPU, adicione variáveis de ambiente para a biblioteca de GPU. Isso possibilita a realização de cálculos pela GPU. Para usar bibliotecas de GPU diferentes, consulte a documentação oficial da biblioteca ou do dispositivo. Configure as chaves a seguir se o atributo `mlLambdaContainerizationMode` estiver definido como `container` ou `both`. ``` "environmentVariables": [ { "key": "PATH", "value": ":$PATH" }, { "key": "LD_LIBRARY_PATH", "value": "" }, ... ] ``` `deviceResources` Obrigatório para dispositivos de GPU. Contém [recursos locais](access-local-resources.md#lra-resource-types) que podem ser acessados por funções do Lambda. Use esta seção para adicionar recursos de dispositivo e de volume locais. + Para recursos de dispositivo, especifique `"type": "device"`. Para dispositivos GPU, os recursos do dispositivo devem ser arquivos de dispositivo relacionados à GPU em `/dev`. **nota** O diretório `/dev/shm` é uma exceção. Ele pode ser configurado apenas como um recursos de volume. + Para recursos de volume, especifique `"type": "volume"`. # Execute o pacote AWS IoT Greengrass de qualificação Depois de [definir a configuração necessária](set-config.md), você poderá iniciar os testes. O runtime do conjunto de testes completo depende do seu hardware. Como referência, leva aproximadamente 30 minutos para concluir o pacote de testes completo em um Raspberry Pi 3B. Os comandos de exemplo `run-suite` a seguir mostram como executar os testes de qualificação para um grupo de dispositivos. Um grupo de dispositivos é um conjunto de dispositivos idênticos. ------ #### [ IDT v3.0.0 and later ] Execute todos os grupos de teste em um conjunto de testes especificado. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1.0.0 --pool-id ``` Use o comando `list-suites` para listar os conjuntos de testes que estão na pasta `tests`. Execute um grupo de testes específico em um conjunto de testes. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1.0.0 --group-id --pool-id ``` Use o comando `list-groups` para listar os grupos de teste em um conjunto de testes. Execute um caso de teste específico em um grupo de teste. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id --test-id ``` Execute vários casos de teste em um grupo de teste. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id --test-id , ``` Liste os casos de teste em um grupo de teste. ``` devicetester_[linux | mac | win_x86-64] list-test-cases --group-id ``` As opções para o comando `run-suite` são opcionais. Por exemplo, você pode omitir `pool-id` se tiver apenas um único grupo de dispositivos definido no arquivo `device.json`. Você também pode omitir `suite-id` se quiser executar a versão mais recente do conjunto de testes na pasta `tests`. **nota** O IDT avisará se uma versão mais recente do conjunto de testes estiver disponível online. Para obter mais informações, consulte [Defina o comportamento de atualização padrão](#idt-update-behavior). Para obter mais informações sobre `run-suite` e outros comandos IDT, consulte [IDT para comandos AWS IoT Greengrass](#bk-cli). ------ #### [ IDT v2.3.0 and earlier ] Execute todos os grupos de teste em um conjunto especificado. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1 --pool-id ``` Execute um grupo de teste específico. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1 --group-id --pool-id ``` `suite-id` e `pool-id` são opcionais se você estiver executando um único conjunto de testes em um único grupo de dispositivos. Isso significa que você tem apenas um grupo de dispositivos definido em seu arquivo `device.json`. ------ ## Verifique as dependências do Greengrass Recomendamos executar o grupo de testes do verificador de dependência para garantir que todas as dependências do Greengrass estejam instaladas antes de executar grupos de testes relacionados. Por exemplo: + Execute `ggcdependencies` antes de executar grupos de testes de qualificação de núcleo. + Execute `containerdependencies` antes de executar grupos de teste específicos do contêiner. + Execute `dockerdependencies` antes de executar grupos de teste específicos do Docker. + Execute `ggcstreammanagementdependencies` antes de executar grupos de testes específicos do gerenciador de fluxos. ## Defina o comportamento de atualização padrão Quando você inicia uma execução de teste, o IDT verifica online se há uma versão mais recente do conjunto de testes. Se houver, o IDT solicitará que você atualize para a versão mais recente disponível. Você pode definir o sinalizador `upgrade-test-suite` (ou `u`) para controlar o comportamento de atualização padrão. Os valores válidos são: + `y`. O IDT faz download e usa a versão mais recente disponível. + `n` (padrão). O IDT usa a versão especificada na opção `suite-id`. Se `suite-id` não for especificado, o IDT usará a versão mais recente na pasta `tests`. Se você não incluir o sinalizador `upgrade-test-suite`, o IDT solicitará quando uma atualização estiver disponível e aguardará 30 segundos por sua entrada (`y` ou `n`). Se nenhuma entrada for inserida, ela assumirá `n` como padrão e continuará executando os testes. Os exemplos a seguir mostram casos de uso comuns para esse atributo: **Usar automaticamente os testes mais recentes disponíveis para um grupo de testes.** ``` devicetester_linux run-suite -u y --group-id mqtt --pool-id DevicePool1 ``` **Execute testes em uma versão específica do conjunto de testes.** ``` devicetester_linux run-suite -u n --suite-id GGQ_1.0.0 --group-id mqtt --pool-id DevicePool1 ``` **Solicitar atualizações em tempo de execução.** ``` devicetester_linux run-suite --pool-id DevicePool1 ``` ## IDT para comandos AWS IoT Greengrass Os comandos do IDT estão localizados no diretório `/bin`. Use-os para as seguintes operações: ------ #### [ IDT v3.0.0 and later ] `help` Lista as informações sobre o comando especificado. `list-groups` Lista os grupos em um determinado conjunto de teste. `list-suites` Lista os conjuntos de teste disponíveis. `list-supported-products` Lista os produtos suportados, neste caso AWS IoT Greengrass as versões, e as versões do conjunto de testes para a versão atual do IDT. `list-test-cases` Lista os casos de teste em um grupo de teste. A seguinte opção é compatível: + `group-id`. O grupo de teste a ser pesquisado. Esta opção é necessária e deve especificar um único grupo. `run-suite` Executa um conjunto de testes em um grupo de dispositivos. Algumas opções compatíveis estão listadas a seguir: + `suite-id`. A versão do conjunto de testes a ser executada. Se não for especificado, o IDT usará a versão mais recente na pasta `tests`. + `group-id`. Os grupos de teste a serem executados, como uma lista separada por vírgulas. Se não for especificado, o IDT executa todos os grupos de teste no conjunto de testes. + `test-id`. Os casos de teste a serem executados, como uma lista separada por vírgulas. Quando especificado, `group-id` deve especificar um único grupo. + `pool-id`. O grupo de dispositivos a ser testado. Você deve especificar um grupo se tiver vários grupos de dispositivos definidos no arquivo `device.json`. + `upgrade-test-suite`. Controla como as atualizações da versão do conjunto de testes são tratadas. A partir do IDT v3.0.0, o IDT verifica online as versões atualizadas do conjunto de testes. Para obter mais informações, consulte [Versões do pacote de testes](idt-gg-qualification.md#idt-test-suite-versions). + `stop-on-first-failure`. Configura o IDT de modo a interromper a execução na primeira falha. Essa opção deve ser usada com para depurar os grupos de teste especificados `group-id`. Não use essa opção para gerar um relatório de qualificação ao executar um conjunto de testes completo. + `update-idt`. Define a resposta para que o prompt atualize o IDT. O `Y` como entrada interrompe a execução do teste se o IDT detectar que há uma versão mais recente. O `N` como entrada continua a execução do teste. + `update-managed-policy`. O `Y` como entrada interrompe a execução do teste se o IDT detectar que a política gerenciada do usuário não foi atualizada. O `N` como entrada continua a execução do teste. Para obter mais informações sobre as opções `run-suite`, use a opção `help`: ``` devicetester_[linux | mac | win_x86-64] run-suite -h ``` ------ #### [ IDT v2.3.0 and earlier ] `help` Lista as informações sobre o comando especificado. `list-groups` Lista os grupos em um determinado conjunto de teste. `list-suites` Lista os conjuntos de teste disponíveis. `run-suite` Executa um conjunto de testes em um grupo de dispositivos. Para obter mais informações sobre as opções `run-suite`, use a opção `help`: ``` devicetester_[linux | mac | win_x86-64] run-suite -h ``` ------ # Noções básicas de resultados e logs Esta seção descreve como visualizar e interpretar os resultados de relatórios e logs do IDT. ## Visualização de resultados Enquanto em execução, o IDT grava erros no console, arquivos de log e relatórios de teste. Depois de concluir o conjunto de testes de qualificação, o IDT gera dois relatórios de teste. Esses relatórios podem ser encontrados em `/results//`. Ambos os relatórios capturam os resultados da execução do pacote de teste de qualificação. Esse `awsiotdevicetester_report.xml` é o relatório do teste de qualificação que você envia AWS para listar seu AWS Partner dispositivo no Catálogo de dispositivos. O relatório contém os seguintes elementos: + A versão IDT. + A AWS IoT Greengrass versão que foi testada. + A SKU e o nome de grupo do dispositivo especificados no arquivo `device.json`. + Os atributos do grupo do dispositivo especificados no arquivo `device.json`. + O resumo agregado dos resultados de teste. + Um detalhamento dos resultados de teste pelas bibliotecas que foram testadas, com base nos atributos do dispositivo (por exemplo, acesso de recurso local, shadow, MQTT e assim por diante). O `GGQ_Result.xml` relatório está no [formato JUnit XML](https://llg.cubic.org/docs/junit/). Você pode integrá-lo em plataformas de integração e implantação como [Jenkins](https://jenkins.io/), [Bamboo](https://www.atlassian.com/software/bamboo) e assim por diante. O relatório contém os seguintes elementos: + Um resumo agregado dos resultados de teste. + Detalhamento dos resultados do teste pela AWS IoT Greengrass funcionalidade que foi testada. ## Interpretando os relatórios do IDT A seção de relatório em `awsiotdevicetester_report.xml` ou `awsiotdevicetester_report.xml` lista os testes que foram executados e os resultados. A primeira tag XML `` contém o resumo da execução do teste. Por exemplo: ``` ```recursos usados na tag `` `name` O nome do conjunto de testes. `time` O tempo, em segundos, necessário para executar o conjunto de qualificação. `tests` O número de testes executados. `failures` O número de testes que foram executados, mas não foram aprovados. `errors` O número de testes que não puderam ser executados pelo IDT. `disabled` Esse recurso não é usado e pode ser ignorado. O arquivo `awsiotdevicetester_report.xml` contém uma tag `` com informações sobre o produto que está sendo testado e os atributos do produto que foram validados após a execução de um pacote de testes.recursos usados na tag `` `name` O nome do produto testado. `version` A versão do produto testado. `features` Os atributos validados. Atributos marcados como `required` são necessários para enviar sua placa para qualificação. O trecho a seguir mostra como essas informações aparecem no arquivo `awsiotdevicetester_report.xml`. ``` ``` Os atributos marcados como `optional` não são necessários para qualificação. Os seguintes trechos mostram atributos opcionais. ``` 
 ``` Se não houver falhas de teste ou erros nos recursos necessários, seu dispositivo atende aos requisitos técnicos para ser executado AWS IoT Greengrass e pode interoperar com AWS IoT os serviços. Se quiser listar seu AWS Partner dispositivo no Catálogo de dispositivos, você pode usar esse relatório como evidência de qualificação. Se houver falhas de teste ou erros, você poderá identificar o teste com falha analisando as tags XML ``. As tags XML `` dentro da tag `` mostram o resumo do resultado do teste para um grupo de testes. Por exemplo: ``` ``` O formato é semelhante à tag ``, mas com um recurso `skipped` que não é usado e pode ser ignorado. Dentro de cada tag XML ``, há tags `` para cada teste executado para um grupo de testes. Por exemplo: ``` > ```recursos usados na tag `` `name` O nome do teste. `attempts` O número de vezes que o IDT executou o caso de teste. Quando um teste falha ou ocorre um erro, as tags `` ou `` são adicionadas à tag `` com informações para a solução de problemas. Por exemplo: ``` Reason for the test failure Reason for the test execution error ``` ## Visualizar logs O IDT gera logs de teste em execução em `/results//logs`. Dois conjuntos de logs são gerados: `test_manager.log` Registros gerados a partir do componente Test Manager do AWS IoT Device Tester (por exemplo, registros relacionados à configuração, sequenciamento de testes e geração de relatórios). `.log (for example, ota.log)` Os logs do grupo de testes, incluindo logs do dispositivo em teste. Quando um teste falhar, um arquivo tar.gz com os logs do dispositivo em teste para o teste será criado (por exemplo, `ota_prod_test_1_ggc_logs.tar.gz`). Para obter mais informações, consulte [IDT para solução de problemas AWS IoT Greengrass](idt-troubleshooting.md). # Usar o IDT para desenvolver e executar os próprios pacotes de testes A partir do IDT v4.0.0, o IDT for AWS IoT Greengrass combina uma configuração padronizada e um formato de resultado com um ambiente de suíte de testes que permite desenvolver suítes de testes personalizadas para seus dispositivos e software de dispositivos. É possível adicionar testes personalizados para sua própria validação interna ou fornecê-los aos seus clientes para verificação de dispositivo. Use o IDT para desenvolver e executar pacotes de testes personalizados da seguinte forma: **Para desenvolver conjuntos de testes personalizados** + Crie conjuntos de testes com lógica de teste personalizada para o dispositivo Greengrass que você deseja testar. + Forneça ao IDT seus conjuntos de testes personalizados para os executores de testes. Inclua informações sobre configurações específicas para seus pacotes de teste. **Para executar pacotes de testes personalizados** + Configure o dispositivo que deseja testar. + Implemente as configurações conforme exigido pelos pacotes de testes que deseja usar. + Use o IDT para executar seus pacotes de teste personalizados. + Veja os resultados do teste e os logs de execução dos testes executados pelo IDT. ## Baixe a versão mais recente do AWS IoT Device Tester para AWS IoT Greengrass Baixe a [versão mais recente](dev-test-versions.md) do IDT e extraia o software em um local no seu sistema de arquivos onde você tenha permissões de leitura e gravação. **nota** O IDT não oferece suporte a execução por vários usuários em um local compartilhado, como um diretório NFS ou uma pasta compartilhada de rede do Windows. Recomendamos extrair o pacote do IDT para uma unidade local e executar o binário do IDT na estação de trabalho local. O Windows tem uma limitação de comprimento de caminho de 260 caracteres. Se você estiver usando o Windows, extraia o IDT para um diretório raiz como `C:\ ` ou `D:\` para manter os caminhos abaixo do limite de 260 caracteres. ## Fluxo de trabalho de criação de pacotes de teste Os conjuntos de testes são compostos por três tipos de arquivos: + Arquivos de configuração JSON que fornecem ao IDT informações sobre como executar o conjunto de testes. + Arquivos executáveis de teste que o IDT usa para executar casos de teste. + Arquivos adicionais necessários para executar testes. Conclua as etapas básicas a seguir para criar testes de IDT personalizados: 1. [Criação de arquivos de configuração JSON](idt-json-config.md) para seu conjunto de testes. 1. [Crie executáveis de casos de teste](test-executables.md) que contenham a lógica de teste para seu conjunto de testes. 1. Verifique e documente as [informações de configuração necessárias para que os executores de teste](set-config-custom.md) executem o pacote de teste. 1. Verifique se o IDT pode executar seu pacote de teste e produzir [resultados de teste](run-tests-custom.md) conforme o esperado. Para criar rapidamente uma amostra de pacote personalizado e executá-la, siga as instruções em [Tutorial: compile e execute o pacote de amostra de teste de IDT](build-sample-suite.md). Para começar a criar um pacote de testes personalizado em Python, consulte [Tutorial: desenvolva um pacote de testes de IDT simples](create-custom-tests.md). # Tutorial: compile e execute o pacote de amostra de teste de IDT O download do AWS IoT Device Tester inclui o código-fonte de uma amostra de suíte de testes. Você pode concluir este tutorial para criar e executar a suíte de testes de amostra para entender como usar o AWS IoT Device Tester AWS IoT Greengrass para executar suítes de testes personalizadas. Neste tutorial, você concluirá as seguintes etapas: 1. [Compile o pacote de teste de amostra](#build-sample) 1. [Usar o IDT para executar o pacote de teste de amostra](#run-sample) ## Pré-requisitos Para concluir este tutorial, você precisará do seguinte: + **Requisitos do computador host** + Versão mais recente do AWS IoT Device Tester + [Python](https://www.python.org/downloads/) 3.7 ou posterior Para verificar a versão do Python instalada em seu computador, execute o seguinte comando: ``` python3 --version ``` No Windows, se o uso deste comando retornar um erro, use `python --version`. Se o número da versão retornada for 3.7 ou superior, execute o seguinte comando em um terminal do Powershell para definir `python3` como um alias para seu comando `python`. ``` Set-Alias -Name "python3" -Value "python" ``` Se nenhuma informação sobre versão for retornada ou se o número da versão for menor do que 3.7, siga as instruções em [Fazer download do Python](https://wiki.python.org/moin/BeginnersGuide/Download) para instalar o Python 3.7\$1. Para obter mais informações, consulte a [Documentação do Python](https://docs.python.org). + [urllib3](https://urllib3.readthedocs.io/en/latest/) Para verificar se `urllib3` está instalado corretamente, execute o seguinte comando: ``` python3 -c 'import urllib3' ``` Se o `urllib3` não estiver instalado, execute o comando a seguir para instalá-lo: ``` python3 -m pip install urllib3 ``` + **Requisitos do dispositivo** + Um dispositivo com sistema operacional Linux e uma conexão de rede com a mesma rede do seu computador host. É recomendado o uso de um [Raspberry Pi](https://www.raspberrypi.org/) com o sistema operacional Raspberry Pi. Certifique-se de configurar o [SSH](https://www.raspberrypi.org/documentation/remote-access/ssh/) no seu Raspberry Pi para se conectar remotamente a ele. ## Configurar as informações do dispositivo para o IDT Configure as informações do seu dispositivo para o IDT executar o teste. É preciso atualizar o modelo `device.json` localizado na pasta `/configs` com as informações a seguir. ``` [ { "id": "pool", "sku": "N/A", "devices": [ { "id": "", "connectivity": { "protocol": "ssh", "ip": "", "port": "", "auth": { "method": "pki | password", "credentials": { "user": "", "privKeyPath": "/path/to/private/key", "password": "" } } } } ] } ] ``` No objeto `devices`, forneça as seguintes informações: `id` Um identificador exclusivo, definido pelo usuário, para o seu dispositivo. `connectivity.ip` O endereço IP do seu dispositivo. `connectivity.port` Opcional. O número da porta que deve ser usado nas conexões SSH ao seu dispositivo. `connectivity.auth` Informações de autenticação da conexão. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `ssh`. `connectivity.auth.method` O método de autenticação usado para acessar um dispositivo pelo protocolo de conectividade indicado. Os valores compatíveis são: + `pki` + `password` `connectivity.auth.credentials` As credenciais usadas para autenticação. `connectivity.auth.credentials.user` O nome de usuário usado para fazer login no seu dispositivo. `connectivity.auth.credentials.privKeyPath` O caminho completo para a chave privada usada para fazer login no dispositivo. Esse valor se aplica somente se `connectivity.auth.method` estiver definido como `pki`. `devices.connectivity.auth.credentials.password` A senha usada para fazer login no dispositivo. Esse valor se aplica somente se `connectivity.auth.method` estiver definido como `password`. **nota** Especifique `privKeyPath` somente se `method` estiver definido como `pki`. Especifique `password` somente se `method` estiver definido como `password`. ## Compile o pacote de teste de amostra A pasta `/samples/python` contém exemplos de arquivos de configuração, código-fonte e o SDK do cliente IDT que você pode combinar em um pacote de teste usando os scripts de compilação fornecidos. A seguinte árvore de diretórios mostra a localização desses arquivos de amostra: ``` ├── ... ├── tests ├── samples │ ├── ... │ └── python │ ├── configuration │ ├── src │ └── build-scripts │ ├── build.sh │ └── build.ps1 └── sdks ├── ... └── python └── idt_client ``` Para compilar o pacote de teste, execute os seguintes comandos em seu computador host: ------ #### [ Windows ] ``` cd /samples/python/build-scripts ./build.ps1 ``` ------ #### [ Linux, macOS, or UNIX ] ``` cd /samples/python/build-scripts ./build.sh ``` ------ Isso compila o conjunto de testes de amostra na pasta `IDTSampleSuitePython_1.0.0` dentro da pasta `/tests`. Examine os arquivos na pasta `IDTSampleSuitePython_1.0.0` para entender como o conjunto de testes de amostra está estruturado e confira vários exemplos de executáveis de casos de teste e arquivos JSON de configuração de teste. Próxima etapa: Usar o IDT para [executar o conjunto de testes de amostra](#run-sample) que você criou. ## Usar o IDT para executar o pacote de teste de amostra Para executar o pacote de teste de amostra, execute os seguintes comandos em seu computador host: ``` cd /bin ./devicetester_[linux | mac | win_x86-64] run-suite --suite-id IDTSampleSuitePython ``` O IDT executa o pacote de teste de amostra e transmite os resultados para o console. Quando a execução do teste é concluída, são vistas as seguintes informações: ``` ========== Test Summary ========== Execution Time: 5s Tests Completed: 4 Tests Passed: 4 Tests Failed: 0 Tests Skipped: 0 ---------------------------------- Test Groups: sample_group: PASSED ---------------------------------- Path to IoT Device Tester Report: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/awsiotdevicetester_report.xml Path to Test Execution Logs: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/logs Path to Aggregated JUnit Report: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/IDTSampleSuitePython_Report.xml ``` ## Solução de problemas Use as informações a seguir para ajudar a resolver os problemas ao concluir o tutorial. **Caso de teste não é executado** Se o teste não for executado, o IDT transmitirá os logs de erro para o console e isso pode ajudar a solucionar o problema de execução do teste. Verifique se todos os [pré-requisitos deste tutorial](#prereqs-tutorial-sample) são atendidos. **Não é possível se conectar ao dispositivo em teste** Verifique o seguinte: + Seu arquivo `device.json` contém o endereço IP, a porta e as informações de autenticação corretos. + Você pode se conectar ao seu dispositivo via SSH a partir do seu computador host. # Tutorial: desenvolva um pacote de testes de IDT simples Um conjunto de testes combina o seguinte: + Executáveis de teste que contêm a lógica de teste + Arquivos de configuração JSON que descrevem o conjunto de testes Este tutorial mostra como usar o IDT AWS IoT Greengrass para desenvolver uma suíte de testes em Python que contém um único caso de teste. Neste tutorial, você concluirá as seguintes etapas: 1. [Crie um diretório de pacotes de teste](#test-suite-dir) 1. [Criação de arquivos de configuração JSON](#test-suite-json) 1. [Crie o executável do caso de teste](#test-suite-exe) 1. [Execute o pacote de teste](#run-test-suite) ## Pré-requisitos Para concluir este tutorial, você precisará do seguinte: + **Requisitos do computador host** + Versão mais recente do AWS IoT Device Tester + [Python](https://www.python.org/downloads/) 3.7 ou posterior Para verificar a versão do Python instalada em seu computador, execute o seguinte comando: ``` python3 --version ``` No Windows, se o uso deste comando retornar um erro, use `python --version`. Se o número da versão retornada for 3.7 ou superior, execute o seguinte comando em um terminal do Powershell para definir `python3` como um alias para seu comando `python`. ``` Set-Alias -Name "python3" -Value "python" ``` Se nenhuma informação sobre versão for retornada ou se o número da versão for menor do que 3.7, siga as instruções em [Fazer download do Python](https://wiki.python.org/moin/BeginnersGuide/Download) para instalar o Python 3.7\$1. Para obter mais informações, consulte a [Documentação do Python](https://docs.python.org). + [urllib3](https://urllib3.readthedocs.io/en/latest/) Para verificar se `urllib3` está instalado corretamente, execute o seguinte comando: ``` python3 -c 'import urllib3' ``` Se o `urllib3` não estiver instalado, execute o comando a seguir para instalá-lo: ``` python3 -m pip install urllib3 ``` + **Requisitos do dispositivo** + Um dispositivo com sistema operacional Linux e uma conexão de rede com a mesma rede do seu computador host. É recomendado o uso de um [Raspberry Pi](https://www.raspberrypi.org/) com o sistema operacional Raspberry Pi. Certifique-se de configurar o [SSH](https://www.raspberrypi.org/documentation/remote-access/ssh/) no seu Raspberry Pi para se conectar remotamente a ele. ## Crie um diretório de pacotes de teste O IDT separa logicamente os casos de teste em grupos de teste dentro de cada pacote de teste. Cada caso de teste deve estar dentro de um grupo de teste. Para este tutorial, crie uma pasta chamada `MyTestSuite_1.0.0` e crie a seguinte árvore de diretórios nessa pasta: ``` MyTestSuite_1.0.0 └── suite └── myTestGroup └── myTestCase ``` ## Criação de arquivos de configuração JSON O conjunto de testes deve conter os seguintes [arquivos de configuração JSON](idt-json-config.md) necessários:Arquivos JSON necessários `suite.json` Contém informações sobre o conjunto de testes. Consulte [Configuração do suite.json](idt-json-config.md#suite-json). `group.json` Contém informações sobre um grupo de teste. É preciso criar um arquivo `group.json` para cada grupo de teste em seu pacote de teste. Consulte [Configurar group.json](idt-json-config.md#group-json). `test.json` Contém informações sobre um caso de teste. É preciso criar um arquivo `test.json` para cada caso de teste em seu pacote de teste. Consulte [Configurar test.json](idt-json-config.md#test-json). 1. Na pasta `MyTestSuite_1.0.0/suite`, crie um arquivo `suite.json` com a seguinte estrutura: ``` { "id": "MyTestSuite_1.0.0", "title": "My Test Suite", "details": "This is my test suite.", "userDataRequired": false } ``` 1. Na pasta `MyTestSuite_1.0.0/myTestGroup`, crie um arquivo `group.json` com a seguinte estrutura: ``` { "id": "MyTestGroup", "title": "My Test Group", "details": "This is my test group.", "optional": false } ``` 1. Na pasta `MyTestSuite_1.0.0/myTestGroup/myTestCase`, crie um arquivo `test.json` com a seguinte estrutura: ``` { "id": "MyTestCase", "title": "My Test Case", "details": "This is my test case.", "execution": { "timeout": 300000, "linux": { "cmd": "python3", "args": [ "myTestCase.py" ] }, "mac": { "cmd": "python3", "args": [ "myTestCase.py" ] }, "win": { "cmd": "python3", "args": [ "myTestCase.py" ] } } } ``` Agora, a árvore de diretórios da pasta `MyTestSuite_1.0.0` deve ser semelhante à seguinte: ``` MyTestSuite_1.0.0 └── suite ├── suite.json └── myTestGroup ├── group.json └── myTestCase └── test.json ``` ## Obtenha o SDK do cliente do IDT Use o [SDK de cliente do IDT](test-executables.md#idt-client-sdk) para permitir que o IDT interaja com o dispositivo testado e relate os resultados do teste. Neste tutorial, use a versão em Python do SDK. Na pasta `/sdks/python/`, copie a pasta `idt_client` para sua pasta `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase`. Para verificar se o SDK foi copiado com êxito, execute o comando a seguir. ``` cd MyTestSuite_1.0.0/suite/myTestGroup/myTestCase python3 -c 'import idt_client' ``` ## Crie o executável do caso de teste Os executáveis do caso de teste contêm a lógica de teste que você deseja executar. Um pacote de teste pode conter vários executáveis de casos de teste. Para este tutorial, crie somente um executável de caso de teste. 1. Crie o arquivo do pacote de teste. Na pasta `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase`, crie um arquivo `myTestCase.py` com o seguinte conteúdo: ``` from idt_client import * def main(): # Use the client SDK to communicate with IDT client = Client() if __name__ == "__main__": main() ``` 1. Use as funções do SDK de cliente para adicionar a seguinte lógica de teste ao seu arquivo `myTestCase.py`: 1. Execute um comando SSH no dispositivo em teste. ``` from idt_client import * def main(): # Use the client SDK to communicate with IDT client = Client() # Create an execute on device request exec_req = ExecuteOnDeviceRequest(ExecuteOnDeviceCommand("echo 'hello world'")) # Run the command exec_resp = client.execute_on_device(exec_req) # Print the standard output print(exec_resp.stdout) if __name__ == "__main__": main() ``` 1. Envie o resultado do teste para o IDT. ``` from idt_client import * def main(): # Use the client SDK to communicate with IDT client = Client() # Create an execute on device request exec_req = ExecuteOnDeviceRequest(ExecuteOnDeviceCommand("echo 'hello world'")) # Run the command exec_resp = client.execute_on_device(exec_req) # Print the standard output print(exec_resp.stdout) # Create a send result request sr_req = SendResultRequest(TestResult(passed=True)) # Send the result client.send_result(sr_req) if __name__ == "__main__": main() ``` ## Configurar as informações do dispositivo para o IDT Configure as informações do seu dispositivo para o IDT executar o teste. É preciso atualizar o modelo `device.json` localizado na pasta `/configs` com as informações a seguir. ``` [ { "id": "pool", "sku": "N/A", "devices": [ { "id": "", "connectivity": { "protocol": "ssh", "ip": "", "port": "", "auth": { "method": "pki | password", "credentials": { "user": "", "privKeyPath": "/path/to/private/key", "password": "" } } } } ] } ] ``` No objeto `devices`, forneça as seguintes informações: `id` Um identificador exclusivo, definido pelo usuário, para o seu dispositivo. `connectivity.ip` O endereço IP do seu dispositivo. `connectivity.port` Opcional. O número da porta que deve ser usado nas conexões SSH ao seu dispositivo. `connectivity.auth` Informações de autenticação da conexão. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `ssh`. `connectivity.auth.method` O método de autenticação usado para acessar um dispositivo pelo protocolo de conectividade indicado. Os valores compatíveis são: + `pki` + `password` `connectivity.auth.credentials` As credenciais usadas para autenticação. `connectivity.auth.credentials.user` O nome de usuário usado para fazer login no seu dispositivo. `connectivity.auth.credentials.privKeyPath` O caminho completo para a chave privada usada para fazer login no dispositivo. Esse valor se aplica somente se `connectivity.auth.method` estiver definido como `pki`. `devices.connectivity.auth.credentials.password` A senha usada para fazer login no dispositivo. Esse valor se aplica somente se `connectivity.auth.method` estiver definido como `password`. **nota** Especifique `privKeyPath` somente se `method` estiver definido como `pki`. Especifique `password` somente se `method` estiver definido como `password`. ## Execute o pacote de teste Depois de criar o pacote de teste, verifique se ele funciona conforme o esperado. Conclua as etapas a seguir para executar o pacote de teste em seu grupo de dispositivos existente. 1. Copie sua pasta `MyTestSuite_1.0.0` em `/tests`. 1. Execute os seguintes comandos : ``` cd /bin ./devicetester_[linux | mac | win_x86-64] run-suite --suite-id MyTestSuite ``` O IDT executa seu pacote de teste e transmite os resultados para o console. Quando a execução do teste é concluída, são vistas as seguintes informações: ``` time="2020-10-19T09:24:47-07:00" level=info msg=Using pool: pool time="2020-10-19T09:24:47-07:00" level=info msg=Using test suite "MyTestSuite_1.0.0" for execution time="2020-10-19T09:24:47-07:00" level=info msg=b'hello world\n' suiteId=MyTestSuite groupId=myTestGroup testCaseId=myTestCase deviceId=my-device executionId=9a52f362-1227-11eb-86c9-8c8590419f30 time="2020-10-19T09:24:47-07:00" level=info msg=All tests finished. executionId=9a52f362-1227-11eb-86c9-8c8590419f30 time="2020-10-19T09:24:48-07:00" level=info msg= ========== Test Summary ========== Execution Time: 1s Tests Completed: 1 Tests Passed: 1 Tests Failed: 0 Tests Skipped: 0 ---------------------------------- Test Groups: myTestGroup: PASSED ---------------------------------- Path to IoT Device Tester Report: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/awsiotdevicetester_report.xml Path to Test Execution Logs: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/logs Path to Aggregated JUnit Report: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/MyTestSuite_Report.xml ``` ## Solução de problemas Use as informações a seguir para ajudar a resolver os problemas ao concluir o tutorial. **Caso de teste não é executado** Se o teste não for executado, o IDT transmitirá os logs de erro para o console e isso pode ajudar a solucionar o problema de execução do teste. Antes de verificar os logs de erro, verifique o seguinte: + O SDK de cliente do IDT está na pasta correta, conforme descrito [nesta etapa](#add-idt-sdk). + Você atende a todos os [pré-requisitos](#prereqs-tutorial-custom) deste tutorial. **Não é possível se conectar ao dispositivo em teste** Verifique o seguinte: + Seu arquivo `device.json` contém o endereço IP, a porta e as informações de autenticação corretos. + Você pode se conectar ao seu dispositivo via SSH a partir do seu computador host. # Crie arquivos de configuração do pacote de testes do IDT Esta seção descreve os formatos nos quais você cria arquivos de configuração JSON que são incluídos ao escrever um pacote personalizado de testes.Arquivos JSON necessários `suite.json` Contém informações sobre o conjunto de testes. Consulte [Configuração do suite.json](#suite-json). `group.json` Contém informações sobre um grupo de teste. É preciso criar um arquivo `group.json` para cada grupo de teste em seu pacote de teste. Consulte [Configurar group.json](#group-json). `test.json` Contém informações sobre um caso de teste. É preciso criar um arquivo `test.json` para cada caso de teste em seu pacote de teste. Consulte [Configurar test.json](#test-json).Arquivos JSON opcionais `state_machine.json` Define como os testes são executados quando o IDT executa o conjunto de testes. Consulte [Configuração de state\$1machine.json](#state-machine-json). `userdata_schema.json` Define o esquema do [arquivo `userdata.json`](set-config-custom.md#userdata-config-custom) que os executores de teste podem incluir em sua definição de configuração. O arquivo `userdata.json` é usado em qualquer informação de configuração adicional necessária para executar o teste, mas que não esteja presente no arquivo `device.json`. Consulte [Configuração de userdata\$1schema.json](#userdata-schema-json). Os arquivos de configuração JSON são colocados no seu ``, conforme mostrado aqui. ``` └── suite ├── suite.json ├── state_machine.json ├── userdata_schema.json ├── ├── group.json ├── └── test.json ``` ## Configuração do suite.json O arquivo `suite.json` define as variáveis de ambiente e determina se os dados do usuário são necessários para executar o pacote de teste. Use o modelo a seguir para configurar seu arquivo `/suite/suite.json`: ``` { "id": "_", "title": "", "details": "", "userDataRequired": true | false, "environmentVariables": [ { "key": "", "value": "", }, ... { "key": "", "value": "", } ] } ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `id` Um ID exclusivo, definido pelo usuário, para o pacote de teste. O valor de `id` deve corresponder ao nome da pasta do pacote de teste na qual o arquivo `suite.json` está localizado. O nome e a versão do pacote devem atender aos seguintes requisitos: + `` não pode conter sublinhados. + `` é indicado como `x.x.x`, em que `x` é um número. O ID é mostrado nos relatórios de teste gerados pelo IDT. `title` Um nome definido pelo usuário para o produto ou recurso que está sendo testado por esse pacote de teste. O nome é exibido na CLI do IDT para os executores de teste. `details` Uma descrição breve da finalidade do pacote de teste. `userDataRequired` Define se os executores de teste precisam incluir informações personalizadas em um arquivo `userdata.json`. Se definir esse valor como `true`, também deverá incluir o [arquivo `userdata_schema.json`](#userdata-schema-json) na pasta do pacote de teste. `environmentVariables` Opcional. Uma matriz de variáveis de ambiente para configurar para esse pacote de teste. `environmentVariables.key` O nome da variável de ambiente. `environmentVariables.value` O valor da variável de ambiente. ## Configurar group.json O arquivo `group.json` define se o grupo de teste é necessário ou opcional. Use o modelo a seguir para configurar seu arquivo `/suite//group.json`: ``` { "id": "", "title": "", "details": "", "optional": true | false, } ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `id` Uma ID exclusiva, definida pelo usuário, para o grupo de testes. O valor de `id` deve corresponder ao nome da pasta do grupo de testes, na qual o arquivo `group.json` está localizado, e não deve conter sublinhados (`_`). A ID é usada nos relatórios de teste gerados pelo IDT. `title` Um nome descritivo para o grupo de teste. O nome é exibido na CLI do IDT para os executores de teste. `details` Uma descrição breve da finalidade do grupo de teste. `optional` Opcional. Defina como `true` para exibir este grupo de teste como um grupo opcional depois que o IDT terminar de executar os testes necessários. O valor padrão é `false`. ## Configurar test.json O arquivo `test.json` determina os executáveis do caso de teste e as variáveis de ambiente que são usadas por um caso de teste. Para obter mais informações sobre como criar executáveis de casos de teste, consulte [Criar executáveis de casos de teste do IDT](test-executables.md). Use o modelo a seguir para configurar seu arquivo `/suite///test.json`: ``` { "id": "", "title": "", "details": "", "requireDUT": true | false, "requiredResources": [ { "name": "", "features": [ { "name": "", "version": "", "jobSlots": } ] } ], "execution": { "timeout": , "mac": { "cmd": "/path/to/executable", "args": [ "" ], }, "linux": { "cmd": "/path/to/executable", "args": [ "" ], }, "win": { "cmd": "/path/to/executable", "args": [ "" ] } }, "environmentVariables": [ { "key": "", "value": "", } ] } ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `id` Uma ID exclusiva definida pelo usuário para o caso de teste. O valor de `id` deve corresponder ao nome da pasta do caso de teste na qual o arquivo `test.json` está localizado e não deve conter sublinhados (`_`). A ID é usada nos relatórios de teste gerados pelo IDT. `title` Um nome descritivo para o caso de teste. O nome é exibido na CLI do IDT para os executores de teste. `details` Uma descrição breve da finalidade do caso de teste. `requireDUT` Opcional. Defina como `true` se um dispositivo for necessário para executar este teste. Caso contrário, defina como `false`. O valor padrão é `true`. Os executores de teste configurarão os dispositivos que usarão para executar o teste nos arquivos `device.json`. `requiredResources` Opcional. Uma matriz que fornece informações sobre os dispositivos de recursos necessários para executar esse teste. `requiredResources.name` O nome exclusivo a ser dado ao dispositivo de recurso quando este teste está sendo executado. `requiredResources.features` Uma matriz de recursos de dispositivos de recursos definidos pelo usuário. `requiredResources.features.name` O nome do recurso. O recurso do dispositivo para o qual você deseja usar este dispositivo. Este nome é comparado ao nome do recurso fornecido pelo executor de teste no arquivo `resource.json`. `requiredResources.features.version` Opcional. A versão do recurso. Este valor é comparado à versão do recurso fornecida pelo executor de teste no arquivo `resource.json`. Se uma versão não for fornecida, o recurso não será verificado. Se um número de versão não for obrigatório para o recurso, deixe este campo em branco. `requiredResources.features.jobSlots` Opcional. O número de testes simultâneos que podem ser compatíveis com este recurso. O valor padrão é `1`. Se você quiser que o IDT use dispositivos distintos para recursos individuais, recomendamos que você defina esse valor como `1`. `execution.timeout` A quantidade de tempo (em milissegundos) que o IDT aguardará a conclusão da execução do teste. Para obter mais informações sobre este valor, consulte [Criar executáveis de casos de teste do IDT](test-executables.md). `execution.os` Os executáveis do caso de teste a serem executados com base no sistema operacional do computador host que executa o IDT. Os valores compatíveis são `linux`, `mac` e `win`. `execution.os.cmd` O caminho para o executável do caso de teste que deseja executar para o sistema operacional especificado. Este local deve estar no caminho do sistema. `execution.os.args` Opcional. Os argumentos a serem fornecidos para executar o executável do caso de teste. `environmentVariables` Opcional. Uma matriz de variáveis de ambiente definidas para este caso de teste. `environmentVariables.key` O nome da variável de ambiente. `environmentVariables.value` O valor da variável de ambiente. Se você especificar a mesma variável de ambiente no arquivo `test.json` e no arquivo `suite.json`, o valor no arquivo `test.json` prevalecerá. ## Configuração de state\$1machine.json Uma máquina de estado é uma estrutura que controla o fluxo de execução do conjunto de testes. Ele determina o estado inicial de um pacote de teste, gerencia as transições de estado com base nas regras definidas pelo usuário e continua a transição por esses estados até atingir o estado final. Se seu pacote de teste não incluir uma máquina de estado definida pelo usuário, o IDT gerará uma máquina de estado para você. A máquina de estado padrão executa as seguintes funções: + Fornece aos executores de teste a capacidade de selecionar e executar grupos de testes específicos, em vez de todo o pacote de teste. + Se grupos de teste específicos não forem selecionados, executará cada grupo de teste no pacote de teste em uma ordem aleatória. + Gera relatórios e exibe um resumo do console que mostra os resultados do teste para cada grupo de teste e caso de teste. Para obter mais informações sobre como a máquina de estado do IDT funciona, consulte [Configure a máquina de estados do IDT](idt-state-machine.md). ## Configuração de userdata\$1schema.json O arquivo `userdata_schema.json` determina o esquema no qual os executores de teste fornecem dados do usuário. Os dados do usuário são necessários se seu pacote de teste exigir informações que não estejam presentes no arquivo `device.json`. Por exemplo, seus testes podem precisar de credenciais de rede Wi-Fi, portas abertas específicas ou certificados que um usuário deve fornecer. Estas informações podem ser fornecidas ao IDT como um parâmetro de entrada chamado `userdata`, cujo valor é um arquivo `userdata.json`, que os usuários criam em suas pastas `/config`. O formato do arquivo `userdata.json` é baseado no arquivo `userdata_schema.json` incluído no pacote de teste. Para indicar que os executores de teste devem fornecer um arquivo `userdata.json`: 1. No arquivo `suite.json`, defina `userDataRequired` como `true`. 1. No seu ``, crie um arquivo `userdata_schema.json`. 1. Edite o arquivo `userdata_schema.json` para criar um [esquema JSON válido do IETF Draft v4](https://json-schema.org/specification-links.html#draft-4). Quando o IDT executa seu conjunto de testes, ele lê automaticamente o esquema e o usa para validar o arquivo `userdata.json` fornecido pelo executor do teste. Se for válido, o conteúdo do arquivo `userdata.json` estará disponível no [contexto do IDT](idt-context.md) e no [contexto da máquina de estados](idt-state-machine.md#state-machine-context). # Configure a máquina de estados do IDT Uma máquina de estado é uma estrutura que controla o fluxo de execução do pacote de teste. Ele determina o estado inicial de um pacote de teste, gerencia as transições de estado com base nas regras definidas pelo usuário e continua a transição por esses estados até atingir o estado final. Se seu pacote de teste não incluir uma máquina de estado definida pelo usuário, o IDT gerará uma máquina de estado para você. A máquina de estado padrão executa as seguintes funções: + Fornece aos executores de teste a capacidade de selecionar e executar grupos de testes específicos, em vez de todo o pacote de teste. + Se grupos de teste específicos não forem selecionados, executará cada grupo de teste no pacote de teste em uma ordem aleatória. + Gera relatórios e imprime um resumo do console que mostra os resultados do teste para cada grupo de teste e caso de teste. A máquina de estado de um pacote de teste da IDT deve atender aos seguintes critérios: + Cada estado corresponde a uma ação a ser executada pelo IDT, como executar um grupo de teste ou produzir um arquivo de relatório. + A transição para um estado executa a ação associada ao estado. + Cada estado define a regra de transição para o próximo estado. + O estado final deve ser `Succeed` ou `Fail`. ## Formato da máquina de estado É possível usar o modelo a seguir para configurar seu próprio arquivo `/suite/state_machine.json`: ``` { "Comment": "", "StartAt": "", "States": { "": { "Type": "", // Additional state configuration } // Required states "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `Comment` Uma descrição da máquina de estado. `StartAt` O nome do estado em que o IDT começa a executar o pacote de teste. O valor de `StartAt` deve ser definido como um dos estados listados no objeto `States`. `States` Um objeto que mapeia nomes de estados definidos pelo usuário para estados IDT válidos. Cada estado. *state-name*objeto contém a definição de um estado válido mapeado para o. *state-name* O objeto `States` deve incluir os estados `Succeed` e `Fail`. Para obter informações sobre estados válidos, consulte [Estados válidos e definições de estado](#valid-states). ## Estados válidos e definições de estado Esta seção descreve as definições de estado de todos os estados válidos que podem ser usados na máquina de estados IDT. Alguns dos estados a seguir são compatíveis com configurações no nível do caso de teste. No entanto, é recomendado configurar as regras de transição de estado no nível do grupo de teste em vez do nível do caso de teste, a menos que seja absolutamente necessário. **Topics** + [RunTask](#state-runtask) + [Escolha](#state-choice) + [Paralelo](#state-parallel) + [AddProductFeatures](#state-addproductfeatures) + [Relatório](#state-report) + [LogMessage](#state-logmessage) + [SelectGroup](#state-selectgroup) + [Falha](#state-fail) + [Êxito](#state-succeed) ### RunTask O estado `RunTask` executa casos de teste de um grupo de teste definido no pacote de teste. ``` { "Type": "RunTask", "Next": "", "TestGroup": "", "TestCases": [ "" ], "ResultVar": "" } ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `Next` O nome do estado para o qual fazer a transição após a execução das ações no estado atual. `TestGroup` Opcional. O ID do grupo de teste a ser executado. Se este valor não for especificado, o IDT executará o grupo de teste selecionado pelo executor de testes. `TestCases` Opcional. Uma matriz de casos IDs de teste do grupo especificado em`TestGroup`. Com base nos valores de `TestGroup` e `TestCases`, o IDT determina o comportamento da execução do teste da seguinte forma: + Quando tanto o `TestGroup` como os `TestCases` são especificados, o IDT executa os casos de teste especificados do grupo de teste. + Quando `TestCases` são especificados, mas `TestGroup` não são especificados, o IDT executa os casos de teste especificados. + Quando `TestGroup` é especificado, mas `TestCases` não são especificados, o IDT executa os casos no grupo de teste especificado. + Quando nem `TestGroup` nem `TestCases` são especificados, o IDT executa todos os casos de teste do grupo de teste que o executor de teste seleciona na CLI do IDT. Para habilitar a seleção de grupos para executores de teste, é preciso incluir ambos os estados `RunTask` e `Choice` em seu arquivo `statemachine.json`. Para ver um exemplo de como isso funciona, consulte [Exemplo de máquina de estado: executar grupos de teste selecionados pelo usuário](#allow-specific-groups). Para obter mais informações sobre como habilitar os comandos da CLI no IDT, consulte [Habilitar comandos da CLI no IDT](test-executables.md#idt-cli-coop). `ResultVar` O nome da variável de contexto a ser definida com os resultados da execução do teste. Não especifique este valor se você não especificou um valor para `TestGroup`. O IDT define o valor da variável que você define em `ResultVar` para `true` ou `false` com base no seguinte: + Se o nome da variável estiver no formato `text_text_passed`, o valor será definido como se todos os testes do primeiro grupo de teste foram aprovados ou ignorados. + Em todos os outros casos, o valor é definido como se todos os testes em todos os grupos de teste tivessem sido aprovados ou ignorados. Normalmente, você usará o `RunTask` estado para especificar um ID de grupo de teste sem especificar um caso de teste individual IDs, para que o IDT execute todos os casos de teste no grupo de teste especificado. Todos os casos de teste executados por esse estado são executados em paralelo, em uma ordem aleatória. No entanto, se todos os casos de teste exigirem a execução de um dispositivo e apenas um único dispositivo estiver disponível, os casos de teste serão executados em sequência. **Como tratar erros** Se algum dos grupos de teste ou caso de teste IDs especificados não for válido, esse estado emitirá o erro de `RunTaskError` execução. Se o estado encontrar um erro de execução, ele também definirá a variável `hasExecutionError` no contexto da máquina de estado como `true`. ### Escolha O estado `Choice` permite definir dinamicamente o próximo estado para o qual fazer a transição com base em condições definidas pelo usuário. ``` { "Type": "Choice", "Default": "", "FallthroughOnError": true | false, "Choices": [ { "Expression": "", "Next": "" } ] } ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `Default` O estado padrão para o qual fazer a transição se nenhuma das expressões definidas em `Choices` puder ser avaliada como `true`. `FallthroughOnError` Opcional. Especifica o comportamento quando o estado se depara com um erro na avaliação de expressões. Defina como `true` se deseja ignorar uma expressão, caso a avaliação resulte em um erro. Se não houver correspondência de expressão, a máquina de estado fará a transição para o estado `Default`. Se o valor `FallthroughOnError` não for especificado, o valor padrão será `false`. `Choices` Uma matriz de expressões e estados para determinar para qual estado fazer a transição depois de executar as ações no estado atual. `Choices.Expression` Uma string de expressão que deve ser avaliada para um valor booleano. Se a expressão for avaliada como `true`, a máquina de estado fará a transição para o estado definido em `Choices.Next`. As strings de expressão recuperam valores do contexto da máquina de estado e, em seguida, executam operações neles para chegar a um valor booleano. Para obter informações sobre como acessar o contexto da máquina de estado, consulte [Contexto da máquina de estado](#state-machine-context). `Choices.Next` O nome do estado para o qual fazer a transição caso a expressão definida em `Choices.Expression` seja avaliada como `true`. **Como tratar erros** O estado `Choice` pode exigir o tratamento de erros nos seguintes casos: + Algumas variáveis nas expressões de escolha não existem no contexto da máquina de estado. + O resultado de uma expressão não é um valor booleano. + O resultado de uma pesquisa JSON não é uma string, número ou booleano. Não é possível usar um bloco `Catch` para tratar erros nesse estado. Se quiser parar de executar a máquina de estado quando ela encontrar um erro, defina `FallthroughOnError` como `false`. No entanto, é recomendado configurar `FallthroughOnError` e `true`, e dependendo do seu caso de uso, executar uma das seguintes etapas: + Se uma variável que você está acessando não existir em alguns casos, use o valor de `Default` e blocos `Choices` adicionais para especificar o próximo estado. + Se uma variável que estiver acessando sempre existir, defina o estado `Default` como `Fail`. ### Paralelo O estado `Parallel` permite que você defina e execute novas máquinas de estado em paralelo. ``` { "Type": "Parallel", "Next": "", "Branches": [ ] } ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `Next` O nome do estado para o qual fazer a transição após a execução das ações no estado atual. `Branches` Uma matriz de definições de máquina de estado a serem executadas. Cada definição de máquina de estado deve conter os próprios estados `StartAt`, `Succeed` e `Fail`. As definições de máquina de estado nesta matriz não podem fazer referência a estados de fora da definição deles. Como cada máquina de estado de ramificação compartilha o mesmo contexto de máquina de estado, definir variáveis em uma ramificação e depois lê-las de outra ramificação pode resultar em um comportamento inesperado. O estado `Parallel` passa para o próximo estado somente depois de executar todas as máquinas de estado da ramificação. Todo estado que necessita um dispositivo aguardará para ser executado até que o dispositivo esteja disponível. Se vários dispositivos estiverem disponíveis, este estado executará casos de teste a partir de vários grupos em paralelo. Se não houver dispositivos suficientes disponíveis, os casos de teste serão executados em sequência. Como os casos de teste são executados em uma ordem aleatória quando executados em paralelo, podem ser usados dispositivos diferentes para executar testes a partir do mesmo grupo de teste. **Como tratar erros** Certifique-se que tanto a máquina de estado da ramificação quanto a máquina de estado pai fazem a transição para o estado `Fail` para tratar erros de execução. Como as máquinas de estado de ramificação não transmitem erros de execução para a máquina de estado principal, você não pode usar um bloco `Catch` para lidar com erros de execução em máquinas de estado de ramificação. Em vez disso, use o valor `hasExecutionErrors` no contexto da máquina de estado compartilhada. Para obter um exemplo de como isso funciona, consulte [Exemplo de máquina de estado: execute dois grupos de testes em paralelo](#run-in-parallel). ### AddProductFeatures O estado `AddProductFeatures` permite adicionar recursos do produto ao arquivo `awsiotdevicetester_report.xml` gerado pelo IDT. Um recurso do produto é uma informação definida pelo usuário sobre critérios específicos que um dispositivo pode atender. Por exemplo, o recurso do produto `MQTT` pode indicar que o dispositivo publica mensagens MQTT corretamente. No relatório, os recursos do produto são definidas como `supported`, `not-supported` ou um valor personalizado, com base na aprovação dos testes especificados. **nota** O estado `AddProductFeatures` não gera relatórios por conta própria. Esse estado deve passar para o [estado `Report`](#state-report) para gerar relatórios. ``` { "Type": "Parallel", "Next": "", "Features": [ { "Feature": "", "Groups": [ "" ], "OneOfGroups": [ "" ], "TestCases": [ "" ], "IsRequired": true | false, "ExecutionMethods": [ "" ] } ] } ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `Next` O nome do estado para o qual fazer a transição após a execução das ações no estado atual. `Features` Uma matriz de recursos do produto para mostrar no arquivo `awsiotdevicetester_report.xml`. `Feature` O nome do recurso `FeatureValue` Opcional. O valor personalizado a ser usado no relatório em vez de `supported`. Se esse valor não for especificado, com base nos resultados do teste, o valor do recurso será definido como `supported` ou `not-supported`. Se você usar um valor personalizado para `FeatureValue`, poderá testar o mesmo recurso com condições diferentes e o IDT concatenará os valores do recurso para as condições compatíveis. Por exemplo, o trecho a seguir mostra o recurso `MyFeature` com dois valores de recurso separados: ``` ... { "Feature": "MyFeature", "FeatureValue": "first-feature-supported", "Groups": ["first-feature-group"] }, { "Feature": "MyFeature", "FeatureValue": "second-feature-supported", "Groups": ["second-feature-group"] }, ... ``` Se os dois grupos de teste forem aprovados, o valor do recurso será definido como `first-feature-supported, second-feature-supported`. `Groups` Opcional. Uma matriz de grupos de teste IDs. Todos os testes dentro de cada grupo de teste especificado devem ser aprovados para que o recurso seja compatível. `OneOfGroups` Opcional. Uma matriz de grupos de teste IDs. Todos os testes dentro de pelo menos um dos grupos de teste especificados devem ser aprovados para que o recurso seja compatível. `TestCases` Opcional. Uma variedade de casos de teste IDs. Se especificar este valor, o seguinte se aplica: + Todos os casos de teste especificados devem ser aprovados para que o recurso seja compatível. + `Groups` deve conter somente um ID de grupo de teste. + `OneOfGroups` não deve ser especificado. `IsRequired` Opcional. Defina como `false` para marcar este recurso como um recurso opcional no relatório. O valor padrão é `true`. `ExecutionMethods` Opcional. Uma matriz de métodos de execução que correspondem ao valor `protocol` especificado no arquivo `device.json`. Se esse valor for especificado, os executores de teste deverão especificar um valor `protocol` que corresponda a um dos valores dessa matriz para incluir o recurso no relatório. Se esse valor não for especificado, o recurso sempre será incluído no relatório. Para usar o estado `AddProductFeatures`, você deve definir o valor de `ResultVar` no estado `RunTask` como um dos seguintes valores: + Se você especificou um caso de teste individual IDs, `ResultVar` defina como`group-id_test-id_passed`. + Se você não especificou um caso de teste individual IDs, `ResultVar` defina como`group-id_passed`. O estado `AddProductFeatures` verifica os resultados dos testes da seguinte maneira: + Se você não especificou nenhum caso de teste IDs, o resultado de cada grupo de teste será determinado a partir do valor da `group-id_passed` variável no contexto da máquina de estado. + Se você especificou o caso de teste IDs, o resultado de cada um dos testes será determinado a partir do valor da `group-id_test-id_passed` variável no contexto da máquina de estado. **Como tratar erros** Se um ID de grupo fornecido neste estado não for um ID de grupo válido, este estado resultará no erro de execução `AddProductFeaturesError`. Se o estado encontrar um erro de execução, ele também definirá a variável `hasExecutionErrors` no contexto da máquina de estado como `true`. ### Relatório O estado `Report` gera os arquivos `suite-name_Report.xml` e `awsiotdevicetester_report.xml`. Este estado também transmite o relatório para o console. ``` { "Type": "Report", "Next": "" } ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `Next` O nome do estado para o qual fazer a transição após a execução das ações no estado atual. É sempre necessário fazer a transição para o estado `Report` perto do final do fluxo de execução do teste para que os executores de teste possam visualizar os resultados do teste. Normalmente, o próximo estado após este estado é `Succeed`. **Como tratar erros** Se este estado se deparar com problemas ao gerar relatórios, ele emitirá o erro de execução `ReportError`. ### LogMessage O estado `LogMessage` gera o arquivo `test_manager.log` e transmite a mensagem de log para o console. ``` { "Type": "LogMessage", "Next": "" "Level": "info | warn | error" "Message": "" } ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `Next` O nome do estado para o qual fazer a transição após a execução das ações no estado atual. `Level` O nível de erro no qual criar a mensagem de log. Se especificar um nível que não seja válido, este estado irá gerar uma mensagem de erro e a descartará. `Message` A mensagem a ser registrada. ### SelectGroup O estado `SelectGroup` atualiza o contexto da máquina de estado para indicar quais grupos estão selecionados. Os valores definidos por esse estado são usados por qualquer estado `Choice` seguinte. ``` { "Type": "SelectGroup", "Next": "" "TestGroups": [ " ] } ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `Next` O nome do estado para o qual fazer a transição após a execução das ações no estado atual. `TestGroups` Uma matriz de grupos de teste que serão marcados como selecionados. Para cada ID de grupo de teste nesta matriz, a variável `group-id_selected` é definida como `true` no contexto. Certifique-se de fornecer um grupo de teste válido IDs porque o IDT não valida se os grupos especificados existem. ### Falha O estado `Fail` indica que a máquina de estado não foi executada corretamente. Este é um estado final para a máquina de estados e cada definição de máquina de estado deve incluir este estado. ``` { "Type": "Fail" } ``` ### Êxito O estado `Succeed` indica que a máquina de estado foi executada corretamente. Este é um estado final para a máquina de estados e cada definição de máquina de estado deve incluir este estado. ``` { "Type": "Succeed" } ``` ## Contexto da máquina de estado O contexto da máquina de estado é um documento JSON somente para leitura que contém dados que estão disponíveis para a máquina de estado durante a execução. O contexto da máquina de estado é acessível somente da máquina de estado e contém informações que determinam o fluxo de teste. Por exemplo, você pode usar as informações configuradas pelos executores de teste no arquivo `userdata.json` para determinar se é necessário executar um teste específico. O contexto da máquina de estado usa o seguinte formato: ``` { "pool": { }, "userData": { }, "config": { }, "suiteFailed": true | false, "specificTestGroups": [ "" ], "specificTestCases": [ "" ], "hasExecutionErrors": true } ``` `pool` Informações sobre o grupo de dispositivos selecionado para a execução do teste. Para um grupo de dispositivos selecionado, essas informações são recuperadas do elemento correspondente da matriz do grupo de dispositivos de nível superior definido no arquivo `device.json`. `userData` As informações no arquivo `userdata.json`. `config` As informações fixadas no arquivo `config.json`. `suiteFailed` O valor é definido como `false` quando a máquina de estado for iniciada. Se um grupo de teste falhar em um estado `RunTask`, este valor será definido como `true` para a duração restante da execução da máquina de estado. `specificTestGroups` Se o executor de teste selecionar grupos de teste específicos para execução em vez de toda a suíte de testes, essa chave será criada e conterá a lista de grupos de testes específicos. IDs `specificTestCases` Se o executor de teste selecionar casos de teste específicos para execução em vez de todo o conjunto de testes, essa chave será criada e conterá a lista de casos de teste específicos. IDs `hasExecutionErrors` Não saia quando a máquina de estado é iniciada. Se algum estado encontrar um erro de execução, esta variável será criada e definida como `true` para a duração restante da execução da máquina de estado. Você pode consultar o contexto usando a JSONPath notação. A sintaxe para JSONPath consultas em definições de estado é. `{{$.query}}` Você pode usar JSONPath consultas como cadeias de caracteres de espaço reservado em alguns estados. O IDT substitui as cadeias de caracteres de espaço reservado pelo valor da JSONPath consulta avaliada do contexto. É possível usar espaços reservados para os seguintes valores: + O valor `TestCases` nos estados `RunTask`. + O valor de `Expression` no estado `Choice`. Ao acessar dados do contexto da máquina de estado, verifique se as seguintes condições são atendidas: + Seus caminhos JSON devem começar com `$.` + Cada valor deve ser avaliado como uma string, um número ou um booleano. Para obter mais informações sobre o uso JSONPath da notação para acessar dados do contexto, consulte[Use o contexto do IDT](idt-context.md). ## Erros de execução Os erros de execução são erros na definição da máquina de estado que a máquina de estado encontra ao executar um estado. O IDT registra informações sobre cada erro no arquivo `test_manager.log` e transmite a mensagem de log para o console. É possível usar os seguintes métodos para lidar com erros de execução: + Adicione um [bloco `Catch`](#catch) na definição do estado. + Verifique o valor do [valor `hasExecutionErrors`](#context) no contexto da máquina de estado. ### Catch Para usar `Catch`, adicione o seguinte à sua definição de estado: ``` "Catch": [ { "ErrorEquals": [ "" ] "Next": "" } ] ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `Catch.ErrorEquals` Uma matriz dos tipos de erro a serem capturados. Se um erro de execução corresponder a um dos valores especificados, a máquina de estado fará a transição para o estado especificado em `Catch.Next`. Consulte cada definição de estado para obter informações sobre o tipo de erro que ela produz. `Catch.Next` O próximo estado para o qual fazer a transição se o estado atual encontrar um erro de execução que corresponder a um dos valores especificados em `Catch.ErrorEquals`. Os blocos de captura são manuseados de maneira sequencial até que um deles corresponda. Se os erros não corresponderem aos listados nos blocos Catch, as máquinas de estado continuarão a ser executadas. Como os erros de execução são resultado de definições de estado incorretas, recomendamos que você faça a transição para o estado Falha quando um estado encontrar um erro de execução. ### hasExecutionError Quando alguns estados encontram erros de execução, além de emitirem o erro, eles também definem o valor `hasExecutionError` como `true` no contexto da máquina de estado. É possível usar este valor para detectar quando ocorre um erro e, em seguida, usar um estado `Choice` para fazer a transição da máquina de estado para o estado `Fail`. Este método tem as características a seguir. + A máquina de estado não inicia com nenhum valor atribuído para `hasExecutionError` e este valor não está disponível até que um determinado estado a defina. Isto significa que é preciso definir explicitamente o `FallthroughOnError` como `false` para os estados `Choice` que acessam este valor para evitar que a máquina de estado pare se nenhum erro de execução ocorrer. + Depois de definido como `true`, `hasExecutionError` nunca é definido como falso ou removido do contexto. Isto significa que esse valor é útil somente na primeira vez em que é definido como `true` e, para todos os estados subsequentes, não fornece um valor significativo. + O valor `hasExecutionError` é compartilhado com todas as máquinas de estado da filial no estado`Parallel`, o que pode resultar em resultados inesperados, dependendo da ordem em que é acessado. Por conta dessas características, não é recomendado usar este método, e sim, usar um bloco Catch. ## Exemplo de máquinas de estado Esta seção fornece alguns exemplos de configurações de máquina de estado. **Topics** + [Exemplo de máquina de estado: execute um único grupo de teste](#single-test-group) + [Exemplo de máquina de estado: execute grupos de teste selecionados pelo usuário](#allow-specific-groups) + [Exemplo de máquina de estado: execute um único grupo de teste com recursos do produto](#run-with-product-features) + [Exemplo de máquina de estado: execute dois grupos de testes em paralelo](#run-in-parallel) ### Exemplo de máquina de estado: execute um único grupo de teste Esta máquina de estado: + Executa o grupo de teste com o ID `GroupA`, que deve estar presente no pacote em um arquivo `group.json`. + Verifica se há erros de execução e transições de `Fail` para ver se algum foi encontrado. + Gera um relatório e faz a transição para `Succeed` se não houver erros e, caso contrário, `Fail`. ``` { "Comment": "Runs a single group and then generates a report.", "StartAt": "RunGroupA", "States": { "RunGroupA": { "Type": "RunTask", "Next": "Report", "TestGroup": "GroupA", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "Report": { "Type": "Report", "Next": "Succeed", "Catch": [ { "ErrorEquals": [ "ReportError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` ### Exemplo de máquina de estado: execute grupos de teste selecionados pelo usuário Esta máquina de estado: + Verifica se o executor do teste selecionou grupos de teste específicos. A máquina de estado não verifica casos de teste específicos porque os executores de teste não podem selecionar casos de teste sem também selecionar um grupo de teste. + Se os grupos de teste forem selecionados: + Executa os casos de teste nos grupos de teste selecionados. Para fazer isso, a máquina de estado não especifica explicitamente nenhum grupo de teste ou caso de teste no estado `RunTask`. + Gera um relatório após executar todos os testes e sai. + Se os grupos de teste não forem selecionados: + Executa testes no grupo de teste `GroupA`. + Gera relatórios e sai. ``` { "Comment": "Runs specific groups if the test runner chose to do that, otherwise runs GroupA.", "StartAt": "SpecificGroupsCheck", "States": { "SpecificGroupsCheck": { "Type": "Choice", "Default": "RunGroupA", "FallthroughOnError": true, "Choices": [ { "Expression": "{{$.specificTestGroups[0]}} != ''", "Next": "RunSpecificGroups" } ] }, "RunSpecificGroups": { "Type": "RunTask", "Next": "Report", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "RunGroupA": { "Type": "RunTask", "Next": "Report", "TestGroup": "GroupA", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "Report": { "Type": "Report", "Next": "Succeed", "Catch": [ { "ErrorEquals": [ "ReportError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` ### Exemplo de máquina de estado: execute um único grupo de teste com recursos do produto Esta máquina de estado: + Executa o grupo de teste `GroupA`. + Verifica se há erros de execução e transições de `Fail` para ver se algum foi encontrado. + Adiciona o recurso `FeatureThatDependsOnGroupA` ao arquivo `awsiotdevicetester_report.xml`: + Se `GroupA` for aprovado, o recurso será definido como `supported`. + O recurso não está marcado como opcional no relatório. + Gera um relatório e faz a transição para `Succeed` se não houver erros e, caso contrário, `Fail` ``` { "Comment": "Runs GroupA and adds product features based on GroupA", "StartAt": "RunGroupA", "States": { "RunGroupA": { "Type": "RunTask", "Next": "AddProductFeatures", "TestGroup": "GroupA", "ResultVar": "GroupA_passed", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "AddProductFeatures": { "Type": "AddProductFeatures", "Next": "Report", "Features": [ { "Feature": "FeatureThatDependsOnGroupA", "Groups": [ "GroupA" ], "IsRequired": true } ] }, "Report": { "Type": "Report", "Next": "Succeed", "Catch": [ { "ErrorEquals": [ "ReportError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` ### Exemplo de máquina de estado: execute dois grupos de testes em paralelo Esta máquina de estado: + Executa os grupos de teste `GroupA` e `GroupB` em paralelo. As variáveis `ResultVar` armazenadas no contexto pelos estados `RunTask` nas máquinas de estado da ramificação estão disponíveis para o estado `AddProductFeatures`. + Verifica se há erros de execução e transições de `Fail` para ver se algum foi encontrado. Esta máquina de estado não usa um bloco `Catch` porque este método não detecta erros de execução em máquinas de estado de ramificação. + Adiciona recursos ao arquivo `awsiotdevicetester_report.xml` com base nos grupos que passam + Se `GroupA` for aprovado, o recurso será definido como `supported`. + O recurso não está marcado como opcional no relatório. + Gera um relatório e faz a transição para `Succeed` se não houver erros e, caso contrário, `Fail` Se dois dispositivos estiverem configurados no grupo de dispositivos, tanto o `GroupA` como o `GroupB` poderão ser executados ao mesmo tempo. No entanto, se um `GroupA` ou `GroupB` tiver vários testes, os dois dispositivos poderão ser alocados para esses testes. Se somente um dispositivo estiver configurado, os grupos de testes serão executados sequencialmente. ``` { "Comment": "Runs GroupA and GroupB in parallel", "StartAt": "RunGroupAAndB", "States": { "RunGroupAAndB": { "Type": "Parallel", "Next": "CheckForErrors", "Branches": [ { "Comment": "Run GroupA state machine", "StartAt": "RunGroupA", "States": { "RunGroupA": { "Type": "RunTask", "Next": "Succeed", "TestGroup": "GroupA", "ResultVar": "GroupA_passed", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } }, { "Comment": "Run GroupB state machine", "StartAt": "RunGroupB", "States": { "RunGroupA": { "Type": "RunTask", "Next": "Succeed", "TestGroup": "GroupB", "ResultVar": "GroupB_passed", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ] }, "CheckForErrors": { "Type": "Choice", "Default": "AddProductFeatures", "FallthroughOnError": true, "Choices": [ { "Expression": "{{$.hasExecutionErrors}} == true", "Next": "Fail" } ] }, "AddProductFeatures": { "Type": "AddProductFeatures", "Next": "Report", "Features": [ { "Feature": "FeatureThatDependsOnGroupA", "Groups": [ "GroupA" ], "IsRequired": true }, { "Feature": "FeatureThatDependsOnGroupB", "Groups": [ "GroupB" ], "IsRequired": true } ] }, "Report": { "Type": "Report", "Next": "Succeed", "Catch": [ { "ErrorEquals": [ "ReportError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` # Criar executáveis de casos de teste do IDT Você pode criar e colocar executáveis de casos de teste em uma pasta de conjuntos de testes das seguintes formas: + Para conjuntos de testes que usam argumentos ou variáveis de ambiente dos arquivos `test.json` para determinar quais testes executar, você pode criar um caso de teste executável único para todo o conjunto de testes ou um executável de teste para cada grupo de testes no conjunto de testes. + 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 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 no arquivo `test.json` e passa as variáveis de ambiente necessárias para o processo. ## Usar o IDT Client SDK O IDT Client SDKs permite simplificar 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 o seguinte: SDKs + SDK do cliente IDT para Python + SDK for Go SDK para Go Eles SDKs estão localizados na `/sdks` pasta. 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. **Topics** + [Interação do dispositivo](#api-device-interaction) + [Interação do IDT](#api-idt-interaction) + [Interação do host](#api-host-interaction) ### 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](idt-context.md). ### 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 obter mais informações, consulte [Use o contexto do IDT](idt-context.md). `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 obter mais informações, consulte [Use o contexto do IDT](idt-context.md). `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\$1TEST\$1TIMEOUT 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\$1TEST\$1TIMEOUT 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](#test-exec-exiting). `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](#test-exec-exiting). `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](idt-state-machine.md#allow-specific-groups) 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 conjuntos de teste personalizados](run-tests-custom.md). ## 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](idt-review-results-logs.md#idt-console-format). 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 `/results//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 `_` localizado na pasta `/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 `/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 `/results//`. 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](idt-review-results-logs.md) 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 JUnit XML, 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 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\$1TEST\$1TIMEOUT. Quando um executor de teste inicializa um teste, o IDT define o valor da variável de ambiente IDT\$1TEST\$1TIMEOUT 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\$1C. 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. 1. Limpar todos os recursos temporários, como artefatos de teste no dispositivo em teste. 1. Relate um resultado de teste ao IDT, como uma falha ou erro no teste. 1. Sair. # Use o contexto do IDT Quando o IDT executa um pacote de teste, o pacote de teste pode acessar um conjunto de dados que podem ser usados para determinar como cada teste é executado. Estes dados são chamados de contexto do IDT. Por exemplo, a configuração de dados do usuário fornecida pelos executores de teste em um arquivo `userdata.json` é disponibilizada para pacotes de teste no contexto do IDT. O contexto do IDT pode ser considerado um documento JSON somente para leitura. Os pacotes de teste podem recuperar e gravar dados no contexto usando tipos de dados JSON padrão, como objetos, matrizes, números e assim por diante. ## Esquema de contexto O contexto do IDT usa o formato a seguir: ``` { "config": { "timeoutMultiplier": timeout-multiplier }, "device": { }, "devicePool": { }, "resource": { "devices": [ { "name": "" } ] }, "testData": { "awsCredentials": { "awsAccessKeyId": "", "awsSecretAccessKey": "", "awsSessionToken": "" }, "logFilePath": "/path/to/log/file" }, "userData": { } } ``` `config` Informações do [arquivo `config.json`](gg-core.md#config-json). O campo `config` também contém o seguinte campo adicional: `config.timeoutMultiplier` O multiplicador de um valor de tempo limite usado pelo conjunto de testes. Este valor é especificado pelo executor de teste da CLI do IDT. O valor padrão é `1`. `device` Informações sobre o dispositivo selecionado para a execução do teste. Estas informações são equivalentes à matriz `devices` definida no [arquivo `device.json`](set-config-custom.md#device-config-custom) do dispositivo selecionado. `devicePool` Informações sobre o grupo de dispositivos selecionado para a execução do teste. Estas informações são equivalentes ao elemento de matriz do grupo de dispositivos de nível superior definido no arquivo `device.json` do grupo de dispositivos selecionado. `resource` As informações sobre dispositivos de recursos do arquivo `resource.json`. `resource.devices` Estas informações são equivalentes à matriz `devices` definida no arquivo `resource.json`. Cada elemento `devices` inclui o seguinte campo adicional: `resource.device.name` O nome do dispositivo de recurso. Este valor é definido como o valor `requiredResource.name` no arquivo `test.json`. `testData.awsCredentials` As AWS credenciais usadas pelo teste para se conectar à AWS nuvem. Estas informações são obtidas do arquivo `config.json`. `testData.logFilePath` O caminho para o arquivo de log no qual o caso de teste grava mensagens de log. O pacote de teste criará este arquivo se ele não existir. `userData` As informações fornecidas pelo executor de teste no [arquivo `userdata.json`](set-config-custom.md#userdata-config-custom). ## Acesse dados no contexto Você pode consultar o contexto usando a JSONPath notação dos seus arquivos JSON e do seu executável de texto com e. `GetContextValue` `GetContextString` APIs A sintaxe JSONPath das cadeias de caracteres para acessar o contexto do IDT varia da seguinte forma: + Em `suite.json` e `test.json`, é usado `{{query}}`. Ou seja, não use o elemento raiz `$.` para iniciar sua expressão. + Em `statemachine.json`, é usado `{{$.query}}`. + Nos comandos da API, é usado `query` ou `{{$.query}}`, dependendo do comando. Para obter mais informações, consulte a documentação em linha no SDKs. A tabela a seguir descreve os operadores em uma JSONPath expressão típica: | Operador | Descrição | | --- |--- | | \$1 | O elemento raiz. Como o valor de contexto de nível superior do IDT é um objeto, normalmente você usará \$1. para iniciar suas consultas. | | .childName | Acessa o elemento filho com o nome childName de um objeto. Se aplicado a uma matriz, produz uma nova matriz com esse operador aplicado a cada elemento. O nome do elemento diferencia maiúsculas e minúsculas. Por exemplo, a consulta para acessar o valor awsRegion no objeto config é \$1.config.awsRegion. | | [start:end] | Filtra elementos de uma matriz, recuperando itens que começam no índice start e vão até o índice end, ambos inclusive. | | [index1, index2, ... , indexN] | Filtra elementos de uma matriz, recuperando itens somente dos índices especificados. | | [?(expr)] | Filtra elementos de uma matriz usando a expressão expr. Esta expressão que deve ser avaliada para um valor booleano. | Para criar expressões de filtro, use os seguintes elementos: ``` | operator | ``` Nesta sintaxe: + `jsonpath`é um JSONPath que usa a sintaxe JSON padrão. + `value` é qualquer valor personalizado que usa a sintaxe JSON padrão. + `operator` é um dos seguintes operadores: + `<` (Menor que) + `<=` (Menor ou igual a) + `==` (Igual a) Se o valor JSONPath ou em sua expressão for um valor de matriz, booleano ou objeto, esse será o único operador binário compatível que você poderá usar. + `>=` (Maior ou igual a) + `>` (Maior que) + `=~` (Correspondência de expressão regular). Para usar esse operador em uma expressão de filtro, o valor JSONPath ou no lado esquerdo da expressão deve ser avaliado como uma string e o lado direito deve ser um valor padrão que siga a [RE2sintaxe](https://github.com/google/re2/wiki/Syntax). Você pode usar JSONPath consultas no formato \$1\$1*query*\$1\$1 como cadeias de caracteres de espaço reservado `environmentVariables` nos campos `args` e nos `test.json` arquivos e nos `environmentVariables` campos nos arquivos. `suite.json` O IDT realiza uma pesquisa de contexto e preenche os campos com o valor avaliado da consulta. Por exemplo, no arquivo `suite.json`, é possível usar strings de espaço reservado para especificar valores de variáveis de ambiente que mudam com cada caso de teste e o IDT preencherá as variáveis de ambiente com o valor correto para cada caso de teste. No entanto, ao usar strings de caracteres de espaço reservado em arquivos `test.json` e `suite.json`, as seguintes considerações se aplicam às suas consultas: + Cada ocorrência da chave `devicePool` em sua consulta deve estar em letras minúsculas. Ou seja, em vez disso, use `devicepool`. + Para as matrizes, somente matrizes de strings podem ser usadas. Além disso, as matrizes usam um formato `item1, item2,...,itemN` não padrão. Se a matriz contiver somente um elemento, ela será serializada como `item`, tornando-a indistinguível de um campo de strings. + Não é possível usar espaços reservados para recuperar objetos do contexto. Por conta dessas considerações, é recomendado, sempre que possível, usar a API para acessar o contexto em sua lógica de teste em vez de strings de espaço reservado em arquivos `test.json` e `suite.json`. No entanto, em alguns casos, pode ser mais conveniente usar JSONPath espaços reservados para recuperar cadeias de caracteres únicas para definir como variáveis de ambiente. # Definir configurações para executores de teste Para executar conjuntos de testes personalizados, os executores de teste devem definir suas configurações com base no pacote de testes que desejam executar. As configurações são especificadas com base nos modelos de arquivo de configuração JSON localizados na pasta `/configs/`. Se necessário, os executores de teste também devem configurar AWS as credenciais que a IDT usará para se conectar à nuvem. AWS Como escritor de teste, será necessário configurar esses arquivos para [depurar seu pacote de teste](run-tests-custom.md). É preciso fornecer instruções aos executores de teste para que eles possam definir as seguintes configurações conforme necessário para executar seus pacotes de testes. ## Configurar device.json O arquivo `device.json` contém informações sobre os dispositivos em que os testes são executados (por exemplo, endereço IP, informações de login, sistema operacional e arquitetura de CPU). Os executores de teste podem fornecer essas informações usando o seguinte arquivo `device.json` de modelo localizado na pasta `/configs/`. ``` [ { "id": "", "sku": "", "features": [ { "name": "", "value": "", "configs": [ { "name": "", "value": "" } ], } ], "devices": [ { "id": "", "connectivity": { "protocol": "ssh | uart | docker", // ssh "ip": "", "port": , "auth": { "method": "pki | password", "credentials": { "user": "", // pki "privKeyPath": "/path/to/private/key", // password "password": "", } }, // uart "serialPort": "", // docker "containerId": "", "containerUser": "", } } ] } ] ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `id` Um ID alfanumérico definido pelo usuário que identifica uma coleção de dispositivos chamada de *grupo de dispositivos*. Os dispositivos que pertencem a um grupo devem ter hardware idêntico. Quando um conjunto de testes é executado, os dispositivos do grupo são usados para paralelizar a workload. Vários dispositivos são usados para executar testes diferentes. `sku` Um valor alfanumérico que identifica exclusivamente o dispositivo em teste. A SKU é usada para rastrear os dispositivos qualificados. Se você quiser listar sua placa no Catálogo de AWS Partner dispositivos, o SKU especificado aqui deve corresponder ao SKU que você usa no processo de listagem. `features` Opcional. Uma matriz que contém recursos compatíveis com o dispositivo. Os recursos do dispositivo são valores definidos pelo usuário que você configura em seu pacote de teste. É preciso fornecer informações aos executores de teste sobre os nomes e valores dos recursos a serem incluídos no arquivo `device.json`. Por exemplo, se você quiser testar um dispositivo que funciona como um servidor MQTT para outros dispositivos, você pode configurar sua lógica de teste para validar níveis específicos suportados para um recurso chamado `MQTT_QOS`. Os executores de teste fornecem esse nome de recurso e definem o valor do recurso para os níveis de QOS compatíveis com o dispositivo deles. É possível recuperar as informações fornecidas do [contexto do IDT](idt-context.md) com a consulta `devicePool.features` ou do [contexto da máquina de estado](idt-state-machine.md#state-machine-context) com a consulta `pool.features`. `features.name` O nome do recurso. `features.value` Os valores dos recursos compatíveis. `features.configs` Definições de configuração, se necessárias, para o recurso. `features.config.name` O nome do ajuste de configurações. `features.config.value` Os valores de configuração compatíveis. `devices` Uma matriz de dispositivos no grupo a serem testados. Pelo menos um dispositivo é necessário. `devices.id` Um identificador exclusivo, definido pelo usuário, para o dispositivo que está sendo testado. `connectivity.protocol` O protocolo de comunicação usado para se comunicar com esse dispositivo. Cada dispositivo em um grupo deve usar o mesmo protocolo. No momento, os únicos valores compatíveis são `ssh` e `uart` para dispositivos físicos e `docker` para contêineres do Docker. `connectivity.ip` O endereço IP do dispositivo que está sendo testado. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `ssh`. `connectivity.port` Opcional. O número da porta usada nas conexões SSH. O valor padrão é 22. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `ssh`. `connectivity.auth` Informações de autenticação da conexão. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `ssh`. `connectivity.auth.method` O método de autenticação usado para acessar um dispositivo pelo protocolo de conectividade indicado. Os valores compatíveis são: + `pki` + `password` `connectivity.auth.credentials` As credenciais usadas para autenticação. `connectivity.auth.credentials.password` A senha usada para fazer login no dispositivo que está sendo testado. Esse valor se aplica somente se `connectivity.auth.method` estiver definido como `password`. `connectivity.auth.credentials.privKeyPath` O caminho completo para a chave privada usada para fazer login no dispositivo que está sendo testado. Esse valor se aplica somente se `connectivity.auth.method` estiver definido como `pki`. `connectivity.auth.credentials.user` O nome de usuário para fazer login no dispositivo que está sendo testado. `connectivity.serialPort` Opcional. A porta serial à qual o dispositivo está conectado. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `uart`. `connectivity.containerId` O ID do contêiner ou o nome do contêiner do Docker que está sendo testado. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `docker`. `connectivity.containerUser` Opcional. O nome de usuário para o usuário dentro do contêiner. O valor padrão é o usuário fornecido no Dockerfile. O valor padrão é 22. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `docker`. Para verificar se os executores de teste configuram a conexão incorreta do dispositivo para um teste, você pode recuperar o `pool.Devices[0].Connectivity.Protocol` do contexto da máquina de estado e compará-la com o valor esperado em um estado `Choice`. Se um protocolo incorreto for usado, imprima uma mensagem usando o estado `LogMessage` e faça a transição para o estado `Fail`. Como alternativa, é possível usar o código de tratamento de erros para relatar uma falha no teste para tipos de dispositivos incorretos. ## (Opcional) Configurar userdata.json O arquivo `userdata.json` contém qualquer informação adicional exigida por um pacote de teste, mas não está especificada no arquivo `device.json`. O formato deste arquivo depende do [arquivo `userdata_scheme.json`](idt-json-config.md#userdata-schema-json) definido no pacote de teste. Se for um redator de testes, certifique-se de fornecer essas informações aos usuários que executarão os pacotes de testes escritos. ## (Opcional) Configurar resource.json O arquivo `resource.json` contém informações sobre todos os dispositivos que serão usados como dispositivos de recursos. Os dispositivos de recursos são dispositivos necessários para testar determinados recursos de um dispositivo em teste. Por exemplo, para testar a capacidade Bluetooth de um dispositivo, é possível usar um dispositivo de recurso para testar se seu dispositivo consegue se conectar com êxito. Os dispositivos de recursos são opcionais e pode exigir quantos dispositivos de recursos precisar. Como redator de teste, é possível usar o [arquivo test.json](idt-json-config.md#test-json) para definir os recursos do dispositivo de recursos necessários para um teste. Em seguida, os executores de teste usam o arquivo `resource.json` para fornecer um pool de dispositivos de recursos com os recursos necessários. Certifique-se de fornecer essas informações aos usuários que executarão os pacotes de testes escritos. Os executores de teste podem fornecer essas informações usando o seguinte arquivo `resource.json` de modelo localizado na pasta `/configs/`. ``` [ { "id": "", "features": [ { "name": "", "version": "", "jobSlots": } ], "devices": [ { "id": "", "connectivity": { "protocol": "ssh | uart | docker", // ssh "ip": "", "port": , "auth": { "method": "pki | password", "credentials": { "user": "", // pki "privKeyPath": "/path/to/private/key", // password "password": "", } }, // uart "serialPort": "", // docker "containerId": "", "containerUser": "", } } ] } ] ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: `id` Um ID alfanumérico definido pelo usuário que identifica uma coleção de dispositivos chamada de *grupo de dispositivos*. Os dispositivos que pertencem a um grupo devem ter hardware idêntico. Quando um conjunto de testes é executado, os dispositivos do grupo são usados para paralelizar a workload. Vários dispositivos são usados para executar testes diferentes. `features` Opcional. Uma matriz que contém recursos compatíveis com o dispositivo. As informações necessárias neste campo são definidas nos [arquivos test.json](idt-json-config.md#test-json) no pacote de teste e determinam quais testes devem ser executados e como executá-los. Se o pacote de teste não exigir nenhum recurso, este campo não será obrigatório. `features.name` O nome do recurso. `features.version` A versão do recurso. `features.jobSlots` Configuração para indicar quantos testes podem usar o dispositivo simultaneamente. O valor padrão é `1`. `devices` Uma matriz de dispositivos no grupo a serem testados. Pelo menos um dispositivo é necessário. `devices.id` Um identificador exclusivo, definido pelo usuário, para o dispositivo que está sendo testado. `connectivity.protocol` O protocolo de comunicação usado para se comunicar com esse dispositivo. Cada dispositivo em um grupo deve usar o mesmo protocolo. No momento, os únicos valores compatíveis são `ssh` e `uart` para dispositivos físicos e `docker` para contêineres do Docker. `connectivity.ip` O endereço IP do dispositivo que está sendo testado. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `ssh`. `connectivity.port` Opcional. O número da porta usada nas conexões SSH. O valor padrão é 22. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `ssh`. `connectivity.auth` Informações de autenticação da conexão. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `ssh`. `connectivity.auth.method` O método de autenticação usado para acessar um dispositivo pelo protocolo de conectividade indicado. Os valores compatíveis são: + `pki` + `password` `connectivity.auth.credentials` As credenciais usadas para autenticação. `connectivity.auth.credentials.password` A senha usada para fazer login no dispositivo que está sendo testado. Esse valor se aplica somente se `connectivity.auth.method` estiver definido como `password`. `connectivity.auth.credentials.privKeyPath` O caminho completo para a chave privada usada para fazer login no dispositivo que está sendo testado. Esse valor se aplica somente se `connectivity.auth.method` estiver definido como `pki`. `connectivity.auth.credentials.user` O nome de usuário para fazer login no dispositivo que está sendo testado. `connectivity.serialPort` Opcional. A porta serial à qual o dispositivo está conectado. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `uart`. `connectivity.containerId` O ID do contêiner ou o nome do contêiner do Docker que está sendo testado. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `docker`. `connectivity.containerUser` Opcional. O nome de usuário para o usuário dentro do contêiner. O valor padrão é o usuário fornecido no Dockerfile. O valor padrão é 22. Essa propriedade será aplicada somente se `connectivity.protocol` estiver definido como `docker`. ## (Opcional) Configurar config.json O arquivo `config.json` contém as informações de configuração do IDT. Normalmente, os executores de teste não precisarão modificar esse arquivo, exceto para fornecer suas credenciais de AWS usuário para o IDT e, opcionalmente, para uma região. AWS Se AWS as credenciais com as permissões necessárias forem fornecidas, AWS IoT o Device Tester coleta e envia métricas de uso para o. AWS Esse atributo é opcional e usado para aprimorar a funcionalidade do IDT. Para obter mais informações, consulte [Métricas de uso do IDT](idt-usage-metrics.md). Os executores de teste podem configurar suas AWS credenciais de uma das seguintes formas: + **Arquivo de credenciais** O IDT usa o mesmo arquivo de credenciais que a AWS CLI. Para obter mais informações, consulte [Arquivos de configuração e credenciais](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html). O local do arquivo de credenciais varia de acordo com o sistema operacional que você está usando: + macOS, Linux: `~/.aws/credentials` + Windows: `C:\Users\UserName\.aws\credentials` + **Variáveis de ambiente** As variáveis de ambiente são variáveis mantidas pelo sistema operacional e usadas pelos comandos do sistema. As variáveis definidas durante uma sessão SSH não estão disponíveis após o encerramento da sessão. O IDT pode usar as variáveis de `AWS_SECRET_ACCESS_KEY` ambiente `AWS_ACCESS_KEY_ID` e para armazenar credenciais AWS Para definir essas variáveis no Linux, macOS ou Unix, use :**export** ``` export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY= ``` Para definir essas variáveis no Windows, use :**set** ``` set AWS_ACCESS_KEY_ID= set AWS_SECRET_ACCESS_KEY= ``` Para configurar AWS as credenciais para o IDT, os executores de teste editam a `auth` seção no `config.json` arquivo localizado na pasta. `/configs/` ``` { "log": { "location": "logs" }, "configFiles": { "root": "configs", "device": "configs/device.json" }, "testPath": "tests", "reportPath": "results", "awsRegion": "", "auth": { "method": "file | environment", "credentials": { "profile": "" } } } ] ``` Todos os campos que contêm valores são necessários, conforme descrito aqui: **nota** Todos os caminhos nesse arquivo são definidos em relação ao**. `log.location` O caminho para a pasta de registros no**. `configFiles.root` O caminho para a pasta que contém os arquivos de configuração. `configFiles.device` O caminho para a função `device.json`. `testPath` O caminho para a pasta que contém pacotes de teste. `reportPath` O caminho para a pasta que conterá os resultados do teste depois que o IDT executar um pacote de teste. `awsRegion` Opcional. A AWS região que as suítes de teste usarão. Se não for definida, os pacotes de teste usarão a região padrão especificada em cada pacote de teste. `auth.method` O método que o IDT usa para recuperar credenciais AWS . Os valores aceitos são `file` recuperar credenciais de um arquivo de credenciais e recuperar credenciais `environment` usando variáveis de ambiente. `auth.credentials.profile` O perfil de credenciais a ser usado no arquivo de credenciais. Essa propriedade será aplicada somente se `auth.method` estiver definido como `file`. # Depure e execute conjuntos de teste personalizados Depois que a [configuração necessária](set-config-custom.md) for definida, o IDT poderá executar seu pacote de teste. O runtime do pacote de teste completo depende do hardware e da composição do pacote de teste. Para referência, são necessários aproximadamente 30 minutos para concluir o conjunto completo de testes de AWS IoT Greengrass qualificação em um Raspberry Pi 3B. À medida que seu pacote de teste é escrito, é possível usar o IDT para executar o pacote de teste no modo de depuração para verificar seu código antes de executá-lo ou fornecê-lo aos executores de teste. ## Executar o IDT no modo de depuração Como os pacotes de teste dependem do IDT para interagir com dispositivos, fornecer o contexto e receber resultados, não é possível simplesmente depurar seus pacotes de teste em um IDE sem qualquer interação com o IDT. Para fazer isso, a CLI do IDT fornece o comando `debug-test-suite` que permite executar o IDT no modo de depuração. Execute o comando a seguir para visualizar as opções disponíveis para `debug-test-suite`: ``` devicetester_[linux | mac | win_x86-64] debug-test-suite -h ``` Ao executar o IDT no modo de depuração, o IDT na verdade não inicia o conjunto de testes nem executa a máquina de estado; em vez disso, ele interage com o IDE para responder às solicitações feitas do conjunto de testes em execução no IDE e exibe os logs no console. O IDT não atinge o tempo limite e espera para sair até ser interrompido manualmente. No modo de depuração, o IDT também não executa a máquina de estado e não gera arquivos de relatório. Para depurar o conjunto de testes, você deve usar seu IDE para fornecer algumas informações que o IDT normalmente obtém dos arquivos JSON de configuração. Forneça as seguintes informações: + Variáveis de ambiente e argumentos para cada teste. O IDT não lerá essas informações de `test.json` ou `suite.json`. + Argumentos para selecionar os dispositivos de recursos. O IDT não lerá essas informações de `test.json`. Para depurar seus pacotes de teste, conclua as seguintes etapas: 1. Crie os arquivos de ajuste de configuração necessários para executar o pacote de teste. Por exemplo, se seu pacote de teste exigir o `device.json`, `resource.json` e `user data.json` certifique-se de configurar todos eles conforme necessário. 1. Execute o comando a seguir para colocar o IDT no modo de depuração e selecionar todos os dispositivos necessários para executar o teste. ``` devicetester_[linux | mac | win_x86-64] debug-test-suite [options] ``` Depois de executar esse comando, o IDT aguarda as solicitações do pacote de teste e responde a elas. O IDT também gera as variáveis de ambiente necessárias para o processo de caso do SDK do cliente de IDT. 1. No seu IDE, use a configuração `run` ou `debug` para fazer o seguinte: 1. Defina os valores das variáveis de ambiente geradas pelo IDT. 1. Defina o valor de qualquer variável de ambiente ou argumento que você especificou em seu arquivo `test.json` e `suite.json`. 1. Definir pontos de interrupção, conforme necessário. 1. Execute o pacote de teste em seu IDE. É possível depurar e executar novamente o pacote de teste quantas vezes for necessário. O IDT não atinge o tempo limite no modo de depuração. 1. Depois de concluir a depuração, interrompa o IDT para sair do modo de depuração. ## Comandos da CLI do IDT para executar testes As seções a seguir descrevem os comandos da CLI do IDT. ------ #### [ IDT v4.0.0 ] `help` Lista as informações sobre o comando especificado. `list-groups` Lista os grupos em um determinado conjunto de teste. `list-suites` Lista os conjuntos de teste disponíveis. `list-supported-products` Lista os produtos compatíveis com sua versão do IDT, neste caso AWS IoT Greengrass as versões, e as versões do pacote de testes de AWS IoT Greengrass qualificação disponíveis para a versão atual do IDT. `list-test-cases` Lista os casos de teste em um grupo de teste. A seguinte opção é compatível: + `group-id`. O grupo de teste a ser pesquisado. Esta opção é necessária e deve especificar um único grupo. `run-suite` Executa um conjunto de testes em um grupo de dispositivos. Algumas opções comumente usadas a seguir: + `suite-id`. A versão do pacote de teste a ser executada. Se não for especificado, o IDT usará a versão mais recente na pasta `tests`. + `group-id`. Os grupos de teste a serem executados, como uma lista separada por vírgulas. Se não for especificado, o IDT executa todos os grupos de teste no conjunto de testes. + `test-id`. Os casos de teste a serem executados, como uma lista separada por vírgulas. Quando especificado, `group-id` deve especificar um único grupo. + `pool-id`. O grupo de dispositivos a ser testado. É preciso especificar um grupo se houver vários grupos de dispositivos definidos no arquivo `device.json`. + `timeout-multiplier`. Configura o IDT para modificar o tempo limite de execução do teste especificado no arquivo `test.json` para um teste com um multiplicador definido pelo usuário. + `stop-on-first-failure`. Configura o IDT de modo a interromper a execução na primeira falha. Essa opção deve ser usada com para depurar os grupos de teste especificados `group-id`. + `userdata`. Define o arquivo que contém as informações de dados do usuário necessárias para executar o pacote de teste. Isto é necessário somente se `userdataRequired` estiver definido como verdadeiro no arquivo `suite.json` do pacote de teste. Para obter mais informações sobre as opções `run-suite`, use a opção `help`: ``` devicetester_[linux | mac | win_x86-64] run-suite -h ``` `debug-test-suite` Execute o pacote de teste no modo de depuração. Para obter mais informações, consulte [Executar o IDT no modo de depuração](#idt-debug-mode). ------ # Analise os resultados e logs dos testes do IDT Esta seção descreve o formato no qual o IDT gera logs de console e relatórios de teste. ## Formato de mensagem do console AWS IoT O Device Tester usa um formato padrão para imprimir mensagens no console quando inicia uma suíte de testes. O trecho a seguir mostra um exemplo de uma mensagem de console gerada pelo IDT. ``` time="2000-01-02T03:04:05-07:00" level=info msg=Using suite: MyTestSuite_1.0.0 executionId=9a52f362-1227-11eb-86c9-8c8590419f30 ``` A maioria das mensagens detalhadas do console consiste nos seguintes campos: `time` Um carimbo de data/hora ISO 8601 completo para o evento registrado. `level` O nível da mensagem para o evento registrado. Normalmente, o nível da mensagem registrada é um `info`, `warn` ou `error`. O IDT emite uma mensagem `fatal` ou `panic` se encontrar um evento esperado que faça com que ele saia antecipadamente. `msg` A mensagem registrada. `executionId` Uma string de ID exclusiva para o processo atual do IDT. Este ID é usado para diferenciar entre execuções individuais de IDT. As mensagens do console geradas de um pacote de teste fornecem informações adicionais sobre o dispositivo em teste e o pacote de teste, o grupo de teste e os casos de teste que o IDT executa. O trecho a seguir mostra um exemplo de uma mensagem de console gerada de um pacote de teste. ``` time="2000-01-02T03:04:05-07:00" level=info msg=Hello world! suiteId=MyTestSuite groupId=myTestGroup testCaseId=myTestCase deviceId=my-device executionId=9a52f362-1227-11eb-86c9-8c8590419f30 ``` A parte específica do pacote de teste da mensagem do console contém os seguintes campos: `suiteId` O nome do pacote de teste em execução no momento. `groupId` O ID do grupo de teste em execução no momento. `testCaseId` O ID do caso de teste em execução no momento. `deviceId` Um ID do dispositivo em teste que está sendo usado pelo caso de teste atual no momento. Para exibir um resumo do teste no console quando um IDT terminar de executar um teste, você deve incluir um [estado `Report`](idt-state-machine.md#state-report) na máquina de estado. O resumo do teste contém informações sobre o conjunto de testes, os resultados de teste de cada grupo em execução e os locais dos arquivos de logs e relatórios gerados. O exemplo a seguir mostra uma mensagem de resume do teste. ``` ========== Test Summary ========== Execution Time: 5m00s Tests Completed: 4 Tests Passed: 3 Tests Failed: 1 Tests Skipped: 0 ---------------------------------- Test Groups: GroupA: PASSED GroupB: FAILED ---------------------------------- Failed Tests: Group Name: GroupB Test Name: TestB1 Reason: Something bad happened ---------------------------------- Path to IoT Device Tester Report: /path/to/awsiotdevicetester_report.xml Path to Test Execution Logs: /path/to/logs Path to Aggregated JUnit Report: /path/to/MyTestSuite_Report.xml ``` ## AWS IoT Esquema do relatório do Device Tester `awsiotdevicetester_report.xml` é um relatório assinado que contém as seguintes informações: + A versão IDT. + A versão do pacote de teste. + A assinatura do relatório e a chave usada para assinar o relatório. + A SKU do dispositivo e o nome de grupo do dispositivo especificados no arquivo `device.json`. + A versão do produto e os recursos do dispositivo que foram testados. + O resumo agregado dos resultados de teste. Estas informações são as mesmas contidas no arquivo `suite-name_report.xml`. ``` idt-version test-suite-version signature keyname execution-id start-time end-time product-name product-version device-sku device-name ssh | uart | docker ``` O arquivo `awsiotdevicetester_report.xml` contém uma tag `` com informações sobre o produto que está sendo testado e os recursos do produto que foram validados após a execução de um pacote de testes.recursos usados na tag `` `name` O nome do produto testado. `version` A versão do produto testado. `features` Os recursos validados. Os recursos marcados como `required` são necessários para que o pacote de teste valide o dispositivo. O trecho a seguir mostra como essas informações aparecem no arquivo `awsiotdevicetester_report.xml`. ``` ``` Os recursos marcados como não `optional` são necessários para validação. Os seguintes trechos mostram recursos opcionais. ``` 
 ``` ## Esquema do relatório do pacote de teste O `suite-name_Result.xml` relatório está no [formato JUnit XML](https://llg.cubic.org/docs/junit/). Você pode integrá-lo em plataformas de integração e implantação como [Jenkins](https://jenkins.io/), [Bamboo](https://www.atlassian.com/software/bamboo) e assim por diante. O relatório contém um resumo agregado dos resultados de teste. ``` reason reason reason ``` A seção de relatório tanto em `awsiotdevicetester_report.xml` como em `suite-name_report.xml` lista os testes que foram executados e os resultados. A primeira tag XML `` contém o resumo da execução do teste. Por exemplo: ``` ```recursos usados na tag `` `name` O nome do conjunto de testes. `time` O tempo, em segundos, necessário para executar o pacote de teste. `tests` O número de testes executados. `failures` O número de testes que foram executados, mas não foram aprovados. `errors` O número de testes que não puderam ser executados pelo IDT. `disabled` Esse recurso não é usado e pode ser ignorado. Se houver falhas de teste ou erros, você poderá identificar o teste com falha analisando as tags XML ``. As tags XML `` dentro da tag `` mostram o resumo do resultado do teste para um grupo de testes. Por exemplo: ``` ``` O formato é semelhante à tag ``, mas com um recurso `skipped` que não é usado e pode ser ignorado. Dentro de cada tag XML ``, há tags `` para cada teste executado para um grupo de testes. Por exemplo: ``` > ```recursos usados na tag `` `name` O nome do teste. `attempts` O número de vezes que o IDT executou o caso de teste. Quando um teste falha ou ocorre um erro, as tags `` ou `` são adicionadas à tag `` com informações para a solução de problemas. Por exemplo: ``` Reason for the test failure Reason for the test execution error ``` # Métricas de uso do IDT Se você fornecer AWS credenciais com as permissões necessárias, o AWS IoT Device Tester coleta e envia métricas de uso para. AWS Este é um recurso opcional e é usado para melhorar a funcionalidade do IDT. O IDT coleta informações como as seguintes: + O Conta da AWS ID usado para executar o IDT + Os comandos da CLI do IDT usados para executar testes + O pacote de teste que é executado + As suítes de teste na ** pasta + O número de dispositivos configurados no grupo de dispositivos + Nomes de casos de teste e tempos de execução + Informações do resultado do teste, como se os testes foram aprovados, falharam, encontraram erros ou foram ignorados + recursos testados do produto + Comportamento de saída do IDT, como saídas inesperadas ou antecipadas Todas as informações enviadas pelo IDT também são registradas em um arquivo `metrics.log` na pasta `/results//`. Você pode visualizar o arquivo de log para ver as informações que foram coletadas durante a execução de um teste. Este arquivo é gerado somente se optar por coletar métricas de uso. Para desativar a coleta de métricas, não é necessário tomar nenhuma outra medida. Simplesmente não armazene suas AWS credenciais e, se você tiver AWS credenciais armazenadas, não configure o arquivo `config.jso` n para acessá-las. ## Configure suas AWS credenciais Se você ainda não tiver um Conta da AWS, deverá [criar um](#idt-metrics-aws-account). Se você já tem uma Conta da AWS, basta [configurar as permissões necessárias](#idt-metrics-permissions) para sua conta, permitindo que a IDT envie métricas de uso AWS em seu nome. ### Etapa 1: criar um Conta da AWS Nesta etapa, crie e configure uma Conta da AWS. Se você já tem um Conta da AWS, vá para[Etapa 2: Configurar permissões para o IDT](#idt-metrics-permissions). #### Inscreva-se para um Conta da AWS Se você não tiver um Conta da AWS, conclua as etapas a seguir para criar um. **Para se inscrever em um Conta da AWS** 1. Abra a [https://portal.aws.amazon.com/billing/inscrição.](https://portal.aws.amazon.com/billing/signup) 1. Siga as instruções online. Parte do procedimento de inscrição envolve receber uma chamada telefônica ou uma mensagem de texto e inserir um código de verificação pelo teclado do telefone. Quando você se inscreve em um Conta da AWS, um *Usuário raiz da conta da AWS*é criado. O usuário-raiz tem acesso a todos os Serviços da AWS e recursos na conta. Como prática recomendada de segurança, atribua o acesso administrativo a um usuário e use somente o usuário-raiz para executar [tarefas que exigem acesso de usuário-raiz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks). AWS envia um e-mail de confirmação após a conclusão do processo de inscrição. A qualquer momento, você pode visualizar a atividade atual da sua conta e gerenciar sua conta acessando [https://aws.amazon.com/e](https://aws.amazon.com/) escolhendo **Minha conta**. #### Criar um usuário com acesso administrativo Depois de se inscrever em um Conta da AWS, proteja seu Usuário raiz da conta da AWS Centro de Identidade do AWS IAM, habilite e crie um usuário administrativo para que você não use o usuário root nas tarefas diárias. **Proteja seu Usuário raiz da conta da AWS** 1. Faça login [Console de gerenciamento da AWS](https://console.aws.amazon.com/)como proprietário da conta escolhendo **Usuário raiz** e inserindo seu endereço de Conta da AWS e-mail. Na próxima página, insira a senha. Para obter ajuda ao fazer login usando o usuário-raiz, consulte [Fazer login como usuário-raiz](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) no *Guia do usuário do Início de Sessão da AWS *. 1. Habilite a autenticação multifator (MFA) para o usuário-raiz. Para obter instruções, consulte [Habilitar um dispositivo de MFA virtual para seu usuário Conta da AWS raiz (console) no Guia](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) do *usuário do IAM*. **Criar um usuário com acesso administrativo** 1. Habilita o Centro de Identidade do IAM. Para obter instruções, consulte [Habilitar o Centro de Identidade do AWS IAM](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) no *Guia do usuário do Centro de Identidade do AWS IAM *. 1. No Centro de Identidade do IAM, conceda o acesso administrativo a um usuário. Para ver um tutorial sobre como usar o Diretório do Centro de Identidade do IAM como fonte de identidade, consulte [Configurar o acesso do usuário com o padrão Diretório do Centro de Identidade do IAM](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) no *Guia Centro de Identidade do AWS IAM do usuário*. **Iniciar sessão como o usuário com acesso administrativo** + Para fazer login com o seu usuário do Centro de Identidade do IAM, use o URL de login enviado ao seu endereço de e-mail quando o usuário do Centro de Identidade do IAM foi criado. Para obter ajuda para fazer login usando um usuário do IAM Identity Center, consulte Como [fazer login no portal de AWS acesso](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) no *Guia Início de Sessão da AWS do usuário*. **Atribuir acesso a usuários adicionais** 1. No Centro de Identidade do IAM, crie um conjunto de permissões que siga as práticas recomendadas de aplicação de permissões com privilégio mínimo. Para obter instruções, consulte [Criar um conjunto de permissões](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) no *Guia do usuário do Centro de Identidade do AWS IAM *. 1. Atribua usuários a um grupo e, em seguida, atribua o acesso de logon único ao grupo. Para obter instruções, consulte [Adicionar grupos](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) no *Guia do usuário do Centro de Identidade do AWS IAM *. ### Etapa 2: Configurar permissões para o IDT Nesta etapa, configure as permissões que o IDT para executar testes e coletar dados de uso do IDT. Você pode usar o Console de gerenciamento da AWS or AWS Command Line Interface (AWS CLI) para criar uma política do IAM e um usuário para o IDT e, em seguida, anexar políticas ao usuário. + [Para configurar permissões para IDT (Console)](#idt-metrics-permissions-console) + [Para configurar permissões para o IDT (AWS CLI)](#idt-metrics-permissions-cli) **Como configurar permissões para o IDT (console)** Siga estas etapas para usar o console para configurar permissões para IDT para AWS IoT Greengrass. 1. [Faça login no console do IAM](https://console.aws.amazon.com/iam). 1. Crie uma política gerenciada pelo cliente que conceda permissões para criar funções com permissões específicas. 1. No painel de navegação, selecione **Políticas** e, em seguida, **Criar política**. 1. Na guia **JSON**, substitua o conteúdo do espaço reservado pela política a seguir. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot-device-tester:SendMetrics" ], "Resource": "*" } ] } ``` ------ 1. Selecione **Next: Tags** (Próximo: tags). 1. Selecione **Next: Review** (Próximo: revisar). 1. Em **Name (Nome)**, insira **IDTUsageMetricsIAMPermissions**. Em **Summary (Resumo)**, revise as permissões concedidas pela política. 1. Escolha **Create policy (Criar política)**. 1. Crie um usuário do IAM e anexe permissões ao usuário. 1. Criar um usuário do IAM. Siga as etapas de 1 a 5 em [Criando usuários do IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) no *Guia do usuário do IAM*. Se você já tiver criado um usuário do IAM, vá para a próxima etapa. 1. Anexe as permissões ao usuário do IAM: 1. Na página **Definir permissões**, selecione **Anexar políticas existentes diretamente**. 1. Pesquise a IAMPermissions política de **IDTUsagemétricas** que você criou na etapa anterior. Marque a caixa de seleção. 1. Selecione **Next: Tags (Próximo: tags)**. 1. Selecione **Next: Review (Próximo: revisar)** para exibir um resumo das suas escolhas. 1. Selecione **Criar usuário**. 1. Para visualizar as chaves de acesso do usuário (chave de acesso IDs e chaves de acesso secretas), escolha **Mostrar** ao lado da senha e da chave de acesso. Para salvar as chaves de acesso, selecione **Download.csv (Fazer download do .csv)** e salve o arquivo em um local seguro. Você usa essas informações posteriormente para configurar seu arquivo de AWS credenciais.   **Como configurar permissões para o IDT (AWS CLI)** Siga estas etapas para usar o AWS CLI para configurar as permissões do IDT para AWS IoT Greengrass. Se você já configurou permissões no console, vá para [Configure seu dispositivo para executar testes de IDT](device-config-setup.md) ou [Opcional: Configurando seu contêiner Docker para IDT para AWS IoT Greengrass](docker-config-setup.md). 1. No seu computador, instale e configure o, AWS CLI se ainda não estiver instalado. Siga as etapas em [Installing the (Instalando a) AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) no *Guia do usuário do AWS Command Line Interface *. **nota** AWS CLI É uma ferramenta de código aberto que você pode usar para interagir com AWS serviços do seu shell de linha de comando. 1. Crie a seguinte política gerenciada pelo cliente que concede permissões para gerenciar IDT e AWS IoT Greengrass funções. ------ #### [ Linux, macOS, or Unix ] ``` aws iam create-policy --policy-name IDTUsageMetricsIAMPermissions --policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot-device-tester:SendMetrics" ], "Resource": "*" } ] }' ``` ------ #### [ Windows command prompt ] ``` aws iam create-policy --policy-name IDTUsageMetricsIAMPermissions --policy-document '{\"Version\": \"2012-10-17\", \"Statement\": [{\"Effect\": \"Allow\", \"Action\": [\"iot-device-tester:SendMetrics\"], \"Resource": \"*\"}]}' ``` **nota** Esta etapa inclui um exemplo de prompt de comando do Windows porque ele usa uma sintaxe JSON diferente dos comandos de terminal Linux, macOS ou Unix. ------ 1. Crie um usuário do IAM e anexe as permissões exigidas pelo IDT para o AWS IoT Greengrass. 1. Criar um usuário do IAM. ``` aws iam create-user --user-name user-name ``` 1. Anexe a política de `IDTUsageMetricsIAMPermissions` criada para o novo usuário do IAM. *user-name*Substitua pelo nome de usuário do IAM e, ** no comando, pelo ID do seu Conta da AWS. ``` aws iam attach-user-policy --user-name user-name --policy-arn arn:aws:iam:::policy/IDTGreengrassIAMPermissions ``` 1. Crie uma chave de acesso secreta para o usuário. ``` aws iam create-access-key --user-name user-name ``` Armazene a saída em um local seguro. Você usa essas informações posteriormente para configurar seu arquivo de AWS credenciais. ## Forneça AWS credenciais ao IDT Para permitir que o IDT acesse suas AWS credenciais e envie métricas para AWS, faça o seguinte: 1. Armazene as AWS credenciais do seu usuário do IAM como variáveis de ambiente ou em um arquivo de credenciais: 1. Para usar as variáveis de ambiente, execute o seguinte comando: ``` AWS_ACCESS_KEY_ID=access-key AWS_SECRET_ACCESS_KEY=secret-access-key ``` 1. Para o arquivo de credenciais, adicione as seguintes informações para `.aws/credentials file:` ``` [profile-name] aws_access_key_id=access-key aws_secret_access_key=secret-access-key ``` 1. Configure a seção `auth` do arquivo `config.json`. Para obter mais informações, consulte [(Opcional) Configurar config.json](set-config-custom.md#config-json-custom). # IDT para solução de problemas AWS IoT Greengrass O IDT para AWS IoT Greengrass gravar esses erros em vários locais com base no tipo de erro. Os erros são gravados no console, arquivos de log e relatórios de teste. ## Códigos de erro A tabela a seguir lista os códigos de erro gerados pelo IDT para AWS IoT Greengrass. | Código de erro | Nome do código de erro | Possível causa raiz | Solução de problemas | | --- | --- | --- | --- | | 101 | InternalError | Ocorreu um erro interno. | Verifique os logs no diretório `/results`. Se você não conseguir depurar o problema, entre em contato com o [Suporte ao desenvolvedor da AWS](https://aws.amazon.com/premiumsupport/plans/developers/). | | 102 | TimeoutError | O teste não pode ser concluído em um período limitado. Isso poderá acontecer se: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) | | 103 | PlatformNotSupportError | Combinação incorreta de SO/arquitetura especificada em `device.json`. | Alterar sua configuração para uma das combinações compatíveis: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) Para obter mais informações, consulte [Configurar device.json](set-config.md#device-config). | | 104 | VersionNotSupportError | A versão do software AWS IoT Greengrass Core não é compatível com a versão do IDT que você está usando. | Use o **device\$1tester\$1bin version** comando para encontrar a versão compatível do software AWS IoT Greengrass Core. Por exemplo, se você estiver usando macOS, use: **./devicetester\$1mac\$1x86\$164 version**. Para encontrar a versão do software AWS IoT Greengrass Core que você está usando: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) Você pode testar uma versão diferente do software AWS IoT Greengrass Core. Para obter mais informações, consulte [Começando com AWS IoT Greengrass](gg-gs.md). | | 105 | LanguageNotSupportError | O IDT suporta Python somente AWS IoT Greengrass para bibliotecas SDKs . | Certifique-se de que: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) | | 106 | ValidationError | Alguns campos em `device.json` ou `config.json` são inválidos. | Verifique a mensagem de erro no lado direito do código de erro no relatório. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) | | 107 | SSHConnectionFalhou | O computador de teste não pode se conectar ao dispositivo configurado. | Verifique se os campos a seguir do arquivo `device.json` estão corretos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) Para obter mais informações, consulte [Configurar device.json](set-config.md#device-config). | | 108 | RunCommandError | O teste não conseguiu executar um comando no dispositivo em teste. | Verifique se o acesso raiz ao usuário configurado em `device.json` é permitido. Uma senha é exigida por alguns dispositivos ao executar comandos com acesso raiz. Verifique se o acesso raiz é permitido sem uma senha. Para obter mais informações, consulte a documentação do seu dispositivo. Tente executar o comando com falha manualmente no dispositivo e verifique se ocorre um erro. | | 109 | PermissionDeniedError | Sem acesso raiz. | Defina o acesso raiz do usuário configurado no seu dispositivo. | | 110 | CreateFileError | Não é possível criar um arquivo. | Verifique o espaço em disco do dispositivo e as permissões do diretório. | | 111 | CreateDirError | Não é possível criar um diretório. | Verifique o espaço em disco do dispositivo e as permissões do diretório. | | 112 | InvalidPathError | O caminho para o software AWS IoT Greengrass principal está incorreto. | Verifique se o caminho na mensagem de erro é válido. Não edite os arquivos do diretório `devicetester_greengrass_`. | | 113 | InvalidFileError | Um arquivo é inválido. | Verifique se o arquivo na mensagem de erro é válido. | | 114 | ReadFileError | Não é possível ler o arquivo especificado. | Verifique o seguinte: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) Se você estiver testando em um macOS, aumente o limite de arquivos abertos. O limite padrão é 256, que é o suficiente para testes. | | 115 | FileNotFoundError | Um arquivo necessário não foi encontrado. | Verifique o seguinte: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) | | 116 | OpenFileFailed | Não foi possível abrir o arquivo especificado. | Verifique o seguinte: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) Se você estiver testando em um macOS, aumente o limite de arquivos abertos. O limite padrão é 256, que é o suficiente para testes. | | 117 | WriteFileFailed | Falha ao gravar arquivo (pode ser o DUT ou computador de teste). | Verifique se o diretório especificado na mensagem de erro existe e se você tem permissão de gravação. | | 118 | FileCleanUpError | O teste não conseguir remover o arquivo especificado ou diretório nem desmontar o arquivo especificado no dispositivo remoto. | Se o arquivo binário ainda estiver em execução, ele poderá ser bloqueado. Termine o processo e exclua o arquivo especificado. | | 119 | InvalidInputError | Configuração inválida. | Verifique se o arquivo `suite.json` é válido. | | 120 | InvalidCredentialError | AWS Credenciais inválidas. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) | | 121 | AWSSessionErro | Falha ao criar uma AWS sessão. | Esse erro pode ocorrer se AWS as credenciais forem inválidas ou se a conexão com a Internet estiver instável. Tente usar o AWS CLI para chamar uma operação de AWS API. | | 122 | AWSApiCallError | Ocorreu um erro de AWS API. | Esse erro pode ser devido a um problema de rede. Verifique sua rede antes de repetir o grupo de testes. | | 123 | IpNotExistError | O endereço IP não está incluído nas informações de conectividade. | Verifique a conexão com a Internet. Você pode usar o AWS IoT Greengrass console para verificar as informações de conectividade do item AWS IoT Greengrass principal que está sendo usado pelo teste. Se houver 10 endpoints incluídos nas informações de conectividade, você poderá remover alguns ou todos e executar o teste novamente. Para obter mais informações, consulte [Informações de conectividade](https://docs.aws.amazon.com/cli/latest/reference/greengrass/get-connectivity-info.html). | | 124 | OTAJobNotCompleteError | Um OTA de trabalho não foi concluído. | Verifique sua conexão com a Internet e tente o grupo de testes OTA novamente. | | 125 | CreateGreengrassServiceRoleError | Houve um dos problemas a seguir: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) | Configure a função AWS IoT Greengrass de serviço. Para obter mais informações, consulte [Função de serviço do Greengrass](service-role.md). | | 126 | DependenciesNotPresentError | Uma ou mais dependências necessárias para o teste específico não estão presentes no dispositivo. | Verifique o log de teste para ver quais dependências estão ausentes no dispositivo: `/results//logs/`. | | 127 | Inválido HSMConfiguration | A configuração HSM/PKCS fornecida está incorreta. | No arquivo `device.json`, forneça a configuração correta necessária para interagir com o HSM usando PKCS\$111. | | 128 | OTAJobNotSuccededError | A tarefa OTA não foi bem-sucedida. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) | | 129 | NoConnectivityError | O atendente de host não consegue se conectar à Internet. | Verifique suas configurações de conexão de rede e firewall. Tente novamente o grupo de testes depois que o problema de conectividade for resolvido. | | 130 | NoPermissionError | O usuário do IAM para o qual você está usando para executar o IDT AWS IoT Greengrass não tem permissão para criar os AWS recursos necessários para executar o IDT. | Consulte [Modelo de política de permissões](https://docs.aws.amazon.com/greengrass/latest/developerguide/policy-template.html) para obter o modelo de política que concede as permissões necessárias para executar o IDT para AWS IoT Greengrass. | | 131 | LeftoverAgentExistError | Seu dispositivo está executando AWS IoT Greengrass processos quando você tenta iniciar o IDT para AWS IoT Greengrass. | Verifique se não há nenhum daemon do Greengrass em execução no dispositivo. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v1/developerguide/idt-troubleshooting.html) Se você estiver usando uma instalação existente ou AWS IoT Greengrass configurada para iniciar automaticamente após a reinicialização, deverá interromper o daemon após a reinicialização e antes de executar a suíte de testes. | | 132 | DeviceTimeOffsetError | O dispositivo tem o horário incorreto. | Defina o horário incorreto no seu dispositivo. | | 133 | Inválido MLConfiguration | A configuração de fornecida está incorreta. | No arquivo `device.json`, forneça a configuração correta necessária para executar testes de inferência de ML. Para obter mais informações, consulte [Opcional: configurar o dispositivo para qualificação de ML](idt-ml-qualification.md). | ## Resolvendo erros no IDT AWS IoT Greengrass Ao usar o IDT, você deve instalar os arquivos de configuração corretos antes de executar o IDT for. AWS IoT Greengrass Se você estiver recebendo erros de análise e configuração, o primeiro passo é localizar e usar um modelo de configuração apropriado para seu ambiente. Se você ainda estiver com problemas, consulte o processo de depuração a seguir. **Topics** + [Onde eu procuro erros?](#where-to-look) + [Erros de análise](#parse-error) + [Erro de parâmetro necessário ausente](#param-missing) + [Erro: Não foi possível iniciar teste](#could-not-start-test) + [Erro de não autorização para acessar um recurso](#not-authorized-to-access-resource) + [Erros de permissão negada](#pwd-sudo) + [Erros de conexão SSH](#ssh-connect-errors) + [Erros de tempo limite](#test-timeout) + [Erros de comando não encontrados durante o teste](#cmd-not-found) + [Exceção de segurança no macOS](#macos-notarization-exception) ### Onde eu procuro erros? Os erros de nível superior serão exibidos no console durante a execução, e um resumo dos testes com falha com o erro será exibido quando todos os testes forem concluídos. `awsiotdevicetester_report.xml` contém um resumo de todos os erros que causaram a falha do teste. Os arquivos de log para cada execução de teste são armazenados em um diretório nomeado com um UUID para a execução de teste que foi exibida no console durante a execução de teste. O diretório dos logs de teste está localizado em `/results//logs/`. Esse diretório contém os seguintes arquivos que são úteis para depuração. | Arquivo | Descrição | | --- | --- | | test\$1manager.log | Todos os logs que foram gravados no console durante a execução do teste. Um resumo dos resultados está localizado no final deste arquivo que inclui uma lista de quais testes falharam. Os logs de aviso e de erro nesse arquivo podem fornecer algumas informações sobre as falhas. | | \$1\$1.log | Logs detalhados para o teste específico. | | \$1ggc\$1logs.tar.gz | Uma coleção compactada de todos os registros que o daemon AWS IoT Greengrass principal gerou durante o teste. Para obter mais informações, consulte [Solução de problemas AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/latest/developerguide/gg-troubleshooting.html). | | \$1ota\$1logs.tar.gz | Uma coleção compactada de registros gerados pelo agente AWS IoT Greengrass OTA durante o teste. Somente para testes OTA. | | \$1basic\$1assertion\$1publisher\$1ggad\$1logs.tar.gz | Um conjunto de logs gerados pelo dispositivo editor do AWS IoT durante o teste. | | \$1basic\$1assertion\$1subscriber\$1ggad\$1logs.tar.gz | Um conjunto de logs gerados pelo dispositivo assinante do AWS IoT durante o teste. | ### Erros de análise Ocasionalmente, um erro ortográfico em uma configuração JSON pode resultar em erros de análise. Na maioria dos casos, o problema é resultado da omissão de um colchete, vírgula ou aspas de seu arquivo JSON. O IDT executa a validação do JSON e imprime as informações de depuração. Ele imprime a linha em que ocorreu o erro, o número da linha e o número da coluna do erro de sintaxe. Essas informações devem ser suficientes para ajudá-lo a corrigir o erro, mas se você ainda não conseguir localizar o erro, poderá realizar a validação manualmente em seu IDE, em um editor de texto, como Atom ou Sublime, ou por meio de uma ferramenta on-line, como JSONLint. ### Erro de parâmetro necessário ausente Como novos atributos estão sendo adicionados ao IDT, os arquivos de configuração podem sofrer alterações. O uso de um arquivo de configuração antigo pode danificar sua configuração. Se isso acontecer, o arquivo `.log`, em `/results//logs`, listará explicitamente todos os parâmetros ausentes. O IDT também valida os esquemas do arquivo de configuração JSON para garantir que a versão compatível mais recente tenha sido usada. ### Erro: Não foi possível iniciar teste Você pode encontrar erros que apontam para falhas ao iniciar o teste. Há várias causas possíveis e, portanto, faça o seguinte: + Verifique se o nome do grupo incluído no comando de execução realmente existe. O nome do grupo é referenciado diretamente em seu arquivo `device.json`. + Verifique se os dispositivos no grupo têm os parâmetros de configuração corretos. ### Erro de não autorização para acessar um recurso Você pode ver a mensagem de erro ` is not authorized to access this resource` na saída do terminal ou no arquivo `test_manager.log` em `/results//logs`. Para resolver este problema, anexe a política gerenciada `AWSIoTDeviceTesterForGreengrassFullAccess` ao usuário de teste. Para obter mais informações, consulte [Crie e configure um Conta da AWS](dev-tst-prereqs.md#config-aws-account-for-idt). ### Erros de permissão negada O ITD executa operações em vários diretórios e arquivos em um dispositivo em teste. Algumas dessas operações exigem acesso raiz. Para automatizar essas operações, o IDT deverá ser capaz de executar comandos com sudo sem digitar uma senha. Siga estas etapas para permitir o acesso do sudo sem digitar uma senha. **nota** `user` e `username` se referem ao usuário SSH usado pelo IDT para acessar o dispositivo em teste. 1. Use **sudo usermod -aG sudo **** para adicionar o usuário SSH ao grupo sudo. 1. Saia e faça login para que as alterações entrem em vigor. 1. Abra o arquivo `/etc/sudoers` e adicione a linha a seguir ao final do arquivo: ` ALL=(ALL) NOPASSWD: ALL` **nota** Como prática recomendada, recomendamos que você use **sudo visudo** ao editar `/etc/sudoers`. ### Erros de conexão SSH Quando o IDT não puder se conectar a um dispositivo em teste, as falhas de conexão serão registradas em log em `/results//logs/.log`. As mensagens de falha de SSH aparecem na parte superior desse arquivo de log, pois a conexão com um dispositivo em teste é uma das primeiras operações executadas pelo IDT. A maioria das configurações do Windows usa o aplicativo de TTy terminal Pu para se conectar aos hosts Linux. Esse aplicativo requer que os arquivos de chave privada PEM padrão sejam convertidos em um formato Windows proprietário chamado PPK. Quando IDT estiver configurado em seu arquivo `device.json`, use apenas os arquivos PEM. Se você usar um arquivo PPK, o IDT não poderá criar uma conexão SSH com o AWS IoT Greengrass dispositivo e não poderá executar testes. ### Erros de tempo limite Você pode aumentar o tempo limite para cada teste especificando um multiplicador de tempo limite, que será aplicado ao valor padrão de cada tempo limite do teste. Qualquer valor configurado para esse sinalizador deve ser maior que ou igual a 1.0. Para usar o multiplicador de tempo limite, use o sinalizador `--timeout-multiplier` ao executar os testes. Por exemplo: ``` ./devicetester_linux run-suite --suite-id GGQ_1.0.0 --pool-id DevicePool1 --timeout-multiplier 2.5 ``` Para obter mais informações, execute `run-suite --help`. ### Erros de comando não encontrados durante o teste Você precisa de uma versão mais antiga da biblioteca OpenSSL (libssl1.0.0) para executar testes em dispositivos. AWS IoT Greengrass A maioria das distribuições atuais do Linux usa o libssl versão 1.0.2 ou posterior (v1.1.0). Por exemplo, em um Raspberry Pi, execute os seguintes comandos para instalar a versão necessária do libssl: 1. ``` wget http://ftp.us.debian.org/debian/pool/main/o/openssl/libssl1.0.0_1.0.2l-1~bpo8+1_armhf.deb ``` 1. ``` sudo dpkg -i libssl1.0.0_1.0.2l-1~bpo8+1_armhf.deb ``` ### Exceção de segurança no macOS Quando você executa o IDT em uma máquina host que usa o macOS 10.15, o tíquete de reconhecimento de firma do IDT não é detectado corretamente e o IDT é impedido de ser executado. Para executar o IDT, você precisará conceder uma exceção de segurança ao executável `devicetester_mac_x86-64`. **Para conceder uma exceção de segurança ao executável do IDT** 1. Inicie as **Preferências do Sistema** no menu Apple. 1. Selecione **Segurança e privacidade** e, em seguida, na guia **Geral**, clique no ícone de cadeado para fazer alterações nas configurações de segurança. 1. Procure a mensagem `"devicetester_mac_x86-64" was blocked from use because it is not from an identified developer.` e, em seguida selecione **Permitir mesmo assim**. 1. Aceite o aviso de segurança. Se você tiver dúvidas sobre a política de suporte do IDT, entre em contato com o [Suporte ao cliente da AWS](https://aws.amazon.com/contact-us/). # Política de suporte para AWS IoT Device Tester for AWS IoT Greengrass V1 AWS IoT [O Device Tester (IDT) for AWS IoT Greengrass é uma estrutura de teste disponível para download que permite validar e [qualificar](https://aws.amazon.com/partners/dqp/) seus AWS IoT Greengrass dispositivos para inclusão no Catálogo de dispositivos.AWS Partner](https://devices.amazonaws.com/) Recomendamos que você use a versão mais recente do AWS IoT Greengrass e do IDT para testar ou qualificar seus dispositivos. Para obter informações, consulte [Versões compatíveis do IDT para AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/dev-test-versions.html) no *Guia do desenvolvedor do AWS IoT Greengrass Version 2 *. Você também pode usar qualquer uma das versões compatíveis do AWS IoT Greengrass e do IDT para testar ou qualificar seus dispositivos. Embora seja possível continuar a usar [versões não compatíveis do IDT](dev-test-versions.md#idt-unsupported-versions), essas versões não recebem correções de bugs ou atualizações. **Importante** A partir de 4 de abril de 2022, AWS IoT o Device Tester (IDT) AWS IoT Greengrass V1 não gera mais relatórios de qualificação assinados. Você não pode mais qualificar novos AWS IoT Greengrass V1 dispositivos para serem listados no [Catálogo de AWS Partner Dispositivos](https://devices.amazonaws.com/) por meio do [Programa de Qualificação de AWS Dispositivos](https://aws.amazon.com/partners/programs/dqp/). Embora você não possa qualificar dispositivos Greengrass V1, você pode continuar usando o IDT AWS IoT Greengrass V1 para testar seus dispositivos Greengrass V1. Recomendamos que você use o [IDT para AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) para qualificar e listar dispositivos Greengrass no [AWS Partner Catálogo de dispositivos](https://devices.amazonaws.com/). Se você tiver dúvidas sobre a política de suporte, entre em contato com o [Suporte ao cliente da AWS](https://aws.amazon.com/contact-us/).