Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# AWS IoT Device Tester per FreerTOS
L'IDT per FreerTOS è uno strumento per qualificare la velocità di trasmissione dei dati con il sistema operativo FreerTOS. Il device tester (IDT) apre innanzitutto una connessione USB o UART a un dispositivo. Quindi mostra un'immagine di FreerTOS configurato per testare la funzionalità del dispositivo in varie condizioni. AWS IoT Device Tester le suite sono estensibili e IDT viene utilizzato per l'orchestrazione dei test dei clienti. AWS IoT
IDT per FreerTOS viene eseguito su un computer host (Windows, macOS o Linux) collegato al dispositivo in fase di test. IDT configura e orchestra i casi di test e aggrega i risultati. Inoltre offre un'interfaccia a riga di comando per gestire l'esecuzione dei test.
## Suite di qualificazione FreerTOS
IDT for FreerTOS verifica la porta di FreerTOS sul microcontrollore e verifica se è in grado di comunicare efficacemente con FreerTOS in modo affidabile e sicuro. AWS IoT In particolare, verifica se le interfacce del livello di porting per le librerie FreerTOS sono implementate correttamente. Esegue anche test con. end-to-end AWS IoT Core Ad esempio, verifica se la tua scheda è in grado di inviare e ricevere messaggi MQTT ed elaborarli correttamente.
[La suite di qualificazione FreerTOS (FRQ) 2.0 utilizza casi FreeRTOS-Libraries-Integration-Tests di test e Device Advisor definiti nella FreeRTOS Qualification Guide.](https://docs.aws.amazon.com/freertos/latest/qualificationguide/freertos-qualification.html#qualifying-your-device-idt)
IDT for FreerTOS genera report di test che puoi inviare AWS a Partner Network (APN) per l'inclusione dei tuoi dispositivi FreerTOS nel Partner Device Catalog. AWS Per ulteriori informazioni, consulta [AWS Device Qualification Program](https://aws.amazon.com/partners/dqp/).
Il diagramma seguente mostra la configurazione dell'infrastruttura di test per la qualificazione FreerTOS.
![\[Diagramma di flusso che mostra come AWS IoT Core interagisce con il computer e il microcontrollore.\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/images/devicetester_afr.png)
IDT for FreerTOS organizza le risorse di test in suite di test e gruppi di test:
+ Una suite di test è l'insieme di gruppi di test utilizzati per verificare che un dispositivo funzioni con versioni particolari di FreerTOS.
+ Un gruppo di test è l'insieme di singoli casi di test relativi a una particolare funzionalità, come la messaggistica BLE e MQTT.
Per ulteriori informazioni, consulta [Versioni della suite di test](idt-test-suite-versions.md)
## Comprendi le suite di test personalizzate
IDT for FreerTOS combina una configurazione di configurazione standardizzata e un formato di risultati con un ambiente di suite di test. Questo ambiente consente di sviluppare suite di test personalizzate per i dispositivi e il software del dispositivo. Puoi aggiungere test personalizzati per la tua convalida interna o fornirli ai tuoi clienti per la verifica del dispositivo.
Il modo in cui configurate le suite di test personalizzate determina le configurazioni di impostazione che dovete fornire agli utenti per eseguire le suite di test personalizzate. Per ulteriori informazioni, consulta [Sviluppa ed esegui le tue suite di test IDT](idt-custom-tests.md).
# Versioni supportate di AWS IoT Device Tester
Questo argomento elenca le versioni supportate di AWS IoT Device Tester per FreerTOS. Come best practice, ti consigliamo di utilizzare l'ultima versione di IDT per FreeRTOS che supporti la versione di destinazione di FreerTOS. Ogni versione di IDT per FreerTOS ha una o più versioni corrispondenti di FreerTOS che supporta. Ti consigliamo di scaricare una nuova versione di IDT per FreerTOS quando viene rilasciata una nuova versione di FreeRTOS.
Scaricando il software, l'utente accetta il Contratto di AWS IoT Device Tester licenza contenuto nell'archivio dei download.
**Nota**
Quando si utilizza AWS IoT Device Tester for FreerTOS, si consiglia di eseguire l'aggiornamento all'ultima versione di patch della versione FreeRTOS-LTS più recente.
**Importante**
A ottobre 2022, AWS IoT Device Tester per AWS IoT FreerTOS Qualification (FRQ) 1.0 non genera report di qualificazione firmati. Non puoi qualificare nuovi dispositivi AWS IoT FreerTOS da inserire nel [Partner Device Catalog tramite AWS il Device](https://partners.amazonaws.com/qualified-devices) [Qualification Program utilizzando AWS le](https://aws.amazon.com/partners/programs/dqp/) versioni IDT FRQ 1.0. Sebbene non sia possibile qualificare i dispositivi FreerTOS utilizzando IDT FRQ 1.0, è possibile continuare a testare i dispositivi FreerTOS con FRQ 1.0. [Ti consigliamo di utilizzare [IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) per qualificare ed elencare i dispositivi FreerTOS nel Partner Device Catalog.AWS](https://partners.amazonaws.com/qualified-devices)
## Versione più recente di AWS IoT Device Tester for FreerTOS
Usa i seguenti link per scaricare le ultime versioni di IDT per FreerTOS.
**Versione più recente di AWS IoT Device Tester for FreerTOS**
| **AWS IoT Device Tester versione** | **Versioni della suite di test** | **Versioni FreerTOS supportate** | **Link per il download** | **Data di rilascio** | **Note di rilascio** |
| --- | --- | --- | --- | --- | --- |
| IDT v4.9.0 | FRQ\$12.5.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/dev-test-versions-afr.html) | 04 aprile 2023 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/dev-test-versions-afr.html) |
**Nota**
Non è consigliabile che più utenti eseguano IDT da un percorso condiviso, ad esempio una directory NFS o una cartella condivisa di rete Windows. Questa pratica potrebbe causare arresti anomali o il danneggiamento dei dati. Si consiglia di estrarre il pacchetto IDT in un'unità locale ed eseguire il file binario IDT sulla workstation locale.
## Versioni IDT precedenti per FreerTOS
Sono supportate anche le seguenti versioni precedenti di IDT per FreerTOS.
**Versioni precedenti di AWS IoT Device Tester for FreerTOS**
| **AWS IoT Device Tester versione** | **Versioni della suite di test** | **Versioni FreerTOS supportate** | **Link per il download** | **Data di rilascio** | **Note di rilascio** |
| --- | --- | --- | --- | --- | --- |
| IDT v4.8.1 | FRQ\$12.4.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/dev-test-versions-afr.html) | 23.01.23 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/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/it_it/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/dev-test-versions-afr.html) | 2022.11.16 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/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/it_it/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/dev-test-versions-afr.html) | 14.10.2022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/dev-test-versions-afr.html) |
Per ulteriori informazioni, consulta [Comprendi la politica di supporto per AWS IoT Device Tester](idt-support-policy.md).
# Versioni IDT non supportate per FreerTOS
Questa sezione elenca le versioni non supportate di IDT per FreerTOS. Le versioni non supportate non ricevono correzioni di bug o aggiornamenti. Per ulteriori informazioni, consulta [Comprendi la politica di supporto per AWS IoT Device Tester](idt-support-policy.md).
Le seguenti versioni di IDT-FreeRTOS non sono più supportate.
**Versioni non supportate di AWS IoT Device Tester for FreerTOS**
| **AWS IoT Device Tester versione** | **Versioni della suite di test** | **Versioni FreerTOS supportate** | **Data di rilascio** | **Note di rilascio** |
| --- | --- | --- | --- | --- |
| IDT v4.5.10 | FRQ\$12.1.4 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 02/09/2022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/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/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.08.17 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/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/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.06.29 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/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/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 06/2022.06 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/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/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.05.31 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/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/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.05.09 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.2 | FRQ\$11.6.2 | 202107,00 | 2022,01,25 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.0.3 | FRQ\$11.5.1 | 202012,00 | 2021,07,30 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.3.0 | FRQ\$11.6.1 | 202107,00 | 2021,07,26 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.1.0 | FRQ\$11.6.0 | 202107,00 | 2021,07,21 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.0.1 | FRQ\$11.4.1 | 202012,00 | 2021,01,19 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.4.0 | FRQ\$11.3.0 | 202011,01 | 2020,11,05 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.3.0 | FRQ\$11.2.0 | 202007,00 | 2020,09,17 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/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/it_it/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/it_it/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/it_it/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/it_it/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/it_it/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/it_it/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/it_it/freertos/latest/userguide/idt-unsupported-versions-afr.html) | | Aggiunto il supporto per testare i dispositivi FreerTOS con il sistema di build CMAKE. |
| IDT-FreeRTOS v1.1 | FRQ\$11.0.0 | | | |
| IDT-FreeRTOS v1.0 | FRQ\$11.0.0 | | | |
# Scarica IDT per FreerTOS
Questo argomento descrive le opzioni per scaricare IDT per FreerTOS. È possibile utilizzare uno dei seguenti collegamenti per il download del software oppure seguire le istruzioni per scaricare IDT a livello di codice.
**Importante**
A ottobre 2022, AWS IoT Device Tester per AWS IoT FreerTOS Qualification (FRQ) 1.0 non genera report di qualificazione firmati. Non è possibile qualificare nuovi dispositivi AWS IoT FreerTOS da inserire nel [Partner Device Catalog tramite AWS il Device](https://partners.amazonaws.com/qualified-devices) [Qualification Program utilizzando AWS le versioni](https://aws.amazon.com/partners/programs/dqp/) IDT FRQ 1.0. Sebbene non sia possibile qualificare i dispositivi FreerTOS utilizzando IDT FRQ 1.0, è possibile continuare a testare i dispositivi FreerTOS con FRQ 1.0. [Ti consigliamo di utilizzare [IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) per qualificare ed elencare i dispositivi FreerTOS nel Partner Device Catalog.AWS](https://partners.amazonaws.com/qualified-devices)
**Topics**
+ [Scarica IDT manualmente](#idt-download-options)
+ [Scarica IDT a livello di codice](idt-programmatic-download-process.md)
Scaricando il software, l'utente accetta il Contratto di AWS IoT Device Tester licenza contenuto nell'archivio dei download.
**Nota**
IDT non supporta l'esecuzione da parte di più utenti da un percorso condiviso, ad esempio una directory NFS o una cartella condivisa di rete Windows. Si consiglia di estrarre il pacchetto IDT in un'unità locale ed eseguire il file binario IDT sulla workstation locale.
## Scarica IDT manualmente
Questo argomento elenca le versioni supportate di IDT per FreerTOS. Come best practice, ti consigliamo di utilizzare la versione più recente AWS IoT Device Tester che supporti la versione di destinazione di FreerTOS. Le nuove versioni di FreerTOS potrebbero richiedere il download di una nuova versione di. AWS IoT Device Tester Riceverai una notifica quando avvii un test se non AWS IoT Device Tester è compatibile con la versione di FreerTOS che stai utilizzando.
Consulta la sezione [Versioni supportate di AWS IoT Device Tester](dev-test-versions-afr.md)
# Scarica IDT a livello di codice
IDT fornisce un'operazione API che è possibile utilizzare per recuperare un URL da cui scaricare IDT a livello di codice. Puoi anche utilizzare questa operazione API per verificare se disponi della versione più recente di IDT. Questa operazione API ha il seguente endpoint.
```
https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt
```
Per richiamare questa operazione API, è necessario disporre dell'autorizzazione per eseguire l'**iot-device-tester:LatestIdt**azione. Includi AWS la tua firma, con `iot-device-tester` come nome del servizio
## Richiesta API
HostOs — Il sistema operativo del computer host. Seleziona una delle opzioni seguenti:
+ `mac`
+ `linux`
+ `windows`
TestSuiteType — Il tipo di suite di test. Scegliete la seguente opzione:
`FR`— IDT per FreerTOS
ProductVersion
(Opzionale) La versione di FreerTOS. Il servizio restituisce l'ultima versione compatibile di IDT per quella versione di FreerTOS. Se non specifichi questa opzione, il servizio restituisce l'ultima versione di IDT.
## Risposta API
La risposta dell'API ha il seguente formato. `DownloadURL`Include un file 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
}
}
```
## Esempi
È possibile fare riferimento ai seguenti esempi per scaricare IDT a livello di programmazione. Questi esempi utilizzano credenziali memorizzate nelle variabili di ambiente e. `AWS_ACCESS_KEY_ID` `AWS_SECRET_ACCESS_KEY` Per seguire le migliori pratiche di sicurezza, non memorizzate le credenziali nel codice.
**Example**
**Esempio: download utilizzando cURL versione 7.75.0 o successiva (Mac e Linux)**
Se hai cURL versione 7.75.0 o successiva, puoi usare il `aws-sigv4` flag per firmare la richiesta API. Questo esempio utilizza [jq](https://stedolan.github.io/jq/) per analizzare l'URL di download dalla risposta.
**Il `aws-sigv4` flag richiede che i parametri di query della richiesta curl GET siano nell'ordine di **HostOs/ProductVersion/TestSuiteType**o/. HostOs TestSuiteType** Gli ordini non conformi comporteranno un errore nell'ottenere firme non corrispondenti per la stringa canonica dall'API Gateway.
Se il parametro opzionale **ProductVersion**è incluso, è necessario utilizzare una versione del prodotto supportata come documentato in [Versioni supportate di AWS IoT Device Tester per FreerTOS](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html).
+ Sostituisci con il tuo*us-west-2*. Regione AWS Per l'elenco dei codici regionali, consulta [Endpoint regionali](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints).
+ Sostituiscilo *linux* con il sistema operativo del computer host.
+ Sostituisci *202107.00* con la tua versione di 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**
**Esempio: download utilizzando una versione precedente di cURL (Mac e Linux)**
È possibile utilizzare il seguente comando cURL con una AWS firma da firmare e calcolare. Per ulteriori informazioni su come firmare e calcolare una AWS firma, consulta [Firmare le richieste AWS API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html).
+ Sostituiscilo *linux* con il sistema operativo del computer host.
+ Sostituisci *Timestamp* con data e ora, ad esempio**20220210T004606Z**.
+ Sostituisci *Date* con la data, ad esempio**20220210**.
+ Sostituisci *AWSRegion* con il tuo Regione AWS. Per l'elenco dei codici regionali, consulta [Endpoint regionali](https://docs.aws.amazon.com/general/latest/gr/rande.html).
+ Sostituiscilo *AWSSignature* con la [AWS firma](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv-create-signed-request.html) generata.
```
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**
**Esempio: download utilizzando uno script Python**
Questo esempio utilizza la libreria di [richieste](https://pypi.org/project/requests/) Python. Questo esempio è adattato dall'esempio Python per [Sign an AWS API request](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) nel *AWS General* Reference.
+ Sostituisci *us-west-2* con la tua regione. Per l'elenco dei codici regionali, consulta [Endpoint regionali](https://docs.aws.amazon.com/general/latest/gr/rande.html).
+ Sostituiscilo *linux* con il sistema operativo del computer 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 con suite di qualificazione FreerTOS 2.0 (FRQ 2.0)
La suite di qualificazione FreerTOS 2.0 è una versione aggiornata della suite di qualificazione FreerTOS. Consigliamo agli sviluppatori di utilizzare FRQ 2.0 perché consiste in casi di test pertinenti per qualificare i dispositivi che eseguono le librerie FreerTOS Long Term Support (LTS).
IDT for FreerTOS verifica la porta di FreerTOS sul microcontrollore e se comunica efficacemente con. AWS IoT In particolare, verifica le interfacce del livello di porting con le librerie FreeRTOS e se i repository di test FreerTOS sono implementati correttamente. end-to-end AWS IoT Core Esegue anche test con. [I test eseguiti da IDT per FreerTOS sono definiti nel repository FreerTOS. GitHub](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests)
IDT per FreerTOS esegue i test come applicazioni integrate che lampeggiano sul dispositivo microcontrollore sottoposto a test. Le immagini binarie dell'applicazione includono FreeRTOS, le interfacce FreeRTOS con porting e i driver dei dispositivi di scheda. Lo scopo dei test è verificare che le interfacce FreeRTOS con porting funzionino correttamente sui driver del dispositivo.
IDT for FreerTOS genera report di test che puoi inviare AWS IoT per inserire il tuo hardware nel Partner Device Catalog. AWS Per ulteriori informazioni, consulta [AWS Device Qualification Program](https://aws.amazon.com/partners/dqp/).
IDT per FreerTOS viene eseguito su un computer host (Windows, macOS o Linux) collegato al dispositivo in fase di test. IDT configura e orchestra i casi di test e aggrega i risultati. Fornisce inoltre un'interfaccia a riga di comando per gestire l'esecuzione dei test.
Per testare il tuo dispositivo, IDT for FreeRTOS crea risorse come AWS IoT oggetti, gruppi FreerTOS, funzioni Lambda. Per creare queste risorse, IDT for FreerTOS utilizza AWS le credenziali configurate in per effettuare chiamate API per `config.json` tuo conto. Il provisioning di queste risorse viene effettuato varie volte nel corso di un test.
Quando esegui IDT for FreerTOS sul tuo computer host, esegue i seguenti passaggi:
1. Carica e convalida la configurazione del dispositivo e delle credenziali.
1. Esegue i test selezionati con le risorse locali e cloud richieste.
1. Esegue la pulizia di risorse locali e cloud.
1. Genera i report di test che indicano se la scheda ha superato i test richiesti per la qualifica.
# Imposta i prerequisiti di qualificazione LTS
Questa sezione descrive i prerequisiti per testare i microcontrollori con. AWS IoT Device Tester
## Preparati per la qualificazione FreerTOS
**Nota**
AWS IoT Device Tester for FreerTOS consiglia vivamente di utilizzare l'ultima patch release della versione più recente di FreeRTOS-LTS.
IDT for FRQ 2.0 è una qualifica per FreerTOS. *Prima di avviare IDT FRQ 2.0 per la qualificazione, devi completare [Qualifying your board nella FreerTOS Qualification](https://docs.aws.amazon.com/freertos/latest/qualificationguide/freertos-qualification.html) Guide.* *Per effettuare il porting delle librerie, i test e la configurazione di`manifest.yml`, consulta [Porting the FreerTOS librerie nella FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting.html) Porting Guide.* FRQ 2.0 contiene un processo di qualificazione diverso. Vedi [le ultime modifiche alle qualifiche nella guida alla qualificazione](https://docs.aws.amazon.com/freertos/latest/qualificationguide/latest-changes.html) di *FreerTOS* per i dettagli.
Il repository [FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests) deve essere presente affinché IDT possa funzionare. Vedi [README.md](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests/blob/main/README.md) su come clonare e trasferire questo repository sul tuo progetto sorgente. FreeRTOS-Libraries-Integration-Testsè necessario includere il file che `manifest.yml` si trova nella radice del progetto, affinché IDT possa funzionare.
**Nota**
IDT dipende dall'implementazione di. `UNITY_OUTPUT_CHAR` I log dei risultati dei test e i log del dispositivo non devono interlacciarsi tra loro. Vedi [la sezione Implementazione delle macro di registrazione della libreria nella FreerTOS Porting](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-library-logging-macros.html) *Guide per ulteriori dettagli*.
## Scarica IDT per FreerTOS
Ogni versione di FreerTOS ha una versione corrispondente di IDT per FreerTOS per eseguire test di qualificazione. Scarica la versione appropriata di IDT per FreerTOS [dalle versioni](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html) supportate di per FreerTOS. AWS IoT Device Tester
Estrai IDT for FreerTOS in una posizione del file system in cui disponi dei permessi di lettura e scrittura. Poiché Microsoft Windows ha un limite di caratteri per la lunghezza del percorso, estrai IDT per FreerTOS in una directory principale come o. `C:\` `D:\`
**Nota**
Più utenti non devono eseguire IDT da una posizione condivisa, come una directory NFS o una cartella condivisa di rete Windows. Ciò provocherà arresti anomali o danneggiamento dei dati. Si consiglia di estrarre il pacchetto IDT in un'unità locale.
## Scarica Git
IDT deve avere Git installato come prerequisito per garantire l'integrità del codice sorgente.
Segui le istruzioni nella [GitHub](https://github.com/git-guides/install-git)guida per installare Git. Per verificare la versione attualmente installata di Git, inserisci il comando `git --version` nel terminale.
**avvertimento**
IDT usa Git per allinearsi allo stato pulito o sporco di una directory. Se Git non è installato, i gruppi di `FreeRTOSIntegrity` test falliranno o non verranno eseguiti come previsto. Se IDT restituisce un errore come `git executable not found` o`git command not found`, installa o reinstalla Git e riprova.
**Topics**
+ [Preparati per la qualificazione FreerTOS](#idt-preparing-qualification)
+ [Scarica IDT per FreerTOS](#idt-download-dev-tester-afr)
+ [Scarica Git](#idt-download-git)
+ [Crea un account AWS](#lts-config-aws-account)
+ [AWS IoT Device Tester politica gestita](#managed-policy)
+ [(Facoltativo) Installa il AWS Command Line Interface](#install-cli)
## Crea un account AWS
**Nota**
La suite di qualificazione IDT completa è supportata solo nei seguenti paesi Regioni AWS
Stati Uniti orientali (Virginia settentrionale)
Stati Uniti occidentali (Oregon)
Asia Pacifico (Tokyo)
Europa (Irlanda)
Per testare il tuo dispositivo, IDT for FreeRTOS crea risorse come AWS IoT oggetti, gruppi FreeRTOS e funzioni Lambda. Per creare tali risorse, IDT for FreerTOS richiede la creazione e la configurazione di AWS un account e una policy IAM che conceda a IDT for FreerTOS l'autorizzazione ad accedere alle risorse per tuo conto durante l'esecuzione dei test.
I seguenti passaggi servono a creare e configurare il tuo account. AWS
1. Se hai già un AWS account, vai al passaggio successivo. Altrimenti crea un [AWS account](https://aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/).
1. Segui i passaggi descritti in [Creazione di ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html). Al momento non aggiungere autorizzazioni o politiche.
1. Per eseguire i test di qualificazione OTA, vai al passaggio 4. Altrimenti vai al passaggio 5.
1. Allega la policy in linea per le autorizzazioni OTA IAM al tuo ruolo IAM.
1.
**Importante**
Il modello di policy seguente concede l'autorizzazione IDT per creare ruoli, policy e collegare policy ai ruoli. IDT for FreerTOS utilizza queste autorizzazioni per i test che creano ruoli. Sebbene il modello di policy non fornisca privilegi di amministratore all'utente, le autorizzazioni possono essere utilizzate per ottenere l'accesso come amministratore al proprio account. AWS
1. Segui i passaggi seguenti per assegnare le autorizzazioni necessarie al tuo ruolo IAM:
1. Nella pagina **Autorizzazioni, scegli **Aggiungi** autorizzazioni**.
1. Scegli **Create inline policy** (Crea policy in linea).
1. Scegliere la scheda **JSON** e copiare le seguenti autorizzazioni nella casella di testo **JSON** . Usa il modello sotto **La maggior parte delle regioni** se non ti trovi nella regione Cina. Se ti trovi nella regione della Cina, usa il modello in Regioni di **Pechino 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 ]
Il seguente modello di politica può essere utilizzato nelle regioni di Pechino e Ningxia.
------
1. Al termine, seleziona **Review policy (Rivedi policy)**.
1. Inserisci **IDTFreeRTOSIAMPermissions**come nome della politica.
1. Scegli **Crea policy**.
1. Allega **AWSIoTDeviceTesterForFreeRTOSFullAccess** al tuo ruolo IAM.
1. Per assegnare le autorizzazioni necessarie al tuo ruolo IAM:
1. Nella pagina **Autorizzazioni, scegli **Aggiungi** autorizzazioni**.
1. Scegli **Collega policy**.
1. Cerca la politica di **AWSIoTDeviceTesterForFreeRTOSFullaccesso**. Seleziona la casella.
1. Scegli **Add Permissions (Aggiungi autorizzazioni)**.
1. Esporta le credenziali per IDT. Per ulteriori dettagli, consulta [Ottenere le credenziali del ruolo IAM per l'accesso alla CLI](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtogetcredentials.html).
## AWS IoT Device Tester politica gestita
La policy `AWSIoTDeviceTesterForFreeRTOSFullAccess` gestita contiene le seguenti AWS IoT Device Tester autorizzazioni per il controllo della versione, le funzionalità di aggiornamento automatico e la raccolta di metriche.
+ `iot-device-tester:SupportedVersion`
Concede AWS IoT Device Tester l'autorizzazione a recuperare l'elenco dei prodotti supportati, delle suite di test e delle versioni IDT.
+ `iot-device-tester:LatestIdt`
Concede AWS IoT Device Tester l'autorizzazione a recuperare l'ultima versione IDT disponibile per il download.
+ `iot-device-tester:CheckVersion`
Concede AWS IoT Device Tester l'autorizzazione a verificare la compatibilità delle versioni per IDT, suite di test e prodotti.
+ `iot-device-tester:DownloadTestSuite`
Concede AWS IoT Device Tester l'autorizzazione a scaricare gli aggiornamenti della suite di test.
+ `iot-device-tester:SendMetrics`
Concede AWS l'autorizzazione a raccogliere metriche sull' AWS IoT Device Tester utilizzo interno.
## (Facoltativo) Installa il AWS Command Line Interface
Potresti preferire utilizzare il AWS CLI per eseguire alcune operazioni. Se non lo hai AWS CLI installato, segui le istruzioni in [Installare il AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html).
Configuralo AWS CLI per la AWS regione che desideri utilizzare eseguendolo **aws configure** da una riga di comando. [Per informazioni sulle AWS regioni che supportano IDT for FreerTOS,AWS consulta Regioni ed endpoint.](https://docs.aws.amazon.com/general/latest/gr/rande.html#amazon-freertos-ota-control) [Per ulteriori informazioni, **aws configure** vedere Configurazione rapida con. **aws configure**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)
# Primo test della scheda del microcontrollore
Puoi usare IDT for FreerTOS per testare la tua implementazione delle librerie FreerTOS. Dopo aver effettuato il porting delle librerie FreerTOS per i driver di dispositivo della tua scheda, AWS IoT Device Tester usale per eseguire i test di qualificazione sulla tua scheda microcontrollore.
## Aggiunta di livelli di porting delle librerie
[Per portare FreerTOS sul tuo dispositivo, consulta la FreerTOS Porting Guide.](https://docs.aws.amazon.com/freertos/latest/portingguide/porting-guide.html) Quando si implementa il repository dei test FreerTOS e si esegue il porting dei layer FreerTOS, è necessario fornire `manifest.yml` un percorso a ciascuna libreria, incluso l'archivio dei test. Questo file si troverà nella directory principale del codice sorgente. Consultate [le istruzioni del file manifest](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist-manifest-instr.html) per i dettagli.
## Configura AWS le tue credenziali AWS IoT Device Tester per comunicare con il Cloud AWS
È necessario configurare le AWS credenziali AWS IoT Device Tester per comunicare con il AWS Cloud. Per ulteriori informazioni, consulta [Configurare AWS le credenziali e la regione per](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html) lo sviluppo. AWS Le credenziali valide sono specificate nel `devicetester_extract_location/devicetester_freertos_[win|mac|linux]/configs/config.json` file di configurazione.
```
"auth": {
"method": "environment"
}
"auth": {
"method": "file",
"credentials": {
"profile": ""
}
}
```
L'`auth`attributo del `config.json` file ha un campo di metodo che controlla AWS l'autenticazione e può essere dichiarato come file o come ambiente. L'impostazione del campo su environment estrae le AWS credenziali dalle variabili di ambiente della macchina host. L'impostazione del campo su file importa un profilo specificato dal file di `.aws/credentials` configurazione.
**Topics**
+ [Aggiunta di livelli di porting delle librerie](#lts-add-port-layer)
+ [Configura AWS le tue credenziali AWS IoT Device Tester per comunicare con il Cloud AWS](#lts-cfg-aws-afr)
+ [Crea un pool di dispositivi in IDT per FreerTOS](lts-cfg-dt-dp.md)
+ [Configurazione delle impostazioni di compilazione, flashing e test](lts-cfg-dt-ud.md)
# Crea un pool di dispositivi in IDT per FreerTOS
I dispositivi da testare sono organizzati in pool di dispositivi. Ogni pool di dispositivi è composto da uno o più dispositivi identici. Puoi configurare IDT per FreerTOS per testare un singolo dispositivo o più dispositivi in un pool. Per accelerare il processo di qualificazione, IDT for FreerTOS può testare dispositivi con le stesse specifiche in parallelo. Lo strumento utilizza un metodo Round Robin per eseguire un gruppo di test differente su ciascun dispositivo di un pool.
Il `device.json` file ha un array nel suo livello superiore. Ogni attributo dell'array è un nuovo pool di dispositivi. Ogni pool di dispositivi ha un attributo di array di dispositivi, che ha più dispositivi dichiarati. Nel modello è presente un pool di dispositivi e solo un dispositivo in quel pool di dispositivi. È possibile aggiungere uno o più dispositivi a un pool di dispositivi modificando la sezione `devices` del modello `device.json` nella cartella `configs`.
**Nota**
Tutti i dispositivi dello stesso pool devono avere le stesse specifiche tecniche e lo stesso SKU. Per abilitare le build parallele del codice sorgente per diversi gruppi di test, IDT for FreerTOS copia il codice sorgente in una cartella dei risultati all'interno della cartella estratta IDT for FreerTOS. È necessario fare riferimento al percorso del codice sorgente nel comando build o flash utilizzando la variabile. `testdata.sourcePath` IDT for FreerTOS sostituisce questa variabile con un percorso temporaneo del codice sorgente copiato. Per ulteriori informazioni, consulta [IDT per variabili FreerTOS](lts-dt-vars.md).
Di seguito è riportato un `device.json` file di esempio utilizzato per creare un pool di dispositivi con più dispositivi.
```
[
{
"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"
}
]
}
]
}
]
```
I seguenti attributi vengono utilizzati nel file `device.json`:
** `id` **
Un ID alfanumerico definito dall'utente che identifica in modo univoco un pool di dispositivi. I dispositivi appartenenti a un pool devono essere dello stesso tipo. Durante l'esecuzione di una suite di test, i dispositivi del pool vengono utilizzati per parallelizzare il carico di lavoro.
** `sku` **
Un valore alfanumerico che identifica in modo univoco la scheda da testare. Il codice SKU viene utilizzato per tenere traccia delle schede qualificate.
Se desideri inserire la tua scheda nel AWS Partner Device Catalog, lo SKU che specifichi qui deve corrispondere allo SKU che utilizzi nel processo di pubblicazione delle offerte.
** `features` **
Un array che contiene le funzionalità supportate dal dispositivo. AWS IoT Device Tester utilizza queste informazioni per selezionare i test di qualificazione da eseguire.
I valori supportati sono:
** `Wifi` **
Indica se la scheda dispone di funzionalità Wi-Fi.
** `Cellular` **
Indica se la scheda dispone di funzionalità di rete cellulare.
** `PKCS11` **
Indica l'algoritmo di crittografia a chiave pubblica supportato dalla scheda. PKCS11 è necessario per la qualificazione. I valori supportati sono `ECC``RSA`, e`Both`. `Both`indica che la scheda supporta entrambi `ECC` e`RSA`.
** `KeyProvisioning` **
Indica il metodo di scrittura di un certificato client X.509 attendibile sulla scheda.
I valori validi sono `Import``Onboard`, `Both` e`No`. `Onboard``Both`, oppure per la qualificazione è richiesta la fornitura delle `No` chiavi. `Import`da sola non è un'opzione valida per la qualificazione.
+ `Import`Utilizzalo solo se la tua scheda consente l'importazione di chiavi private. `Import`La selezione non è una configurazione valida per la qualificazione e deve essere utilizzata solo a scopo di test, in particolare per i casi di PKCS11 test. `Onboard`, `Both` o `No` è necessario per la qualificazione.
+ Utilizzalo `Onboard` se la tua scheda supporta le chiavi private integrate (ad esempio, se il tuo dispositivo ha un elemento sicuro o se preferisci generare la tua coppia di chiavi e il tuo certificato del dispositivo). Assicurarsi di aggiungere un elemento `secureElementConfig` in ciascuna delle sezioni del dispositivo e inserire il percorso assoluto del file della chiave pubblica nel campo `publicKeyAsciiHexFilePath`.
+ Utilizzalo `Both` se la tua scheda supporta sia l'importazione di chiavi private che la generazione di chiavi integrate per il provisioning delle chiavi.
+ Utilizzalo `No` se la tua scheda non supporta il provisioning delle chiavi. `No`è un'opzione valida solo quando anche il dispositivo è preconfigurato.
** `OTA` **
Indica se la scheda supporta la funzionalità di aggiornamento over-the-air (OTA). L'attributo `OtaDataPlaneProtocol` indica quale protocollo di piano dei dati OTA supporta il dispositivo. Per la qualificazione è richiesta una OTA con protocollo dataplane HTTP o MQTT. Per ignorare l'esecuzione dei test OTA durante il test, imposta la funzionalità OTA su e l'attributo su`No`. `OtaDataPlaneProtocol` `None` Questa non sarà una corsa di qualificazione.
** `BLE` **
Indica se la scheda supporta Bluetooth Low Energy (BLE).
** `devices.id` **
Un identificativo univoco definito dall'utente del dispositivo sottoposto a test.
** `devices.connectivity.serialPort` **
La porta seriale del computer host utilizzato per connettersi ai dispositivi da testare.
** `devices.secureElementConfig.PublicKeyAsciiHexFilePath` **
Obbligatoria se la tavola NON è `pre-provisioned` o non `PublicDeviceCertificateArn` viene fornita. Poiché `Onboard` è un tipo obbligatorio di Key Provisioning, questo campo è attualmente obbligatorio per il gruppo di test FullTransportInterface TLS. Se il dispositivo lo è`pre-provisioned`, `PublicKeyAsciiHexFilePath` è facoltativo e non deve essere incluso.
Il blocco seguente è un percorso assoluto del file che contiene la chiave pubblica in byte esadecimali estratta dalla chiave `Onboard` privata.
```
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 la chiave pubblica è in formato.der, puoi codificare direttamente in esadecimale la chiave pubblica per generare il file esadecimale.
Per generare il file esadecimale da una chiave pubblica.der, inserisci il seguente comando: **xxd**
```
xxd -p pubkey.der > outFile
```
Se la tua chiave pubblica è in formato.pem, puoi estrarre le intestazioni e i piè di pagina codificati in base64 e decodificarla in formato binario. Quindi, codificate in modo esadecimale la stringa binaria per generare il file esadecimale.
Per generare un file esadecimale per una chiave pubblica.pem, procedi come segue:
1. Esegui il **base64** comando seguente per rimuovere l'intestazione e il piè di pagina base64 dalla chiave pubblica. La chiave decodificata, denominata`base64key`, viene quindi emessa nel file: `pubkey.der`
```
base64 —decode base64key > pubkey.der
```
1. Esegui il seguente **xxd** comando per `pubkey.der` convertire in formato esadecimale. La chiave risultante viene salvata come `outFile`
```
xxd -p pubkey.der > outFile
```
** `devices.secureElementConfig.PublicDeviceCertificateArn` **
L'ARN del certificato del tuo elemento sicuro su cui viene caricato. AWS IoT Core*Per informazioni sul caricamento del certificato su AWS IoT Core, consulta i [certificati client X.509](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html) nella Developer Guide.AWS IoT *
** `devices.secureElementConfig.SecureElementSerialNumber` **
(Facoltativo) Il numero di serie dell'elemento sicuro. Il numero di serie viene utilizzato opzionalmente per creare certificati di dispositivo per la fornitura di chiavi JITR.
** `devices.secureElementConfig.preProvisioned` **
(Facoltativo) Imposta su «Sì» se il dispositivo dispone di un elemento sicuro preconfigurato con credenziali bloccate, che non può importare, creare o distruggere oggetti. Se questo attributo è impostato su **Sì, è necessario fornire le etichette** pkcs11 corrispondenti.
** `devices.secureElementConfig.pkcs11JITPCodeVerifyRootCertSupport` **
(Facoltativo) Imposta su **Sì** se l'PKCS11 implementazione principale del dispositivo supporta l'archiviazione per JITP. Ciò abiliterà il test JITP durante il `codeverify` test di base di PKCS 11 e richiede la fornitura della chiave di verifica del codice, del certificato JITP e delle etichette PKCS 11 del certificato radice.
** `identifiers` **
(Facoltativo) Un array di coppie nome/valore arbitrarie. Puoi utilizzare questi valori nei comandi di compilazione e flashing descritti nella sezione successiva.
# Configurazione delle impostazioni di compilazione, flashing e test
IDT for FreerTOS crea e invia automaticamente i test sulla scheda. Per abilitare ciò, è necessario configurare IDT per eseguire i comandi build e flash per il proprio hardware. Le impostazioni dei comandi di compilazione e flashing sono configurate nel file di modello `userdata.json` che si trova nella cartella `config`.
# Configurazione delle impostazioni per il testing dei dispositivi
Le impostazioni di compilazione, flashing e test vengono eseguite nel file `configs/userdata.json`. Il seguente esempio JSON mostra come configurare IDT per FreerTOS per testare più dispositivi:
```
{
"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": ""
}
}
```
Il seguente elenca gli attributi utilizzati in `userdata.json`:
** `sourcePath` **
Il percorso alla radice del codice sorgente di FreerTOS portato.
** `retainModifiedSourceDirectories` **
(Facoltativo) Verifica se conservare le directory sorgente modificate utilizzate durante la compilazione e il flashing per scopi di debug. Se impostata su`true`, le directory di origine modificate vengono denominate RetainedSrc e si trovano nelle cartelle di registro dei risultati di ogni esecuzione del gruppo di test. Se non è incluso, il valore predefinito del campo è. `false`
** `freeRTOSTestParamConfigPath` **
Il percorso del `test_param_config.h` file per FreeRTOS-Libraries-Integration-Tests l'integrazione. Questo file deve utilizzare la variabile `{{testData.sourcePath}}` placeholder per renderlo relativo alla radice del codice sorgente. AWS IoT Device Tester utilizza i parametri di questo file per configurare i test.
** `freeRTOSTestExecutionConfigPath` **
Il percorso del `test_execution_config.h` file per FreeRTOS-Libraries-Integration-Tests l'integrazione. Questo file deve utilizzare la variabile `{{testData.sourcePath}}` placeholder per renderlo relativo alla radice del repository. AWS IoT Device Tester utilizza questo file per controllare quali test devono essere eseguiti.
** `freeRTOSVersion` **
La versione di FreerTOS inclusa la versione patch utilizzata nell'implementazione. Vedi [Versioni supportate di AWS IoT Device Tester for FreeRTOS](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html) per le versioni FreeRTOS compatibili con for FreerTOS. AWS IoT Device Tester
** `buildTool` **
Il comando per creare il codice sorgente. Tutti i riferimenti al percorso del codice sorgente nel comando build devono essere sostituiti dalla AWS IoT Device Tester variabile`{{testData.sourcePath}}`. Utilizzate il `{{config.idtRootPath}}` segnaposto per fare riferimento a uno script di compilazione relativo al percorso AWS IoT Device Tester principale.
** `flashTool` **
Il comando per far lampeggiare un'immagine sul dispositivo. Tutti i riferimenti al percorso del codice sorgente nel comando flash devono essere sostituiti dalla AWS IoT Device Tester variabile`{{testData.sourcePath}}`. Utilizzate il `{{config.idtRootPath}}` segnaposto per fare riferimento a uno script flash relativo al AWS IoT Device Tester percorso principale.
La nuova struttura dei test di integrazione con FRQ 2.0 non richiede variabili di percorso come e. `{{enableTests}}` `{{buildImageName}}` I test OTA End to End vengono eseguiti con i modelli di configurazione forniti nel [ FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests/blob/main/config_template/) GitHub repository. Se i file del GitHub repository sono presenti nel progetto sorgente principale, il codice sorgente non viene modificato tra un test e l'altro. Se è necessaria un'immagine di build diversa per OTA End to End, è necessario creare questa immagine nello script di compilazione e specificarla nel `userdata.json` file specificato sotto`otaConfiguration`.
** `testStartDelayms` **
Speciifica quanti millisecondi aspetterà il test runner FreerTOS prima di iniziare a eseguire i test. Ciò può essere utile se il dispositivo sottoposto a test inizia a emettere importanti informazioni di test prima che IDT abbia la possibilità di connettersi e avviare la registrazione a causa di problemi di rete o di altro tipo. Questo valore è applicabile solo ai gruppi di test FreerTOS e non ad altri gruppi di test che non utilizzano il test runner FreerTOS, come i test OTA. Se ricevi un errore relativo a **10 previsto ma ne ricevi 5**, questo campo deve essere impostato su 5000.
** `echoServerConfiguration` **
La configurazione per configurare il server echo per il test TLS. Questo campo è obbligatorio.
** `keyGenerationMethod` **
Il server echo è configurato con questa opzione. Le opzioni sono EC o RSA.
** `serverPort` **
Il numero di porta su cui viene eseguito il server echo.
** `otaConfiguration` **
La configurazione per i test OTA PAL e OTA E2E. Questo campo è obbligatorio.
**`otaE2EFirmwarePath`**
Percorso dell'immagine del contenitore OTA utilizzata da IDT per i test OTA End to End.
** `otaPALCertificatePath` **
Il percorso del certificato per il test OTA PAL sul dispositivo. Viene utilizzato per verificare la firma. Ad esempio, **ecdsa-sha256-signer.crt.pem**.
** `deviceFirmwarePath` **
Il percorso del nome codificato per l'avvio dell'immagine del firmware. Se il dispositivo NON utilizza il file system per l'avvio del firmware, specifica questo campo come`'NA'`. Se il dispositivo utilizza il file system per l'avvio del firmware, specifica il percorso o il nome dell'immagine di avvio del firmware.
** `codeSigningConfiguration` **
** `signingMethod` **
Il metodo di firma del codice. I valori possibili sono AWS o Personalizzato.
Per le regioni di Pechino e Ningxia, usa Custom. AWS la firma del codice non è supportata in quella regione.
** `signerHashingAlgorithm` **
L'algoritmo hash supportato sul dispositivo. I valori possibili sono `SHA1` o `SHA256`.
** `signerSigningAlgorithm` **
L'algoritmo di firma supportato sul dispositivo. I valori possibili sono `RSA` o `ECDSA`.
** `signerCertificate` **
Il certificato attendibile utilizzato per OTA. Per il metodo di firma del AWS codice, usa Amazon Resource Name (ARN) per il certificato affidabile caricato su Certificate Manager AWS . Per il metodo di firma del codice personalizzato, utilizza il percorso assoluto del file del certificato del firmatario. Per informazioni sulla creazione di un certificato affidabile, consulta [Creare un certificato di firma del codice](https://docs.aws.amazon.com/freertos/latest/userguide/ota-code-sign-cert.html).
** `untrustedSignerCertificate` **
L'ARN o il percorso del file per un secondo certificato utilizzato in alcuni test OTA come certificato non attendibile. Per informazioni sulla creazione di un certificato, consulta [Creare un](https://docs.aws.amazon.com//freertos/latest/userguide/ota-code-sign-cert.html) certificato di firma del codice.
** `signerCertificateFileName` **
Il nome del file del certificato di firma del codice sul dispositivo. Questo valore deve corrispondere al nome di file fornito durante l'esecuzione del `aws acm import-certificate` comando.
** `compileSignerCertificate` **
Valore booleano che determina lo stato del certificato di verifica della firma. I valori validi sono `true` e `false`.
Imposta questo valore su **true** se il certificato di verifica della firma del firmatario del codice non è fornito o visualizzato. Deve essere compilato nel progetto. AWS IoT Device Tester recupera il certificato affidabile e lo compila in. `aws_codesigner_certificate.h`
** `signerPlatform` **
L'algoritmo di firma e hashing utilizzato da AWS Code Signer durante la creazione del processo di aggiornamento OTA. Al momento, i valori possibili per questo campo sono `AmazonFreeRTOS-TI-CC3220SF` e `AmazonFreeRTOS-Default`.
+ Scegli `AmazonFreeRTOS-TI-CC3220SF` se `SHA1` e `RSA`.
+ Scegli `AmazonFreeRTOS-Default` se `SHA256` e `ECDSA`.
+ Se ti occorre `SHA256` \$1 `RSA` o `SHA1` \$1 `ECDSA` per la configurazione, contattaci per ulteriore supporto.
+ Configura `signCommand` se hai scelto `Custom` per `signingMethod`.
** `signCommand` **
Sono necessari due segnaposto `{{inputImageFilePath}}` e `{{outputSignatureFilePath}}` nel comando. `{{inputImageFilePath}}` è il percorso del file dell'immagine creata da IDT da firmare. `{{outputSignatureFilePath}} ` è il percorso del file della firma che verrà generato dallo script.
** `pkcs11LabelConfiguration` **
PKCS11 la configurazione dell'etichetta richiede almeno un set di etichette di etichetta di certificato del dispositivo, etichetta a chiave pubblica e etichetta a chiave privata per eseguire i gruppi di PKCS11 test. Le PKCS11 etichette richieste si basano sulla configurazione del dispositivo nel `device.json` file. Se pre-provisioned è impostato su **Sì** in`device.json`, le etichette richieste devono essere una delle seguenti, a seconda del tipo scelto per la PKCS11 funzionalità.
+ `PreProvisionedEC`
+ `PreProvisionedRSA`
Se pre-provisioned è impostato su **No** in`device.json`, le etichette richieste sono:
+ `pkcs11LabelDevicePrivateKeyForTLS`
+ `pkcs11LabelDevicePublicKeyForTLS`
+ `pkcs11LabelDeviceCertificateForTLS`
Le tre etichette seguenti sono obbligatorie solo se si seleziona **Sì** per `pkcs11JITPCodeVerifyRootCertSupport` nel file`device.json`.
+ `pkcs11LabelCodeVerifyKey`
+ `pkcs11LabelRootCertificate`
+ `pkcs11LabelJITPCertificate`
I valori di questi campi devono corrispondere ai valori definiti nella [FreerTOS Porting Guide](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-pkcs.html).
** `pkcs11LabelDevicePrivateKeyForTLS` **
(Facoltativo) Questa etichetta viene utilizzata per l'etichetta PKCS \$111 della chiave privata. Per i dispositivi con supporto integrato e di importazione per la fornitura di chiavi, questa etichetta viene utilizzata a scopo di test. Questa etichetta può essere diversa da quella definita per il caso predisposto. Se il provisioning delle chiavi è impostato su **No** e il pre-provisioning è impostato su **Sì**, nel`device.json`, questo non sarà definito.
** `pkcs11LabelDevicePublicKeyForTLS` **
(Facoltativo) Questa etichetta viene utilizzata per l'etichetta PKCS \$111 della chiave pubblica. Per i dispositivi con supporto integrato e di importazione per la fornitura di chiavi, questa etichetta viene utilizzata a scopo di test. Questa etichetta può essere diversa da quella definita per il caso preconfezionato. Se il provisioning delle chiavi è impostato su **No** e il pre-provisioning è impostato su **Sì**, nel`device.json`, questo non sarà definito.
** `pkcs11LabelDeviceCertificateForTLS` **
(Facoltativo) Questa etichetta viene utilizzata per l'etichetta PKCS \$111 del certificato del dispositivo. Per i dispositivi con supporto integrato e di importazione per la fornitura di chiavi, questa etichetta verrà utilizzata per i test. Questa etichetta può essere diversa da quella definita per il caso preconfezionato. Se il provisioning delle chiavi è impostato su **No** e il pre-provisioning è impostato su **Sì**, nel`device.json`, questo non sarà definito.
** `pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS` **
(Facoltativo) Questa etichetta viene utilizzata per l'etichetta PKCS \$111 della chiave privata. Per i dispositivi con elementi sicuri o limitazioni hardware, questa avrà un'etichetta diversa per conservare AWS IoT le credenziali. Se il tuo dispositivo supporta il pre-provisioning con una chiave EC, fornisci questa etichetta. Quando PreProvisioned è impostato su **Yes** in`device.json`, è necessario fornire questa etichetta o entrambe. `pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS` Questa etichetta può essere diversa da quella definita per i casi di bordo e di importazione.
** `pkcs11LabelPreProvisionedECDevicePublicKeyForTLS` **
(Facoltativo) Questa etichetta viene utilizzata per l'etichetta PKCS \$111 della chiave pubblica. Per i dispositivi con elementi sicuri o limitazioni hardware, questa avrà un'etichetta diversa per conservare AWS IoT le credenziali. Se il tuo dispositivo supporta il pre-provisioning con una chiave EC, fornisci questa etichetta. Quando PreProvisioned è impostato su **Yes** in`device.json`, è necessario fornire questa etichetta o entrambe. `pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS` Questa etichetta può essere diversa da quella definita per i casi di bordo e di importazione.
** `pkcs11LabelPreProvisionedECDeviceCertificateForTLS` **
(Facoltativo) Questa etichetta viene utilizzata per l'etichetta PKCS \$111 del certificato del dispositivo. Per i dispositivi con elementi sicuri o limitazioni hardware, questa avrà un'etichetta diversa per conservare AWS IoT le credenziali. Se il tuo dispositivo supporta il pre-provisioning con una chiave EC, fornisci questa etichetta. Quando PreProvisioned è impostato su **Yes** in`device.json`, è necessario fornire questa etichetta o entrambe. `pkcs11LabelPreProvisionedRSADeviceCertificateForTLS` Questa etichetta può essere diversa da quella definita per i casi di bordo e di importazione.
** `pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS` **
(Facoltativo) Questa etichetta viene utilizzata per l'etichetta PKCS \$111 della chiave privata. Per i dispositivi con elementi sicuri o limitazioni hardware, questa avrà un'etichetta diversa per conservare AWS IoT le credenziali. Se il tuo dispositivo supporta il pre-provisioning con una chiave RSA, fornisci questa etichetta. Quando PreProvisioned è impostato su **Yes** in`device.json`, è necessario fornire questa etichetta o `pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS` entrambe.
** `pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS` **
(Facoltativo) Questa etichetta viene utilizzata per l'etichetta PKCS \$111 della chiave pubblica. Per i dispositivi con elementi sicuri o limitazioni hardware, questa avrà un'etichetta diversa per conservare AWS IoT le credenziali. Se il tuo dispositivo supporta il pre-provisioning con una chiave RSA, fornisci questa etichetta. Quando PreProvisioned è impostato su **Yes** in`device.json`, è necessario fornire questa etichetta o `pkcs11LabelPreProvisionedECDevicePublicKeyForTLS` entrambe.
** `pkcs11LabelPreProvisionedRSADeviceCertificateForTLS` **
(Facoltativo) Questa etichetta viene utilizzata per l'etichetta PKCS \$111 del certificato del dispositivo. Per i dispositivi con elementi sicuri o limitazioni hardware, questa avrà un'etichetta diversa per conservare AWS IoT le credenziali. Se il tuo dispositivo supporta il pre-provisioning con una chiave RSA, fornisci questa etichetta. Quando PreProvisioned è impostato su **Yes** in`device.json`, è necessario fornire questa etichetta o `pkcs11LabelPreProvisionedECDeviceCertificateForTLS` entrambe.
** `pkcs11LabelCodeVerifyKey` **
(Facoltativo) Questa etichetta viene utilizzata per l'etichetta PKCS \$111 della chiave di verifica del codice. Se il dispositivo dispone del supporto per l'archiviazione PKCS \$111 del certificato JITP, della chiave di verifica del codice e del certificato root, fornisci questa etichetta. Se `pkcs11JITPCodeVerifyRootCertSupport` in `device.json` è impostato su **Sì**, questa etichetta deve essere fornita.
** `pkcs11LabelJITPCertificate` **
(Facoltativo) Questa etichetta viene utilizzata per l'etichetta PKCS \$111 del certificato JITP. Se il dispositivo dispone del supporto per l'archiviazione PKCS \$111 del certificato JITP, della chiave di verifica del codice e del certificato root, fornisci questa etichetta. Se `pkcs11JITPCodeVerifyRootCertSupport` in `device.json` è impostato su **Sì**, questa etichetta deve essere fornita.
# IDT per variabili FreerTOS
I comandi per creare il codice e eseguire il flashing del dispositivo potrebbero richiedere connettività o altre informazioni sui dispositivi per funzionare correttamente. AWS IoT Device Tester consente di fare riferimento alle informazioni sul dispositivo in flash e di creare comandi utilizzando [JsonPath](https://goessner.net/articles/JsonPath/). Utilizzando JsonPath espressioni semplici, è possibile recuperare le informazioni richieste specificate nel `device.json` file.
## Variabili di percorso
IDT per FreerTOS definisce le seguenti variabili di percorso che possono essere utilizzate nelle righe di comando e nei file di configurazione:
** `{{testData.sourcePath}}` **
Si estende al percorso del codice sorgente. Se utilizzi questa variabile, deve essere utilizzata sia nei comandi flash che di compilazione.
** `{{device.connectivity.serialPort}}` **
Si estende alla porta seriale.
** `{{device.identifiers[?(@.name == 'serialNo')].value[0]}}` **
Estende al numero seriale del dispositivo.
** `{{config.idtRootPath}}` **
Si espande fino al percorso principale. AWS IoT Device Tester
# Interfaccia utente per IDT per la suite di qualificazione FreerTOS 2.0 (FRQ 2.0)
AWS IoT Device Tester for FreerTOS (IDT for FreerTOS) include un'interfaccia utente (UI) basata sul Web in cui è possibile interagire con l'applicazione a riga di comando IDT e i relativi file di configurazione. Utilizzi l'interfaccia utente IDT for FreerTOS per creare una nuova configurazione o modificarne una esistente per il tuo dispositivo. Puoi anche usare l'interfaccia utente per chiamare l'applicazione IDT ed eseguire i test FreerTOS sul tuo dispositivo.
Per informazioni su come utilizzare la riga di comando per eseguire i test di qualificazione, consulta. [Primo test della scheda del microcontrollore](lts-qual-steps.md)
Questa sezione descrive i prerequisiti per l'interfaccia utente IDT for FreerTOS e come eseguire i test di qualificazione dall'interfaccia utente.
**Topics**
+ [Imposta i prerequisiti IDT](#lts-dev-tester-ui-prereqs)
+ [Configura le AWS credenziali per utilizzare l'interfaccia utente IDT](lts-configure-aws-credentials.md)
+ [Apri l'interfaccia utente di IDT per FreerTOS](lts-open-idt-ui.md)
+ [Crea una nuova configurazione](lts-create-new-configuration.md)
+ [Modifica una configurazione esistente](lts-modify-existing-configuration.md)
+ [Esegui test di qualificazione](lts-run-tests-from-ui.md)
## Imposta i prerequisiti IDT
Per eseguire i test tramite l'interfaccia utente AWS IoT Device Tester (IDT) for FreerTOS, è necessario completare i prerequisiti nella [Imposta i prerequisiti di qualificazione LTS](lts-idt-dev-tester-prereqs.md) pagina per IDT FreerTOS Qualification (FRQ) 2.x.
# Configura le AWS credenziali per utilizzare l'interfaccia utente IDT
Devi configurare le credenziali utente IAM per l' AWS utente in [Crea un account AWS](lts-idt-dev-tester-prereqs.md#lts-config-aws-account) cui hai creato. Puoi specificare le credenziali in uno dei due modi seguenti:
+ In un file di credenziali
+ Come variabili di ambiente
## Configura AWS le credenziali con un file di credenziali
IDT usa lo stesso file delle credenziali di AWS CLI. Per ulteriori informazioni, consulta l'argomento relativo ai [file di configurazione e delle credenziali](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html).
La posizione del file delle credenziali varia in base al sistema operativo utilizzato:
+ **macOS e Linux** — `~/.aws/credentials`
+ **Windows** – `C:\Users\UserName\.aws\credentials`
Aggiungi AWS le tue credenziali al `credentials` file nel seguente formato:
```
[default]
aws_access_key_id = your_access_key_id
aws_secret_access_key = your_secret_access_key
```
**Nota**
Se non utilizzi il `default` AWS profilo, devi specificare il nome del profilo nell'interfaccia utente di IDT per FreerTOS. Per ulteriori informazioni sui profili, consulta [Configurazione e impostazioni dei file di credenziali](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html).
## Configura AWS le credenziali con variabili di ambiente
Le variabili di ambiente sono variabili gestite dal sistema operativo e utilizzate dai comandi di sistema. Non vengono salvati se si chiude la sessione SSH. L'interfaccia utente di IDT per FreerTOS utilizza le variabili di ambiente `AWS_SECRET_ACCESS_KEY` e per `AWS_ACCESS_KEY_ID` memorizzare le credenziali. AWS
Per impostare queste variabili su Linux, macOS o Unix, utilizza **export**:
```
export AWS_ACCESS_KEY_ID=your_access_key_id
export AWS_SECRET_ACCESS_KEY=your_secret_access_key
```
Per impostare queste variabili su Windows, utilizza **set**:
```
set AWS_ACCESS_KEY_ID=your_access_key_id
set AWS_SECRET_ACCESS_KEY=your_secret_access_key
```
# Apri l'interfaccia utente di IDT per FreerTOS
Questo argomento spiega come aprire l'interfaccia utente IDT for FreerTOS per utilizzare la suite di qualificazione FreeRTOS.
**Per aprire l'interfaccia utente di IDT per FreerTOS**
1. Scarica una versione IDT per FreerTOS supportata. Quindi estrai l'archivio scaricato in una directory per la quale disponi delle autorizzazioni di lettura e scrittura.
1. Vai alla directory di installazione di IDT for FreerTOS:
```
cd devicetester-extract-location/bin
```
1. Esegui il seguente comando per aprire l'interfaccia utente IDT per FreerTOS:
------
#### [ Linux ]
```
.devicetester_ui_linux_x86-64
```
------
#### [ Windows ]
```
./devicetester_ui_win_x64-64
```
------
#### [ macOS ]
```
./devicetester_ui_mac_x86-64
```
**Nota**
In macOS, per consentire al sistema di eseguire l'interfaccia utente, vai a **Preferenze di sistema -> Sicurezza e privacy**. Quando esegui i test, potrebbe essere necessario farlo altre tre volte. questo
------
L'interfaccia utente di IDT per FreerTOS si apre nel browser predefinito. Le ultime tre versioni principali dei seguenti browser supportano l'interfaccia utente:
+ Google Chrome
+ Mozilla Firefox
+ Microsoft Edge
+ Apple Safari per macOS
**Nota**
Per un'esperienza migliore, consigliamo Google Chrome o Mozilla Firefox per accedere all'interfaccia utente IDT per FreerTOS. Microsoft Internet Explorer non è supportato dall'interfaccia utente.
**Importante**
È necessario configurare le AWS credenziali prima di aprire l'interfaccia utente. Se non hai configurato le tue credenziali, chiudi la finestra del browser dell'interfaccia utente di IDT per FreerTOS, segui i passaggi indicati e poi riapri l'interfaccia utente di IDT per FreerTOS. [Configura le AWS credenziali per utilizzare l'interfaccia utente IDT](lts-configure-aws-credentials.md)
# Crea una nuova configurazione
Se sei un utente alle prime armi, devi creare una nuova configurazione per configurare i file di configurazione JSON richiesti da IDT for FreerTOS per eseguire i test. È quindi possibile eseguire test o modificare la configurazione creata.
Per esempi dei `userdata.json` file, e`config.json`,`device.json`,,,,,,, vedi[Primo test della scheda del microcontrollore](lts-qual-steps.md).
**Per creare una nuova configurazione**
1. **Nell'interfaccia utente di IDT per FreerTOS, apri il menu di navigazione e scegli Crea nuova configurazione.**
![\[Interfaccia Device Tester per FreerTOS con pulsante «Crea nuova configurazione» e informazioni sull'autotest automatico dei microcontrollori.\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/images/gsg-create-configuration.png)
1. Segui la procedura guidata di configurazione per accedere alle impostazioni di configurazione IDT utilizzate per eseguire i test di qualificazione. La procedura guidata configura le seguenti impostazioni nei file di configurazione JSON che si trovano nella directory. `devicetester-extract-location/config`
+ **Impostazioni del dispositivo: le impostazioni** del pool di dispositivi per i dispositivi da testare. Queste impostazioni sono configurate nei `sku` campi `id` and e il blocco dei **dispositivi** per il pool di dispositivi contenuto nel `config.json` file.
![\[Schermata di configurazione di Device Tester for FreerTOS con campi Identifier e SKU per la configurazione di un pool di dispositivi, opzioni di impostazione del dispositivo come metodo di connettività, key provisioning, impostazioni PKCS #11, campi di immissione dei dettagli del dispositivo e controlli per aggiungere dispositivi o identificatori.\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/images/gsg-device-settings.png)
+ **AWS impostazioni dell'account** — Le Account AWS informazioni che IDT for FreerTOS utilizza per AWS creare risorse durante le esecuzioni dei test. Queste impostazioni sono configurate nel file. `config.json`
![\[Account AWS pagina delle impostazioni con campi per la regione dell'account, la posizione delle credenziali come file o ambiente e il nome del profilo\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/images/gsg-account-settings.png)
+ Implementazione **FreerTOS**: il percorso assoluto verso il repository FreerTOS e il codice portato e la versione di FreeRTOS su cui vuoi eseguire IDT FRQ. I percorsi dei file di intestazione di esecuzione e configurazione dei parametri dal repository. `FreeRTOS-Libraries-Integration-Tests` GitHub I comandi build e flash per l'hardware che consentono a IDT di creare ed eseguire test sulla scheda in modo automatico. Queste impostazioni sono configurate nel `userdata.json` file.
![\[Sezione di configurazione dell'implementazione di FreerTOS con percorsi di repository, percorsi di esecuzione dei test, versione di FreeRTOS, dettagli dello strumento di compilazione e impostazioni dello strumento flash.\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/images/gsg-implementation-settings.png)
+ Etichette **PKCS \$111 e server Echo: le etichette** [PKCS \$111](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-pkcs.html) che corrispondono alle chiavi fornite nell'hardware in base alla funzionalità delle chiavi e al metodo di fornitura delle chiavi. Le impostazioni di configurazione del server echo per i test dell'interfaccia di trasporto. Queste impostazioni sono configurate nei `device.json` file `userdata.json` and.
![\[Etichette PKCS #11 e configurazioni del server Echo con campi di input per le etichette delle chiavi, il metodo di generazione delle chiavi e il numero di porta del server\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/images/gsg-pkcs11-settings.png)
+ **Over-the-air Aggiornamenti (OTA)**: le impostazioni che controllano i test di funzionalità OTA. Queste impostazioni sono configurate nel `features` blocco dei `userdata.json` file `device.json` and.
![\[Opzioni di configurazione dell'aggiornamento OTA: skip test, protocolli dati, percorsi firmware, percorso certificato PAL, firma del codice, hash/sign algoritmi, certificati firmatari, file di certificato trusted/untrusted firmatario, compilazione del certificato firmatario, piattaforma firmatario.\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/images/gsg-ota-settings.png)
1. Nella pagina di revisione, verifica le informazioni di **configurazione**.
![\[Finestra di dialogo di configurazione creata per Device Tester for FreerTOS, che mostra i dettagli sulla creazione di una nuova configurazione di test con opzioni per modificare o eseguire test.\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/images/gsg-configuration-created.png)
**Dopo aver terminato la revisione della configurazione, per eseguire i test di qualificazione, scegli Esegui test.**
# Modifica una configurazione esistente
Se hai già configurato i file di configurazione per IDT per FreerTOS, puoi usare l'interfaccia utente IDT for FreerTOS per modificare la configurazione esistente. I file di configurazione esistenti devono trovarsi nella directory. `devicetester-extract-location/config`
**Per modificare una configurazione**
1. **Nell'interfaccia utente di IDT per FreerTOS, apri il menu di navigazione e scegli Modifica configurazione esistente.**
La dashboard di configurazione mostra informazioni sulle impostazioni di configurazione esistenti. Se una configurazione è errata o non disponibile, lo stato di tale configurazione è`Error validating configuration`.
![\[Schermata di configurazione con le sezioni relative al dispositivo Account AWS, all'implementazione di FreerTOS, alle etichette PKCS e al server echo over-the-air, agli aggiornamenti e alle impostazioni di esecuzione del test che mostrano lo stato valido.\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/images/modify-existing-configuration.png)
1. Per modificare un'impostazione di configurazione esistente, completa i seguenti passaggi:
1. Scegli il nome di un'impostazione di configurazione per aprire la relativa pagina delle impostazioni.
1. Modifica le impostazioni, quindi scegli **Salva** per rigenerare il file di configurazione corrispondente.
1. Per modificare le impostazioni di esecuzione del test IDT per FreerTOS, **scegli le impostazioni di esecuzione del test IDT nella vista di** modifica:
![\[Finestra di dialogo delle impostazioni di esecuzione del test IDT con opzioni per la selezione del test, il salto dei gruppi di test, il moltiplicatore di timeout e l'interruzione al primo errore.\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/images/idt-testrun-settings.png)
Dopo aver modificato la configurazione, verifica che tutte le impostazioni di configurazione superino la convalida. Se lo stato di ogni impostazione di configurazione è`Valid`, puoi eseguire i test di qualificazione con questa configurazione.
# Esegui test di qualificazione
Dopo aver creato una configurazione per l'interfaccia utente IDT per FreerTOS, puoi eseguire i test di qualificazione.
**Per eseguire test di qualificazione**
1. Nel menu di navigazione, scegli **Esegui test**.
1. Scegli **Avvia test** per iniziare l'esecuzione del test. Per impostazione predefinita, vengono eseguiti tutti i test applicabili per la configurazione del dispositivo. IDT for FreerTOS genera un rapporto di qualificazione al termine di tutti i test.
![\[L'interfaccia Device Tester per FreerTOS non mostra ancora alcun test eseguito, con opzioni per creare una nuova configurazione, modificare la configurazione esistente ed eseguire test.\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/images/idt-run-tests.png)
IDT for FreerTOS esegue i test di qualificazione. **Visualizza quindi il riepilogo dei test eseguiti e gli eventuali errori nella console Test runner.** Al termine dell'esecuzione del test, è possibile visualizzare i risultati e i registri del test dalle seguenti posizioni:
+ I risultati dei test si trovano nella `devicetester-extract-location/results/execution-id` directory.
+ I registri dei test si trovano nella `devicetester-extract-location/results/execution-id/logs` directory.
Per ulteriori informazioni sui risultati e sui registri dei test, vedere [Visualizza l'IDT gratuitamente RTOSresults](view-results-lts.md) e. [Visualizza l'IDT gratuitamente RTOSlogs](view-logs-lts.md)
![\[Registro di esecuzione di Device Tester for FreerTOS che mostra i test superati, i gruppi di test e i percorsi dei file per log e report.\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/images/idt-results.png)
# Esegui la suite di qualificazione FreerTOS 2.0
Usa l'eseguibile AWS IoT Device Tester for FreerTOS per interagire con IDT for FreerTOS. Gli esempi della riga di comando seguenti illustrano come eseguire i test di qualifica per un pool di dispositivi (serie di dispositivi identici).
------
#### [ 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
```
Esegue una suite di test in un determinato pool di dispositivi. Il file `userdata.json` si deve trovare nella directory `devicetester_extract_location/devicetester_freertos_[win|mac|linux]/configs/`.
**Nota**
Se stai usando IDT for FreerTOS su Windows, usa le barre (/) per specificare il percorso del file. `userdata.json`
Utilizza il comando seguente per eseguire un gruppo di test specifico:
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1.99.0 \
--group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
I parametri `suite-id` e `pool-id` sono facoltativi se esegui una singola suite di test su un singolo pool di dispositivi (ovvero nel tuo file `device.json` c'è un solo pool di dispositivi definito).
Utilizza il comando seguente per eseguire un caso di test specifico in un gruppo di test:
```
devicetester_[linux | mac | win_x86-64] run-suite \
--group-id group-id \
--test-id test-id
```
Puoi utilizzare il comando `list-test-cases` per elencare i casi di test in un gruppo di test.
**IDT per le opzioni della riga di comando di FreerTOS**
**group-id**
(Facoltativo) I gruppi di test da eseguire, come elenco con valori separati da virgole. Se non specificato, IDT esegue tutti i gruppi di test nella suite di test.
**pool-id**
(Facoltativo) Il pool di dispositivi da testare. Questo è necessario se si definiscono più pool di dispositivi in `device.json`. Se hai un solo pool di dispositivi, questa opzione può essere omessa.
**suite-id**
(Facoltativo) Versione della suite di test da eseguire. Se non specificato, IDT utilizza la versione più recente nella directory dei test del sistema.
**test-id**
(Facoltativo) I test da eseguire, come elenco con valori separati da virgole. Se specificato, `group-id` deve includere un singolo gruppo.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id FreeRTOSVersion --test-id FreeRTOSVersion
```
**h**
Utilizza l'opzione di aiuto per ulteriori informazioni sulle opzioni `run-suite`.
**Example**
**Esempio**
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
------
## Comandi IDT per FreerTOS
Il comando IDT for FreerTOS supporta le seguenti operazioni:
------
#### [ IDT v4.5.2 and later ]
** `help` **
Elenca le informazioni sul comando specificato.
** `list-groups` **
Elenca i gruppi in una determinata suite.
** `list-suites` **
Elenca le suite disponibili.
** `list-supported-products` **
Elenca i prodotti e le versioni della suite di test supportati.
** `list-supported-versions` **
Elenca le versioni di FreerTOS e della suite di test supportate dalla versione IDT corrente.
** `list-test-cases` **
Elenca i casi di test in un gruppo specificato.
** `run-suite` **
Esegue una suite di test in un determinato pool di dispositivi.
Utilizza l'opzione `--suite-id` per specificare una versione della suite di test oppure omettila per utilizzare la versione più recente nel sistema.
Utilizza `--test-id` per eseguire un singolo caso di test.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id FreeRTOSVersion --test-id FreeRTOSVersion
```
A partire da IDT v3.0.0, IDT controlla online le suite di test più recenti. Per ulteriori informazioni, consulta [Versioni della suite di test](idt-test-suite-versions.md).
------
# Visualizza l'IDT gratuitamente RTOSresults
Durante l'esecuzione, IDT scrive gli errori nella console, i file di log e i report di test. Al termine della suite di test di qualifica, IDT scrive un riepilogo dell'esecuzione dei test nella console e genera due report di test. Questi report sono disponibili in `devicetester-extract-location/results/execution-id/`. Entrambi i report acquisiscono i risultati dall'esecuzione della suite di test di qualifica.
`awsiotdevicetester_report.xml`È il rapporto del test di qualificazione che invii AWS per inserire il tuo dispositivo nel AWS Partner Device Catalog. Il report contiene i seguenti elementi:
+ La versione IDT per FreerTOS.
+ La versione di FreerTOS che è stata testata.
+ Le funzionalità di FreerTOS supportate dal dispositivo in base ai test superati.
+ Il codice SKU e il nome del dispositivo specificato nel file `device.json`.
+ Le caratteristiche del dispositivo specificato nel file `device.json`.
+ Il riepilogo aggregato dei risultati dei casi di test.
+ Un'analisi dei risultati dei casi di test suddivisi per le librerie sottoposte a test in base alle caratteristiche del dispositivo.
`FRQ_Report.xml`Si tratta di un report in [JUnit formato XML](https://llg.cubic.org/docs/junit/) standard. Puoi integrarlo in CI/CD piattaforme come [Jenkins](https://jenkins.io/), [Bamboo](https://www.atlassian.com/software/bamboo) e così via. Il report contiene i seguenti elementi:
+ Un riepilogo aggregato dei risultati dei casi di test.
+ Un'analisi dei risultati dei casi di test suddivisi per le librerie sottoposte a test in base alle caratteristiche del dispositivo.
# Interpreta i risultati di IDT for FreerTOS
La sezione dei report in `awsiotdevicetester_report.xml` o `FRQ_Report.xml` elenca i risultati dei test eseguiti.
Il primo tag XML `` contiene il riepilogo complessivo dell'esecuzione dei test. Esempio:
``
**Attributi utilizzati nel `` tag**
** `name` **
Il nome della suite di test.
** `time` **
Il tempo, espresso in secondi, impiegato per eseguire la suite di qualifica.
** `tests` **
Il numero dei casi di test eseguiti.
** `failures` **
Il numero dei casi di test eseguiti ma non superati.
** `errors` **
Il numero di casi di test che IDT for FreerTOS non è riuscito a eseguire.
** `disabled` **
Questo attributo non è utilizzato e si può ignorare.
Se non ci sono guasti o errori nel test case, il tuo dispositivo soddisfa i requisiti tecnici per eseguire FreerTOS e può interagire con i servizi. AWS IoT Se scegli di inserire il tuo dispositivo nel AWS Partner Device Catalog, puoi utilizzare questo rapporto come prova di idoneità.
In caso di esiti negativi o errori nei casi di test, puoi identificare il caso di test non riuscito esaminando i tag XML ``. I tag XML `` all'interno del tag `` mostrano il riepilogo dei risultati dei casi di test per un gruppo di test.
``
Il formato è simile al tag ``, ma con un attributo denominato `skipped` che non viene utilizzato e si può ignorare. All'interno di ogni tag XML `` ci sono tag `` per ciascuno dei casi di test eseguiti per un gruppo di test. Esempio:
``
**Attributi utilizzati nel tag ``**
** `name` **
Il nome del prodotto sottoposto a test.
** `version` **
La versione del prodotto sottoposto a test.
** `features` **
Le caratteristiche convalidate. Le caratteristiche contrassegnate come `required` sono necessarie per inviare la scheda per la qualifica. Il seguente frammento mostra come appare nel `awsiotdevicetester_report.xml` file.
```
```
Caratteristiche contrassegnate come `optional` non sono necessarie per la qualifica. I seguenti snippet mostrano caratteristiche facoltative.
```
```
Se non si verificano errori o errori nei test per le funzionalità richieste, il dispositivo soddisfa i requisiti tecnici per eseguire FreerTOS e può interagire con i servizi. AWS IoT Se desideri inserire il tuo dispositivo nel [AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices), puoi utilizzare questo rapporto come prova di idoneità.
In caso di esiti negativi o errori nei test, puoi identificare il test non riuscito esaminando i tag XML ``. I tag XML `` all'interno del tag `` mostrano il riepilogo dei risultati dei test per un gruppo di test. Esempio:
```
```
Il formato è simile al `` tag, ma ha un `skipped` attributo che non viene utilizzato e può essere ignorato. All'interno di ogni tag XML `` ci sono tag `` per ciascuno dei test eseguiti per un gruppo di test. Esempio:
```
```
**Attributi utilizzati nel tag ``**
** `name` **
Il nome del caso di test.
** `attempts` **
Il numero di volte in cui IDT per FreerTOS ha eseguito il test case.
Quando un test non riesce o si verifica un errore, i tag `` o `` vengono aggiunti al tag `` con informazioni per la risoluzione dei problemi. Esempio:
```
Reason for the test case failure
Reason for the test case execution error
```
Per ulteriori informazioni, consulta [Risoluzione degli errori](dt-afr-troubleshooting.md).
# Visualizza l'IDT gratuitamente RTOSlogs
Puoi trovare i log che IDT for FreerTOS genera dall'esecuzione del test in. `devicetester-extract-location/results/execution-id/logs` Vengono generate due serie di log:
+ `test_manager.log`
Contiene i log generati da IDT per FreerTOS (ad esempio, la configurazione relativa ai log e la generazione di report).
+ `test_group_id/test_case_id/test_case_id.log`
Il file di log per un caso di test, incluso l'output dal dispositivo sottoposto a test. Il file di log viene denominato in base al gruppo di test e al caso di test che è stato eseguito.
# IDT con suite di qualificazione FreerTOS 1.0 (FRQ 1.0)
**Importante**
A ottobre 2022, AWS IoT Device Tester per AWS IoT FreerTOS Qualification (FRQ) 1.0 non genera report di qualificazione firmati. Non è possibile qualificare nuovi dispositivi AWS IoT FreerTOS da inserire nel [Partner Device Catalog tramite AWS il Device](https://partners.amazonaws.com/qualified-devices) [Qualification Program utilizzando AWS le versioni](https://aws.amazon.com/partners/programs/dqp/) IDT FRQ 1.0. Sebbene non sia possibile qualificare i dispositivi FreerTOS utilizzando IDT FRQ 1.0, è possibile continuare a testare i dispositivi FreerTOS con FRQ 1.0. [Ti consigliamo di utilizzare [IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) per qualificare ed elencare i dispositivi FreerTOS nel Partner Device Catalog.AWS](https://partners.amazonaws.com/qualified-devices)
Puoi utilizzare la qualificazione IDT for FreerTOS per verificare che il sistema operativo FreeRTOS funzioni localmente sul tuo dispositivo e con cui possa comunicare. AWS IoT In particolare, verifica che le interfacce del livello di porting per le librerie FreerTOS siano implementate correttamente. Esegue anche test con. end-to-end AWS IoT Core Ad esempio, verifica che la scheda sia in grado di inviare e ricevere messaggi MQTT ed elaborarli correttamente. [I test eseguiti da IDT per FreerTOS sono definiti nel repository FreerTOS. GitHub ](https://github.com/aws/amazon-freertos)
I test vengono eseguiti come applicazioni incorporate di cui viene eseguito il flashing nella scheda. Le immagini binarie dell'applicazione includono FreeRTOS, le interfacce FreeRTOS con porting del fornitore di semiconduttori e i driver dei dispositivi di scheda. Lo scopo dei test è verificare che le interfacce FreerTOS portate funzionino correttamente sui driver del dispositivo.
IDT for FreerTOS genera report di test che puoi inviare AWS IoT per aggiungere il tuo hardware al AWS Partner Device Catalog. Per ulteriori informazioni, consulta [AWS Device Qualification Program](https://aws.amazon.com/partners/dqp/).
IDT per FreerTOS funziona su un computer host (Windows, macOS o Linux) collegato alla scheda da testare. IDT esegue i casi di test e aggrega i risultati. Inoltre offre un'interfaccia a riga di comando per gestire l'esecuzione dei test.
Oltre ai dispositivi di test, IDT for FreeRTOS crea risorse (ad esempio AWS IoT oggetti, gruppi FreeRTOS, funzioni Lambda e così via) per facilitare il processo di qualificazione. Per creare queste risorse, IDT for FreerTOS utilizza AWS le credenziali configurate in per effettuare chiamate API per `config.json` tuo conto. Il provisioning di queste risorse viene effettuato varie volte nel corso di un test.
Quando esegui IDT for FreerTOS sul tuo computer host, esegue i seguenti passaggi:
1. Carica e convalida la configurazione del dispositivo e delle credenziali.
1. Esegue i test selezionati con le risorse locali e cloud richieste.
1. Esegue la pulizia di risorse locali e cloud.
1. Genera i report di test che indicano se la scheda ha superato i test richiesti per la qualifica.
**Topics**
+ [Imposta i prerequisiti di qualificazione 1.0](dev-tester-prereqs.md)
+ [Primo test della scheda del microcontrollore](qual-steps.md)
+ [Usa l'interfaccia utente IDT per eseguire la suite di qualificazione FreerTOS](device-tester-ui.md)
+ [Esegui i test Bluetooth Low Energy](afr-bridgekeeper-dt-bt.md)
+ [Esegui la suite di qualificazione FreerTOS](run-tests.md)
+ [Visualizza i risultati di IDT for FreerTOS](view-results-frq.md)
+ [Interpreta i risultati di IDT for FreerTOS](interpreting-results-frq.md)
+ [Visualizza i log di IDT for FreerTOS](view-logs-frq.md)
# Imposta i prerequisiti di qualificazione 1.0
Questa sezione descrive i prerequisiti per testare i microcontrollori con. AWS IoT Device Tester
## Scarica FreerTOS
Puoi scaricare una versione di FreerTOS [GitHub](https://github.com/aws/amazon-freertos)da con il seguente comando:
```
git clone --branch --recurse-submodules https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
dove è una versione di FreeRTOS (ad esempio, 202007.00) corrispondente a una versione IDT elencata in. [Versioni supportate di AWS IoT Device Tester](dev-test-versions-afr.md) Questo ti assicura di avere il codice sorgente completo, compresi i sottomoduli, e di utilizzare la versione corretta di IDT per la tua versione di FreerTOS e viceversa.
In Windows esiste un limite di lunghezza del percorso di 260 caratteri. La struttura dei percorsi di FreerTOS è profonda a molti livelli, quindi se usi Windows, mantieni i percorsi dei file al di sotto del limite di 260 caratteri. Ad esempio, clona FreerTOS su invece `C:\FreeRTOS` di. `C:\Users\username\programs\projects\myproj\FreeRTOS\`
### Qualificazione FreerTOS con librerie LTS
+ Affinché il tuo microcontrollore sia designato per supportare le versioni di FreeRTOS basate sul supporto a lungo termine (LTS) nel AWS Partner Device Catalog, devi fornire un file manifest. *Per ulteriori informazioni, consulta la [Checklist per la qualificazione di FreerTOS nella FreerTOS Qualification Guide](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist.html).*
+ Per verificare che il microcontrollore supporti le versioni basate su LTS di FreeRTOS e qualificarlo per l'invio al AWS Partner Device Catalog, è necessario utilizzare ( AWS IoT Device Tester IDT) con la suite di test FreerTOS Qualification (FRQ) v1.4.x.
+ Il supporto per le versioni basate su LTS di FreerTOS è limitato alla versione 202012.xx di FreerTOS.
## Scarica IDT per FreerTOS
Ogni versione di FreerTOS ha una versione corrispondente di IDT per FreerTOS per eseguire test di qualificazione. Scarica la versione appropriata di IDT per FreerTOS da. [Versioni supportate di AWS IoT Device Tester](dev-test-versions-afr.md)
Estrai IDT for FreerTOS in una posizione del file system in cui disponi dei permessi di lettura e scrittura. Poiché Microsoft Windows ha un limite di caratteri per la lunghezza del percorso, estrai IDT per FreerTOS in una directory principale come o. `C:\` `D:\`
**Nota**
Non è consigliabile che più utenti eseguano IDT da un percorso condiviso, ad esempio una directory NFS o una cartella condivisa di rete Windows. Questo comportamento potrebbe causare arresti anomali o il danneggiamento dei dati. Si consiglia di estrarre il pacchetto IDT in un'unità locale.
## Crea e configura un account AWS
### Iscriviti per un Account AWS
Se non ne hai uno Account AWS, completa i seguenti passaggi per crearne uno.
**Per iscriverti a un Account AWS**
1. Apri la [https://portal.aws.amazon.com/billing/registrazione.](https://portal.aws.amazon.com/billing/signup)
1. Segui le istruzioni online.
Nel corso della procedura di registrazione riceverai una telefonata o un messaggio di testo e ti verrà chiesto di inserire un codice di verifica attraverso la tastiera del telefono.
Quando ti iscrivi a un Account AWS, *Utente root dell'account AWS*viene creato un. L’utente root dispone dell’accesso a tutte le risorse e tutti i Servizi AWS nell’account. Come best practice di sicurezza, assegna l’accesso amministrativo a un utente e utilizza solo l’utente root per eseguire [attività che richiedono l’accesso di un utente root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).
AWS ti invia un'email di conferma dopo il completamento della procedura di registrazione. In qualsiasi momento, puoi visualizzare l'attività corrente del tuo account e gestirlo accedendo a [https://aws.amazon.com/](https://aws.amazon.com/)e scegliendo **Il mio account**.
### Crea un utente con accesso amministrativo
Dopo esserti registrato Account AWS, proteggi Utente root dell'account AWS AWS IAM Identity Center, abilita e crea un utente amministrativo in modo da non utilizzare l'utente root per le attività quotidiane.
**Proteggi i tuoi Utente root dell'account AWS**
1. Accedi [Console di gestione AWS](https://console.aws.amazon.com/)come proprietario dell'account scegliendo **Utente root** e inserendo il tuo indirizzo Account AWS email. Nella pagina successiva, inserisci la password.
Per informazioni sull’accesso utilizzando un utente root, consulta la pagina [Accedere come utente root](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) nella *Guida per l’utente di Accedi ad AWS *.
1. Abilita l’autenticazione a più fattori (MFA) per l’utente root.
Per istruzioni, consulta [Abilitare un dispositivo MFA virtuale per l'utente Account AWS root (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) nella Guida per l'*utente IAM*.
**Crea un utente con accesso amministrativo**
1. Abilita il Centro identità IAM.
Per istruzioni, consulta [Abilitazione del AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) nella *Guida per l’utente di AWS IAM Identity Center *.
1. Nel Centro identità IAM, assegna l’accesso amministrativo a un utente.
Per un tutorial sull'utilizzo di IAM Identity Center directory come fonte di identità, consulta [Configurare l'accesso utente con l'impostazione predefinita IAM Identity Center directory](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) nella *Guida per l'AWS IAM Identity Center utente*.
**Accesso come utente amministratore**
+ Per accedere come utente del Centro identità IAM, utilizza l’URL di accesso che è stato inviato al tuo indirizzo e-mail quando hai creato l’utente del Centro identità IAM.
Per informazioni sull'accesso utilizzando un utente IAM Identity Center, consulta [AWS Accedere al portale di accesso](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) nella *Guida per l'Accedi ad AWS utente*.
**Assegnazione dell’accesso ad altri utenti**
1. Nel Centro identità IAM, crea un set di autorizzazioni conforme alla best practice per l’applicazione di autorizzazioni con il privilegio minimo.
Segui le istruzioni riportate nella pagina [Creazione di un set di autorizzazioni](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) nella *Guida per l’utente di AWS IAM Identity Center *.
1. Assegna al gruppo prima gli utenti e poi l’accesso con autenticazione unica (Single Sign-On).
Per istruzioni, consulta [Aggiungere gruppi](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) nella *Guida per l’utente di AWS IAM Identity Center *.
## AWS IoT Device Tester politica gestita
La policy `AWSIoTDeviceTesterForFreeRTOSFullAccess` gestita contiene le seguenti AWS IoT Device Tester autorizzazioni per il controllo della versione, le funzionalità di aggiornamento automatico e la raccolta di metriche.
+ `iot-device-tester:SupportedVersion`
Concede AWS IoT Device Tester l'autorizzazione a recuperare l'elenco dei prodotti supportati, delle suite di test e delle versioni IDT.
+ `iot-device-tester:LatestIdt`
Concede AWS IoT Device Tester l'autorizzazione a recuperare l'ultima versione IDT disponibile per il download.
+ `iot-device-tester:CheckVersion`
Concede AWS IoT Device Tester l'autorizzazione a verificare la compatibilità delle versioni per IDT, suite di test e prodotti.
+ `iot-device-tester:DownloadTestSuite`
Concede AWS IoT Device Tester l'autorizzazione a scaricare gli aggiornamenti della suite di test.
+ `iot-device-tester:SendMetrics`
Concede AWS l'autorizzazione a raccogliere metriche sull' AWS IoT Device Tester utilizzo interno.
## (Facoltativo) Installa il AWS Command Line Interface
Potresti preferire utilizzare il AWS CLI per eseguire alcune operazioni. Se non lo hai AWS CLI installato, segui le istruzioni in [Installare il AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html).
Configuralo AWS CLI per la AWS regione che desideri utilizzare eseguendolo **aws configure** da una riga di comando. [Per informazioni sulle AWS regioni che supportano IDT for FreerTOS,AWS consulta Regioni ed endpoint.](https://docs.aws.amazon.com/general/latest/gr/rande.html#amazon-freertos-ota-control) [Per ulteriori informazioni, **aws configure** vedere Configurazione rapida con. **aws configure**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)
# Primo test della scheda del microcontrollore
Puoi usare IDT for FreeRTOS per eseguire il test durante il porting delle interfacce FreeRTOS. Dopo aver effettuato il porting delle interfacce FreerTOS per i driver di dispositivo della scheda, si AWS IoT Device Tester eseguono i test di qualificazione sulla scheda del microcontrollore.
## Aggiunta di livelli di porting delle librerie
Per portare FreerTOS sul tuo dispositivo, segui le istruzioni nella [FreerTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/) Porting Guide.
## AWS Configura le tue credenziali
Devi configurare AWS le tue credenziali AWS IoT Device Tester per comunicare con il AWS Cloud. Per ulteriori informazioni, consulta [Configurare AWS le credenziali e la regione per](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html) lo sviluppo. AWS Le credenziali valide devono essere specificate nel `devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/config.json` file di configurazione.
**Topics**
+ [Aggiunta di livelli di porting delle librerie](#add-port-layer)
+ [AWS Configura le tue credenziali](#cfg-aws-afr)
+ [Crea un pool di dispositivi in IDT per FreerTOS](cfg-dt-dp.md)
+ [Configurazione delle impostazioni di compilazione, flashing e test](cfg-dt-ud.md)
# Crea un pool di dispositivi in IDT per FreerTOS
I dispositivi da testare sono organizzati in pool di dispositivi. Ogni pool di dispositivi è composto da uno o più dispositivi identici. Puoi configurare IDT per FreerTOS per testare un singolo dispositivo in un pool o più dispositivi in un pool. Per accelerare il processo di qualificazione, IDT for FreerTOS può testare dispositivi con le stesse specifiche in parallelo. Lo strumento utilizza un metodo Round Robin per eseguire un gruppo di test differente su ciascun dispositivo di un pool.
È possibile aggiungere uno o più dispositivi a un pool di dispositivi modificando la sezione `devices` del modello `device.json` nella cartella `configs`.
**Nota**
La specifica tecnica e il codice SKU dei dispositivi in uno stesso pool devono essere identici.
Per abilitare le build parallele del codice sorgente per diversi gruppi di test, IDT for FreerTOS copia il codice sorgente in una cartella dei risultati all'interno della cartella estratta IDT for FreerTOS. Il percorso del codice sorgente nel comando build o flash deve essere referenziato utilizzando la variabile or. `testdata.sourcePath` `sdkPath` IDT for FreerTOS sostituisce questa variabile con un percorso temporaneo del codice sorgente copiato. Per ulteriori informazioni, consultare [IDT per variabili FreerTOS](dt-vars.md).
Di seguito è riportato un esempio di file `device.json` utilizzato per creare un pool di dispositivi con più dispositivi.
```
[
{
"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"
}
]
}
]
}
]
```
I seguenti attributi vengono utilizzati nel file `device.json`:
**`id`**
Un ID alfanumerico definito dall'utente che identifica in modo univoco un pool di dispositivi. I dispositivi appartenenti a un pool devono essere dello stesso tipo. Durante l'esecuzione di una suite di test, i dispositivi del pool vengono utilizzati per parallelizzare il carico di lavoro.
**`sku`**
Un valore alfanumerico che identifica in modo univoco la scheda da testare. Il codice SKU viene utilizzato per tenere traccia delle schede qualificate.
Se desideri inserire la tua scheda nel AWS Partner Device Catalog, lo SKU che specifichi qui deve corrispondere allo SKU utilizzato nel processo di pubblicazione.
**`features`**
Un array che contiene le funzionalità supportate dal dispositivo. AWS IoT Device Tester utilizza queste informazioni per selezionare i test di qualificazione da eseguire.
I valori supportati sono:
**`TCP/IP`**
Indica se la scheda supporta uno TCP/IP stack e se è supportata su chip (MCU) o trasferita su un altro modulo. TCP/IP è necessario per la qualificazione.
**`WIFI`**
Indica se la scheda dispone di funzionalità Wi-Fi. Deve essere impostato su `No` se `Cellular` è impostato su. `Yes`
**`Cellular`**
Indica se la scheda è dotata di funzionalità di rete cellulare. Deve essere impostato su `No` se `WIFI` è impostato su`Yes`. Quando questa funzionalità è impostata su`Yes`, il FullSecureSockets test verrà eseguito utilizzando istanze AWS t2.micro EC2 e ciò potrebbe comportare costi aggiuntivi per l'account. Per ulteriori informazioni, consulta [Prezzi di Amazon EC2](https://aws.amazon.com/ec2/pricing/).
**`TLS`**
Indica se la scheda supporta TLS. TLS è obbligatorio per la qualifica.
**`PKCS11`**
Indica l'algoritmo di crittografia a chiave pubblica supportato dalla scheda. PKCS11 è necessario per la qualificazione. I valori supportati sono `ECC`, `RSA`, `Both` e `No`. `Both` indica che la scheda supporta sia gli algoritmi `ECC` e `RSA`.
**`KeyProvisioning`**
Indica il metodo di scrittura di un certificato client X.509 attendibile sulla scheda. I valori validi sono `Import`, `Onboard` e `No`. Per la qualifica è necessario il provisioning delle chiavi.
+ Utilizzare `Import` se la scheda consente l'importazione di chiavi private. IDT creerà una chiave privata e la inserirà nel codice sorgente di FreerTOS.
+ Utilizzare `Onboard` se la scheda supporta la generazione di chiavi private integrate (ad esempio, se il dispositivo ha un elemento protetto o se si preferisce generare la coppia di chiavi del dispositivo e il certificato). Assicurarsi di aggiungere un elemento `secureElementConfig` in ciascuna delle sezioni del dispositivo e inserire il percorso assoluto del file della chiave pubblica nel campo `publicKeyAsciiHexFilePath`.
+ Utilizzare `No` se la scheda non supporta il provisioning delle chiavi.
**`OTA`**
Indica se la scheda supporta la funzionalità di over-the-air aggiornamento (OTA). L'attributo `OtaDataPlaneProtocol` indica quale protocollo di piano dei dati OTA supporta il dispositivo. L'attributo viene ignorato se la caratteristica OTA non è supportata dal dispositivo. Quando è selezionato `"Both"`, il tempo di esecuzione del test OTA viene prolungato a causa dell'esecuzione di MQTT, HTTP e test misti.
A partire da IDT v4.1.0, `OtaDataPlaneProtocol` accetta solo `HTTP` e `MQTT` come valori supportati.
**`BLE`**
Indica se la scheda supporta Bluetooth Low Energy (BLE).
**`devices.id`**
Un identificativo univoco definito dall'utente del dispositivo sottoposto a test.
**`devices.connectivity.protocol`**
Il protocollo di comunicazione utilizzato per comunicare con questo dispositivo. Valore supportato: `uart`.
**`devices.connectivity.serialPort`**
La porta seriale del computer host utilizzato per connettersi ai dispositivi da testare.
**`devices.secureElementConfig.PublicKeyAsciiHexFilePath`**
Il percorso assoluto del file che contiene la chiave pubblica in byte esadecimali estratta dalla chiave privata integrata.
Formato di esempio:
```
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 la tua chiave pubblica è in formato.der, puoi codificare direttamente in esadecimale la chiave pubblica per generare il file esadecimale.
Comando di esempio per la chiave pubblica.der per generare un file esadecimale:
```
xxd -p pubkey.der > outFile
```
Se la chiave pubblica è in formato.pem, puoi estrarre la parte codificata in base64, decodificarla in formato binario e quindi codificarla in esadecimale per generare il file esadecimale.
Ad esempio, utilizzate questi comandi per generare un file esadecimale per una chiave pubblica.pem:
1. Estrai la parte codificata in base64 della chiave (elimina l'intestazione e il piè di pagina) e memorizzala in un file, ad esempio assegnagli un nome`base64key`, esegui questo comando per convertirla in formato.der:
```
base64 —decode base64key > pubkey.der
```
1. Esegui il `xxd` comando per convertirlo in formato esadecimale.
```
xxd -p pubkey.der > outFile
```
**`devices.secureElementConfig.SecureElementSerialNumber`**
(Facoltativo) Il numero di serie dell'elemento sicuro. Fornisci questo campo quando il numero di serie viene stampato insieme alla chiave pubblica del dispositivo quando esegui il progetto FreerTOS demo/test .
**`devices.secureElementConfig.preProvisioned`**
(Facoltativo) Imposta su «Sì» se il dispositivo dispone di un elemento sicuro prestabilito con credenziali bloccate, che non può importare, creare o distruggere oggetti. Questa configurazione `features` ha effetto solo se è `KeyProvisioning` impostata su «Onboard», insieme a «ECC». `PKCS11`
**`identifiers`**
(Facoltativo) Un array di coppie nome/valore arbitrarie. Puoi utilizzare questi valori nei comandi di compilazione e flashing descritti nella sezione successiva.
# Configurazione delle impostazioni di compilazione, flashing e test
Affinché IDT for FreerTOS possa creare ed eseguire test flash sulla scheda automaticamente, è necessario configurare IDT per eseguire i comandi build e flash per il proprio hardware. Le impostazioni dei comandi di compilazione e flashing sono configurate nel file di modello `userdata.json` che si trova nella cartella `config`.
# Configurazione delle impostazioni per il testing dei dispositivi
Le impostazioni di compilazione, flashing e test vengono eseguite nel file `configs/userdata.json`. Supportiamo la configurazione di Echo Server caricando i certificati e le chiavi del client e del `customPath` server in. Per ulteriori informazioni, consulta [Configurazione di un server echo](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html) nella *FreerTOS* Porting Guide. Il seguente esempio JSON mostra come configurare IDT per FreerTOS per testare più dispositivi:
```
{
"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"
}
]
}
}
```
Il seguente elenca gli attributi utilizzati in `userdata.json`:
**`sourcePath`**
Il percorso alla radice del codice sorgente di FreerTOS portato. Per i test paralleli con un SDK, è `sourcePath` possibile impostarlo utilizzando il `{{userData.sdkConfiguration.path}}` segnaposto. Esempio:
```
{ "sourcePath":"{{userData.sdkConfiguration.path}}/freertos" }
```
**`vendorPath`**
Il percorso verso il codice FreerTOS specifico del fornitore. Per i test seriali, `vendorPath` può essere impostato come un percorso assoluto. Esempio:
```
{ "vendorPath":"C:/path-to-freertos/vendors/espressif/boards/esp32" }
```
Per test paralleli, `vendorPath` può essere impostato utilizzando il segnaposto `{{testData.sourcePath}}`. Esempio:
```
{ "vendorPath":"{{testData.sourcePath}}/vendors/espressif/boards/esp32" }
```
La `vendorPath` variabile è necessaria solo quando viene eseguita senza un SDK, altrimenti può essere rimossa.
Quando si eseguono test in parallelo senza un SDK, il `{{testData.sourcePath}}` segnaposto deve essere utilizzato nei campi`vendorPath`,,`buildTool`. `flashTool` Quando si esegue il test con un singolo dispositivo, i percorsi assoluti devono essere utilizzati nei campi `vendorPath`, `buildTool`, `flashTool`. Quando si esegue con un SDK, il `{{sdkPath}}` segnaposto deve essere utilizzato nei comandi, e. `sourcePath` `buildTool` `flashTool`
**`sdkConfiguration`**
Se stai qualificando FreerTOS con modifiche alla struttura di file e cartelle oltre a quelle richieste per il porting, dovrai configurare le informazioni del tuo SDK in questo blocco. Se non ti qualifichi con un FreerTOS portato all'interno di un SDK, allora dovresti omettere completamente questo blocco.
**`sdkConfiguration.name`**
Il nome dell'SDK che stai usando con FreerTOS. Se non stai usando un SDK, allora l'intero `sdkConfiguration` blocco dovrebbe essere omesso.
**`sdkConfiguration.version`**
La versione dell'SDK che stai usando con FreerTOS. Se non stai utilizzando un SDK, l'intero `sdkConfiguration` blocco dovrebbe essere omesso.
**`sdkConfiguration.path`**
Il percorso assoluto della directory SDK che contiene il codice FreerTOS. Se non stai usando un SDK, allora l'intero `sdkConfiguration` blocco dovrebbe essere omesso.
**`buildTool`**
Il percorso completo allo script di build (.bat o.sh) contenente i comandi per creare il codice sorgente. Tutti i riferimenti al percorso del codice sorgente nel comando build devono essere sostituiti dalla AWS IoT Device Tester variabile `{{testdata.sourcePath}}` e i riferimenti al percorso SDK devono essere sostituiti da. `{{sdkPath}}` Utilizzate il `{{config.idtRootPath}}` segnaposto per fare riferimento al percorso IDT assoluto o relativo.
**`testStartDelayms`**
Speciifica quanti millisecondi aspetterà il test runner FreerTOS prima di iniziare a eseguire i test. Ciò può essere utile se il dispositivo sottoposto a test inizia a emettere importanti informazioni di test prima che IDT abbia la possibilità di connettersi e avviare la registrazione a causa della rete o di altra latenza. Il valore massimo consentito è 30000 ms (30 secondi). Questo valore è applicabile solo ai gruppi di test FreerTOS e non applicabile ad altri gruppi di test che non utilizzano il test runner FreerTOS, come i test OTA.
**`flashTool`**
Il percorso completo allo script di flash (.sh o.bat) contenente i comandi flash per il dispositivo. Tutti i riferimenti al percorso del codice sorgente nel comando flash devono essere sostituiti dalla variabile IDT per FreerTOS `{{testdata.sourcePath}}` e tutti i riferimenti al percorso SDK devono essere sostituiti dalla variabile IDT per FreeRTOS. Utilizzate il segnaposto per fare riferimento al percorso IDT assoluto o relativo. `{{sdkPath}}` `{{config.idtRootPath}}`
**`buildImageInfo`**
**`testsImageName`**
Il nome del file prodotto dal comando build durante la creazione dei test dalla cartella. `freertos-source/tests`
**`demosImageName`**
Il nome del file prodotto dal comando build durante la creazione dei test dalla `freertos-source/demos` cartella.
**`clientWifiConfig`**
Configurazione del Wi-Fi client. I test della libreria Wi-Fi richiedono la connessione di una scheda MCU a due punti di accesso. I due punti di accesso possono essere uguali. Questo attributo configura le impostazioni di rete Wi-Fi per il primo punto di accesso. Alcuni dei casi di test del Wi-Fi prevedono che il punto di accesso disponga di una certa sicurezza e che non sia aperto. Assicurati che entrambi i punti di accesso si trovino sulla stessa sottorete del computer host su cui è in esecuzione IDT.
**`wifi_ssid`**
SSID del Wi-Fi.
**`wifi_password`**
Password del Wi-Fi.
**`wifiSecurityType`**
Tipo di sicurezza Wi-Fi utilizzato. Uno dei valori:
+ `eWiFiSecurityOpen`
+ `eWiFiSecurityWEP`
+ `eWiFiSecurityWPA`
+ `eWiFiSecurityWPA2`
+ `eWiFiSecurityWPA3`
Se la scheda non supporta il Wi-Fi, devi comunque includere la sezione `clientWifiConfig` nel file `device.json`, ma puoi omettere i valori per questi attributi.
**`testWifiConfig`**
Effettua il test della configurazione Wi-Fi. I test della libreria Wi-Fi richiedono la connessione di una scheda MCU a due punti di accesso. I due punti di accesso possono essere uguali. Questo attributo configura l'impostazione del Wi-Fi per il secondo punto di accesso. Alcuni dei casi di test del Wi-Fi prevedono che il punto di accesso disponga di una certa sicurezza e che non sia aperto. Assicurati che entrambi i punti di accesso si trovino sulla stessa sottorete del computer host su cui è in esecuzione IDT.
**`wifiSSID`**
SSID del Wi-Fi.
**`wifiPassword`**
Password del Wi-Fi.
**`wifiSecurityType`**
Tipo di sicurezza Wi-Fi utilizzato. Uno dei valori:
+ `eWiFiSecurityOpen`
+ `eWiFiSecurityWEP`
+ `eWiFiSecurityWPA`
+ `eWiFiSecurityWPA2`
+ `eWiFiSecurityWPA3`
Se la scheda non supporta il Wi-Fi, devi comunque includere la sezione `testWifiConfig` nel file `device.json`, ma puoi omettere i valori per questi attributi.
**`echoServerCertificateConfiguration`**
Il segnaposto configurabile per la generazione di certificati del server echo per i test dei socket sicuri. Questo campo è obbligatorio.
**`certificateGenerationMethod`**
Speciifica se il certificato del server viene generato automaticamente o fornito manualmente.
**`customPath`**
Sono «Personalizzati» `certificatePath` e `privateKeyPath` sono obbligatori. `certificateGenerationMethod`
**`certificatePath`**
Speciifica il percorso del file per il certificato del server.
**`privateKeyPath`**
Speciifica il percorso del file per la chiave privata.
**`eccCurveFormat`**
Specifica il formato della curva supportato dalla scheda. Richiesto quando `PKCS11` è impostato su «ecc» in`device.json`. I valori validi sono «P224", «P256", «P384" o «P521".
**`echoServerConfiguration`**
Le porte configurabili del server echo per i test dei socket sicuri. WiFi Questo campo è facoltativo.
**`securePortForSecureSocket`**
La porta che viene utilizzata per configurare un server echo con TLS per il test di Secure Sockets. Il valore predefinito è 33333. Verificare che la porta configurata non sia bloccata da un firewall o dalla rete aziendale.
**`insecurePortForSecureSocket`**
La porta che viene utilizzata per configurare un server echo senza TLS per il test di Secure Sockets. Il valore predefinito utilizzato nel test è 33334. Verificare che la porta configurata non sia bloccata da un firewall o dalla rete aziendale.
**`insecurePortForWiFi`**
La porta utilizzata per configurare il server echo senza TLS per il test. WiFi Il valore predefinito utilizzato nel test è 33335. Verificare che la porta configurata non sia bloccata da un firewall o dalla rete aziendale.
**`otaConfiguration`**
La configurazione OTA. [Facoltativo].
**`otaFirmwareFilePath`**
Il percorso completo dell'immagine OTA creata dopo il build. Ad esempio, `{{testData.sourcePath}}/relative-path/to/ota/image/from/source/root`.
**`deviceFirmwareFileName`**
Il percorso completo del file sul dispositivo MCU in cui si trova il firmware OTA. Anche se alcuni dispositivi non utilizzano questo campo, è comunque necessario fornire un valore.
**`otaDemoConfigFilePath`**
Il percorso completo di `aws_demo_config.h`, disponibile in `afr-source/vendors/vendor/boards/board/aws_demos/config_files/`. Questi file sono inclusi nel modello di codice di porting fornito da FreerTOS.
**`codeSigningConfiguration`**
La configurazione della firma del codice.
**`signingMethod`**
Il metodo di firma del codice. I valori possibili sono `AWS` o `Custom`.
Per le regioni di Pechino e Ningxia, usa. `Custom` `AWS`la firma del codice non è supportata in queste regioni.
**`signerHashingAlgorithm`**
L'algoritmo hash supportato sul dispositivo. I valori possibili sono `SHA1` o `SHA256`.
**`signerSigningAlgorithm`**
L'algoritmo di firma supportato sul dispositivo. I valori possibili sono `RSA` o `ECDSA`.
**`signerCertificate`**
Il certificato attendibile utilizzato per OTA.
Per il metodo di firma del AWS codice, usa Amazon Resource Name (ARN) per il certificato affidabile caricato su. AWS Certificate Manager
Per il metodo di firma del codice personalizzato, utilizza il percorso assoluto del file del certificato firmatario.
Per ulteriori informazioni sulla creazione di un certificato attendibile, consulta [Creazione di un certificato di firma del codice](ota-code-sign-cert.md).
**`signerCertificateFileName`**
Il nome del file del certificato di firma del codice sul dispositivo. Questo valore deve corrispondere al nome di file fornito durante l'esecuzione del `aws acm import-certificate` comando.
Per ulteriori informazioni, consulta [Creazione di un certificato di firma del codice](ota-code-sign-cert.md).
**`compileSignerCertificate`**
Imposta questa `true` opzione se il certificato di verifica della firma del firmatario del codice non è fornito o aggiornato, quindi deve essere compilato nel progetto. AWS IoT Device Tester recupera il certificato affidabile e lo compila in. `aws_codesigner_certifiate.h`
**`untrustedSignerCertificate`**
L'ARN o il percorso del file per un secondo certificato utilizzato in alcuni test OTA come certificato non attendibile. Per ulteriori informazioni sulla creazione di un certificato, consulta [Creare un](https://docs.aws.amazon.com/freertos/latest/userguide/ota-code-sign-cert.html) certificato di firma del codice.
**`signerPlatform`**
L'algoritmo di firma e hashing utilizzato da AWS Code Signer durante la creazione del processo di aggiornamento OTA. Al momento, i valori possibili per questo campo sono `AmazonFreeRTOS-TI-CC3220SF` e `AmazonFreeRTOS-Default`.
+ Scegli `AmazonFreeRTOS-TI-CC3220SF` se `SHA1` e `RSA`.
+ Scegli `AmazonFreeRTOS-Default` se `SHA256` e `ECDSA`.
Se ti occorre `SHA256` \$1 `RSA` o `SHA1` \$1 `ECDSA` per la configurazione, contattaci per ulteriore supporto.
Configura `signCommand` se hai scelto `Custom` per `signingMethod`.
**`signCommand`**
Il comando utilizzato per eseguire la firma del codice personalizzato. Puoi trovare il modello nella directory `/configs/script_templates`.
Sono necessari due segnaposto `{{inputImageFilePath}}` e `{{outputSignatureFilePath}}` nel comando. `{{inputImageFilePath}}` è il percorso del file dell'immagine creata da IDT da firmare. `{{outputSignatureFilePath}}` è il percorso del file della firma che verrà generato dallo script.
**`cmakeConfiguration`**
CMake configurazione [Opzionale]
Per eseguire casi di CMake test, è necessario fornire il nome della scheda, il nome del fornitore e l'opzione `frToolchainPath` o`compilerName`. `cmakeToolchainPath`Se disponi di un percorso personalizzato per accedere alla CMake toolchain, puoi anche fornire il.
**`boardName`**
Nome della scheda sottoposta a test. Il nome della scheda deve essere uguale al nome della cartella in `path/to/afr/source/code/vendors/vendor/boards/board`.
**`vendorName`**
Nome del fornitore della scheda sottoposta a test. Il nome del fornitore deve essere uguale al nome della cartella in `path/to/afr/source/code/vendors/vendor`.
**`compilerName`**
Nome del compilatore.
**`frToolchainPath`**
Percorso completo del toolchain del compilatore.
**`cmakeToolchainPath` **
Il percorso completo verso la toolchain. CMake Questo campo è facoltativo
**`freertosFileConfiguration`**
La configurazione dei file FreerTOS che IDT modifica prima di eseguire i test.
**`required`**
Questa sezione specifica i test obbligatori di cui hai spostato i file di configurazione PKCS11, ad esempio TLS e così via.
**`configName`**
Il nome del test che viene configurato.
**`filePath`**
Il percorso assoluto dei file di configurazione all'interno del `freertos` repository. Utilizzate la `{{testData.sourcePath}}` variabile per definire il percorso.
**`optional`**
Questa sezione specifica i test opzionali di cui sono stati spostati i file di configurazione, ad esempio OTA e così via. WiFi
**`configName`**
Il nome del test che viene configurato.
**`filePath`**
Il percorso assoluto dei file di configurazione all'interno del `freertos` repository. Utilizzate la `{{testData.sourcePath}}` variabile per definire il percorso.
**Nota**
Per eseguire i CMake test case, è necessario fornire il nome della scheda, il nome del fornitore e l'opzione `afrToolchainPath` o`compilerName`. Puoi anche fornire `cmakeToolchainPath` se disponi di un percorso personalizzato per la CMake toolchain.
# IDT per variabili FreerTOS
I comandi per creare il codice e eseguire il flashing del dispositivo potrebbero richiedere connettività o altre informazioni sui dispositivi per funzionare correttamente. AWS IoT Device Tester consente di fare riferimento alle informazioni sul dispositivo in flash e di creare comandi utilizzando [JsonPath](https://goessner.net/articles/JsonPath/). Utilizzando JsonPath espressioni semplici, è possibile recuperare le informazioni richieste specificate nel `device.json` file.
## Variabili di percorso
IDT per FreerTOS definisce le seguenti variabili di percorso che possono essere utilizzate nelle righe di comando e nei file di configurazione:
**`{{testData.sourcePath}}`**
Si estende al percorso del codice sorgente. Se utilizzi questa variabile, deve essere utilizzata sia nei comandi flash che di compilazione.
**`{{sdkPath}}`**
Si espande fino al valore del tuo `userData.sdkConfiguration.path` quando viene utilizzato nei comandi build e flash.
**`{{device.connectivity.serialPort}}`**
Si estende alla porta seriale.
**`{{device.identifiers[?(@.name == 'serialNo')].value[0]}}`**
Estende al numero seriale del dispositivo.
**`{{enableTests}}`**
Valore intero che indica se la compilazione è per test (valore 1) o demo (valore 0).
**`{{buildImageName}}`**
Il nome del file dell'immagine creata dal comando di compilazione.
**`{{otaCodeSignerPemFile}}`**
File PEM per il firmatario del codice OTA.
**`{{config.idtRootPath}}`**
Si espande fino al percorso principale. AWS IoT Device Tester Questa variabile sostituisce il percorso assoluto per IDT quando viene utilizzata dai comandi build e flash.
# Usa l'interfaccia utente IDT per eseguire la suite di qualificazione FreerTOS
A partire da IDT v4.3.0, for AWS IoT Device Tester FreerTOS (IDT-FreeRTOS) include un'interfaccia utente basata sul Web che consente di interagire con l'eseguibile della riga di comando IDT e i relativi file di configurazione. È possibile utilizzare l'interfaccia utente IDT-FreeRTOS per creare una nuova configurazione per eseguire test IDT o per modificare una configurazione esistente. È inoltre possibile utilizzare l'interfaccia utente per richiamare l'eseguibile IDT ed eseguire test.
L'interfaccia utente IDT-FreeRTOS offre le seguenti funzioni:
+ Semplifica la configurazione dei file di configurazione per i test IDT-FreeRTOS.
+ Semplifica l'utilizzo di IDT-FreeRTOS per eseguire test di qualificazione.
Per informazioni sull'utilizzo della riga di comando per eseguire i test di qualificazione, vedere. [Primo test della scheda del microcontrollore](qual-steps.md)
Questa sezione descrive i prerequisiti per l'utilizzo dell'interfaccia utente IDT-FreeRTOS e mostra come iniziare a eseguire test di qualificazione nell'interfaccia utente.
**Topics**
+ [Imposta i prerequisiti per eseguire la suite di qualificazione FreerTOS](dev-tester-ui-prereqs.md)
+ [Inizia con l'interfaccia utente IDT-FreeRTOS](dev-tester-ui-getting-started.md)
# Imposta i prerequisiti per eseguire la suite di qualificazione FreerTOS
Questa sezione descrive i prerequisiti per testare i microcontrollori con. AWS IoT Device Tester
**Topics**
+ [Utilizza un browser Web supportato](#idt-ui-supported-web-browser)
+ [Scarica FreerTOS](#ui-download-afr)
+ [Scarica IDT per FreerTOS](#ui-download-dev-tester-afr)
+ [Creare e configurare un account AWS](#ui-config-aws-account)
+ [AWS IoT Device Tester politica gestita](#ui-managed-policy)
## Utilizza un browser Web supportato
L'interfaccia utente IDT-FreeRTOS supporta i seguenti browser Web.
| Browser | Versione |
| --- | --- |
| Google Chrome | Le ultime tre versioni principali |
| Mozilla Firefox | Le ultime tre versioni principali |
| Microsoft Edge | Le ultime tre versioni principali |
| Apple Safari per macOS | Le ultime tre versioni principali |
Ti consigliamo di utilizzare Google Chrome o Mozilla Firefox per un'esperienza migliore.
**Nota**
L'interfaccia utente IDT-FreeRTOS non supporta Microsoft Internet Explorer.
## Scarica FreerTOS
Puoi scaricare una versione di FreerTOS [GitHub](https://github.com/aws/amazon-freertos)da con il seguente comando:
```
git clone --branch --recurse-submodules https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
dove è una versione di FreeRTOS (ad esempio, 202007.00) corrispondente a una versione IDT elencata in. [Versioni supportate di AWS IoT Device Tester](dev-test-versions-afr.md) Questo ti assicura di avere il codice sorgente completo, compresi i sottomoduli, e di utilizzare la versione corretta di IDT per la tua versione di FreerTOS e viceversa.
In Windows esiste un limite di lunghezza del percorso di 260 caratteri. La struttura dei percorsi di FreerTOS è profonda a molti livelli, quindi se usi Windows, mantieni i percorsi dei file al di sotto del limite di 260 caratteri. Ad esempio, clona FreerTOS su invece `C:\FreeRTOS` di. `C:\Users\username\programs\projects\myproj\FreeRTOS\`
### Considerazioni per la qualificazione LTS (qualificazione per FreerTOS che utilizza librerie LTS)
+ Affinché il tuo microcontrollore sia designato per supportare le versioni di FreeRTOS basate sul supporto a lungo termine (LTS) nel AWS Partner Device Catalog, devi fornire un file manifest. *Per ulteriori informazioni, consulta la [Checklist per la qualificazione di FreerTOS nella FreerTOS Qualification Guide](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist.html).*
+ Per verificare che il microcontrollore supporti le versioni basate su LTS di FreeRTOS e qualificarlo per l'invio al AWS Partner Device Catalog, è necessario utilizzare ( AWS IoT Device Tester IDT) con la suite di test FreerTOS Qualification (FRQ) v1.4.x.
+ Il supporto per le versioni basate su LTS di FreerTOS è limitato alla versione 202012.xx di FreerTOS.
## Scarica IDT per FreerTOS
Ogni versione di FreeRTOS ha una versione corrispondente di IDT per FreerTOS per eseguire test di qualificazione. Scarica la versione appropriata di IDT per FreerTOS da. [Versioni supportate di AWS IoT Device Tester](dev-test-versions-afr.md)
Estrai IDT for FreerTOS in una posizione del file system in cui disponi dei permessi di lettura e scrittura. Poiché Microsoft Windows ha un limite di caratteri per la lunghezza del percorso, estrai IDT per FreerTOS in una directory principale come o. `C:\` `D:\`
**Nota**
Si consiglia di estrarre il pacchetto IDT in un'unità locale. Se si consente a più utenti di eseguire IDT da una posizione condivisa, ad esempio una directory NFS o una cartella condivisa di rete Windows, il sistema potrebbe non rispondere o danneggiare i dati.
## Creare e configurare un account AWS
### Iscriviti per un Account AWS
Se non ne hai uno Account AWS, completa i seguenti passaggi per crearne uno.
**Per iscriverti a un Account AWS**
1. Apri la [https://portal.aws.amazon.com/billing/registrazione.](https://portal.aws.amazon.com/billing/signup)
1. Segui le istruzioni online.
Nel corso della procedura di registrazione riceverai una telefonata o un messaggio di testo e ti verrà chiesto di inserire un codice di verifica attraverso la tastiera del telefono.
Quando ti iscrivi a un Account AWS, *Utente root dell'account AWS*viene creato un. L’utente root dispone dell’accesso a tutte le risorse e tutti i Servizi AWS nell’account. Come best practice di sicurezza, assegna l’accesso amministrativo a un utente e utilizza solo l’utente root per eseguire [attività che richiedono l’accesso di un utente root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).
AWS ti invia un'email di conferma dopo il completamento della procedura di registrazione. In qualsiasi momento, puoi visualizzare l'attività corrente del tuo account e gestirlo accedendo a [https://aws.amazon.com/](https://aws.amazon.com/)e scegliendo **Il mio account**.
### Crea un utente con accesso amministrativo
Dopo esserti registrato Account AWS, proteggi Utente root dell'account AWS AWS IAM Identity Center, abilita e crea un utente amministrativo in modo da non utilizzare l'utente root per le attività quotidiane.
**Proteggi i tuoi Utente root dell'account AWS**
1. Accedi [Console di gestione AWS](https://console.aws.amazon.com/)come proprietario dell'account scegliendo **Utente root** e inserendo il tuo indirizzo Account AWS email. Nella pagina successiva, inserisci la password.
Per informazioni sull’accesso utilizzando un utente root, consulta la pagina [Accedere come utente root](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) nella *Guida per l’utente di Accedi ad AWS *.
1. Abilita l’autenticazione a più fattori (MFA) per l’utente root.
Per istruzioni, consulta [Abilitare un dispositivo MFA virtuale per l'utente Account AWS root (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) nella Guida per l'*utente IAM*.
**Crea un utente con accesso amministrativo**
1. Abilita il Centro identità IAM.
Per istruzioni, consulta [Abilitazione del AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) nella *Guida per l’utente di AWS IAM Identity Center *.
1. Nel Centro identità IAM, assegna l’accesso amministrativo a un utente.
Per un tutorial sull'utilizzo di IAM Identity Center directory come fonte di identità, consulta [Configurare l'accesso utente con l'impostazione predefinita IAM Identity Center directory](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) nella *Guida per l'AWS IAM Identity Center utente*.
**Accesso come utente amministratore**
+ Per accedere come utente del Centro identità IAM, utilizza l’URL di accesso che è stato inviato al tuo indirizzo e-mail quando hai creato l’utente del Centro identità IAM.
Per informazioni sull'accesso utilizzando un utente IAM Identity Center, consulta [AWS Accedere al portale di accesso](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) nella *Guida per l'Accedi ad AWS utente*.
**Assegnazione dell’accesso ad altri utenti**
1. Nel Centro identità IAM, crea un set di autorizzazioni conforme alla best practice per l’applicazione di autorizzazioni con il privilegio minimo.
Segui le istruzioni riportate nella pagina [Creazione di un set di autorizzazioni](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) nella *Guida per l’utente di AWS IAM Identity Center *.
1. Assegna al gruppo prima gli utenti e poi l’accesso con autenticazione unica (Single Sign-On).
Per istruzioni, consulta [Aggiungere gruppi](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) nella *Guida per l’utente di AWS IAM Identity Center *.
## AWS IoT Device Tester politica gestita
Per consentire l'esecuzione del tester del dispositivo e la raccolta delle metriche, la policy `AWSIoTDeviceTesterForFreeRTOSFullAccess` gestita contiene le seguenti autorizzazioni:
+ `iot-device-tester:SupportedVersion`
Concede il permesso di ottenere l'elenco delle versioni di FreerTOS e delle versioni della suite di test supportate da IDT, in modo che siano disponibili da. AWS CLI
+ `iot-device-tester:LatestIdt`
Concede l'autorizzazione per ottenere la AWS IoT Device Tester versione più recente disponibile per il download.
+ `iot-device-tester:CheckVersion`
Concede l'autorizzazione per verificare la compatibilità di una combinazione di versioni di prodotto, suite di test e AWS IoT Device Tester .
+ `iot-device-tester:DownloadTestSuite`
Concede l'autorizzazione a AWS IoT Device Tester scaricare le suite di test.
+ `iot-device-tester:SendMetrics`
Concede l'autorizzazione a pubblicare i dati delle metriche AWS IoT Device Tester di utilizzo.
# Inizia con l'interfaccia utente IDT-FreeRTOS
Questa sezione mostra come utilizzare l'interfaccia utente IDT-FreeRTOS per creare o modificare la configurazione, quindi mostra come eseguire i test.
**Topics**
+ [Configura le credenziali AWS](#configure-aws-credentials)
+ [Apri l'interfaccia utente IDT-FreeRTOS](#open-idt-ui)
+ [Creare una nuova configurazione](#create-new-configuration)
+ [Modifica una configurazione esistente](#modify-existing-configuration)
+ [Esegui test di qualificazione](#run-tests-from-ui)
## Configura le credenziali AWS
È necessario configurare le credenziali per l' AWS utente in [Creare e configurare un account AWS](dev-tester-ui-prereqs.md#ui-config-aws-account) cui è stato creato. Puoi specificare le credenziali in uno dei due modi seguenti:
+ In un file di credenziali
+ Come variabili di ambiente
### Configura AWS le credenziali con un file di credenziali
IDT usa lo stesso file delle credenziali di AWS CLI. Per ulteriori informazioni, consulta l'argomento relativo ai [file di configurazione e delle credenziali](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html).
La posizione del file delle credenziali varia a seconda del sistema operativo in uso:
+ macOS, Linux: `~/.aws/credentials`
+ Windows: `C:\Users\UserName\.aws\credentials`
Aggiungi AWS le tue credenziali al `credentials` file nel seguente formato:
```
[default]
aws_access_key_id =
aws_secret_access_key =
```
**Nota**
Se non usi il `default` AWS profilo, assicurati di specificare il nome del profilo nell'interfaccia utente IDT-FreeRTOS. Per ulteriori informazioni sui profili, vedere [Configurazione e impostazioni](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html) dei file di credenziali.
### Configura AWS le credenziali con variabili di ambiente
Le variabili di ambiente sono variabili gestite dal sistema operativo e utilizzate dai comandi di sistema. Non vengono salvate se si chiude la sessione SSH. L'interfaccia utente IDT-FreeRTOS utilizza le variabili di `AWS_SECRET_ACCESS_KEY` ambiente `AWS_ACCESS_KEY_ID` e per memorizzare le credenziali. AWS
Per impostare queste variabili su Linux, macOS o Unix, utilizza **export**:
```
export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
```
Per impostare queste variabili su Windows, utilizza **set**:
```
set AWS_ACCESS_KEY_ID=
set AWS_SECRET_ACCESS_KEY=
```
## Apri l'interfaccia utente IDT-FreeRTOS
**Per aprire l'interfaccia utente di IDT-FreeRTOS**
1. Scarica una versione IDT-FreeRTOS supportata ed estrai l'archivio scaricato in una posizione del tuo file system in cui disponi delle autorizzazioni di lettura e scrittura.
1. Esegui il seguente comando per accedere alla directory di installazione di IDT-FreeRTOS:
```
cd devicetester-extract-location/bin
```
1. Esegui il seguente comando per aprire l'interfaccia utente IDT-FreeRTOS:
------
#### [ Linux ]
```
.devicetestergui_linux_x86-64.exe
```
------
#### [ Windows ]
```
./devicetestergui_win_x64-64
```
------
#### [ macOS ]
```
./devicetestergui_mac_x86-64
```
**Nota**
Su Mac, per consentire al sistema di eseguire l'interfaccia utente, vai su **Preferenze di Sistema ->** Sicurezza e privacy. Quando esegui i test, potresti dover eseguire questa operazione altre tre volte.
------
L'interfaccia utente IDT-FreeRTOS si apre nel browser predefinito. Per informazioni sui browser supportati, vedere. [Utilizza un browser Web supportato](dev-tester-ui-prereqs.md#idt-ui-supported-web-browser)
## Creare una nuova configurazione
Se sei un utente alle prime armi, devi creare una nuova configurazione per configurare i file di configurazione JSON richiesti da IDT-FreeRTOS per eseguire i test. È quindi possibile eseguire test o modificare la configurazione creata.
Per esempi dei `userdata.json` file, e`config.json`,`device.json`,,,,, vedi[Primo test della scheda del microcontrollore](qual-steps.md). Per un esempio del `resource.json` file utilizzato solo per eseguire i test Bluetooth Low Energy (BLE), vedere[Esegui i test Bluetooth Low Energy](afr-bridgekeeper-dt-bt.md).
**Per creare una nuova configurazione**
1. **Nell'interfaccia utente di IDT-FreeRTOS, apri il menu di navigazione, quindi scegli Crea nuova configurazione.**
**Importante**
È necessario configurare le AWS credenziali prima di aprire l'interfaccia utente. Se non hai configurato le tue credenziali, chiudi la finestra del browser dell'interfaccia utente IDT-FreeRTOS, segui i passaggi indicati e riapri l'interfaccia utente di IDT-FreeRTOS. [Configura le credenziali AWS](#configure-aws-credentials)
1. Segui la procedura guidata di configurazione per accedere alle impostazioni di configurazione IDT utilizzate per eseguire i test di qualificazione. La procedura guidata configura le seguenti impostazioni nei file di configurazione JSON che si trovano nella directory. `devicetester-extract-location/config`
+ **AWS settings: le** Account AWS informazioni che IDT-FreeRTOS utilizza per creare AWS risorse durante le esecuzioni dei test. Queste impostazioni sono configurate nel file. `config.json`
+ Repository **FreerTOS**: il percorso assoluto verso il repository FreerTOS e il codice portato e il tipo di qualifica che desideri eseguire. Queste impostazioni sono configurate nel file. `userdata.json`
Devi portare FreerTOS sul tuo dispositivo prima di poter eseguire i test di qualificazione. Per ulteriori informazioni, consulta la [FreerTOS Porting Guide](https://docs.aws.amazon.com/freertos/latest/portingguide/)
+ **Build and flash**: i comandi build e flash per l'hardware che consentono a IDT di creare e eseguire test flash sulla scheda in modo automatico. Queste impostazioni sono configurate nel file. `userdata.json`
+ **Dispositivi**: le impostazioni del pool di dispositivi per i dispositivi da testare. Queste impostazioni sono configurate nei `sku` campi `id` e nel `devices` blocco per il pool di dispositivi nel `device.json` file.
+ **Rete**: le impostazioni per testare il supporto delle comunicazioni di rete per i dispositivi. Queste impostazioni sono configurate nel `features` blocco del `device.json` file e nei `testWifiConfig` blocchi `clientWifiConfig` and del `userdata.json` file.
+ **Echo server**: le impostazioni di configurazione del server echo per i test Secure Socket. Queste impostazioni sono configurate nel file. `userdata.json`
Per ulteriori informazioni sulla configurazione del server echo, vedere[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**— (Facoltativo) Le impostazioni per eseguire i test di funzionalità della CMake build. Questa configurazione è richiesta solo se utilizzi CMake come sistema di compilazione. Queste impostazioni sono configurate nel `userdata.json` file.
+ **BLE**: le impostazioni per eseguire i test di funzionalità Bluetooth Low Energy. Queste impostazioni sono configurate nel `features` blocco del `device.json` file e nel `resource.json` file.
+ **OTA**: le impostazioni per eseguire i test di funzionalità OTA. Queste impostazioni sono configurate nel `features` blocco del `device.json` file e nel `userdata.json` file.
1. Nella pagina **Revisione**, verifica le informazioni di configurazione.
Dopo aver esaminato la configurazione, per eseguire i test di qualificazione, scegli **Esegui test**.
## Modifica una configurazione esistente
Se hai già impostato i file di configurazione per IDT, puoi utilizzare l'interfaccia utente IDT-FreeRTOS per modificare la configurazione esistente. Assicuratevi che i file di configurazione esistenti siano disponibili nella directory. `devicetester-extract-location/config`
**Per modificare una nuova configurazione**
1. **Nell'interfaccia utente IDT-FreeRTOS, apri il menu di navigazione, quindi scegli Modifica configurazione esistente.**
La dashboard di configurazione mostra informazioni sulle impostazioni di configurazione esistenti. Se una configurazione è errata o non disponibile, lo stato di tale configurazione è`Error validating configuration`.
1. Per modificare un'impostazione di configurazione esistente, completare i seguenti passaggi:
1. Scegli il nome di un'impostazione di configurazione per aprire la relativa pagina delle impostazioni.
1. Modifica le impostazioni, quindi scegli **Salva** per rigenerare il file di configurazione corrispondente.
Dopo aver modificato la configurazione, verifica che tutte le impostazioni di configurazione superino la convalida. Se lo stato di ogni impostazione di configurazione è`Valid`, puoi eseguire i test di qualificazione utilizzando questa configurazione.
## Esegui test di qualificazione
Dopo aver creato una configurazione per IDT-FreeRTOS, puoi eseguire i test di qualificazione.
**Per eseguire test di qualificazione**
1. Convalida la tua configurazione.
1. Nel menu di navigazione, scegli **Esegui test**.
1. Per iniziare l'esecuzione del test, scegli **Avvia test**.
**IDT-FreeRTOS esegue i test di qualificazione e visualizza il riepilogo dei test eseguiti e gli eventuali errori nella console Test runner.** Una volta completata l'esecuzione del test, è possibile visualizzare i risultati e i registri del test dalle seguenti posizioni:
+ I risultati dei test si trovano nella `devicetester-extract-location/results/execution-id` directory.
+ I registri dei test si trovano nella `devicetester-extract-location/results/execution-id/logs` directory.
Per ulteriori informazioni sui risultati e sui registri dei test, vedere [Visualizza i risultati di IDT for FreerTOS](view-results-frq.md) e. [Visualizza i log di IDT for FreerTOS](view-logs-frq.md)
# Esegui i test Bluetooth Low Energy
Questa sezione descrive come configurare ed eseguire i test Bluetooth Low Energy utilizzando AWS IoT Device Tester FreerTOS.
I test Bluetooth non sono richiesti per la qualifica core. Se non vuoi testare il tuo dispositivo con il supporto Bluetooth di FreerTOS puoi saltare questa configurazione, assicurati di lasciare la funzionalità BLE in device.json impostata su. `No`
## Prerequisiti
+ Segui le istruzioni in [Primo test della scheda del microcontrollore](qual-steps.md).
+ Un Raspberry Pi 4B o 3B\$1. Obbligatorio per eseguire l'applicazione companion Raspberry Pi BLE.
+ Una scheda microSD e una scheda SD per il software Raspberry Pi.
## Configurazione di Raspberry Pi
Per testare le funzionalità BLE del dispositivo in prova (DUT), è necessario disporre di un Raspberry Pi Model 4B o 3B\$1.
**Per configurare il Raspberry Pi per eseguire i test BLE**
1. Scarica una delle immagini Yocto personalizzate che contengono il software necessario per eseguire i test.
+ [Immagine per Raspberry Pi 4B](https://docs.aws.amazon.com/freertos/latest/userguide/freertos/IDTFR_BLE_RaspberryPi4B_1.0.0_2021-04-13.rpi-sd.img)
+ [Immagine per 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**
L'immagine Yocto deve essere usata solo per i test con AWS IoT Device Tester FreerTOS e non per altri scopi.
1. Memorizzare sulla memoria flash l'immagine Yocto sulla scheda SD per Raspberry Pi.
1. Utilizzando uno strumento di scrittura per scheda SD come [Etcher](https://www.balena.io/etcher), memorizzare sulla memoria flash il file `image-name.rpi-sd.img` scaricato sulla scheda SD. Poiché l'immagine del sistema operativo è di grandi dimensioni, l'operazione potrebbe richiedere alcuni minuti. Espelli la scheda SD dal computer e inserisci la scheda microSD nel Raspberry Pi.
1. Configurare il Raspberry Pi.
1. Per il primo avvio, ti consigliamo di connettere il Raspberry Pi a un monitor, una tastiera e un mouse.
1. Collegare il Raspberry Pi a una fonte di alimentazione micro USB.
1. Accedere utilizzando le credenziali predefinite. Per ID utente, immettere **root**. Per la password, immettere **idtafr**.
1. Utilizzando una connessione Wi-Fi o Ethernet, connettere il Raspberry Pi alla rete.
1. Per collegare il Raspberry Pi tramite Wi-Fi, aprire `/etc/wpa_supplicant.conf` sul Raspberry Pi e aggiungere le credenziali Wi-Fi alla configurazione di `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. Eseguire `ifup wlan0` per avviare la connessione Wi-Fi. Potrebbe essere necessario qualche minuto per la connessione alla rete Wi-Fi.
1. Per una connessione Ethernet, eseguire `ifconfig eth0`. Per una connessione Wi-Fi, eseguire `ifconfig wlan0`. Annotare l'indirizzo IP che viene visualizzato come `inet addr` nell'output del comando. L'indirizzo IP sarà necessario più avanti in questa procedura.
1. (Facoltativo) I test eseguono i comandi sul Raspberry Pi tramite SSH utilizzando le credenziali predefinite per l'immagine yocto. Per una maggiore sicurezza, si consiglia di impostare l'autenticazione della chiave pubblica per SSH e disabilitare l'SSH basato su password.
1. Creare un chiave SSH utilizzando il comando `ssh-keygen` OpenSSL. Se hai già una coppia di chiavi SSK sul tuo computer host, è consigliabile crearne una nuova AWS IoT Device Tester per consentire a FreerTOS di accedere al tuo Raspberry Pi.
**Nota**
Windows non viene fornito con un client SSH preinstallato. Per informazioni su come installare un client SSH su Windows, consultare l'argomento che descrive come [scaricare il software SSH](https://www.ssh.com/ssh/#sec-Download-client-software).
1. Il comando `ssh-keygen` richiede di specificare un nome e un percorso di archiviazione della coppia di chiavi. Per impostazione predefinita, i file della coppia di chiavi sono `id_rsa` (chiave privata) e `id_rsa.pub` (chiave pubblica). In macOS e Linux, il percorso predefinito di questi file è `~/.ssh/`. In Windows, la posizione predefinita è `C:\Users\user-name`.
1. Quando viene richiesta una frase chiave, è sufficiente premere INVIO per continuare.
1. Per aggiungere la tua chiave SSH al tuo Raspberry Pi in modo che AWS IoT Device Tester FreerTOS possa accedere al dispositivo, usa il `ssh-copy-id` comando dal tuo computer host. Questo comando aggiunge la chiave pubblica al file `~/.ssh/authorized_keys` sul Raspberry Pi.
`ssh-copy-id root@raspberry-pi-ip-address`
1. Quando viene richiesta una password, immettere **idtafr**. Questa è la password predefinita per l'immagine yocto.
**Nota**
Il comando `ssh-copy-id` presume che la chiave pubblica sia denominata `id_rsa.pub`. Su macOS e Linux, la posizione predefinita è ` ~/.ssh/`. In Windows, la posizione predefinita è `C:\Users\user-name\.ssh`. Se hai attribuito un nome diverso alla chiave pubblica o la hai archiviata in una posizione diversa, devi specificare il percorso completo della chiave pubblica SSH con l'opzione `-i` di `ssh-copy-id`, ad esempio `ssh-copy-id -i ~/my/path/myKey.pub`. Per ulteriori informazioni sulla creazione di chiavi SSH e sulla copia di chiavi pubbliche, consulta [SSH-COPY-ID](https://www.ssh.com/ssh/copy-id).
1. Per verificare che l'autenticazione della chiave pubblica funzioni, eseguire `ssh -i /my/path/myKey root@raspberry-pi-device-ip`.
Se non viene richiesta una password, l'autenticazione della chiave pubblica è attiva.
1. Verificare che sia possibile accedere al Raspberry Pi utilizzando una chiave pubblica e quindi disabilitare SSH basato su password.
1. Sul Raspberry Pi, modificare il file `/etc/ssh/sshd_config`.
1. Impostare l'attributo `PasswordAuthentication` su `no`.
1. Salvare e chiudere il file `sshd_config`.
1. Ricaricare il server SSH eseguendo `/etc/init.d/sshd reload`.
1. Creare un file `resource.json`.
1. Nella directory in cui hai estratto AWS IoT Device Tester, crea un file denominato. `resource.json`
1. Aggiungi le seguenti informazioni sul tuo Raspberry Pi al file, sostituendole *rasp-pi-ip-address* con l'indirizzo IP del tuo 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 non hai scelto di utilizzare l'autenticazione a chiave pubblica per SSH, aggiungi quanto segue alla `connectivity` sezione del file. `resource.json`
```
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address",
"auth": {
"method": "password",
"credentials": {
"user": "root",
"password": "idtafr"
}
}
}
```
1. (Facoltativo) Se è stato scelto di utilizzare l'autenticazione della chiave pubblica per SSH, aggiungere quanto segue alla sezione `connectivity` del file `resource.json`.
```
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address",
"auth": {
"method": "pki",
"credentials": {
"user": "root",
"privKeyPath": "location-of-private-key"
}
}
}
```
## Configurazione del dispositivo FreerTOS
Nel file `device.json`, imposta la caratteristica `BLE` su `Yes`. Se si inizia da un file `device.json` prima che i test Bluetooth fossero disponibili, è necessario aggiungere la caratteristica per BLE all'array `features`:
```
{
...
"features": [
{
"name": "BLE",
"value": "Yes"
},
...
}
```
## Esegui i test BLE
Dopo aver abilitato la caratteristica BLE in `device.json`, i test BLE vengono eseguiti quando esegui `devicetester_[linux | mac | win_x86-64] run-suite` *senza specificare un ID gruppo*.
Se vuoi eseguire i test BLE separatamente, puoi specificare l'ID gruppo per BLE: `devicetester_[linux | mac | win_x86-64] run-suite --userdata path-to-userdata/userdata.json --group-id FullBLE`.
Per le prestazioni più affidabili, posiziona il Raspberry Pi vicino al dispositivo sottoposto a test.
## Risolvi i problemi relativi ai test BLE
Verifica di aver seguito i passaggi descritti in [Primo test della scheda del microcontrollore](qual-steps.md). Se i test diversi da BLE non riescono, il problema probabilmente non è dovuto alla configurazione Bluetooth.
# Esegui la suite di qualificazione FreerTOS
Si utilizza l'eseguibile AWS IoT Device Tester for FreeRTOS per interagire con IDT for FreerTOS. Gli esempi della riga di comando seguenti illustrano come eseguire i test di qualifica per un pool di dispositivi (serie di dispositivi identici).
------
#### [ 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
```
Esegue una suite di test in un determinato pool di dispositivi. Il file `userdata.json` si deve trovare nella directory `devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/`.
**Nota**
Se stai usando IDT for FreerTOS su Windows, usa le barre (/) per specificare il percorso del file. `userdata.json`
Utilizza il comando seguente per eseguire un gruppo di test specifico:
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1.0.1 \
--group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
I parametri `suite-id` e `pool-id` sono facoltativi se esegui una singola suite di test su un singolo pool di dispositivi (ovvero nel tuo file `device.json` c'è un solo pool di dispositivi definito).
Utilizza il comando seguente per eseguire un caso di test specifico in un gruppo di test:
```
devicetester_[linux | mac | win_x86-64] run-suite \
--group-id group-id \
--test-id test-id
```
Puoi utilizzare il comando `list-test-cases` per elencare i casi di test in un gruppo di test. IDT per le opzioni della riga di comando di FreerTOS
**group-id**
(Facoltativo) I gruppi di test da eseguire, come elenco con valori separati da virgole. Se non specificato, IDT esegue tutti i gruppi di test nella suite di test.
**pool-id**
(Facoltativo) Il pool di dispositivi da testare. Questo è necessario se si definiscono più pool di dispositivi in `device.json`. Se hai un solo pool di dispositivi, questa opzione può essere omessa.
**suite-id**
(Facoltativo) Versione della suite di test da eseguire. Se non specificato, IDT utilizza la versione più recente nella directory dei test del sistema.
A partire da IDT v3.0.0, IDT controlla online le suite di test più recenti. Per ulteriori informazioni, consulta [Versioni della suite di test](idt-test-suite-versions.md).
**test-id**
(Facoltativo) I test da eseguire, come elenco con valori separati da virgole. Se specificato, `group-id` deve includere un singolo gruppo.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id mqtt --test-id mqtt_test
```
**update-idt**
(Facoltativo) Se questo parametro non è impostato ed è disponibile una versione IDT più recente, ti verrà richiesto di aggiornare IDT. Se questo parametro è impostato su`Y`, IDT interromperà l'esecuzione del test se rileva che è disponibile una versione più recente. Se questo parametro è impostato su`N`, IDT continuerà l'esecuzione del test.
**update-managed-policy**
(Facoltativo) Se questo parametro non viene utilizzato e IDT rileva che la tua politica gestita non lo è up-to-date, ti verrà richiesto di aggiornare la politica gestita. Se questo parametro è impostato su`Y`, IDT interromperà l'esecuzione del test se rileva che la politica gestita non lo è. up-to-date Se questo parametro è impostato su`N`, IDT continuerà l'esecuzione del test.
**upgrade-test-suite**
(Facoltativo) Se non utilizzato ed è disponibile una versione più recente della suite di test, viene richiesto di scaricarla. Per nascondere il prompt, specifica `y` per scaricare sempre la suite di test più recente o `n` per utilizzare la suite di test specificata o l'ultima versione nel sistema.
**Example**
**Esempio**
Per scaricare e utilizzare sempre la suite di test più recente, utilizza il seguente comando.
```
devicetester_[linux | mac | win_x86-64] run-suite --userdata userdata file --group-id group ID --upgrade-test-suite y
```
Per utilizzare la suite di test più recente nel sistema, utilizza il seguente comando.
```
devicetester_[linux | mac | win_x86-64] run-suite --userdata userdata file --group-id group ID --upgrade-test-suite n
```
**h**
Utilizza l'opzione di aiuto per ulteriori informazioni sulle opzioni `run-suite`.
**Example**
**Esempio**
```
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
```
Il file `userdata.json` deve trovarsi nella directory `devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/`.
**Nota**
Se stai usando IDT for FreerTOS su Windows, usa le barre (/) per specificare il percorso del file. `userdata.json`
Utilizza il comando seguente per eseguire un gruppo di test specifico.
```
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` sono facoltativi se esegui una singola suite di test su un singolo pool di dispositivi (ovvero nel tuo file `device.json` c'è un solo pool di dispositivi definito).IDT per le opzioni della riga di comando di FreerTOS
**group-id**
(Facoltativo) Specifica il gruppo di test.
**pool-id**
Specifica il pool di dispositivi da testare. Se hai un solo pool di dispositivi, questa opzione può essere omessa.
**suite-id**
(Facoltativo) Specifica la suite di test da eseguire.
------
## Comandi IDT per FreerTOS
Il comando IDT for FreerTOS supporta le seguenti operazioni:
------
#### [ IDT v3.0.0 and later ]
**`help`**
Elenca le informazioni sul comando specificato.
**`list-groups`**
Elenca i gruppi in una determinata suite.
**`list-suites`**
Elenca le suite disponibili.
**`list-supported-products`**
Elenca i prodotti e le versioni della suite di test supportati.
**`list-supported-versions`**
Elenca le versioni di FreerTOS e della suite di test supportate dalla versione IDT corrente.
**`list-test-cases`**
Elenca i casi di test in un gruppo specificato.
**`run-suite`**
Esegue una suite di test in un determinato pool di dispositivi.
Utilizza l'opzione `--suite-id` per specificare una versione della suite di test oppure omettila per utilizzare la versione più recente nel sistema.
Utilizza `--test-id` per eseguire un singolo caso di test.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id mqtt --test-id mqtt_test
```
Per l'elenco completo delle opzioni, consulta [Esegui la suite di qualificazione FreerTOS](#run-tests).
A partire da IDT v3.0.0, IDT controlla online le suite di test più recenti. Per ulteriori informazioni, consulta [Versioni della suite di test](idt-test-suite-versions.md).
------
#### [ IDT v1.7.0 and earlier ]
**`help`**
Elenca le informazioni sul comando specificato.
**`list-groups`**
Elenca i gruppi in una determinata suite.
**`list-suites`**
Elenca le suite disponibili.
**`run-suite`**
Esegue una suite di test in un determinato pool di dispositivi.
------
## Test di riqualifica
Man mano che vengono rilasciate nuove versioni di IDT per i test di qualificazione FreerTOS o quando aggiorni i pacchetti o i driver di dispositivo specifici della scheda, puoi utilizzare IDT per FreerTOS per testare le tue schede microcontrollori. Per le qualifiche successive, assicurati di disporre delle versioni più recenti di FreeRTOS e IDT for FreerTOS ed esegui nuovamente i test di qualificazione.
# Visualizza i risultati di IDT for FreerTOS
Durante l'esecuzione, IDT scrive gli errori nella console, i file di log e i report di test. Al termine della suite di test di qualifica, IDT scrive un riepilogo dell'esecuzione dei test nella console e genera due report di test. Questi report sono disponibili in `devicetester-extract-location/results/execution-id/`. Entrambi i report acquisiscono i risultati dall'esecuzione della suite di test di qualifica.
`awsiotdevicetester_report.xml`È il rapporto del test di qualificazione che invii AWS per inserire il tuo dispositivo nel AWS Partner Device Catalog. Il report contiene i seguenti elementi:
+ La versione IDT per FreerTOS.
+ La versione di FreerTOS che è stata testata.
+ Le funzionalità di FreerTOS supportate dal dispositivo in base ai test superati.
+ Il codice SKU e il nome del dispositivo specificato nel file `device.json`.
+ Le caratteristiche del dispositivo specificato nel file `device.json`.
+ Il riepilogo aggregato dei risultati dei casi di test.
+ Un'analisi dei risultati dei test case in base alle librerie testate in base alle funzionalità del dispositivo (ad esempio FullWiFi, FullMQTT e così via).
+ Se questa qualifica di FreerTOS è per la versione 202012.00 che utilizza le librerie LTS.
`FRQ_Report.xml`[Si tratta di un rapporto in formato XML standard. JUnit ](https://llg.cubic.org/docs/junit/) Puoi integrarlo in CI/CD piattaforme come [Jenkins](https://jenkins.io/), [Bamboo](https://www.atlassian.com/software/bamboo) e così via. Il report contiene i seguenti elementi:
+ Un riepilogo aggregato dei risultati dei casi di test.
+ Un'analisi dei risultati dei casi di test suddivisi per le librerie sottoposte a test in base alle caratteristiche del dispositivo.
# Interpreta i risultati di IDT for FreerTOS
La sezione dei report in `awsiotdevicetester_report.xml` o `FRQ_Report.xml` elenca i risultati dei test eseguiti.
Il primo tag XML `` contiene il riepilogo complessivo dell'esecuzione dei test. Esempio:
``
**Attributi utilizzati nel `` tag**
**`name`**
Il nome della suite di test.
**`time`**
Il tempo, espresso in secondi, impiegato per eseguire la suite di qualifica.
**`tests`**
Il numero dei casi di test eseguiti.
**`failures`**
Il numero dei casi di test eseguiti ma non superati.
**`errors`**
Il numero di casi di test che IDT for FreerTOS non è riuscito a eseguire.
**`disabled`**
Questo attributo non è utilizzato e si può ignorare.
Se non ci sono guasti o errori nel test case, il tuo dispositivo soddisfa i requisiti tecnici per eseguire FreerTOS e può interagire con i servizi. AWS IoT Se scegli di inserire il tuo dispositivo nel AWS Partner Device Catalog, puoi utilizzare questo rapporto come prova di idoneità.
In caso di esiti negativi o errori nei casi di test, puoi identificare il caso di test non riuscito esaminando i tag XML ``. I tag XML `` all'interno del tag `` mostrano il riepilogo dei risultati dei casi di test per un gruppo di test.
``
Il formato è simile al tag ``, ma con un attributo denominato `skipped` che non viene utilizzato e si può ignorare. All'interno di ogni tag XML `` ci sono tag `` per ciascuno dei casi di test eseguiti per un gruppo di test. Esempio:
``
**Attributi utilizzati nel tag ``**
**`name`**
Il nome del prodotto sottoposto a test.
**`version`**
La versione del prodotto sottoposto a test.
**`sdk`**
Se hai eseguito IDT con un SDK, questo blocco contiene il nome e la versione del tuo SDK. Se non hai eseguito IDT con un SDK, questo blocco contiene:
```
N/A
N/A
```
**`features`**
Le caratteristiche convalidate. Le caratteristiche contrassegnate come `required` sono necessarie per inviare la scheda per la qualifica. Il seguente frammento mostra come questo appare nel file. `awsiotdevicetester_report.xml`
```
```
Caratteristiche contrassegnate come `optional` non sono necessarie per la qualifica. I seguenti snippet mostrano caratteristiche facoltative.
```
```
Se non si verificano errori o errori nei test per le funzionalità richieste, il dispositivo soddisfa i requisiti tecnici per eseguire FreerTOS e può interagire con i servizi. AWS IoT Se desideri inserire il tuo dispositivo nel [AWS Partner Device Catalog](https://partners.amazonaws.com/qualified-devices), puoi utilizzare questo rapporto come prova di idoneità.
In caso di esiti negativi o errori nei test, puoi identificare il test non riuscito esaminando i tag XML ``. I tag XML `` all'interno del tag `` mostrano il riepilogo dei risultati dei test per un gruppo di test. Esempio:
```
```
Il formato è simile al `` tag, ma ha un `skipped` attributo che non viene utilizzato e può essere ignorato. All'interno di ogni tag XML `` ci sono tag `` per ciascuno dei test eseguiti per un gruppo di test. Esempio:
```
```
**`lts`**
Vero se sei idoneo per una versione di FreeRTOS che utilizza librerie LTS, false in caso contrario.
**Attributi usati nel tag ``**
**`name`**
Il nome del caso di test.
**`attempts`**
Il numero di volte in cui IDT per FreerTOS ha eseguito il test case.
Quando un test non riesce o si verifica un errore, i tag `` o `` vengono aggiunti al tag `` con informazioni per la risoluzione dei problemi. Esempio:
```
Reason for the test case failure
Reason for the test case execution error
```
Per ulteriori informazioni, consulta [Risoluzione degli errori](dt-afr-troubleshooting.md).
# Visualizza i log di IDT for FreerTOS
Puoi trovare i log che IDT for FreerTOS genera dall'esecuzione del test in. `devicetester-extract-location/results/execution-id/logs` Vengono generate due serie di log:
**`test_manager.log`**
Contiene i log generati da IDT per FreerTOS (ad esempio, la configurazione relativa ai log e la generazione di report).
**`test_group_id__test_case_id.log` (ad esempio, `FullMQTT__Full_MQTT.log`)**
Il file di log per un caso di test, incluso l'output dal dispositivo sottoposto a test. Il file di log viene denominato in base al gruppo di test e al caso di test che è stato eseguito.
# Sviluppa ed esegui le tue suite di test IDT
A partire da IDT v4.0.0, IDT per FreerTOS combina una configurazione di configurazione standardizzata e un formato di risultati con un ambiente di suite di test che consente di sviluppare suite di test personalizzate per i dispositivi e il software del dispositivo. Potete aggiungere test personalizzati per la vostra convalida interna o fornirli ai clienti per la verifica dei dispositivi.
Utilizza IDT per sviluppare ed eseguire suite di test personalizzate, come segue:
****Per sviluppare suite di test personalizzate****
+ Crea suite di test con logica di test personalizzata per il dispositivo che desideri testare.
+ Fornisci a IDT le tue suite di test personalizzate per i test runner. Includi informazioni sulle configurazioni di impostazioni specifiche per le tue suite di test.
****Per eseguire suite di test personalizzate****
+ Configura il dispositivo che desideri testare.
+ Implementa le configurazioni delle impostazioni come richiesto dalle suite di test che desideri utilizzare.
+ Usa IDT per eseguire le tue suite di test personalizzate.
+ Visualizza i risultati dei test e i registri di esecuzione per i test eseguiti da IDT.
## Scarica l'ultima versione di AWS IoT Device Tester per FreerTOS
Scaricate l'[ultima versione](dev-test-versions-afr.md#idt-latest-version-afr) di IDT ed estraete il software in una posizione del file system in cui disponete delle autorizzazioni di lettura e scrittura.
**Nota**
IDT non supporta l'esecuzione da parte di più utenti da un percorso condiviso, ad esempio una directory NFS o una cartella condivisa di rete Windows. Si consiglia di estrarre il pacchetto IDT in un'unità locale ed eseguire il file binario IDT sulla workstation locale.
In Windows esiste un limite di lunghezza del percorso di 260 caratteri. Se stai usando Windows, estrai IDT in una directory root come `C:\ ` o `D:\` per mantenere i percorsi entro il limite di 260 caratteri.
## Workflow della suite di test
Le suite di test sono composte da tre tipi di file:
+ File di configurazione che forniscono a IDT informazioni su come eseguire la suite di test.
+ File eseguibili di test utilizzati da IDT per eseguire casi di test.
+ File aggiuntivi necessari per eseguire i test.
Completa i seguenti passaggi di base per creare test IDT personalizzati:
1. [Crea file di configurazione](idt-json-config.md) per la tua suite di test.
1. [Crea eseguibili per test case](test-executables.md) che contengano la logica di test per la tua suite di test.
1. Verifica e documenta le [informazioni di configurazione richieste ai test runner per](set-config-custom.md) eseguire la suite di test.
1. Verifica che IDT sia in grado di eseguire la tua suite di test e produrre [i risultati dei test come previsto](run-tests-custom.md).
Per creare rapidamente una suite personalizzata di esempio ed eseguirla, segui le istruzioni riportate in[Tutorial: crea ed esegui la suite di test IDT di esempio](build-sample-suite.md).
Per iniziare a creare una suite di test personalizzata in Python, vedi. [Tutorial: Sviluppa una semplice suite di test IDT](create-custom-tests.md)
# Tutorial: crea ed esegui la suite di test IDT di esempio
Il AWS IoT Device Tester download include il codice sorgente per una suite di test di esempio. Puoi completare questo tutorial per creare ed eseguire la suite di test di esempio per capire come utilizzare FreerTOS AWS IoT Device Tester per eseguire suite di test personalizzate. Sebbene questo tutorial utilizzi SSH, è utile imparare a usarlo AWS IoT Device Tester con i dispositivi FreerTOS.
In questo tutorial, completerai i seguenti passaggi:
1. [Crea la suite di test di esempio](build-sample.md)
1. [Usa IDT per eseguire la suite di test di esempio](run-sample.md)
**Topics**
+ [Imposta i prerequisiti per la suite di test di esempio](prereqs-tutorial-sample.md)
+ [Configura le informazioni sul dispositivo per IDT](configure-idt-sample.md)
+ [Crea la suite di test di esempio](build-sample.md)
+ [Usa IDT per eseguire la suite di test di esempio](run-sample.md)
+ [Risoluzione degli errori](tutorial-troubleshooting-custom.md)
# Imposta i prerequisiti per la suite di test di esempio
Per completare questo tutorial, è necessario quanto segue:
+
**requisiti del computer host**
+ Versione più recente di AWS IoT Device Tester
+ [Python 3.7](https://docs.python.org/3/) o successivo
Per verificare la versione di Python installata sul tuo computer, esegui il seguente comando:
```
python3 --version
```
In Windows, se l'utilizzo di questo comando restituisce un errore, usalo `python --version` invece. Se il numero di versione restituito è 3.7 o superiore, esegui il comando seguente in un terminale Powershell da impostare `python3` come alias per il comando. `python`
```
Set-Alias -Name "python3" -Value "python"
```
Se non viene restituita alcuna informazione sulla versione o se il numero di versione è inferiore a 3.7, segui le istruzioni in [Downloading Python per installare Python](https://wiki.python.org/moin/BeginnersGuide/Download) 3.7\$1. Per ulteriori informazioni, consulta la documentazione di [Python](https://docs.python.org/3/).
+ [urllib3](https://urllib3.readthedocs.io/en/latest/)
Per verificare che `urllib3` sia installato correttamente, esegui il seguente comando:
```
python3 -c 'import urllib3'
```
Se non `urllib3` è installato, esegui il seguente comando per installarlo:
```
python3 -m pip install urllib3
```
+
**Requisiti per il dispositivo**
+ Un dispositivo con un sistema operativo Linux e una connessione di rete alla stessa rete del computer host.
Ti consigliamo di utilizzare un [Raspberry Pi](https://www.raspberrypi.org/) con sistema operativo Raspberry Pi. Assicurati di aver configurato [SSH](https://www.raspberrypi.com/documentation/computers/remote-access.html) sul tuo Raspberry Pi per connetterti in remoto ad esso.
# Configura le informazioni sul dispositivo per IDT
Configura le informazioni sul dispositivo per consentire a IDT di eseguire il test. È necessario aggiornare il `device.json` modello che si trova nella `/configs` cartella con le seguenti informazioni.
```
[
{
"id": "pool",
"sku": "N/A",
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
"privKeyPath": "/path/to/private/key",
"password": ""
}
}
}
}
]
}
]
```
Nell'`devices`oggetto, fornite le seguenti informazioni:
**`id`**
Un identificatore univoco definito dall'utente per il dispositivo.
**`connectivity.ip`**
L'indirizzo IP del dispositivo.
**`connectivity.port`**
Opzionale. Il numero di porta da utilizzare per le connessioni SSH al dispositivo.
**`connectivity.auth`**
Informazioni di autenticazione per la connessione.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `ssh`.
**`connectivity.auth.method`**
Il metodo di autorizzazione utilizzato per accedere a un dispositivo con un determinato protocollo di connettività.
I valori supportati sono:
+ `pki`
+ `password`
**`connectivity.auth.credentials`**
Le credenziali utilizzate per l'autenticazione.
**`connectivity.auth.credentials.user`**
Il nome utente utilizzato per accedere al dispositivo.
**`connectivity.auth.credentials.privKeyPath`**
Il percorso completo della chiave privata utilizzata per accedere al dispositivo.
Questo valore si applica solo se `connectivity.auth.method` è impostato su `pki`.
**`devices.connectivity.auth.credentials.password`**
La password utilizzata per accedere al dispositivo.
Questo valore si applica solo se `connectivity.auth.method` è impostato su `password`.
**Nota**
Specificare `privKeyPath` solo se `method` è impostato su `pki`.
Specificare `password` solo se `method` è impostato su `password`.
# Crea la suite di test di esempio
La `/samples/python` cartella contiene file di configurazione di esempio, codice sorgente e IDT Client SDK che puoi combinare in una suite di test utilizzando gli script di build forniti. Il seguente albero di directory mostra la posizione di questi file di esempio:
```
├── ...
├── tests
├── samples
│ ├── ...
│ └── python
│ ├── configuration
│ ├── src
│ └── build-scripts
│ ├── build.sh
│ └── build.ps1
└── sdks
├── ...
└── python
└── idt_client
```
Per creare la suite di test, esegui i seguenti comandi sul tuo computer host:
------
#### [ Windows ]
```
cd /samples/python/build-scripts
./build.ps1
```
------
#### [ Linux, macOS, or UNIX ]
```
cd /samples/python/build-scripts
./build.sh
```
------
Questo crea la suite di test di esempio nella `IDTSampleSuitePython_1.0.0` cartella all'interno della `/tests` cartella. Esamina i file nella `IDTSampleSuitePython_1.0.0` cartella per capire come è strutturata la suite di test di esempio e per vedere vari esempi di eseguibili di test case e file di configurazione dei test.
**Nota**
La suite di test di esempio include il codice sorgente Python. Non includete informazioni sensibili nel codice della suite di test.
Passaggio successivo: usa IDT per [eseguire la suite di test di esempio](run-sample.md) che hai creato.
# Usa IDT per eseguire la suite di test di esempio
Per eseguire la suite di test di esempio, esegui i seguenti comandi sul tuo computer host:
```
cd /bin
./devicetester_[linux | mac | win_x86-64] run-suite --suite-id IDTSampleSuitePython
```
IDT esegue la suite di test di esempio e trasmette i risultati alla console. Al termine dell'esecuzione del test, vengono visualizzate le seguenti informazioni:
```
========== 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
```
# Risoluzione degli errori
Utilizza le seguenti informazioni per risolvere eventuali problemi relativi al completamento del tutorial.
**Il test case non viene eseguito correttamente**
+ Se il test non viene eseguito correttamente, IDT invia i log degli errori alla console per aiutarti a risolvere i problemi relativi all'esecuzione del test. [Assicurati di soddisfare tutti i prerequisiti per questo tutorial.](prereqs-tutorial-sample.md)
**Impossibile connettersi al dispositivo in prova**
Verificare quanto segue:
+ Il `device.json` file contiene l'indirizzo IP, la porta e le informazioni di autenticazione corretti.
+ Puoi connetterti al tuo dispositivo tramite SSH dal tuo computer host.
# Tutorial: Sviluppa una semplice suite di test IDT
Una suite di test combina quanto segue:
+ Eseguibile di test che contiene la logica di test
+ File di configurazione che descrivono la suite di test
Questo tutorial mostra come usare IDT per FreerTOS per sviluppare una suite di test Python che contenga un singolo test case. Sebbene questo tutorial utilizzi SSH, è utile imparare a usarlo AWS IoT Device Tester con i dispositivi FreerTOS.
In questo tutorial, completerai i seguenti passaggi:
1. [Crea una directory per la suite di test](test-suite-dir.md)
1. [Crea file di configurazione](test-suite-json.md)
1. [Crea l'eseguibile del test case](test-suite-exe.md)
1. [Esegui la suite di test](run-test-suite.md)
Segui i passaggi seguenti per completare un tutorial per lo sviluppo di una semplice suite di test IDT.
**Topics**
+ [Imposta i prerequisiti per una semplice suite di test IDT](prereqs-tutorial-custom.md)
+ [Crea una directory per la suite di test](test-suite-dir.md)
+ [Crea file di configurazione](test-suite-json.md)
+ [Scarica l'SDK del client IDT](add-idt-sdk.md)
+ [Crea l'eseguibile del test case](test-suite-exe.md)
+ [Configura le informazioni sul dispositivo per IDT](configure-idt-sample2.md)
+ [Esegui la suite di test](run-test-suite.md)
+ [Risoluzione degli errori](tutorial-troubleshooting.md)
+ [Crea file di configurazione della suite di test IDT](idt-json-config.md)
+ [Configura l'orchestrator di test IDT](idt-test-orchestrator.md)
+ [Configurare la macchina a stati IDT](idt-state-machine.md)
+ [Crea un file eseguibile per il test case IDT](test-executables.md)
+ [Usa il contesto IDT](idt-context.md)
+ [Configura le impostazioni per i test runner](set-config-custom.md)
+ [Esegui il debug ed esegui suite di test personalizzate](run-tests-custom.md)
+ [Esamina i risultati e i registri dei test IDT](idt-review-results-logs.md)
+ [Invia le metriche di utilizzo IDT](idt-usage-metrics.md)
# Imposta i prerequisiti per una semplice suite di test IDT
Per completare questo tutorial, è necessario quanto segue:
+
**requisiti del computer host**
+ Versione più recente di AWS IoT Device Tester
+ [Python 3.7](https://www.python.org/downloads/) o successivo
Per verificare la versione di Python installata sul tuo computer, esegui il seguente comando:
```
python3 --version
```
In Windows, se l'utilizzo di questo comando restituisce un errore, usalo `python --version` invece. Se il numero di versione restituito è 3.7 o superiore, esegui il comando seguente in un terminale Powershell da impostare `python3` come alias per il comando. `python`
```
Set-Alias -Name "python3" -Value "python"
```
Se non viene restituita alcuna informazione sulla versione o se il numero di versione è inferiore a 3.7, segui le istruzioni in [Downloading Python per installare Python](https://wiki.python.org/moin/BeginnersGuide/Download) 3.7\$1. Per ulteriori informazioni, consulta la documentazione di [Python](https://docs.python.org/3/).
+ [urllib3](https://urllib3.readthedocs.io/en/latest/)
Per verificare che `urllib3` sia installato correttamente, esegui il seguente comando:
```
python3 -c 'import urllib3'
```
Se non `urllib3` è installato, esegui il seguente comando per installarlo:
```
python3 -m pip install urllib3
```
+
**Requisiti per il dispositivo**
+ Un dispositivo con un sistema operativo Linux e una connessione di rete alla stessa rete del computer host.
Ti consigliamo di utilizzare un [Raspberry Pi](https://www.raspberrypi.org/) con sistema operativo Raspberry Pi. Assicurati di aver configurato [SSH](https://www.raspberrypi.com/documentation/computers/remote-access.html) sul tuo Raspberry Pi per connetterti in remoto ad esso.
# Crea una directory per la suite di test
IDT separa logicamente i casi di test in gruppi di test all'interno di ciascuna suite di test. Ogni test case deve essere all'interno di un gruppo di test. Per questo tutorial, crea una cartella chiamata `MyTestSuite_1.0.0` e crea il seguente albero di directory all'interno di questa cartella:
```
MyTestSuite_1.0.0
└── suite
└── myTestGroup
└── myTestCase
```
# Crea file di configurazione
La suite di test deve contenere i seguenti [file di configurazione](idt-json-config.md) richiesti:
**File richiesti**
**`suite.json`**
Contiene informazioni sulla suite di test. Per informazioni, consulta [Configura suite.json](idt-json-config.md#suite-json).
**`group.json`**
Contiene informazioni su un gruppo di test. È necessario creare un `group.json` file per ogni gruppo di test nella suite di test. Per informazioni, consulta [Configura group.json](idt-json-config.md#group-json).
**`test.json`**
Contiene informazioni su un test case. È necessario creare un `test.json` file per ogni test case nella suite di test. Per informazioni, consulta [Configura test.json](idt-json-config.md#test-json).
1. Nella `MyTestSuite_1.0.0/suite` cartella, create un `suite.json` file con la seguente struttura:
```
{
"id": "MyTestSuite_1.0.0",
"title": "My Test Suite",
"details": "This is my test suite.",
"userDataRequired": false
}
```
1. Nella `MyTestSuite_1.0.0/myTestGroup` cartella, create un `group.json` file con la seguente struttura:
```
{
"id": "MyTestGroup",
"title": "My Test Group",
"details": "This is my test group.",
"optional": false
}
```
1. Nella `MyTestSuite_1.0.0/myTestGroup/myTestCase` cartella, create un `test.json` file con la seguente struttura:
```
{
"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"
]
}
}
}
```
L'albero delle cartelle della `MyTestSuite_1.0.0` cartella dovrebbe ora avere il seguente aspetto:
```
MyTestSuite_1.0.0
└── suite
├── suite.json
└── myTestGroup
├── group.json
└── myTestCase
└── test.json
```
# Scarica l'SDK del client IDT
Si utilizza l'[SDK del client IDT](test-executables.md#idt-client-sdk) per consentire a IDT di interagire con il dispositivo sottoposto a test e di riportare i risultati del test. Per questo tutorial, utilizzerai la versione Python dell'SDK.
Dalla `/sdks/python/` cartella, copia la `idt_client` cartella nella tua `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase` cartella.
Per verificare che l'SDK sia stato copiato correttamente, esegui il comando seguente.
```
cd MyTestSuite_1.0.0/suite/myTestGroup/myTestCase
python3 -c 'import idt_client'
```
# Crea l'eseguibile del test case
Gli eseguibili dei test case contengono la logica di test che si desidera eseguire. Una suite di test può contenere più eseguibili di test case. Per questo tutorial, creerai un solo eseguibile di test case.
1. Crea il file della suite di test.
Nella `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase` cartella, crea un `myTestCase.py` file con il seguente contenuto:
```
from idt_client import *
def main():
# Use the client SDK to communicate with IDT
client = Client()
if __name__ == "__main__":
main()
```
1. Utilizza le funzioni dell'SDK del client per aggiungere la seguente logica di test al tuo `myTestCase.py` file:
1. Esegui un comando SSH sul dispositivo sottoposto a test.
```
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. Invia il risultato del test a 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()
```
# Configura le informazioni sul dispositivo per IDT
Configura le informazioni sul dispositivo per consentire a IDT di eseguire il test. È necessario aggiornare il `device.json` modello che si trova nella `/configs` cartella con le seguenti informazioni.
```
[
{
"id": "pool",
"sku": "N/A",
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
"privKeyPath": "/path/to/private/key",
"password": ""
}
}
}
}
]
}
]
```
Nell'`devices`oggetto, fornite le seguenti informazioni:
**`id`**
Un identificatore univoco definito dall'utente per il dispositivo.
**`connectivity.ip`**
L'indirizzo IP del dispositivo.
**`connectivity.port`**
Opzionale. Il numero di porta da utilizzare per le connessioni SSH al dispositivo.
**`connectivity.auth`**
Informazioni di autenticazione per la connessione.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `ssh`.
**`connectivity.auth.method`**
Il metodo di autorizzazione utilizzato per accedere a un dispositivo con un determinato protocollo di connettività.
I valori supportati sono:
+ `pki`
+ `password`
**`connectivity.auth.credentials`**
Le credenziali utilizzate per l'autenticazione.
**`connectivity.auth.credentials.user`**
Il nome utente utilizzato per accedere al dispositivo.
**`connectivity.auth.credentials.privKeyPath`**
Il percorso completo della chiave privata utilizzata per accedere al dispositivo.
Questo valore si applica solo se `connectivity.auth.method` è impostato su `pki`.
**`devices.connectivity.auth.credentials.password`**
La password utilizzata per accedere al dispositivo.
Questo valore si applica solo se `connectivity.auth.method` è impostato su `password`.
**Nota**
Specificare `privKeyPath` solo se `method` è impostato su `pki`.
Specificare `password` solo se `method` è impostato su `password`.
# Esegui la suite di test
Dopo aver creato la suite di test, devi assicurarti che funzioni come previsto. Completa i seguenti passaggi per eseguire la suite di test con il pool di dispositivi esistente a tale scopo.
1. Copia la `MyTestSuite_1.0.0` cartella in`/tests`.
1. Esegui i comandi seguenti:
```
cd /bin
./devicetester_[linux | mac | win_x86-64] run-suite --suite-id MyTestSuite
```
IDT esegue la tua suite di test e trasmette i risultati alla console. Al termine dell'esecuzione del test, vengono visualizzate le seguenti informazioni:
```
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
```
# Risoluzione degli errori
Utilizza le seguenti informazioni per risolvere eventuali problemi relativi al completamento del tutorial.
**Il test case non viene eseguito correttamente**
Se il test non viene eseguito correttamente, IDT invia i log degli errori alla console per aiutarti a risolvere i problemi relativi all'esecuzione del test. Prima di controllare i log degli errori, verifica quanto segue:
+ L'SDK del client IDT si trova nella cartella corretta, come descritto in. [Scarica l'SDK del client IDT](add-idt-sdk.md)
+ Soddisfi tutti i prerequisiti per questo tutorial. Per ulteriori informazioni, consulta [Imposta i prerequisiti per una semplice suite di test IDT](prereqs-tutorial-custom.md).
**Impossibile connettersi al dispositivo in prova**
Verificare quanto segue:
+ Il `device.json` file contiene l'indirizzo IP, la porta e le informazioni di autenticazione corretti.
+ Puoi connetterti al tuo dispositivo tramite SSH dal tuo computer host.
# Crea file di configurazione della suite di test IDT
Questa sezione descrive i formati in cui crei i file di configurazione da includere quando scrivi una suite di test personalizzata.
**File di configurazione richiesti**
**`suite.json`**
Contiene informazioni sulla suite di test. Per informazioni, consulta [Configura suite.json](#suite-json).
**`group.json`**
Contiene informazioni su un gruppo di test. È necessario creare un `group.json` file per ogni gruppo di test nella suite di test. Per informazioni, consulta [Configura group.json](#group-json).
**`test.json`**
Contiene informazioni su un test case. È necessario creare un `test.json` file per ogni test case nella suite di test. Per informazioni, consulta [Configura test.json](#test-json).
**File di configurazione opzionali**
**`test_orchestrator.yaml` o `state_machine.json`**
Definisce come vengono eseguiti i test quando IDT esegue la suite di test. SSe [Configura test\$1orchestrator.yaml](#test-orchestrator-config).
A partire da IDT v4.5.2, si utilizza il `test_orchestrator.yaml` file per definire il flusso di lavoro del test. Nelle versioni precedenti di IDT, si utilizza il file. `state_machine.json` Per informazioni sulla macchina a stati, vedere[Configurare la macchina a stati IDT](idt-state-machine.md).
**`userdata_schema.json`**
Definisce lo schema per il [`userdata.json`file](set-config-custom.md#userdata-config-custom) che i test runner possono includere nella configurazione delle impostazioni. Il `userdata.json` file viene utilizzato per tutte le informazioni di configurazione aggiuntive necessarie per eseguire il test ma che non sono presenti nel `device.json` file. Per informazioni, consulta [Configura userdata\$1schema.json](#userdata-schema-json).
I file di configurazione vengono inseriti nel file `` come illustrato qui.
```
└── suite
├── suite.json
├── test_orchestrator.yaml
├── userdata_schema.json
├──
├── group.json
├──
└── test.json
```
## Configura suite.json
Il `suite.json` file imposta le variabili di ambiente e determina se i dati utente sono necessari per eseguire la suite di test. Utilizzate il seguente modello per configurare il `/suite/suite.json` file:
```
{
"id": "_",
"title": "",
"details": "",
"userDataRequired": true | false,
"environmentVariables": [
{
"key": "",
"value": "",
},
...
{
"key": "",
"value": "",
}
]
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`id`**
Un ID univoco definito dall'utente per la suite di test. Il valore di `id` deve corrispondere al nome della cartella della suite di test in cui si trova il `suite.json` file. Il nome e la versione della suite devono inoltre soddisfare i seguenti requisiti:
+ ``non può contenere caratteri di sottolineatura.
+ ``è indicato come`x.x.x`, dove `x` è un numero.
L'ID viene visualizzato nei rapporti di test generati da IDT.
**`title`**
Un nome definito dall'utente per il prodotto o la funzionalità testata da questa suite di test. Il nome viene visualizzato nella CLI IDT per i test runner.
**`details`**
Una breve descrizione dello scopo della suite di test.
**`userDataRequired`**
Definisce se i test runner devono includere informazioni personalizzate in un `userdata.json` file. Se imposti questo valore su`true`, devi anche includere il [`userdata_schema.json`file](#userdata-schema-json) nella cartella della suite di test.
**`environmentVariables`**
Opzionale. Una serie di variabili di ambiente da impostare per questa suite di test.
**`environmentVariables.key`**
Il nome della variabile di ambiente.
**`environmentVariables.value`**
Il valore della variabile di ambiente.
## Configura group.json
Il `group.json` file definisce se un gruppo di test è obbligatorio o facoltativo. Utilizzate il seguente modello per configurare il `/suite//group.json` file:
```
{
"id": "",
"title": "",
"details": "",
"optional": true | false,
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`id`**
Un ID univoco definito dall'utente per il gruppo di test. Il valore di `id` deve corrispondere al nome della cartella del gruppo di test in cui si trova il `group.json` file e non deve contenere caratteri di sottolineatura ()`_`. L'ID viene utilizzato nei report di test generati da IDT.
**`title`**
Un nome descrittivo per il gruppo di test. Il nome viene visualizzato nella CLI IDT per i test runner.
**`details`**
Una breve descrizione dello scopo del gruppo di test.
**`optional`**
Opzionale. Imposta `true` per visualizzare questo gruppo di test come gruppo opzionale dopo che IDT ha terminato l'esecuzione dei test richiesti. Il valore predefinito è `false`.
## Configura test.json
Il `test.json` file determina gli eseguibili del test case e le variabili di ambiente utilizzate da un test case. Per ulteriori informazioni sulla creazione di eseguibili per i test case, vedere. [Crea un file eseguibile per il test case IDT](test-executables.md)
Utilizzate il seguente modello per configurare il `/suite///test.json` file:
```
{
"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": "",
}
]
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`id`**
Un ID univoco definito dall'utente per il test case. Il valore di `id` deve corrispondere al nome della cartella del test case in cui si trova il `test.json` file e non deve contenere caratteri di sottolineatura ()`_`. L'ID viene utilizzato nei report di test generati da IDT.
**`title`**
Un nome descrittivo per il test case. Il nome viene visualizzato nella CLI IDT per i test runner.
**`details`**
Una breve descrizione dello scopo del test case.
**`requireDUT`**
Opzionale. Imposta `true` se è necessario un dispositivo per eseguire questo test, altrimenti imposta su`false`. Il valore predefinito è `true`. I test runner configureranno i dispositivi che useranno per eseguire il test nel proprio `device.json` file.
**`requiredResources`**
Opzionale. Un array che fornisce informazioni sui dispositivi di risorse necessari per eseguire questo test.
**`requiredResources.name`**
Il nome univoco da assegnare al dispositivo di risorse durante l'esecuzione di questo test.
**`requiredResources.features`**
Una serie di funzionalità del dispositivo di risorse definite dall'utente.
**`requiredResources.features.name`**
Il nome della funzionalità. La funzionalità del dispositivo per cui si desidera utilizzare questo dispositivo. Questo nome viene confrontato con il nome della funzionalità fornito dal test runner nel `resource.json` file.
**`requiredResources.features.version`**
Opzionale. La versione della funzionalità. Questo valore viene confrontato con la versione della funzionalità fornita dal test runner nel `resource.json` file. Se non viene fornita una versione, la funzionalità non viene verificata. Se non è richiesto un numero di versione per la funzionalità, lascia vuoto questo campo.
**`requiredResources.features.jobSlots`**
Opzionale. Il numero di test simultanei che questa funzionalità può supportare. Il valore predefinito è `1`. Se desideri che IDT utilizzi dispositivi distinti per le singole funzionalità, ti consigliamo di impostare questo valore su. `1`
**`execution.timeout`**
La quantità di tempo (in millisecondi) che IDT attende prima che il test finisca. Per ulteriori informazioni sull'impostazione di questo valore, vedere. [Crea un file eseguibile per il test case IDT](test-executables.md)
**`execution.os`**
Gli eseguibili del test case da eseguire in base al sistema operativo del computer host che esegue IDT. I valori supportati sono `linux`, `mac` e `win`.
**`execution.os.cmd`**
Il percorso dell'eseguibile del test case che si desidera eseguire per il sistema operativo specificato. Questa posizione deve trovarsi nel percorso di sistema.
**`execution.os.args`**
Opzionale. Gli argomenti da fornire per eseguire l'eseguibile del test case.
**`environmentVariables`**
Opzionale. Una serie di variabili di ambiente impostate per questo test case.
**`environmentVariables.key`**
Il nome della variabile di ambiente.
**`environmentVariables.value`**
Il valore della variabile di ambiente.
Se specificate la stessa variabile di ambiente nel `test.json` file e nel `suite.json` file, il valore nel `test.json` file ha la precedenza.
## Configura test\$1orchestrator.yaml
Un orchestratore di test è un costrutto che controlla il flusso di esecuzione della suite di test. Determina lo stato iniziale di una suite di test, gestisce le transizioni di stato in base a regole definite dall'utente e continua la transizione attraverso tali stati fino a raggiungere lo stato finale.
Se la vostra suite di test non include un orchestratore di test definito dall'utente, IDT genererà un orchestratore di test per voi.
L'orchestrator di test predefinito svolge le seguenti funzioni:
+ Fornisce ai test runner la possibilità di selezionare ed eseguire gruppi di test specifici, anziché l'intera suite di test.
+ Se non sono selezionati gruppi di test specifici, esegue ogni gruppo di test nella suite di test in ordine casuale.
+ Genera report e stampa un riepilogo della console che mostra i risultati dei test per ogni gruppo di test e test case.
Per ulteriori informazioni sul funzionamento dell'IDT test orchestrator, consulta. [Configura l'orchestrator di test IDT](idt-test-orchestrator.md)
## Configura userdata\$1schema.json
Il `userdata_schema.json` file determina lo schema in cui i test runner forniscono i dati degli utenti. I dati utente sono necessari se la suite di test richiede informazioni che non sono presenti nel `device.json` file. Ad esempio, i test potrebbero richiedere credenziali di rete Wi-Fi, porte aperte specifiche o certificati che un utente deve fornire. Queste informazioni possono essere fornite a IDT come parametro di input chiamato`userdata`, il cui valore è un `userdata.json` file, che gli utenti creano nella propria `/config` cartella. Il formato del `userdata.json` file si basa sul `userdata_schema.json` file incluso nella suite di test.
Per indicare che i test runner devono fornire un `userdata.json` file:
1. Nel `suite.json` file, imposta su`userDataRequired`. `true`
1. Nel tuo``, crea un `userdata_schema.json` file.
1. Modifica il `userdata_schema.json` file per creare uno schema [JSON IETF Draft v4](https://json-schema.org/specification-links#draft-4) valido.
Quando IDT esegue la suite di test, legge automaticamente lo schema e lo usa per convalidare il `userdata.json` file fornito dal test runner. [Se valido, il contenuto del `userdata.json` file è disponibile sia nel contesto [IDT che nel contesto del test orchestrator](idt-context.md).](idt-test-orchestrator.md#idt-test-orchestrator-context)
# Configura l'orchestrator di test IDT
*A partire da IDT v4.5.2, IDT include un nuovo componente di test orchestrator.* Il test orchestrator è un componente IDT che controlla il flusso di esecuzione della suite di test e genera il rapporto di test dopo che IDT ha terminato l'esecuzione di tutti i test. Il test orchestrator determina la selezione dei test e l'ordine in cui i test vengono eseguiti in base a regole definite dall'utente.
Se la tua suite di test non include un orchestratore di test definito dall'utente, IDT genererà un orchestrator di test per te.
L'orchestrator di test predefinito svolge le seguenti funzioni:
+ Fornisce ai test runner la possibilità di selezionare ed eseguire gruppi di test specifici, anziché l'intera suite di test.
+ Se non sono selezionati gruppi di test specifici, esegue ogni gruppo di test nella suite di test in ordine casuale.
+ Genera report e stampa un riepilogo della console che mostra i risultati dei test per ogni gruppo di test e test case.
Il test orchestrator sostituisce la macchina a stati IDT. Ti consigliamo vivamente di utilizzare il test orchestrator per sviluppare le tue suite di test anziché la macchina a stati IDT. Il test orchestrator offre le seguenti funzionalità migliorate:
+ Utilizza un formato dichiarativo rispetto al formato imperativo utilizzato dalla macchina a stati IDT. Ciò consente di specificare quali test eseguire e quando eseguirli.
+ Gestisce la gestione di gruppi specifici, la generazione di report, la gestione degli errori e il tracciamento dei risultati in modo da non dover gestire manualmente queste azioni.
+ Utilizza il formato YAML, che supporta i commenti per impostazione predefinita.
+ Richiede l'80% di spazio su disco in meno rispetto al test orchestrator per definire lo stesso flusso di lavoro.
+ Aggiunge la convalida preliminare al test per verificare che la definizione del flusso di lavoro non contenga test errati o dipendenze circolari. IDs
## Formato dell'orchestratore di test
È possibile utilizzare il seguente modello per configurare il proprio file: `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
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
`Aliases`
Opzionale. Stringhe definite dall'utente che mappano alle espressioni di contesto. Gli alias consentono di generare nomi descrittivi per identificare le espressioni di contesto nella configurazione del test orchestrator. Ciò è particolarmente utile se state creando espressioni di contesto complesse o espressioni da utilizzare in più posizioni.
È possibile utilizzare le espressioni di contesto per archiviare query di contesto che consentono di accedere ai dati da altre configurazioni IDT. Per ulteriori informazioni, consulta [Accedere ai dati nel contesto](idt-context.md#accessing-context-data).
**Example**
**Esempio**
```
Aliases:
FizzChosen: "'{{$pool.features[?(@.name == 'Fizz')].value[0]}}' == 'yes'"
BuzzChosen: "'{{$pool.features[?(@.name == 'Buzz')].value[0]}}' == 'yes'"
FizzBuzzChosen: "'{{$aliases.FizzChosen}}' && '{{$aliases.BuzzChosen}}'"
```
`ConditionalTests`
Opzionale. Un elenco di condizioni e i casi di test corrispondenti che vengono eseguiti quando ogni condizione è soddisfatta. Ogni condizione può avere più casi di test; tuttavia, è possibile assegnare un determinato test case a una sola condizione.
Per impostazione predefinita, IDT esegue qualsiasi test case che non è assegnato a una condizione in questo elenco. Se non specificate questa sezione, IDT esegue tutti i gruppi di test nella suite di test.
Ogni elemento dell'`ConditionalTests`elenco include i seguenti parametri:
`Condition`
Un'espressione di contesto che restituisce un valore booleano. Se il valore valutato è vero, IDT esegue i test case specificati nel parametro. `Tests`
`Tests`
L'elenco dei descrittori di test.
Ogni descrittore di test utilizza l'ID del gruppo di test e uno o più test case IDs per identificare i singoli test da eseguire da un gruppo di test specifico. Il descrittore di test utilizza il seguente formato:
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
**Example**
**Esempio**
L'esempio seguente utilizza espressioni di contesto generiche che è possibile definire come`Aliases`.
```
ConditionalTests:
- Condition: "{{$aliases.Condition1}}"
Tests:
- GroupId: A
- GroupId: B
- Condition: "{{$aliases.Condition2}}"
Tests:
- GroupId: D
- Condition: "{{$aliases.Condition1}} || {{$aliases.Condition2}}"
Tests:
- GroupId: C
```
In base alle condizioni definite, IDT seleziona i gruppi di test come segue:
+ Se `Condition1` è vero, IDT esegue i test nei gruppi di test A, B e C.
+ Se `Condition2` è vero, IDT esegue i test nei gruppi di test C e D.
`Order`
Opzionale. L'ordine in cui eseguire i test. L'ordine dei test viene specificato a livello di gruppo di test. Se non specificate questa sezione, IDT esegue tutti i gruppi di test applicabili in ordine casuale. Il valore di `Order` è un elenco di elenchi di descrittori di gruppo. Qualsiasi gruppo di test in `Order` cui non fai parte dell'elenco può essere eseguito in parallelo con qualsiasi altro gruppo di test elencato.
Ogni elenco di descrittori di gruppo contiene uno o più descrittori di gruppo e identifica l'ordine in cui eseguire i gruppi specificati in ciascun descrittore. È possibile utilizzare i seguenti formati per definire i singoli descrittori di gruppo:
+ `group-id`— L'ID del gruppo di un gruppo di test esistente.
+ `[group-id, group-id]`—Elenco di gruppi di test che possono essere eseguiti in qualsiasi ordine l'uno rispetto all'altro.
+ `"*"`—Wild card. Equivale all'elenco di tutti i gruppi di test che non sono già specificati nell'elenco corrente dei descrittori di gruppo.
Il valore per `Order` deve inoltre soddisfare i seguenti requisiti:
+ Il gruppo IDs di test specificato in un descrittore di gruppo deve esistere nella suite di test.
+ Ogni elenco di descrittori di gruppo deve includere almeno un gruppo di test.
+ Ogni elenco di descrittori di gruppo deve contenere un gruppo univoco. IDs Non è possibile ripetere un ID di gruppo di test all'interno di singoli descrittori di gruppo.
+ Un elenco di descrittori di gruppo può avere al massimo un descrittore di gruppo con caratteri jolly. Il descrittore di gruppo con caratteri jolly deve essere il primo o l'ultimo elemento dell'elenco.
**Example**
**Esempio**
Per una suite di test che contiene i gruppi di test A, B, C, D ed E, il seguente elenco di esempi mostra diversi modi per specificare che IDT deve prima eseguire il gruppo di test A, quindi eseguire il gruppo di test B e quindi eseguire i gruppi di test C, D ed E in qualsiasi ordine.
+
```
Order:
- - A
- B
- [C, D, E]
```
+
```
Order:
- - A
- B
- "*"
```
+
```
Order:
- - A
- B
- - B
- C
- - B
- D
- - B
- E
```
`Features`
Opzionale. L'elenco delle funzionalità del prodotto che desideri che IDT aggiunga al `awsiotdevicetester_report.xml` file. Se non specifichi questa sezione, IDT non aggiungerà alcuna funzionalità del prodotto al rapporto.
Una funzionalità del prodotto è costituita da informazioni definite dall'utente su criteri specifici che un dispositivo potrebbe soddisfare. Ad esempio, la funzionalità del prodotto MQTT può indicare che il dispositivo pubblica correttamente i messaggi MQTT. In`awsiotdevicetester_report.xml`, le funzionalità del prodotto sono impostate come o come un valore personalizzato definito dall'utente `supported``not-supported`, in base al superamento dei test specificati.
Ogni elemento dell'`Features`elenco è composto dai seguenti parametri:
`Name`
Il nome della funzionalità.
`Value`
Opzionale. Il valore personalizzato che desideri utilizzare nel rapporto anziché`supported`. Se questo valore non è specificato, l'IDT basato su imposta il valore della funzionalità su `supported` o in `not-supported` base ai risultati del test. Se testate la stessa funzionalità con condizioni diverse, potete utilizzare un valore personalizzato per ogni istanza di quella funzionalità nell'`Features`elenco e IDT concatena i valori delle caratteristiche per le condizioni supportate. Per ulteriori informazioni, consultare la pagina
`Condition`
Un'espressione di contesto che restituisce un valore booleano. Se il valore valutato è vero, IDT aggiunge la funzionalità al rapporto di test dopo aver terminato l'esecuzione della suite di test. Se il valore valutato è falso, il test non è incluso nel rapporto.
`Tests`
Opzionale. L'elenco dei descrittori dei test. Tutti i test specificati in questo elenco devono essere superati affinché la funzionalità sia supportata.
Ogni descrittore di test in questo elenco utilizza l'ID del gruppo di test e uno o più test case IDs per identificare i singoli test da eseguire da un gruppo di test specifico. Il descrittore di test utilizza il seguente formato:
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
È necessario specificare una `Tests` o `OneOfTests` per ciascuna funzionalità nell'`Features`elenco.
`OneOfTests`
Opzionale. L'elenco dei descrittori dei test. Almeno uno dei test specificati in questo elenco deve essere superato affinché la funzionalità sia supportata.
Ogni descrittore di test in questo elenco utilizza l'ID del gruppo di test e uno o più test case IDs per identificare i singoli test da eseguire da un gruppo di test specifico. Il descrittore di test utilizza il seguente formato:
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
È necessario specificare una `Tests` o `OneOfTests` per ciascuna funzionalità nell'`Features`elenco.
`IsRequired`
Il valore booleano che definisce se la funzionalità è richiesta nel rapporto di test. Il valore predefinito è `false`.
## Contesto dell'orchestratore di test
Il contesto di test orchestrator è un documento JSON di sola lettura che contiene dati disponibili per il test orchestrator durante l'esecuzione. Il contesto del test orchestrator è accessibile solo dal test orchestrator e contiene informazioni che determinano il flusso di test. Ad esempio, è possibile utilizzare le informazioni configurate dai test runner nel `userdata.json` file per determinare se è necessario eseguire un test specifico.
Il contesto del test orchestrator utilizza il seguente formato:
```
{
"pool": {
},
"userData": {
},
"config": {
}
}
```
`pool`
Informazioni sul pool di dispositivi selezionato per l'esecuzione del test. Per un pool di dispositivi selezionato, queste informazioni vengono recuperate dal corrispondente elemento dell'array del pool di dispositivi di primo livello definito nel `device.json` file.
`userData`
Informazioni contenute nel file. `userdata.json`
`config`
Informazioni contenute nel `config.json` fascicolo.
È possibile interrogare il contesto utilizzando la JSONPath notazione. La sintassi per le JSONPath interrogazioni nelle definizioni di stato è. `{{query}}` Quando accedi ai dati dal contesto di test orchestrator, assicurati che ogni valore restituisca una stringa, un numero o un valore booleano.
Per ulteriori informazioni sull'utilizzo della JSONPath notazione per accedere ai dati dal contesto, consulta. [Usa il contesto IDT](idt-context.md)
# Configurare la macchina a stati IDT
**Importante**
A partire da IDT v4.5.2, questa macchina a stati è obsoleta. Ti consigliamo vivamente di utilizzare il nuovo orchestrator di test. Per ulteriori informazioni, consulta [Configura l'orchestrator di test IDT](idt-test-orchestrator.md).
Una macchina a stati è un costrutto che controlla il flusso di esecuzione della suite di test. Determina lo stato iniziale di una suite di test, gestisce le transizioni di stato in base a regole definite dall'utente e continua la transizione attraverso tali stati fino a raggiungere lo stato finale.
Se la vostra suite di test non include una macchina a stati definita dall'utente, IDT genererà una macchina a stati per voi. La macchina a stati predefinita svolge le seguenti funzioni:
+ Fornisce ai test runner la possibilità di selezionare ed eseguire gruppi di test specifici, anziché l'intera suite di test.
+ Se non sono selezionati gruppi di test specifici, esegue ogni gruppo di test nella suite di test in ordine casuale.
+ Genera report e stampa un riepilogo della console che mostra i risultati dei test per ogni gruppo di test e test case.
La macchina a stati per una suite di test IDT deve soddisfare i seguenti criteri:
+ Ogni stato corrisponde a un'azione che IDT deve intraprendere, ad esempio eseguire un gruppo di test o produrre un file di report.
+ La transizione a uno stato esegue l'azione associata allo stato.
+ Ogni stato definisce la regola di transizione per lo stato successivo.
+ Lo stato finale deve essere `Succeed` o`Fail`.
## Formato macchina a stati
È possibile utilizzare il seguente modello per configurare il proprio `/suite/state_machine.json` file:
```
{
"Comment": "",
"StartAt": "",
"States": {
"": {
"Type": "",
// Additional state configuration
}
// Required states
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`Comment`**
Una descrizione della macchina a stati.
**`StartAt`**
Il nome dello stato in cui IDT inizia a eseguire la suite di test. Il valore di `StartAt` deve essere impostato su uno degli stati elencati nell'`States`oggetto.
**`States`**
Un oggetto che associa i nomi di stato definiti dall'utente a stati IDT validi. Ogni stato. *state-name*l'oggetto contiene la definizione di uno stato valido mappato su. *state-name*
L'`States`oggetto deve includere gli `Fail` stati `Succeed` e. Per informazioni sugli stati validi, vedere[Stati e definizioni di stato validi](#valid-states).
## Stati e definizioni di stato validi
Questa sezione descrive le definizioni di stato di tutti gli stati validi che possono essere utilizzati nella macchina a stati IDT. Alcuni dei seguenti stati supportano configurazioni a livello di test case. Tuttavia, si consiglia di configurare le regole di transizione degli stati a livello di gruppo di test anziché a livello di test case, a meno che non sia assolutamente necessario.
**Topics**
+ [RunTask](#state-runtask)
+ [Choice](#state-choice)
+ [Parallel](#state-parallel)
+ [AddProductFeatures](#state-addproductfeatures)
+ [Report](#state-report)
+ [LogMessage](#state-logmessage)
+ [SelectGroup](#state-selectgroup)
+ [Fail](#state-fail)
+ [Succeed](#state-succeed)
### RunTask
Lo `RunTask` stato esegue casi di test da un gruppo di test definito nella suite di test.
```
{
"Type": "RunTask",
"Next": "",
"TestGroup": "",
"TestCases": [
""
],
"ResultVar": ""
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`Next`**
Il nome dello stato a cui passare dopo l'esecuzione delle azioni nello stato corrente.
**`TestGroup`**
Opzionale. L'ID del gruppo di test da eseguire. Se questo valore non è specificato, IDT esegue il gruppo di test selezionato dal test runner.
**`TestCases`**
Opzionale. Una serie di test case del gruppo IDs specificato in. `TestGroup` In base ai valori di `TestGroup` and`TestCases`, IDT determina il comportamento di esecuzione del test nel modo seguente:
+ Quando `TestCases` vengono specificati entrambi gli `TestGroup` E, IDT esegue i casi di test specificati dal gruppo di test.
+ Quando `TestCases` sono specificati ma non `TestGroup` sono specificati, IDT esegue i casi di test specificati.
+ Quando `TestGroup` è specificato, ma non `TestCases` è specificato, IDT esegue tutti i casi di test all'interno del gruppo di test specificato.
+ Quando nessuno dei due `TestGroup` `TestCases` è specificato, IDT esegue tutti i casi di test dal gruppo di test selezionato dal test runner dalla CLI IDT. Per abilitare la selezione di gruppo per i test runner, è necessario includere entrambi `RunTask` gli stati nel file. `Choice` `statemachine.json` Per un esempio di come funziona, vedi [Example state machine: Esegui gruppi di test selezionati dall'utente](#allow-specific-groups).
Per ulteriori informazioni sull'abilitazione dei comandi CLI IDT per i test runner, vedere. [Abilita i comandi CLI IDT](test-executables.md#idt-cli-coop)
**`ResultVar`**
Il nome della variabile di contesto da impostare con i risultati dell'esecuzione del test. Non specificate questo valore se non avete specificato un valore per`TestGroup`. IDT imposta il valore della variabile definita in `true` o in `false` base `ResultVar` a quanto segue:
+ Se il nome della variabile è nel formato`text_text_passed`, il valore viene impostato in base al fatto che tutti i test del primo gruppo di test siano stati superati o ignorati.
+ In tutti gli altri casi, il valore è impostato in base al fatto che tutti i test di tutti i gruppi di test siano stati superati o saltati.
In genere, si utilizza `RunTask` lo stato per specificare un ID del gruppo di test senza specificare il singolo test case IDs, in modo che IDT esegua tutti i casi di test nel gruppo di test specificato. Tutti i casi di test eseguiti da questo stato vengono eseguiti in parallelo, in ordine casuale. Tuttavia, se tutti i casi di test richiedono l'esecuzione di un dispositivo ed è disponibile un solo dispositivo, i test case verranno invece eseguiti in sequenza.
**Gestione errori**
Se uno dei gruppi di test o dei test case IDs specificati non è valido, questo stato genera l'errore di `RunTaskError` esecuzione. Se lo stato rileva un errore di esecuzione, imposta anche la `hasExecutionError` variabile nel contesto della macchina a stati su. `true`
### Choice
Lo `Choice` stato consente di impostare dinamicamente lo stato successivo a cui passare in base a condizioni definite dall'utente.
```
{
"Type": "Choice",
"Default": "",
"FallthroughOnError": true | false,
"Choices": [
{
"Expression": "",
"Next": ""
}
]
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`Default`**
Lo stato predefinito a cui passare se nessuna delle espressioni definite in `Choices` può essere valutata. `true`
**`FallthroughOnError`**
Opzionale. Speciifica il comportamento quando lo stato rileva un errore nella valutazione delle espressioni. Imposta su `true` se desideri saltare un'espressione se la valutazione genera un errore. Se nessuna espressione corrisponde, la macchina a stati passa allo `Default` stato. Se il `FallthroughOnError` valore non è specificato, il valore predefinito è. `false`
**`Choices`**
Un array di espressioni e stati per determinare a quale stato passare dopo aver eseguito le azioni nello stato corrente.
**`Choices.Expression`**
Una stringa di espressione che restituisce un valore booleano. Se l'espressione restituisce a`true`, la macchina a stati passa allo stato definito in. `Choices.Next` Le stringhe di espressione recuperano i valori dal contesto della macchina a stati e quindi eseguono operazioni su di essi per ottenere un valore booleano. Per informazioni sull'accesso al contesto della macchina a stati, vedere. [Contesto della macchina a stati](#state-machine-context)
**`Choices.Next`**
Il nome dello stato a cui passare se l'espressione definita in `Choices.Expression` restituisce. `true`
**Gestione errori**
Lo `Choice` stato può richiedere la gestione degli errori nei seguenti casi:
+ Alcune variabili nelle espressioni di scelta non esistono nel contesto della macchina a stati.
+ Il risultato di un'espressione non è un valore booleano.
+ Il risultato di una ricerca JSON non è una stringa, un numero o un valore booleano.
Non è possibile utilizzare un `Catch` blocco per gestire gli errori in questo stato. Se si desidera interrompere l'esecuzione della macchina a stati quando rileva un errore, è necessario impostare su`FallthroughOnError`. `false` Tuttavia, ti consigliamo di impostare e`true`, `FallthroughOnError` a seconda del caso d'uso, di eseguire una delle seguenti operazioni:
+ Se in alcuni casi si prevede che una variabile a cui stai accedendo non esista, utilizza il valore `Default` e i `Choices` blocchi aggiuntivi per specificare lo stato successivo.
+ Se una variabile a cui stai accedendo deve sempre esistere, imposta lo `Default` stato su`Fail`.
### Parallel
Lo `Parallel` stato consente di definire ed eseguire nuove macchine a stati in parallelo tra loro.
```
{
"Type": "Parallel",
"Next": "",
"Branches": [
]
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`Next`**
Il nome dello stato a cui passare dopo l'esecuzione delle azioni nello stato corrente.
**`Branches`**
Una serie di definizioni di macchine a stati da eseguire. Ogni definizione di macchina a stati deve contenere `StartAt` `Succeed` i propri `Fail` stati. Le definizioni delle macchine a stati in questo array non possono fare riferimento a stati al di fuori della propria definizione.
Poiché ogni macchina a stati della filiale condivide lo stesso contesto della macchina a stati, l'impostazione delle variabili in un ramo e la successiva lettura di tali variabili da un altro ramo potrebbe causare un comportamento imprevisto.
Lo `Parallel` stato passa allo stato successivo solo dopo aver eseguito tutte le macchine a stati della filiale. Ogni stato che richiede un dispositivo aspetterà di funzionare finché il dispositivo non sarà disponibile. Se sono disponibili più dispositivi, questo stato esegue casi di test da più gruppi in parallelo. Se non sono disponibili dispositivi sufficienti, i test case verranno eseguiti in sequenza. Poiché i casi di test vengono eseguiti in ordine casuale quando vengono eseguiti in parallelo, è possibile utilizzare dispositivi diversi per eseguire i test dello stesso gruppo di test.
**Gestione errori**
Assicurati che sia la macchina a stati della filiale che la macchina a stati principale passino allo `Fail` stato per gestire gli errori di esecuzione.
Poiché le macchine a stati delle filiali non trasmettono errori di esecuzione alla macchina a stato principale, non è possibile utilizzare un `Catch` blocco per gestire gli errori di esecuzione nelle macchine a stato delle filiali. Utilizzate invece il `hasExecutionErrors` valore nel contesto della macchina a stati condivisa. Per un esempio di come funziona, vedi[Esempio di macchina a stati: esecuzione di due gruppi di test in parallelo](#run-in-parallel).
### AddProductFeatures
Lo `AddProductFeatures` stato consente di aggiungere funzionalità del prodotto al `awsiotdevicetester_report.xml` file generato da IDT.
Una funzionalità del prodotto è costituita da informazioni definite dall'utente su criteri specifici che un dispositivo potrebbe soddisfare. Ad esempio, la funzionalità del `MQTT` prodotto può indicare che il dispositivo pubblica correttamente i messaggi MQTT. Nel rapporto, le caratteristiche del prodotto sono impostate come o come valore personalizzato `supported``not-supported`, in base al superamento dei test specificati.
**Nota**
Lo `AddProductFeatures` stato non genera report da solo. Questo stato deve passare allo [`Report`stato](#state-report) per generare report.
```
{
"Type": "Parallel",
"Next": "",
"Features": [
{
"Feature": "",
"Groups": [
""
],
"OneOfGroups": [
""
],
"TestCases": [
""
],
"IsRequired": true | false,
"ExecutionMethods": [
""
]
}
]
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`Next`**
Il nome dello stato a cui passare dopo l'esecuzione delle azioni nello stato corrente.
**`Features`**
Una serie di caratteristiche del prodotto da mostrare nel `awsiotdevicetester_report.xml` file.
**`Feature`**
Il nome della funzionalità
**`FeatureValue`**
Opzionale. Il valore personalizzato da utilizzare nel rapporto anziché`supported`. Se questo valore non è specificato, in base ai risultati del test, il valore della funzionalità viene impostato su `supported` o`not-supported`.
Se utilizzate un valore personalizzato per`FeatureValue`, potete testare la stessa funzionalità con condizioni diverse e IDT concatena i valori delle caratteristiche per le condizioni supportate. Ad esempio, il seguente estratto mostra la funzionalità con due valori di `MyFeature` funzionalità separati:
```
...
{
"Feature": "MyFeature",
"FeatureValue": "first-feature-supported",
"Groups": ["first-feature-group"]
},
{
"Feature": "MyFeature",
"FeatureValue": "second-feature-supported",
"Groups": ["second-feature-group"]
},
...
```
Se entrambi i gruppi di test superano il test, il valore della funzionalità viene impostato su. `first-feature-supported, second-feature-supported`
**`Groups`**
Opzionale. Una serie di gruppi di test IDs. Tutti i test all'interno di ogni gruppo di test specificato devono essere superati affinché la funzionalità sia supportata.
**`OneOfGroups`**
Opzionale. Una serie di gruppi di test IDs. Tutti i test all'interno di almeno uno dei gruppi di test specificati devono essere superati affinché la funzionalità sia supportata.
**`TestCases`**
Opzionale. Una serie di test case IDs. Se si specifica questo valore, si applica quanto segue:
+ Tutti i casi di test specificati devono essere superati affinché la funzionalità sia supportata.
+ `Groups`deve contenere un solo ID del gruppo di test.
+ `OneOfGroups`non deve essere specificato.
**`IsRequired`**
Opzionale. Imposta `false` su per contrassegnare questa funzionalità come opzionale nel rapporto. Il valore predefinito è `true`.
**`ExecutionMethods`**
Opzionale. Una serie di metodi di esecuzione che corrispondono al `protocol` valore specificato nel `device.json` file. Se viene specificato questo valore, i test runner devono specificare un `protocol` valore che corrisponda a uno dei valori di questo array per includere la funzionalità nel report. Se questo valore non è specificato, la funzionalità verrà sempre inclusa nel rapporto.
Per utilizzare lo `AddProductFeatures` stato, è necessario impostare il valore di `ResultVar` in the `RunTask` state su uno dei seguenti valori:
+ Se hai specificato un singolo test case IDs, imposta `ResultVar` su`group-id_test-id_passed`.
+ Se non hai specificato un singolo test case IDs, imposta `ResultVar` su`group-id_passed`.
Lo `AddProductFeatures` stato verifica i risultati dei test nel modo seguente:
+ Se non è stato specificato alcun test case IDs, il risultato per ogni gruppo di test viene determinato dal valore della `group-id_passed` variabile nel contesto della macchina a stati.
+ Se hai specificato il test case IDs, il risultato di ciascuno dei test viene determinato dal valore della `group-id_test-id_passed` variabile nel contesto della macchina a stati.
**Gestione errori**
Se un ID di gruppo fornito in questo stato non è un ID di gruppo valido, questo stato genera l'errore di `AddProductFeaturesError` esecuzione. Se lo stato rileva un errore di esecuzione, imposta anche la `hasExecutionErrors` variabile nel contesto della macchina a stati su. `true`
### Report
Lo `Report` stato genera i file `suite-name_Report.xml` and`awsiotdevicetester_report.xml`. Questo stato trasmette inoltre il report alla console.
```
{
"Type": "Report",
"Next": ""
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`Next`**
Il nome dello stato a cui passare dopo l'esecuzione delle azioni nello stato corrente.
Dovresti sempre passare `Report` allo stato verso la fine del flusso di esecuzione del test in modo che i test runner possano visualizzare i risultati del test. In genere, lo stato successivo a questo è`Succeed`.
**Gestione errori**
Se questo stato riscontra problemi con la generazione dei report, genera l'errore di `ReportError` esecuzione.
### LogMessage
Lo `LogMessage` stato genera il `test_manager.log` file e trasmette il messaggio di registro alla console.
```
{
"Type": "LogMessage",
"Next": ""
"Level": "info | warn | error"
"Message": ""
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`Next`**
Il nome dello stato a cui passare dopo l'esecuzione delle azioni nello stato corrente.
**`Level`**
Il livello di errore al quale creare il messaggio di registro. Se si specifica un livello non valido, questo stato genera un messaggio di errore e lo elimina.
**`Message`**
Il messaggio da registrare.
### SelectGroup
Lo `SelectGroup` stato aggiorna il contesto della macchina a stati per indicare quali gruppi sono selezionati. I valori impostati da questo stato vengono utilizzati da tutti `Choice` gli stati successivi.
```
{
"Type": "SelectGroup",
"Next": ""
"TestGroups": [
"
]
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`Next`**
Il nome dello stato a cui passare dopo l'esecuzione delle azioni nello stato corrente.
**`TestGroups`**
Una serie di gruppi di test che verranno contrassegnati come selezionati. Per ogni ID del gruppo di test in questo array, la `group-id_selected` variabile è impostata su `true` nel contesto. Assicuratevi di fornire un gruppo di test valido IDs perché IDT non verifica l'esistenza dei gruppi specificati.
### Fail
Lo `Fail` stato indica che la macchina a stati non è stata eseguita correttamente. Si tratta di uno stato finale per la macchina a stati e ogni definizione di macchina a stati deve includere questo stato.
```
{
"Type": "Fail"
}
```
### Succeed
Lo `Succeed` stato indica che la macchina a stati è stata eseguita correttamente. Questo è lo stato finale della macchina a stati e ogni definizione di macchina a stati deve includere questo stato.
```
{
"Type": "Succeed"
}
```
## Contesto della macchina a stati
Il contesto della macchina a stati è un documento JSON di sola lettura che contiene dati disponibili per la macchina a stati durante l'esecuzione. Il contesto della macchina a stati è accessibile solo dalla macchina a stati e contiene informazioni che determinano il flusso di test. Ad esempio, è possibile utilizzare le informazioni configurate dai test runner nel `userdata.json` file per determinare se è necessario eseguire un test specifico.
Il contesto della macchina a stati utilizza il seguente formato:
```
{
"pool": {
},
"userData": {
},
"config": {
},
"suiteFailed": true | false,
"specificTestGroups": [
""
],
"specificTestCases": [
""
],
"hasExecutionErrors": true
}
```
**`pool`**
Informazioni sul pool di dispositivi selezionato per l'esecuzione del test. Per un pool di dispositivi selezionato, queste informazioni vengono recuperate dal corrispondente elemento dell'array del pool di dispositivi di primo livello definito nel `device.json` file.
**`userData`**
Informazioni contenute nel file. `userdata.json`
**`config`**
Le informazioni bloccano il `config.json` file.
**`suiteFailed`**
Il valore è impostato su `false` quando viene avviata la macchina a stati. Se un gruppo di test fallisce in uno `RunTask` stato, questo valore viene impostato `true` per la durata residua dell'esecuzione della macchina a stati.
**`specificTestGroups`**
Se il test runner seleziona gruppi di test specifici da eseguire anziché l'intera suite di test, questa chiave viene creata e contiene l'elenco dei gruppi di test specifici. IDs
**`specificTestCases`**
Se il test runner seleziona casi di test specifici da eseguire anziché l'intera suite di test, questa chiave viene creata e contiene l'elenco di casi di test specifici. IDs
**`hasExecutionErrors`**
Non esce all'avvio della macchina a stati. Se uno stato rileva errori di esecuzione, questa variabile viene creata e impostata `true` per la durata residua dell'esecuzione della macchina a stati.
È possibile interrogare il contesto utilizzando JSONPath la notazione. La sintassi per le JSONPath interrogazioni nelle definizioni di stato è. `{{$.query}}` È possibile utilizzare JSONPath le query come stringhe segnaposto in alcuni stati. IDT sostituisce le stringhe segnaposto con il valore della query valutata dal contesto. JSONPath È possibile utilizzare i segnaposto per i seguenti valori:
+ Il `TestCases` valore in `RunTask` stati.
+ Lo `Choice` stato `Expression` del valore.
Quando accedete ai dati dal contesto della macchina a stati, assicuratevi che siano soddisfatte le seguenti condizioni:
+ I percorsi JSON devono iniziare con `$.`
+ Ogni valore deve restituire una stringa, un numero o un valore booleano.
Per ulteriori informazioni sull'utilizzo della JSONPath notazione per accedere ai dati dal contesto, vedere. [Usa il contesto IDT](idt-context.md)
## Errori di esecuzione
Gli errori di esecuzione sono errori nella definizione della macchina a stati che la macchina a stati incontra durante l'esecuzione di uno stato. IDT registra le informazioni su ogni errore nel `test_manager.log` file e trasmette il messaggio di registro alla console.
È possibile utilizzare i seguenti metodi per gestire gli errori di esecuzione:
+ Aggiungere un [`Catch`blocco](#catch) nella definizione dello stato.
+ Controlla il valore del [`hasExecutionErrors`valore](#context) nel contesto della macchina a stati.
### Cattura
Per utilizzarlo`Catch`, aggiungi quanto segue alla definizione dello stato:
```
"Catch": [
{
"ErrorEquals": [
""
]
"Next": ""
}
]
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`Catch.ErrorEquals`**
Una serie di tipi di errore da catturare. Se un errore di esecuzione corrisponde a uno dei valori specificati, la macchina a stati passa allo stato specificato in`Catch.Next`. Consultate la definizione di ogni stato per informazioni sul tipo di errore che produce.
**`Catch.Next`**
Lo stato successivo a cui passare se lo stato corrente rileva un errore di esecuzione che corrisponde a uno dei valori specificati in. `Catch.ErrorEquals`
I blocchi Catch vengono gestiti in sequenza fino a quando non ne corrisponde uno. Se gli errori no corrispondono a quelli elencati nei blocchi Catch, le macchine a stati continuano a essere eseguite. Poiché gli errori di esecuzione sono il risultato di definizioni di stato errate, si consiglia di passare allo stato Fail quando uno stato rileva un errore di esecuzione.
### hasExecutionError
Quando alcuni stati riscontrano errori di esecuzione, oltre a emettere l'errore, impostano anche il `hasExecutionError` valore su `true` nel contesto della macchina a stati. È possibile utilizzare questo valore per rilevare quando si verifica un errore e quindi utilizzare uno `Choice` stato per trasferire la macchina a stati allo `Fail` stato.
Questo metodo presenta le seguenti caratteristiche.
+ La macchina a stati non si avvia con alcun valore assegnato a `hasExecutionError` e questo valore non è disponibile finché non viene impostato da uno stato particolare. Ciò significa che è necessario impostare in modo esplicito il `FallthroughOnError` to `false` per gli `Choice` stati che accedono a questo valore per evitare che la macchina a stati si fermi se non si verificano errori di esecuzione.
+ Una volta impostato su`true`, non `hasExecutionError` viene mai impostato su false o rimosso dal contesto. Ciò significa che questo valore è utile solo la prima volta che viene impostato su e per tutti gli stati successivi non fornisce un valore significativo. `true`
+ Il `hasExecutionError` valore è condiviso con tutte le macchine a stati delle filiali presenti `Parallel` nello stato, il che può generare risultati imprevisti a seconda dell'ordine in cui viene effettuato l'accesso.
A causa di queste caratteristiche, non è consigliabile utilizzare questo metodo se è possibile utilizzare invece un blocco Catch.
## Esempi di macchine a stati
Questa sezione fornisce alcuni esempi di configurazioni di macchine a stati.
**Topics**
+ [Esempio di macchina a stati: Esegui un singolo gruppo di test](#single-test-group)
+ [Esempio di macchina a stati: esegue gruppi di test selezionati dall'utente](#allow-specific-groups)
+ [Esempio di macchina a stati: esegui un singolo gruppo di test con le caratteristiche del prodotto](#run-with-product-features)
+ [Esempio di macchina a stati: esecuzione di due gruppi di test in parallelo](#run-in-parallel)
### Esempio di macchina a stati: Esegui un singolo gruppo di test
Questa macchina a stati:
+ Esegue il gruppo di test con id`GroupA`, che deve essere presente nella suite in un `group.json` file.
+ Verifica la presenza di errori di esecuzione e le `Fail` eventuali transizioni rilevate.
+ Genera un rapporto e passa a `Succeed` se non ci sono errori e `Fail` altro.
```
{
"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"
}
}
}
```
### Esempio di macchina a stati: esegue gruppi di test selezionati dall'utente
Questa macchina a stati:
+ Verifica se il test runner ha selezionato gruppi di test specifici. La macchina a stati non verifica la presenza di casi di test specifici perché i test runner non possono selezionare casi di test senza selezionare anche un gruppo di test.
+ Se sono selezionati gruppi di test:
+ Esegue i casi di test all'interno dei gruppi di test selezionati. A tale scopo, la macchina a stati non specifica esplicitamente alcun gruppo di test o caso di test nello `RunTask` stato.
+ Genera un rapporto dopo aver eseguito tutti i test e le uscite.
+ Se i gruppi di test non sono selezionati:
+ Esegue i test nel gruppo di test`GroupA`.
+ Genera report ed uscite.
```
{
"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"
}
}
}
```
### Esempio di macchina a stati: esegui un singolo gruppo di test con le caratteristiche del prodotto
Questa macchina a stati:
+ Esegue il gruppo di test`GroupA`.
+ Verifica la presenza di errori di esecuzione e le `Fail` eventuali transizioni rilevate.
+ Aggiunge la `FeatureThatDependsOnGroupA` funzionalità al `awsiotdevicetester_report.xml` file:
+ Se ha `GroupA` esito positivo, la funzionalità è impostata su`supported`.
+ La funzionalità non è contrassegnata come opzionale nel rapporto.
+ Genera un rapporto e passa a `Succeed` se non ci sono errori e altro `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"
}
}
}
```
### Esempio di macchina a stati: esecuzione di due gruppi di test in parallelo
Questa macchina a stati:
+ Esegue i gruppi `GroupA` e `GroupB` test in parallelo. Le `ResultVar` variabili memorizzate nel contesto dagli `RunTask` stati nelle macchine a stati della filiale di sono disponibili per lo `AddProductFeatures` stato.
+ Verifica la presenza di errori di esecuzione e le `Fail` eventuali transizioni rilevate. Questa macchina a stati non utilizza un `Catch` blocco perché tale metodo non rileva errori di esecuzione nelle macchine a stati delle filiali.
+ Aggiunge funzionalità al `awsiotdevicetester_report.xml` file in base ai gruppi che passano
+ Se ha `GroupA` esito positivo, la funzionalità è impostata su`supported`.
+ La funzionalità non è contrassegnata come opzionale nel rapporto.
+ Genera un rapporto e passa a `Succeed` se non ci sono errori e altro `Fail`
Se due dispositivi sono configurati nel pool di dispositivi, entrambi `GroupA` `GroupB` possono funzionare contemporaneamente. Tuttavia, se uno `GroupA` o `GroupB` più test sono inclusi, entrambi i dispositivi possono essere assegnati a tali test. Se è configurato un solo dispositivo, i gruppi di test verranno eseguiti in sequenza.
```
{
"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"
}
}
}
```
# Crea un file eseguibile per il test case IDT
È possibile creare e inserire il file eseguibile del test case in una cartella della suite di test nei seguenti modi:
+ Per le suite di test che utilizzano argomenti o variabili di ambiente dei `test.json` file per determinare quali test eseguire, è possibile creare un singolo test case eseguibile per l'intera suite di test o un eseguibile di test per ogni gruppo di test nella suite di test.
+ Per una suite di test in cui desideri eseguire test specifici in base a comandi specifici, crei un eseguibile di test case per ogni test case della suite di test.
In qualità di scrittore di test, puoi determinare quale approccio è appropriato per il tuo caso d'uso e strutturare di conseguenza il tuo eseguibile del test case. Assicurati di fornire il percorso eseguibile corretto del test case in ogni `test.json` file e che l'eseguibile specificato funzioni correttamente.
Quando tutti i dispositivi sono pronti per l'esecuzione di un test case, IDT legge i seguenti file:
+ Il test case `test.json` per il test case selezionato determina i processi da avviare e le variabili di ambiente da impostare.
+ La suite `suite.json` for the test determina le variabili di ambiente da impostare.
IDT avvia il processo eseguibile di test richiesto in base ai comandi e agli argomenti specificati nel `test.json` file e passa le variabili di ambiente richieste al processo.
## Usa l'IDT Client SDK
Il client IDT ti SDKs consente di semplificare il modo in cui scrivi la logica di test nell'eseguibile di test con comandi API che puoi utilizzare per interagire con IDT e i tuoi dispositivi sottoposti a test. IDT attualmente fornisce quanto segue: SDKs
+ SDK del client IDT per Python
+ SDK del client IDT per Go
+ SDK del client IDT per Java
Questi si SDKs trovano nella cartella. `/sdks` Quando crei un nuovo eseguibile del test case, devi copiare l'SDK che desideri utilizzare nella cartella che contiene l'eseguibile del test case e fare riferimento all'SDK nel codice. Questa sezione fornisce una breve descrizione dei comandi API disponibili che puoi utilizzare negli eseguibili del test case.
**Topics**
+ [Interazione con il dispositivo](#api-device-interaction)
+ [Interazione IDT](#api-idt-interaction)
+ [Interazione con l'host](#api-host-interaction)
### Interazione con il dispositivo
I seguenti comandi consentono di comunicare con il dispositivo sottoposto a test senza dover implementare ulteriori funzioni di interazione con il dispositivo e di gestione della connettività.
**`ExecuteOnDevice`**
Consente alle suite di test di eseguire comandi shell su un dispositivo che supporta connessioni shell SSH o Docker.
**`CopyToDevice`**
Consente alle suite di test di copiare un file locale dalla macchina host che esegue IDT in una posizione specificata su un dispositivo che supporta connessioni shell SSH o Docker.
**`ReadFromDevice`**
Consente alle suite di test di leggere dalla porta seriale dei dispositivi che supportano le connessioni UART.
**Nota**
Poiché IDT non gestisce le connessioni dirette ai dispositivi effettuate utilizzando le informazioni di accesso ai dispositivi provenienti dal contesto, consigliamo di utilizzare questi comandi API di interazione con i dispositivi negli eseguibili dei test case. Tuttavia, se questi comandi non soddisfano i requisiti del test case, potete recuperare le informazioni di accesso al dispositivo dal contesto IDT e utilizzarle per stabilire una connessione diretta al dispositivo dalla suite di test.
Per stabilire una connessione diretta, recuperate le informazioni nei campi `device.connectivity` e nei `resource.devices.connectivity` campi per il dispositivo in esame e per i dispositivi di risorse, rispettivamente. Per ulteriori informazioni sull'utilizzo del contesto IDT, vedere. [Usa il contesto IDT](idt-context.md)
### Interazione IDT
I seguenti comandi consentono alle suite di test di comunicare con IDT.
**`PollForNotifications`**
Consente alle suite di test di verificare la presenza di notifiche da IDT.
**`GetContextValue ` e `GetContextString`**
Consente alle suite di test di recuperare valori dal contesto IDT. Per ulteriori informazioni, consulta [Usa il contesto IDT](idt-context.md).
**`SendResult`**
Consente alle suite di test di riportare i risultati dei test case a IDT. Questo comando deve essere chiamato alla fine di ogni test case in una suite di test.
### Interazione con l'host
Il comando seguente consente alle suite di test di comunicare con la macchina host.
**`PollForNotifications`**
Consente alle suite di test di verificare la presenza di notifiche da IDT.
**`GetContextValue` e `GetContextString`**
Consente alle suite di test di recuperare valori dal contesto IDT. Per ulteriori informazioni, consulta [Usa il contesto IDT](idt-context.md).
**`ExecuteOnHost`**
Consente alle suite di test di eseguire comandi sulla macchina locale e consente a IDT di gestire il ciclo di vita eseguibile del test case.
## Abilita i comandi CLI IDT
Il `run-suite` comando IDT CLI fornisce diverse opzioni che consentono a test runner di personalizzare l'esecuzione del test. Per consentire ai test runner di utilizzare queste opzioni per eseguire la suite di test personalizzata, è necessario implementare il supporto per la CLI IDT. Se non si implementa il supporto, i test runner saranno comunque in grado di eseguire i test, ma alcune opzioni della CLI non funzioneranno correttamente. Per fornire un'esperienza cliente ideale, si consiglia di implementare il supporto per i seguenti argomenti per il `run-suite` comando nella CLI IDT:
**`timeout-multiplier`**
Speciifica un valore maggiore di 1,0 che verrà applicato a tutti i timeout durante l'esecuzione dei test.
I test runner possono utilizzare questo argomento per aumentare il timeout per i test case che desiderano eseguire. Quando un test runner specifica questo argomento nel proprio `run-suite` comando, IDT lo utilizza per calcolare il valore della variabile di ambiente IDT\$1TEST\$1TIMEOUT e imposta il campo nel contesto IDT. `config.timeoutMultiplier` Per supportare questo argomento, devi fare quanto segue:
+ Invece di utilizzare direttamente il valore di timeout del `test.json` file, leggete la variabile di ambiente IDT\$1TEST\$1TIMEOUT per ottenere il valore di timeout calcolato correttamente.
+ Recuperate il `config.timeoutMultiplier` valore dal contesto IDT e applicatelo a timeout di esecuzione prolungati.
Per ulteriori informazioni sull'uscita anticipata a causa di eventi di timeout, consulta. [Specificate il comportamento di uscita](#test-exec-exiting)
**`stop-on-first-failure`**
Speciifica che IDT deve interrompere l'esecuzione di tutti i test in caso di errore.
Quando un test runner specifica questo argomento nel proprio `run-suite` comando, IDT interromperà l'esecuzione dei test non appena riscontra un errore. Tuttavia, se i test case vengono eseguiti in parallelo, ciò può portare a risultati imprevisti. Per implementare il supporto, assicuratevi che se IDT rileva questo evento, la logica di test indichi a tutti i casi di test in esecuzione di interrompersi, ripulisca le risorse temporanee e riporti un risultato del test a IDT. Per ulteriori informazioni sull'uscita anticipata in caso di guasto, consulta. [Specificate il comportamento di uscita](#test-exec-exiting)
**`group-id` e `test-id`**
Speciifica che IDT deve eseguire solo i gruppi di test o i casi di test selezionati.
I test runner possono utilizzare questi argomenti con il loro `run-suite` comando per specificare il seguente comportamento di esecuzione del test:
+ Esegui tutti i test all'interno dei gruppi di test specificati.
+ Esegui una selezione di test all'interno di un gruppo di test specificato.
Per supportare questi argomenti, la macchina a stati della suite di test deve includere un set specifico `RunTask` di `Choice` stati nella macchina a stati. Se non utilizzate una macchina a stati personalizzata, la macchina a stati IDT predefinita include gli stati richiesti e non è necessario intraprendere ulteriori azioni. Tuttavia, se utilizzate una macchina a stati personalizzata, usatela [Esempio di macchina a stati: esegue gruppi di test selezionati dall'utente](idt-state-machine.md#allow-specific-groups) come esempio per aggiungere gli stati richiesti nella vostra macchina a stati.
Per ulteriori informazioni sui comandi CLI IDT, vedere. [Esegui il debug ed esegui suite di test personalizzate](run-tests-custom.md)
## Scrivere registri degli eventi
Durante l'esecuzione del test, si inviano dati `stdout` e `stderr` si scrivono registri degli eventi e messaggi di errore nella console. Per informazioni sul formato dei messaggi della console, vedere[Formato dei messaggi della console](idt-review-results-logs.md#idt-console-format).
Quando IDT termina l'esecuzione della suite di test, queste informazioni sono disponibili anche nel `test_manager.log` file che si trova nella `/results//logs` cartella.
È possibile configurare ogni test case in modo che scriva i log dell'esecuzione del test, inclusi i log del dispositivo sottoposto a test, nel `_` file che si trova nella cartella. `/results/execution-id/logs` A tale scopo, recuperate il percorso del file di registro dal contesto IDT con la `testData.logFilePath` query, create un file in quel percorso e scrivete il contenuto desiderato. IDT aggiorna automaticamente il percorso in base al test case in esecuzione. Se si sceglie di non creare il file di registro per un test case, non viene generato alcun file per quel test case.
È inoltre possibile configurare il file eseguibile di testo per creare file di registro aggiuntivi, se necessario, nella `/logs` cartella. Ti consigliamo di specificare prefissi univoci per i nomi dei file di registro in modo che i file non vengano sovrascritti.
## Segnala i risultati a IDT
IDT scrive i risultati dei test nei file `awsiotdevicetester_report.xml` e. `suite-name_report.xml` Questi file di report si trovano in`/results//`. Entrambi i report acquisiscono i risultati dell'esecuzione della suite di test. Per ulteriori informazioni sugli schemi utilizzati da IDT per questi report, vedere [Esamina i risultati e i registri dei test IDT](idt-review-results-logs.md)
Per compilare il contenuto del `suite-name_report.xml` file, è necessario utilizzare il `SendResult` comando per riportare i risultati dei test a IDT prima del termine dell'esecuzione del test. Se IDT non è in grado di individuare i risultati di un test, genera un errore per il test case. Il seguente estratto di Python mostra i comandi per inviare il risultato di un test a IDT:
```
request-variable = SendResultRequest(TestResult(result))
client.send_result(request-variable)
```
Se non riporti i risultati tramite l'API, IDT cerca i risultati dei test nella cartella test artifacts. Il percorso di questa cartella viene memorizzato nel `testData.testArtifactsPath` file nel contesto IDT. In questa cartella, IDT utilizza il primo file XML in ordine alfabetico che individua come risultato del test.
Se la logica del test produce risultati JUnit XML, è possibile scrivere i risultati del test in un file XML nella cartella artifacts per fornire i risultati direttamente a IDT anziché analizzarli e quindi utilizzare l'API per inviarli a IDT.
Se utilizzate questo metodo, assicuratevi che la logica del test riassuma accuratamente i risultati del test e formatti il file dei risultati nello stesso formato del file. `suite-name_report.xml` IDT non esegue alcuna convalida dei dati forniti, con le seguenti eccezioni:
+ IDT ignora tutte le proprietà del tag. `testsuites` Invece, calcola le proprietà del tag in base ai risultati di altri gruppi di test riportati.
+ All'interno `testsuites` deve esistere almeno un `testsuite` tag.
Poiché IDT utilizza la stessa cartella Artifacts per tutti i casi di test e non elimina i file dei risultati tra le esecuzioni dei test, questo metodo potrebbe anche portare a segnalazioni errate se IDT legge il file errato. Si consiglia di utilizzare lo stesso nome per il file dei risultati XML generato in tutti i casi di test per sovrascrivere i risultati di ogni test case e assicurarsi che siano disponibili i risultati corretti per l'uso da IDT. Sebbene nella suite di test sia possibile utilizzare un approccio misto alla reportistica, ovvero utilizzare un file di risultati XML per alcuni casi di test e inviare i risultati tramite l'API per altri, non consigliamo questo approccio.
## Specificate il comportamento di uscita
Configura il tuo eseguibile testuale in modo che esca sempre con un codice di uscita pari a 0, anche se un test case riporta un errore o un risultato di errore. Utilizza codici di uscita diversi da zero solo per indicare che un test case non è stato eseguito o se l'eseguibile del test case non è in grado di comunicare alcun risultato a IDT. Quando IDT riceve un codice di uscita diverso da zero, indica che il test case ha riscontrato un errore che ne ha impedito l'esecuzione.
IDT potrebbe richiedere o aspettarsi che un test case smetta di funzionare prima del termine nei seguenti eventi. Utilizzate queste informazioni per configurare l'eseguibile del test case in modo da rilevare ciascuno di questi eventi dal test case:
****Timeout****
Si verifica quando un test case viene eseguito per un periodo più lungo del valore di timeout specificato nel `test.json` file. Se il test runner ha utilizzato l'`timeout-multiplier`argomento per specificare un moltiplicatore di timeout, IDT calcola il valore di timeout con il moltiplicatore.
Per rilevare questo evento, utilizzate la variabile di ambiente IDT\$1TEST\$1TIMEOUT. Quando un test runner avvia un test, IDT imposta il valore della variabile di ambiente IDT\$1TEST\$1TIMEOUT sul valore di timeout calcolato (in secondi) e passa la variabile all'eseguibile del test case. È possibile leggere il valore della variabile per impostare un timer appropriato.
****Interrompere****
Si verifica quando il test runner interrompe IDT. Ad esempio, premendo. Ctrl\$1C
Poiché i terminali propagano i segnali a tutti i processi secondari, nei casi di test è sufficiente configurare un gestore di segnali per rilevare i segnali di interruzione.
In alternativa, puoi interrogare periodicamente l'API per verificare il valore del `CancellationRequested` booleano nella risposta dell'API. `PollForNotifications` Quando IDT riceve un segnale di interruzione, imposta il valore del valore booleano su. `CancellationRequested` `true`
****Smettila al primo errore****
Si verifica quando un test case in esecuzione in parallelo al test case corrente ha esito negativo e il test runner ha utilizzato l'`stop-on-first-failure`argomento per specificare che IDT deve interrompersi in caso di errore.
Per rilevare questo evento, è possibile interrogare periodicamente l'API per verificare il valore del valore `CancellationRequested` booleano nella risposta dell'API. `PollForNotifications` Quando IDT rileva un errore ed è configurato per interrompersi al primo errore, imposta il valore del valore booleano su. `CancellationRequested` `true`
Quando si verifica uno di questi eventi, IDT attende 5 minuti per terminare l'esecuzione di tutti i test case attualmente in esecuzione. Se tutti i casi di test in esecuzione non si chiudono entro 5 minuti, IDT impone l'interruzione di ciascuno dei relativi processi. Se IDT non ha ricevuto i risultati dei test prima della fine dei processi, contrassegnerà i casi di test come scaduti. Come best practice, dovreste assicurarvi che i test case eseguano le seguenti azioni quando si verificano uno degli eventi:
1. Smetti di eseguire la normale logica di test.
1. Pulisci tutte le risorse temporanee, come gli artefatti di test sul dispositivo sottoposto a test.
1. Segnala un risultato del test a IDT, ad esempio un errore o un fallimento del test.
1. Esci.
# Usa il contesto IDT
Quando IDT esegue una suite di test, la suite di test può accedere a una serie di dati che possono essere utilizzati per determinare l'esecuzione di ciascun test. Questi dati sono chiamati contesto IDT. Ad esempio, la configurazione dei dati utente fornita dai test runner in un `userdata.json` file viene resa disponibile alle suite di test nel contesto IDT.
Il contesto IDT può essere considerato un documento JSON di sola lettura. Le suite di test possono recuperare dati e scrivere dati nel contesto utilizzando tipi di dati JSON standard come oggetti, matrici, numeri e così via.
## Schema contestuale
Il contesto IDT utilizza il seguente formato:
```
{
"config": {
"timeoutMultiplier": timeout-multiplier,
"idtRootPath":
},
"device": {
},
"devicePool": {
},
"resource": {
"devices": [
{
"name": ""
}
]
},
"testData": {
"awsCredentials": {
"awsAccessKeyId": "",
"awsSecretAccessKey": "",
"awsSessionToken": ""
},
"logFilePath": "/path/to/log/file"
},
"userData": {
}
}
```
**`config`**
Informazioni dal [`config.json`file](set-config-custom.md#config-json-custom). Il `config` campo contiene anche i seguenti campi aggiuntivi:
**`config.timeoutMultiplier`**
Il moltiplicatore per l'eventuale valore di timeout utilizzato dalla suite di test. Questo valore è specificato dal test runner dalla CLI IDT. Il valore predefinito è `1`.
**`config.idRootPath`**
Questo valore è un segnaposto per il valore assoluto del percorso di IDT durante la configurazione del file. `userdata.json` Viene utilizzato dai comandi build e flash.
**`device`**
Informazioni sul dispositivo selezionato per l'esecuzione del test. Queste informazioni sono equivalenti all'elemento dell'`devices`array nel [`device.json`file](set-config-custom.md#device-config-custom) per il dispositivo selezionato.
**`devicePool`**
Informazioni sul pool di dispositivi selezionato per l'esecuzione del test. Queste informazioni sono equivalenti all'elemento dell'array del pool di dispositivi di primo livello definito nel `device.json` file per il pool di dispositivi selezionato.
**`resource`**
Informazioni sui dispositivi di risorse contenute nel `resource.json` file.
**`resource.devices`**
Queste informazioni sono equivalenti all'`devices`array definito nel `resource.json` file. Ogni `devices` elemento include il seguente campo aggiuntivo:
**`resource.device.name`**
Il nome del dispositivo di risorse. Questo valore è impostato sul `requiredResource.name` valore del `test.json` file.
**`testData.awsCredentials`**
Le AWS credenziali utilizzate dal test per connettersi al AWS cloud. Queste informazioni sono ottenute dal `config.json` file.
**`testData.logFilePath`**
Il percorso del file di registro in cui il test case scrive i messaggi di registro. La suite di test crea questo file se non esiste.
**`userData`**
Informazioni fornite dal test runner nel [`userdata.json`file](set-config-custom.md#userdata-config-custom).
## Accedere ai dati nel contesto
È possibile interrogare il contesto utilizzando la JSONPath notazione dei file di configurazione e quella del testo eseguibile con `GetContextValue` and `GetContextString` APIs. La sintassi con cui JSONPath le stringhe accedono al contesto IDT varia come segue:
+ In `suite.json` e`test.json`, si usa. `{{query}}` Cioè, non usate l'elemento root `$.` per iniziare l'espressione.
+ In`statemachine.json`, si usa`{{$.query}}`.
+ Nei comandi API, si utilizza `query` o`{{$.query}}`, a seconda del comando. Per ulteriori informazioni, consultate la documentazione in linea in. SDKs
La tabella seguente descrive gli operatori in una tipica espressione foobar JSONPath:
| Operatore | Description |
| --- | --- |
| \$1 | Lelemento radice. Poiché il valore di contesto di primo livello per IDT è un oggetto, viene in genere utilizzato \$1. per avviare le query. |
| .childName | Accede all'elemento figlio con il nome childName di un oggetto. Se applicato a un array, produce un nuovo array con questo operatore applicato a ciascun elemento. Il nome dell'elemento distingue tra maiuscole e minuscole. Ad esempio, la query per accedere al awsRegion valore nell'configoggetto è\$1.config.awsRegion. |
| [start:end] | Filtra gli elementi da una matrice, recuperando gli elementi che iniziano dall'startindice e risalgono all'endindice, entrambi inclusi. |
| [index1, index2, ... , indexN] | Filtra gli elementi da un array, recuperando gli elementi solo dagli indici specificati. |
| [?(expr)] | Filtra gli elementi di un array utilizzando l'espressione. expr Questa espressione deve restituire un valore booleano. |
Per creare espressioni di filtro, utilizzate la seguente sintassi:
```
| operator |
```
In questa sintassi:
+ `jsonpath`è un programma JSONPath che utilizza la sintassi JSON standard.
+ `value`è qualsiasi valore personalizzato che utilizza la sintassi JSON standard.
+ `operator`è uno dei seguenti operatori:
+ `<`(Meno di)
+ `<=`(Minore o uguale a)
+ `==`(Uguale a)
Se il valore JSONPath o nell'espressione è un array, un valore booleano o un valore di oggetto, questo è l'unico operatore binario supportato che è possibile utilizzare.
+ `>=`(Maggiore o uguale a)
+ `>`(Maggiore di)
+ `=~`(Corrispondenza delle espressioni regolari). Per utilizzare questo operatore in un'espressione di filtro, il valore JSONPath o sul lato sinistro dell'espressione deve restituire una stringa e il lato destro deve essere un valore di modello che segue la [RE2sintassi](https://github.com/google/re2/wiki/Syntax).
È possibile utilizzare JSONPath le interrogazioni nel formato \$1\$1*query*\$1\$1 come stringhe segnaposto all'interno dei `environmentVariables` campi `args` e nei campi `test.json` dei file. `environmentVariables` `suite.json` IDT esegue una ricerca contestuale e popola i campi con il valore valutato della query. Ad esempio, nel `suite.json` file, è possibile utilizzare stringhe segnaposto per specificare i valori delle variabili di ambiente che cambiano con ogni test case e IDT popolerà le variabili di ambiente con il valore corretto per ogni test case. Tuttavia, quando utilizzate stringhe segnaposto nei `suite.json` file `test.json` e, alle vostre query valgono le seguenti considerazioni:
+ È necessario che ogni occorrenza della `devicePool` chiave nella query sia scritta interamente in lettere minuscole. Cioè, usa `devicepool` invece.
+ Per gli array, è possibile utilizzare solo matrici di stringhe. Inoltre, gli array utilizzano un formato non standard. `item1, item2,...,itemN` Se l'array contiene solo un elemento, viene serializzato come`item`, rendendolo indistinguibile da un campo di stringa.
+ Non è possibile utilizzare segnaposti per recuperare oggetti dal contesto.
Alla luce di queste considerazioni, consigliamo, quando possibile, di utilizzare l'API per accedere al contesto nella logica di test anziché le stringhe segnaposto nei file e nei file. `test.json` `suite.json` Tuttavia, in alcuni casi potrebbe essere più comodo utilizzare i JSONPath segnaposto per recuperare singole stringhe da impostare come variabili di ambiente.
# Configura le impostazioni per i test runner
Per eseguire suite di test personalizzate, i test runner devono configurare le proprie impostazioni in base alla suite di test che desiderano eseguire. Le impostazioni vengono specificate in base ai modelli di file di configurazione presenti nella `/configs/` cartella. Se necessario, i test runner devono anche impostare AWS le credenziali che IDT utilizzerà per connettersi al cloud. AWS
In qualità di scrittore di test, dovrai configurare questi file per eseguire il [debug](run-tests-custom.md) della tua suite di test. È necessario fornire istruzioni ai test runner in modo che possano configurare le seguenti impostazioni in base alle esigenze per eseguire le suite di test.
## Configura dispositivo.json
Il `device.json` file contiene informazioni sui dispositivi su cui vengono eseguiti i test (ad esempio, indirizzo IP, informazioni di accesso, sistema operativo e architettura della CPU).
I test runner possono fornire queste informazioni utilizzando il seguente `device.json` file modello che si trova nella `/configs/` cartella.
```
[
{
"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": "",
}
}
]
}
]
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`id`**
Un ID alfanumerico definito dall'utente che identifica in modo univoco una raccolta di dispositivi denominata un *pool di dispositivi*. I dispositivi che appartengono a un pool devono avere lo stesso hardware. Durante l'esecuzione di una suite di test, i dispositivi del pool vengono utilizzati per parallelizzare il carico di lavoro. Più dispositivi vengono utilizzati per eseguire diversi test.
**`sku`**
Un valore alfanumerico che identifica in modo univoco il dispositivo sottoposto a test. Lo SKU viene utilizzato per tracciare i dispositivi qualificati.
Se desideri inserire la tua scheda nel AWS Partner Device Catalog, lo SKU che specifichi qui deve corrispondere allo SKU utilizzato nel processo di pubblicazione delle offerte.
**`features`**
Opzionale. Un array contenente le caratteristiche supportate del dispositivo. Le funzionalità del dispositivo sono valori definiti dall'utente che configuri nella tua suite di test. È necessario fornire ai test runner informazioni sui nomi e sui valori delle funzionalità da includere nel `device.json` file. Ad esempio, se desiderate testare un dispositivo che funge da server MQTT per altri dispositivi, potete configurare la logica di test per convalidare livelli supportati specifici per una funzionalità denominata. `MQTT_QoS` I test runner forniscono questo nome di funzionalità e impostano il valore della funzionalità sui livelli QoS supportati dal proprio dispositivo. È possibile recuperare le informazioni fornite dal contesto [IDT con la `devicePool.features` query o dal contesto](idt-context.md) della [macchina a stati](idt-state-machine.md#state-machine-context) con la query. `pool.features`
**`features.name`**
Il nome della funzionalità.
**`features.value`**
I valori delle funzionalità supportate.
**`features.configs`**
Impostazioni di configurazione, se necessarie, per la funzionalità.
**`features.config.name`**
Il nome dell’impostazione di configurazione.
**`features.config.value`**
I valori di impostazione supportati.
**`devices`**
Una serie di dispositivi nel pool da testare. È richiesto almeno un dispositivo.
**`devices.id`**
Un identificativo univoco definito dall'utente del dispositivo sottoposto a test.
**`devices.pairedResource`**
Un identificatore univoco definito dall'utente per un dispositivo di risorse. Questo valore è necessario quando si testano i dispositivi utilizzando il protocollo di `no-op` connettività.
**`connectivity.protocol`**
Il protocollo di comunicazione utilizzato per comunicare con questo dispositivo. Ogni dispositivo in un pool deve utilizzare lo stesso protocollo.
Attualmente, gli unici valori supportati sono `ssh` e `uart` per i dispositivi fisici, `docker` per i contenitori Docker e `no-op` per i dispositivi che non dispongono di una connessione diretta con la macchina host IDT ma richiedono un dispositivo di risorse come middleware fisico per comunicare con la macchina host.
Per i dispositivi non operativi, si configura l'ID del dispositivo di risorsa in. `devices.pairedResource` È inoltre necessario specificare questo ID nel `resource.json` file. Il dispositivo associato deve essere un dispositivo fisicamente associato al dispositivo in prova. Dopo che IDT ha identificato e si è connesso al dispositivo di risorse associato, IDT non si connetterà ad altri dispositivi di risorse in base alle funzionalità descritte nel file. `test.json`
**`connectivity.ip`**
L'indirizzo IP del dispositivo sottoposto a test.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `ssh`.
**`connectivity.port`**
Opzionale. Il numero di porta da utilizzare per le connessioni SSH.
Il valore predefinito è 22.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `ssh`.
**`connectivity.publicKeyPath`**
Opzionale. Il percorso completo della chiave pubblica utilizzata per autenticare le connessioni al dispositivo in esame. Quando si specifica il`publicKeyPath`, IDT convalida la chiave pubblica del dispositivo quando stabilisce una connessione SSH al dispositivo in prova. Se questo valore non è specificato, IDT crea una connessione SSH, ma non convalida la chiave pubblica del dispositivo.
Ti consigliamo vivamente di specificare il percorso della chiave pubblica e di utilizzare un metodo sicuro per recuperare questa chiave pubblica. Per i client SSH standard basati sulla riga di comando, la chiave pubblica viene fornita nel file. `known_hosts` Se si specifica un file con chiave pubblica separato, questo file deve utilizzare lo stesso formato del `known_hosts` file, ovvero. `ip-address key-type public-key`
**`connectivity.auth`**
Informazioni di autenticazione per la connessione.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `ssh`.
**`connectivity.auth.method`**
Il metodo di autorizzazione utilizzato per accedere a un dispositivo con un determinato protocollo di connettività.
I valori supportati sono:
+ `pki`
+ `password`
**`connectivity.auth.credentials`**
Le credenziali utilizzate per l'autenticazione.
**`connectivity.auth.credentials.password`**
La password utilizzata per l'accesso al dispositivo da testare.
Questo valore si applica solo se `connectivity.auth.method` è impostato su `password`.
**`connectivity.auth.credentials.privKeyPath`**
Il percorso completo alla chiave privata utilizzata per accedere al dispositivo sottoposto a test.
Questo valore si applica solo se `connectivity.auth.method` è impostato su `pki`.
**`connectivity.auth.credentials.user`**
Il nome utente per l'accesso al dispositivo sottoposto a test.
**`connectivity.serialPort`**
Opzionale. La porta seriale a cui è collegato il dispositivo.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `uart`.
**`connectivity.containerId`**
L'ID contenitore o il nome del contenitore Docker in fase di test.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `docker`.
**`connectivity.containerUser`**
Opzionale. Il nome da utente a utente all'interno del contenitore. Il valore predefinito è l'utente fornito nel Dockerfile.
Il valore predefinito è 22.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `docker`.
Per verificare se i test runner configurano la connessione errata del dispositivo per un test, è possibile recuperarlo `pool.Devices[0].Connectivity.Protocol` dal contesto della macchina a stati e confrontarlo con il valore previsto in uno `Choice` stato. Se viene utilizzato un protocollo errato, stampa un messaggio utilizzando lo `LogMessage` stato e passa allo `Fail` stato.
In alternativa, è possibile utilizzare il codice di gestione degli errori per segnalare un errore di test per tipi di dispositivi errati.
## (Facoltativo) Configura userdata.json
Il `userdata.json` file contiene tutte le informazioni aggiuntive richieste da una suite di test ma non sono specificate nel file. `device.json` Il formato di questo file dipende dal [`userdata_scheme.json`file](idt-json-config.md#userdata-schema-json) definito nella suite di test. Se sei uno scrittore di test, assicurati di fornire queste informazioni agli utenti che eseguiranno le suite di test che scrivi.
## (Facoltativo) Configura resource.json
Il `resource.json` file contiene informazioni su tutti i dispositivi che verranno utilizzati come dispositivi di risorse. I dispositivi di risorse sono dispositivi necessari per testare determinate funzionalità di un dispositivo sottoposto a test. Ad esempio, per testare la funzionalità Bluetooth di un dispositivo, è possibile utilizzare un dispositivo di risorse per verificare che il dispositivo sia in grado di connettersi correttamente. I dispositivi di risorse sono opzionali e puoi richiedere tutti i dispositivi di risorse di cui hai bisogno. In qualità di autore del test, utilizzi il [file test.json](idt-json-config.md#test-json) per definire le funzionalità dei dispositivi di risorse necessarie per un test. I test runner utilizzano quindi il `resource.json` file per fornire un pool di dispositivi di risorse dotati delle funzionalità richieste. Assicurati di fornire queste informazioni agli utenti che eseguiranno le suite di test che scrivi.
I test runner possono fornire queste informazioni utilizzando il seguente `resource.json` file modello che si trova nella `/configs/` cartella.
```
[
{
"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": "",
}
}
]
}
]
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**`id`**
Un ID alfanumerico definito dall'utente che identifica in modo univoco una raccolta di dispositivi denominata un *pool di dispositivi*. I dispositivi che appartengono a un pool devono avere lo stesso hardware. Durante l'esecuzione di una suite di test, i dispositivi del pool vengono utilizzati per parallelizzare il carico di lavoro. Più dispositivi vengono utilizzati per eseguire diversi test.
**`features`**
Opzionale. Un array contenente le caratteristiche supportate del dispositivo. Le informazioni richieste in questo campo sono definite nei [file test.json](idt-json-config.md#test-json) nella suite di test e determinano quali test eseguire e come eseguirli. Se la suite di test non richiede alcuna funzionalità, questo campo non è obbligatorio.
**`features.name`**
Il nome della funzionalità.
**`features.version`**
La versione della funzionalità.
**`features.jobSlots`**
Impostazione per indicare quanti test possono utilizzare il dispositivo contemporaneamente. Il valore predefinito è `1`.
**`devices`**
Una serie di dispositivi nel pool da testare. È richiesto almeno un dispositivo.
**`devices.id`**
Un identificativo univoco definito dall'utente del dispositivo sottoposto a test.
**`connectivity.protocol`**
Il protocollo di comunicazione utilizzato per comunicare con questo dispositivo. Ogni dispositivo in un pool deve utilizzare lo stesso protocollo.
Attualmente, gli unici valori supportati sono `ssh` e `uart` per i dispositivi fisici e `docker` per i contenitori Docker.
**`connectivity.ip`**
L'indirizzo IP del dispositivo sottoposto a test.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `ssh`.
**`connectivity.port`**
Opzionale. Il numero di porta da utilizzare per le connessioni SSH.
Il valore predefinito è 22.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `ssh`.
**`connectivity.publicKeyPath`**
Opzionale. Il percorso completo della chiave pubblica utilizzata per autenticare le connessioni al dispositivo in esame. Quando si specifica il`publicKeyPath`, IDT convalida la chiave pubblica del dispositivo quando stabilisce una connessione SSH al dispositivo in prova. Se questo valore non è specificato, IDT crea una connessione SSH, ma non convalida la chiave pubblica del dispositivo.
Ti consigliamo vivamente di specificare il percorso della chiave pubblica e di utilizzare un metodo sicuro per recuperare questa chiave pubblica. Per i client SSH standard basati sulla riga di comando, la chiave pubblica viene fornita nel file. `known_hosts` Se si specifica un file con chiave pubblica separato, questo file deve utilizzare lo stesso formato del `known_hosts` file, ovvero. `ip-address key-type public-key`
**`connectivity.auth`**
Informazioni di autenticazione per la connessione.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `ssh`.
**`connectivity.auth.method`**
Il metodo di autorizzazione utilizzato per accedere a un dispositivo con un determinato protocollo di connettività.
I valori supportati sono:
+ `pki`
+ `password`
**`connectivity.auth.credentials`**
Le credenziali utilizzate per l'autenticazione.
**`connectivity.auth.credentials.password`**
La password utilizzata per l'accesso al dispositivo da testare.
Questo valore si applica solo se `connectivity.auth.method` è impostato su `password`.
**`connectivity.auth.credentials.privKeyPath`**
Il percorso completo alla chiave privata utilizzata per accedere al dispositivo sottoposto a test.
Questo valore si applica solo se `connectivity.auth.method` è impostato su `pki`.
**`connectivity.auth.credentials.user`**
Il nome utente per l'accesso al dispositivo sottoposto a test.
**`connectivity.serialPort`**
Opzionale. La porta seriale a cui è collegato il dispositivo.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `uart`.
**`connectivity.containerId`**
L'ID contenitore o il nome del contenitore Docker in fase di test.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `docker`.
**`connectivity.containerUser`**
Opzionale. Il nome da utente a utente all'interno del contenitore. Il valore predefinito è l'utente fornito nel Dockerfile.
Il valore predefinito è 22.
Questa proprietà si applica solo se `connectivity.protocol` è impostata su `docker`.
## (Facoltativo) Configura config.json
Il `config.json` file contiene informazioni di configurazione per IDT. In genere, i test runner non avranno bisogno di modificare questo file se non per fornire le proprie credenziali AWS utente per IDT e, facoltativamente, una regione. AWS Se vengono fornite AWS le credenziali con le autorizzazioni richieste, AWS IoT Device Tester raccoglie e invia le metriche di utilizzo a. AWS Si tratta di una funzionalità opzionale e viene utilizzata per migliorare la funzionalità IDT. Per ulteriori informazioni, consulta [Invia le metriche di utilizzo IDT](idt-usage-metrics.md).
I test runner possono configurare le proprie AWS credenziali in uno dei seguenti modi:
+ **File di credenziali**
IDT usa lo stesso file delle credenziali di AWS CLI. Per ulteriori informazioni, consulta l'argomento relativo ai [file di configurazione e delle credenziali](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html).
La posizione del file delle credenziali varia in base al sistema operativo in uso:
+ macOS, Linux: `~/.aws/credentials`
+ Windows: `C:\Users\UserName\.aws\credentials`
+ **Variabili di ambiente**
Le variabili di ambiente sono variabili gestite dal sistema operativo e utilizzate dai comandi di sistema. Le variabili definite durante una sessione SSH non sono disponibili dopo la chiusura della sessione. IDT può utilizzare le variabili di `AWS_SECRET_ACCESS_KEY` ambiente `AWS_ACCESS_KEY_ID` e per memorizzare le credenziali AWS
Per impostare queste variabili su Linux, macOS o Unix, utilizza **export**:
```
export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
```
Per impostare queste variabili su Windows, utilizza **set**:
```
set AWS_ACCESS_KEY_ID=
set AWS_SECRET_ACCESS_KEY=
```
Per configurare AWS le credenziali per IDT, i test runner modificano la `auth` sezione del `config.json` file che si trova nella cartella. `/configs/`
```
{
"log": {
"location": "logs"
},
"configFiles": {
"root": "configs",
"device": "configs/device.json"
},
"testPath": "tests",
"reportPath": "results",
"awsRegion": "",
"auth": {
"method": "file | environment",
"credentials": {
"profile": ""
}
}
}
]
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
**Nota**
Tutti i percorsi di questo file sono definiti in relazione a. **
**`log.location`**
Il percorso della cartella dei registri in. **
**`configFiles.root`**
Il percorso della cartella che contiene i file di configurazione.
**`configFiles.device`**
Il percorso del `device.json` file.
**`testPath`**
Il percorso della cartella che contiene le suite di test.
**`reportPath`**
Il percorso della cartella che conterrà i risultati dei test dopo che IDT avrà eseguito una suite di test.
**`awsRegion`**
Opzionale. La AWS regione che verranno utilizzate dalle suite di test. Se non è impostata, le suite di test utilizzeranno la regione predefinita specificata in ciascuna suite di test.
**`auth.method`**
Il metodo utilizzato da IDT per recuperare AWS le credenziali. I valori supportati sono `file` il recupero delle credenziali da un file di credenziali e il recupero delle credenziali utilizzando le variabili `environment` di ambiente.
**`auth.credentials.profile`**
Il profilo delle credenziali da utilizzare dal file delle credenziali. Questa proprietà si applica solo se `auth.method` è impostata su `file`.
# Esegui il debug ed esegui suite di test personalizzate
Dopo aver impostato la [configurazione richiesta](set-config-custom.md), IDT può eseguire la suite di test. Il tempo di esecuzione della suite di test completa dipende dall'hardware e dalla composizione della suite di test. Per riferimento, sono necessari circa 30 minuti per completare l'intera suite di test di qualificazione FreerTOS su un Raspberry Pi 3B.
Mentre scrivi la tua suite di test, puoi usare IDT per eseguire la suite di test in modalità debug per controllare il codice prima di eseguirlo o fornirlo ai test runner.
## Esegui IDT in modalità debug
Poiché le suite di test dipendono da IDT per interagire con i dispositivi, fornire il contesto e ricevere risultati, non è possibile semplicemente eseguire il debug delle suite di test in un IDE senza alcuna interazione IDT. A tale scopo, la CLI IDT fornisce `debug-test-suite` il comando che consente di eseguire IDT in modalità debug. Eseguite il comando seguente per visualizzare le opzioni disponibili per: `debug-test-suite`
```
devicetester_[linux | mac | win_x86-64] debug-test-suite -h
```
Quando eseguite IDT in modalità debug, IDT non avvia effettivamente la suite di test né esegue il test orchestrator; interagisce invece con l'IDE per rispondere alle richieste fatte dalla suite di test in esecuzione nell'IDE e stampa i log sulla console. IDT non scade e attende di uscire fino a quando non viene interrotto manualmente. In modalità debug, IDT inoltre non esegue il test orchestrator e non genererà alcun file di report. Per eseguire il debug della suite di test, è necessario utilizzare l'IDE per fornire alcune informazioni che IDT di solito ottiene dai file di configurazione. Assicurati di fornire le seguenti informazioni:
+ Variabili di ambiente e argomenti per ogni test. IDT non leggerà queste informazioni da `test.json` o`suite.json`.
+ Argomenti per selezionare i dispositivi di risorse. IDT non leggerà queste informazioni da`test.json`.
Per eseguire il debug delle tue suite di test, completa i seguenti passaggi:
1. Crea i file di configurazione delle impostazioni necessari per eseguire la suite di test. Ad esempio, se la tua suite di test richiede `device.json` `resource.json``user data.json`, e, assicurati di configurarli tutti secondo necessità.
1. Eseguite il comando seguente per mettere IDT in modalità debug e selezionare tutti i dispositivi necessari per eseguire il test.
```
devicetester_[linux | mac | win_x86-64] debug-test-suite [options]
```
Dopo aver eseguito questo comando, IDT attende le richieste dalla suite di test e quindi risponde ad esse. IDT genera anche le variabili di ambiente necessarie per il processo di elaborazione dei casi per IDT Client SDK.
1. Nel tuo IDE, usa la `debug` configurazione `run` o per effettuare le seguenti operazioni:
1. Imposta i valori delle variabili di ambiente generate da IDT.
1. Imposta il valore di tutte le variabili o gli argomenti di ambiente che hai specificato nel file `test.json` and`suite.json`.
1. Imposta i punti di interruzione secondo necessità.
1. Esegui la suite di test nel tuo IDE.
Puoi eseguire il debug e rieseguire la suite di test tutte le volte che è necessario. IDT non scade in modalità di debug.
1. Dopo aver completato il debug, interrompi IDT per uscire dalla modalità di debug.
## Comandi IDT CLI per eseguire test
La sezione seguente descrive i comandi IDT CLI:
------
#### [ IDT v4.0.0 ]
**`help`**
Elenca le informazioni sul comando specificato.
**`list-groups`**
Elenca i gruppi in una determinata suite di test.
**`list-suites`**
Elenca le suite di test disponibili.
**`list-supported-products`**
Elenca i prodotti supportati per la tua versione di IDT, in questo caso le versioni FreeRTOS e le versioni della suite di test di qualificazione FreerTOS disponibili per la versione IDT corrente.
**`list-test-cases`**
Elenca i casi di test in un determinato gruppo di test. È supportata la seguente opzione:
+ `group-id`. Il gruppo di test da cercare. Questa opzione è obbligatoria e deve specificare un singolo gruppo.
**`run-suite`**
Esegue una suite di test in un determinato pool di dispositivi. Di seguito sono riportate alcune opzioni di uso comune:
+ `suite-id`. La versione della suite di test da eseguire. Se non specificato, IDT utilizza la versione più recente nella cartella `tests`.
+ `group-id`. I gruppi di test da eseguire, sotto forma di elenco separato da virgole. Se non specificato, IDT esegue tutti i gruppi di test nella suite di test.
+ `test-id`. I casi di test da eseguire, come elenco separato da virgole. Quando specificato, `group-id` deve specificare un singolo gruppo.
+ `pool-id`. Il pool di dispositivi da testare. I test runner devono specificare un pool se hanno più pool di dispositivi definiti nel `device.json` file.
+ `timeout-multiplier`. Configura IDT per modificare il timeout di esecuzione del test specificato nel `test.json` file per un test con un moltiplicatore definito dall'utente.
+ `stop-on-first-failure`. Configura IDT per interrompere l'esecuzione al primo errore. Questa opzione deve essere utilizzata con `group-id` per eseguire il debug dei gruppi di test specificati.
+ `userdata`. Imposta il file che contiene le informazioni sui dati utente necessarie per eseguire la suite di test. Questo è richiesto solo se `userdataRequired` è impostato su true nel `suite.json` file della suite di test.
Per ulteriori informazioni sulle opzioni `run-suite`, utilizzare l'opzione `help`:
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
**`debug-test-suite`**
Esegui la suite di test in modalità debug. Per ulteriori informazioni, consulta [Esegui IDT in modalità debug](#idt-debug-mode).
------
# Esamina i risultati e i registri dei test IDT
Questa sezione descrive il formato in cui IDT genera i log della console e i rapporti di test.
## Formato dei messaggi della console
AWS IoT Device Tester utilizza un formato standard per la stampa dei messaggi sulla console quando avvia una suite di test. Il seguente estratto mostra un esempio di messaggio di console generato da IDT.
```
[INFO] [2000-01-02 03:04:05]: Using suite: MyTestSuite_1.0.0 executionId=9a52f362-1227-11eb-86c9-8c8590419f30
```
La maggior parte dei messaggi della console è composta dai seguenti campi:
**`time`**
Un timestamp ISO 8601 completo per l'evento registrato.
**`level`**
Il livello del messaggio per l'evento registrato. In genere, il livello del messaggio registrato è uno dei `info``warn`, o. `error` IDT emette un `panic` messaggio `fatal` or se rileva un evento previsto che ne causa la chiusura anticipata.
**`msg`**
Il messaggio registrato.
**`executionId`**
Una stringa ID univoca per il processo IDT corrente. Questo ID viene utilizzato per distinguere le singole esecuzioni IDT.
I messaggi della console generati da una suite di test forniscono informazioni aggiuntive sul dispositivo sottoposto a test e sulla suite di test, sul gruppo di test e sui casi di test eseguiti da IDT. Il seguente estratto mostra un esempio di messaggio di console generato da una suite di test.
```
[INFO] [2000-01-02 03:04:05]: Hello world! suiteId=MyTestSuitegroupId=myTestGroup testCaseId=myTestCase deviceId=my-deviceexecutionId=9a52f362-1227-11eb-86c9-8c8590419f30
```
La parte specifica del messaggio della console di test contiene i seguenti campi:
**`suiteId`**
Il nome della suite di test attualmente in esecuzione.
**`groupId`**
L'ID del gruppo di test attualmente in esecuzione.
**`testCaseId`**
L'ID del test case attualmente in esecuzione.
**`deviceId`**
Un ID del dispositivo sottoposto a test utilizzato dal test case corrente.
Il riepilogo del test contiene informazioni sulla suite di test, i risultati dei test per ogni gruppo eseguito e le posizioni dei log e dei file di report generati. L'esempio seguente mostra un messaggio di riepilogo del test.
```
========== 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 schema del rapporto
`awsiotdevicetester_report.xml`è un rapporto firmato che contiene le seguenti informazioni:
+ La versione di IDT.
+ La versione della suite di test.
+ La firma del rapporto e la chiave utilizzate per firmare il rapporto.
+ Lo SKU del dispositivo e il nome del pool di dispositivi specificati nel `device.json` file.
+ La versione del prodotto e le funzionalità del dispositivo testate.
+ Il riepilogo aggregato dei risultati dei test. Queste informazioni sono le stesse contenute nel `suite-name_report.xml` file.
```
idt-version
test-suite-version
signature
keyname
execution-id
start-time
end-time
product-name
product-version
device-sku
device-name
ssh | uart | docker
```
Il file `awsiotdevicetester_report.xml` contiene un tag `` con le informazioni relative al prodotto sottoposto a test e le caratteristiche del prodotto che sono state convalidate dopo l'esecuzione di una suite di test.
**Attributi utilizzati nel `` tag**
**`name`**
Il nome del prodotto sottoposto a test.
**`version`**
La versione del prodotto sottoposto a test.
**`features`**
Le caratteristiche convalidate. Le funzionalità contrassegnate come `required` sono necessarie affinché la suite di test possa convalidare il dispositivo. Il seguente frammento di codice mostra come questa informazione viene visualizzata nel file `awsiotdevicetester_report.xml`.
```
```
Le funzionalità contrassegnate come non `optional` sono richieste per la convalida. I seguenti snippet mostrano caratteristiche facoltative.
```
```
## Schema di report della suite di test
Il `suite-name_Result.xml` rapporto è in [formato JUnit XML](https://llg.cubic.org/docs/junit/). Puoi eseguire l'integrazione in piattaforme di integrazione e distribuzione continue come [Jenkins](https://jenkins.io/), [Bambù](https://www.atlassian.com/software/bamboo) e così via. Il rapporto contiene un riepilogo aggregato dei risultati del test.
```
reason
reason
reason
```
La sezione del rapporto in entrambe le sezioni `awsiotdevicetester_report.xml` o `suite-name_report.xml` elenca i test eseguiti e i risultati.
Il primo tag XML `` contiene il riepilogo dell'esecuzione dei test. Esempio:
```
```
**Attributi utilizzati nel `` tag**
**`name`**
Il nome della suite di test.
**`time`**
Il tempo impiegato, in secondi, per eseguire la suite di test.
**`tests`**
Il numero di test eseguiti.
**`failures`**
Il numero di test eseguiti ma non superati.
**`errors`**
Il numero di test che IDT non è stato in grado di eseguire.
**`disabled`**
Questo attributo non è utilizzato e si può ignorare.
In caso di esiti negativi o errori nei test, puoi identificare il test non riuscito esaminando i tag XML ``. I tag XML `` all'interno del tag `` mostrano il riepilogo dei risultati dei test per un gruppo di test. Esempio:
```
```
Il formato è simile al tag ``, ma con un attributo `skipped` che non viene utilizzato e che è possibile ignorare. All'interno di ogni tag XML `` ci sono tag `` per ciascuno dei test eseguiti per un gruppo di test. Esempio:
```
```
**Attributi utilizzati nel `` tag**
**`name`**
Il nome del test.
**`attempts`**
Il numero di volte che IDT ha eseguito il test.
Quando un test non riesce o si verifica un errore, i tag `` o `` vengono aggiunti al tag `` con informazioni per la risoluzione dei problemi. Esempio:
```
Reason for the test failure
Reason for the test execution error
```
# Invia le metriche di utilizzo IDT
Se fornisci AWS credenziali con le autorizzazioni richieste, AWS IoT Device Tester raccoglie e invia le metriche di utilizzo a. AWS Si tratta di una funzionalità opzionale e viene utilizzata per migliorare la funzionalità IDT. IDT raccoglie informazioni come le seguenti:
+ L'ID AWS dell'account utilizzato per eseguire IDT
+ I comandi IDT CLI utilizzati per eseguire i test
+ La suite di test che viene eseguita
+ Le suite di test nella ** cartella
+ Il numero di dispositivi configurati nel pool di dispositivi
+ Nomi e tempi di esecuzione dei test case
+ Informazioni sui risultati del test, ad esempio se i test sono stati superati, hanno avuto esito negativo, hanno riscontrato errori o sono stati saltati
+ Caratteristiche del prodotto testate
+ Comportamento di uscita IDT, ad esempio uscite impreviste o anticipate
Tutte le informazioni inviate da IDT vengono inoltre registrate in un `metrics.log` file nella cartella. `/results//` È possibile visualizzare il file di registro per visualizzare le informazioni raccolte durante un'esecuzione di test. Questo file viene generato solo se si sceglie di raccogliere le metriche di utilizzo.
Per disabilitare la raccolta delle metriche, non è necessario intraprendere ulteriori azioni. Semplicemente non archiviate AWS le vostre credenziali e, se avete AWS credenziali memorizzate, non configurate il `config.json` file per accedervi.
## Registrati per un Account AWS
Se non ne hai uno Account AWS, completa i seguenti passaggi per crearne uno.
**Per iscriverti a un Account AWS**
1. Apri la [https://portal.aws.amazon.com/billing/registrazione.](https://portal.aws.amazon.com/billing/signup)
1. Segui le istruzioni online.
Nel corso della procedura di registrazione riceverai una telefonata o un messaggio di testo e ti verrà chiesto di inserire un codice di verifica attraverso la tastiera del telefono.
Quando ti iscrivi a un Account AWS, *Utente root dell'account AWS*viene creato un. L’utente root dispone dell’accesso a tutte le risorse e tutti i Servizi AWS nell’account. Come best practice di sicurezza, assegna l’accesso amministrativo a un utente e utilizza solo l’utente root per eseguire [attività che richiedono l’accesso di un utente root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).
AWS ti invia un'email di conferma dopo il completamento della procedura di registrazione. In qualsiasi momento, puoi visualizzare l'attività corrente del tuo account e gestirlo accedendo a [https://aws.amazon.com/](https://aws.amazon.com/)e scegliendo **Il mio account**.
## Crea un utente con accesso amministrativo
Dopo esserti registrato Account AWS, proteggi Utente root dell'account AWS AWS IAM Identity Center, abilita e crea un utente amministrativo in modo da non utilizzare l'utente root per le attività quotidiane.
**Proteggi i tuoi Utente root dell'account AWS**
1. Accedi [Console di gestione AWS](https://console.aws.amazon.com/)come proprietario dell'account scegliendo **Utente root** e inserendo il tuo indirizzo Account AWS email. Nella pagina successiva, inserisci la password.
Per informazioni sull’accesso utilizzando un utente root, consulta la pagina [Accedere come utente root](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) nella *Guida per l’utente di Accedi ad AWS *.
1. Abilita l’autenticazione a più fattori (MFA) per l’utente root.
Per istruzioni, consulta [Abilitare un dispositivo MFA virtuale per l'utente Account AWS root (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) nella Guida per l'*utente IAM*.
**Crea un utente con accesso amministrativo**
1. Abilita il Centro identità IAM.
Per istruzioni, consulta [Abilitazione del AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) nella *Guida per l’utente di AWS IAM Identity Center *.
1. Nel Centro identità IAM, assegna l’accesso amministrativo a un utente.
Per un tutorial sull'utilizzo di IAM Identity Center directory come fonte di identità, consulta [Configurare l'accesso utente con l'impostazione predefinita IAM Identity Center directory](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) nella *Guida per l'AWS IAM Identity Center utente*.
**Accesso come utente amministratore**
+ Per accedere come utente del Centro identità IAM, utilizza l’URL di accesso che è stato inviato al tuo indirizzo e-mail quando hai creato l’utente del Centro identità IAM.
Per informazioni sull'accesso utilizzando un utente IAM Identity Center, consulta [AWS Accedere al portale di accesso](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) nella *Guida per l'Accedi ad AWS utente*.
**Assegnazione dell’accesso ad altri utenti**
1. Nel Centro identità IAM, crea un set di autorizzazioni conforme alla best practice per l’applicazione di autorizzazioni con il privilegio minimo.
Segui le istruzioni riportate nella pagina [Creazione di un set di autorizzazioni](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) nella *Guida per l’utente di AWS IAM Identity Center *.
1. Assegna al gruppo prima gli utenti e poi l’accesso con autenticazione unica (Single Sign-On).
Per istruzioni, consulta [Aggiungere gruppi](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) nella *Guida per l’utente di AWS IAM Identity Center *.
Per fornire l’accesso, aggiungi autorizzazioni agli utenti, gruppi o ruoli:
+ Utenti e gruppi in AWS IAM Identity Center:
Crea un set di autorizzazioni. Segui le istruzioni riportate nella pagina [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) (Creazione di un set di autorizzazioni) nella *Guida per l’utente di AWS IAM Identity Center *.
+ Utenti gestiti in IAM tramite un provider di identità:
Crea un ruolo per la federazione delle identità. Segui le istruzioni riportate nella pagina [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) della *Guida per l’utente IAM*.
+ Utenti IAM:
+ Crea un ruolo che l’utente possa assumere. Segui le istruzioni riportate nella pagina [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) della *Guida per l’utente IAM*.
+ (Non consigliato) Collega una policy direttamente a un utente o aggiungi un utente a un gruppo di utenti. Segui le istruzioni riportate nella pagina [Aggiunta di autorizzazioni a un utente (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) nella *Guida per l’utente IAM*.
## Fornire AWS credenziali a IDT
Per consentire a IDT di accedere alle tue AWS credenziali e inviare le metriche a AWS, procedi come segue:
1. Archivia le AWS credenziali per il tuo utente IAM come variabili di ambiente o in un file di credenziali:
1. Per utilizzare le variabili di ambiente, esegui il comando seguente:
```
AWS_ACCESS_KEY_ID=access-key
AWS_SECRET_ACCESS_KEY=secret-access-key
```
1. Per utilizzare il file delle credenziali, aggiungete le seguenti informazioni al `.aws/credentials file:`
```
[profile-name]
aws_access_key_id=access-key
aws_secret_access_key=secret-access-key
```
1. Configura la `auth` sezione del `config.json` file. Per ulteriori informazioni, consulta [(Facoltativo) Configura config.json](set-config-custom.md#config-json-custom).
# Mantieni le versioni della suite di test
IDT for FreerTOS organizza le risorse di test in suite di test e gruppi di test:
+ Una suite di test è l'insieme di gruppi di test utilizzati per verificare che un dispositivo funzioni con versioni particolari di FreerTOS.
+ Un gruppo di test è il set di singoli test relativi a una particolare funzionalità, come la messaggistica BLE e MQTT.
A partire da IDT v3.0.0, le versioni della suite di test sono definite utilizzando il formato `major`.`minor`.`patch` a partire da 1.0.0. Quando scarichi IDT, il pacchetto include la versione più recente della suite di test.
Quando avvii IDT nell'interfaccia a riga di comando, IDT verifica se è disponibile una versione più recente della suite di test. In tal caso, viene richiesto di eseguire l'aggiornamento alla nuova versione. Puoi scegliere di aggiornare o continuare con i test correnti.
**Nota**
IDT supporta le tre versioni più recenti della suite di test per la qualifica. Per ulteriori informazioni, consulta [Comprendi la politica di supporto per AWS IoT Device Tester](idt-support-policy.md).
Puoi scaricare le suite di test utilizzando il comando `upgrade-test-suite`. In alternativa, puoi utilizzare il parametro `-upgrade-test-suite flag` opzionale all'avvio di IDT, dove *flag* può essere '`y`' per scaricare sempre la versione più recente o '`n`' per utilizzare la versione esistente.
Puoi anche eseguire il `list-supported-versions` comando per elencare le versioni di FreerTOS e della suite di test supportate dalla versione corrente di IDT.
Nuovi test potrebbero introdurre nuove impostazioni di configurazione IDT. Se le impostazioni sono facoltative, IDT ti invia una notifica e continua a eseguire i test. Se le impostazioni sono necessarie, IDT invia una notifica all'utente e interrompe l'esecuzione. Una volta configurate le impostazioni, puoi continuare a eseguire i test.
# Risoluzione degli errori
Ogni esecuzione della suite di test ha un ID di esecuzione univoco che viene utilizzato per creare una cartella denominata `results/execution-id` nella directory `results`. I log dei singoli gruppi di test sono disponibili nella directory `results/execution-id/logs`. Usa l'output della console IDT for FreerTOS per trovare l'id di esecuzione, l'id del test case e l'id del gruppo di test del test case che ha avuto esito negativo, quindi apri il file di registro per quel test case denominato. `results/execution-id/logs/test_group_id__test_case_id.log` Le informazioni nel file includono:
+ Output completo dei comandi build e flash.
+ Output dell'esecuzione di test.
+ IDT più prolisso per l'output della console FreerTOS.
Per la risoluzione dei problemi consigliamo il seguente flusso di lavoro:
1. Se vedi l'errore "non *user/role* è autorizzato ad accedere a questa risorsa», assicurati di configurare le autorizzazioni come specificato in. [Crea e configura un account AWS](dev-tester-prereqs.md#config-aws-account)
1. Leggere l'output della console per trovare le informazioni, ad esempio l'UUID dell'esecuzione e le attività attualmente in esecuzione.
1. Nel file `FRQ_Report.xml` cercare le istruzioni di errore risultanti da ciascun test. Questa directory contiene i log di esecuzione di ciascun gruppo di test.
1. Cerca nei file di registro sotto`/results/execution-id/logs`.
1. Esaminare una delle seguenti aree problematiche:
+ Configurazione del dispositivo, ad esempio i file di configurazione JSON nella cartella `/configs/`.
+ Interfaccia del dispositivo. Controllare i log per determinare l'interfaccia che ha generato l'errore.
+ Strumenti del dispositivo. Verificare che le toolchain per le operazioni di compilazione e flashing del dispositivo siano installate e configurate correttamente.
+ Per FRQ 1.x.x assicurati che sia disponibile una versione pulita e clonata del codice sorgente di FreerTOS. Le versioni di FreerTOS sono etichettate in base alla versione di FreerTOS. Per clonare una versione specifica del codice, usa i seguenti comandi:
```
git clone --branch version-number https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
## Risolvi i problemi di configurazione del dispositivo
Quando si utilizza IDT per FreerTOS, è necessario disporre dei file di configurazione corretti prima di eseguire il file binario. Se ottieni errori di parsing e di configurazione, per prima cosa dovresti individuare e utilizzare un modello di configurazione appropriato per il tuo ambiente. Questi modelli si trovano nella directory `IDT_ROOT/configs`.
Se continui a riscontare problemi, consulta la seguente procedura di debug.
### Dove devo cercare?
Per iniziare, leggi l'output della console per trovare le informazioni necessarie, ad esempio l'UUID dell'esecuzione, ovvero `execution-id` in questa documentazione.
Esamina quindi il file `FRQ_Report.xml` nella directory `/results/execution-id`. Questo file contiene tutti i casi di test eseguiti e i frammenti di errore per ogni fallimento. Per ottenere tutti i log di esecuzione, cerca il file `/results/execution-id/logs/test_group_id__test_case_id.log` per ciascun caso di test.
### Codici di errore IDT
La tabella seguente spiega i codici di errore generati da IDT per FreerTOS:
| Codice di errore | Nome del codice di errore | Possibile causa principale | Risoluzione dei problemi |
| --- | --- | --- | --- |
| 201 | InvalidInputError | I campi in `device.json`, `config.json` o `userdata.json` sono mancanti o in un formato errato. | Assicurati che i campi obbligatori non siano mancanti e che siano nel formato obbligatorio nei file elencati. Per ulteriori informazioni, consulta [Primo test della scheda del microcontrollore](qual-steps.md). |
| 202 | ValidationError | I campi in `device.json`, `config.json` o `userdata.json` contengono valori non validi. | Controllare il messaggio di errore a destra del codice di errore nel report: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 203 | CopySourceCodeError | Impossibile copiare il codice sorgente di FreerTOS nella directory specificata. | Verificare quanto segue: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 204 | BuildSourceError | Impossibile compilare il codice sorgente di FreerTOS. | Verificare quanto segue: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 205 | FlashOrRunTestError | IDT FreeRTOS non è in grado di eseguire il flashing o eseguire FreerTOS sul tuo DUT. | Verifica che le informazioni in `flashTool` nel file `userdata.json` siano corrette. Per ulteriori informazioni, consulta [Configurazione delle impostazioni di compilazione, flashing e test](cfg-dt-ud.md). |
| 206 | StartEchoServerError | IDT FreerTOS non è in grado di avviare il server echo per i test o secure socket. WiFi | Verificare che le porte configurate in `echoServerConfiguration` nel file `userdata.json` non siano in uso o bloccate dalle impostazioni del firewall o della rete. |
### Errori di analisi del file di configurazione di debug
Talvolta un refuso in una configurazione JSON può causare errori di parsing. Nella maggior parte dei casi, il problema è dovuto all'omissione di parentesi, virgole o virgolette nel file JSON. IDT for FreerTOS esegue la convalida JSON e stampa le informazioni di debug. Inoltre indica la riga in cui si è verificato l'errore, il numero di riga e il numero di colonna dell'errore di sintassi. Queste informazioni dovrebbero essere sufficienti per aiutarti a correggere l'errore, ma se hai ancora problemi a localizzare l'errore, puoi eseguire la convalida manualmente nel tuo IDE, in un editor di testo come Atom o Sublime o tramite uno strumento online come. JSONLint
### I risultati dei test di debug analizzano gli errori
Durante l'esecuzione di un gruppo di test da [ FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests), come **FullTransportInterfaceTLS, Full PKCS11 \$1Core, Full \$1onboard\$1ECC, Full PKCS11 \$1onboard\$1RSA, Full \$1 PKCS11 \$1ECC, Full \$1 PKCS11 \$1RSA o, **OTACore**IDT for FreerTOS PreProvisioned analizza i risultati del test dal PKCS11 dispositivo PreProvisioned di test con la connessione seriale**. A volte, uscite seriali aggiuntive sul dispositivo possono interferire con l'analisi dei risultati del test.
Nel caso sopra menzionato, vengono emessi strani motivi di errore del test case, come stringhe provenienti da uscite di dispositivi non correlati. Il file di registro del test case IDT for FreerTOS (che include tutto l'output seriale che IDT for FreerTOS ha ricevuto durante il test) può mostrare quanto segue:
```
TEST(Full_PKCS11_Capabilities, PKCS11_Capabilities)
PASS
```
**Nell'esempio precedente, l'output del dispositivo non correlato impedisce a IDT for FreerTOS di rilevare il risultato del test che è PASS.**
Controllate quanto segue per garantire un test ottimale.
+ Assicurati che le macro di registrazione utilizzate sul dispositivo siano thread-safe. Per ulteriori informazioni, [consulta Implementazione delle macro di registrazione della libreria](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-library-logging-macros.html).
+ Assicurati che ci siano uscite minime alla connessione seriale durante i test. Le uscite di altri dispositivi possono essere un problema anche se le macro di registrazione sono correttamente thread-safe, perché i risultati del test verranno emessi in chiamate separate durante il test.
Un registro dei casi di test IDT per FreerTOS mostrerebbe idealmente un output dei risultati del test ininterrotto come di seguito:
```
---------STARTING TESTS---------
TEST(Full_OTA_PAL, otaPal_CloseFile_ValidSignature) PASS
TEST(Full_OTA_PAL, otaPal_CloseFile_InvalidSignatureBlockWritten) PASS
-----------------------
2 Tests 0 Failures 0 Ignored
```
### Errori di controllo dell'integrità del debug
Se si utilizza la versione FRQ 1.x.x di FreerTOS, si applicano i seguenti controlli di integrità.
Quando esegui il gruppo di RTOSIntegrity test Free e riscontri degli errori, assicurati innanzitutto di non aver modificato nessuno dei file di directory. `freertos` Se non l'hai fatto e continui a riscontrare problemi, assicurati di utilizzare il ramo corretto. Se esegui il `list-supported-products` comando di IDT, puoi trovare quale ramo taggato del `freertos` repository dovresti usare.
Se hai clonato il ramo con tag corretto del `freertos` repository e hai ancora problemi, assicurati di aver eseguito anche il comando. `submodule update` Il flusso di lavoro di clonazione per il `freertos` repository è il seguente.
```
git clone --branch version-number https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout —init —recursive
```
L'elenco dei file che il correttore di integrità cerca si trova nel `checksums.json` file della directory. `freertos` Per qualificare una porta FreerTOS senza alcuna modifica ai file e alla struttura delle cartelle, assicurati che nessuno dei file elencati nelle sezioni '' e `exhaustive` `minimal` '' del `checksums.json` file sia stato modificato. Per eseguirlo con un SDK configurato, verifica che nessuno dei file nella sezione '`minimal`' sia stato modificato.
Se esegui IDT con un SDK e hai modificato alcuni file nella tua `freertos` directory, assicurati di configurare correttamente l'SDK nel file. `userdata` Altrimenti, il correttore di integrità verificherà tutti i file nella directory. `freertos`
### Errori del gruppo di FullWiFi test di debug
Se si utilizza FRQ 1.x.x e si verificano errori nel gruppo di test e il FullWiFi test "`AFQP_WiFiConnectMultipleAP`" non riesce, ciò potrebbe essere dovuto al fatto che entrambi i punti di accesso non si trovano nella stessa sottorete del computer host su cui è in esecuzione IDT. Assicuratevi che entrambi i punti di accesso si trovino nella stessa sottorete del computer host su cui è in esecuzione IDT.
### Esegui il debug degli errori «parametri obbligatori mancanti»
Poiché vengono aggiunte nuove funzionalità a IDT per FreerTOS, potrebbero essere introdotte modifiche ai file di configurazione. L'utilizzo di un file di configurazione precedente potrebbe invalidare la tua configurazione. In questo caso, il file `test_group_id__test_case_id.log` nella directory `results/execution-id/logs` elenca in modo esplicito tutti i parametri mancanti. IDT for FreerTOS convalida gli schemi dei file di configurazione JSON per garantire che sia stata utilizzata l'ultima versione supportata.
### Errori di debug del tipo «test could not start»
È possibile che si verifichino errori relativi a problemi in fase di avvio del test. Poiché le potenziali cause sono diverse, verifica che nelle seguenti aree non ci siano errori:
+ Assicurati che il nome del pool incluso nel comando di esecuzione esista effettivamente. Questa informazione è riferita direttamente dal tuo file `device.json`.
+ Verifica che i parametri di configurazione del dispositivo o dei dispositivi nel pool siano corretti.
### Errori di debug «impossibile trovare i risultati di inizio del test»
Potresti riscontrare degli errori quando IDT tenta di analizzare i risultati emessi dal dispositivo in prova. Le cause possibili sono diverse, quindi controllate la correttezza delle seguenti aree:
+ Assicurati che il dispositivo in esame abbia una connessione stabile al computer host. Puoi controllare il file di registro per un test che mostri questi errori per vedere cosa sta ricevendo IDT.
+ Se usi FRQ 1.x.x e il dispositivo in test è connesso tramite una rete lenta o un'altra interfaccia, o non vedi il flag «---------STARTING TESTS---------» in un registro del gruppo di test FreerTOS insieme ad altri output del gruppo di test FreerTOS, puoi provare ad aumentare il valore di nella tua configurazione userdata. `testStartDelayms` Per ulteriori informazioni, consulta [Configurazione delle impostazioni di compilazione, flashing e test](cfg-dt-ud.md).
### Esegui il debug di un errore «Test failure:previsto \$1\$1 risultati ma sono stati rilevati \$1\$1\$1»
È possibile che vengano visualizzati errori che indicano un fallimento del test durante il test. Il test prevede un certo numero di risultati e non lo visualizza durante il test. Alcuni test FreerTOS vengono eseguiti prima che IDT veda l'output del dispositivo. *Se vedi questo errore, puoi provare ad aumentare il valore di `testStartDelayms` nella tua configurazione userdata.* Per ulteriori informazioni, consulta [Configurazione delle impostazioni di compilazione, flashing e test](lts-cfg-dt-ud.md).
### Esegui il debug di un errore «\$1\$1\$1\$1\$1\$1\$1\$1 non è stato selezionato a causa di vincoli» ConditionalTests
Ciò significa che stai eseguendo un test su un pool di dispositivi incompatibile con il test. Ciò può accadere con i test OTA E2E. **Ad esempio, durante l'esecuzione del gruppo di `OTADataplaneMQTT` test e nel file di `device.json` configurazione, hai scelto OTA come **No o `OTADataPlaneProtocol` come HTTP**.** Il gruppo di test scelto per l'esecuzione deve corrispondere alle `device.json` funzionalità selezionate.
### Esegui il debug di un timeout IDT durante il monitoraggio dell'output del dispositivo
IDT può andare in timeout per una serie di motivi. Se si verifica un timeout durante la fase di monitoraggio dell'output del dispositivo di un test e puoi vedere i risultati all'interno del registro dei casi di test IDT, significa che i risultati sono stati analizzati erroneamente da IDT. Uno dei motivi potrebbero essere i messaggi di registro interlacciati al centro dei risultati del test. In tal caso, consulta la [FreerTOS Porting](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-ota.html) Guide per ulteriori dettagli su come devono essere configurati i log UNITY.
Un altro motivo per cui si verifica un timeout durante il monitoraggio dell'output del dispositivo potrebbe essere il riavvio del dispositivo dopo un singolo errore del test case TLS. Il dispositivo esegue quindi l'immagine lampeggiata e provoca un ciclo infinito che viene visualizzato nei registri. In tal caso, assicurati che il dispositivo non si riavvii dopo un errore di test.
### Esegui il debug di un errore «accesso non autorizzato alla risorsa»
Potresti vedere l'errore "non *user/role* è autorizzato ad accedere a questa risorsa» nell'output del terminale o nel `test_manager.log` file sottostante`/results/execution-id/logs`. Per risolvere questo problema, associare la policy `AWS IoTDeviceTesterForFreeRTOSFullAccess` gestita all'utente del test. Per ulteriori informazioni, consulta [Crea e configura un account AWS](dev-tester-prereqs.md#config-aws-account).
### Esegui il debug degli errori dei test di rete
Per i test basati sulla rete, IDT avvia un server echo che si collega a una porta non riservata sul computer host. Se riscontri errori dovuti a timeout o connessioni non disponibili nei test WiFi o secure socket, assicurati che la rete sia configurata per consentire il traffico verso le porte configurate nell'intervallo 1024 - 49151.
Il test Secure Sockets utilizza le porte 33333 e 33334 per impostazione predefinita. Per impostazione predefinita, i WiFi test utilizzano la porta 33335. Se queste tre porte sono in uso o bloccate da firewall o rete, è possibile scegliere di utilizzare per il test porte diverse in userdata.json. Per ulteriori informazioni, consulta [Configurazione delle impostazioni di compilazione, flashing e test](cfg-dt-ud.md). È possibile utilizzare i seguenti comandi per verificare se una porta specifica è in uso:
+ Windows: `netsh advfirewall firewall show rule name=all | grep port`
+ Linux: `sudo netstat -pan | grep port`
+ macOS: `netstat -nat | grep port`
### Errori di aggiornamento OTA dovuti al payload della stessa versione
Se i test case OTA falliscono perché la stessa versione è presente sul dispositivo dopo l'esecuzione di un'OTA, potrebbe essere dovuto al fatto che il sistema di compilazione (ad esempio cmake) non ha notato le modifiche di IDT al codice sorgente di FreerTOS e non ha creato un binario aggiornato. Ciò fa sì che OTA venga eseguito con lo stesso file binario attualmente presente sul dispositivo e che il test non riesca. Per risolvere gli errori di aggiornamento OTA, assicurarsi per prima cosa di utilizzare la versione più recente supportata del sistema di compilazione.
### Errore del test OTA nel caso di test `PresignedUrlExpired`
Un prerequisito di questo test è che il tempo di aggiornamento OTA dovrebbe essere superiore a 60 secondi, altrimenti il test non riesce. In questo caso, nel log viene trovato il seguente messaggio di errore: "Test takes less than 60 seconds (url expired time) to finish. Please reach out to us." (Il test impiega meno di 60 secondi (tempo scadenza url) per terminare. Contattaci.)
### Esegui il debug dell'interfaccia del dispositivo e degli errori di porta
Questa sezione contiene informazioni sulle interfacce di dispositivo che IDT usa per connettersi ai tuoi dispositivi.
#### Piattaforme supportate
IDT supporta Linux, macOS e Windows. Le tre piattaforme hanno schemi di denominazione differenti per i dispositivi seriali a esse collegati:
+ Linux: `/dev/tty*`
+ macOS: `/dev/tty.*` o `/dev/cu.*`
+ Windows: COM\$1
Per verificare la porta del tuo dispositivo:
+ Per Linux e macOS, apri un terminale ed esegui `ls /dev/tty*`.
+ Per macOS, apri un terminale ed esegui `ls /dev/tty.*` o `ls /dev/cu.*`.
+ Per Windows, apri Device Manager ed espandi il gruppo di dispositivi seriali.
Per verificare quale dispositivo è collegato a una porta:
+ Per Linux, verifica che il pacchetto `udev` sia installato, quindi esegui `udevadm info –name=PORT`. Questa utilità stampa le informazioni relative al driver del dispositivo. Tali informazioni consentono di verificare se si sta utilizzando la porta corretta.
+ Per macOS, apri Launchpad e cerca **System Information**.
+ Per Windows, apri Device Manager ed espandi il gruppo di dispositivi seriali.
#### Interfacce del dispositivo
Ogni dispositivo incorporato è diverso, il che significa che possono avere una o più porte seriali. Se sono collegati a un computer, i dispositivi dispongono comunemente di due porte:
+ Una porta dati per le operazioni di flashing del dispositivo.
+ Una porta di lettura per la lettura dell'output.
Devi impostare la porta di lettura corretta nel file `device.json`. In caso contrario, la lettura dell'output dal dispositivo potrebbe restituire un errore.
In presenza di più porte, assicurati di utilizzare la porta di lettura del dispositivo nel file `device.json`. Ad esempio, se colleghi un WRover dispositivo Espressif e le due porte ad esso assegnate sono `/dev/ttyUSB0` e`/dev/ttyUSB1`, utilizzate `/dev/ttyUSB1` nel file. `device.json`
Per Windows, segui la stessa logica.
#### Lettura dei dati dal dispositivo
IDT for FreerTOS utilizza strumenti flash e di creazione di singoli dispositivi per specificare la configurazione delle porte. Se testando il dispositivo non ottieni un output, prova le seguenti impostazioni predefinite:
+ Velocità in baud: 115200
+ Bit di dati: 8
+ Parità: nessuna
+ Bit di stop: 1
+ Controllo di flusso: nessuno
Queste impostazioni sono gestite da IDT per FreerTOS. Non è necessario impostarle manualmente. Tuttavia, è possibile utilizzare lo stesso metodo per leggere manualmente l'output del dispositivo. In Linux o macOS lo puoi fare utilizzando il comando `screen`. In Windows, è possibile utilizzare un programma come. TeraTerm
`Screen: screen /dev/cu.usbserial 115200`
`TeraTerm: Use the above-provided settings to set the fields explicitly in the GUI.`
### Problemi nella toolchain di sviluppo
In questa sezione vengono illustrati i problemi che possono verificarsi con la toolchain.
#### Code Composer Studio su Ubuntu
Le versioni più recenti di Ubuntu (17.10 e 18.04) hanno una versione del pacchetto `glibc` che non è compatibile con Code Composer Studio versioni 7.*x*. Consigliamo di installare Code Composer Studio versione 8.2 o successive.
I seguenti sono alcuni dei possibili sintomi di incompatibilità:
+ FreerTOS non riesce a creare o eseguire il flashing sul tuo dispositivo.
+ L'installer di Code Composer Studio potrebbe bloccarsi.
+ Durante il processo di compilazione o flashing non viene visualizzato alcun output di log nella console.
+ Il comando build tenta l'avvio in modalità GUI anche quando richiamato in modalità headless.
### Registrazione dei log
I log di IDT for FreerTOS sono collocati in un'unica posizione. Nella directory root di IDT, questi file sono disponibili in `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` sono i log più importanti da esaminare. `FRQ_Report.xml` contiene informazioni sui casi di test non riusciti con un messaggio di errore specifico. È quindi possibile utilizzare `logs/test_group_id__test_case_id.log` per analizzare più a fondo il problema per ottenere un contesto migliore.
#### Errori della console
Quando AWS IoT Device Tester viene eseguito, gli errori vengono segnalati alla console con brevi messaggi. Cerca in `results/execution-id/logs/test_group_id__test_case_id.log` ulteriori informazioni sull'errore.
#### Errori di log
Ogni esecuzione della suite di test ha un ID di esecuzione univoco che viene utilizzato per creare una cartella denominata `results/execution-id`. I log dei singoli casi di test sono disponibili nella directory `results/execution-id/logs`. Usa l'output della console IDT for FreerTOS per trovare l'id di esecuzione, l'id del test case e l'id del gruppo di test del test case che ha avuto esito negativo. Utilizzate quindi queste informazioni per trovare e aprire il file di registro per il test case denominato. `results/execution-id/logs/test_group_id__test_case_id.log` Le informazioni contenute in questo file includono l'output completo dei comandi di build e flash, l'output di esecuzione del test e l'output più dettagliato AWS IoT Device Tester della console.
#### Problemi con i bucket S3
Se si preme CTRL\$1C durante l'esecuzione di IDT, IDT avvierà un processo di pulizia. Parte di questa pulizia consiste nella rimozione delle risorse Amazon S3 che sono state create come parte dei test IDT. Se la pulizia non riesce a terminare, potresti riscontrare un problema a causa del numero eccessivo di bucket Amazon S3 creati. Ciò significa che la prossima volta che eseguirai IDT, i test inizieranno a fallire.
Se si preme CTRL\$1C per interrompere IDT, è necessario lasciarlo terminare il processo di pulizia per evitare questo problema. Puoi anche eliminare i bucket Amazon S3 dal tuo account che sono stati creati manualmente.
## Risolvi gli errori di timeout
Se si verificano errori di timeout durante l'esecuzione di una suite di test, aumentare il timeout specificando un fattore di moltiplicatore di timeout. Questo fattore viene applicato al valore di timeout predefinito. Qualsiasi valore configurato per questo flag deve essere maggiore o uguale a 1.0. Per usare il moltiplicatore di timeout, utilizzare il flag `--timeout-multiplier` durante l'esecuzione dei test.
**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
```
## Funzionalità e costi del cellulare AWS
Quando la `Cellular` funzionalità è impostata `Yes` nel tuo `device.JSON` file, FullSecureSockets utilizzerà le istanze t.micro EC2 per eseguire i test e ciò potrebbe comportare costi aggiuntivi per il tuo account. AWS Per ulteriori informazioni, consulta [Prezzi di Amazon EC2](https://aws.amazon.com/ec2/pricing/).
## Politica di generazione dei report di qualificazione
I report sulle qualifiche vengono generati solo da versioni AWS IoT Device Tester (IDT) che supportano le versioni FreerTOS rilasciate negli ultimi due anni. Se avete domande sulla politica di supporto, contattateci. [Supporto AWS](https://aws.amazon.com/contact-us/)
# Comprendi la politica AWS gestita per AWS IoT Device Tester
Una politica AWS gestita è una politica autonoma creata e amministrata da AWS. AWS le politiche gestite sono progettate per fornire autorizzazioni per molti casi d'uso comuni, in modo da poter iniziare ad assegnare autorizzazioni a utenti, gruppi e ruoli.
Tieni presente che le policy AWS gestite potrebbero non concedere le autorizzazioni con il privilegio minimo per i tuoi casi d'uso specifici, poiché sono disponibili per tutti i clienti. AWS Si consiglia pertanto di ridurre ulteriormente le autorizzazioni definendo [policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) specifiche per i propri casi d'uso.
Non è possibile modificare le autorizzazioni definite nelle politiche gestite. AWS Se AWS aggiorna le autorizzazioni definite in una politica AWS gestita, l'aggiornamento ha effetto su tutte le identità principali (utenti, gruppi e ruoli) a cui è associata la politica. AWS è più probabile che aggiorni una policy AWS gestita quando ne Servizio AWS viene lanciata una nuova o quando diventano disponibili nuove operazioni API per i servizi esistenti.
Per ulteriori informazioni, consultare [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) nella *Guida per l'utente di IAM*.
**Topics**
+ [AWS politica gestita: AWS Io TDevice TesterForFree RTOSFull Access](#aws-managed-policies-AWSIoTDT)
+ [Aggiornamenti alle politiche gestite AWS](#aws-managed-policy-updates)
## AWS politica gestita: AWS Io TDevice TesterForFree RTOSFull Access
La policy `AWSIoTDeviceTesterForFreeRTOSFullAccess` gestita contiene le seguenti AWS IoT Device Tester autorizzazioni per il controllo della versione, le funzionalità di aggiornamento automatico e la raccolta di metriche.
**Dettagli dell’autorizzazione**
Questa policy include le seguenti autorizzazioni:
+ `iot-device-tester:SupportedVersion`
Concede AWS IoT Device Tester l'autorizzazione a recuperare l'elenco dei prodotti supportati, delle suite di test e delle versioni IDT.
+ `iot-device-tester:LatestIdt`
Concede AWS IoT Device Tester l'autorizzazione a recuperare l'ultima versione IDT disponibile per il download.
+ `iot-device-tester:CheckVersion`
Concede AWS IoT Device Tester l'autorizzazione a verificare la compatibilità delle versioni per IDT, suite di test e prodotti.
+ `iot-device-tester:DownloadTestSuite`
Concede AWS IoT Device Tester l'autorizzazione a scaricare gli aggiornamenti della suite di test.
+ `iot-device-tester:SendMetrics`
Concede AWS l'autorizzazione a raccogliere metriche sull' AWS IoT Device Tester utilizzo 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"
]
}
}
}
]
}
```
------
## Aggiornamenti alle politiche gestite AWS
Puoi visualizzare i dettagli sugli aggiornamenti delle politiche AWS gestite AWS IoT Device Tester dal momento in cui questo servizio ha iniziato a tenere traccia di queste modifiche.
| Versione | Modifica | Descrizione | Data |
| --- | --- | --- | --- |
| 7 (Più recente) | Ha ristrutturato le `ec2:CreateTags` condizioni. | Rimozione dell'uso di. `ForAnyValues` | 14/06/2023 |
| 6 | Rimosso `freertos:ListHardwarePlatforms` dalla politica. | Rimozione delle autorizzazioni poiché questa azione è obsoleta a partire dal 1° marzo 2023. | 02/06/2023 |
| 5 | Sono state aggiunte le autorizzazioni per eseguire i test del server echo utilizzando EC2. | Serve per avviare e arrestare un'istanza EC2 negli account dei clienti. AWS | 15/12/2020 |
| 4 | Aggiunto `iot:CancelJobExecution`. | Questa autorizzazione annulla i lavori OTA. | 17/07/2020 |
| 3 | Aggiunte le seguenti autorizzazioni: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/security-iam-aws-managed-policies.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/freertos/latest/userguide/security-iam-aws-managed-policies.html) | 23/03/2020 |
| 2 | Autorizzazioni aggiunte. `iot-device-tester:SendMetrics` | Concede AWS l'autorizzazione a raccogliere metriche sull' AWS IoT Device Tester utilizzo interno. | 18/02/2020 |
| 1 | Versione iniziale. | | 2/12/2020 |
# Comprendi la politica di supporto per AWS IoT Device Tester
**Importante**
A ottobre 2022, AWS IoT Device Tester per AWS IoT FreerTOS Qualification (FRQ) 1.0 non genera report di qualificazione firmati. Non è possibile qualificare nuovi dispositivi AWS IoT FreerTOS da inserire nel [Partner Device Catalog tramite AWS il Device](https://partners.amazonaws.com/qualified-devices) [Qualification Program utilizzando AWS le versioni](https://aws.amazon.com/partners/programs/dqp/) IDT FRQ 1.0. Sebbene non sia possibile qualificare i dispositivi FreerTOS utilizzando IDT FRQ 1.0, è possibile continuare a testare i dispositivi FreerTOS con FRQ 1.0. [Ti consigliamo di utilizzare [IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) per qualificare ed elencare i dispositivi FreerTOS nel Partner Device Catalog.AWS](https://partners.amazonaws.com/qualified-devices)
AWS IoT Device Tester for FreerTOS è uno strumento di automazione dei test per convalidare la porta FreerTOS sui dispositivi. [Inoltre puoi [qualificare](https://aws.amazon.com/partners/programs/dqp/) i tuoi dispositivi FreerTOS ed elencarli nel Partner Device Catalog.AWS](https://partners.amazonaws.com/qualified-devices) [https://github.com/FreeRTOS/FreeRTOS-LTS](https://github.com/FreeRTOS/FreeRTOS-LTS) Ti consigliamo di utilizzare le versioni più recenti di FreeRTOS e FreerTOS AWS IoT Device Tester per convalidare e qualificare i tuoi dispositivi.
Per FreerTOS-LTS, IDT supporta la convalida e la qualificazione della versione FreeRTOS 202210 LTS. Vedi qui per maggiori informazioni sulle versioni di [FreerTOS LTS](https://www.freertos.org/lts-libraries.html) e sulla loro tempistica di manutenzione. Una volta terminato il periodo di supporto di queste versioni LTS, puoi comunque continuare la convalida, ma IDT non genererà un rapporto che ti consenta di inviare il tuo dispositivo per la qualificazione.
Per i FreerTOS principali disponibili [su](https://github.com/FreeRTOS/FreeRTOS) FreerTOS/FreeRTOS, supportiamo la convalida e la qualificazione di tutte le versioni rilasciate negli ultimi sei mesi o delle due versioni precedenti di FreerTOS se rilasciate a più di sei mesi di distanza. [Vedi]( https://docs.aws.amazon.com//freertos/latest/userguide/dev-test-versions-afr.html) qui per le versioni attualmente supportate. Per le versioni non supportate di FreerTOS, puoi comunque continuare la convalida, ma IDT non genererà un rapporto che ti consentirà di inviare il tuo dispositivo per la qualificazione.
Vedi [Versioni supportate di AWS IoT Device Tester](dev-test-versions-afr.md) le ultime versioni supportate di IDT e FreerTOS. Puoi utilizzare una qualsiasi delle versioni supportate di AWS IoT Device Tester con la versione corrispondente di FreerTOS per testare o qualificare il tuo dispositivo. Se continui a utilizzare[Versioni IDT non supportate per FreerTOS](idt-unsupported-versions-afr.md), non riceverai le correzioni di bug o gli aggiornamenti più recenti.
Per domande sulla politica di supporto, contatta l'[assistenza AWS clienti](https://aws.amazon.com/contact-us/).