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 AWS IoT Greengrass Testing Framework Greengrass Testing Framework (GTF) è una raccolta di elementi costitutivi che supporta end-to-end l'automazione dal punto di vista del cliente. GTF utilizza [Cucumber](https://cucumber.io) come driver di funzionalità. AWS IoT Greengrass utilizza gli stessi elementi costitutivi per qualificare le modifiche al software su vari dispositivi. Per ulteriori informazioni, consulta [Greengrass Testing Framework su](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1) Github. GTF è implementato utilizzando Cucumber, uno strumento utilizzato per eseguire test automatici, per incoraggiare uno sviluppo basato sul comportamento (BDD) dei componenti. In Cucumber, le caratteristiche di questo sistema sono descritte in un tipo speciale di file chiamato. `feature` Ogni funzionalità è descritta in un formato leggibile dall'uomo chiamato scenari, che sono specifiche che possono essere convertite in test automatici. Ogni scenario è delineato come una serie di passaggi che definiscono le interazioni e i risultati del sistema in esame utilizzando un linguaggio specifico del dominio chiamato Gherkin. Una [fase Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) è collegata al codice di programmazione utilizzando un metodo chiamato step definition che collega le specifiche al flusso di test. Le definizioni dei passaggi in GTF sono implementate con Java. **Topics** + [Come funziona](#gg-testing-framework-how-gtf-works) + [Changelog](#gtf-changelog) + [Opzioni di configurazione di Greengrass Testing Framework](configuration-options-gtf.md) + [Tutorial: Esegui end-to-end i test utilizzando Greengrass Testing Framework e Greengrass Development Kit](run-e2e-tests-tutorial.md) + [Tutorial: usa un test di confidenza dalla suite di test di fiducia](confidence-tests-tutorial.md) ## Come funziona AWS IoT Greengrass distribuisce GTF come JAR autonomo composto da diversi moduli Java. Per utilizzare GTF per end-to-end testare i componenti, è necessario implementare i test all'interno di un progetto Java. L'aggiunta del JAR standable di test come dipendenza nel progetto Java consente di utilizzare le funzionalità esistenti del GTF ed estenderle scrivendo casi di test personalizzati. Per eseguire i test case personalizzati, puoi creare il tuo progetto Java ed eseguire il JAR di destinazione con le opzioni di configurazione descritte in. [Opzioni di configurazione di Greengrass Testing Framework](configuration-options-gtf.md) ### JAR standalone GTF Greengrass utilizza Cloudfront come repository [Maven](https://maven.apache.org/) per ospitare diverse versioni del JAR standalone GTF. [Per un elenco completo delle versioni GTF, consulta le versioni GTF.](https://github.com/aws-greengrass/aws-greengrass-testing/releases) Il JAR standalone GTF include i seguenti moduli. Non è limitato solo a questi moduli. Puoi scegliere ciascuna di queste dipendenze separatamente nel tuo progetto o includerle tutte contemporaneamente nel file [JAR standalone di test](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1/aws-greengrass-testing-standalone). + `aws-greengrass-testing-resources`: Questo modulo fornisce l'astrazione per la gestione del ciclo di vita di una AWS risorsa nel corso di un test. Puoi usarlo per definire le tue AWS risorse personalizzate usando l'`ResourceSpec`astrazione in modo che GTF possa occuparsi della creazione e della rimozione di tali risorse per te. + `aws-greengrass-testing-platform`: Questo modulo fornisce l'astrazione a livello di piattaforma per il dispositivo sottoposto a test durante il ciclo di vita del test. Contiene dati APIs utilizzati per interagire con il sistema operativo indipendentemente dalla piattaforma e può essere utilizzato per simulare i comandi in esecuzione nella shell del dispositivo. + `aws-greengrass-testing-components`: Questo modulo è costituito da componenti di esempio utilizzati per testare le funzionalità principali di Greengrass come implementazioni, IPC e altre funzionalità. + `aws-greengrass-testing-features`: Questo modulo è composto da passaggi comuni riutilizzabili e relative definizioni che vengono utilizzati per i test nell'ambiente Greengrass. **Topics** + [Come funziona](#gg-testing-framework-how-gtf-works) + [Changelog](#gtf-changelog) + [Opzioni di configurazione di Greengrass Testing Framework](configuration-options-gtf.md) + [Tutorial: Esegui end-to-end i test utilizzando Greengrass Testing Framework e Greengrass Development Kit](run-e2e-tests-tutorial.md) + [Tutorial: usa un test di confidenza dalla suite di test di fiducia](confidence-tests-tutorial.md) ## Changelog La tabella seguente descrive le modifiche in ogni versione del GTF. Per ulteriori informazioni, consulta la [pagina GTF Releases](https://github.com/aws-greengrass/aws-greengrass-testing/releases) su. GitHub | **Versione** | **Modifiche** | | --- | --- | | 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/gg-testing-framework.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/gg-testing-framework.html) | | 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/gg-testing-framework.html) | | 1.0.0 | Versione iniziale. | # Opzioni di configurazione di Greengrass Testing Framework ## Opzioni di configurazione GTF Greengrass Testing Framework (GTF) consente di configurare determinati parametri durante l'avvio del processo di end-to-end test per orchestrare il flusso di test. È possibile specificare queste opzioni di configurazione come argomenti CLI per il JAR standalone GTF. La versione 1.1.0 e successive di GTF fornisce le seguenti opzioni di configurazione. + `additional-plugins`— (Opzionale) Plugin aggiuntivi per Cucumber + `aws-region`— Si rivolge a endpoint regionali specifici per i servizi. AWS L'impostazione predefinita è ciò che rileva l' AWS SDK. + `credentials-path`— Percorso opzionale AWS delle credenziali del profilo. L'impostazione predefinita sono le credenziali rilevate nell'ambiente host. + `credentials-path-rotation`— Durata di rotazione opzionale per le credenziali. AWS Il valore predefinito è 15 minuti o. `PT15M` + `csr-path`— Il percorso della CSR con cui verrà generato il certificato del dispositivo. + `device-mode`— Il dispositivo bersaglio sottoposto a test. L'impostazione predefinita è il dispositivo locale. + `env-stage`— Si rivolge all'ambiente di implementazione di Greengrass. L'impostazione predefinita è la produzione. + `existing-device-cert-arn`— L'arn di un certificato esistente che desideri utilizzare come certificato del dispositivo per Greengrass. + `feature-path`— File o directory contenente file di funzionalità aggiuntivi. L'impostazione predefinita è che non vengono utilizzati file di feature aggiuntivi. + `gg-cli-version`— Sostituisce la versione della CLI di Greengrass. Il valore predefinito è il valore trovato in. `ggc.version` + `gg-component-bucket`— Il nome di un bucket Amazon S3 esistente che contiene componenti Greengrass. + `gg-component-overrides`— Un elenco di componenti sostituiti da Greengrass. + `gg-persist`— Un elenco di elementi di test che devono persistere dopo l'esecuzione di un test. Il comportamento predefinito consiste nel non rendere persistente nulla. I valori accettati sono: `aws.resources``installed.software`, e`generated.files`. + `gg-runtime`— Un elenco di valori per influenzare il modo in cui il test interagisce con le risorse di test. Questi valori sostituiscono il parametro. `gg.persist` Se l'impostazione predefinita è vuota, presuppone che tutte le risorse di test siano gestite per test case, incluso il runtime Greengrass installato. I valori accettati sono:`aws.resources`, e`installed.software`. `generated.files` + `ggc-archive`— Il percorso verso il componente Greengrass nucleus archiviato. + `ggc-install-root`— Directory per installare il componente Greengrass nucleus. I valori predefiniti sono test.temp.path e test run. + `ggc-log-level`— Imposta il livello di registro del nucleo di Greengrass per l'esecuzione del test. L'impostazione predefinita è «INFO». + `ggc-tes-rolename`— Il ruolo IAM che AWS IoT Greengrass Core assumerà per accedere ai AWS servizi. Se non esiste un ruolo con un nome specifico, ne verrà creato uno e una politica di accesso predefinita. + `ggc-trusted-plugins`— L'elenco separato da virgole dei percorsi (sull'host) dei plugin affidabili che devono essere aggiunti a Greengrass. Per fornire il percorso sul DUT stesso, inserisci il prefisso 'dut: ' + `ggc-user-name`— Il valore PosixUser user:group per il nucleo Greengrass. Il valore predefinito è il nome utente corrente a cui è stato effettuato l'accesso. + `ggc-version`— Sostituisce la versione del componente Greengrass nucleus in esecuzione. Il valore predefinito è il valore trovato in ggc.archive. + `log-level`— Livello di registro dell'esecuzione del test. Il valore predefinito è «INFO». + `parallel-config`— Set di indice di batch e numero di batch come stringa JSON. Il valore predefinito dell'indice batch è 0 e il numero di batch è 1. + `proxy-url`— Configura tutti i test per indirizzare il traffico attraverso questo URL. + `tags`— Esegui solo tag di funzionalità. Può essere intersecato con '&' + `test-id-prefix`— Un prefisso comune applicato a tutte le risorse specifiche del test, inclusi i nomi e i tag AWS delle risorse. L'impostazione predefinita è il prefisso «gg». + `test-log-path`— Directory che conterrà i risultati dell'intera esecuzione del test. Il valore predefinito è «testResults». + `test-results-json`— Contrassegno per determinare se viene generato un report Cucumber JSON risultante scritto su disco. Il valore predefinito è true. + `test-results-log`— Contrassegno per determinare se l'output della console viene generato scritto su disco. Il valore predefinito è false (falso). + `test-results-xml`— Contrassegno per determinare se viene generato un report JUnit XML risultante scritto su disco. Il valore predefinito è true. + `test-temp-path`— Directory per generare artefatti di test locali. Il valore predefinito è una directory temporanea casuale con il prefisso gg-testing. + `timeout-multiplier`— Moltiplicatore fornito a tutti i timeout dei test. Il valore predefinito è 1.0. # Tutorial: Esegui end-to-end i test utilizzando Greengrass Testing Framework e Greengrass Development Kit AWS IoT Greengrass Testing Framework (GTF) e Greengrass Development Kit (GDK) offrono agli sviluppatori modi per eseguire i test. end-to-end Puoi completare questo tutorial per inizializzare un progetto GDK con un componente, inizializzare un progetto GDK con un modulo di test e creare un end-to-end test case personalizzato. Dopo aver creato il tuo test case personalizzato, puoi eseguire il test. In questo tutorial, esegui quanto indicato di seguito: 1. Inizializza un progetto GDK con un componente. 1. Inizializza un progetto GDK con un modulo di test. end-to-end 1. Crea un test case personalizzato. 1. Aggiungi un tag al nuovo test case. 1. Crea il JAR di test. 1. Eseguire il test . **Topics** + [Prerequisiti](#run-e2e-tests-tutorial-prerequisites) + [Fase 1: Inizializza un progetto GDK con un componente](#init-gdk-with-component) + [Fase 2: Inizializza un progetto GDK con un end-to-end modulo di test](#init-gdk-with-e2e-test) + [Passaggio 3: crea un test case personalizzato](#run-e2e-tests-tutorial-instructions) + [Passaggio 4: aggiungere un tag al nuovo test case](#add-tag-to-test-case) + [Fase 5: Creare il JAR di test](#build-test-jar) + [Passaggio 6: eseguire il test](#run-test-gtf) + [Esempio: crea un test case personalizzato](#build-test-case-example) ## Prerequisiti Per completare questo tutorial, è necessario quanto segue: + GDK versione 1.3.0 o successiva + Java + Maven + Git ## Fase 1: Inizializza un progetto GDK con un componente + Inizializza una cartella vuota con un progetto GDK. Scarica il `HelloWorld` componente implementato in Python eseguendo il seguente comando. ``` gdk component init -t HelloWorld -l python -n HelloWorld ``` Questo comando crea una nuova directory denominata `HelloWorld` nella directory corrente. ## Fase 2: Inizializza un progetto GDK con un end-to-end modulo di test + GDK consente di scaricare il modello del modulo di test costituito da un'implementazione di funzionalità e fasi. Esegui il comando seguente per aprire la `HelloWorld` directory e inizializzare il progetto GDK esistente utilizzando un modulo di test. ``` cd HelloWorld gdk test-e2e init ``` Questo comando crea una nuova directory denominata `gg-e2e-tests` all'interno della `HelloWorld` directory. Questa directory di test è un progetto [Maven](https://maven.apache.org/) che dipende dal JAR standalone di test Greengrass. ## Passaggio 3: crea un test case personalizzato La scrittura di un test case personalizzato consiste sostanzialmente in due passaggi: creare un file di funzionalità con uno scenario di test e implementare le definizioni dei passaggi. Per un esempio di creazione di un test case personalizzato, vedi[Esempio: crea un test case personalizzato](#build-test-case-example). Utilizza i seguenti passaggi per creare il tuo test case personalizzato: 1. Crea un file di funzionalità con uno scenario di test Una funzionalità descrive in genere una funzionalità specifica del software che viene testato. In Cucumber, ogni funzionalità è specificata come un singolo file di funzionalità con un titolo, una descrizione dettagliata e uno o più esempi di casi specifici chiamati scenari. Ogni scenario è composto da un titolo, una descrizione dettagliata e una serie di passaggi che definiscono le interazioni e i risultati attesi. Gli scenari sono scritti in un formato strutturato utilizzando le parole chiave «given», «when» e «then». 1. Implementa le definizioni dei Una definizione di fase collega la [fase Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) in un linguaggio semplice al codice programmatico. Quando Cucumber identifica un passaggio Gherkin in uno scenario, cercherà una definizione di fase corrispondente da eseguire. ## Passaggio 4: aggiungere un tag al nuovo test case + È possibile assegnare tag alle funzionalità e agli scenari per organizzare il processo di test. È possibile utilizzare i tag per classificare i sottoinsiemi di scenari e anche selezionare gli hook in modo condizionale da eseguire. Le funzionalità e gli scenari possono avere più tag separati da uno spazio. In questo esempio, stiamo usando il `HelloWorld` componente. Nel file delle funzionalità, aggiungete un nuovo tag denominato `@HelloWorld` accanto al `@Sample` tag. ``` @Sample @HelloWorld Scenario: As a developer, I can create a component and deploy it on my device .... ``` ## Fase 5: Creare il JAR di test 1. Costruisci il componente. È necessario creare il componente prima di creare il modulo di test. ``` gdk component build ``` 1. Costruite il modulo di test utilizzando il seguente comando. Questo comando creerà il JAR di test nella `greengrass-build` cartella. ``` gdk test-e2e build ``` ## Passaggio 6: eseguire il test Quando esegui un test case personalizzato, GTF automatizza il ciclo di vita del test oltre alla gestione delle risorse create durante il test. Innanzitutto esegue il provisioning di un dispositivo in fase di test (DUT) come dispositivo e installa su di esso il software di base Greengrass. AWS IoT Creerà quindi un nuovo componente denominato `HelloWorld` utilizzando la ricetta specificata in quel percorso. Il `HelloWorld` componente viene quindi distribuito sul dispositivo principale tramite una distribuzione di oggetti Greengrass. Verrà quindi verificato se l'implementazione è riuscita. Lo stato di distribuzione verrà modificato `COMPLETED` entro 3 minuti se la distribuzione ha esito positivo. 1. Vai al `gdk-config.json` file nella directory del progetto per indirizzare i test con il `HelloWorld` tag. Aggiorna la `test-e2e` chiave usando il seguente comando. ``` "test-e2e":{ "gtf_options" : { "tags":"HelloWorld" } } ``` 1. Prima di eseguire i test, è necessario fornire AWS le credenziali al dispositivo host. GTF utilizza queste credenziali per gestire le AWS risorse durante il processo di test. Assicurati che il ruolo che fornisci disponga delle autorizzazioni per automatizzare le operazioni necessarie incluse nel test. Esegui i seguenti comandi per fornire le credenziali. AWS 1. ------ #### [ Linux or Unix ] ``` export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY ``` ------ #### [ Windows Command Prompt (CMD) ] ``` set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY ``` ------ #### [ PowerShell ] ``` $env:AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE" $env:AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" ``` ------ 1. Eseguite il test utilizzando il seguente comando. ``` gdk test-e2e run ``` Questo comando scarica l'ultima versione del nucleo Greengrass nella `greengrass-build` cartella ed esegue i test utilizzandola. Questo comando si rivolge inoltre solo agli scenari con il `HelloWorld` tag e genera un report per tali scenari. Vedrai che le AWS risorse create durante questo test vengono scartate alla fine del test. ## Esempio: crea un test case personalizzato **Example** Il modulo di test scaricato nel progetto GDK è costituito da una funzionalità di esempio e da un file di implementazione delle fasi. Nell'esempio seguente, creiamo un file di funzionalità per testare la funzionalità di distribuzione degli oggetti del software Greengrass. Testiamo parzialmente la funzionalità di questa funzionalità con uno scenario che esegue l'implementazione di un componente tramite Greengrass Cloud AWS. Questa è una serie di passaggi che ci aiutano a comprendere le interazioni e i risultati attesi di questo caso d'uso. 1. **Create un file di feature** Passate alla `gg-e2e-tests/src/main/resources/greengrass/features` cartella nella directory corrente. È possibile trovare l'esempio `component.feature` simile all'esempio seguente. In questo file di funzionalità, puoi testare la funzionalità di distribuzione degli oggetti del software Greengrass. È possibile testare parzialmente la funzionalità di questa funzionalità con uno scenario che esegue una distribuzione di un componente tramite il cloud Greengrass. Lo scenario è una serie di passaggi che aiutano a comprendere le interazioni e i risultati attesi di questo caso d'uso. ``` Feature: Testing features of Greengrassv2 component Background: Given my device is registered as a Thing And my device is running Greengrass @Sample Scenario: As a developer, I can create a component and deploy it on my device When I create a Greengrass deployment with components HelloWorld | /path/to/recipe/file And I deploy the Greengrass deployment configuration Then the Greengrass deployment is COMPLETED on the device after 180 seconds And I call my custom step ``` GTF contiene le definizioni dei passaggi di tutti i passaggi seguenti, ad eccezione del passaggio denominato:. `And I call my custom step` 1. **Implementa le definizioni dei** Il JAR standalone GTF contiene le definizioni di tutti i passaggi tranne uno:. `And I call my custom step` Puoi implementare questo passaggio nel modulo di test. Vai al codice sorgente del file di test. È possibile collegare il passaggio personalizzato utilizzando una definizione di passaggio utilizzando il comando seguente. ``` @And("I call my custom step") public void customStep() { System.out.println("My custom step was called "); } ``` # Tutorial: usa un test di confidenza dalla suite di test di fiducia AWS IoT Greengrass Testing Framework (GTF) e Greengrass Development Kit (GDK) offrono agli sviluppatori modi per eseguire i test. end-to-end Puoi completare questo tutorial per inizializzare un progetto GDK con un componente, inizializzare un progetto GDK con un modulo di test e utilizzare un end-to-end test di confidenza della suite di test di confidenza. Dopo aver creato il tuo test case personalizzato, puoi eseguire il test. Un test di confidenza è un test generico fornito da Greengrass che convalida i comportamenti fondamentali dei componenti. Questi test possono essere modificati o estesi per soddisfare esigenze più specifiche dei componenti. Per questo tutorial useremo un HelloWorld componente. Se stai usando un altro componente, sostituisci il HelloWorld componente con il tuo componente. In questo tutorial, esegui quanto indicato di seguito: 1. Inizializza un progetto GDK con un componente. 1. Inizializza un progetto GDK con un modulo di test. end-to-end 1. Usa un test della suite di test di fiducia. 1. Aggiungi un tag al nuovo test case. 1. Crea il JAR di test. 1. Eseguire il test . **Topics** + [Prerequisiti](#confidence-tests-tutorial-prerequisites) + [Fase 1: Inizializza un progetto GDK con un componente](#init-gdk-with-component) + [Fase 2: Inizializza un progetto GDK con un end-to-end modulo di test](#init-gdk-with-e2e-test) + [Passaggio 3: utilizzare un test della suite di test di fiducia](#confidence-tests-tutorial-instructions) + [Fase 4: Aggiungere un tag al nuovo test case](#add-tag-to-test-case) + [Passaggio 5: crea il JAR di test](#build-test-jar) + [Passaggio 6: eseguire il test](#run-test-gtf) + [Esempio: utilizza un test di fiducia](#build-confidence-test-case-example) ## Prerequisiti Per completare questo tutorial, è necessario quanto segue: + GDK versione 1.6.0 o successiva + Java + Maven + Git ## Fase 1: Inizializza un progetto GDK con un componente + Inizializza una cartella vuota con un progetto GDK. Scarica il `HelloWorld` componente implementato in Python eseguendo il seguente comando. ``` gdk component init -t HelloWorld -l python -n HelloWorld ``` Questo comando crea una nuova directory denominata `HelloWorld` nella directory corrente. ## Fase 2: Inizializza un progetto GDK con un end-to-end modulo di test + GDK consente di scaricare il modello del modulo di test costituito da un'implementazione di funzionalità e fasi. Esegui il comando seguente per aprire la `HelloWorld` directory e inizializzare il progetto GDK esistente utilizzando un modulo di test. ``` cd HelloWorld gdk test-e2e init ``` Questo comando crea una nuova directory denominata `gg-e2e-tests` all'interno della `HelloWorld` directory. Questa directory di test è un progetto [Maven](https://maven.apache.org/) che dipende dal JAR standalone di test Greengrass. ## Passaggio 3: utilizzare un test della suite di test di fiducia La scrittura di un test case di fiducia consiste nell'utilizzare il file di funzionalità fornito e, se necessario, nella modifica degli scenari. Per un esempio di utilizzo di un test di confidenza, vedere[Esempio: crea un test case personalizzato](run-e2e-tests-tutorial.md#build-test-case-example). Per utilizzare un test di confidenza, attenersi alla seguente procedura: + Utilizzate il file di funzionalità fornito. Passate alla `gg-e2e-tests/src/main/resources/greengrass/features` cartella nella directory corrente. Apri il `confidenceTest.feature` file di esempio per utilizzare il test di fiducia. ## Fase 4: Aggiungere un tag al nuovo test case + È possibile assegnare tag alle funzionalità e agli scenari per organizzare il processo di test. È possibile utilizzare i tag per classificare i sottoinsiemi di scenari e anche selezionare gli hook in modo condizionale da eseguire. Le funzionalità e gli scenari possono avere più tag separati da uno spazio. In questo esempio, stiamo usando il `HelloWorld` componente. Ogni scenario è contrassegnato con`@ConfidenceTest`. Modifica o aggiungi tag se desideri eseguire solo un sottoinsieme della suite di test. Ogni scenario di test è descritto all'inizio di ogni test di confidenza. Lo scenario è una serie di passaggi che aiutano a comprendere le interazioni e i risultati attesi di ogni caso di test. È possibile estendere questi test aggiungendo passaggi personalizzati o modificando quelli esistenti. ``` @ConfidenceTest Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected .... ``` ## Passaggio 5: crea il JAR di test 1. Costruisci il componente. È necessario creare il componente prima di creare il modulo di test. ``` gdk component build ``` 1. Costruite il modulo di test utilizzando il seguente comando. Questo comando creerà il JAR di test nella `greengrass-build` cartella. ``` gdk test-e2e build ``` ## Passaggio 6: eseguire il test Quando si esegue un test di confidenza, il GTF automatizza il ciclo di vita del test oltre alla gestione delle risorse create durante il test. Innanzitutto esegue il provisioning di un dispositivo in fase di test (DUT) come dispositivo e installa su di esso il software di base Greengrass. AWS IoT Creerà quindi un nuovo componente denominato `HelloWorld` utilizzando la ricetta specificata in quel percorso. Il `HelloWorld` componente viene quindi distribuito sul dispositivo principale tramite una distribuzione di oggetti Greengrass. Verrà quindi verificato se l'implementazione è riuscita. Lo stato di distribuzione verrà modificato `COMPLETED` entro 3 minuti se la distribuzione ha esito positivo. 1. Vai al `gdk-config.json` file nella directory del progetto per indirizzare i test con il `ConfidenceTest` tag o il tag yo8u specificato nel passaggio 4. Aggiorna la `test-e2e` chiave usando il seguente comando. ``` "test-e2e":{ "gtf_options" : { "tags":"ConfidenceTest" } } ``` 1. Prima di eseguire i test, è necessario fornire AWS le credenziali al dispositivo host. GTF utilizza queste credenziali per gestire le AWS risorse durante il processo di test. Assicurati che il ruolo che fornisci disponga delle autorizzazioni necessarie per automatizzare le operazioni necessarie incluse nel test. Esegui i seguenti comandi per fornire le credenziali. AWS 1. ------ #### [ Linux or Unix ] ``` export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY ``` ------ #### [ Windows Command Prompt (CMD) ] ``` set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY ``` ------ #### [ PowerShell ] ``` $env:AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE" $env:AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" ``` ------ 1. Eseguite il test utilizzando il seguente comando. ``` gdk test-e2e run ``` Questo comando scarica l'ultima versione del nucleo Greengrass nella `greengrass-build` cartella ed esegue i test utilizzandola. Questo comando si rivolge inoltre solo agli scenari con il `ConfidenceTest` tag e genera un report per tali scenari. Vedrai che le AWS risorse create durante questo test vengono scartate alla fine del test. ## Esempio: utilizza un test di fiducia **Example** Il modulo di test scaricato nel progetto GDK è costituito da un file di funzionalità fornito. Nell'esempio seguente, utilizziamo un file di funzionalità per testare la funzionalità di distribuzione degli oggetti del software Greengrass. Testiamo parzialmente la funzionalità di questa funzionalità con uno scenario che esegue l'implementazione di un componente tramite Greengrass Cloud AWS. Questa è una serie di passaggi che ci aiutano a comprendere le interazioni e i risultati attesi di questo caso d'uso. + **Utilizza il file di funzionalità fornito.** Passate alla `gg-e2e-tests/src/main/resources/greengrass/features` cartella nella directory corrente. È possibile trovare l'esempio `confidenceTest.feature` simile all'esempio seguente. ``` Feature: Confidence Test Suite Background: Given my device is registered as a Thing And my device is running Greengrass @ConfidenceTest Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected When I create a Greengrass deployment with components | GDK_COMPONENT_NAME | GDK_COMPONENT_RECIPE_FILE | | aws.greengrass.Cli | LATEST | And I deploy the Greengrass deployment configuration Then the Greengrass deployment is COMPLETED on the device after 180 seconds # Update component state accordingly. Possible states: {RUNNING, FINISHED, BROKEN, STOPPING} And I verify the GDK_COMPONENT_NAME component is RUNNING using the greengrass-cli ``` Ogni scenario di test è descritto all'inizio di ogni test di confidenza. Lo scenario è una serie di passaggi che aiutano a comprendere le interazioni e i risultati attesi di ogni caso di test. È possibile estendere questi test aggiungendo passaggi personalizzati o modificando quelli esistenti. Ciascuno degli scenari include commenti che consentono di apportare queste modifiche.