Crea file eseguibili per test case IDT - AWS IoT Greengrass
Usa l'IDT Client SDKAbilita i comandi IDT CLI IDTScrivere registri degli eventiSegnala i risultati a IDTSpecifica il comportamento di uscita

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 file eseguibili per test case IDT

È possibile creare e inserire gli eseguibili dei test case in una cartella della suite di test nei seguenti modi:

  • Per le suite di test che utilizzano argomenti o variabili di ambiente daitest.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 si desidera eseguire test specifici in base a comandi specificati, si crea un test case eseguibile per ogni test case nella suite di test.

In qualità di autore di test, puoi determinare quale approccio è appropriato per il tuo caso d'uso e strutturare di conseguenza il tuo test case eseguibile. Assicurati di fornire il percorso eseguibile del test case corretto in ognitest.json file e che l'eseguibile specificato venga eseguito correttamente.

Quando tutti i dispositivi sono pronti per l'esecuzione di un test case, IDT legge i seguenti file:

  • Il test casetest.json per il test selezionato determina i processi da avviare e le variabili di ambiente da impostare.

  • La suitesuite.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 neltest.json file e passa le variabili di ambiente richieste al processo.

Usa l'IDT Client SDK

Gli IDT Client SDK consentono di semplificare il modo in cui si scrive la logica di test nell'eseguibile di test con comandi API che è possibile utilizzare per interagire con IDT e i dispositivi in fase di test. IDT attualmente fornisce i seguenti SDK:

  • SDK per Python

  • SDK for Go di DAF per Go

  • SDK for Java

Questi SDK si trovano nella<device-tester-extract-location>/sdks cartella. Quando si crea un nuovo eseguibile del test case, è necessario copiare l'SDK che si desidera utilizzare nella cartella contenente l'eseguibile del test case e fare riferimento all'SDK nel codice. Questa sezione fornisce una breve descrizione dei comandi API disponibili che puoi utilizzare negli eseguibili del test case.

Interazione dei dispositivi

I seguenti comandi consentono di comunicare con il dispositivo in prova senza dover implementare funzioni aggiuntive di interazione del dispositivo e 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 realizzate utilizzando le informazioni di accesso ai dispositivi dal contesto, consigliamo di utilizzare questi comandi API di interazione con i dispositivi negli eseguibili del test case. Tuttavia, se questi comandi non soddisfano i requisiti del test case, puoi 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, recupera le informazioni nei campidevice.connectivity eresource.devices.connectivity nei campi rispettivamente per il dispositivo sottoposto a test e per i dispositivi di risorse. Per ulteriori informazioni sull'utilizzo del contesto IDT, consultaUsa il contesto IDT.

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.

SendResult

Consente alle suite di test di segnalare i risultati dei test case all'IDT. Questo comando deve essere chiamato alla fine di ogni test case in una suite di test.

Interazione dell'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.

ExecuteOnHost

Consente alle suite di test di eseguire comandi sul computer locale e consente a IDT di gestire il ciclo di vita dell'eseguibile del test case.

Abilita i comandi IDT CLI IDT

Ilrun-suite comando IDT CLI fornisce diverse opzioni che consentono al test runner di personalizzare l'esecuzione del test. Per consentire ai test runner di utilizzare queste opzioni per eseguire la tua suite di test personalizzata, implementi il supporto per l'IDT CLI. 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 offrire un'esperienza cliente ideale, si consiglia di implementare il supporto per i seguenti argomenti delrun-suite comando nella CLI IDT:

timeout-multiplier

Specifica 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 casi di test che desiderano eseguire. Quando un test runner specifica questo argomento nel propriorun-suite comando, IDT lo utilizza per calcolare il valore della variabile di ambiente IDT_TEST_TIMEOUT e imposta ilconfig.timeoutMultiplier campo nel contesto IDT. Per supportare questa argomentazione, è necessario eseguire le operazioni indicate di seguito:

  • Invece di utilizzare direttamente il valore di timeout daltest.json file, leggi la variabile di ambiente IDT_TEST_TIMEOUT per ottenere il valore di timeout calcolato correttamente.

  • Recupera ilconfig.timeoutMultiplier valore dal contesto IDT e applicalo a timeout di lunga durata.

Per ulteriori informazioni sull'uscita anticipata a causa di eventi di timeout, consultaSpecifica il comportamento di uscita.

stop-on-first-failure

Specifica che IDT deve interrompere l'esecuzione di tutti i test in caso di errore.

Quando un test runner specifica questo argomento nel propriorun-suite comando, IDT interromperà l'esecuzione dei test non appena riscontra un errore. Tuttavia, se i casi di test vengono eseguiti in parallel, ciò può portare a risultati imprevisti. Per implementare il supporto, assicurati che se IDT rileva questo evento, la logica del test indichi a tutti i casi di test in esecuzione di interrompersi, ripulire le risorse temporanee e segnalare un risultato del test a IDT. Per ulteriori informazioni sull'errori dei processi, consultaSpecifica il comportamento di uscita.

group-id e test-id

Specifica che IDT deve eseguire solo i gruppi di test o i casi di test selezionati.

I test runner possono utilizzare questi argomenti con il lororun-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'orchestratore di test per la tua suite di test deve includere un set specifico diRunTask eChoice stati nel tuo orchestratore di test. Se non si utilizza una macchina a stati personalizzata, l'orchestratore di test IDT predefinito include automaticamente gli stati richiesti e non è necessario eseguire ulteriori azioni. Tuttavia, se utilizzi un orchestratore di test personalizzato, utilizzaloEsempio della macchina a stati: Esegui gruppi di test selezionati dall'utente come campione per aggiungere gli stati richiesti nel tuo orchestratore di test.

Per ulteriori informazioni sui comandi CLI IDT, consultaEsegui il debug ed esegui suite di test personalizzate.

Scrivere registri degli eventi

Mentre il test è in esecuzione, si inviano datistdout e si scrivonostderr i registri degli eventi e i messaggi di errore alla console. Per informazioni sul formato di messaggi della console, consultaFormato dei messaggi della console.

Quando l'IDT termina l'esecuzione della suite di test, queste informazioni sono disponibili anche neltest_manager.log file che si trova nella<devicetester-extract-location>/results/<execution-id>/logs cartella.

È possibile configurare ogni test case per scrivere i registri dell'esecuzione del test, inclusi i registri del dispositivo sottoposto a test, nel<group-id>_<test-id> file che si trova nella<device-tester-extract-location>/results/execution-id/logs cartella. A tale scopo, recupera il percorso del file di registro dal contesto IDT con latestData.logFilePath query, crea un file in quel percorso e scrivi il contenuto che desideri. IDT aggiorna automaticamente il percorso in base al test case in esecuzione. Se scegli di non creare il file di registro per un test case, non viene generato alcun file per quel test case.

Puoi anche configurare il tuo eseguibile di testo per creare file di registro aggiuntivi, se necessario, nella<device-tester-extract-location>/logs cartella. Si consiglia 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 fileawsiotdevicetester_report.xml e neisuite-name_report.xml file. Questi file di report si trovano in<device-tester-extract-location>/results/<execution-id>/. Entrambi i report acquisiscono i risultati dell'esecuzione della suite di test. Per ulteriori informazioni sugli schemi utilizzati da IDT per questi report, vedereRivedi i risultati e i registri dei test

Per compilare il contenuto delsuite-name_report.xml file, è necessario utilizzare ilSendResult comando per segnalare i risultati del test a IDT prima del termine dell'esecuzione del test. Se IDT non è in grado di individuare i risultati di un test, emette un errore per il test case. Il seguente estratto di Python mostra i comandi per inviare un risultato del test a IDT:

request-variable = SendResultRequest(TestResult(result))
client.send_result(request-variable)

Se non si segnalano i risultati tramite l'API, IDT cerca i risultati dei test nella cartella degli artefatti del test. Il percorso di questa cartella ètestData.testArtifactsPath memorizzato nel campo nel contesto IDT. In questa cartella, IDT utilizza il primo file XML in ordine alfabetico che trova come risultato del test.

Se la logica del test produce risultati XML JUnit, puoi scrivere i risultati del test in un file XML nella cartella degli artefatti per fornire direttamente i risultati a IDT invece di analizzarli e quindi utilizzare l'API per inviarli a IDT.

Se utilizzi questo metodo, assicurati che la logica del test riassuma accuratamente i risultati del test e formatti il file dei risultati nello stesso formato delsuite-name_report.xml file. IDT non esegue alcuna convalida dei dati forniti, con le seguenti eccezioni:

  • IDT ignora tutte le proprietà deltestsuites tag. Invece, calcola le proprietà dei tag in base ai risultati di altri gruppi di test riportati.

  • Al suo interno deve essere presente almeno untestsuite tagtestsuites.

Poiché IDT utilizza la stessa cartella degli artefatti per tutti i casi di test e non elimina i file dei risultati tra le esecuzioni del test, questo metodo potrebbe anche portare a segnalazioni errate se IDT legge il file errato. Ti consigliamo 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 assicurarti che i risultati corretti siano disponibili per l'uso da IDT. Sebbene sia possibile utilizzare un approccio misto alla creazione di report nella suite di test, 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.

Specifica il comportamento di uscita

Configura il tuo eseguibile di testo in modo che esca sempre con un codice di uscita pari a 0, anche se un test case riporta un errore o un risultato di errore. Utilizza codici di uscita diversi da zero solo per indicare che un test case non è stato eseguito o se l'eseguibile del test case non è stato 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 che sia terminato nei seguenti eventi. Utilizza queste informazioni per configurare l'eseguibile del test case per rilevare ciascuno di questi eventi dal test case:

Timeout

Si verifica quando un test case viene eseguito per un periodo superiore al valore di timeout specificato neltest.json file. Se il test runner ha utilizzato l'timeout-multiplierargomento per specificare un moltiplicatore di timeout, IDT calcola il valore di timeout con il moltiplicatore.

Per rilevare questo evento, utilizzare la variabile di ambiente IDT_TEST_TIMEOUT. Quando un test runner avvia un test, IDT imposta il valore della variabile di ambiente IDT_TEST_TIMEOUT sul valore di timeout calcolato (in secondi) e passa la variabile all'eseguibile del test case. Puoi leggere il valore della variabile per impostare un timer appropriato.

Interrompere

Si verifica quando il test runner interrompe l'IDT. Ad esempio, premendoCtrl+C.

Poiché i terminali propagano i segnali a tutti i processi secondari, è sufficiente configurare un gestore di segnali nei casi di test per rilevare i segnali di interruzione.

In alternativa, puoi interrogare periodicamente l'API per verificare il valore delCancellationRequested booleano nella risposta dell'PollForNotificationsAPI. Quando IDT riceve un segnale di interruzione, imposta il valore delCancellationRequested booleano sutrue.

Stop al primo fallimento

Si verifica quando un test case in esecuzione in parallel al test case corrente fallisce e il test runner utilizza l'stop-on-first-failureargomento per specificare che IDT deve interrompersi in caso di errore.

Per rilevare questo evento, puoi periodicamente interrogare l'API per verificare il valore delCancellationRequested booleano nella risposta dell'PollForNotificationsAPI. Quando IDT rileva un errore ed è configurato per interrompersi al primo errore, imposta il valore delCancellationRequested booleano sutrue.

Quando si verifica uno di questi eventi, IDT attende 5 minuti affinché tutti i test case attualmente in esecuzione finiscano l'esecuzione. Se tutti i test case in corso non si concludono entro 5 minuti, IDT forza l'arresto 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 buona pratica, dovresti assicurarti che i tuoi casi di test eseguano le seguenti azioni quando incontrano uno degli eventi:

  1. Smetti di eseguire la normale logica di test.

  2. Pulisci tutte le risorse temporanee, ad esempio gli artefatti di test sul dispositivo sottoposto a test.

  3. Segnala un risultato del test a IDT, ad esempio un errore o un errore del test.

  4. Uscita.