View a markdown version of this page

Crea un test case IDT eseguibile - FreeRTOS
Usa l'IDT Client SDKAbilita i comandi IDT CLIScrivere 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 un test case IDT eseguibile

È possibile creare e inserire un test case eseguibile in una cartella della suite di test nei seguenti modi:

  • Per le suite di test che utilizzano argomenti o variabili di ambiente dai test.json file per determinare quali test eseguire, puoi creare un singolo eseguibile di test case 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 specificati, crei 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 l'eseguibile del tuo test case di conseguenza. Assicuratevi di fornire il percorso eseguibile del test case corretto in ogni test.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 caso test.json di test selezionato determina i processi da avviare e le variabili di ambiente da impostare.

  • suite.jsonPer la suite di 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

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:

  • IDT Client SDK per Python

  • IDT Client SDK per Go

  • IDT Client SDK per Java

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

Interazione con il dispositivo

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

ExecuteOnDevice

Consente alle suite di test di eseguire comandi di 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 SSH o Docker shell.

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 create utilizzando le informazioni di accesso ai dispositivi provenienti dal contesto, consigliamo di utilizzare questi comandi API di interazione del dispositivo 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 resource.devices.connectivity campi rispettivamente device.connectivity per il dispositivo in fase di test e per i dispositivi di risorse. Per ulteriori informazioni sull'uso 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 valori dal contesto IDT. Per ulteriori informazioni, consulta Usa il contesto IDT.

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 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 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 degli eseguibili del test case.

Abilita i comandi IDT CLI

Il run-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 suite di test personalizzata, è necessario implementare il supporto per l'IDT CLI. Se non implementate 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, ti consigliamo di implementare il supporto per i seguenti argomenti per il run-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 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_TEST_TIMEOUT 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 dal test.json file, leggete la variabile di ambiente IDT_TEST_TIMEOUT per ottenere il valore di timeout calcolato correttamente.

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

Per ulteriori informazioni sull'uscita anticipata a causa di eventi di timeout, vedere. Specifica 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 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 test case in esecuzione di fermarsi, ripulire le risorse temporanee e segnalare il risultato del test a IDT. Per ulteriori informazioni su come uscire precocemente in caso di errori, consulta. Specifica 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 loro run-suite comando per specificare il seguente comportamento di esecuzione del test:

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

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

Per supportare questi argomenti, la macchina a stati della suite di test deve includere un set specifico di Choice stati RunTask e stati nella macchina a stati. Se non si utilizza una macchina a stati personalizzata, la macchina a stati IDT predefinita include gli stati richiesti e non è necessario intraprendere ulteriori azioni. Tuttavia, se stai utilizzando una macchina a stati personalizzata, usala Esempio di macchina a stati: esegue gruppi di test selezionati dall'utente come esempio per aggiungere gli stati richiesti nella tua macchina a stati.

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

Scrivere registri degli eventi

Mentre il test è in esecuzione, si inviano dati stdout e si scrivono stderr i registri degli eventi e i messaggi di errore sulla console. Per informazioni sul formato dei messaggi della console, vedereFormato dei messaggi della console.

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

È possibile configurare ogni test case per scrivere i log relativi all'esecuzione del test, inclusi i log 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, recuperate il percorso del file di registro dal contesto IDT con la testData.logFilePath query, create un file in tale percorso e scrivete il contenuto desiderato. IDT aggiorna automaticamente il percorso in base al test case in esecuzione. Se scegli di non creare il file di log per un test case, non viene generato alcun file per quel test case.

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

Per popolare il contenuto del suite-name_report.xml file, è necessario utilizzare il SendResult comando per riportare i risultati del test a IDT prima che l'esecuzione del test termini. Se IDT non è in grado di individuare i risultati di un test, genera un errore per il test case. Il seguente estratto in 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 test artifacts. Il percorso di questa cartella è 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 di test produce risultati XML JUnit, puoi scrivere i risultati del test in un file XML nella cartella artifacts 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 di 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.

  • Al suo interno testsuites deve essere presente almeno un testsuite tag.

Poiché IDT utilizza la stessa cartella degli artifacts per tutti i test case 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. Ti consigliamo di utilizzare lo stesso nome per il file dei risultati XML generato in tutti i test case per sovrascrivere i risultati di ogni test case e assicurarti che i risultati corretti siano disponibili per l'uso da parte di IDT. Sebbene nella suite di test sia possibile utilizzare un approccio misto al reporting, ovvero utilizzare un file di risultati XML per alcuni test case e inviare i risultati tramite l'API per altri, non consigliamo questo approccio.

Specifica il comportamento di uscita

Configura il tuo file 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. Usa 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. Usa 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 superiore al valore di timeout specificato nel test.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, utilizzate 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. È possibile leggere il valore della variabile per impostare un timer appropriato.

Interrompere

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

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

In alternativa, puoi interrogare periodicamente l'API per verificare il valore del valore CancellationRequested booleano nella risposta dell'API. PollForNotifications Quando IDT riceve un segnale di interruzione, imposta il valore del booleano su. CancellationRequested true

Interrompi al primo errore

Si verifica quando un test case in esecuzione in parallelo al test case corrente ha esito negativo 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 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 arrestarsi al primo errore, imposta il valore del valore booleano su. CancellationRequested true

Quando si verifica uno di questi eventi, IDT attende 5 minuti affinché tutti i test case attualmente in esecuzione finiscano di funzionare. Se tutti i test case in esecuzione non si concludono entro 5 minuti, IDT forza l'arresto di ciascuno dei processi. Se IDT non riceve i risultati dei test prima della fine dei processi, contrassegnerà i test case come scaduti. Come best practice, dovreste assicurarvi che i test case eseguano le seguenti azioni quando si verifica uno degli eventi:

  1. Smetti di eseguire la normale logica di test.

  2. Pulisci tutte le risorse temporanee, ad esempio gli artefatti del test sul dispositivo in esame.

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

  4. Esci.