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à.
# Usa IDT per sviluppare ed eseguire le tue suite di test
A partire da IDT v4.0.1, IDT per AWS IoT Greengrass V2 combina una configurazione di configurazione e un formato di risultati standardizzati 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 Greengrass 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 for AWS IoT Device Tester AWS IoT Greengrass
Scaricate l'[ultima versione](idt-programmatic-download.md) di IDT ed estraete il software in una posizione (**) del file system in cui disponete delle autorizzazioni di lettura/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.
## Flusso di lavoro per la creazione della suite
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.
+ Esegui il test dei file eseguibili utilizzati da IDT per eseguire i test case.
+ 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](create-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-custom-idt-config.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-debug-custom-tests.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 e capire come utilizzare IDT per AWS IoT Greengrass eseguire suite di test personalizzate.
In questo tutorial, completerai i seguenti passaggi:
1. [Crea la suite di test di esempio](#build-sample)
1. [Usa IDT per eseguire la suite di test di esempio](#run-sample)
## Prerequisiti
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).
+ [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.org/documentation/remote-access/ssh/) 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
```
------
In questo modo viene creata 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 per test case e file JSON 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) 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 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 dei problemi
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 trasmette 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)
**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:
+ Eseguibili di test che contengono la logica di test
+ File di configurazione che descrivono la suite di test
Questo tutorial mostra come usare IDT per AWS IoT Greengrass sviluppare una suite di test Python che contenga un singolo test case. In questo tutorial, completerai i seguenti passaggi:
1. [Crea una directory per la suite di test](#test-suite-dir)
1. [Crea file di configurazione](#test-suite-json)
1. [Crea l'eseguibile del test case](#test-suite-exe)
1. [Esegui la suite di test](#run-test-suite)
## Prerequisiti
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).
+ [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.org/documentation/remote-access/ssh/) 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 tua suite di test deve contenere i seguenti [file di configurazione](idt-json-config.md) richiesti:File di configurazione 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
Utilizzi l'[SDK del client IDT](create-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 del 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 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 dei problemi
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 trasmette 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 questo passaggio.](#add-idt-sdk)
+ Soddisfi tutti i [prerequisiti](#prereqs-tutorial-custom) per questo tutorial.
**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 create i file di configurazione da includere quando scrivete 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.1, 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-custom-idt-config.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`
Facoltativo. 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 può 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`
Facoltativo. 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 eseguibili per test case IDT](create-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 può 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`
Facoltativo. 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`
Facoltativo. 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`
Facoltativo. 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`
Facoltativo. 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 eseguibili per test case IDT](create-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`
Facoltativo. Gli argomenti da fornire per eseguire l'eseguibile del test case.
`environmentVariables`
Facoltativo. 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 orchestrator 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. [Configurare 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.html#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-state-machine.md#state-machine-context)
# Configurare l'orchestrator di test IDT
*A partire da IDT v4.5.1, 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.
L'orchestrator di test sostituisce l'orchestrator di test IDT. Ti consigliamo vivamente di utilizzare l'orchestrator di test per sviluppare le tue suite di test anziché l'orchestrator di test 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: `/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`
Facoltativo. 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`
Facoltativo. 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 casi di test 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ù casi di test 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`
Facoltativo. 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 Esempi**
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`
Facoltativo. 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`
Facoltativo. 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, consulta 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`
Facoltativo. 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`
Facoltativo. 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`.
**Example**
## Contesto dell'orchestratore di test
Il contesto di test orchestrator è un documento JSON di sola lettura che contiene dati disponibili per l'orchestrator di test 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.1, questa macchina a stati è obsoleta. Ti consigliamo vivamente di utilizzare il nuovo orchestrator di test. Per ulteriori informazioni, consulta [Configurare 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` `state_machine.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](create-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 stato della filiale 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 filiale. 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. Si tratta di uno stato finale per la 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 eseguibili per test case IDT
È possibile creare e inserire gli eseguibili dei test case in una cartella di test suite 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 tuo 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, l'orchestrator di test per la suite di test deve includere un set specifico di `Choice` stati nell'orchestrator di `RunTask` test. Se non utilizzate una macchina a stati personalizzata, l'orchestrator di test IDT predefinito include gli stati richiesti e non è necessario intraprendere ulteriori azioni. Tuttavia, se utilizzi un orchestrator di test personalizzato, utilizzalo [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 nel tuo orchestrator di test.
Per ulteriori informazioni sui comandi CLI IDT, vedere. [Esegui il debug ed esegui suite di test personalizzate](run-debug-custom-tests.md)
## Scrivere registri degli eventi
Durante l'esecuzione del test, invii dati `stdout` e `stderr` scrivi 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 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 un set di dati che possono essere utilizzati per determinare la modalità di 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
},
"device": {
},
"devicePool": {
},
"resource": {
"devices": [
{
"name": ""
}
]
},
"testData": {
"awsCredentials": {
"awsAccessKeyId": "",
"awsSecretAccessKey": "",
"awsSessionToken": ""
},
"logFilePath": "/path/to/log/file"
},
"userData": {
}
}
```
`config`
Informazioni dal [`config.json`file](set-custom-idt-config.md#config-json-custom). Il `config` campo contiene anche il seguente campo aggiuntivo:
`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`.
`device`
Informazioni sul dispositivo selezionato per l'esecuzione del test. Queste informazioni sono equivalenti all'elemento dell'`devices`array nel [`device.json`file](set-custom-idt-config.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-custom-idt-config.md#userdata-config-custom).
## Accedere ai dati nel contesto
Puoi interrogare il contesto utilizzando la JSONPath notazione dei tuoi file JSON e del tuo file eseguibile di testo con and. `GetContextValue` `GetContextString` APIs La sintassi con cui le JSONPath 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`test_orchestrator.yaml`, si usa`{{query}}`.
Se usi la macchina a stati deprecata, allora in`state_machine.json`, usi. `{{$.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 di un' JSONPathespressione tipica:
| Operatore | Descrizione |
| --- |--- |
| \$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 secondario con il nome childName di un oggetto. Se applicato a un array, restituisce 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 stringhe.
+ 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.
# Configurare 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-debug-custom-tests.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": "",
"connectivity": {
"protocol": "ssh | uart | docker",
// ssh
"ip": "",
"port": ,
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
// pki
"privKeyPath": "/path/to/private/key",
// password
"password": "",
}
},
// uart
"serialPort": "",
// docker
"containerId": "",
"containerUser": "",
}
}
]
}
]
```
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 nella procedura di pubblicazione.
`features`
Facoltativo. 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) di [test orchestrator](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.
`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`
Facoltativo. 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.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`
Facoltativo. 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 `ssh`.
`connectivity.containerUser`
Facoltativo. 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 `ssh`.
Per verificare se i test runner configurano la connessione errata del dispositivo per un test, puoi recuperarlo `pool.Devices[0].Connectivity.Protocol` dal contesto del test orchestrator e confrontarlo con il valore previsto in uno stato. `Choice` Se viene utilizzato un protocollo errato, stampa un messaggio utilizzando `LogMessage` lo stato e passa allo stato. `Fail`
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 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 ad esso. 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": ,
"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`
Facoltativo. 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`
Facoltativo. 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.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`
Facoltativo. 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 `ssh`.
`connectivity.containerUser`
Facoltativo. 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 `ssh`.
## (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 [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`
Facoltativo. 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-custom-idt-config.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 AWS IoT Greengrass qualificazione su un Raspberry Pi 3B.
Durante la scrittura della suite di test, è possibile utilizzare 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à di 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à di 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 JSON 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 in base alle esigenze.
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 versione di IDT in uso, in questo caso AWS IoT Greengrass le versioni, e le versioni della suite di test di AWS IoT Greengrass qualificazione 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à di 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 report dei 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.
```
time="2000-01-02T03:04:05-07:00" level=info msg=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.
```
time="2000-01-02T03:04:05-07:00" level=info msg=Hello world! suiteId=MyTestSuite
groupId=myTestGroup testCaseId=myTestCase deviceId=my-device
executionId=9a52f362-1227-11eb-86c9-8c8590419f30
```
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.
Per stampare un riepilogo del test sulla console quando un IDT termina l'esecuzione di un test, è necessario includere uno [`Report`stato](idt-state-machine.md#state-report) nel test orchestrator. 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 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 per consentire alla suite di test di 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. Per 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. Per 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. Per 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. Per esempio:
```
Reason for the test failure
Reason for the test execution error
```
# 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' Account AWS ID utilizzato per eseguire IDT
+ I AWS CLI comandi IDT utilizzati per eseguire i test
+ Le suite di test che vengono eseguite
+ 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.
## Configura le tue credenziali AWS
Se non ne hai già uno Account AWS, devi [crearne uno](#idt-metrics-aws-account). Se ne hai già uno Account AWS, devi semplicemente [configurare le autorizzazioni richieste per il](#idt-metrics-permissions) tuo account che consentano a IDT di inviare le metriche di utilizzo AWS a tuo nome.
### Fase 1: Creare un Account AWS
In questo passaggio, crea e configura un Account AWS. Se disponi già di un Account AWS, passa a [Fase 2: configurazione delle autorizzazioni per IDT](#idt-metrics-permissions).
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).
Per creare un utente amministratore, scegli una delle seguenti opzioni.
****
| Scelta di un modo per gestire il tuo amministratore | Per | Come | Puoi anche |
| --- | --- | --- | --- |
| In IAM Identity Center (Consigliato) | Usa credenziali a breve termine per accedere a AWS.Ciò è in linea con le best practice per la sicurezza. Per informazioni sulle best practice, consulta [Best practice per la sicurezza in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) nella *Guida per l'utente di IAM*. | Segui le istruzioni riportate in [Nozioni di base](https://docs.aws.amazon.com//singlesignon/latest/userguide/getting-started.html) nella Guida per l'utente di AWS IAM Identity Center . | Configura l'accesso programmatico [configurando l'uso AWS IAM Identity Center nella Guida AWS CLI per](https://docs.aws.amazon.com//cli/latest/userguide/cli-configure-sso.html) l'AWS Command Line Interface utente. |
| In IAM (Non consigliato) | Usa credenziali a lungo termine per accedere a AWS. | Segui le istruzioni in [Creare un utente IAM per l’accesso di emergenza](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started-emergency-iam-user.html) nella Guida per l’utente di IAM. | Configura l’accesso programmatico seguendo quanto riportato in [Gestione delle chiavi di accesso per gli utenti IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html) nella Guida per l’utente di IAM. |
### Fase 2: configurazione delle autorizzazioni per IDT
In questo passaggio, configura le autorizzazioni utilizzate da IDT per eseguire test e raccogliere dati sull'utilizzo di IDT. Puoi utilizzare Console di gestione AWS or AWS Command Line Interface (AWS CLI) per creare una policy IAM e un utente per IDT, quindi allegare le policy all'utente.
+ [Per configurare le autorizzazioni per IDT (Console)](#idt-metrics-permissions-console)
+ [Per configurare le autorizzazioni per IDT (AWS CLI)](#idt-metrics-permissions-cli)
**Per configurare le autorizzazioni per IDT (Console)**
Attenersi alla seguente procedura per utilizzare la console per configurare le autorizzazioni per IDT per AWS IoT Greengrass.
1. Accedere alla [console IAM](https://console.aws.amazon.com/iam).
1. Creare un criterio gestito dal cliente che concede le autorizzazioni per creare ruoli con autorizzazioni specifiche.
1. Nel pannello di navigazione, scegli **Policy** e **Crea policy**.
1. Nella scheda **JSON**, sostituire il contenuto del segnaposto con la seguente policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iot-device-tester:SendMetrics"
],
"Resource": "*"
}
]
}
```
------
1. Scegliere **Esamina policy**.
1. In **Nome**, inserisci **IDTUsageMetricsIAMPermissions**. In **Riepilogo**, esaminare le autorizzazioni concesse dai criteri.
1. Scegli **Crea policy**.
1. Crea un utente IAM e assegna le autorizzazioni all'utente.
1. Crea un utente IAM. Segui i passaggi da 1 a 5 in [Creazione di utenti IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) nella *Guida per l'utente IAM*. Se hai già creato un utente IAM, vai al passaggio successivo.
1. Allega le autorizzazioni al tuo utente IAM:
1. Nella pagina **Imposta autorizzazioni**, seleziona **Collega direttamente policy esistenti**.
1. Cerca la IAMPermissions policy **IDTUsageMetrics** che hai creato nel passaggio precedente. Selezionare la casella di controllo.
1. Scegli **Successivo: Tag**.
1. Scegliere **Next:Review** per visualizzare un riepilogo delle tue scelte.
1. Selezionare **Create user (Crea utente)**.
1. Per visualizzare le chiavi di accesso dell'utente (chiave di accesso IDs e chiavi di accesso segrete), scegli **Mostra** accanto alla password e alla chiave di accesso. Per salvare le chiavi di accesso, scegliere **Scarica .csv** e salvare il file in una posizione sicura. Utilizzerai queste informazioni in seguito per configurare il file AWS delle credenziali.
**Per configurare le autorizzazioni per IDT (AWS CLI)**
Segui questi passaggi per utilizzare il file AWS CLI per configurare le autorizzazioni per IDT. AWS IoT Greengrass
1. Sul tuo computer, installa e configura il file AWS CLI se non è già installato. Segui la procedura descritta in [Installazione di AWS CLI nella](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) *Guida AWS Command Line Interface per l'utente*.
**Nota**
AWS CLI È uno strumento open source che puoi utilizzare per interagire con AWS i servizi dalla tua shell a riga di comando.
1. Crea la seguente politica gestita dai clienti che concede le autorizzazioni per gestire IDT e ruoli. AWS IoT Greengrass
------
#### [ Linux or Unix ]
```
aws iam create-policy --policy-name IDTUsageMetricsIAMPermissions --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iot-device-tester:SendMetrics"
],
"Resource": "*"
}
]
}'
```
------
#### [ Windows command prompt ]
```
aws iam create-policy --policy-name IDTUsageMetricsIAMPermissions --policy-document
'{\"Version\": \"2012-10-17\", \"Statement\": [{\"Effect\": \"Allow\", \"Action\": [\"iot-device-tester:SendMetrics\"], \"Resource": \"*\"}]}'
```
**Nota**
Questo passaggio include un esempio del prompt dei comandi di Windows perché utilizza una sintassi JSON diversa rispetto ai comandi del terminale Linux, macOS o Unix.
------
#### [ PowerShell ]
```
aws iam create-policy --policy-name IDTUsageMetricsIAMPermissions --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iot-device-tester:SendMetrics"
],
"Resource": "*"
}
]
}'
```
------
1. Crea un utente IAM e allega le autorizzazioni richieste da IDT for. AWS IoT Greengrass
1. Crea un utente IAM.
```
aws iam create-user --user-name user-name
```
1. Allega la `IDTUsageMetricsIAMPermissions` policy che hai creato al tuo utente IAM. Sostituiscila *user-name* con il tuo nome utente IAM e ** nel comando con l'ID del tuo Account AWS.
```
aws iam attach-user-policy --user-name user-name --policy-arn arn:aws:iam:::policy/IDTGreengrassIAMPermissions
```
1. Creare una chiave di accesso segreta per l'utente.
```
aws iam create-access-key --user-name user-name
```
Memorizzare l'output in una posizione sicura. Utilizzerai queste informazioni in seguito per configurare il file AWS delle credenziali.
## Fornisci le 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 i seguenti comandi.
------
#### [ Linux or Unix ]
```
export AWS_ACCESS_KEY_ID=access-key
export AWS_SECRET_ACCESS_KEY=secret-access-key
```
------
#### [ Windows Command Prompt (CMD) ]
```
set AWS_ACCESS_KEY_ID=access-key
set AWS_SECRET_ACCESS_KEY=secret-access-key
```
------
#### [ PowerShell ]
```
$env:AWS_ACCESS_KEY_ID="access-key"
$env: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-custom-idt-config.md#config-json-custom).