Creare eseguibili del test case IDT - AWS IoT Greengrass
Utilizzare IDT Client SDKAbilitare i comandi CLI IDTScrivono log eventiSegnala i risultati a IDTSpecificare il comportamento di uscita

AWS IoT Greengrass Version 1 è entrato nella fase di estensione della vita utile il 30 giugno 2023. Per ulteriori informazioni, consulta la politica AWS IoT Greengrass V1 di manutenzione. Dopo questa data, AWS IoT Greengrass V1 non rilascerà aggiornamenti che forniscano funzionalità, miglioramenti, correzioni di bug o patch di sicurezza. I dispositivi che funzionano AWS IoT Greengrass V1 non subiranno interruzioni e continueranno a funzionare e a connettersi al cloud. Ti consigliamo vivamente di eseguire la migrazione a AWS IoT Greengrass Version 2, che aggiunge nuove importanti funzionalità e supporto per piattaforme aggiuntive.

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

Creare eseguibili del test case IDT

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

  • Per le suite di test che utilizzano argomenti o variabili d'ambiente daltest.jsonper determinare quali test eseguire, è possibile creare un singolo test case eseguibile per l'intera suite di test o un eseguibile di test per ciascun gruppo di test nella suite di test.

  • Per una suite di test in cui si desidera eseguire test specifici basati su comandi specificati, è possibile creare un test case eseguibile per ogni test case nella suite di test.

Come scrittore di test, puoi determinare quale approccio è appropriato per il tuo caso d'uso e strutturare di conseguenza l'eseguibile del test case. Assicurati di fornire il percorso eseguibile del caso di test corretto in ciascunotest.jsonfile e che l'eseguibile specificato viene eseguito correttamente.

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

  • Latest.jsonper il test case selezionato determina i processi da avviare e le variabili d'ambiente da impostare.

  • Lasuite.jsonper la suite di test determina le variabili d'ambiente da impostare.

IDT avvia il processo eseguibile di test richiesto in base ai comandi e agli argomenti specificati nellatest.jsonfile e passa le variabili di ambiente richieste al processo.

Utilizzare IDT Client SDK

Gli SDK client IDT consentono di semplificare la scrittura della logica di test nell'eseguibile di test con comandi API che è possibile utilizzare interagire con IDT e i dispositivi in fase di test. IDT attualmente fornisce i seguenti SDK:

  • SDK client IDT per Python

  • SDK client IDT per Go

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

Interazione con dispositivo

I seguenti comandi consentono di comunicare con il dispositivo in fase di test senza dover implementare ulteriori funzioni di interazione e gestione della connettività del dispositivo.

ExecuteOnDevice

Consente alle suite di test di eseguire comandi shell su un dispositivo che supporta le 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 le 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 creati utilizzando le informazioni di accesso ai dispositivi dal contesto, si consiglia di utilizzare questi comandi API di interazione del dispositivo nei file eseguibili del caso di test. Tuttavia, se questi comandi non soddisfano i requisiti del caso di test, è possibile 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 nelladevice.connectivitye laresource.devices.connectivitycampi per il dispositivo in fase di test e per i dispositivi di risorse, rispettivamente. Per ulteriori informazioni sull'utilizzo del contesto IDT, consulta.Usa 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 i valori dal contesto IDT. Per ulteriori informazioni, consulta la pagina Usa il contesto IDT .

SendResult

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

Interazione dell'host

Il seguente comando consente alle suite di test di comunicare con il computer 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 i valori dal contesto IDT. Per ulteriori informazioni, consulta la pagina 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 eseguibile del test case.

Abilitare i comandi CLI IDT

Larun-suitecomando 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, è possibile implementare il supporto per l'interfaccia a riga di comando IDT. Se non si implementa il supporto, i test runner saranno comunque in grado di eseguire test, ma alcune opzioni CLI non funzioneranno correttamente. Per fornire una customer experience ideale, ti consigliamo di implementare il supporto per i seguenti argomenti per ilrun-suitecomando nella CLI IDT:

timeout-multiplier

Specifica un valore superiore a 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 vogliono eseguire. Quando un test runner specifica questo argomento nel lororun-suitecomando, IDT lo utilizza per calcolare il valore della variabile d'ambiente IDT_TEST_TIMEOUT e imposta ilconfig.timeoutMultipliercampo nel contesto IDT. Per supportare questo argomento, è necessario eseguire le operazioni riportate di seguito:

  • Invece di utilizzare direttamente il valore di timeout daltest.jsonfile, leggere la variabile d'ambiente IDT_TEST_TIMEOUT per ottenere il valore di timeout calcolato correttamente.

  • Recupero del fileconfig.timeoutMultipliervalore dal contesto IDT e applicalo a timeout di lunga durata.

Per ulteriori informazioni sull'uscita anticipata a causa degli eventi di timeout, consulta.Specificare 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 lororun-suitecomando, IDT interromperà l'esecuzione dei test non appena si verifica un errore. Tuttavia, se i test case sono in esecuzione in parallel, ciò può portare a risultati imprevisti. Per implementare il supporto, assicurarsi che se IDT incontra questo evento, la logica di test indica a tutti i test case in esecuzione di arrestare, pulire le risorse temporanee e segnalare un risultato del test a IDT. Per ulteriori informazioni sull'uscita anticipata dei guasti, consulta.Specificare il comportamento di uscita.

group-id e test-id

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

I test runner possono utilizzare questi argomenti con lororun-suitecomando per specificare il seguente comportamento di esecuzione del test:

  • Esegui tutti i test all'interno dei gruppi di test specificati.

  • Eseguire una selezione di test all'interno di un gruppo di test specificato.

Per supportare questi argomenti, la macchina a stato per la suite di test deve includere un set specifico diRunTaskeChoicestati nella macchina a stati. Se non si utilizza una macchina a stato personalizzato, la macchina a stato IDT predefinita include gli stati richiesti per l'utente e non è necessario intraprendere ulteriori azioni. Tuttavia, se si utilizza una macchina a stato personalizzato, utilizzareEsempio della macchina a stati: Esegui gruppi di test selezionati dall'utentecome esempio per aggiungere gli stati richiesti nella macchina a stato.

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

Scrivono log eventi

Mentre il test è in esecuzione, invii dati astdoutestderrper scrivere registri eventi e messaggi di errore sulla console. Per informazioni sul formato dei messaggi della console, consulta.Formato dei messaggi della console.

Quando l'IDT termina di eseguire la suite di test, queste informazioni sono disponibili anche neltest_manager.logfile che si trova nel file<devicetester-extract-location>/results/<execution-id>/logsfolder.

È possibile configurare ogni test case per scrivere i registri dalla sua esecuzione di test, inclusi i registri dal dispositivo in esame, al<group-id>_<test-id>file che si trova nel file<device-tester-extract-location>/results/execution-id/logsfolder. Per fare ciò, recuperate il percorso del file di registro dal contesto IDT con iltestData.logFilePathinterrogare, creare un file su quel percorso e scrivere 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 caso di test, non viene generato alcun file per quel test case.

È inoltre possibile impostare il file eseguibile di testo per creare file di registro aggiuntivi in base alle esigenze<device-tester-extract-location>/logsfolder. 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 del test sulawsiotdevicetester_report.xmle lasuite-name_report.xmlfile. Questi file di report si trovano in<device-tester-extract-location>/results/<execution-id>/. Entrambi i report acquisiscono i risultati dall'esecuzione della suite di test. Per ulteriori informazioni sugli schemi utilizzati da IDT per questi report, consulta.Rivedi i risultati e i registri dei test

Per compilare il contenuto della finestrasuite-name_report.xmlfile, è necessario utilizzare il fileSendResultcomando per segnalare i risultati del test a IDT prima della fine 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 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 del test nella cartella degli artifact di test. Il percorso di questa cartella è memorizzato nella cartellatestData.testArtifactsPatharchiviato nel contesto IDT. In questa cartella, IDT utilizza il primo file XML ordinato alfabeticamente che individua come risultato del test.

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

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

  • IDT ignora tutte le proprietà deltestsuitesetichetta. Al contrario, calcola le proprietà dei tag da altri risultati del gruppo di test segnalati.

  • Almeno unotestsuiteil tag deve esistere all'internotestsuites.

Poiché IDT utilizza la stessa cartella degli artifact per tutti i test case e non elimina i file dei risultati tra le esecuzioni di 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 test case per sovrascrivere i risultati per ogni test case e assicurarsi che i risultati corretti siano disponibili per 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 è consigliabile questo approccio.

Specificare il comportamento di uscita

Configurare l'eseguibile di testo in modo che esca sempre con un codice di uscita 0, anche se un caso di test segnala un errore o un risultato di errore. Utilizzare 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 interrompa l'esecuzione prima che sia terminato nei seguenti eventi. Utilizzare 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 più lungo del valore di timeout specificato nellatest.jsonfile. Se il corridore di prova ha usato iltimeout-multiplierargomento per specificare un moltiplicatore di timeout, quindi IDT calcola il valore di timeout con il moltiplicatore.

Per rilevare questo evento, utilizzare la variabile d'ambiente IDT_TEST_TIMEOUT. Quando un test runner avvia un test, IDT imposta il valore della variabile d'ambiente IDT_TEST_TIMEOUT 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.

Interrupt

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

Poiché i terminali propagano segnali a tutti i processi figlio, è sufficiente configurare un gestore di segnale nei test case per rilevare i segnali di interrupt.

In alternativa, è possibile eseguire periodicamente il polling dell'API per verificare il valore delCancellationRequestedbooleano nelPollForNotificationsRisposta API. Quando IDT riceve un segnale di interrupt, imposta il valore delCancellationRequestedbooleano atrue.

Arresto al primo fallimento

Si verifica quando un test case in esecuzione parallel con il test case corrente fallisce e il corridore di prova ha utilizzato ilstop-on-first-failureargomento per specificare che IDT dovrebbe interrompersi quando si verifica un errore.

Per rilevare questo evento, è possibile eseguire periodicamente il polling dell'API per verificare il valore delCancellationRequestedbooleano nelPollForNotificationsRisposta API. Quando IDT rileva un errore ed è configurato per arrestarsi al primo errore, imposta il valore delCancellationRequestedbooleano atrue.

Quando si verifica uno di questi eventi, IDT attende 5 minuti che tutti i test case attualmente in esecuzione finiscano. Se tutti i test case in esecuzione non escono entro 5 minuti, IDT costringe l'arresto di ciascuno dei processi. Se IDT non ha ricevuto i risultati del test prima della fine dei processi, contrassegnerà i test case come scaduti. Come best practice, è necessario assicurarsi che i test case eseguano le seguenti azioni quando incontrano uno degli eventi:

  1. Smetti di eseguire la normale logica di test.

  2. Pulire eventuali risorse temporanee, come gli artefatti di test sul dispositivo sottoposto a test.

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

  4. Uscire.