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à.
# 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.