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á.
# AWS IoT Device Tester para FreeRTOS
O IDT para FreeRTOS é uma ferramenta para qualificar a taxa de throughput de dados no sistema operacional do FreeRTOS. O testador de dispositivos (IDT) abre primeiro uma conexão USB ou UART com um dispositivo. Em seguida, ele exibe uma imagem dos FreeRTOS configurados para testar a funcionalidade do dispositivo sob várias condições. AWS IoT Device Tester as suítes são extensíveis e o IDT é usado para orquestração de AWS IoT testes do cliente.
O IDT para FreeRTOS é executado em um computador host (Windows, macOS ou Linux) que está conectado à placa a ser testada. O IDT configura e orquestra casos de teste e reúne resultados. Ele também fornece uma interface de linha de comando para gerenciar a execução do teste.
## Pacote de qualificação do FreeRTOS
O IDT para FreeRTOS verifica a porta do FreeRTOS em seu microcontrolador e se ele pode se comunicar de forma eficaz de maneira confiável e segura. AWS IoT Especificamente, ele verifica se as interfaces da camada de portabilidade para as bibliotecas do FreeRTOS estão implementadas corretamente. Ele também realiza end-to-end testes com AWS IoT Core. Por exemplo, verifica se a placa pode enviar e receber mensagens MQTT e processá-las corretamente.
[O pacote FreeRTOS Qualification (FRQ) 2.0 usa casos de testes do Device Advisor definidos no Guia FreeRTOS-Libraries-Integration-Tests de Qualificação do FreeRTOS.](https://docs.aws.amazon.com/freertos/latest/qualificationguide/freertos-qualification.html#qualifying-your-device-idt)
O IDT for FreeRTOS gera relatórios de teste que você pode enviar AWS à Partner Network (APN) para inclusão de seus dispositivos FreeRTOS no Catálogo de dispositivos do parceiro. AWS Para obter mais informações, consulte [Programa de Qualificação de Dispositivos da AWS](https://aws.amazon.com/partners/dqp/).
O diagrama a seguir mostra a configuração da infraestrutura de teste para a qualificação do FreeRTOS.
![\[Fluxograma que mostra como AWS IoT Core interage com seu computador e o microcontrolador.\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/images/devicetester_afr.png)
O IDT para FreeRTOS organiza testes em pacotes de testes e grupos de testes:
+ Um pacote de testes é o conjunto de grupos de teste usado para verificar se um dispositivo funciona com versões específicas do FreeRTOS.
+ Um grupo de testes é o conjunto de casos de teste individuais relacionados a um recurso específico, como sistemas de mensagens BLE e MQTT.
Para obter mais informações, consulte [Versões do pacote de testes](idt-test-suite-versions.md).
## Entenda os pacotes de teste personalizados
O IDT para FreeRTOS combina uma configuração padronizada e um formato de resultado com um ambiente de pacotes de teste. Este ambiente permite que você desenvolva pacotes de teste personalizados para seus dispositivos e software de dispositivos. Você pode adicionar testes personalizados a própria validação interna ou fornecê-los aos seus clientes para verificação de dispositivo.
A forma como os pacotes de teste personalizados são configurados determina as configurações que devem ser fornecidas aos usuários para executar seus pacotes de teste personalizados. Para obter mais informações, consulte [Desenvolver e executar os próprios pacotes de testes do IDT](idt-custom-tests.md).
# Versões compatíveis do AWS IoT Device Tester
Este tópico lista as versões compatíveis do AWS IoT Device Tester para FreeRTOS. Como prática recomendada, é aconselhável usar a versão mais recente do IDT para FreeRTOS que seja compatível com a sua versão de destino do FreeRTOS. Cada versão do IDT para FreeRTOS tem uma ou mais versões correspondentes do FreeRTOS que ele oferece suporte. Recomendamos que você baixe uma nova versão do IDT para FreeRTOS quando uma nova versão do FreeRTOS for lançada.
Ao fazer o download do software, você concorda com o Contrato de Licença do AWS IoT Device Tester contido no arquivo de download.
**nota**
Ao usar oAWS IoT Device Tester para FreeRTOS, recomendamos que você atualize para a última versão do patch da versão mais recente do FreeRTOS-LTS.
**Importante**
Desde outubro de 2022, o AWS IoT Device Tester para AWS IoT da qualificação do FreeRTOS (FRQ) 1.0 não gera relatórios de qualificação assinados. Você não pode qualificar novos dispositivos AWS IoT do FreeRTOS para serem listados no [AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices) por meio do [Programa de qualificação de dispositivos da AWS](https://aws.amazon.com/partners/programs/dqp/) usando as versões IDT FRQ 1.0. Embora você não possa qualificar dispositivos FreeRTOS usando o IDT FRQ 1.0, você pode continuar testando seus dispositivos FreeRTOS com o FRQ 1.0. Recomendamos que você use o [IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) para qualificar e listar dispositivos FreeRTOS no [AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices).
## Versão mais recente do AWS IoT Device Tester para FreeRTOS
Use os links a seguir para baixar as versões mais recente do IDT para FreeRTOS.
**Versão mais recente do AWS IoT Device Tester para FreeRTOS**
| **Versão do AWS IoT Device Tester** | **Versões do pacote de testes** | **Versões compatíveis do FreeRTOS** | **Links para fazer download** | **Data de lançamento** | **Notas da versão** |
| --- | --- | --- | --- | --- | --- |
| IDT v4.9.0 | FRQ\$12.5.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dev-test-versions-afr.html) | 04/04/2023 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dev-test-versions-afr.html) |
**nota**
Não é recomendável que vários usuários executem o IDT em um local compartilhado, como um diretório NFS ou uma pasta compartilhada de rede do Windows. Essa prática pode resultar em falhas ou corrupção de dados. Recomendamos extrair o pacote do IDT para uma unidade local e executar o binário do IDT na estação de trabalho local.
## Versões antigas do IDT para o FreeRTOS
As seguintes versões antigas do IDT para FreeRTOS também são compatíveis.
**Versões antigas do AWS IoT Device Tester para o FreeRTOS**
| **Versão do AWS IoT Device Tester** | **Versões do pacote de testes** | **Versões compatíveis do FreeRTOS** | **Links para fazer download** | **Data de lançamento** | **Notas da versão** |
| --- | --- | --- | --- | --- | --- |
| IDT v4.8.1 | FRQ\$12.4.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dev-test-versions-afr.html) | 23/01/2023 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dev-test-versions-afr.html) |
| IDT v4.6.0 | FRQ\$12.3.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dev-test-versions-afr.html) | 16/11/2022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dev-test-versions-afr.html) |
| IDT v4.5.11 | FRQ\$12.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dev-test-versions-afr.html) | 14/10/2022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dev-test-versions-afr.html) |
Para obter mais informações, consulte [Entenda a política de suporte para AWS IoT Device Tester](idt-support-policy.md).
# Versões não compatíveis do IDT para FreeRTOS
Esta seção lista as versões não compatíveis do IDT para FreeRTOS. Versões não compatíveis não recebem correções de bugs ou atualizações. Para obter mais informações, consulte [Entenda a política de suporte para AWS IoT Device Tester](idt-support-policy.md).
As seguintes versões do IDT-FreeRTOS não são mais compatíveis.
**Versões não compatíveis do AWS IoT Device Tester para FreeRTOS**
| **Versão do AWS IoT Device Tester** | **Versões do pacote de testes** | **Versões compatíveis do FreeRTOS** | **Data de lançamento** | **Notas da versão** |
| --- | --- | --- | --- | --- |
| IDT v4.5.10 | FRQ\$12.1.4 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2/09/2022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.9 | FRQ\$12.1.3 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 17/08/2022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.6 | FRQ\$12.1.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 29/06/2022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.5 | FRQ\$12.1.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 06/06/2022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.5 | FRQ\$12.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 31/05/2022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.4 | FRQ\$12.0.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 09/05/2022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.2 | FRQ\$11.6.2 | 202107.00 | 25/01/2022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.0.3 | FRQ\$11.5.1 | 202012.00 | 30/07/2021 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.3.0 | FRQ\$11.6.1 | 202107.00 | 26/07/2021 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.1.0 | FRQ\$11.6.0 | 202107.00 | 21/07/2021 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.0.1 | FRQ\$11.4.1 | 202012.00 | 19/01/2021 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.4.0 | FRQ\$11.3.0 | 202011.01 | 05/11/2020 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.3.0 | FRQ\$11.2.0 | 202007.00 | 17/09/2020 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.0.2 | FRQ\$11.0.1 | 202002.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.7.1 | FRQ\$11.0.0 | 202002.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.6.2 | FRQ\$11.0.0 | 202002.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.5.2 | FRQ\$11.0.0 | 201910.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.4.1 | FRQ\$11.0.0 | 201908.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.3.2 | FRQ\$11.0.0 | 201906.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT-FreeRTOS v1.2 | FRQ\$11.0.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/idt-unsupported-versions-afr.html) | | Adicionou suporte para testes de dispositivos FreeRTOS com o sistema de compilação CMAKE. |
| IDT-FreeRTOS v1.1 | FRQ\$11.0.0 | | | |
| IDT-FreeRTOS v1.0 | FRQ\$11.0.0 | | | |
# Fazer download do IDT para FreeRTOS
Este tópico descreve as opções para baixar o IDT para FreeRTOS. Você pode usar um dos links de download de software a seguir ou seguir as instruções para baixar o IDT de forma programada.
**Importante**
Desde outubro de 2022, o AWS IoT Device Tester para AWS IoT da qualificação do FreeRTOS (FRQ) 1.0 não gera relatórios de qualificação assinados. Você não pode qualificar novos dispositivos AWS IoT do FreeRTOS para serem listados no [AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices) por meio do [Programa de qualificação de dispositivos da AWS](https://aws.amazon.com/partners/programs/dqp/) usando as versões IDT FRQ 1.0. Embora você não possa qualificar dispositivos FreeRTOS usando o IDT FRQ 1.0, você pode continuar testando seus dispositivos FreeRTOS com o FRQ 1.0. Recomendamos que você use o [IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) para qualificar e listar dispositivos FreeRTOS no [AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices).
**Topics**
+ [Baixar IDT manualmente](#idt-download-options)
+ [Baixar IDT de maneira programada](idt-programmatic-download-process.md)
Ao fazer o download do software, você concorda com o Contrato de Licença do AWS IoT Device Tester contido no arquivo de download.
**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.
## Baixar IDT manualmente
Este tópico lista as versões compatíveis do IDT para FreeRTOS. Como prática recomendada, aconselhamos usar a versão mais recente do AWS IoT Device Tester que seja compatível com a sua versão de destino do FreeRTOS. Novas versões do FreeRTOS podem exigir que você faça o download de uma nova versão do AWS IoT Device Tester. Você receberá uma notificação ao iniciar uma execução de teste se o IDT para AWS IoT Device Tester não for compatível com a versão do FreeRTOS que você está usando.
Consulte [Versões compatíveis do AWS IoT Device Tester](dev-test-versions-afr.md)
# Baixar IDT de maneira programada
O IDT fornece uma operação de API que você pode usar para recuperar um URL na qual é possível baixar o IDT de maneira programada. Você também pode usar essa operação de API para verificar se você tem a versão mais recente do IDT. Essa operação da API tem o seguinte endpoint.
```
https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt
```
Para chamar essa operação de API, você deve ter a permissão para executar a ação **iot-device-tester:LatestIdt**. Inclua sua assinatura da AWS, com `iot-device-tester` como o nome do serviço
## Solicitações de API
HostOS: o sistema operacional da máquina host. Escolha uma das seguintes opções:
+ `mac`
+ `linux`
+ `windows`
TestSuiteType: o tipo do pacote de testes. Escolha a seguinte opção:
`FR`: IDT para FreeRTOS
ProductVersion
(Opcional) A versão do FreeRTOS. O serviço retorna a versão mais recente compatível do IDT para essa versão do FreeRTOS. Se você não especificar essa opção, o serviço retornará a versão mais recente do IDT.
## Resposta da API
O resposta da API tem o seguinte formato. O arquivo `DownloadURL` inclui o arquivo zip.
```
{
"Success": True or False,
"Message": Message,
"LatestBk": {
"Version": The version of the IDT binary,
"TestSuiteVersion": The version of the test suite,
"DownloadURL": The URL to download the IDT Bundle, valid for one hour
}
}
```
## Exemplos
Você pode consultar os exemplos a seguir para baixar o IDT de maneira programada. Esses exemplos usam credenciais que você armazena nas variáveis de ambiente `AWS_ACCESS_KEY_ID` e `AWS_SECRET_ACCESS_KEY`. Para seguir as práticas recomendadas de segurança, não armazene suas credenciais em seu código.
**Example**
**Exemplo: faça download usando cURL versão 7.75.0 ou posterior (Mac e Linux)**
Se você tiver a versão 7.75.0 ou posterior do cURL, poderá usar a sinalização `aws-sigv4` para assinar a solicitação da API. Este exemplo usa [jq](https://stedolan.github.io/jq/) para analisar o URL de download da resposta.
A sinalização `aws-sigv4` exige que os parâmetros de consulta da solicitação GET curl estejam na ordem **HostOs/ProductVersion/TestSuiteType** ou **HostOs/TestSuiteType**. Pedidos que não estiverem em conformidade resultarão em um erro ao obter assinaturas incompatíveis para a string canônica do API Gateway.
Se o parâmetro opcional **ProductVersion** estiver incluído, você deverá usar uma versão de produto compatível conforme documentado em [Versões compatíveis do AWS IoT Device Tester para FreeRTOS](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html).
+ Substitua *us-west-2* pela sua Região da AWS. Para obter uma lista de códigos de região, consulte [Endpoints regionais](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints).
+ Substitua *linux* pelo sistema operacional da sua máquina host.
+ Substitua *202107.00* pela sua versão dos FreeRTOS.
```
url=$(curl --request GET "https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt?HostOs=linux&ProductVersion=202107.00&TestSuiteType=FR" \
--user $AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY \
--aws-sigv4 "aws:amz:us-west-2:iot-device-tester" \
| jq -r '.LatestBk["DownloadURL"]')
curl $url --output devicetester.zip
```
**Example**
**Exemplo: faça download usando uma versão anterior do cURL (Mac e Linux)**
Você pode usar o seguinte comando cURL com uma assinatura da AWS que você assina e calcula. Para obter mais informações sobre como assinar e calcular uma assinatura da AWS, consulte [Assinatura de solicitações de API da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html).
+ Substitua *linux* pelo sistema operacional da sua máquina host.
+ Substitua *Timestamp* pela data e hora, como **20220210T004606Z**.
+ Substitua a *date* pela data, como **20220210**.
+ Substitua a *AWSRegion* pela sua Região da AWS. Para obter uma lista de códigos de região, consulte [Endpoints regionais](https://docs.aws.amazon.com/general/latest/gr/rande.html).
+ Substitua *AWSSignature* pela [Assinatura da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv-create-signed-request.html) gerada.
```
curl --location --request GET 'https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt?HostOs=linux&TestSuiteType=FR' \
--header 'X-Amz-Date: Timestamp \
--header 'Authorization: AWS4-HMAC-SHA256 Credential=$AWS_ACCESS_KEY_ID/Date/AWSRegion/iot-device-tester/aws4_request, SignedHeaders=host;x-amz-date, Signature=AWSSignature'
```
**Example**
**Exemplo: faça o download usando um script Python**
Este exemplo usa a biblioteca de [solicitações](https://pypi.org/project/requests/) do Python. Esse exemplo foi adaptado do exemplo do Python para [Assinar uma solicitação de API da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) na *Referência geral da AWS*.
+ Substitua *us-west-2* pela sua região. Para obter uma lista de códigos de região, consulte [Endpoints regionais](https://docs.aws.amazon.com/general/latest/gr/rande.html).
+ Substitua *linux* pelo sistema operacional da sua máquina host.
```
# Copyright 2010-2022 Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# This file is licensed under the Apache License, Version 2.0 (the "License").
# You may not use this file except in compliance with the License. A copy of the
#License is located at
#
# http://aws.amazon.com/apache2.0/
#
# This file is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS
# OF ANY KIND, either express or implied. See the License for the specific
# language governing permissions and limitations under the License.
# See: http://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html
# This version makes a GET request and passes the signature
# in the Authorization header.
import sys, os, base64, datetime, hashlib, hmac
import requests # pip install requests
# ************* REQUEST VALUES *************
method = 'GET'
service = 'iot-device-tester'
host = 'download.devicetester.iotdevicesecosystem.amazonaws.com'
region = 'us-west-2'
endpoint = 'https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt'
request_parameters = 'HostOs=linux&TestSuiteType=FR'
# Key derivation functions. See:
# http://docs.aws.amazon.com/general/latest/gr/signature-v4-examples.html#signature-v4-examples-python
def sign(key, msg):
return hmac.new(key, msg.encode('utf-8'), hashlib.sha256).digest()
def getSignatureKey(key, dateStamp, regionName, serviceName):
kDate = sign(('AWS4' + key).encode('utf-8'), dateStamp)
kRegion = sign(kDate, regionName)
kService = sign(kRegion, serviceName)
kSigning = sign(kService, 'aws4_request')
return kSigning
# Read AWS access key from env. variables or configuration file. Best practice is NOT
# to embed credentials in code.
access_key = os.environ.get('AWS_ACCESS_KEY_ID')
secret_key = os.environ.get('AWS_SECRET_ACCESS_KEY')
if access_key is None or secret_key is None:
print('No access key is available.')
sys.exit()
# Create a date for headers and the credential string
t = datetime.datetime.utcnow()
amzdate = t.strftime('%Y%m%dT%H%M%SZ')
datestamp = t.strftime('%Y%m%d') # Date w/o time, used in credential scope
# ************* TASK 1: CREATE A CANONICAL REQUEST *************
# http://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html
# Step 1 is to define the verb (GET, POST, etc.)--already done.
# Step 2: Create canonical URI--the part of the URI from domain to query
# string (use '/' if no path)
canonical_uri = '/latestidt'
# Step 3: Create the canonical query string. In this example (a GET request),
# request parameters are in the query string. Query string values must
# be URL-encoded (space=%20). The parameters must be sorted by name.
# For this example, the query string is pre-formatted in the request_parameters variable.
canonical_querystring = request_parameters
# Step 4: Create the canonical headers and signed headers. Header names
# must be trimmed and lowercase, and sorted in code point order from
# low to high. Note that there is a trailing \n.
canonical_headers = 'host:' + host + '\n' + 'x-amz-date:' + amzdate + '\n'
# Step 5: Create the list of signed headers. This lists the headers
# in the canonical_headers list, delimited with ";" and in alpha order.
# Note: The request can include any headers; canonical_headers and
# signed_headers lists those that you want to be included in the
# hash of the request. "Host" and "x-amz-date" are always required.
signed_headers = 'host;x-amz-date'
# Step 6: Create payload hash (hash of the request body content). For GET
# requests, the payload is an empty string ("").
payload_hash = hashlib.sha256(('').encode('utf-8')).hexdigest()
# Step 7: Combine elements to create canonical request
canonical_request = method + '\n' + canonical_uri + '\n' + canonical_querystring + '\n' + canonical_headers + '\n' + signed_headers + '\n' + payload_hash
# ************* TASK 2: CREATE THE STRING TO SIGN*************
# Match the algorithm to the hashing algorithm you use, either SHA-1 or
# SHA-256 (recommended)
algorithm = 'AWS4-HMAC-SHA256'
credential_scope = datestamp + '/' + region + '/' + service + '/' + 'aws4_request'
string_to_sign = algorithm + '\n' + amzdate + '\n' + credential_scope + '\n' + hashlib.sha256(canonical_request.encode('utf-8')).hexdigest()
# ************* TASK 3: CALCULATE THE SIGNATURE *************
# Create the signing key using the function defined above.
signing_key = getSignatureKey(secret_key, datestamp, region, service)
# Sign the string_to_sign using the signing_key
signature = hmac.new(signing_key, (string_to_sign).encode('utf-8'), hashlib.sha256).hexdigest()
# ************* TASK 4: ADD SIGNING INFORMATION TO THE REQUEST *************
# The signing information can be either in a query string value or in
# a header named Authorization. This code shows how to use a header.
# Create authorization header and add to request headers
authorization_header = algorithm + ' ' + 'Credential=' + access_key + '/' + credential_scope + ', ' + 'SignedHeaders=' + signed_headers + ', ' + 'Signature=' + signature
# The request can include any headers, but MUST include "host", "x-amz-date",
# and (for this scenario) "Authorization". "host" and "x-amz-date" must
# be included in the canonical_headers and signed_headers, as noted
# earlier. Order here is not significant.
# Python note: The 'host' header is added automatically by the Python 'requests' library.
headers = {'x-amz-date':amzdate, 'Authorization':authorization_header}
# ************* SEND THE REQUEST *************
request_url = endpoint + '?' + canonical_querystring
print('\nBEGIN REQUEST++++++++++++++++++++++++++++++++++++')
print('Request URL = ' + request_url)
response = requests.get(request_url, headers=headers)
print('\nRESPONSE++++++++++++++++++++++++++++++++++++')
print('Response code: %d\n' % response.status_code)
print(response.text)
download_url = response.json()["LatestBk"]["DownloadURL"]
r = requests.get(download_url)
open('devicetester.zip', 'wb').write(r.content)
```
# IDT com o pacote de qualificação do FreeRTOS 2.0 (FRQ 2.0)
O pacote de qualificação do FreeRTOS 2.0 é uma versão atualizada do pacote de qualificação do FreeRTOS. É recomendado que os desenvolvedores usem o FRQ 2.0 porque ele consiste em casos de teste relevantes para qualificar dispositivos que executam as bibliotecas do FreeRTOS Long Term Support (LTS).
O IDT para FreeRTOS verifica a porta do FreeRTOS em seu microcontrolador e se ele se comunica de forma eficaz com. AWS IoT Especificamente, ele verifica as interfaces da camada de portabilidade com as bibliotecas do FreeRTOS e se os repositórios de teste do FreeRTOS estão implementados corretamente. Ele também realiza end-to-end testes com AWS IoT Core. [Os testes executados pelo IDT para FreeRTOS são definidos no repositório do FreeRTOS. GitHub](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests)
O IDT para FreeRTOS executa testes como aplicações incorporadas que são exibidas no dispositivo microcontrolador em teste. As imagens binárias da aplicação incluem o FreeRTOS, as interfaces do FreeRTOS obtidas por portabilidade e os drivers de dispositivos da placa. A finalidade dos testes é verificar se as interfaces do FreeRTOS obtidas por portabilidade funcionam corretamente em cima dos drivers do seu dispositivo.
O IDT for FreeRTOS gera relatórios de teste que você pode enviar AWS IoT para que seu hardware seja listado no AWS Partner Device Catalog. Para obter mais informações, consulte [Programa de Qualificação de Dispositivos da AWS](https://aws.amazon.com/partners/dqp/).
O IDT para FreeRTOS é executado em um computador host (Windows, macOS ou Linux) que está conectado à placa em teste. O IDT configura e orquestra casos de teste e reúne resultados. Ele também fornece uma interface de linha de comando para gerenciar a execução dos testes.
Para testar seu dispositivo, o IDT for FreeRTOS cria recursos como AWS IoT coisas, grupos do FreeRTOS e funções Lambda. Para criar esses recursos, o IDT para FreeRTOS usa AWS as credenciais configuradas no para fazer chamadas de API em `config.json` seu nome. Esses recursos são provisionados em vários momentos durante o teste.
Ao executar o IDT para FreeRTOS em seu computador host, ele executa as seguintes etapas:
1. Carrega e valida o dispositivo e configuração de credenciais.
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 a placa passou nos testes necessários para a qualificação.
# Configurar os pré-requisitos de qualificação LTS
Esta seção descreve os pré-requisitos para testar microcontroladores com. AWS IoT Device Tester
## Preparar-se para a qualificação do FreeRTOS
**nota**
AWS IoT Device Tester for FreeRTOS recomenda fortemente o uso da última versão de patch da versão mais recente do FreeRTOS-LTS.
O IDT para FRQ 2.0 é uma qualificação para FreeRTOS. Antes de executar o IDT FRQ 2.0 para qualificação, é preciso concluir a [Qualificação de sua placa](https://docs.aws.amazon.com/freertos/latest/qualificationguide/freertos-qualification.html) no *Guia de qualificação do FreeRTOS*. Para portar bibliotecas, testar e configurar o `manifest.yml`, consulte [Como portar as bibliotecas do FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting.html) no *Guia de portabilidade do FreeRTOS*. O FRQ 2.0 contém um processo diferente de qualificação. Consulte [Alterações mais recentes na qualificação](https://docs.aws.amazon.com/freertos/latest/qualificationguide/latest-changes.html) no *Guia de qualificação do FreeRTOS* para obter detalhes.
O repositório [IDT-FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests) deve estar presente para que o IDT seja executado. Consulte o [README.md](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests/blob/main/README.md) sobre como clonar e portar esse repositório para seu projeto de origem. FreeRTOS-Libraries-Integration-Testsdeve incluir o `manifest.yml` localizado na raiz do seu projeto, para que o IDT seja executado.
**nota**
O IDT depende da implementação do repositório de testes do `UNITY_OUTPUT_CHAR`. Os logs de saída de teste e os logs do dispositivo não devem ser intercalados entre si. Consulte [Como implementar a seção de macros de registro em log da biblioteca](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-library-logging-macros.html) no *Guia de portabilidade do FreeRTOS* para obter mais detalhes.
## Baixe o IDT para FreeRTOS
Cada versão do FreeRTOS tem uma versão correspondente do IDT para o FreeRTOS para realizar testes de qualificação. Baixe a versão apropriada do IDT para FreeRTOS a [partir das versões](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html) suportadas do para FreeRTOS. AWS IoT Device Tester
Extraia o IDT para FreeRTOS em um local no sistema de arquivos onde existam permissões de leitura e gravação. Como o Microsoft Windows tem um limite de caracteres para o comprimento do caminho, extraia o IDT para FreeRTOS em um diretório raiz, como `C:\` ou `D:\`.
**nota**
Vários usuários não devem executar o IDT de um local compartilhado, como um diretório NFS ou uma pasta compartilhada de rede do Windows. Isto pode resultar em falhas ou corrupção de dados. Recomendamos extrair o pacote IDT para uma unidade local.
## Baixe o Git
O IDT deve ter o Git instalado como um pré-requisito para garantir a integridade do código-fonte.
Siga as instruções no [GitHub](https://github.com/git-guides/install-git)guia para instalar o Git. Para verificar a versão atual instalada do Git, digite o comando `git --version` no terminal.
**Atenção**
O IDT usa o Git para se alinhar ao status de limpo ou sujo de um diretório. Se o Git não estiver instalado, os grupos de teste `FreeRTOSIntegrity` falharão ou não serão executados conforme o esperado. Se o IDT retornar um erro como `git executable not found` ou`git command not found`, instale ou reinstale o Git e tente novamente.
**Topics**
+ [Preparar-se para a qualificação do FreeRTOS](#idt-preparing-qualification)
+ [Baixe o IDT para FreeRTOS](#idt-download-dev-tester-afr)
+ [Baixe o Git](#idt-download-git)
+ [Crie uma AWS conta](#lts-config-aws-account)
+ [AWS IoT Device Tester política gerenciada](#managed-policy)
+ [(Opcional) Instale o AWS Command Line Interface](#install-cli)
## Crie uma AWS conta
**nota**
O pacote completo de qualificação da IDT é suportado somente no seguinte Regiões da AWS
Leste dos EUA (N. da Virgínia)
Oeste dos EUA (Oregon)
Ásia-Pacífico (Tóquio)
Europa (Irlanda)
Para testar seu dispositivo, o IDT for FreeRTOS cria recursos como AWS IoT coisas, grupos do FreeRTOS e funções Lambda. Para criar esses recursos, o IDT for FreeRTOS exige que você crie e configure AWS uma conta e uma política do IAM que conceda ao IDT for FreeRTOS permissão para acessar recursos em seu nome durante a execução de testes.
As etapas a seguir são para criar e configurar sua AWS conta.
1. Se você já tiver uma AWS conta, vá para a próxima etapa. Para criar uma [conta da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/).
1. Siga as etapas em [Como criar perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html). Não adicione permissões ou políticas no momento.
1. Para executar testes de qualificação OTA, vá para a etapa 4. Caso contrário, vá para a etapa 5.
1. Anexe a política embutida de permissões do OTA IAM ao seu perfil do IAM.
1.
**Importante**
O modelo de política a seguir concede ao IDT permissão para criar funções e políticas, e associar políticas às funções. O IDT para FreeRTOS usa essas permissões para testes que criam perfis. Embora o modelo de política não forneça privilégios de administrador ao usuário, as permissões podem ser usadas para obter acesso de administrador à sua AWS conta.
1. Siga as etapas abaixo para anexar as permissões necessárias ao perfil do IAM:
1. Na guia **Permissões**, escolha **Adicionar permissões**.
1. Escolha **Criar política em linha**.
1. Escolha a guia **JSON** e copie as permissões a seguir na caixa de texto **JSON**. Use o modelo na **Maioria das regiões** se não estiver na região da China. Se estiver na região da China, use o modelo nas **regiões de Pequim e Ningxia**.
------
#### [ Most Regions ]
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iotdeviceadvisor:*",
"Resource": [
"arn:aws:iotdeviceadvisor:*:*:suiterun/*/*",
"arn:aws:iotdeviceadvisor:*:*:suitedefinition/*"
]
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/idt*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "iotdeviceadvisor.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke*",
"iam:ListRoles",
"iot:Connect",
"iot:CreateJob",
"iot:DeleteJob",
"iot:DescribeCertificate",
"iot:DescribeEndpoint",
"iot:DescribeJobExecution",
"iot:DescribeJob",
"iot:DescribeThing",
"iot:GetPolicy",
"iot:ListAttachedPolicies",
"iot:ListCertificates",
"iot:ListPrincipalPolicies",
"iot:ListThingPrincipals",
"iot:ListThings",
"iot:Publish",
"iot:UpdateThingShadow",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:PutLogEvents",
"logs:PutRetentionPolicy"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iotdeviceadvisor:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "logs:DeleteLogGroup",
"Resource": "arn:aws:logs:*:*:log-group:/aws/iot/deviceadvisor/*"
},
{
"Effect": "Allow",
"Action": "logs:GetLogEvents",
"Resource": "arn:aws:logs:*:*:log-group:/aws/iot/deviceadvisor/*:log-stream:*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreatePolicy",
"iam:DetachRolePolicy",
"iam:DeleteRolePolicy",
"iam:DeletePolicy",
"iam:CreateRole",
"iam:DeleteRole",
"iam:AttachRolePolicy"
],
"Resource": [
"arn:aws:iam::*:policy/idt*",
"arn:aws:iam::*:role/idt*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameters"
],
"Resource": [
"arn:aws:ssm:*::parameter/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:RunInstances",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateKeyPair",
"ec2:DeleteKeyPair"
],
"Resource": [
"arn:aws:ec2:*:*:key-pair/idt-ec2-ssh-key-*"
]
},
{
"Effect": "Allow",
"Condition": {
"StringEqualsIgnoreCase": {
"aws:ResourceTag/Owner": "IoTDeviceTester"
}
},
"Action": [
"ec2:TerminateInstances",
"ec2:DeleteSecurityGroup",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupIngress"
],
"Resource": [
"*"
]
}
]
}
```
------
------
#### [ Beijing and Ningxia Regions ]
O modelo de política a seguir pode ser usado nas regiões de Pequim e Ningxia.
------
1. Ao concluir, selecione **Review policy (Revisar política)**.
1. Insira **IDTFreeRTOSIAMPermissions**como nome da política.
1. Selecione **Criar política**.
1. Anexe **AWSIoTDeviceTesterForFreeRTOSFullo Access** à sua função do IAM.
1. Para associar as permissões necessárias ao seu perfil do IAM:
1. Na guia **Permissões**, escolha **Adicionar permissões**.
1. Escolha **Anexar políticas**.
1. Pesquise a política de **AWSIoTDeviceTesterForFreeRTOSFullacesso**. Marque a caixa.
1. Escolha **Adicionar permissões**.
1. Exporte credenciais para o IDT. Consulte [Obter credenciais de perfil do IAM para acesso à CLI](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtogetcredentials.html) para obter detalhes.
## AWS IoT Device Tester política gerenciada
A política `AWSIoTDeviceTesterForFreeRTOSFullAccess` gerenciada contém as seguintes AWS IoT Device Tester permissões para verificação de versão, recursos de atualização automática e coleção de métricas.
+ `iot-device-tester:SupportedVersion`
Concede AWS IoT Device Tester permissão para buscar a lista de produtos compatíveis, suítes de teste e versões do IDT.
+ `iot-device-tester:LatestIdt`
Concede AWS IoT Device Tester permissão para obter a versão mais recente do IDT disponível para download.
+ `iot-device-tester:CheckVersion`
Concede AWS IoT Device Tester permissão para verificar a compatibilidade de versões do IDT, suítes de teste e produtos.
+ `iot-device-tester:DownloadTestSuite`
Concede AWS IoT Device Tester permissão para baixar atualizações da suíte de testes.
+ `iot-device-tester:SendMetrics`
Concede AWS permissão para coletar métricas sobre o uso AWS IoT Device Tester interno.
## (Opcional) Instale o AWS Command Line Interface
Talvez você prefira usar o AWS CLI para realizar algumas operações. Se não tiver a AWS CLI instalada, siga as instruções em [Instalar a AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html).
Configure o AWS CLI para a AWS região que você deseja usar executando a **aws configure** partir de uma linha de comando. [Para obter informações sobre as AWS regiões que oferecem suporte ao IDT para FreeRTOS,AWS consulte Regiões e endpoints.](https://docs.aws.amazon.com/general/latest/gr/rande.html#amazon-freertos-ota-control) Para obter mais informações sobre **aws configure**, consulte [Configuração rápida com o **aws configure**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config).
# Primeiro teste da sua placa de microcontrolador
É possível usar o IDT for FreeRTOS para testar sua implementação das bibliotecas do FreeRTOS. Depois de portar as bibliotecas do FreeRTOS para os drivers de dispositivo da sua placa, AWS IoT Device Tester use para executar os testes de qualificação na sua placa microcontroladora.
## Adicionar camadas de transferência da biblioteca
Para fazer a portabilidade do FreeRTOS para seu dispositivo, consulte o [Guia de portabilidade do FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/porting-guide.html). Ao implementar o repositório de testes do FreeRTOS e portar as camadas do FreeRTOS, é preciso fornecer um `manifest.yml` com caminhos para cada biblioteca, incluindo o repositório de testes. Este arquivo estará no diretório-raiz do código-fonte. Consulte as [instruções do arquivo de manifesto](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist-manifest-instr.html) para obter detalhes.
## Configure suas AWS credenciais AWS IoT Device Tester para se comunicar com a nuvem AWS
Você precisa configurar suas AWS credenciais para se AWS IoT Device Tester comunicar com a AWS nuvem. Para obter mais informações, consulte [Configurar as credenciais e a região da AWS para desenvolvimento](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html). AWS As credenciais válidas são especificadas no arquivo `devicetester_extract_location/devicetester_freertos_[win|mac|linux]/configs/config.json` de configuração.
```
"auth": {
"method": "environment"
}
"auth": {
"method": "file",
"credentials": {
"profile": ""
}
}
```
O `auth` atributo do `config.json` arquivo tem um campo de método que controla a AWS autenticação e pode ser declarado como arquivo ou ambiente. Definir o campo como ambiente extrai suas AWS credenciais das variáveis de ambiente da sua máquina host. Definir o campo como arquivo importa um perfil especificado do arquivo de configuração `.aws/credentials`.
**Topics**
+ [Adicionar camadas de transferência da biblioteca](#lts-add-port-layer)
+ [Configure suas AWS credenciais AWS IoT Device Tester para se comunicar com a nuvem AWS](#lts-cfg-aws-afr)
+ [Crie um grupo de dispositivos no IDT para FreeRTOS](lts-cfg-dt-dp.md)
+ [Configuração de parâmetros de compilação, atualização e teste](lts-cfg-dt-ud.md)
# Crie um grupo de dispositivos no IDT para FreeRTOS
Os dispositivos a serem testados são organizados em grupos de dispositivos. Cada grupo de dispositivos consiste em um ou mais dispositivos idênticos. Também é possível configurar o IDT para FreeRTOS para testar um único dispositivo ou vários dispositivos em um grupo. Para acelerar o processo de qualificação, o IDT para FreeRTOS pode testar dispositivos com as mesmas especificações em paralelo. Ele usa o método round-robin para executar um grupo de testes diferente em cada dispositivo de um grupo de dispositivos.
O arquivo `device.json` tem uma matriz em seu nível superior. Cada recurso da matriz é um novo grupo de dispositivos. Cada grupo de dispositivos tem um recurso de matriz de dispositivos, que tem vários dispositivos declarados. No modelo, há um grupo de dispositivos e somente um dispositivo neste grupo de dispositivos. Você pode adicionar um ou mais dispositivos a um grupo de dispositivos editando a seção `devices` do modelo `device.json` na pasta `configs`.
**nota**
Todos os dispositivos no mesmo grupo devem ser da mesma especificação técnica e SKU. Para habilitar as compilações paralelas do código-fonte para diferentes grupos de teste, o IDT para FreeRTOS copia o código-fonte para uma pasta de resultados dentro da pasta onde o IDT para FreeRTOS foi extraído. É preciso referenciar o caminho do código-fonte no comando de compilação ou atualização por meio da variável `testdata.sourcePath`. O IDT para FreeRTOS substitui esta variável por um caminho temporário do código-fonte copiado. Para obter mais informações, consulte [Variáveis do IDT para FreeRTOS](lts-dt-vars.md).
Veja a seguir um exemplo do arquivo `device.json` que foi usado para criar um grupo de dispositivos com vários dispositivos.
```
[
{
"id": "pool-id",
"sku": "sku",
"features": [
{
"name": "Wifi",
"value": "Yes | No"
},
{
"name": "Cellular",
"value": "Yes | No"
},
{
"name": "BLE",
"value": "Yes | No"
},
{
"name": "PKCS11",
"value": "RSA | ECC | Both"
},
{
"name": "OTA",
"value": "Yes | No",
"configs": [
{
"name": "OTADataPlaneProtocol",
"value": "MQTT | HTTP | None"
}
]
},
{
"name": "KeyProvisioning",
"value": "Onboard | Import | Both | No"
}
],
"devices": [
{
"id": "device-id",
"connectivity": {
"protocol": "uart",
"serialPort": "/dev/tty*"
},
"secureElementConfig" : {
"publicKeyAsciiHexFilePath": "absolute-path-to/public-key-txt-file: contains-the-hex-bytes-public-key-extracted-from-onboard-private-key",
"publiDeviceCertificateArn": "arn:partition:iot:region:account-id:resourcetype:resource:qualifier",
"secureElementSerialNumber": "secure-element-serialNo-value",
"preProvisioned" : "Yes | No",
"pkcs11JITPCodeVerifyRootCertSupport": "Yes | No"
},
"identifiers": [
{
"name": "serialNo",
"value": "serialNo-value"
}
]
}
]
}
]
```
Os seguintes recursos são usados no arquivo `device.json`:
** `id` **
Um ID alfanumérico definido pelo usuário que identifica exclusivamente um grupo de dispositivos. Os dispositivos que pertencem a um grupo devem ser do mesmo tipo. Quando um conjunto de testes está em execução, os dispositivos do grupo são usados para paralelizar a carga de trabalho.
** `sku` **
Um valor alfanumérico que identifica exclusivamente a placa sendo testada. A SKU é usada para rastrear as placas qualificadas.
Se você quiser listar sua placa no AWS Partner Device Catalog, o SKU especificado aqui deve corresponder ao SKU que você usa no processo de listagem.
** `features` **
Uma matriz que contém os recursos suportados pelo dispositivo. AWS IoT Device Tester usa essas informações para selecionar os testes de qualificação a serem executados.
Os valores compatíveis são:
** `Wifi` **
Indica se a placa tem recursos de Wi-Fi.
** `Cellular` **
Indica se a placa tem recursos de celular.
** `PKCS11` **
Indica o algoritmo de criptografia de chave pública que a placa suporta. PKCS11 é necessário para a qualificação. Os valores compatíveis são `ECC`, `RSA`, e `Both`. `Both` indica que a placa é compatível com os algoritmos `ECC` e `RSA`.
** `KeyProvisioning` **
Indica o método de gravação de um certificado de cliente X.509 confiável em sua placa.
Os valores válidos são `Import`, `Onboard`, `Both` e `No`. O provisionamento das chaves `Onboard`, `Both` ou `No` é necessário para a qualificação. `Import`, por si só, não é uma opção válida para qualificação.
+ Use `Import` somente se a sua placa permitir a importação de chaves privadas. `Import`A seleção não é uma configuração válida para qualificação e deve ser usada somente para fins de teste, especificamente com casos PKCS11 de teste. `Onboard`, `Both` ou `No` é necessário para a qualificação.
+ Use `Onboard` se a placa for compatível com chaves privadas integradas (por exemplo, se o dispositivo tiver um elemento seguro ou se você preferir gerar o seu próprio par de chaves de dispositivo e certificado). Adicione um elemento `secureElementConfig` em cada uma das seções do dispositivo e coloque o caminho absoluto para o arquivo de chave pública no campo `publicKeyAsciiHexFilePath`.
+ Use `Both` se sua placa suportar a importação de chaves privadas e a geração de chaves integradas para provisionamento de chaves.
+ Use `No` se sua placa não suportar o provisionamento de chaves. `No` só é uma opção válida quando seu dispositivo também está pré-provisionado.
** `OTA` **
Indica se sua placa suporta a funcionalidade de atualização over-the-air (OTA). O recurso `OtaDataPlaneProtocol` indica a qual protocolo de plano de dados OTA o dispositivo oferece suporte. Um OTA com o protocolo de plano de dados HTTP ou MQTT é necessário para a qualificação. Para pular a execução de testes OTA durante o teste, defina o recurso OTA como `No` e o recurso `OtaDataPlaneProtocol` como `None`. Esta não será uma corrida de qualificação.
** `BLE` **
Indica se a placa é compatível com Bluetooth Low Energy (BLE).
** `devices.id` **
Um identificador exclusivo, definido pelo usuário, para o dispositivo que está sendo testado.
** `devices.connectivity.serialPort` **
A porta serial do computador host usada para se conectar aos dispositivos que estão sendo testados.
** `devices.secureElementConfig.PublicKeyAsciiHexFilePath` **
Obrigatório se sua placa NÃO for `pre-provisioned` ou `PublicDeviceCertificateArn` não for fornecido. Como `Onboard` é um tipo obrigatório de provisionamento de chaves, esse campo atualmente é obrigatório para o grupo de FullTransportInterface teste TLS. Se o seu dispositivo for `pre-provisioned`, `PublicKeyAsciiHexFilePath` é opcional e não precisa ser incluído.
O bloco a seguir é um caminho absoluto para o arquivo que contém a chave pública de bytes hexadecimal extraída da chave privada `Onboard`.
```
3059 3013 0607 2a86 48ce 3d02 0106 082a
8648 ce3d 0301 0703 4200 04cd 6569 ceb8
1bb9 1e72 339f e8cf 60ef 0f9f b473 33ac
6f19 1813 6999 3fa0 c293 5fae 08f1 1ad0
41b7 345c e746 1046 228e 5a5f d787 d571
dcb2 4e8d 75b3 2586 e2cc 0c
```
Se sua chave pública estiver no formato .der, é possível codificar a chave pública em hexadecimal diretamente para gerar o arquivo hexadecimal.
Para gerar o arquivo hexadecimal a partir de uma chave pública .der, digite o seguinte comando **xxd**:
```
xxd -p pubkey.der > outFile
```
Se sua chave pública estiver no formato .pem, é possível extrair os cabeçalhos e rodapés codificados em base64 e decodificá-los em formato binário. Em seguida, string binária é codificada em hexadecimal para gerar o arquivo hexadecimal.
Para gerar um arquivo hexadecimal para uma chave pública. pem, faça o seguinte:
1. Execute o comando **base64** a seguir para remover o cabeçalho e o rodapé base64 da chave pública. A chave decodificada, chamada `base64key`, é enviada para o arquivo `pubkey.der`:
```
base64 —decode base64key > pubkey.der
```
1. Execute o comando **xxd** a seguir para converter `pubkey.der` para o formato hexadecimal. A chave resultante é salva como `outFile`.
```
xxd -p pubkey.der > outFile
```
** `devices.secureElementConfig.PublicDeviceCertificateArn` **
O ARN do certificado do seu elemento seguro que é carregado para. AWS IoT Core*Para obter informações sobre como carregar seu certificado para AWS IoT Core, consulte [certificados de cliente X.509 no Guia](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html) do AWS IoT desenvolvedor.*
** `devices.secureElementConfig.SecureElementSerialNumber` **
(Opcional) O número de série do elemento seguro. O número de série é usado como opção para criar certificados de dispositivo para o provisionamento de chaves JITR.
** `devices.secureElementConfig.preProvisioned` **
(Opcional) Defina como "Sim" se o dispositivo tiver um elemento seguro pré-provisionado com credenciais bloqueadas, que não possa importar, criar ou destruir objetos. Se este recurso for definido como **Sim**, os rótulos pkcs11 correspondentes deverão ser fornecidos.
** `devices.secureElementConfig.pkcs11JITPCodeVerifyRootCertSupport` **
(Opcional) Defina como **Sim** se a PKCS11 implementação principal do dispositivo suportar armazenamento para JITP. Isto habilitará o teste `codeverify` JITP ao testar o PKCS 11 principal e exigirá que sejam fornecidos rótulos de chave de verificação de código, certificado JITP e certificado raiz PKCS 11.
** `identifiers` **
(Opcional) Uma matriz de pares de nome-valor arbitrários. Você pode usar esses valores nos comandos de compilação e atualização descritos na próxima seção.
# Configuração de parâmetros de compilação, atualização e teste
O IDT para FreeRTOS compila e atualiza os testes automaticamente em sua placa. Para habilitar isso, é preciso configurar o IDT para executar os comandos compilar e atualizar do seu hardware. As configurações de comando de compilação e atualização são definidas no modelo de arquivo `userdata.json` localizado na pasta `config`.
# Configuração de parâmetros para testar dispositivos
As configurações de compilação, atualização e teste são feitas no arquivo `configs/userdata.json`. O seguinte exemplo de JSON mostra como é possível configurar o IDT para FreeRTOS para testar vários dispositivos:
```
{
"sourcePath": "",
"retainModifiedSourceDirectories": true | false,
"freeRTOSVersion": "",
"freeRTOSTestParamConfigPath": "{{testData.sourcePath}}/path/from/source/path/to/test_param_config.h",
"freeRTOSTestExecutionConfigPath": "{{testData.sourcePath}}/path/from/source/path/to/test_execution_config.h",
"buildTool": {
"name": "your-build-tool-name",
"version": "your-build-tool-version",
"command": [
" -any-additional-flags {{testData.sourcePath}}"
]
},
"flashTool": {
"name": "your-flash-tool-name",
"version": "your-flash-tool-version",
"command": [
" -any-additional-flags {{testData.sourcePath}} -any-additional-flags"
]
},
"testStartDelayms": 0,
"echoServerConfiguration": {
"keyGenerationMethod": "EC | RSA",
"serverPort": 9000
},
"otaConfiguration": {
"otaE2EFirmwarePath": "{{testData.sourcePath}}/relative-path-to/ota-image-generated-in-build-process",
"otaPALCertificatePath": "/path/to/ota/pal/certificate/on/device",
"deviceFirmwarePath" : "/path/to/firmware/image/name/on/device",
"codeSigningConfiguration": {
"signingMethod": "AWS | Custom",
"signerHashingAlgorithm": "SHA1 | SHA256",
"signerSigningAlgorithm": "RSA | ECDSA",
"signerCertificate": "arn:partition:service:region:account-id:resource:qualifier | /absolute-path-to/signer-certificate-file",
"untrustedSignerCertificate": "arn:partition:service:region:account-id:resourcetype:resource:qualifier",
"signerCertificateFileName": "signerCertificate-file-name",
"compileSignerCertificate": true | false,
// ***********Use signerPlatform if you choose AWS for signingMethod***************
"signerPlatform": "AmazonFreeRTOS-Default | AmazonFreeRTOS-TI-CC3220SF"
]
}
},
**********
This section is used for PKCS #11 labels of private key, public key, device certificate, code verification key, JITP certificate, and root certificate.
When configuring PKCS11, you set up labels and you must provide the labels of the device certificate, public key,
and private key for the key generation type (EC or RSA) it was created with. If your device supports PKCS11 storage of JITP certificate,
code verification key, and root certificate, set 'pkcs11JITPCodeVerifyRootCertSupport' to 'Yes' in device.json and provide the corresponding labels.
**********
"pkcs11LabelConfiguration":{
"pkcs11LabelDevicePrivateKeyForTLS": "",
"pkcs11LabelDevicePublicKeyForTLS": "",
"pkcs11LabelDeviceCertificateForTLS": "",
"pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS": "",
"pkcs11LabelPreProvisionedECDevicePublicKeyForTLS": "",
"pkcs11LabelPreProvisionedECDeviceCertificateForTLS": "",
"pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS": "",
"pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS": "",
"pkcs11LabelPreProvisionedRSADeviceCertificateForTLS": "",
"pkcs11LabelCodeVerifyKey": "",
"pkcs11LabelJITPCertificate": "",
"pkcs11LabelRootCertificate": ""
}
}
```
Veja a seguir uma lista dos recursos usados no `userdata.json`:
** `sourcePath` **
O caminho para a raiz do código-fonte transferido do FreeRTOS.
** `retainModifiedSourceDirectories` **
(Opcional) Verifica se deve reter os diretórios de origem modificados usados durante a compilação e a atualização para fins de depuração. Se definido como `true`, os diretórios de origem modificados são denominados RetainedSrc e são encontrados nas pastas de log de resultados em cada execução do grupo de teste. Se não for incluído, o campo assume `false` como padrão.
** `freeRTOSTestParamConfigPath` **
O caminho para o `test_param_config.h` arquivo para FreeRTOS-Libraries-Integration-Tests integração. Esse arquivo deve usar a variável de `{{testData.sourcePath}}` espaço reservado para torná-lo relativo à raiz do código-fonte. AWS IoT Device Tester usa os parâmetros desse arquivo para configurar os testes.
** `freeRTOSTestExecutionConfigPath` **
O caminho para o `test_execution_config.h` arquivo para FreeRTOS-Libraries-Integration-Tests integração. Esse arquivo deve usar a variável de `{{testData.sourcePath}}` espaço reservado para torná-lo relativo à raiz do repositório. AWS IoT Device Tester usa esse arquivo para controlar quais testes devem ser executados.
** `freeRTOSVersion` **
A versão dos FreeRTOS, incluindo a versão do patch usada em sua implementação. Consulte [Versões suportadas do FreeRTOS AWS IoT Device Tester para as versões do](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html) FreeRTOS compatíveis com o FreeRTOS. AWS IoT Device Tester
** `buildTool` **
O comando para compilar o código-fonte. Todas as referências ao caminho do código-fonte no comando build devem ser substituídas pela AWS IoT Device Tester variável`{{testData.sourcePath}}`. Use o `{{config.idtRootPath}}` espaço reservado para referenciar um script de construção em relação ao caminho AWS IoT Device Tester raiz.
** `flashTool` **
O comando para exibir uma imagem em seu dispositivo. Todas as referências ao caminho do código-fonte no comando f.ash devem ser substituídas pela AWS IoT Device Tester variável`{{testData.sourcePath}}`. Use o `{{config.idtRootPath}}` espaço reservado para referenciar um script flash em relação ao caminho AWS IoT Device Tester raiz.
A nova estrutura de testes de integração com o FRQ 2.0 não requer variáveis de caminho como `{{enableTests}}` e `{{buildImageName}}`. Os testes OTA End to End são executados com os modelos de configuração fornecidos no [ FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests/blob/main/config_template/) GitHub repositório. Se os arquivos no GitHub repositório estiverem presentes no seu projeto fonte principal, o código-fonte não será alterado entre os testes. Se for necessária uma imagem de compilação diferente para o OTA End to End, esta imagem deverá ser criada no script de compilação e especificada no arquivo `userdata.json` especificado abaixo `otaConfiguration`.
** `testStartDelayms` **
Especifica quantos milissegundos o executor de testes do FreeRTOS aguardará antes de começar a executar os testes. Isto pode ser útil se o dispositivo em teste começar a gerar informações de teste importantes antes que o IDT tenha a chance de se conectar e iniciar o registro em log devido à rede ou outros problemas de latência. Este valor é aplicável somente aos grupos de teste do FreeRTOS, e não a outros grupos de teste que não utilizam o executor de testes do FreeRTOS, como os testes OTA. Se receber um erro relacionado a **10 esperados, mas cinco recebidos**, este campo deverá ser definido como 5.000.
** `echoServerConfiguration` **
A configuração para configurar o servidor de eco para o teste TLS. Este campo é obrigatório.
** `keyGenerationMethod` **
O servidor echo está configurado com esta opção. As opções são EC ou RSA.
** `serverPort` **
O número da porta na qual o servidor echo é executado.
** `otaConfiguration` **
A configuração para testes OTA PAL e OTA E2E. Este campo é obrigatório.
**`otaE2EFirmwarePath`**
O caminho para a imagem do compartimento OTA que o IDT usa para os testes do OTA End to End.
** `otaPALCertificatePath` **
O caminho para o certificado para o teste OTA PAL no dispositivo. Isto é usado para verificar a assinatura. Por exemplo, **ecdsa-sha256-signer.crt.pem**.
** `deviceFirmwarePath` **
O caminho para o nome com codificação rígida da imagem do firmware a ser inicializada. Se o seu dispositivo NÃO usar o sistema de arquivos para inicialização do firmware, especifique este campo como `'NA'`. Se o seu dispositivo usa o sistema de arquivos para inicialização do firmware, especifique o caminho ou o nome da imagem de inicialização do firmware.
** `codeSigningConfiguration` **
** `signingMethod` **
O método de assinatura de código. Os valores possíveis são AWS ou Custom.
Para as regiões de Pequim e Ningxia, use Personalizado. AWS a assinatura de código não é suportada nessa região.
** `signerHashingAlgorithm` **
O algoritmo de hash ao qual o dispositivo oferece suporte. Os valores possíveis são `SHA1` ou `SHA256`.
** `signerSigningAlgorithm` **
O algoritmo de assinatura ao qual o dispositivo oferece suporte. Os valores possíveis são `RSA` ou `ECDSA`.
** `signerCertificate` **
O certificado de confiança usado para OTA. Para o método de assinatura de AWS código, use o Amazon Resource Name (ARN) para o certificado confiável carregado no AWS Certificate Manager. Para o método de assinatura de código personalizado, use o caminho absoluto para o arquivo de certificado do assinante. Para obter mais informações sobre como criar um certificado confiável, consulte [Criar um certificado de assinatura de código](https://docs.aws.amazon.com/freertos/latest/userguide/ota-code-sign-cert.html).
** `untrustedSignerCertificate` **
O ARN ou caminho de arquivo de um segundo certificado usado em alguns testes OTA como um certificado não confiável. Para obter informações sobre como criar um certificado, consulte [Criar um certificado de assinatura de código](https://docs.aws.amazon.com//freertos/latest/userguide/ota-code-sign-cert.html).
** `signerCertificateFileName` **
O nome do arquivo do certificado de assinatura de código no dispositivo. Este valor deve corresponder ao nome do arquivo fornecido ao executar o comando `aws acm import-certificate`.
** `compileSignerCertificate` **
Valor booleano que determina o status do certificado de verificação de assinatura. Os valores válidos são `true` e `false`.
Defina este valor como **verdadeiro** se o certificado de verificação da assinatura do signatário do código não for provisionado ou exibido. Ele deve ser compilado no projeto. AWS IoT Device Tester busca o certificado confiável e o compila em. `aws_codesigner_certificate.h`
** `signerPlatform` **
O algoritmo de assinatura e hashing que o AWS Code Signer usa ao criar o trabalho de atualização do OTA. Atualmente, os valores possíveis para este campo são `AmazonFreeRTOS-TI-CC3220SF` e `AmazonFreeRTOS-Default`.
+ Escolha `AmazonFreeRTOS-TI-CC3220SF` se `SHA1` e `RSA`.
+ Escolha `AmazonFreeRTOS-Default` se `SHA256` e `ECDSA`.
+ Se você precisar de `SHA256` \$1 `RSA` ou `SHA1` \$1 `ECDSA` para sua configuração, entre em contato conosco para obter mais suporte.
+ Configure `signCommand` se você escolheu `Custom` para `signingMethod`.
** `signCommand` **
Dois espaços reservados `{{inputImageFilePath}}` e `{{outputSignatureFilePath}}` são necessários no comando. `{{inputImageFilePath}}` é o caminho do arquivo da imagem criada pelo IDT a ser assinado. `{{outputSignatureFilePath}} ` é o caminho do arquivo da assinatura que será gerado pelo script.
** `pkcs11LabelConfiguration` **
PKCS11 a configuração do rótulo requer pelo menos um conjunto de rótulos de rótulo de certificado de dispositivo, rótulo de chave pública e rótulo de chave privada para executar os grupos de PKCS11 teste. As PKCS11 etiquetas necessárias são baseadas na configuração do dispositivo no `device.json` arquivo. Se pré-provisionado estiver definido como **Sim** em`device.json`, os rótulos necessários deverão ser um dos abaixo, dependendo do que for escolhido para o recurso. PKCS11
+ `PreProvisionedEC`
+ `PreProvisionedRSA`
Se pré-provisionado estiver definido como **Não** em `device.json`, os rótulos necessários serão:
+ `pkcs11LabelDevicePrivateKeyForTLS`
+ `pkcs11LabelDevicePublicKeyForTLS`
+ `pkcs11LabelDeviceCertificateForTLS`
Os três rótulos a seguir são necessários somente se você selecionar **Sim** para `pkcs11JITPCodeVerifyRootCertSupport` em seu arquivo `device.json`.
+ `pkcs11LabelCodeVerifyKey`
+ `pkcs11LabelRootCertificate`
+ `pkcs11LabelJITPCertificate`
Os valores desses campos devem corresponder aos valores definidos no [Guia de portabilidade do FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-pkcs.html).
** `pkcs11LabelDevicePrivateKeyForTLS` **
(Opcional) Este rótulo é usado para o rótulo PKCS n.º 11 da chave privada. Para dispositivos com suporte integrado e de importação de provisionamento de chaves, este rótulo é usado para testes. Este rótulo pode ser diferente daquele definido para o caso pré-provisionado. Se tiver o provisionamento de chaves definido como **Não** e o pré-provisionado definido como **Sim**, em `device.json`, isso será indefinido.
** `pkcs11LabelDevicePublicKeyForTLS` **
(Opcional) Este rótulo é usado para o rótulo PKCS n.º 11 da chave pública. Para dispositivos com suporte integrado e de importação de provisionamento de chaves, este rótulo é usado para testes. Este rótulo pode ser diferente do definido para o caso pré-provisionado. Se tiver o provisionamento de chaves definido como **Não** e o pré-provisionado definido como **Sim**, em `device.json`, isso será indefinido.
** `pkcs11LabelDeviceCertificateForTLS` **
(Opcional) Este rótulo é usado para o rótulo PKCS n.º 11 do certificado do dispositivo. Para dispositivos com suporte integrado e de importação de provisionamento de chaves, este rótulo será usado para testes. Este rótulo pode ser diferente do definido para o caso pré-provisionado. Se tiver o provisionamento de chaves definido como **Não** e o pré-provisionado definido como **Sim**, em `device.json`, isso será indefinido.
** `pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS` **
(Opcional) Este rótulo é usado para o rótulo PKCS n.º 11 da chave privada. Para dispositivos com elementos seguros ou limitações de hardware, isso terá uma etiqueta diferente para preservar AWS IoT as credenciais. Se o seu dispositivo for compatível com o pré-provisionamento com uma chave EC, forneça este rótulo. Quando PreProvisioned é definido como **Sim** em `device.json`, este rótulo, `pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS`, ou ambos devem ser fornecidos. Este rótulo pode ser diferente do definido para caixas integradas e de importação.
** `pkcs11LabelPreProvisionedECDevicePublicKeyForTLS` **
(Opcional) Este rótulo é usado para o rótulo PKCS n.º 11 da chave pública. Para dispositivos com elementos seguros ou limitações de hardware, isso terá uma etiqueta diferente para preservar AWS IoT as credenciais. Se o seu dispositivo for compatível com o pré-provisionamento com uma chave EC, forneça este rótulo. Quando PreProvisioned é definido como **Sim** em `device.json`, este rótulo, `pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS`, ou ambos devem ser fornecidos. Este rótulo pode ser diferente do definido para caixas integradas e de importação.
** `pkcs11LabelPreProvisionedECDeviceCertificateForTLS` **
(Opcional) Este rótulo é usado para o rótulo PKCS n.º 11 do certificado do dispositivo. Para dispositivos com elementos seguros ou limitações de hardware, isso terá uma etiqueta diferente para preservar AWS IoT as credenciais. Se o seu dispositivo for compatível com o pré-provisionamento com uma chave EC, forneça este rótulo. Quando PreProvisioned é definido como **Sim** em `device.json`, este rótulo, `pkcs11LabelPreProvisionedRSADeviceCertificateForTLS`, ou ambos devem ser fornecidos. Este rótulo pode ser diferente do definido para caixas integradas e de importação.
** `pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS` **
(Opcional) Este rótulo é usado para o rótulo PKCS n.º 11 da chave privada. Para dispositivos com elementos seguros ou limitações de hardware, isso terá uma etiqueta diferente para preservar AWS IoT as credenciais. Se o seu dispositivo for compatível com o pré-provisionamento com uma chave RSA, forneça este rótulo. Quando PreProvisioned é definido como **Sim** em `device.json`, este rótulo, `pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS`, ou ambos devem ser fornecidos.
** `pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS` **
(Opcional) Este rótulo é usado para o rótulo PKCS n.º 11 da chave pública. Para dispositivos com elementos seguros ou limitações de hardware, isso terá uma etiqueta diferente para preservar AWS IoT as credenciais. Se o seu dispositivo for compatível com o pré-provisionamento com uma chave RSA, forneça este rótulo. Quando PreProvisioned é definido como **Sim** em `device.json`, este rótulo, `pkcs11LabelPreProvisionedECDevicePublicKeyForTLS`, ou ambos devem ser fornecidos.
** `pkcs11LabelPreProvisionedRSADeviceCertificateForTLS` **
(Opcional) Este rótulo é usado para o rótulo PKCS n.º 11 do certificado do dispositivo. Para dispositivos com elementos seguros ou limitações de hardware, isso terá uma etiqueta diferente para preservar AWS IoT as credenciais. Se o seu dispositivo for compatível com o pré-provisionamento com uma chave RSA, forneça este rótulo. Quando PreProvisioned é definido como **Sim** em `device.json`, este rótulo, `pkcs11LabelPreProvisionedECDeviceCertificateForTLS`, ou ambos devem ser fornecidos.
** `pkcs11LabelCodeVerifyKey` **
(Opcional) Este rótulo é usado para o rótulo PKCS n.º 11 da chave de verificação de código. Se o seu dispositivo tiver suporte de armazenamento PKCS n.º 11 para o certificado JITP, a chave de verificação de código e o certificado-raiz, forneça este rótulo. Quando `pkcs11JITPCodeVerifyRootCertSupport` em `device.json` estiver definido como **Sim**, este rótulo deverá ser fornecido.
** `pkcs11LabelJITPCertificate` **
(Opcional) Este rótulo é usado para o rótulo PKCS n.º 11 do certificado JITP. Se o seu dispositivo tiver suporte de armazenamento PKCS n.º 11 para o certificado JITP, a chave de verificação de código e o certificado-raiz, forneça este rótulo. Quando `pkcs11JITPCodeVerifyRootCertSupport` em `device.json` estiver definido como **Sim**, este rótulo deverá ser fornecido.
# Variáveis do IDT para FreeRTOS
Os comandos para criar seu código e atualizar o dispositivo podem exigir conectividade ou outras informações sobre seus dispositivos para serem executados com êxito. AWS IoT Device Tester permite referenciar informações do dispositivo em flash e criar comandos usando [JsonPath](https://goessner.net/articles/JsonPath/)o. Usando JsonPath expressões simples, você pode buscar as informações necessárias especificadas em seu `device.json` arquivo.
## Variáveis de caminho
O IDT para FreeRTOS define as seguintes variáveis de caminho que podem ser usadas em linhas de comando e arquivos de configuração:
** `{{testData.sourcePath}}` **
Expande o caminho do código-fonte. Se você usar essa variável, ela deverá ser usada nos comandos de compilação e atualização.
** `{{device.connectivity.serialPort}}` **
Expande à porta serial.
** `{{device.identifiers[?(@.name == 'serialNo')].value[0]}}` **
Expande o número de série do dispositivo.
** `{{config.idtRootPath}}` **
Expande-se até o caminho AWS IoT Device Tester raiz.
# Interface do usuário para o IDT para o pacote de qualificação FreeRTOS 2.0 (FRQ 2.0)
AWS IoT Device Tester para FreeRTOS (IDT for FreeRTOS) inclui uma interface de usuário (UI) baseada na web na qual você pode interagir com o aplicativo de linha de comando do IDT e os arquivos de configuração relacionados. Você usa a interface do IDT para FreeRTOS para criar uma nova configuração ou modificar uma existente para seu dispositivo. Você também pode usar a interface do usuário para chamar a aplicação IDT e executar os testes do FreeRTOS em seu dispositivo.
Para obter informações sobre o uso da linha de comando para executar os testes de qualificação, consulte [Primeiro teste da sua placa de microcontrolador](lts-qual-steps.md).
Esta seção descreve os pré-requisitos da interface do usuário do IDT para FreeRTOS e como executar testes de qualificação a partir da interface do usuário.
**Topics**
+ [Configurar os pré-requisitos do IDT](#lts-dev-tester-ui-prereqs)
+ [Configurar AWS credenciais para usar a interface de usuário do IDT](lts-configure-aws-credentials.md)
+ [Abrir a interface de usuário do IDT para FreeRTOS](lts-open-idt-ui.md)
+ [Criar uma configuração](lts-create-new-configuration.md)
+ [Modificar uma configuração existente](lts-modify-existing-configuration.md)
+ [Execute testes de qualificação](lts-run-tests-from-ui.md)
## Configurar os pré-requisitos do IDT
Para executar testes por meio da interface do usuário AWS IoT Device Tester (IDT) for FreeRTOS, você deve preencher os pré-requisitos na página do IDT FreeRTOS Qualification ([Configurar os pré-requisitos de qualificação LTS](lts-idt-dev-tester-prereqs.md)FRQ) 2.x.
# Configurar AWS credenciais para usar a interface de usuário do IDT
Você deve configurar suas credenciais de usuário do IAM para o AWS usuário que você criou. [Crie uma AWS conta](lts-idt-dev-tester-prereqs.md#lts-config-aws-account) Você pode especificar suas credenciais de uma das seguintes formas:
+ Em um arquivo de credenciais
+ Como 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ê usa:
+ **macOS e Linux** – `~/.aws/credentials`
+ **Windows**: `C:\Users\UserName\.aws\credentials`
Adicione suas AWS credenciais ao `credentials` arquivo no seguinte formato:
```
[default]
aws_access_key_id = your_access_key_id
aws_secret_access_key = your_secret_access_key
```
**nota**
Se você não usar o `default` AWS perfil, deverá especificar o nome do perfil na interface de usuário do IDT para Freertos. Para obter mais informações sobre perfis, consulte [Configurações de arquivos de configuração e credenciais](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.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 são salvas se você fechar a sessão SSH. A interface de usuário do IDT para FreeRTOS usa as variáveis de ambiente `AWS_SECRET_ACCESS_KEY` e `AWS_ACCESS_KEY_ID` para armazenar suas credenciais. AWS
Para definir essas variáveis no Linux, macOS ou Unix, use :**export**
```
export AWS_ACCESS_KEY_ID=your_access_key_id
export AWS_SECRET_ACCESS_KEY=your_secret_access_key
```
Para definir essas variáveis no Windows, use :**set**
```
set AWS_ACCESS_KEY_ID=your_access_key_id
set AWS_SECRET_ACCESS_KEY=your_secret_access_key
```
# Abrir a interface de usuário do IDT para FreeRTOS
Este tópico explica como abrir a interface de usuário do IDT para FreeRTOS para usar o pacote de qualificações do FreeRTOS.
**Como abrir a interface de usuário do IDT para FreeRTOS**
1. Baixe um IDT compatível para a versão do FreeRTOS. Em seguida, extraia o arquivo baixado em um diretório para o qual você tenha permissões de leitura e gravação.
1. Navegue até o diretório da instalação do IDT para FreeRTOS:
```
cd devicetester-extract-location/bin
```
1. Execute o comando a seguir para abrir a interface de usuário do IDT para FreeRTOS:
------
#### [ Linux ]
```
.devicetester_ui_linux_x86-64
```
------
#### [ Windows ]
```
./devicetester_ui_win_x64-64
```
------
#### [ macOS ]
```
./devicetester_ui_mac_x86-64
```
**nota**
No macOS, para permitir que seu sistema execute a interface do usuário, acesse **Preferências do sistema -> Segurança e privacidade**. Ao executar os testes, é aconselhável repeti-lo três vezes.
------
A interface de usuário do IDT para FreeRTOS é aberta em seu navegador padrão. As três versões principais mais recentes dos seguintes navegadores são compatíveis com a interface do usuário:
+ Google Chrome
+ Mozilla Firefox
+ Microsoft Edge
+ Apple Safari para macOS
**nota**
Para obter uma melhor experiência, recomendamos o Google Chrome ou o Mozilla Firefox para acessar a interface de usuário do IDT para FreeRTOS. O Microsoft Internet Explorer não é compatível com a interface do usuário.
**Importante**
Você deve configurar suas AWS credenciais antes de abrir a interface do usuário. Se você não configurou suas credenciais, feche a janela do navegador da interface de usuário do IDT para FreeRTOS, siga as etapas em [Configurar AWS credenciais para usar a interface de usuário do IDT](lts-configure-aws-credentials.md) e reabra a interface de usuário do IDT para FreeRTOS.
# Criar uma configuração
Se você for um usuário iniciante, deverá criar uma nova configuração para definir os arquivos de configuração JSON que o IDT para FreeRTOS exige para executar testes. Em seguida, você pode executar testes ou modificar a configuração criada.
Para obter exemplos dos arquivos `config.json`, `device.json` e `userdata.json`, consulte [Primeiro teste da sua placa de microcontrolador](lts-qual-steps.md).
**Como criar uma configuração**
1. Na interface de usuário do IDT para FreeRTOS, abra o menu de navegação e escolha **Criar nova configuração**.
![\[Device Tester para interface do FreeRTOS com botão "Criar configuração" e informações sobre autoteste automatizado de microcontroladores.\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/images/gsg-create-configuration.png)
1. Siga o assistente de configuração para inserir as configurações do IDT usadas para executar os testes de qualificação. O assistente define as seguintes configurações nos arquivos de configuração JSON localizados no diretório `devicetester-extract-location/config`.
+ **Configurações de dispositivos**: as configurações do grupo de dispositivos para os dispositivos a serem testados. Essas configurações são definidas nos campos `id` e `sku` no bloco do grupo de **dispositivos** no arquivo `config.json`.
![\[Tela de configuração do Device Tester para o FreeRTOS com campos de identificador e SKU para configurar um pool de dispositivos, opções de configurações do dispositivo como método de conectividade, provisionamento de chave, configurações PKCS #11, campos de entrada de detalhes do dispositivo e controles para adicionar dispositivos ou identificadores.\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/images/gsg-device-settings.png)
+ **AWS configurações da conta** — As Conta da AWS informações que o IDT para FreeRTOS usa para AWS criar recursos durante as execuções de teste. Essas configurações são definidas no arquivo `config.json`.
![\[Conta da AWS página de configurações com campos para região da conta, localização das credenciais como arquivo ou ambiente e nome do perfil\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/images/gsg-account-settings.png)
+ **Implementação do FreeRTOS**: o caminho absoluto para o repositório e o código transferido do FreeRTOS e a versão do FreeRTOS na qual você deseja executar o FRQ do IDT. Os caminhos para os arquivos de cabeçalho de configuração de execução e parâmetros do `FreeRTOS-Libraries-Integration-Tests` GitHub repositório. Compilar e instalar: os comandos para seu hardware que permitem que o IDT compile e instale testes em sua placa automaticamente. Essas configurações são definidas no arquivo `userdata.json`.
![\[Seção de configuração da implementação do FreeRTOS com caminhos de repositório, caminhos de execução de testes, versão do FreeRTOS, detalhes da ferramenta de compilação e configurações da ferramenta de gravação em flash.\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/images/gsg-implementation-settings.png)
+ **Rótulos PKCS \$111 e servidor echo**: os rótulos [PKCS \$111](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-pkcs.html) que correspondem às chaves provisionadas em seu hardware com base na funcionalidade e no método de provisionamento de chaves. As configurações do servidor echo para os testes da Interface de transporte. Essas configurações são definidas nos arquivos `userdata.json` e `device.json`.
![\[Rótulos PKCS #11 e configurações do servidor Echo com campos de entrada para rótulos de chave, método de geração de chave e número da porta do servidor\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/images/gsg-pkcs11-settings.png)
+ **Over-the-air Atualizações (OTA) — As** configurações que controlam os testes de funcionalidade OTA. Essas configurações são definidas no bloco `features` dos arquivos `device.json` e `userdata.json`.
![\[Opções de configuração de atualização do OTA: ignorar testes, protocolos de dados, caminhos de firmware, caminho do certificado PAL, assinatura de código, hash/sign algoritmos, certificados do assinante, arquivo do certificado do trusted/untrusted assinante, compilar certificado do assinante, plataforma do assinante.\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/images/gsg-ota-settings.png)
1. Na página **Revisar**, verifique suas informações de configuração.
![\[Caixa de diálogo de configuração criada para o Device Tester para o FreeRTOS, mostrando detalhes sobre a criação de uma configuração de teste com opções para editar ou executar testes.\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/images/gsg-configuration-created.png)
Depois de concluir a revisão da configuração, para executar os testes de qualificação, escolha **Executar testes**.
# Modificar uma configuração existente
Se você já configurou arquivos de configuração do IDT para FreeRTOS, você pode usar a interface de usuário do IDT para FreeRTOS para modificar sua configuração existente. Os arquivos de configuração existentes devem estar localizados no diretório `devicetester-extract-location/config`.
**Como criar uma configuração**
1. Na interface de usuário do IDT para FreeRTOS, abra o menu de navegação e escolha **Editar configuração existente**.
O painel de configuração exibe informações sobre suas configurações existentes. Se uma configuração estiver incorreta ou indisponível, o status dessa configuração será `Error validating configuration`.
![\[Tela de configuração com seções de dispositivo Conta da AWS, implementação de FreeRTOS, rótulos PKCS e servidor de eco over-the-air, atualizações e configurações de execução de teste mostrando status válido.\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/images/modify-existing-configuration.png)
1. Para modificar uma configuração existente, conclua estas etapas:
1. Escolha o nome de uma configuração para abrir sua página de ajustes.
1. Modifique as configurações e escolha **Salvar** para regenerar o arquivo de configuração correspondente.
1. Para modificar as configurações de execução de teste do IDT para FreeRTOS, escolha as **configurações de execução de teste do IDT** na visualização de edição:
![\[Caixa de diálogo de configurações de execução de testes do IDT com opções para seleção de testes, ignorar grupos de testes, multiplicador de tempo limite e interrupção na primeira falha.\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/images/idt-testrun-settings.png)
Depois de concluir a modificação da configuração, verifique se todas as configurações passaram pela validação. Se o status de cada configuração for `Valid`, será possível executar seus testes de qualificação com essa configuração.
# Execute testes de qualificação
Após criar uma configuração para a interface de usuário do IDT para FreeRTOS, é possível executar os testes de qualificação.
**Como executar testes de qualificação**
1. No menu de navegação, escolha **Executar testes**.
1. Escolha **Iniciar testes** para iniciar a execução do teste. Por padrão, todos os testes aplicáveis são executados para a configuração do seu dispositivo. O IDT para FreeRTOS gera um relatório de qualificação quando todos os testes terminam.
![\[A interface do Device Tester para FreeRTOS mostra que nenhum teste foi executado ainda, com opções para criar uma configuração, editar uma configuração existente e executar testes.\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/images/idt-run-tests.png)
O IDT para FreeRTOS executa os testes de qualificação. Em seguida, ele exibe o resumo da execução do teste e todos os erros no console do **Executor de teste**. Depois que a execução do teste for concluída, você poderá visualizar os resultados e os logs do teste nos seguintes locais:
+ Os resultados dos testes estão localizados no diretório `devicetester-extract-location/results/execution-id`.
+ Os logs de teste estão localizados no diretório `devicetester-extract-location/results/execution-id/logs`.
Para obter mais informações sobre os resultados de teste e logs, consulte [Veja o IDT gratuitamente RTOSresults](view-results-lts.md) e [Veja o IDT gratuitamente RTOSlogs](view-logs-lts.md).
![\[Log de execução do Device Tester para FreeRTOS exibindo testes aprovados, grupos de testes e caminhos dos arquivos de log e relatórios.\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/images/idt-results.png)
# Executar o pacote de qualificação do FreeRTOS 2.0
Use o executável AWS IoT Device Tester for FreeRTOS para interagir com o IDT for FreeRTOS. Os exemplos de linha de comando a seguir mostram como executar os testes de qualificação para um grupo de dispositivos (um conjunto de dispositivos idênticos).
------
#### [ IDT v4.5.2 and later ]
```
devicetester_[linux | mac | win] run-suite \
--suite-id suite-id \
--group-id group-id \
--pool-id your-device-pool \
--test-id test-id \
--userdata userdata.json
```
Executa um conjunto de testes em um grupo de dispositivos. O arquivo `userdata.json` deve estar localizado no diretório `devicetester_extract_location/devicetester_freertos_[win|mac|linux]/configs/`.
**nota**
Se estiver executando o IDT para FreeRTOS no Windows, use barras (/) para especificar o caminho até o arquivo `userdata.json`.
Use o seguinte comando para executar um grupo de testes específico:
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1.99.0 \
--group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
Os parâmetros `suite-id` e `pool-id` são opcionais se você estiver executando um único conjunto de testes em um único grupo de dispositivos (ou seja, você tem apenas um grupo de dispositivos definido no arquivo `device.json`).
Use o seguinte comando para executar um caso de teste em um grupo de testes:
```
devicetester_[linux | mac | win_x86-64] run-suite \
--group-id group-id \
--test-id test-id
```
Você pode usar o comando `list-test-cases` para listar os casos de teste em um grupo de testes.
**Opções de linhas de comando do IDT para FreeRTOS**
**group-id**
(Opcional) Os grupos de testes a serem executados, como uma lista separada por vírgulas. Se não for especificado, o IDT executará todos os grupos de testes no conjunto de testes.
**pool-id**
(Opcional) O grupo de dispositivos a ser testado. Isso será necessário se você definir vários grupos de dispositivos no `device.json`. Se você tiver apenas um grupo de dispositivos, poderá omitir essa opção.
**suite-id**
(Opcional) A versão do conjunto de testes a ser executada. Se não for especificada, o IDT usará a versão mais recente no diretório de testes em seu sistema.
**test-id**
(Opcional) Os testes a serem executados, como uma lista separada por vírgulas. Se especificado, `group-id` deve especificar um único grupo.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id FreeRTOSVersion --test-id FreeRTOSVersion
```
**h**
Use a opção de ajuda para saber mais sobre as opções de `run-suite`.
**Example**
**Exemplo**
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
------
## Comandos do IDT para FreeRTOS
O comando do IDT para FreeRTOS é compatível com as seguintes operações:
------
#### [ IDT v4.5.2 and later ]
** `help` **
Lista as informações sobre o comando especificado.
** `list-groups` **
Lista os grupos em um determinado conjunto.
** `list-suites` **
Lista os conjuntos disponíveis.
** `list-supported-products` **
Lista os produtos compatíveis e as versões do conjunto de testes.
** `list-supported-versions` **
Lista as versões do FreeRTOS e do pacote de teste compatíveis com a versão atual do IDT.
** `list-test-cases` **
Lista os casos de teste em um grupo especificado.
** `run-suite` **
Executa um conjunto de testes em um grupo de dispositivos.
Use a opção `--suite-id` para especificar uma versão do conjunto de testes, ou omiti-la para usar a versão mais recente em seu sistema.
Use o `--test-id` para executar um caso de teste individual.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id FreeRTOSVersion --test-id FreeRTOSVersion
```
Começando com o IDT v3.0.0, o IDT verifica se há conjuntos de testes mais recentes online. Para obter mais informações, consulte [Versões do pacote de testes](idt-test-suite-versions.md).
------
# Veja o IDT gratuitamente RTOSresults
Enquanto em execução, o IDT grava erros no console, arquivos de log e relatórios de teste. Depois de concluir o pacote de teste de qualificação, O IDT gravará um resumo da execução de teste no console e gerará dois relatórios de teste. Esses relatórios podem ser encontrados em `devicetester-extract-location/results/execution-id/`. 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 dispositivo no Catálogo de dispositivos do AWS parceiro. O relatório contém os seguintes elementos:
+ A versão do IDT para FreeRTOS.
+ A versão do FreeRTOS que foi testada.
+ Os recursos do FreeRTOS que são compatíveis com o dispositivo com base nos testes aprovados.
+ A SKU e o nome do dispositivo especificados no arquivo `device.json`.
+ Os recursos do dispositivo especificados no arquivo `device.json`.
+ O resumo agregado dos resultados de casos de teste.
+ Um detalhamento dos resultados de casos de teste por bibliotecas que foram testadas com base nos recursos do dispositivo.
`FRQ_Report.xml`É um relatório em [formato JUnit XML](https://llg.cubic.org/docs/junit/) padrão. Você pode integrá-lo em CI/CD plataformas 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 casos de teste.
+ Um detalhamento dos resultados de casos de teste por bibliotecas que foram testadas com base nos recursos do dispositivo.
# Interpretar os resultados do IDT para FreeRTOS
A seção de relatório em `awsiotdevicetester_report.xml` ou em `FRQ_Report.xml` lista os resultados dos testes que são executados.
A primeira tag XML `` contém o resumo geral da execução do teste. Por exemplo:
``
**Atributos 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 casos de teste executados.
** `failures` **
O número de casos de teste que foram executados, mas não foram aprovados.
** `errors` **
O número de casos de teste que o IDT para FreeRTOS não pôde executar.
** `disabled` **
Esse recurso não é usado e pode ser ignorado.
Se não houver falhas ou erros no caso de teste, seu dispositivo atende aos requisitos técnicos para executar Freertos e pode interoperar com os serviços. AWS IoT Se você optar por listar seu dispositivo no Catálogo de dispositivos do AWS parceiro, poderá usar esse relatório como evidência de qualificação.
Se houver falhas de caso de teste ou erros, você poderá identificar o caso de teste com falha analisando as tags XML ``. As tags XML `` dentro da tag `` mostram o resumo do resultado do caso de teste para um grupo de testes.
``
O formato é semelhante à tag ``, mas com um recurso chamado `skipped` que não é usado e pode ser ignorado. Dentro de cada tag XML ``, há tags `` para cada um dos casos de teste que foram executados para um grupo de testes. Por exemplo:
``
**Atributos usados na tag ``**
** `name` **
O nome do produto testado.
** `version` **
A versão do produto testado.
** `features` **
Os atributos validados. recursos marcados como `required` são necessários para enviar sua placa para qualificação. O snippet a seguir mostra como essas informações aparecem no arquivo `awsiotdevicetester_report.xml`.
```
```
Os recursos marcados como `optional` não são necessários para qualificação. Os seguintes trechos mostram recursos opcionais.
```
```
Se não há falhas de teste ou erros nos recursos exigidos, seu dispositivo atende aos requisitos técnicos para executar o FreeRTOS e pode interoperar com serviços do AWS IoT . Se quiser listar o dispositivo no [AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices), poderá usar este 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 tem 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:
```
```
**Atributos usados na tag ``**
** `name` **
O nome do caso de teste.
** `attempts` **
O número de vezes que o IDT para FreeRTOS 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 case failure
Reason for the test case execution error
```
Para obter mais informações, consulte [Solucionar erros](dt-afr-troubleshooting.md).
# Veja o IDT gratuitamente RTOSlogs
É possível encontrar os logs que o IDT para FreeRTOS gera ao executar testes em `devicetester-extract-location/results/execution-id/logs`. Dois conjuntos de logs são gerados:
+ `test_manager.log`
Contém logs gerados de IDT para FreeRTOS (por exemplo, logs relacionados à configuração e geração de relatórios).
+ `test_group_id/test_case_id/test_case_id.log`
O arquivo de log para um caso de teste, incluindo a saída do dispositivo em teste. O arquivo de log é nomeado de acordo com o grupo de teste e com o caso de teste que foi executado.
# IDT com o pacote de qualificação do FreeRTOS 1.0 (FRQ 1.0)
**Importante**
Em outubro de 2022, AWS IoT Device Tester o AWS IoT FreeRTOS Qualification (FRQ) 1.0 não gera relatórios de qualificação assinados. Você não pode qualificar novos dispositivos AWS IoT FreeRTOS para serem listados no Catálogo de Dispositivos [Parceiros por meio AWS do Programa de Qualificação de Dispositivos](https://partners.amazonaws.com/qualified-devices) [usando AWS as versões IDT](https://aws.amazon.com/partners/programs/dqp/) FRQ 1.0. Embora você não possa qualificar dispositivos FreeRTOS usando o IDT FRQ 1.0, você pode continuar testando seus dispositivos FreeRTOS com o FRQ 1.0. Recomendamos que você use o [IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) para qualificar e listar dispositivos FreeRTOS no [AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices).
Você pode usar o IDT para qualificação do FreeRTOS para verificar se o sistema operacional do FreeRTOS funciona localmente em seu dispositivo e pode se comunicar com ele. AWS IoT Especificamente, ele verifica se as interfaces da camada de portabilidade para as bibliotecas do FreeRTOS estão implementadas corretamente. Ele também realiza end-to-end testes com AWS IoT Core. Por exemplo, ele verifica se a placa pode enviar e receber mensagens MQTT e processá-las corretamente. [Os testes executados pelo IDT para FreeRTOS são definidos no repositório do FreeRTOS. GitHub ](https://github.com/aws/amazon-freertos)
Os testes são executados como aplicações incorporadas que são atualizadas na placa. As imagens binárias da aplicação incluem o FreeRTOS, as interfaces do FreeRTOS obtidas por portabilidade do fornecedor de semicondutores e os drivers de dispositivos da placa. A finalidade dos testes é verificar se as interfaces do FreeRTOS obtidas por portabilidade funcionam corretamente em cima dos drivers de dispositivo.
O IDT for FreeRTOS gera relatórios de teste que você pode enviar AWS IoT para adicionar seu hardware ao AWS Partner Device Catalog. Para obter mais informações, consulte [Programa de Qualificação de Dispositivos da AWS](https://aws.amazon.com/partners/dqp/).
O IDT para FreeRTOS é executado em um computador host (Windows, macOS ou Linux) que está conectado à placa a ser testada. O IDT executa casos de teste e agrega os resultados. Ele também fornece uma interface de linha de comando para gerenciar a execução do teste.
Além de testar dispositivos, o IDT for FreeRTOS cria recursos (por exemplo, AWS IoT coisas, grupos do FreeRTOS, funções do Lambda etc.) para facilitar o processo de qualificação. Para criar esses recursos, o IDT para FreeRTOS usa AWS as credenciais configuradas no para fazer chamadas de API em `config.json` seu nome. Esses recursos são provisionados em vários momentos durante o teste.
Ao executar o IDT para FreeRTOS em seu computador host, ele executa as seguintes etapas:
1. Carrega e valida o dispositivo e configuração de credenciais.
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 a placa passou nos testes necessários para a qualificação.
**Topics**
+ [Configurar os pré-requisitos de qualificação 1.0](dev-tester-prereqs.md)
+ [Primeiro teste da sua placa de microcontrolador](qual-steps.md)
+ [Use a interface de usuário do IDT para executar o pacote de qualificação do FreeRTOS](device-tester-ui.md)
+ [Executar testes de Bluetooth Low Energy](afr-bridgekeeper-dt-bt.md)
+ [Executar o pacote de qualificação do FreeRTOS](run-tests.md)
+ [Veja os resultados do IDT para FreeRTOS](view-results-frq.md)
+ [Interpretar os resultados do IDT para FreeRTOS](interpreting-results-frq.md)
+ [Exibir os logs do IDT para FreeRTOS](view-logs-frq.md)
# Configurar os pré-requisitos de qualificação 1.0
Esta seção descreve os pré-requisitos para testar microcontroladores com. AWS IoT Device Tester
## Fazer download do FreeRTOS
Você pode baixar uma versão do FreeRTOS com o seguinte [GitHub](https://github.com/aws/amazon-freertos)comando:
```
git clone --branch --recurse-submodules https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
em que é uma versão do FreeRTOS (por exemplo, 202007.00) correspondente a uma versão do IDT listada em [Versões compatíveis do AWS IoT Device Tester](dev-test-versions-afr.md). Isso garante que você tenha o código-fonte completo, incluindo submódulos, e esteja usando a versão correta do IDT para sua versão de FreeRTOS e vice-versa.
O Windows tem uma limitação de comprimento de caminho de 260 caracteres. A estrutura de caminho do FreeRTOS tem muitos níveis; portanto, se você estiver usando o Windows, mantenha os caminhos de arquivo dentro do limite de 260 caracteres. Por exemplo, clone o FreeRTOS para `C:\FreeRTOS` em vez de `C:\Users\username\programs\projects\myproj\FreeRTOS\`.
### Qualificação do FreeRTOS com bibliotecas LTS
+ Para que seu microcontrolador seja designado como compatível com versões de FreeRTOS baseadas em suporte de longo prazo (LTS) no AWS Partner Device Catalog, você deve fornecer um arquivo manifesto. Para obter mais informações, consulte a [Lista de verificação de qualificação do FreeRTOS](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist.html) no *Guia de qualificação do FreeRTOS*.
+ Para validar se seu microcontrolador suporta versões baseadas em LTS do FreeRTOS e qualificá-lo para envio ao AWS Partner Device Catalog, você deve usar ( AWS IoT Device Tester IDT) com a suíte de testes FreeRTOS Qualification (FRQ) versão v1.4.x.
+ O suporte para versões baseadas em LTS do FreeRTOS está limitado à versão 202012.xx do FreeRTOS.
## Faça download do IDT para FreeRTOS
Cada versão do FreeRTOS tem uma versão correspondente do IDT para o FreeRTOS para realizar testes de qualificação. Baixe a versão adequada do IDT para FreeRTOS em [Versões compatíveis do AWS IoT Device Tester](dev-test-versions-afr.md).
Extraia o IDT para FreeRTOS em um local no sistema de arquivos onde existam permissões de leitura e gravação. Como o Microsoft Windows tem um limite de caracteres para o comprimento do caminho, extraia o IDT para FreeRTOS em um diretório raiz, como `C:\` ou `D:\`.
**nota**
Não é recomendável que vários usuários executem o IDT em um local compartilhado, como um diretório NFS ou uma pasta compartilhada de rede do Windows. Isso pode resultar em falhas ou corrupção de dados. Recomendamos extrair o pacote IDT para uma unidade local.
## Crie e configure uma AWS conta
### 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 *.
## AWS IoT Device Tester política gerenciada
A política `AWSIoTDeviceTesterForFreeRTOSFullAccess` gerenciada contém as seguintes AWS IoT Device Tester permissões para verificação de versão, recursos de atualização automática e coleção de métricas.
+ `iot-device-tester:SupportedVersion`
Concede AWS IoT Device Tester permissão para buscar a lista de produtos compatíveis, suítes de teste e versões do IDT.
+ `iot-device-tester:LatestIdt`
Concede AWS IoT Device Tester permissão para obter a versão mais recente do IDT disponível para download.
+ `iot-device-tester:CheckVersion`
Concede AWS IoT Device Tester permissão para verificar a compatibilidade de versões do IDT, suítes de teste e produtos.
+ `iot-device-tester:DownloadTestSuite`
Concede AWS IoT Device Tester permissão para baixar atualizações da suíte de testes.
+ `iot-device-tester:SendMetrics`
Concede AWS permissão para coletar métricas sobre o uso AWS IoT Device Tester interno.
## (Opcional) Instale o AWS Command Line Interface
Talvez você prefira usar o AWS CLI para realizar algumas operações. Se não tiver a AWS CLI instalada, siga as instruções em [Instalar a AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html).
Configure o AWS CLI para a AWS região que você deseja usar executando a **aws configure** partir de uma linha de comando. [Para obter informações sobre as AWS regiões que oferecem suporte ao IDT para FreeRTOS,AWS consulte Regiões e endpoints.](https://docs.aws.amazon.com/general/latest/gr/rande.html#amazon-freertos-ota-control) Para obter mais informações sobre **aws configure**, consulte [Configuração rápida com o **aws configure**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config).
# Primeiro teste da sua placa de microcontrolador
Você pode usar o IDT para FreeRTOS para testar conforme transfere as interfaces do FreeRTOS. Depois de portar as interfaces FreeRTOS para os drivers de dispositivo da sua placa, você pode executar os testes AWS IoT Device Tester de qualificação na placa microcontroladora.
## Adicionar camadas de transferência da biblioteca
Para fazer a portabilidade do FreeRTOS para seu dispositivo, siga as instruções no [Guia de portabilidade do FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/).
## Configure suas AWS credenciais
Você precisa configurar suas AWS credenciais para se AWS IoT Device Tester comunicar com a AWS nuvem. Para obter mais informações, consulte [Configurar as credenciais e a região da AWS para desenvolvimento](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html). AWS As credenciais válidas devem ser especificadas no arquivo `devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/config.json` de configuração.
**Topics**
+ [Adicionar camadas de transferência da biblioteca](#add-port-layer)
+ [Configure suas AWS credenciais](#cfg-aws-afr)
+ [Crie um grupo de dispositivos no IDT para FreeRTOS](cfg-dt-dp.md)
+ [Configuração de parâmetros de compilação, atualização e teste](cfg-dt-ud.md)
# Crie um grupo de dispositivos no IDT para FreeRTOS
Os dispositivos a serem testados são organizados em grupos de dispositivos. Cada grupo de dispositivos consiste em um ou mais dispositivos idênticos. Você pode configurar o IDT para FreeRTOS para testar um único dispositivo em um grupo ou vários dispositivos em um grupo. Para acelerar o processo de qualificação, o IDT para FreeRTOS pode testar dispositivos com as mesmas especificações em paralelo. Ele usa o método round-robin para executar um grupo de testes diferente em cada dispositivo de um grupo de dispositivos.
Você pode adicionar um ou mais dispositivos a um grupo de dispositivos editando a seção `devices` do modelo `device.json` na pasta `configs`.
**nota**
Todos os dispositivos no mesmo grupo devem ser da mesma especificação técnica e SKU.
Para habilitar as compilações paralelas do código-fonte para diferentes grupos de teste, o IDT para FreeRTOS copia o código-fonte para uma pasta de resultados dentro da pasta onde o IDT para FreeRTOS foi extraído. O caminho do código-fonte no comando de compilação ou atualização deve ser referenciado por meio da variável `testdata.sourcePath` ou `sdkPath`. O IDT para FreeRTOS substitui esta variável por um caminho temporário do código-fonte copiado. Para obter mais informações, consulte, [Variáveis do IDT para FreeRTOS](dt-vars.md).
Veja a seguir um exemplo do arquivo `device.json` usado para criar um grupo de dispositivos com vários dispositivos.
```
[
{
"id": "pool-id",
"sku": "sku",
"features": [
{
"name": "WIFI",
"value": "Yes | No"
},
{
"name": "Cellular",
"value": "Yes | No"
},
{
"name": "OTA",
"value": "Yes | No",
"configs": [
{
"name": "OTADataPlaneProtocol",
"value": "HTTP | MQTT"
}
]
},
{
"name": "BLE",
"value": "Yes | No"
},
{
"name": "TCP/IP",
"value": "On-chip | Offloaded | No"
},
{
"name": "TLS",
"value": "Yes | No"
},
{
"name": "PKCS11",
"value": "RSA | ECC | Both | No"
},
{
"name": "KeyProvisioning",
"value": "Import | Onboard | No"
}
],
"devices": [
{
"id": "device-id",
"connectivity": {
"protocol": "uart",
"serialPort": "/dev/tty*"
},
***********Remove the section below if the device does not support onboard key generation***************
"secureElementConfig" : {
"publicKeyAsciiHexFilePath": "absolute-path-to/public-key-txt-file: contains-the-hex-bytes-public-key-extracted-from-onboard-private-key",
"secureElementSerialNumber": "secure-element-serialNo-value",
"preProvisioned" : "Yes | No"
},
**********************************************************************************************************
"identifiers": [
{
"name": "serialNo",
"value": "serialNo-value"
}
]
}
]
}
]
```
Os seguintes recursos são usados no arquivo `device.json`:
**`id`**
Um ID alfanumérico definido pelo usuário que identifica exclusivamente um grupo de dispositivos. Os dispositivos que pertencem a um grupo devem ser do mesmo tipo. Quando um conjunto de testes está em execução, os dispositivos do grupo são usados para paralelizar a carga de trabalho.
**`sku`**
Um valor alfanumérico que identifica exclusivamente a placa sendo testada. A SKU é usada para rastrear as placas qualificadas.
Se você quiser listar sua placa no AWS Partner Device Catalog, o SKU especificado aqui deve corresponder ao SKU que você usa no processo de listagem.
**`features`**
Uma matriz que contém os recursos suportados pelo dispositivo. AWS IoT Device Tester usa essas informações para selecionar os testes de qualificação a serem executados.
Os valores compatíveis são:
**`TCP/IP`**
Indica se sua placa suporta uma TCP/IP pilha e se ela é suportada no chip (MCU) ou descarregada em outro módulo. TCP/IP é necessário para a qualificação.
**`WIFI`**
Indica se a placa tem recursos de Wi-Fi. Deve ser definido como `No`, se `Cellular` estiver definido como `Yes`.
**`Cellular`**
Indica se a placa tem recursos de celular. Deve ser definido como `No`, se `WIFI` estiver definido como `Yes`. Quando esse recurso estiver configurado como`Yes`, o FullSecureSockets teste será executado usando instâncias EC2 AWS t2.micro e isso poderá gerar custos adicionais para sua conta. Para obter mais informações, consulte [Definição de preço do Amazon EC2](https://aws.amazon.com/ec2/pricing/).
**`TLS`**
Indica se sua placa oferece suporte a TLS. O TLS é necessário para qualificação.
**`PKCS11`**
Indica o algoritmo de criptografia de chave pública que a placa suporta. PKCS11 é necessário para a qualificação. Os valores compatíveis são `ECC`, `RSA`, `Both` e `No`. `Both` indica que a placa é compatível com os algoritmos `ECC` e `RSA`.
**`KeyProvisioning`**
Indica o método de gravação de um certificado de cliente X.509 confiável em sua placa. Os valores válidos são `Import`, `Onboard` e `No`. O provisionamento de chaves é necessário para a qualificação.
+ Use `Import` se a sua placa permitir a importação de chaves privadas. O IDT criará uma chave privada e criará isso para o código-fonte do FreeRTOS.
+ Use `Onboard` se a placa for compatível com a geração de chaves privadas integradas (por exemplo, se o dispositivo tiver um elemento seguro ou se você preferir gerar o seu próprio par de chaves de dispositivo e certificado). Adicione um elemento `secureElementConfig` em cada uma das seções do dispositivo e coloque o caminho absoluto para o arquivo de chave pública no campo `publicKeyAsciiHexFilePath`.
+ Se a placa não for compatível com o provisionamento de chaves, use `No`.
**`OTA`**
Indica se sua placa suporta a funcionalidade de atualização over-the-air (OTA). O recurso `OtaDataPlaneProtocol` indica a qual protocolo de plano de dados OTA o dispositivo oferece suporte. O atributo será ignorado se o dispositivo não oferecer suporte ao recurso OTA. Quando `"Both"` é selecionado, o tempo de execução do teste OTA é prolongado devido à execução de testes MQTT, HTTP e mistos.
A partir do IDT v4.1.0, `OtaDataPlaneProtocol` aceita somente `HTTP` e `MQTT` como valores compatíveis.
**`BLE`**
Indica se a placa é compatível com Bluetooth Low Energy (BLE).
**`devices.id`**
Um identificador exclusivo, definido pelo usuário, para o dispositivo que está sendo testado.
**`devices.connectivity.protocol`**
O protocolo de comunicação usado para se comunicar com esse dispositivo. Valor compatível: `uart`.
**`devices.connectivity.serialPort`**
A porta serial do computador host usada para se conectar aos dispositivos que estão sendo testados.
**`devices.secureElementConfig.PublicKeyAsciiHexFilePath`**
O caminho absoluto para o arquivo que contém a chave pública de bytes hexadecimal extraída da chave privada integrada.
Formato de exemplo:
```
3059 3013 0607 2a86 48ce 3d02 0106 082a
8648 ce3d 0301 0703 4200 04cd 6569 ceb8
1bb9 1e72 339f e8cf 60ef 0f9f b473 33ac
6f19 1813 6999 3fa0 c293 5fae 08f1 1ad0
41b7 345c e746 1046 228e 5a5f d787 d571
dcb2 4e8d 75b3 2586 e2cc 0c
```
Se sua chave pública estiver no formato .der, você pode codificar a chave pública em hexadecimal diretamente para gerar o arquivo hexadecimal.
Exemplo de comando para a chave pública .der para gerar o arquivo hexadecimal:
```
xxd -p pubkey.der > outFile
```
Se sua chave pública estiver no formato .pem, é possível extrair a parte codificada em base64, decodificá-la em formato binário e, em seguida, codificá-la em hexadecimal para gerar o arquivo hexadecimal.
Por exemplo, use esses comandos para gerar um arquivo hexadecimal para a chave pública .pem:
1. Retire a parte codificada em base64 da chave (retire o cabeçalho e o rodapé) e armazene-a em um arquivo, por exemplo, nomeie-a como `base64key`, execute este comando para convertê-la para o formato .der:
```
base64 —decode base64key > pubkey.der
```
1. Execute o comando `xxd` para convertê-la para o formato hexadecimal.
```
xxd -p pubkey.der > outFile
```
**`devices.secureElementConfig.SecureElementSerialNumber`**
(Opcional) O número de série do elemento seguro. Forneça esse campo quando o número de série for impresso junto com a chave pública do dispositivo ao executar o projeto FreeRTOS demo/test .
**`devices.secureElementConfig.preProvisioned`**
(Opcional) Defina como "Sim" se o dispositivo tiver um elemento seguro pré-provisionado com credenciais bloqueadas, que não possa importar, criar ou destruir objetos. Essa configuração tem efeito apenas quando o `features` tem a `KeyProvisioning` definida como "Onboard", junto com `PKCS11` definida como "ECC".
**`identifiers`**
(Opcional) Uma matriz de pares de nome-valor arbitrários. Você pode usar esses valores nos comandos de compilação e atualização descritos na próxima seção.
# Configuração de parâmetros de compilação, atualização e teste
Para que o IDT para FreeRTOS crie e atualize testes em sua placa automaticamente, você deve configurar o IDT para executar os comandos de compilação e atualização para seu hardware. As configurações de comando de compilação e atualização são definidas no modelo de arquivo `userdata.json` localizado na pasta `config`.
# Configuração de parâmetros para testar dispositivos
As configurações de compilação, atualização e teste são feitas no arquivo `configs/userdata.json`. Oferecemos suporte à configuração do servidor echo carregando os certificados e chaves do cliente e do servidor no `customPath`. Para obter mais informações, consulte [Configurando um servidor Echo](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html) no *Guia de portabilidade do FreeRTOS*. O seguinte exemplo de JSON mostra como você pode configurar o IDT para FreeRTOS para testar vários dispositivos:
```
{
"sourcePath": "/absolute-path-to/freertos",
"vendorPath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name",
// ***********The sdkConfiguration block below is needed if you are not using the default, unmodified FreeRTOS repo.
// In other words, if you are using the default, unmodified FreeRTOS repo then remove this block***************
"sdkConfiguration": {
"name": "sdk-name",
"version": "sdk-version",
"path": "/absolute-path-to/sdk"
},
"buildTool": {
"name": "your-build-tool-name",
"version": "your-build-tool-version",
"command": [
"{{config.idtRootPath}}/relative-path-to/build-parallel.sh {{testData.sourcePath}} {{enableTests}}"
]
},
"flashTool": {
"name": "your-flash-tool-name",
"version": "your-flash-tool-version",
"command": [
"/{{config.idtRootPath}}/relative-path-to/flash-parallel.sh {{testData.sourcePath}} {{device.connectivity.serialPort}} {{buildImageName}}"
],
"buildImageInfo" : {
"testsImageName": "tests-image-name",
"demosImageName": "demos-image-name"
}
},
"testStartDelayms": 0,
"clientWifiConfig": {
"wifiSSID": "ssid",
"wifiPassword": "password",
"wifiSecurityType": "eWiFiSecurityOpen | eWiFiSecurityWEP | eWiFiSecurityWPA | eWiFiSecurityWPA2 | eWiFiSecurityWPA3"
},
"testWifiConfig": {
"wifiSSID": "ssid",
"wifiPassword": "password",
"wifiSecurityType": "eWiFiSecurityOpen | eWiFiSecurityWEP | eWiFiSecurityWPA | eWiFiSecurityWPA2 | eWiFiSecurityWPA3"
},
//**********
//This section is used to start echo server based on server certificate generation method,
//When certificateGenerationMethod is set as Automatic specify the eccCurveFormat to generate certifcate and key based on curve format,
//When certificateGenerationMethod is set as Custom specify the certificatePath and PrivateKeyPath to be used to start echo server
//**********
"echoServerCertificateConfiguration": {
"certificateGenerationMethod": "Automatic | Custom",
"customPath": {
"clientCertificatePath":"/path/to/clientCertificate",
"clientPrivateKeyPath": "/path/to/clientPrivateKey",
"serverCertificatePath":"/path/to/serverCertificate",
"serverPrivateKeyPath": "/path/to/serverPrivateKey"
},
"eccCurveFormat": "P224 | P256 | P384 | P521"
},
"echoServerConfiguration": {
"securePortForSecureSocket": 33333, // Secure tcp port used by SecureSocket test. Default value is 33333. Ensure that the port configured isn't blocked by the firewall or your corporate network
"insecurePortForSecureSocket": 33334, // Insecure tcp port used by SecureSocket test. Default value is 33334. Ensure that the port configured isn't blocked by the firewall or your corporate network
"insecurePortForWiFi": 33335 // Insecure tcp port used by Wi-Fi test. Default value is 33335. Ensure that the port configured isn't blocked by the firewall or your corporate network
},
"otaConfiguration": {
"otaFirmwareFilePath": "{{testData.sourcePath}}/relative-path-to/ota-image-generated-in-build-process",
"deviceFirmwareFileName": "ota-image-name-on-device",
"otaDemoConfigFilePath": "{{testData.sourcePath}}/relative-path-to/ota-demo-config-header-file",
"codeSigningConfiguration": {
"signingMethod": "AWS | Custom",
"signerHashingAlgorithm": "SHA1 | SHA256",
"signerSigningAlgorithm": "RSA | ECDSA",
"signerCertificate": "arn:partition:service:region:account-id:resource:qualifier | /absolute-path-to/signer-certificate-file",
"signerCertificateFileName": "signerCertificate-file-name",
"compileSignerCertificate": boolean,
// ***********Use signerPlatform if you choose aws for signingMethod***************
"signerPlatform": "AmazonFreeRTOS-Default | AmazonFreeRTOS-TI-CC3220SF",
"untrustedSignerCertificate": "arn:partition:service:region:account-id:resourcetype:resource:qualifier",
// ***********Use signCommand if you choose custom for signingMethod***************
"signCommand": [
"/absolute-path-to/sign.sh {{inputImageFilePath}} {{outputSignatureFilePath}}"
]
}
},
// ***********Remove the section below if you're not configuring CMake***************
"cmakeConfiguration": {
"boardName": "board-name",
"vendorName": "vendor-name",
"compilerName": "compiler-name",
"frToolchainPath": "/path/to/freertos/toolchain",
"cmakeToolchainPath": "/path/to/cmake/toolchain"
},
"freertosFileConfiguration": {
"required": [
{
"configName": "pkcs11Config",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/core_pkcs11_config.h"
},
{
"configName": "pkcs11TestConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/iot_test_pkcs11_config.h"
}
],
"optional": [
{
"configName": "otaAgentTestsConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/ota_config.h"
},
{
"configName": "otaAgentDemosConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_demos/config_files/ota_config.h"
},
{
"configName": "otaDemosConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_demos/config_files/ota_demo_config.h"
}
]
}
}
```
Veja a seguir uma lista dos recursos usados no `userdata.json`:
**`sourcePath`**
O caminho para a raiz do código-fonte do FreeRTOS transferido. Para testes paralelos com um SDK, o `sourcePath` pode ser definido usando o espaço reservado `{{userData.sdkConfiguration.path}}`. Por exemplo:
```
{ "sourcePath":"{{userData.sdkConfiguration.path}}/freertos" }
```
**`vendorPath`**
O caminho para o código do FreeRTOS específico do fornecedor. Para testes em série, o `vendorPath` pode ser definido como um caminho absoluto. Por exemplo:
```
{ "vendorPath":"C:/path-to-freertos/vendors/espressif/boards/esp32" }
```
Para testes paralelos, o `vendorPath` pode ser definido usando o espaço reservado `{{testData.sourcePath}}`. Por exemplo:
```
{ "vendorPath":"{{testData.sourcePath}}/vendors/espressif/boards/esp32" }
```
A variável `vendorPath` só é necessária quando executada sem um SDK, caso contrário, ela pode ser removida.
Ao executar testes em paralelo sem um SDK, o espaço reservado `{{testData.sourcePath}}` deve ser usado nos campos `vendorPath`, `buildTool`, `flashTool`. o executar o teste com um único dispositivo, caminhos absolutos devem ser usados nos campos `vendorPath`, `buildTool` e `flashTool`. Ao executar com um SDK, o espaço reservado `{{sdkPath}}` deve ser usado nos comandos `sourcePath`, `buildTool` e `flashTool`.
**`sdkConfiguration`**
Se você estiver qualificando o FreeRTOS com modificações na estrutura de arquivos e pastas além do necessário para a portabilidade, será necessário configurar as informações do SDK neste bloco. Se você não estiver qualificando com um Freertos transferido de dentro de um SDK, será necessário omitir esse bloco totalmente.
**`sdkConfiguration.name`**
O nome do SDK que você está usando com o FreeRTOS. Se você não estiver usando um SDK, todo o bloco `sdkConfiguration` deverá ser omitido.
**`sdkConfiguration.version`**
A versão do SDK que você está usando com o FreeRTOS. Se você não estiver usando um SDK, todo o bloco `sdkConfiguration` deverá ser omitido.
**`sdkConfiguration.path`**
O caminho absoluto para o diretório do SDK que contém o código do FreeRTOS. Se você não estiver usando um SDK, todo o bloco `sdkConfiguration` deverá ser omitido.
**`buildTool`**
O caminho completo para o script de compilação (.bat ou .sh) que contém os comandos para compilar seu código-fonte. Todas as referências ao caminho do código-fonte no comando build devem ser substituídas pela AWS IoT Device Tester variável `{{testdata.sourcePath}}` e as referências ao caminho do SDK devem ser substituídas por`{{sdkPath}}`. Use o `{{config.idtRootPath}}` espaço reservado para referenciar o caminho IDT absoluto ou relativo.
**`testStartDelayms`**
Especifica quantos milissegundos o executor de testes do FreeRTOS aguardará antes de começar a executar os testes. Isso pode ser útil se o dispositivo em teste começar a gerar informações de teste importantes antes que o IDT tenha a chance de se conectar e iniciar o registro em log devido à rede ou outra latência. O valor máximo permitido é 30.000 ms (30 segundos). Este valor é aplicável somente aos grupos de teste do FreeRTOS, e não aplicável a outros grupos de teste que não utilizam o executor de testes do FreeRTOS, como os testes OTA.
**`flashTool`**
O caminho completo para o script de atualização (.sh ou .bat) que contém os comandos de atualização para o dispositivo. Todas as referências ao caminho do código-fonte no comando de atualização devem ser substituídas pela variável `{{testdata.sourcePath}}` do IDT para FreeRTOS e todas as referências ao seu caminho do SDK devem ser substituídas pela variável`{{sdkPath}}` do IDT para FreeRTOS. Use o espaço reservado `{{config.idtRootPath}}` para fazer referência ao caminho absoluto ou relativo do IDT.
**`buildImageInfo`**
**`testsImageName`**
O nome do arquivo produzido pelo comando de compilação ao compilar testes da pasta `freertos-source/tests`.
**`demosImageName`**
O nome do arquivo produzido pelo comando de compilação ao compilar testes da pasta `freertos-source/demos`.
**`clientWifiConfig`**
Configuração do Wi-Fi do cliente. Os testes da biblioteca de Wi-Fi exigem que uma placa de MCU seja conectada a dois pontos de acesso. (Os dois pontos de acesso podem ser os mesmos.) Este atributo define as configurações de Wi-Fi para o primeiro ponto de acesso. Alguns dos casos de teste de Wi-Fi esperam que o ponto de acesso tenha algum recurso de segurança e que não esteja aberto. Verifique se os dois pontos de acesso estão na mesma sub-rede do computador host que executa o IDT.
**`wifi_ssid`**
O SSID do Wi-Fi.
**`wifi_password`**
A senha do Wi-Fi.
**`wifiSecurityType`**
O tipo de segurança do Wi-Fi utilizada. Um dos valores:
+ `eWiFiSecurityOpen`
+ `eWiFiSecurityWEP`
+ `eWiFiSecurityWPA`
+ `eWiFiSecurityWPA2`
+ `eWiFiSecurityWPA3`
Se a placa não for compatível com Wi-Fi, você ainda deverá incluir a seção `clientWifiConfig` no arquivo `device.json`, mas poderá omitir os valores desses recursos.
**`testWifiConfig`**
Configuração de teste do Wi-Fi. Os testes da biblioteca de Wi-Fi exigem que uma placa de MCU seja conectada a dois pontos de acesso. (Os dois pontos de acesso podem ser os mesmos.) Esse atributo define a configuração do Wi-Fi para o segundo ponto de acesso. Alguns dos casos de teste de Wi-Fi esperam que o ponto de acesso tenha algum recurso de segurança e que não esteja aberto. Verifique se os dois pontos de acesso estão na mesma sub-rede do computador host que executa o IDT.
**`wifiSSID`**
O SSID do Wi-Fi.
**`wifiPassword`**
A senha do Wi-Fi.
**`wifiSecurityType`**
O tipo de segurança do Wi-Fi utilizada. Um dos valores:
+ `eWiFiSecurityOpen`
+ `eWiFiSecurityWEP`
+ `eWiFiSecurityWPA`
+ `eWiFiSecurityWPA2`
+ `eWiFiSecurityWPA3`
Se a placa não for compatível com Wi-Fi, você ainda deverá incluir a seção `testWifiConfig` no arquivo `device.json`, mas poderá omitir os valores desses recursos.
**`echoServerCertificateConfiguration`**
O espaço reservado configurável de geração de certificados do servidor echo para testes de SSL. Este campo é obrigatório.
**`certificateGenerationMethod`**
Especifica se o certificado do servidor é gerado automaticamente ou fornecido manualmente.
**`customPath`**
Se o `certificateGenerationMethod` for "personalizado", `certificatePath` e `privateKeyPath` são obrigatórios.
**`certificatePath`**
Especifica o caminho do arquivo do certificado do servidor.
**`privateKeyPath`**
Especifica o caminho do arquivo da chave privada.
**`eccCurveFormat`**
Especifica o formato de curva compatível com a placa. Obrigatório quando `PKCS11` estiver definido como "ecc" em `device.json`. Os valores válidos são "P224", "P256", "P384" ou "P521".
**`echoServerConfiguration`**
As portas configuráveis do servidor de eco para WiFi testes de soquetes seguros. Esse campo é opcional.
**`securePortForSecureSocket`**
A porta que é usada para configurar um servidor echo com TLS para o teste de soquetes seguros. O valor padrão é 33333. Verifique se a porta configurada não está bloqueada por um firewall ou pela rede corporativa.
**`insecurePortForSecureSocket`**
A porta usada para configurar o servidor echo sem TLS para o teste de soquetes seguros. O valor padrão usado no teste é 33334. Verifique se a porta configurada não está bloqueada por um firewall ou pela rede corporativa.
**`insecurePortForWiFi`**
A porta usada para configurar o servidor de eco sem TLS para WiFi teste. O valor padrão usado no teste é 33335. Verifique se a porta configurada não está bloqueada por um firewall ou pela rede corporativa.
**`otaConfiguration`**
A configuração OTA. [Opcional]
**`otaFirmwareFilePath`**
O caminho completo para a imagem OTA criada após a compilação. Por exemplo, `{{testData.sourcePath}}/relative-path/to/ota/image/from/source/root`.
**`deviceFirmwareFileName`**
O caminho completo do arquivo no dispositivo MCU onde o firmware OTA está localizado. Alguns dispositivos não usam esse campo, mas você ainda deve fornecer um valor.
**`otaDemoConfigFilePath`**
O caminho completo para `aws_demo_config.h`, encontrado em `afr-source/vendors/vendor/boards/board/aws_demos/config_files/`. Esses arquivos estão incluídos no modelo de código de transferência fornecido pelo FreeRTOS.
**`codeSigningConfiguration`**
A configuração de assinatura de código.
**`signingMethod`**
O método de assinatura de código. Os valores possíveis são `AWS` ou `Custom`.
Nas regiões de Pequim e Ningxia, use `Custom`. Não há compatibilidade para a assinatura de código da `AWS` nessas regiões.
**`signerHashingAlgorithm`**
O algoritmo de hash ao qual o dispositivo oferece suporte. Os valores possíveis são `SHA1` ou `SHA256`.
**`signerSigningAlgorithm`**
O algoritmo de assinatura ao qual o dispositivo oferece suporte. Os valores possíveis são `RSA` ou `ECDSA`.
**`signerCertificate`**
O certificado de confiança usado para OTA.
Para o método de assinatura de AWS código, use o Amazon Resource Name (ARN) para o certificado confiável enviado para o. AWS Certificate Manager
Para o método de assinatura de código personalizado, use o caminho absoluto para o arquivo de certificado do assinante.
Para obter mais informações sobre como criar um certificado confiável, consulte [Criação de um certificado de assinatura de código](ota-code-sign-cert.md).
**`signerCertificateFileName`**
O nome do arquivo do certificado de assinatura de código no dispositivo. Esse valor deve corresponder ao nome do arquivo que você forneceu ao executar o comando `aws acm import-certificate`.
Para obter mais informações, consulte [Criação de um certificado de assinatura de código](ota-code-sign-cert.md).
**`compileSignerCertificate`**
Defina como `true` se o certificado de verificação de assinatura do signatário do código não for provisionado ou atualizado, então ele deve ser compilado no projeto. AWS IoT Device Tester busca o certificado confiável e o compila em. `aws_codesigner_certifiate.h`
**`untrustedSignerCertificate`**
O ARN ou caminho de arquivo de um segundo certificado usado em alguns testes OTA como um certificado não confiável. Para obter mais informações sobre como criar um certificado, consulte [Criar um certificado de assinatura de código](https://docs.aws.amazon.com/freertos/latest/userguide/ota-code-sign-cert.html).
**`signerPlatform`**
O algoritmo de assinatura e hashing que o AWS Code Signer usa ao criar o trabalho de atualização do OTA. Atualmente, os valores possíveis para este campo são `AmazonFreeRTOS-TI-CC3220SF` e `AmazonFreeRTOS-Default`.
+ Escolha `AmazonFreeRTOS-TI-CC3220SF` se `SHA1` e `RSA`.
+ Escolha `AmazonFreeRTOS-Default` se `SHA256` e `ECDSA`.
Se você precisar de `SHA256` \$1 `RSA` ou `SHA1` \$1 `ECDSA` para sua configuração, entre em contato conosco para obter mais suporte.
Configure `signCommand` se você escolheu `Custom` para `signingMethod`.
**`signCommand`**
O comando usado para executar a assinatura de código personalizado. É possível encontrar o modelo no diretório `/configs/script_templates`.
Dois espaços reservados `{{inputImageFilePath}}` e `{{outputSignatureFilePath}}` são necessários no comando. `{{inputImageFilePath}}` é o caminho do arquivo da imagem criada pelo IDT a ser assinado. `{{outputSignatureFilePath}}` é o caminho do arquivo da assinatura que será gerado pelo script.
**`cmakeConfiguration`**
CMake configuração [Opcional]
Para executar casos de CMake teste, você deve fornecer o nome da placa, o nome do fornecedor e o `frToolchainPath` ou`compilerName`. Você também pode fornecer o `cmakeToolchainPath` se tiver um caminho personalizado para o CMake conjunto de ferramentas.
**`boardName`**
O nome da placa em teste. O nome do painel deve ser o mesmo que o nome da pasta em `path/to/afr/source/code/vendors/vendor/boards/board`.
**`vendorName`**
O nome do fornecedor para a placa em teste. O fornecedor deve ser o mesmo que o nome da pasta em `path/to/afr/source/code/vendors/vendor`.
**`compilerName`**
O nome do compilador.
**`frToolchainPath`**
O caminho totalmente qualificado para o conjunto de ferramentas do compilador
**`cmakeToolchainPath` **
O caminho totalmente qualificado para a cadeia de ferramentas. CMake Este campo é opcional
**`freertosFileConfiguration`**
A configuração dos arquivos FreeRTOS que o IDT modifica antes de executar testes.
**`required`**
Esta seção especifica os testes necessários cujos arquivos de configuração você moveu, por exemplo PKCS11, TLS e assim por diante.
**`configName`**
O nome do teste que é configurado.
**`filePath`**
O caminho absoluto para os arquivos de configuração no repositório `freertos`. Use a variável `{{testData.sourcePath}}` para definir o caminho.
**`optional`**
Esta seção especifica testes opcionais cujos arquivos de configuração você moveu, por exemplo, OTA WiFi, etc.
**`configName`**
O nome do teste que é configurado.
**`filePath`**
O caminho absoluto para os arquivos de configuração no repositório `freertos`. Use a variável `{{testData.sourcePath}}` para definir o caminho.
**nota**
Para executar casos de CMake teste, você deve fornecer o nome da placa, o nome do fornecedor e o `afrToolchainPath` ou`compilerName`. Você também pode fornecer `cmakeToolchainPath` se você tem um caminho personalizado para o CMake conjunto de ferramentas.
# Variáveis do IDT para FreeRTOS
Os comandos para criar seu código e atualizar o dispositivo podem exigir conectividade ou outras informações sobre seus dispositivos para serem executados com êxito. AWS IoT Device Tester permite referenciar informações do dispositivo em flash e criar comandos usando [JsonPath](https://goessner.net/articles/JsonPath/)o. Usando JsonPath expressões simples, você pode buscar as informações necessárias especificadas em seu `device.json` arquivo.
## Variáveis de caminho
O IDT para FreeRTOS define as seguintes variáveis de caminho que podem ser usadas em linhas de comando e arquivos de configuração:
**`{{testData.sourcePath}}`**
Expande o caminho do código-fonte. Se você usar essa variável, ela deverá ser usada nos comandos de compilação e atualização.
**`{{sdkPath}}`**
Expande-se para o valor em seu `userData.sdkConfiguration.path` quando usado nos comandos compilar e atualizar.
**`{{device.connectivity.serialPort}}`**
Expande à porta serial.
**`{{device.identifiers[?(@.name == 'serialNo')].value[0]}}`**
Expande o número de série do dispositivo.
**`{{enableTests}}`**
Valor inteiro que indica se a compilação é para testes (valor 1) ou demonstrações (valor 0).
**`{{buildImageName}}`**
O nome do arquivo da imagem criada pelo comando de compilação.
**`{{otaCodeSignerPemFile}}`**
Arquivo PEM para o assinante do código OTA.
**`{{config.idtRootPath}}`**
Expande-se até o caminho AWS IoT Device Tester raiz. Essa variável substitui o caminho absoluto do IDT quando usada pelos comandos build e flash.
# Use a interface de usuário do IDT para executar o pacote de qualificação do FreeRTOS
A partir do IDT v4.3.0, para AWS IoT Device Tester FreeRTOS (IDT-FreeRTOS) inclui uma interface de usuário baseada na web que permite interagir com o executável da linha de comando do IDT e os arquivos de configuração relacionados. Você pode usar a interface do IDT-FreeRTOS para criar uma nova configuração para executar testes de IDT ou modificar uma configuração existente. Também é possível usar a interface do usuário para invocar o executável do IDT e executar testes.
A interface de usuário do IDT-FreeRTOS fornece as seguintes funções:
+ Simplifique a configuração dos arquivos de configuração para testes do IDT-FreeRTOS.
+ Simplifique o uso do IDT-FreeRTOS para executar testes de qualificação.
Para obter informações sobre o uso da linha de comando para executar os testes de qualificação, consulte [Primeiro teste da sua placa de microcontrolador](qual-steps.md).
Esta seção descreve os pré-requisitos da interface do usuário do IDT para FreeRTOS e mostra como começar a executar testes de qualificação da interface do usuário.
**Topics**
+ [Configurar os pré-requisitos para executar o pacote de qualificações do FreeRTOS](dev-tester-ui-prereqs.md)
+ [Conceitos básicos da interface do usuário do IDT-FreeRTOS](dev-tester-ui-getting-started.md)
# Configurar os pré-requisitos para executar o pacote de qualificações do FreeRTOS
Esta seção descreve os pré-requisitos para testar microcontroladores com o AWS IoT Device Tester.
**Topics**
+ [Usar um navegador da web compatível](#idt-ui-supported-web-browser)
+ [Faça download do FreeRTOS](#ui-download-afr)
+ [Faça download do IDT para FreeRTOS](#ui-download-dev-tester-afr)
+ [Crie e configure uma AWS conta](#ui-config-aws-account)
+ [AWS IoT Device Tester política gerenciada](#ui-managed-policy)
## Usar um navegador da web compatível
A interface de usuário do IDT para FreeRTOS é compatível com os seguintes navegadores da web.
| Navegador | Versão |
| --- | --- |
| Google Chrome | Últimas três versões principais |
| Mozilla Firefox | Últimas três versões principais |
| Microsoft Edge | Últimas três versões principais |
| Apple Safari para macOS | Últimas três versões principais |
Recomendamos que você use o Google Chrome ou o Mozilla Firefox para uma ter melhor experiência.
**nota**
A interface de usuário do IDT para FreeRTOS não é compatível com o Microsoft Internet Explorer.
## Faça download do FreeRTOS
Você pode baixar uma versão do FreeRTOS com o seguinte [GitHub](https://github.com/aws/amazon-freertos)comando:
```
git clone --branch --recurse-submodules https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
em que é uma versão do FreeRTOS (por exemplo, 202007.00) correspondente a uma versão do IDT listada em [Versões compatíveis do AWS IoT Device Tester](dev-test-versions-afr.md). Isso garante que você tenha o código-fonte completo, incluindo submódulos, e esteja usando a versão correta do IDT para sua versão de FreeRTOS e vice-versa.
O Windows tem uma limitação de comprimento de caminho de 260 caracteres. A estrutura de caminho do FreeRTOS tem muitos níveis; portanto, se você estiver usando o Windows, mantenha os caminhos de arquivo dentro do limite de 260 caracteres. Por exemplo, clone o FreeRTOS para `C:\FreeRTOS` em vez de `C:\Users\username\programs\projects\myproj\FreeRTOS\`.
### Considerações para a qualificação LTS (qualificação para FreeRTOS que usa bibliotecas LTS)
+ Para que seu microcontrolador seja designado como compatível com versões de FreeRTOS baseadas em suporte de longo prazo (LTS) no AWS Partner Device Catalog, você deve fornecer um arquivo manifesto. Para obter mais informações, consulte a [Lista de verificação de qualificação do FreeRTOS](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist.html) no *Guia de qualificação do FreeRTOS*.
+ Para validar se seu microcontrolador suporta versões baseadas em LTS do FreeRTOS e qualificá-lo para envio ao AWS Partner Device Catalog, você deve usar ( AWS IoT Device Tester IDT) com a suíte de testes FreeRTOS Qualification (FRQ) versão v1.4.x.
+ O suporte para versões baseadas em LTS do FreeRTOS está limitado à versão 202012.xx do FreeRTOS.
## Faça download do IDT para FreeRTOS
Cada versão do FreeRTOS tem uma versão correspondente do IDT para o FreeRTOS para realizar testes de qualificação. Baixe a versão adequada do IDT para FreeRTOS em [Versões compatíveis do AWS IoT Device Tester](dev-test-versions-afr.md).
Extraia o IDT para FreeRTOS em um local no sistema de arquivos onde existam permissões de leitura e gravação. Como o Microsoft Windows tem um limite de caracteres para o comprimento do caminho, extraia o IDT para FreeRTOS em um diretório raiz, como `C:\` ou `D:\`.
**nota**
Recomendamos que você extraia o pacote IDT em uma unidade local. Permitir que vários usuários executem o IDT em um local compartilhado, como um diretório NFS ou uma pasta compartilhada na rede do Windows, pode resultar na falta de resposta do sistema ou na corrupção de dados.
## Crie e configure uma AWS conta
### 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 *.
## AWS IoT Device Tester política gerenciada
Para habilitar o Device Tester a executar e coletar métricas, a política gerenciada `AWSIoTDeviceTesterForFreeRTOSFullAccess` contém as seguintes permissões:
+ `iot-device-tester:SupportedVersion`
Concede permissão para obter a lista de versões do FreeRTOS e versões do pacote de testes compatíveis com o IDT, para que elas estejam disponíveis na AWS CLI.
+ `iot-device-tester:LatestIdt`
Concede permissão para obter a AWS IoT Device Tester versão mais recente que está disponível para download.
+ `iot-device-tester:CheckVersion`
Concede permissão para verificar se uma combinação de produtos, conjunto de testes e versões do AWS IoT Device Tester são compatíveis.
+ `iot-device-tester:DownloadTestSuite`
Concede permissão AWS IoT Device Tester para baixar suítes de teste.
+ `iot-device-tester:SendMetrics`
Concede permissão para publicar dados AWS IoT Device Tester de métricas de uso.
# Conceitos básicos da interface do usuário do IDT-FreeRTOS
Esta seção mostra como usar a interface de usuário do IDT-FreeRTOS para criar ou modificar sua configuração e, em seguida, mostra como executar testes.
**Topics**
+ [Configurar AWS credenciais](#configure-aws-credentials)
+ [Abra a interface de usuário do IDT-FreeRTOS](#open-idt-ui)
+ [Criar uma configuração](#create-new-configuration)
+ [Modificar uma configuração existente](#modify-existing-configuration)
+ [Execute testes de qualificação](#run-tests-from-ui)
## Configurar AWS credenciais
Você deve configurar as credenciais para o AWS usuário que você criou em[Crie e configure uma AWS conta](dev-tester-ui-prereqs.md#ui-config-aws-account). Você pode especificar suas credenciais de uma das seguintes formas:
+ Em um arquivo de credenciais
+ Como 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 =
```
**nota**
Se você não usar o `default` AWS perfil, certifique-se de especificar o nome do perfil na interface do IDT-FreeRTOS. Para obter mais informações sobre perfis, consulte [Configurações de arquivos de configuração e credenciais](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 são salvas se você fechar a sessão SSH. A interface de usuário do IDT-FreeRTOS usa as variáveis de ambiente `AWS_ACCESS_KEY_ID` e `AWS_SECRET_ACCESS_KEY` para armazenar suas credenciais da 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=
```
## Abra a interface de usuário do IDT-FreeRTOS
**Como abrir a interface de usuário do IDT-FreeRTOS**
1. Baixe uma versão compatível do IDT-FreeRTOS e extraia o arquivo baixado em um local em seu sistema de arquivos onde existam permissões de leitura e gravação.
1. Execute o comando a seguir para navegar até o diretório de instalação do IDT-FreeRTOS:
```
cd devicetester-extract-location/bin
```
1. Execute o comando a seguir para abrir a interface de usuário do IDT-FreeRTOS:
------
#### [ Linux ]
```
.devicetestergui_linux_x86-64.exe
```
------
#### [ Windows ]
```
./devicetestergui_win_x64-64
```
------
#### [ macOS ]
```
./devicetestergui_mac_x86-64
```
**nota**
No Mac, para permitir que seu sistema execute a interface do usuário, acesse **Preferências do sistema -> Segurança e privacidade**. Ao executar os testes, é aconselhável repeti-los mais três vezes.
------
A interface de usuário do IDT-FreeRTOS é aberta em seu navegador padrão. Para obter informações sobre os navegadores compatíveis, consulte [Usar um navegador da web compatível](dev-tester-ui-prereqs.md#idt-ui-supported-web-browser).
## Criar uma configuração
Se for um usuário iniciante, deverá criar uma nova configuração para definir os arquivos de configuração JSON que o IDT-FreeRTOS exige para executar testes. Em seguida, você pode executar testes ou modificar a configuração criada.
Para obter exemplos dos arquivos `config.json`, `device.json` e `userdata.json`, consulte [Primeiro teste da sua placa de microcontrolador](qual-steps.md). Para obter um exemplo do arquivo `resource.json` usado somente para executar testes de Bluetooth Low Energy (BLE), consulte [Executar testes de Bluetooth Low Energy](afr-bridgekeeper-dt-bt.md).
**Como criar uma configuração**
1. Na interface de usuário do IDT-FreeRTOS, abra o menu de navegação e escolha **Criar configuração**.
**Importante**
Você deve configurar suas AWS credenciais antes de abrir a interface do usuário. Se não configurou suas credenciais, feche a janela do navegador da interface de usuário do IDT-FreeRTOS, siga as etapas em [Configurar AWS credenciais](#configure-aws-credentials) e reabra a interface de usuário do IDT-FreeRTOS.
1. Siga o assistente de configuração para inserir as configurações do IDT que são usadas para executar os testes de qualificação. O assistente define as seguintes configurações nos arquivos de configuração JSON localizados no diretório `devicetester-extract-location/config`.
+ **AWS settings — As** Conta da AWS informações que o IDT-FreeRTOS usa para criar AWS recursos durante as execuções de teste. Essas configurações são definidas no arquivo `config.json`.
+ **Repositório FreeRTOS**: o caminho absoluto para o repositório e o código portado do FreeRTOS, e o tipo de qualificação que você deseja realizar. Essas configurações são definidas no arquivo `userdata.json`.
Você deve transferir o FreeRTOS para o seu dispositivo antes de executar os testes de qualificação. Para obter mais informações, consulte o [Guia de portabilidade do FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/)
+ **Compilar e atualizar**: os comandos de compilação e atualização para seu hardware que permitem que o IDT compile e instale testes em sua placa automaticamente. Essas configurações são definidas no arquivo `userdata.json`.
+ **Dispositivos**: as configurações do grupo de dispositivos para os dispositivos a serem testados. Essas configurações são definidas nos campos `id` e `sku` no bloco `devices` do grupo de dispositivos no arquivo `device.json`.
+ **Rede**: as configurações para testar o suporte de comunicação de rede para seus dispositivos. Essas configurações são definidas no bloco `features` do arquivo `device.json` e nos blocos `clientWifiConfig` e `testWifiConfig` do arquivo `userdata.json`.
+ **Servidor echo**: as configurações do servidor echo para testes de soquete seguros. Essas configurações são definidas no arquivo `userdata.json`.
Para obter mais informações sobre a configuração do servidor echo, consulte [https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html).
+ **CMake**— (Opcional) As configurações para executar testes de funcionalidade de CMake compilação. Essa configuração é necessária somente se você estiver usando CMake como seu sistema de compilação. Essas configurações são definidas no arquivo `userdata.json`.
+ **BLE**: as configurações para executar testes de funcionalidade Bluetooth Low Energy. Essas configurações são definidas no bloco `features` do arquivo `device.json` e no arquivo `resource.json`.
+ **OTA**: as configurações para executar testes de funcionalidade OTA. Essas configurações são definidas no bloco `features` do arquivo `device.json` e no arquivo `userdata.json`.
1. Na página **Revisar**, verifique suas informações de configuração.
Depois de concluir a revisão da configuração, para executar os testes de qualificação, escolha **Executar testes**.
## Modificar uma configuração existente
Se já configurou os arquivos de configuração para o IDT, pode usar a interface de usuário do IDT-FreeRTOS para modificar a configuração existente. Verifique se os arquivos de configuração existentes estão disponíveis no diretório `devicetester-extract-location/config`.
**Como modificar uma configuração nova**
1. Na interface de usuário do IDT-FreeRTOS, abra o menu de navegação e escolha **Editar configuração existente**.
O painel de configuração exibe informações sobre suas configurações existentes. Se uma configuração estiver incorreta ou indisponível, o status dessa configuração será `Error validating configuration`.
1. Para modificar uma configuração existente, conclua estas etapas:
1. Escolha o nome de uma configuração para abrir sua página de ajustes.
1. Modifique as configurações e escolha **Salvar** para regenerar o arquivo de configuração correspondente.
Depois de concluir a modificação da configuração, verifique se todas as configurações passaram pela validação. Se o status de cada configuração for `Valid`, será possível executar seus testes de qualificação usando essa configuração.
## Execute testes de qualificação
Depois de criar uma configuração para o IDT-FreeRTOS, é possível executar seus testes de qualificação.
**Como executar testes de qualificação**
1. Para validar a configuração.
1. No menu de navegação, escolha **Executar testes**.
1. Escolha **Iniciar testes** para iniciar a execução do teste.
O IDT-FreeRTOS executa os testes de qualificação e exibe o resumo da execução do teste e quaisquer erros no console do **Executor de testes**. Depois que a execução do teste for concluída, você poderá visualizar os resultados e os logs do teste nos seguintes locais:
+ Os resultados dos testes estão localizados no diretório `devicetester-extract-location/results/execution-id`.
+ Os logs de teste estão localizados no diretório `devicetester-extract-location/results/execution-id/logs`.
Para obter mais informações sobre os resultados de teste e logs, consulte [Veja os resultados do IDT para FreeRTOS](view-results-frq.md) e [Exibir os logs do IDT para FreeRTOS](view-logs-frq.md).
# Executar testes de Bluetooth Low Energy
Esta seção descreve como configurar e executar testes Bluetooth Low Energy usando AWS IoT Device Tester FreeRTOS.
Os testes Bluetooth não são necessários para a qualificação principal. Se você não deseja testar seu dispositivo com o suporte a Bluetooth do FreeRTOS, pode ignorar esta configuração. Deixe o recurso BLE no device.json definido como `No`.
## Pré-requisitos
+ Siga as instruções em [Primeiro teste da sua placa de microcontrolador](qual-steps.md).
+ Um Raspberry Pi 4B ou 3B\$1. (Obrigatório para executar a aplicação complementar Raspberry Pi BLE)
+ Um micro cartão SD e adaptador de cartão SD para o software Raspberry Pi.
## Configuração do Raspberry Pi
Para testar os recursos de BLE do dispositivo em teste (DUT), você deve ter um Raspberry Pi Modelo 4B ou 3B\$1.
**Para configurar o Raspberry Pi para executar testes de BLE**
1. Baixe uma das imagens Yocto personalizadas que contenham o software necessário para executar os testes.
+ [Imagem para Raspberry Pi 4B](https://docs.aws.amazon.com/freertos/latest/userguide/freertos/IDTFR_BLE_RaspberryPi4B_1.0.0_2021-04-13.rpi-sd.img)
+ [Imagem para Raspberry Pi 3B\$1](https://docs.aws.amazon.com/freertos/latest/userguide/freertos/IDTFR_BLE_RaspberryPi3Bplus_1.0.0_2021-04-13.rpi-sd.img)
**nota**
A imagem do Yocto só deve ser usada para testes com AWS IoT Device Tester FreeRTOS e não para qualquer outra finalidade.
1. Atualize a imagem yocto no cartão SD do Raspberry Pi.
1. Usando uma ferramenta de gravação de cartão SD, como [Etcher](https://www.balena.io/etcher), instale o arquivo `image-name.rpi-sd.img` obtido por download no cartão SD. Como a imagem do sistema operacional é grande, essa etapa deve levar algum tempo. Depois ejete seu cartão SD do computador e insira o cartão microSD no seu Raspberry Pi.
1. Configure seu Raspberry Pi.
1. Durante a primeira inicialização, recomendamos que você conecte o Raspberry Pi a um monitor, teclado e mouse.
1. Conecte seu Raspberry Pi a uma fonte de alimentação micro USB.
1. Faça login usando as credenciais padrão. Para ID de usuário, insira **root**. Para senha, insira **idtafr**.
1. Usando uma conexão Wi-Fi ou Ethernet, conecte o Raspberry Pi à sua rede.
1. Para conectar seu Raspberry Pi por Wi-Fi, abra `/etc/wpa_supplicant.conf` no Raspberry Pi e adicione suas credenciais Wi-Fi à configuração de `Network`.
```
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
update_config=1
network={
scan_ssid=1
ssid="your-wifi-ssid"
psk="your-wifi-password"
}
```
1. Execute `ifup wlan0` para iniciar a conexão Wi-Fi. Pode levar alguns minutos para se conectar à sua rede Wi-Fi.
1. Para uma conexão Ethernet, execute `ifconfig eth0`. Para uma conexão Wi-Fi, execute `ifconfig wlan0`. Anote o endereço IP, que aparece como `inet addr` na saída do comando. Você precisa do endereço IP posteriormente neste procedimento.
1. (Opcional) Os testes executam comandos no Raspberry Pi sobre SSH usando as credenciais padrão para a imagem yocto. Para segurança adicional, recomendamos que você configure a autenticação de chave pública para SSH e desative o SSH baseado em senha.
1. Crie uma chave SSH usando o comando OpenSSL `ssh-keygen`. Se você já tem um par de chaves SSK no seu computador host, é uma prática recomendada criar um novo AWS IoT Device Tester para permitir que os FreeRTOS façam login no seu Raspberry Pi.
**nota**
O Windows não vem com um cliente SSH instalado. Para obter informações sobre como instalar um cliente SSH no Windows, consulte [Como fazer download do software SSH](https://www.ssh.com/ssh/#sec-Download-client-software).
1. 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\user-name`.
1. Quando uma frase-chave for solicitada, bastará pressionar ENTER para continuar.
1. Para adicionar sua chave SSH ao Raspberry Pi para que os AWS IoT Device Tester FreeRTOS possam entrar no dispositivo, use o comando do seu computador host. `ssh-copy-id` Esse comando adiciona sua chave pública ao arquivo `~/.ssh/authorized_keys` no seu Raspberry Pi.
`ssh-copy-id root@raspberry-pi-ip-address`
1. Quando solicitado a inserir uma senha, digite **idtafr**. Essa é a senha padrão para a imagem yocto.
**nota**
O comando `ssh-copy-id` pressupõe que a chave pública é chamada `id_rsa.pub`. No macOS e Linux, o local padrão é ` ~/.ssh/`. No Windows, o local padrão é `C:\Users\user-name\.ssh`. 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 ~/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).
1. Para testar se a autenticação da chave pública está funcionando, execute `ssh -i /my/path/myKey root@raspberry-pi-device-ip`.
Se você não receber uma solicitação de senha, a autenticação de chave pública está funcionando.
1. Verifique se é possível fazer login no seu Raspberry Pi usando uma chave pública e, depois, desative o SSH baseado em senha.
1. No Raspberry Pi, edite o arquivo `/etc/ssh/sshd_config`.
1. Defina o recurso `PasswordAuthentication` como `no`.
1. Salve e feche o arquivo `sshd_config`.
1. Recarregue o servidor SSH executando `/etc/init.d/sshd reload`.
1. Crie um arquivo `resource.json`.
1. No diretório em que você extraiu o AWS IoT Device Tester, crie um arquivo chamado. `resource.json`
1. Adicione as seguintes informações sobre seu Raspberry Pi ao arquivo, *rasp-pi-ip-address* substituindo-as pelo endereço IP do seu Raspberry Pi.
```
[
{
"id": "ble-test-raspberry-pi",
"features": [
{"name":"ble", "version":"4.2"}
],
"devices": [
{
"id": "ble-test-raspberry-pi-1",
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address"
}
}
]
}
]
```
1. Se você decidir não usar a autenticação de chave pública para SSH, adicione o seguinte à seção `connectivity` do arquivo `resource.json`.
```
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address",
"auth": {
"method": "password",
"credentials": {
"user": "root",
"password": "idtafr"
}
}
}
```
1. (Opcional) Se você decidir usar a autenticação de chave pública para SSH, adicione o seguinte à seção `connectivity` do arquivo `resource.json`.
```
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address",
"auth": {
"method": "pki",
"credentials": {
"user": "root",
"privKeyPath": "location-of-private-key"
}
}
}
```
## Configuração do dispositivo do FreeRTOS
No seu arquivo `device.json`, defina o recurso `BLE` como `Yes`. Se você estiver começando com um arquivo `device.json` de antes de os testes de Bluetooth estarem disponíveis, é preciso adicionar o recurso para o BLE à matriz `features`:
```
{
...
"features": [
{
"name": "BLE",
"value": "Yes"
},
...
}
```
## Executar os testes do BLE
Depois de habilitar o recurso BLE no `device.json`, os testes BLE serão executados quando você executar `devicetester_[linux | mac | win_x86-64] run-suite` *sem especificar um group-id*.
Se você quiser executar os testes BLE separadamente, poderá especificar o ID do grupo para o BLE: `devicetester_[linux | mac | win_x86-64] run-suite --userdata path-to-userdata/userdata.json --group-id FullBLE`.
Para o desempenho mais confiável, coloque o Raspberry Pi próximo do dispositivo em teste (DUT).
## Solução de problemas de testes de BLE
Siga as etapas em [Primeiro teste da sua placa de microcontrolador](qual-steps.md). Se testes diferentes de BLE estiverem falhando, é mais provável que o problema não seja decorrente da configuração do Bluetooth.
# Executar o pacote de qualificação do FreeRTOS
Você usa o executável AWS IoT Device Tester for FreeRTOS para interagir com o IDT for FreeRTOS. Os exemplos de linha de comando a seguir mostram como executar os testes de qualificação para um grupo de dispositivos (um conjunto de dispositivos idênticos).
------
#### [ IDT v3.0.0 and later ]
```
devicetester_[linux | mac | win] run-suite \
--suite-id suite-id \
--group-id group-id \
--pool-id your-device-pool \
--test-id test-id \
--upgrade-test-suite y|n \
--update-idt y|n \
--update-managed-policy y|n \
--userdata userdata.json
```
Executa um conjunto de testes em um grupo de dispositivos. O arquivo `userdata.json` deve estar localizado no diretório `devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/`.
**nota**
Se estiver executando o IDT para FreeRTOS no Windows, use barras (/) para especificar o caminho até o arquivo `userdata.json`.
Use o seguinte comando para executar um grupo de testes específico:
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1.0.1 \
--group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
Os parâmetros `suite-id` e `pool-id` são opcionais se você estiver executando um único conjunto de testes em um único grupo de dispositivos (ou seja, você tem apenas um grupo de dispositivos definido no arquivo `device.json`).
Use o seguinte comando para executar um caso de teste em um grupo de testes:
```
devicetester_[linux | mac | win_x86-64] run-suite \
--group-id group-id \
--test-id test-id
```
Você pode usar o comando `list-test-cases` para listar os casos de teste em um grupo de testes. Opções de linhas de comando do IDT para FreeRTOS
**group-id**
(Opcional) Os grupos de testes a serem executados, como uma lista separada por vírgulas. Se não for especificado, o IDT executará todos os grupos de testes no conjunto de testes.
**pool-id**
(Opcional) O grupo de dispositivos a ser testado. Isso será necessário se você definir vários grupos de dispositivos no `device.json`. Se você tiver apenas um grupo de dispositivos, poderá omitir essa opção.
**suite-id**
(Opcional) A versão do conjunto de testes a ser executada. Se não for especificada, o IDT usará a versão mais recente no diretório de testes em seu sistema.
Começando com o IDT v3.0.0, o IDT verifica se há conjuntos de testes mais recentes online. Para obter mais informações, consulte [Versões do pacote de testes](idt-test-suite-versions.md).
**test-id**
(Opcional) Os testes a serem executados, como uma lista separada por vírgulas. Se especificado, `group-id` deve especificar um único grupo.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id mqtt --test-id mqtt_test
```
**update-idt**
(Opcional) Se este parâmetro não estiver definido e houver uma versão mais recente do IDT disponível, será solicitado atualizar o IDT. Se esse parâmetro for definido como `Y`, o IDT interromperá a execução do teste se detectar que uma versão mais recente está disponível. Se esse parâmetro for definido como `N`, o IDT continuará a execução do teste.
**update-managed-policy**
(Opcional) Se esse parâmetro não for usado e o IDT detectar que sua política gerenciada não é up-to-date, você será solicitado a atualizar sua política gerenciada. Se esse parâmetro for definido como`Y`, o IDT interromperá a execução do teste se detectar que sua política gerenciada não está. up-to-date Se esse parâmetro for definido como `N`, o IDT continuará a execução do teste.
**upgrade-test-suite**
(Opcional) Se não for usado e uma versão mais recente do conjunto de testes estiver disponível, você será solicitado a fazer download. Para ocultar o prompt, especifique `y` para sempre fazer download do conjunto de testes mais recente, ou `n` para usar o conjunto de testes especificado ou a versão mais recente em seu sistema.
**Example**
**Exemplo**
Para sempre fazer download e usar o conjunto de testes mais recente, use o seguinte comando.
```
devicetester_[linux | mac | win_x86-64] run-suite --userdata userdata file --group-id group ID --upgrade-test-suite y
```
Para usar o conjunto de testes mais recente em seu sistema, use o seguinte comando.
```
devicetester_[linux | mac | win_x86-64] run-suite --userdata userdata file --group-id group ID --upgrade-test-suite n
```
**h**
Use a opção de ajuda para saber mais sobre as opções de `run-suite`.
**Example**
**Exemplo**
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
------
#### [ IDT v1.7.0 and earlier ]
```
devicetester_[linux | mac | win] run-suite \
--suite-id suite-id \
--pool-id your-device-pool \
--userdata userdata.json
```
O arquivo `userdata.json` deve estar localizado no diretório `devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/`.
**nota**
Se você estiver executando o IDT para FreeRTOS no Windows, use barras (/) para especificar o caminho até o arquivo `userdata.json`.
Use o seguinte comando para executar um grupo de testes específico.
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1 --group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
`suite-id` e `pool-id` são opcionais se você estiver executando um único conjunto de testes em um único grupo de dispositivos (ou seja, você tem apenas um grupo de dispositivos definido no arquivo `device.json`).Opções de linhas de comando do IDT para FreeRTOS
**group-id**
(Opcional) Especifica o grupo de testes.
**pool-id**
Especifica o grupo de dispositivos para testar. Se você tiver apenas um grupo de dispositivos, poderá omitir essa opção.
**suite-id**
(Opcional) Especifica o conjunto de testes a ser executado.
------
## Comandos do IDT para FreeRTOS
O comando do IDT para FreeRTOS é compatível com 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.
**`list-suites`**
Lista os conjuntos disponíveis.
**`list-supported-products`**
Lista os produtos compatíveis e as versões do conjunto de testes.
**`list-supported-versions`**
Lista as versões do FreeRTOS e do pacote de teste compatíveis com a versão atual do IDT.
**`list-test-cases`**
Lista os casos de teste em um grupo especificado.
**`run-suite`**
Executa um conjunto de testes em um grupo de dispositivos.
Use a opção `--suite-id` para especificar uma versão do conjunto de testes, ou omiti-la para usar a versão mais recente em seu sistema.
Use o `--test-id` para executar um caso de teste individual.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id mqtt --test-id mqtt_test
```
Para obter uma lista completa de opções, consulte [Executar o pacote de qualificação do FreeRTOS](#run-tests).
Começando com o IDT v3.0.0, o IDT verifica se há conjuntos de testes mais recentes online. Para obter mais informações, consulte [Versões do pacote de testes](idt-test-suite-versions.md).
------
#### [ IDT v1.7.0 and earlier ]
**`help`**
Lista as informações sobre o comando especificado.
**`list-groups`**
Lista os grupos em um determinado conjunto.
**`list-suites`**
Lista os conjuntos disponíveis.
**`run-suite`**
Executa um conjunto de testes em um grupo de dispositivos.
------
## Teste para requalificação
À medida que novas versões de testes de qualificação do IDT para FreeRTOS são lançadas, ou ao atualizar os pacotes ou drivers de dispositivo específicos da placa, você pode usar o IDT para FreeRTOS para testar as placas do microcontrolador. Para qualificações subsequentes, certifique-se de que tem as versões mais recentes do FreeRTOS e do IDT para FreeRTOS e execute os testes de qualificação novamente.
# Veja os resultados do IDT para FreeRTOS
Enquanto em execução, o IDT grava erros no console, arquivos de log e relatórios de teste. Depois de concluir o pacote de teste de qualificação, O IDT gravará um resumo da execução de teste no console e gerará dois relatórios de teste. Esses relatórios podem ser encontrados em `devicetester-extract-location/results/execution-id/`. 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 dispositivo no Catálogo de dispositivos do AWS parceiro. O relatório contém os seguintes elementos:
+ A versão do IDT para FreeRTOS.
+ A versão do FreeRTOS que foi testada.
+ Os recursos do FreeRTOS que são compatíveis com o dispositivo com base nos testes aprovados.
+ A SKU e o nome do dispositivo especificados no arquivo `device.json`.
+ Os recursos do dispositivo especificados no arquivo `device.json`.
+ O resumo agregado dos resultados de casos de teste.
+ Um detalhamento dos resultados dos casos de teste por bibliotecas que foram testadas com base nos recursos do dispositivo (por exemplo FullWiFi, FullMQTT e assim por diante).
+ Caso essa qualificação do FreeRTOS seja para a versão 202012.00 que usa bibliotecas LTS.
`FRQ_Report.xml`É um relatório em [formato JUnit XML](https://llg.cubic.org/docs/junit/) padrão. Você pode integrá-lo em CI/CD plataformas 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 casos de teste.
+ Um detalhamento dos resultados de casos de teste por bibliotecas que foram testadas com base nos recursos do dispositivo.
# Interpretar os resultados do IDT para FreeRTOS
A seção de relatório em `awsiotdevicetester_report.xml` ou em `FRQ_Report.xml` lista os resultados dos testes que são executados.
A primeira tag XML `` contém o resumo geral da execução do teste. Por exemplo:
``
**Atributos 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 casos de teste executados.
**`failures`**
O número de casos de teste que foram executados, mas não foram aprovados.
**`errors`**
O número de casos de teste que o IDT para FreeRTOS não pôde executar.
**`disabled`**
Esse recurso não é usado e pode ser ignorado.
Se não houver falhas ou erros no caso de teste, seu dispositivo atende aos requisitos técnicos para executar Freertos e pode interoperar com os serviços. AWS IoT Se você optar por listar seu dispositivo no Catálogo de dispositivos do AWS parceiro, poderá usar esse relatório como evidência de qualificação.
Se houver falhas de caso de teste ou erros, você poderá identificar o caso de teste com falha analisando as tags XML ``. As tags XML `` dentro da tag `` mostram o resumo do resultado do caso de teste para um grupo de testes.
``
O formato é semelhante à tag ``, mas com um recurso chamado `skipped` que não é usado e pode ser ignorado. Dentro de cada tag XML ``, há tags `` para cada um dos casos de teste que foram executados para um grupo de testes. Por exemplo:
``
**Atributos usados na tag ``**
**`name`**
O nome do produto testado.
**`version`**
A versão do produto testado.
**`sdk`**
Se você executou o IDT com um SDK, esse bloco contém o nome e a versão do seu SDK. Se você não executou o IDT com um SDK, esse bloco contém:
```
N/A
N/A
```
**`features`**
Os recursos validados. recursos marcados como `required` são necessários para enviar sua placa para qualificação. O snippet a seguir mostra como essas informações aparecem no arquivo `awsiotdevicetester_report.xml`.
```
```
Os recursos marcados como `optional` não são necessários para qualificação. Os seguintes trechos mostram recursos opcionais.
```
```
Se não há falhas de teste ou erros nos recursos exigidos, seu dispositivo atende aos requisitos técnicos para executar o FreeRTOS e pode interoperar com serviços do AWS IoT . Se quiser listar o dispositivo no [AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices), poderá usar este 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 tem 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:
```
```
**`lts`**
Verdadeiro se a qualificação for para uma versão do FreeRTOS que usa bibliotecas LTS; caso contrário, falso.
**Atributos usados na tag ``**
**`name`**
O nome do caso de teste.
**`attempts`**
O número de vezes que o IDT para FreeRTOS 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 case failure
Reason for the test case execution error
```
Para obter mais informações, consulte [Solucionar erros](dt-afr-troubleshooting.md).
# Exibir os logs do IDT para FreeRTOS
É possível encontrar os logs que o IDT para FreeRTOS gera ao executar testes em `devicetester-extract-location/results/execution-id/logs`. Dois conjuntos de logs são gerados:
**`test_manager.log`**
Contém logs gerados de IDT para FreeRTOS (por exemplo, logs relacionados à configuração e geração de relatórios).
**`test_group_id__test_case_id.log` (por exemplo: `FullMQTT__Full_MQTT.log`)**
O arquivo de log para um caso de teste, incluindo a saída do dispositivo em teste. O arquivo de log é nomeado de acordo com o grupo de teste e com o caso de teste que foi executado.
# Desenvolver e executar os próprios pacotes de testes do IDT
Começando do IDT v4.0.0, o IDT para FreeRTOS combina uma configuração padronizada e um formato de resultado com um ambiente de conjunto de testes que permite desenvolver conjuntos de testes personalizados 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 pacotes de teste personalizados****
+ Crie pacotes de teste com lógica de testes personalizada para o dispositivo que deseja testar.
+ Forneça ao IDT os pacotes de testes personalizados para os executores de teste. 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 FreeRTOS
Baixe a [versão mais recente](dev-test-versions-afr.md#idt-latest-version-afr) 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 dos pacotes de teste
Os pacotes de teste são compostos por três tipos de arquivos:
+ Arquivos de configuração que fornecem ao IDT informações sobre como executar o pacote de teste.
+ Os 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. [Crie arquivos de configuração](idt-json-config.md) para seu pacote de teste.
1. [Crie executáveis de casos de teste](test-executables.md) que contenham a lógica de teste para seu pacote de teste.
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 teste de amostra do IDT](build-sample-suite.md).
Para começar a criar um pacote de teste personalizado em Python, consulte [Tutorial: desenvolva um pacote de teste simples do IDT](create-custom-tests.md).
# Tutorial: compile e execute o pacote de teste de amostra do IDT
O AWS IoT Device Tester download 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 você pode usar o FreeRTOS AWS IoT Device Tester para executar suítes de testes personalizadas. Embora este tutorial use SSH, é útil aprender a usar AWS IoT Device Tester com dispositivos FreeRTOS.
Neste tutorial, você concluirá as seguintes etapas:
1. [Compile o pacote de teste de amostra](build-sample.md)
1. [Usar o IDT para executar o pacote de teste de amostra](run-sample.md)
**Topics**
+ [Configurar os pré-requisitos para o pacote de teste de amostra](prereqs-tutorial-sample.md)
+ [Configurar as informações do dispositivo para o IDT](configure-idt-sample.md)
+ [Compile o pacote de teste de amostra](build-sample.md)
+ [Usar o IDT para executar o pacote de teste de amostra](run-sample.md)
+ [Solucionar erros](tutorial-troubleshooting-custom.md)
# Configurar os pré-requisitos para o pacote de teste de amostra
Para concluir este tutorial, você precisará do seguinte:
+
**Requisitos do computador host**
+ Versão mais recente do AWS IoT Device Tester
+ [Python](https://docs.python.org/3/) 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/3/).
+ [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.com/documentation/computers/remote-access.html) 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 pacote de teste de amostra está estruturado e para ver vários exemplos de executáveis de casos de teste e arquivos de configuração de teste.
**nota**
O pacote de teste de amostra inclui um código-fonte em Python. Não inclua informações confidenciais no código do seu pacote de teste.
Próxima etapa: use o IDT para [executar o pacote de teste de amostra](run-sample.md) criada.
# 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 AWS 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
```
# Solucionar erros
Use as informações a seguir para ajudar a resolver os problemas ao concluir o tutorial.
**O caso de teste não foi executado com êxito**
+ 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.md) 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.
+ Também é possível se conectar ao seu dispositivo via SSH do seu computador host.
# Tutorial: desenvolva um pacote de teste simples do IDT
Um conjunto de testes combina o seguinte:
+ Executável de teste que contém a lógica de teste
+ Arquivos de configuração que descrevem o pacote de teste
Este tutorial mostra como usar o IDT para FreeRTOS para desenvolver um pacote de teste em Python contendo um caso de teste único. Embora este tutorial use SSH, é útil aprender a usar AWS IoT Device Tester com dispositivos FreeRTOS.
Neste tutorial, você concluirá as seguintes etapas:
1. [Crie um diretório de pacotes de teste](test-suite-dir.md)
1. [Crie arquivos de configuração](test-suite-json.md)
1. [Crie o executável do caso de teste](test-suite-exe.md)
1. [Execute o pacote de teste](run-test-suite.md)
Siga as etapas abaixo para concluir um tutorial sobre como desenvolver um pacote de teste do IDT simples.
**Topics**
+ [Configurar os pré-requisitos para um pacote de teste do IDT simples](prereqs-tutorial-custom.md)
+ [Crie um diretório de pacotes de teste](test-suite-dir.md)
+ [Crie arquivos de configuração](test-suite-json.md)
+ [Obtenha o SDK do cliente do IDT](add-idt-sdk.md)
+ [Crie o executável do caso de teste](test-suite-exe.md)
+ [Configurar as informações do dispositivo para o IDT](configure-idt-sample2.md)
+ [Execute o pacote de teste](run-test-suite.md)
+ [Solucionar erros](tutorial-troubleshooting.md)
+ [Criação de arquivos de configuração do conjunto de testes do IDT](idt-json-config.md)
+ [Configure o orquestrador de testes do IDT](idt-test-orchestrator.md)
+ [Configurar a máquina de estado do IDT](idt-state-machine.md)
+ [Crie um executável de caso de teste do IDT](test-executables.md)
+ [Use o contexto do IDT](idt-context.md)
+ [Definir configurações para os executores de teste](set-config-custom.md)
+ [Depure e execute pacotes de teste personalizados](run-tests-custom.md)
+ [Analise os resultados e logs dos testes do IDT](idt-review-results-logs.md)
+ [Enviar métricas de uso do IDT](idt-usage-metrics.md)
# Configurar os pré-requisitos para um pacote de teste do IDT simples
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/3/).
+ [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.com/documentation/computers/remote-access.html) 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 nesta pasta:
```
MyTestSuite_1.0.0
└── suite
└── myTestGroup
└── myTestCase
```
# Crie arquivos de configuração
Seu pacote de teste deve conter os seguintes [arquivos de configuração](idt-json-config.md) necessários:
**Arquivos necessários**
**`suite.json`**
Contém informações sobre o pacote de teste. Consulte [Configurar 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 AWS 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
```
# Solucionar erros
Use as informações a seguir para ajudar a resolver os problemas ao concluir o tutorial.
**O caso de teste não foi executado com êxito**
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 em [Obtenha o SDK do cliente do IDT](add-idt-sdk.md).
+ Você atende a todos os pré-requisitos deste tutorial. Para obter mais informações, consulte [Configurar os pré-requisitos para um pacote de teste do IDT simples](prereqs-tutorial-custom.md).
**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.
+ Também é possível se conectar ao seu dispositivo via SSH do seu computador host.
# Criação de arquivos de configuração do conjunto de testes do IDT
Esta seção descreve os formatos nos quais você cria arquivos de configuração incluídos ao escrever um pacote de teste personalizado.
**Arquivos de configuração necessária**
**`suite.json`**
Contém informações sobre o pacote de teste. Consulte [Configurar 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 de configuração opcional**
**`test_orchestrator.yaml` ou `state_machine.json`**
Define como os testes são executados quando o IDT executa o conjunto de testes. SSe [Configurar test\$1orchestrator.yaml](#test-orchestrator-config).
Desde o IDT v4.5.2, você usa o arquivo `test_orchestrator.yaml` para definir o fluxo de trabalho de testes. Nas versões anteriores do IDT, você usa o arquivo `state_machine.json`. Para obter informações sobre a máquina de estado, consulte [Configurar a máquina de estado do IDT](idt-state-machine.md).
**`userdata_schema.json`**
Define o esquema do [arquivo `userdata.json`](set-config-custom.md#userdata-config-custom) que os executores de teste podem incluir na 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 [Configurar userdata\$1schema.json](#userdata-schema-json).
Os arquivos de configuração JSON são colocados no seu ``, conforme mostrado aqui.
```
└── suite
├── suite.json
├── test_orchestrator.yaml
├── userdata_schema.json
├──
├── group.json
├──
└── test.json
```
## Configurar 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`**
Um ID exclusivo, definido pelo usuário, para o grupo de teste. O valor de `id` deve corresponder ao nome da pasta do grupo de teste na qual o arquivo `group.json` está localizado e não deve ter sublinhados (`_`). O ID é usado 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 [Crie um executável de caso 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`**
Um ID exclusivo, definido 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 ter sublinhados (`_`). O ID é usado 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 [Crie um executável de caso 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 especificar a mesma variável de ambiente no arquivo `test.json` e no arquivo `suite.json`, o valor no arquivo `test.json` terá precedência.
## Configurar test\$1orchestrator.yaml
Um orquestrador de teste é 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 um orquestrador de testes definido pelo usuário, o IDT gerará um orquestrador de testes para você.
O orquestrador de teste 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.
Para obter mais informações sobre como o orquestrador de testes do IDT funciona, consulte [Configure o orquestrador de testes do IDT](idt-test-orchestrator.md).
## Configurar 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#draft-4).
Quando o IDT executa seu pacote de teste, ele lê automaticamente o esquema e o usa para validar o arquivo `userdata.json` fornecido pelo executor do teste. Se válido, o conteúdo do arquivo `userdata.json` estará disponível no [contexto do IDT](idt-context.md) e no [contexto do orquestrador de testes](idt-test-orchestrator.md#idt-test-orchestrator-context).
# Configure o orquestrador de testes do IDT
Desde o IDT v4.5.2, o IDT inclui um novo componente *orquestrador de testes*. O orquestrador de testes é um componente do IDT que controla o fluxo de execução do pacote de teste e gera o relatório de teste depois que o IDT termina de executar todos os testes. O orquestrador de testes determina a seleção do teste e a ordem na qual os testes são executados com base nas regras definidas pelo usuário.
Se seu pacote de teste não incluir um orquestrador de testes definido pelo usuário, o IDT gerará um orquestrador de testes para você.
O orquestrador de teste 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.
O orquestrador de teste substitui a máquina de estado do IDT. É recomendado utilizar a versão mais recente do orquestrador de testes para desenvolver seus pacotes de teste em vez da máquina de estado do IDT. O orquestrador de testes fornece os seguintes recursos aprimorados:
+ Usa um formato declarativo em comparação com o formato imperativo que a máquina de estado do IDT usa. Isto permite que especificar quais testes deseja executar e quando deseja executá-los.
+ Gerencia o tratamento de grupos específicos, a geração de relatórios, o tratamento de erros e o rastreamento de resultados para que você não precise gerenciar manualmente essas ações.
+ Usa o formato YAML, que é compatível com comentários por padrão.
+ Requer 80% menos espaço em disco do que o orquestrador de teste para definir o mesmo fluxo de trabalho.
+ Adiciona validação de pré-teste para verificar se a definição do fluxo de trabalho não contém dependências circulares IDs ou de teste incorretas.
## Formato do orquestrador de testes
É possível usar o modelo a seguir para configurar seu próprio arquivo `custom-test-suite-folder/suite/test_orchestrator.yaml`:
```
Aliases:
string: context-expression
ConditionalTests:
- Condition: context-expression
Tests:
- test-descriptor
Order:
- - group-descriptor
- group-descriptor
Features:
- Name: feature-name
Value: support-description
Condition: context-expression
Tests:
- test-descriptor
OneOfTests:
- test-descriptor
IsRequired: boolean
```
Todos os campos que contêm valores são necessários, conforme descrito aqui:
`Aliases`
Opcional. Strings definidas pelo usuário que são mapeadas para expressões de contexto. Os aliases permitem que você gere nomes amigáveis para identificar expressões de contexto na configuração do orquestrador de teste. Isto é muito útil se estiver criando expressões de contexto complexas ou expressões usadas em vários lugares.
É possível usar expressões de contexto para armazenar consultas de contexto que permitem acessar dados de outras configurações do IDT. Para obter mais informações, consulte [Acesse dados no contexto](idt-context.md#accessing-context-data).
**Example**
**Exemplo**
```
Aliases:
FizzChosen: "'{{$pool.features[?(@.name == 'Fizz')].value[0]}}' == 'yes'"
BuzzChosen: "'{{$pool.features[?(@.name == 'Buzz')].value[0]}}' == 'yes'"
FizzBuzzChosen: "'{{$aliases.FizzChosen}}' && '{{$aliases.BuzzChosen}}'"
```
`ConditionalTests`
Opcional. Uma lista de condições e os casos de teste correspondentes que são executados quando cada condição é atendida. Cada condição pode ter vários casos de teste. No entanto, só é possível atribuir um determinado caso de teste a uma condição.
Por padrão, o IDT executa qualquer caso de teste que não esteja atribuído a uma condição nessa lista. Se não especificar essa seção, o IDT executará todos os grupos de teste no pacote de teste.
Cada item da lista `ConditionalTests` inclui os seguintes parâmetros:
`Condition`
Uma expressão de contexto que deve ser avaliada para um valor booleano. Se o valor avaliado for verdadeiro, o IDT executará os casos de teste especificados no parâmetro `Tests`.
`Tests`
A lista dos descritores de teste.
Cada descritor de teste usa o ID do grupo de teste e um ou mais casos de teste IDs para identificar os testes individuais a serem executados a partir de um grupo de teste específico. O descritor de teste usa o seguinte formato:
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
**Example**
**Exemplo**
O exemplo a seguir usa expressões de contexto genéricas que podem ser definidas como `Aliases`.
```
ConditionalTests:
- Condition: "{{$aliases.Condition1}}"
Tests:
- GroupId: A
- GroupId: B
- Condition: "{{$aliases.Condition2}}"
Tests:
- GroupId: D
- Condition: "{{$aliases.Condition1}} || {{$aliases.Condition2}}"
Tests:
- GroupId: C
```
Com base nas condições definidas, o IDT seleciona os grupos de teste da seguinte forma:
+ Se `Condition1` for verdade, o IDT executa os testes nos grupos de teste A, B e C.
+ Se `Condition2` for verdade, o IDT executa os testes nos grupos de teste C e D.
`Order`
Opcional. A ordem em que os testes serão executados. Especifique a ordem do teste no nível do grupo de teste. Se não especificar essa seção, o IDT executará todos os grupos de teste aplicáveis em uma ordem aleatória. O valor de `Order` é uma lista de listas de descritores de grupos. Qualquer grupo de teste que não esteja listado em `Order` pode ser executado em paralelo com qualquer outro grupo de teste listado.
Cada lista de descritores de grupo contém um ou mais descritores de grupo e identifica a ordem na qual executar os grupos especificados em cada descritor. É possível usar os seguintes formatos para definir descritores de grupo individuais:
+ `group-id`: o ID do grupo de um grupo de teste existente.
+ `[group-id, group-id]`: lista de grupos de teste que podem ser executados em qualquer ordem em relação um ao outro.
+ `"*"`: curinga. Isto é equivalente à lista de todos os grupos de teste que ainda não estão especificados na lista atual de descritores de grupo.
O valor de `Order` também devem atender aos seguintes requisitos:
+ O grupo de teste IDs que você especifica em um descritor de grupo deve existir em sua suíte de testes.
+ Cada lista de descritores de grupo deve incluir pelo menos um grupo de teste.
+ Cada lista de descritores de grupo deve conter um grupo IDs exclusivo. Não é possível repetir um ID de grupo de teste em descritores de grupos individuais.
+ Uma lista de descritores de grupo pode ter no máximo um descritor de grupo curinga. O descritor do grupo curinga deve ser o primeiro ou o último item na lista.
**Example**
**Exemplo**
Para um pacote de teste que contém os grupos de teste A, B, C, D e E, a lista de exemplos a seguir mostra maneiras diferentes de especificar que o IDT deve primeiro executar o grupo de teste A, depois executar o grupo de teste B e, em seguida, executar os grupos de teste C, D e E em qualquer ordem.
+
```
Order:
- - A
- B
- [C, D, E]
```
+
```
Order:
- - A
- B
- "*"
```
+
```
Order:
- - A
- B
- - B
- C
- - B
- D
- - B
- E
```
`Features`
Opcional. A lista de recursos do produto que você deseja que o IDT adicione ao arquivo `awsiotdevicetester_report.xml`. Se você não especificar essa seção, o IDT não adicionará nenhum recurso do produto ao relatório.
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. Em `awsiotdevicetester_report.xml`, os recursos do produto são definidos como `supported`, `not-supported` ou um valor personalizado e definido pelo usuário, com base na aprovação dos testes especificados.
Cada item da lista `Features` consiste dos seguintes parâmetros:
`Name`
O nome do recurso.
`Value`
Opcional. O valor personalizado que deseja usar no relatório em vez de `supported`. Se esse valor não for especificado, com base nos conjuntos do IDT, o valor do recurso será definido como `supported` ou `not-supported`. Se você testar o mesmo recurso com condições diferentes, poderá usar um valor personalizado para cada instância desse recurso na lista `Features`, e o IDT concatena os valores do recurso para as condições compatíveis. Para obter mais informações, consulte .
`Condition`
Uma expressão de contexto que deve ser avaliada para um valor booleano. Se o valor avaliado for verdadeiro, o IDT adiciona o recurso ao relatório de teste após concluir a execução do pacote de teste. Se o valor avaliado for falso, o teste não será incluído no relatório.
`Tests`
Opcional. A lista dos descritores de teste. Todos os testes que são especificados nesta lista devem ser aprovados para que o recurso seja compatível.
Cada descritor de teste nesta lista usa o ID do grupo de teste e um ou mais casos de teste IDs para identificar os testes individuais a serem executados em um grupo de teste específico. O descritor de teste usa o seguinte formato:
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
Você deve especificar um `Tests` ou `OneOfTests` para cada recurso na lista `Features`.
`OneOfTests`
Opcional. A lista dos descritores de teste. Pelo menos um dos testes especificados nesta lista deve ser aprovado para que o recurso seja compatível.
Cada descritor de teste nesta lista usa o ID do grupo de teste e um ou mais casos de teste IDs para identificar os testes individuais a serem executados em um grupo de teste específico. O descritor de teste usa o seguinte formato:
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
Você deve especificar um `Tests` ou `OneOfTests` para cada recurso na lista `Features`.
`IsRequired`
O valor booleano que define se o recurso é exigido no relatório de teste. O valor padrão é `false`.
## Contexto do orquestrador de teste
O contexto do orquestrador de estado é um documento JSON somente para leitura que contém dados que estão disponíveis para o orquestrador de estado durante a execução. O contexto do orquestrador de estado é acessível somente do orquestrador 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 do orquestrador de teste usa o seguinte formato:
```
{
"pool": {
},
"userData": {
},
"config": {
}
}
```
`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 no arquivo `config.json`.
Você pode consultar o contexto usando a JSONPath notação. A sintaxe para JSONPath consultas em definições de estado é. `{{query}}` Ao acessar dados do contexto do orquestrador de testes, verifique que cada valor seja 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).
# Configurar a máquina de estado do IDT
**Importante**
Desde o IDT v4.5.2, esta máquina de estado está obsoleta. É muito recomendado o uso do novo orquestrador de testes. Para obter mais informações, consulte [Configure o orquestrador de testes do IDT](idt-test-orchestrator.md).
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 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 se a expressão definida em `Choices.Expression` for 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 a partir 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 teste serão executados em sequência.
```
{
"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"
}
}
}
```
# Crie um executável de caso de teste do IDT
É possível criar e colocar o executável do caso de teste em uma pasta do pacote de teste das seguintes maneiras:
+ Para pacotes de testes que usam argumentos ou variáveis de ambiente dos arquivos `test.json` para determinar quais testes executar, você pode criar um único caso de teste executável para todo o pacote de teste ou um executável de teste para cada grupo de teste no pacote de teste.
+ Para um pacote de teste em que você deseja executar testes específicos com base em comandos especificados, você cria um caso de teste executável para cada caso de teste no pacote de teste.
Como redator de teste, é possível determinar qual abordagem é apropriada para seu caso de uso e estruturar o executável do caso de teste de acordo. Certifique-se de fornecer o caminho correto do executável do caso de teste em cada arquivo `test.json` e de que o executável especificado seja executado corretamente.
Quando todos os dispositivos estiverem prontos para a execução de um caso de teste, o IDT lê os seguintes arquivos:
+ O `test.json` para o caso de teste selecionado determina os processos a serem iniciados e as variáveis de ambiente a serem definidas.
+ O `suite.json` para o pacote de teste determina as variáveis de ambiente a serem definidas.
O IDT inicia o processo executável de teste necessário com base nos comandos e argumentos especificados no arquivo `test.json` e passa as variáveis de ambiente necessárias para o processo.
## Use o SDK do cliente do IDT
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 do cliente IDT para Go
+ SDK do cliente IDT para Java
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 pacotes 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,
"idtRootPath":
},
"device": {
},
"devicePool": {
},
"resource": {
"devices": [
{
"name": ""
}
]
},
"testData": {
"awsCredentials": {
"awsAccessKeyId": "",
"awsSecretAccessKey": "",
"awsSessionToken": ""
},
"logFilePath": "/path/to/log/file"
},
"userData": {
}
}
```
**`config`**
As informações do [arquivo `config.json`](set-config-custom.md#config-json-custom). O campo `config` também contém os seguintes campos adicionais:
**`config.timeoutMultiplier`**
O multiplicador para qualquer valor de tempo limite usado pelo pacote de teste. Este valor é especificado pelo executor de teste da CLI do IDT. O valor padrão é `1`.
**`config.idRootPath`**
Este valor é um espaço reservado para o valor absoluto do caminho do IDT durante a configuração do arquivo `userdata.json`. Isto é usado pelos comandos de compilação e atualização.
**`device`**
As 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 de configuração 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 expressão típica de foobar: JSONPath
| Operador | Description |
| --- | --- |
| \$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 os executores de teste
Para executar pacotes de testes personalizados, os executores de teste devem definir suas configurações com base no pacote de teste que desejam executar. As configurações são especificadas com base nos modelos de arquivo de configuração 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": "",
"pairedResource": "", //used for no-op protocol
"connectivity": {
"protocol": "ssh | uart | docker | no-op",
// ssh
"ip": "",
"port": ,
"publicKeyPath": "",
"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 dispositivos AWS parceiros, 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 este nome de recurso e definem o valor do recurso para os níveis de QoS compatíveis com o dispositivo. É 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.
**`devices.pairedResource`**
Um identificador exclusivo, definido pelo usuário, para um dispositivo de recursos. Este valor é necessário quando você testa dispositivos usando o protocolo de conectividade `no-op`.
**`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, `docker` para contêineres do Docker e `no-op` para dispositivos que não tenham uma conexão direta com a máquina host do IDT, mas precisam de um dispositivo de recursos como middleware físico para se comunicar com a máquina host.
Para dispositivos não operacionais, você configura o ID do dispositivo de recurso em `devices.pairedResource`. Também é preciso especificar esse ID no arquivo `resource.json`. O dispositivo emparelhado deve ser um dispositivo fisicamente emparelhado com o dispositivo em teste. Depois que o IDT identificar e se conectar ao dispositivo de recursos emparelhado, o IDT não se conectará a outros dispositivos de recursos de acordo com os recursos descritos no arquivo `test.json`.
**`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.publicKeyPath`**
Opcional. O caminho completo para a chave pública usada para autenticar conexões com o dispositivo em teste. Ao especificar o `publicKeyPath`, o IDT valida a chave pública do dispositivo ao estabelecer uma conexão SSH com o dispositivo em teste. Se este valor não for especificado, o IDT cria uma conexão SSH, mas não valida a chave pública do dispositivo.
É altamente recomendável especificar o caminho para a chave pública e use um método seguro para buscar essa chave pública. Para clientes SSH padrão baseados em linha de comando, a chave pública é fornecida no arquivo `known_hosts`. Se especificar um arquivo de chave pública separado, esse arquivo deverá usar o mesmo formato do arquivo `known_hosts` , ou seja, `ip-address key-type public-key`.
**`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": ,
"publicKeyPath": "",
"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.publicKeyPath`**
Opcional. O caminho completo para a chave pública usada para autenticar conexões com o dispositivo em teste. Ao especificar o `publicKeyPath`, o IDT valida a chave pública do dispositivo ao estabelecer uma conexão SSH com o dispositivo em teste. Se este valor não for especificado, o IDT cria uma conexão SSH, mas não valida a chave pública do dispositivo.
É altamente recomendável especificar o caminho para a chave pública e use um método seguro para buscar essa chave pública. Para clientes SSH padrão baseados em linha de comando, a chave pública é fornecida no arquivo `known_hosts`. Se especificar um arquivo de chave pública separado, esse arquivo deverá usar o mesmo formato do arquivo `known_hosts` , ou seja, `ip-address key-type public-key`.
**`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 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 [Enviar 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 ambiente `AWS_ACCESS_KEY_ID` e `AWS_SECRET_ACCESS_KEY` para armazenar suas credenciais da 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 pacotes 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. Como referência, leva aproximadamente 30 minutos para concluir o pacote de teste do FreeRTOS completo 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 seguinte comando 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 pacote de teste nem executa o orquestrador de testes. Em vez disso, ele interage com seu IDE para responder às solicitações feitas do pacote de teste em execução no IDE e imprime 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 o orquestrador de testes e não gera nenhum arquivo de relatório. Para depurar seu pacote de teste, você deve usar seu IDE para fornecer algumas informações que o IDT normalmente obtém dos arquivos de configuração. Certifique-se de fornecer 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 para a sua versão do IDT (neste caso, versões do IDT) e versões do pacote de teste de qualificação do FreeRTOS 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 Device Tester usa um formato padrão para imprimir mensagens no console quando ele inicia uma suíte de testes. O trecho a seguir mostra um exemplo de uma mensagem de console gerada pelo IDT.
```
[INFO] [2000-01-02 03:04:05]: 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.
```
[INFO] [2000-01-02 03:04:05]: Hello world! suiteId=MyTestSuitegroupId=myTestGroup testCaseId=myTestCase deviceId=my-deviceexecutionId=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 o caso de teste atual está usando.
O resumo do teste contém informações sobre o pacote de teste, os resultados de cada grupo executado e os locais dos registros e arquivos de logs 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 AWS 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 Device Tester esquema de relatório
`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.
**Atributos 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:
```
```
**Atributos 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:
```
```
**Atributos 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
```
# Enviar métricas de uso do IDT
Se você fornecer AWS credenciais com as permissões necessárias, AWS IoT Device Tester coletará e enviará 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 ID AWS da conta 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 `config.json` arquivo para acessá-las.
## 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 *.
Para conceder acesso, adicione as permissões aos seus usuários, grupos ou perfis:
+ Usuários e grupos em Centro de Identidade do AWS IAM:
Crie um conjunto de permissões. Siga as instruções em [Criação de um conjunto de permissões](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) no *Guia do usuário do Centro de Identidade do AWS IAM *.
+ Usuários gerenciados no IAM com provedor de identidades:
Crie um perfil para a federação de identidades. Siga as instruções em [Criando um perfil para um provedor de identidades de terceiros (federação)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) no *Guia do Usuário do IAM*.
+ Usuários do IAM:
+ Crie um perfil que seu usuário possa assumir. Siga as instruções em [Criação de um perfil para um usuário do IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) no *Guia do usuário do IAM*.
+ (Não recomendado) Vincule uma política diretamente a um usuário ou adicione um usuário a um grupo de usuários. Siga as instruções em [Adição de permissões a um usuário (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) no *Guia do usuário do IAM*.
## 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).
# Manter versões do pacote de teste
O IDT para FreeRTOS organiza testes em pacotes de testes e grupos de testes:
+ Um pacote de testes é o conjunto de grupos de teste usado para verificar se um dispositivo funciona com versões específicas do FreeRTOS.
+ Um grupo de teste é o conjunto de testes individuais relacionados a um recurso específico, como sistemas de mensagens BLE e MQTT.
Começando com o IDT v3.0.0, os conjuntos de testes são versionados usando um formato `major`.`minor`.`patch` começando com 1.0.0. Quando você faz download do IDT, o pacote inclui a versão mais recente do conjunto de testes.
Quando você inicia o IDT na interface de linha de comando, o IDT verifica se uma versão mais recente do conjunto de testes está disponível. Em caso afirmativo, solicitará que você atualize para a nova versão. Você pode optar por atualizar ou continuar com seus testes atuais.
**nota**
O IDT é compatível com as três versões mais recentes do conjunto de testes para qualificação. Para obter mais informações, consulte [Entenda a política de suporte para AWS IoT Device Tester](idt-support-policy.md).
Você pode fazer download dos conjuntos de testes usando o comando `upgrade-test-suite`. Ou você pode usar o parâmetro opcional `-upgrade-test-suite flag` ao iniciar o IDT, onde *flag* pode ser '`y`' para sempre baixar a versão mais recente ou '`n`' para usar a versão existente.
Também é possível executar o comando `list-supported-versions` para listar as versões do FreeRTOS e do pacote de testes compatíveis com a versão atual do IDT.
Novos testes podem apresentar novas definições de configuração do IDT. Se as configurações forem opcionais, o IDT notificará você e 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, você pode continuar a executar os testes.
# Solucionar erros
Cada execução do conjunto de testes tem um ID de execução exclusivo que é usado para criar uma pasta chamada `results/execution-id` no diretório `results`. Os logs individuais do grupo de testes estão no diretório `results/execution-id/logs`. Use a saída do console do IDT para FreeRTOS para encontrar o ID de execução, o ID do caso de teste e o ID do grupo de testes do caso de teste que falhou, e abra o arquivo de log para esse caso de teste chamado `results/execution-id/logs/test_group_id__test_case_id.log`. As informações desse arquivo incluem:
+ Saída completa de comando de compilação e flash.
+ Saída de execução de teste.
+ Mais detalhes da saída de console do IDT para FreeRTOS.
Recomendamos o seguinte fluxo de trabalho para solucionar problemas:
1. Se você ver o erro "não *user/role* está autorizado a acessar este recurso”, certifique-se de configurar as permissões conforme especificado em[Crie e configure uma AWS conta](dev-tester-prereqs.md#config-aws-account).
1. Leia a saída do console para encontrar informações, como UUID de execução e tarefas atualmente em execução.
1. Examine o arquivo para verificar se há declarações de erro em cada teste `FRQ_Report.xml`. Esse diretório contém os logs de execução de cada grupo de teste.
1. Procure os arquivos de logs em `/results/execution-id/logs`.
1. Investigue uma das seguintes áreas problemáticas:
+ Configuração de dispositivo, como arquivos de configuração JSON na pasta `/configs/`.
+ Interface do dispositivo. Verifique os logs para determinar qual interface está falhando.
+ Ferramentas do dispositivo. Certifique-se de que os conjuntos de ferramentas para a criação e a atualização do dispositivo estejam instaladas e configuradas corretamente.
+ Para o FRQ 1.x.x, certifique-se de que uma versão limpa e clonada do código-fonte do FreeRTOS esteja disponível. Os lançamentos do FreeRTOS são marcados de acordo com a versão do FreeRTOS. Para clonar uma versão específica do código, use os comandos a seguir:
```
git clone --branch version-number https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
## Solucionar problemas de configuração de dispositivos
Ao usar o IDT para FreeRTOS, é preciso obter os arquivos de configuração corretos antes de executar o binário. Se você estiver recebendo erros de análise e configuração, o primeiro passo deve ser localizar e usar um modelo de configuração apropriado para seu ambiente. Esses modelos estão localizados no diretório `IDT_ROOT/configs`.
Se você ainda estiver com problemas, consulte o processo de depuração a seguir.
### Onde eu procuro?
Comece lendo a saída do console para encontrar informações, como o UUID de execução, que é referido como nesta documentação `execution-id`.
Depois, examine o arquivo `FRQ_Report.xml` no diretório `/results/execution-id`. Este arquivo contém todos os casos de teste que foram executados e os trechos com erros para cada falha. Para obter todos os logs de execução, procure o arquivo para cada caso de teste `/results/execution-id/logs/test_group_id__test_case_id.log`.
### Códigos de erro de IDT
A tabela a seguir explica os códigos de erro gerados pelo IDT para FreeRTOS:
| Código de erro | Nome do código de erro | Possível causa raiz | Solução de problemas |
| --- | --- | --- | --- |
| 201 | InvalidInputError | Os campos em `device.json`, `config.json` ou `userdata.json` estão ausentes ou em um formato incorreto. | Certifique-se de que os campos obrigatórios não estejam ausentes e estejam no formato obrigatório nos arquivos listados. Para obter mais informações, consulte [Primeiro teste da sua placa de microcontrolador](qual-steps.md). |
| 202 | ValidationError | Os campos em `device.json`, `config.json` ou `userdata.json` contêm valores 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/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 203 | CopySourceCodeError | Não foi possível copiar o código-fonte do FreeRTOS para o diretório especificado. | Verifique os seguintes itens: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 204 | BuildSourceError | Não foi possível compilar o código-fonte do FreeRTOS. | Verifique os seguintes itens: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 205 | FlashOrRunTestError | O IDT FreeRTOS não consegue instalar ou executar o FreeRTOS no seu DUT. | Verifique se as informações em `flashTool` no arquivo `userdata.json` estão corretas. Para obter mais informações, consulte [Configuração de parâmetros de compilação, atualização e teste](cfg-dt-ud.md). |
| 206 | StartEchoServerError | O IDT FreeRTOS não consegue iniciar o servidor de eco para os testes de soquetes seguros ou de soquetes. WiFi | Verifique se as portas configuradas `echoServerConfiguration` em seu arquivo `userdata.json` não estão em uso ou bloqueadas por configurações de firewall ou rede. |
### Depurar erros de análise do arquivo de configuração
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 para FreeRTOS 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 tiver problemas para 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
### Depurar erros de análise de resultados de teste
Ao executar um grupo de teste de [ FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests), como **FullTransportInterfaceTLS, Full PKCS11 \$1Core, Full \$1Onboard\$1ECC, Full PKCS11 \$1Onboard\$1RSA, Full \$1 PKCS11 \$1ECC, Full \$1 PKCS11 \$1RSA ou IDT for FreerTOSPreProvisioned, analisa os resultados do teste do PKCS11 dispositivo de teste com a PreProvisioned conexão** serial. **OTACore** Às vezes, saídas seriais extras no dispositivo podem interferir na análise dos resultados do teste.
No caso mencionado acima, motivos estranhos de falha em casos de teste, como cadeias de caracteres provenientes de saídas de dispositivos não relacionados, são gerados. O arquivo de log do caso de teste do IDT para FreeRTOS (que inclui toda a saída serial que o IDT do FreeRTOS recebeu durante o teste) pode mostrar o seguinte:
```
TEST(Full_PKCS11_Capabilities, PKCS11_Capabilities)
PASS
```
No exemplo acima, a saída não relacionada do dispositivo impede que o IDT para FreeRTOS detecte o resultado do teste, que é **APROVADO**.
Verifique o seguinte para garantir o teste ideal.
+ Verifique se as macros de registro em log usadas no dispositivo são seguras para thread. Consulte [Implementação das macros de registro em log da biblioteca](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-library-logging-macros.html) para obter mais informações.
+ Verifique se há um mínimo de saídas para a conexão serial durante os testes. As saídas de outros dispositivos podem ser um problema, mesmo que suas macros de registro em log sejam devidamente seguras, pois os resultados do teste serão exibidos em chamadas separadas durante o teste.
Idealmente, um log de casos de teste do IDT para FreeRTOS mostraria uma saída ininterrupta dos resultados do teste, como abaixo:
```
---------STARTING TESTS---------
TEST(Full_OTA_PAL, otaPal_CloseFile_ValidSignature) PASS
TEST(Full_OTA_PAL, otaPal_CloseFile_InvalidSignatureBlockWritten) PASS
-----------------------
2 Tests 0 Failures 0 Ignored
```
### Depurar falhas na verificação de integridade
Se estiver usando a versão FRQ 1.x.x dos FreeRTOS, as verificações de integridade a seguir se aplicam.
Ao executar o grupo de RTOSIntegrity teste Free e encontrar falhas, primeiro certifique-se de não ter modificado nenhum dos arquivos do `freertos` diretório. Se não fez isso e ainda está tendo problemas, verifique se está usando a ramificação correta. Se executar o comando `list-supported-products` do IDT, poderá descobrir qual ramificação marcada do repositório `freertos` deve ser usada.
Se clonou a ramificação marcada correta do repositório `freertos` e ainda tiver problemas, verifique se também executou o comando `submodule update`. O fluxo de trabalho de clonagem para o repositório `freertos` é o seguinte.
```
git clone --branch version-number https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout —init —recursive
```
A lista de arquivos que o verificador de integridade procura está no arquivo `checksums.json` em seu diretório `freertos`. Para qualificar uma porta do FreeRTOS sem nenhuma modificação nos arquivos e na estrutura de pastas, verifique se nenhum dos arquivos listados nas seções "`exhaustive`" e "`minimal`" do arquivo `checksums.json` foi modificado. Para executar com um SDK configurado, verifique se nenhum dos arquivos na seção "`minimal`" foi modificado.
Se o IDT for executado com um SDK e alguns arquivos em seu diretório `freertos` tiverem sido modificados, certifique-se de configurar corretamente o SDK em seu arquivo `userdata`. Caso contrário, o verificador de integridade verificará todos os arquivos no diretório `freertos`.
### Depurar falhas FullWiFi do grupo de teste
Se você estiver usando o FRQ 1.x.x e encontrar falhas no grupo de FullWiFi teste, e o teste "`AFQP_WiFiConnectMultipleAP`" falhar, isso pode ser porque os dois pontos de acesso não estão na mesma sub-rede que o computador host executando o IDT. Verifique se os dois pontos de acesso estão na mesma sub-rede do computador host que executa o IDT.
### Depurar erros de "parâmetro obrigatório ausente"
Como novos recursos estão sendo adicionados ao IDT para FreeRTOS, 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 `test_group_id__test_case_id.log` no diretório `results/execution-id/logs` listará explicitamente todos os parâmetros ausentes. O IDT para FreeRTOS valida os esquemas do arquivo de configuração JSON para garantir que a versão compatível mais recente foi usada.
### Depurar erros "o teste não pôde ser iniciado"
Você pode encontrar erros que apontam para falhas ao iniciar o teste. Como existem várias causas possíveis, verifique se há algum problema nas seguintes áreas:
+ Verifique se o nome do grupo incluído no comando de execução realmente existe. Ele é referenciado diretamente em seu arquivo `device.json`.
+ Verifique se o(s) dispositivo(s) no grupo têm os parâmetros de configuração corretos.
### Depurar erros "não foi possível encontrar o início dos resultados do teste"
Você pode obter erros quando o IDT tenta analisar a saída de resultados pelo dispositivo em teste. Existem várias causas possíveis, por isso verifique se há algum problema nas seguintes áreas:
+ Verifique se o dispositivo em teste tem uma conexão estável com sua máquina host. É possível verificar o arquivo de log para ver se há um teste que mostre esses erros e ver o que o IDT está recebendo.
+ Se estiver usando o FRQ 1.x.x e o dispositivo em teste estiver conectado por meio de uma rede lenta ou outra interface, ou se você não ver o sinalizador "---------STARTING TESTS---------" em um log do grupo de testes do FreeRTOS junto com outras saídas do grupo de testes do FreeRTOS, tente aumentar o valor de `testStartDelayms` em sua configuração de dados do usuário. Para obter mais informações, consulte [Configuração de parâmetros de compilação, atualização e teste](cfg-dt-ud.md).
### Depurar erros "Falha no teste: resultados esperados \$1\$1, mas foram vistos \$1\$1\$1"
Você pode encontrar erros que apontam para falhas ao iniciar o teste. O teste espera um certo número de resultados e não vê isso durante o teste. Alguns testes do FreeRTOS são executados antes que o IDT veja a saída do dispositivo. Se ver esse erro, tente aumentar o valor de `testStartDelayms` em sua configuração de *dados de usuário*. Para obter mais informações, consulte [Configuração de parâmetros de compilação, atualização e teste](lts-cfg-dt-ud.md).
### Depurar um erro do tipo “\$1\$1\$1\$1\$1\$1\$1\$1 não foi selecionado devido a restrições” ConditionalTests
Isso significa que você está executando um teste em um grupo de dispositivos que é incompatível com o teste. Isso pode acontecer com os testes E2E OTA. Por exemplo, ao executar o grupo de testes `OTADataplaneMQTT` e em seu arquivo de configuração `device.json`, você escolheu OTA como **Não** ou `OTADataPlaneProtocol` como **HTTP**. O grupo de teste escolhido para execução deve corresponder às suas seleções de capacidade `device.json`.
### Depurar um tempo limite do IDT durante o monitoramento de saída do dispositivo
O IDT pode atingir o tempo limite por conta de vários motivos. Se ocorrer um tempo limite durante a fase de monitoramento da saída do dispositivo de um teste e puder ver os resultados no log do caso de testes do IDT, isso significa que os resultados foram analisados incorretamente pelo IDT. Um dos motivos podem ser as mensagens de log intercaladas no meio dos resultados do teste. Se for este o caso, consulte o [Guia de portabilidade do FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-ota.html) para obter mais detalhes sobre como os logs do UNITY devem ser configurados.
Outro motivo para o tempo limite durante o monitoramento da saída do dispositivo pode ser a reinicialização do dispositivo após uma única falha no caso de testes do TLS. O dispositivo executará a imagem instalada e causará um loop infinito que será visto nos logs. Se isto acontecer, o seu dispositivo não será reinicializado após uma falha no teste.
### Depurar erro de "não autorizado para acessar um recurso"
Você pode ver o erro "não *user/role* está autorizado a acessar este recurso” na saída do terminal ou no `test_manager.log` arquivo abaixo`/results/execution-id/logs`. Para resolver este problema, anexe a política gerenciada `AWS IoTDeviceTesterForFreeRTOSFullAccess` ao usuário de teste. Para obter mais informações, consulte [Crie e configure uma AWS conta](dev-tester-prereqs.md#config-aws-account).
### Depurar erros de teste de rede
Para testes com base em rede, o IDT inicia um servidor de eco que vincula a uma porta não reservada na máquina host. Se você estiver enfrentando erros devido a tempos limite ou conexões indisponíveis nos testes de soquetes seguros WiFi ou de soquetes seguros, certifique-se de que sua rede esteja configurada para permitir tráfego para portas configuradas na faixa de 1024 a 49151.
O teste de soquetes seguros usa as portas 33333 e 33334 por padrão. Os WiFi testes usam a porta 33335 por padrão. Se essas três portas estiverem em uso ou bloqueadas por firewall ou rede, opte por usar portas diferentes em userdata.json para testes. Para obter mais informações, consulte [Configuração de parâmetros de compilação, atualização e teste](cfg-dt-ud.md). Você pode usar os seguintes comandos para verificar se uma porta específica está em uso:
+ Windows: `netsh advfirewall firewall show rule name=all | grep port`
+ Linux: `sudo netstat -pan | grep port`
+ macOS: `netstat -nat | grep port`
### Falhas de atualização de OTA devido à mesma carga útil de versão
Se os casos de teste OTA estiverem falhando por a mesma versão estar no dispositivo depois que uma OTA foi executada, pode ser que o seu sistema de compilação (por exemplo, cmake) não notou as alterações do IDT ao código-fonte do FreeRTOS e não criou um binário atualizado. Isso faz com que o OTA seja executado com o mesmo binário que está atualmente no dispositivo e o teste falhe. Para solucionar problemas de falhas de atualização OTA, comece certificando-se de que você está usando a versão mais recente com suporte do sistema de compilação.
### Falha no teste de OTA no caso de teste de `PresignedUrlExpired`
Um pré-requisito deste teste é que o tempo de atualização OTA deve ser superior a 60 segundos, caso contrário o teste falharia. Se isso ocorrer, a seguinte mensagem de erro é encontrada no log: “Teste leva menos de 60 segundos (tempo expirado da url) para concluir. Por favor, entre em contato conosco."
### Depurar erros de porta e de interface de dispositivo
Esta seção contém informações sobre as interfaces de dispositivo usadas pelo IDT para se conectar aos dispositivos.
#### Plataformas compatíveis
O IDT é compatível com Linux, macOS e Windows. Todas as três plataformas têm diferentes esquemas de nomenclatura para os dispositivos seriais que se conectam a elas:
+ Linux: `/dev/tty*`
+ macOS: `/dev/tty.*` ou `/dev/cu.*`
+ Windows: COM\$1
Para verificar a porta do dispositivo:
+ No Linux/macOS, abra um terminal e execute `ls /dev/tty*`.
+ No macOS, abra um terminal e execute `ls /dev/tty.*` ou `ls /dev/cu.*`.
+ No Windows, abra o Gerenciador de dispositivos e expanda o grupo de dispositivos seriais.
Para verificar qual dispositivo está conectado a uma porta:
+ Para o Linux, verifique se o pacote `udev` está instalado e execute `udevadm info –name=PORT`. Este utilitário imprime informações do driver de dispositivo que ajudam você a verificar se está usando a porta correta.
+ Para macOS, abra o Launchpad e procure **System Information**.
+ No Windows, abra o Gerenciador de dispositivos e expanda o grupo de dispositivos seriais.
#### Interfaces de dispositivo
Cada dispositivo incorporado é diferente, o que significa que ele pode ter uma ou mais portas seriais. É comum que os dispositivos tenham duas portas quando conectados a uma máquina:
+ Uma porta de dados para a atualização do dispositivo.
+ Uma porta de leitura para ler a saída.
Você deve definir a porta de leitura correta em seu arquivo `device.json`. Caso contrário, a leitura de saída do dispositivo pode falhar.
No caso de várias portas, certifique-se de usar a porta de leitura do dispositivo em seu arquivo `device.json`. Por exemplo, se você conectar um WRover dispositivo Espressif e as duas portas atribuídas a ele forem `/dev/ttyUSB0` e`/dev/ttyUSB1`, use `/dev/ttyUSB1` em seu arquivo. `device.json`
No Windows, siga a mesma lógica.
#### Leitura de dados de dispositivo
O IDT para FreeRTOS usa ferramentas individuais de compilação e atualização de dispositivos para especificar a configuração da porta. Se você estiver testando o dispositivo e não obtiver a saída, tente as seguintes configurações padrão:
+ Taxa de baud: 115200
+ Bits de dados: 8
+ Paridade: nenhum
+ Bits de parada: 1
+ Controle de fluxo: nenhum
Essas configurações são processadas pelo IDT para FreeRTOS. Você não precisa defini-los. No entanto, você pode usar o mesmo método para ler a saída do dispositivo manualmente. No Linux ou macOS, você pode fazer isso com o comando `screen`. No Windows, você pode usar um programa como TeraTerm.
`Screen: screen /dev/cu.usbserial 115200`
`TeraTerm: Use the above-provided settings to set the fields explicitly in the GUI.`
### Problemas de cadeia de ferramentas de desenvolvimento
Esta seção aborda os problemas que podem ocorrer com a cadeia de ferramentas.
#### Code Composer Studio no Ubuntu
As versões mais recentes do Ubuntu (17.10 e 18.04) têm uma versão do pacote `glibc` que não é compatível com as versões 7.*x* do Code Composer Studio. Recomendamos que você instale o Code Composer Studio versão 8.2 ou mais recente.
Os sintomas de incompatibilidade podem incluir:
+ Falha do FreeRTOS ao compilar ou atualizar seu dispositivo.
+ O instalador do Code Composer Studio pode congelar.
+ Nenhuma saída de log é exibida no console durante o processo de compilação ou atualização.
+ O comando de compilação tenta executar em modo GUI mesmo quando é invocado em modo dedicado.
### Registro em log
Os logs do IDT para FreeRTOS são armazenados em um único local. No diretório raiz do IDT, esses arquivos estão disponíveis em `results/execution-id/`:
+ `FRQ_Report.xml`
+ `awsiotdevicetester_report.xml`
+ `logs/test_group_id__test_case_id.log`
`FRQ_Report.xml` e `logs/test_group_id__test_case_id.log` são os logs mais importantes a serem examinados. `FRQ_Report.xml` contém informações sobre quais casos de teste falharam com uma mensagem de erro específica. Depois, é possível usar `logs/test_group_id__test_case_id.log` para ver mais detalhes sobre o problema, a fim de obter um contexto melhor.
#### Erros do console
Quando AWS IoT Device Tester é executado, as falhas são reportadas ao console com mensagens breves. Examine `results/execution-id/logs/test_group_id__test_case_id.log` para saber mais sobre o erro.
#### Erros de logs
Cada execução do conjunto de testes tem um ID de execução exclusivo usado para criar uma pasta chamada `results/execution-id`. Os logs de casos de testes individuais estão no diretório `results/execution-id/logs`. Use a saída do console do IDT para FreeRTOS a fim de localizar o ID de execução, o ID de caso de teste e o ID de grupo de teste do caso de teste que falhou. Em seguida, use essas informações para localizar e abrir o arquivo de log desse caso de teste chamado `results/execution-id/logs/test_group_id__test_case_id.log` As informações nesse arquivo incluem a saída completa dos comandos de compilação e flash, a saída da execução do teste e a saída mais detalhada AWS IoT Device Tester do console.
#### Problemas de bucket do S3
Se pressionar CTRL\$1C enquanto executa o IDT, o IDT iniciará um processo de limpeza. Parte dessa limpeza é remover os recursos do Amazon S3 que foram criados como parte dos testes do IDT. Se a limpeza não puder ser concluída, você poderá ter um problema em que muitos buckets do Amazon S3 foram criados. Isso significa que na próxima vez que você executar o IDT, os testes começarão a falhar.
Se pressionar CTRL\$1C para interromper o IDT, deverá deixá-lo concluir o processo de limpeza para evitar este problema. Você também pode excluir os buckets do Amazon S3 da sua conta que foram criados manualmente.
## Solucionar erros de tempo limite
Se você encontrar erros de tempo limite ao executar um conjunto de testes, aumente o tempo limite especificando um fator multiplicador. Esse fator é aplicado ao valor de tempo limite padrão. 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 o conjunto de testes.
**Example**
```
./devicetester_linux run-suite --suite-id FRQ_1.0.1 --pool-id DevicePool1 --timeout-multiplier 2.5
```
```
./devicetester_linux run-suite --suite-id FRQ_1 --pool-id DevicePool1 --timeout-multiplier 2.5
```
## Recurso e AWS cobranças do celular
Quando o `Cellular` recurso estiver configurado `Yes` em seu `device.JSON` arquivo, FullSecureSockets usará instâncias t.micro EC2 para executar testes e isso poderá incorrer em custos adicionais em sua conta. AWS Para obter mais informações, consulte [Definição de preço do Amazon EC2](https://aws.amazon.com/ec2/pricing/).
## Política de geração de relatórios de qualificação
Os relatórios de qualificação são gerados somente pelas versões AWS IoT Device Tester (IDT) que oferecem suporte às versões do FreeRTOS lançadas nos últimos dois anos. Se tiver dúvidas sobre a política de suporte, entre em contato com o [AWS Support](https://aws.amazon.com/contact-us/).
# Entenda a política AWS gerenciada para AWS IoT Device Tester
Uma política AWS gerenciada é uma política autônoma criada e administrada por AWS. AWS as políticas gerenciadas são projetadas para fornecer permissões para muitos casos de uso comuns, para que você possa começar a atribuir permissões a usuários, grupos e funções.
Lembre-se de que as políticas AWS gerenciadas podem não conceder permissões de privilégio mínimo para seus casos de uso específicos porque elas estão disponíveis para uso de todos os AWS clientes. Recomendamos que você reduza ainda mais as permissões definindo as [ políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) que são específicas para seus casos de uso.
Você não pode alterar as permissões definidas nas políticas AWS gerenciadas. Se AWS atualizar as permissões definidas em uma política AWS gerenciada, a atualização afetará todas as identidades principais (usuários, grupos e funções) às quais a política está anexada. AWS é mais provável que atualize uma política AWS gerenciada quando uma nova AWS service (Serviço da AWS) for lançada ou novas operações de API forem disponibilizadas para serviços existentes.
Para saber mais, consulte [AWS Políticas gerenciadas pela ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) no *Guia do usuário do IAM*.
**Topics**
+ [AWS política gerenciada: AWS Io TDevice TesterForFree RTOSFull Access](#aws-managed-policies-AWSIoTDT)
+ [Atualizações nas políticas AWS gerenciadas](#aws-managed-policy-updates)
## AWS política gerenciada: AWS Io TDevice TesterForFree RTOSFull Access
A política `AWSIoTDeviceTesterForFreeRTOSFullAccess` gerenciada contém as seguintes AWS IoT Device Tester permissões para verificação de versão, recursos de atualização automática e coleção de métricas.
**Detalhes de permissões**
Esta política inclui as seguintes permissões:
+ `iot-device-tester:SupportedVersion`
Concede AWS IoT Device Tester permissão para buscar a lista de produtos compatíveis, suítes de teste e versões do IDT.
+ `iot-device-tester:LatestIdt`
Concede AWS IoT Device Tester permissão para obter a versão mais recente do IDT disponível para download.
+ `iot-device-tester:CheckVersion`
Concede AWS IoT Device Tester permissão para verificar a compatibilidade de versões do IDT, suítes de teste e produtos.
+ `iot-device-tester:DownloadTestSuite`
Concede AWS IoT Device Tester permissão para baixar atualizações da suíte de testes.
+ `iot-device-tester:SendMetrics`
Concede AWS permissão para coletar métricas sobre o uso AWS IoT Device Tester interno.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/idt-*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "iot.amazonaws.com"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"iot:DeleteThing",
"iot:AttachThingPrincipal",
"iot:DeleteCertificate",
"iot:GetRegistrationCode",
"iot:CreatePolicy",
"iot:UpdateCACertificate",
"s3:ListBucket",
"iot:DescribeEndpoint",
"iot:CreateOTAUpdate",
"iot:CreateStream",
"signer:ListSigningJobs",
"acm:ListCertificates",
"iot:CreateKeysAndCertificate",
"iot:UpdateCertificate",
"iot:CreateCertificateFromCsr",
"iot:DetachThingPrincipal",
"iot:RegisterCACertificate",
"iot:CreateThing",
"iam:ListRoles",
"iot:RegisterCertificate",
"iot:DeleteCACertificate",
"signer:PutSigningProfile",
"s3:ListAllMyBuckets",
"signer:ListSigningPlatforms",
"iot-device-tester:SendMetrics",
"iot-device-tester:SupportedVersion",
"iot-device-tester:LatestIdt",
"iot-device-tester:CheckVersion",
"iot-device-tester:DownloadTestSuite"
],
"Resource": "*"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"iam:GetRole",
"signer:StartSigningJob",
"acm:GetCertificate",
"signer:DescribeSigningJob",
"s3:CreateBucket",
"execute-api:Invoke",
"s3:DeleteBucket",
"s3:PutBucketVersioning",
"signer:CancelSigningProfile"
],
"Resource": [
"arn:aws:execute-api:us-east-1:098862408343:9xpmnvs5h4/prod/POST/metrics",
"arn:aws:signer:*:*:/signing-profiles/*",
"arn:aws:signer:*:*:/signing-jobs/*",
"arn:aws:iam::*:role/idt-*",
"arn:aws:acm:*:*:certificate/*",
"arn:aws:s3:::idt-*",
"arn:aws:s3:::afr-ota*"
]
},
{
"Sid": "VisualEditor3",
"Effect": "Allow",
"Action": [
"iot:DeleteStream",
"iot:DeleteCertificate",
"iot:AttachPolicy",
"iot:DetachPolicy",
"iot:DeletePolicy",
"s3:ListBucketVersions",
"iot:UpdateCertificate",
"iot:GetOTAUpdate",
"iot:DeleteOTAUpdate",
"iot:DescribeJobExecution"
],
"Resource": [
"arn:aws:s3:::afr-ota*",
"arn:aws:iot:*:*:thinggroup/idt*",
"arn:aws:iam::*:role/idt-*"
]
},
{
"Sid": "VisualEditor4",
"Effect": "Allow",
"Action": [
"iot:DeleteCertificate",
"iot:AttachPolicy",
"iot:DetachPolicy",
"s3:DeleteObjectVersion",
"iot:DeleteOTAUpdate",
"s3:PutObject",
"s3:GetObject",
"iot:DeleteStream",
"iot:DeletePolicy",
"s3:DeleteObject",
"iot:UpdateCertificate",
"iot:GetOTAUpdate",
"s3:GetObjectVersion",
"iot:DescribeJobExecution"
],
"Resource": [
"arn:aws:s3:::afr-ota*/*",
"arn:aws:s3:::idt-*/*",
"arn:aws:iot:*:*:policy/idt*",
"arn:aws:iam::*:role/idt-*",
"arn:aws:iot:*:*:otaupdate/idt*",
"arn:aws:iot:*:*:thing/idt*",
"arn:aws:iot:*:*:cert/*",
"arn:aws:iot:*:*:job/*",
"arn:aws:iot:*:*:stream/*"
]
},
{
"Sid": "VisualEditor5",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::afr-ota*/*",
"arn:aws:s3:::idt-*/*"
]
},
{
"Sid": "VisualEditor6",
"Effect": "Allow",
"Action": [
"iot:CancelJobExecution"
],
"Resource": [
"arn:aws:iot:*:*:job/*",
"arn:aws:iot:*:*:thing/idt*"
]
},
{
"Sid": "VisualEditor7",
"Effect": "Allow",
"Action": [
"ec2:TerminateInstances"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor8",
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:DeleteSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor9",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor10",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:image/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:placement-group/*",
"arn:aws:ec2:*:*:snapshot/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:subnet/*"
]
},
{
"Sid": "VisualEditor11",
"Effect": "Allow",
"Action": [
"ec2:CreateSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor12",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeSecurityGroups",
"ssm:DescribeParameters",
"ssm:GetParameters"
],
"Resource": "*"
},
{
"Sid": "VisualEditor13",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"Owner"
]
},
"StringEquals": {
"ec2:CreateAction": [
"RunInstances",
"CreateSecurityGroup"
]
}
}
}
]
}
```
------
## Atualizações nas políticas AWS gerenciadas
Você pode ver detalhes sobre as atualizações das políticas AWS gerenciadas a AWS IoT Device Tester partir do momento em que esse serviço começou a rastrear essas alterações.
| Versão | Alteração | Descrição | Data |
| --- | --- | --- | --- |
| 7 (Mais recente) | Reestruturou as condições `ec2:CreateTags`. | Remoção do uso de `ForAnyValues`. | 14/06/2023 |
| 6 | Removeu `freertos:ListHardwarePlatforms` da política. | Remoção das permissões, pois essa ação foi preterida em 1º de março de 2023. | 02/06/2023 |
| 5 | Adicionou permissões para executar testes de servidor echo usando o EC2. | Isso serve para iniciar e interromper uma instância do EC2 nas contas dos clientes AWS . | 15/12/2020 |
| 4 | Adição do `iot:CancelJobExecution`. | Essa permissão cancela trabalhos OTA. | 17/07/2020 |
| 3 | Adicionou as seguintes permissões: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/security-iam-aws-managed-policies.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/freertos/latest/userguide/security-iam-aws-managed-policies.html) | 23/03/2020 |
| 2 | Adicionou permissões de `iot-device-tester:SendMetrics`. | Concede AWS permissão para coletar métricas sobre o uso AWS IoT Device Tester interno. | 18/02/2020 |
| 1 | Versão inicial. | | 12/02/2020 |
# Entenda a política de suporte para AWS IoT Device Tester
**Importante**
Em outubro de 2022, AWS IoT Device Tester o AWS IoT FreeRTOS Qualification (FRQ) 1.0 não gera relatórios de qualificação assinados. Você não pode qualificar novos dispositivos AWS IoT FreeRTOS para serem listados no Catálogo de Dispositivos [Parceiros por meio AWS do Programa de Qualificação de Dispositivos](https://partners.amazonaws.com/qualified-devices) [usando AWS as versões do IDT](https://aws.amazon.com/partners/programs/dqp/) FRQ 1.0. Embora você não possa qualificar dispositivos FreeRTOS usando o IDT FRQ 1.0, você pode continuar testando seus dispositivos FreeRTOS com o FRQ 1.0. Recomendamos que você use o [IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) para qualificar e listar dispositivos FreeRTOS no [AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices).
AWS IoT Device Tester for FreeRTOS é uma ferramenta de automação de testes para validar a porta do FreeRTOS para dispositivos. Além disso, você pode [qualificar](https://aws.amazon.com/partners/programs/dqp/) seus dispositivos FreeRTOS e listá-los no [AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices). [O AWS IoT Device Tester for FreeRTOS oferece suporte à validação e qualificação das bibliotecas FreeRTOS Long Term Supported (LTS) disponíveis no FreeRTOS/FreeRTOS-LTS, e da linha principal do FreeRTOS disponível GitHub no [FreeRTOS/FreeRTOS](https://github.com/FreeRTOS/FreeRTOS-LTS).](https://github.com/FreeRTOS/FreeRTOS) Recomendamos que você use as versões mais recentes do FreeRTOS e do FreeRTOS AWS IoT Device Tester para validar e qualificar seus dispositivos.
Para FreeRTOS-LTS, o IDT oferece suporte a validação e qualificação da versão 202210 LTS do FreeRTOS. Veja aqui mais informações sobre as [Versões LTS do FreeRTOS](https://www.freertos.org/lts-libraries.html) e seu cronograma de manutenção. Quando o período de suporte dessas versões do LTS termina, você ainda poderá continuar a validação, mas o IDT não gerará um relatório que permita enviar seu dispositivo para qualificação.
Para os linhas principais do FreeRTOS disponíveis no [FreeRTOS/FreeRTOS](https://github.com/FreeRTOS/FreeRTOS), oferecemos suporte à validação e qualificação de todas as versões lançadas nos últimos seis meses, ou das duas versões anteriores do FreeRTOS, se lançadas com mais de seis meses de intervalo. Confira aqui as [versões compatíveis no momento]( https://docs.aws.amazon.com//freertos/latest/userguide/dev-test-versions-afr.html). Para as versões do FreeRTOS sem suporte, você ainda poderá continuar a validação, mas o IDT não gerará um relatório que permita enviar seu dispositivo para qualificação.
Consulte [Versões compatíveis do AWS IoT Device Tester](dev-test-versions-afr.md) as versões compatíveis do IDT e do FreeRTOS mais recentes. Você pode usar qualquer uma das versões compatíveis AWS IoT Device Tester com a versão correspondente dos FreeRTOS para testar ou qualificar seu dispositivo. Se continuar a usar [Versões não compatíveis do IDT para FreeRTOS](idt-unsupported-versions-afr.md), você não receberá as correções de bugs ou atualizações mais recentes.
Para tirar dúvidas sobre a política de suporte, entre em contato com o [Suporte ao cliente da AWS](https://aws.amazon.com/contact-us/).