

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Verwenden Sie AWS IoT Greengrass Testing Framework
<a name="gg-testing-framework"></a>

Das Greengrass Testing Framework (GTF) ist eine Sammlung von Bausteinen, die die end-to-end Automatisierung aus Kundensicht unterstützen. GTF verwendet [Cucumber als Feature-Treiber](https://cucumber.io). AWS IoT Greengrass verwendet dieselben Bausteine, um Softwareänderungen auf verschiedenen Geräten zu qualifizieren. Weitere Informationen finden Sie unter [Greengrass Testing Framework auf Github](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1).

GTF wird mithilfe von Cucumber implementiert, einem Tool zur Durchführung automatisierter Tests, um eine verhaltensgesteuerte Entwicklung (BDD) der Komponenten zu fördern. In Cucumber werden die Funktionen dieses Systems in einem speziellen Dateityp namens beschrieben. `feature` Jede Funktion wird in einem für Menschen lesbaren Format beschrieben, das als Szenarien bezeichnet wird. Dabei handelt es sich um Spezifikationen, die in automatisierte Tests umgewandelt werden können. Jedes Szenario besteht aus einer Reihe von Schritten, die die Interaktionen und Ergebnisse des zu testenden Systems mithilfe einer domänenspezifischen Sprache namens Gherkin definieren. Ein [Gherkin-Schritt](https://cucumber.io/docs/gherkin/reference/#steps) ist mit dem Programmiercode verknüpft. Dabei wird eine Methode verwendet, die als Schrittdefinition bezeichnet wird und die Spezifikation fest mit dem Testablauf verknüpft. Schrittdefinitionen in GTF werden mit Java implementiert.

**Topics**
+ [Funktionsweise](#gg-testing-framework-how-gtf-works)
+ [Änderungsprotokoll](#gtf-changelog)
+ [Konfigurationsoptionen für das Greengrass Testing Framework](configuration-options-gtf.md)
+ [Tutorial: Führen Sie end-to-end Tests mit dem Greengrass Testing Framework und dem Greengrass Development Kit durch](run-e2e-tests-tutorial.md)
+ [Tutorial: Verwenden Sie einen Konfidenztest aus der Konfidenztestsuite](confidence-tests-tutorial.md)

## Funktionsweise
<a name="gg-testing-framework-how-gtf-works"></a>

AWS IoT Greengrass verteilt das GTF als eigenständiges JAR, das aus mehreren Java-Modulen besteht. Um GTF zum end-to-end Testen von Komponenten zu verwenden, müssen Sie die Tests in einem Java-Projekt implementieren. Wenn Sie das Test-Standable-JAR als Abhängigkeit in Ihrem Java-Projekt hinzufügen, können Sie die bestehende Funktionalität der GTF nutzen und sie erweitern, indem Sie Ihre eigenen benutzerdefinierten Testfälle schreiben. Um die benutzerdefinierten Testfälle auszuführen, können Sie Ihr Java-Projekt erstellen und das Ziel-JAR mit den unter beschriebenen Konfigurationsoptionen ausführen. [Konfigurationsoptionen für das Greengrass Testing Framework](configuration-options-gtf.md)

### Eigenständiges GTF-JAR
<a name="w2ab1c24c19c25c11b5"></a>

Greengrass verwendet Cloudfront als [Maven-Repository](https://maven.apache.org/), um verschiedene Versionen des GTF-Standalone-JAR zu hosten. [Eine vollständige Liste der GTF-Versionen finden Sie unter GTF-Versionen.](https://github.com/aws-greengrass/aws-greengrass-testing/releases)

GTF Standalone JAR umfasst die folgenden Module. Es ist nicht nur auf diese Module beschränkt. Sie können jede dieser Abhängigkeiten separat in Ihrem Projekt auswählen oder sie alle gleichzeitig in die [eigenständige JAR-Testdatei](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1/aws-greengrass-testing-standalone) aufnehmen.
+ `aws-greengrass-testing-resources`: Dieses Modul bietet Abstraktion für die Verwaltung des Lebenszyklus einer AWS Ressource während eines Tests. Sie können dies verwenden, um Ihre benutzerdefinierten AWS Ressourcen mithilfe von `ResourceSpec` Abstraktion zu definieren, sodass GTF die Erstellung und Entfernung dieser Ressourcen für Sie übernehmen kann.
+ `aws-greengrass-testing-platform`: Dieses Modul bietet Abstraktion auf Plattformebene für das zu testende Gerät während des Testlebenszyklus. Es APIs dient zur plattformunabhängigen Interaktion mit dem Betriebssystem und kann zur Simulation der Befehle verwendet werden, die in der Geräte-Shell ausgeführt werden.
+ `aws-greengrass-testing-components`: Dieses Modul besteht aus Beispielkomponenten, die zum Testen der Greengrass-Kernfunktionen wie Bereitstellungen, IPC und anderen Funktionen verwendet werden.
+ `aws-greengrass-testing-features`: Dieses Modul besteht aus wiederverwendbaren gemeinsamen Schritten und ihren Definitionen, die für Tests in der Greengrass-Umgebung verwendet werden.

**Topics**
+ [Funktionsweise](#gg-testing-framework-how-gtf-works)
+ [Änderungsprotokoll](#gtf-changelog)
+ [Konfigurationsoptionen für das Greengrass Testing Framework](configuration-options-gtf.md)
+ [Tutorial: Führen Sie end-to-end Tests mit dem Greengrass Testing Framework und dem Greengrass Development Kit durch](run-e2e-tests-tutorial.md)
+ [Tutorial: Verwenden Sie einen Konfidenztest aus der Konfidenztestsuite](confidence-tests-tutorial.md)

## Änderungsprotokoll
<a name="gtf-changelog"></a>

In der folgenden Tabelle werden die Änderungen in den einzelnen Versionen des GTF beschrieben. Weitere Informationen finden Sie auf der [Seite GTF-Veröffentlichungen](https://github.com/aws-greengrass/aws-greengrass-testing/releases) unter. GitHub


|  **Version**  |  **Änderungen**  | 
| --- | --- | 
| 1.2.0 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/gg-testing-framework.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/gg-testing-framework.html)  | 
|  1.1.0  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/gg-testing-framework.html)  | 
|  1.0.0  |  Erste Version  | 

# Konfigurationsoptionen für das Greengrass Testing Framework
<a name="configuration-options-gtf"></a>

## GTF-Konfigurationsoptionen
<a name="configuration-options-gtf-options"></a>

Greengrass Testing Framework (GTF) ermöglicht es Ihnen, während des Starts des end-to-end Testprozesses bestimmte Parameter zu konfigurieren, um den Testablauf zu orchestrieren. Sie können diese Konfigurationsoptionen als CLI-Argumente für das eigenständige GTF-JAR angeben.

<a name="gtf_options"></a>GTF Version 1.1.0 und höher bietet die folgenden Konfigurationsoptionen.
+ `additional-plugins`— (Optional) Zusätzliche Cucumber-Plugins
+ `aws-region`— Zielt auf spezifische regionale Endpunkte für AWS Dienste ab. Standardmäßig wird das verwendet, was das AWS SDK entdeckt.
+ `credentials-path`— Optionaler Pfad für die AWS Profilanmeldedaten. Standardmäßig werden Anmeldeinformationen verwendet, die in der Host-Umgebung gefunden wurden.
+ `credentials-path-rotation`— Optionale Rotationsdauer für AWS Anmeldeinformationen. Der Standardwert ist 15 Minuten oder`PT15M`.
+ `csr-path`— Der Pfad für die CSR, mit der das Gerätezertifikat generiert wird.
+ `device-mode`— Das zu testende Zielgerät. Standardmäßig ist das lokale Gerät aktiviert.
+ `env-stage`— Zielt auf die Bereitstellungsumgebung von Greengrass ab. Standardmäßig ist die Produktion eingestellt.
+ `existing-device-cert-arn`— Der ARN eines vorhandenen Zertifikats, das Sie als Gerätezertifikat für Greengrass verwenden möchten.
+ `feature-path`— Datei oder Verzeichnis mit zusätzlichen Funktionsdateien. Standardmäßig werden keine zusätzlichen Featuredateien verwendet.
+ `gg-cli-version`— Überschreibt die Version der Greengrass-CLI. Standardmäßig wird der Wert verwendet, der in gefunden wurde. `ggc.version`
+ `gg-component-bucket`— Der Name eines vorhandenen Amazon S3 S3-Buckets, der Greengrass-Komponenten enthält.
+ `gg-component-overrides`— Eine Liste von Greengrass-Komponenten-Overrides.
+ `gg-persist`— Eine Liste von Testelementen, die nach einem Testlauf beibehalten werden sollen. Das Standardverhalten besteht darin, nichts beizubehalten. Zulässige Werte sind: `aws.resources``installed.software`, und`generated.files`.
+ `gg-runtime`— Eine Liste von Werten, die beeinflussen sollen, wie der Test mit den Testressourcen interagiert. Diese Werte haben Vorrang vor dem Parameter. `gg.persist` Wenn der Standardwert leer ist, wird davon ausgegangen, dass alle Testressourcen nach Testfällen verwaltet werden, einschließlich der installierten Greengrass-Runtime. Zulässige Werte sind: `aws.resources``installed.software`, und. `generated.files`
+ `ggc-archive`— Der Pfad zur archivierten Greengrass-Kernkomponente.
+ `ggc-install-root`— Verzeichnis zur Installation der Greengrass Nucleus-Komponente. Standardmäßig ist dies der Ordner test.temp.path und der Testrun-Ordner.
+ `ggc-log-level`— Stellen Sie den Greengrass Nucleus Log Level für den Testlauf ein. Die Standardeinstellung ist „INFO“.
+ `ggc-tes-rolename`— Die IAM-Rolle, die AWS IoT Greengrass Core für den Zugriff auf AWS Dienste übernehmen wird. Wenn eine Rolle mit dem angegebenen Namen nicht existiert, wird eine erstellt und es wird eine Standardzugriffsrichtlinie festgelegt.
+ `ggc-trusted-plugins`— Die durch Kommas getrennte Liste der Pfade (auf dem Host) der vertrauenswürdigen Plugins, die zu Greengrass hinzugefügt werden müssen. Um den Pfad auf dem DUT selbst anzugeben, stellen Sie dem Pfad „dut:“ voran
+ `ggc-user-name`— Der posixUser-Wert user:group für den Greengrass-Kern. Standardmäßig wird der aktuelle Benutzername verwendet, der angemeldet ist.
+ `ggc-version`— Überschreibt die Version der laufenden Greengrass Nucleus-Komponente. Standardmäßig wird der in ggc.archive gefundene Wert verwendet.
+ `log-level`— Protokollebene des Testlaufs. Der Standardwert ist „INFO“.
+ `parallel-config`— Satz von Batch-Index und Anzahl der Batches als JSON-Zeichenfolge. Der Standardwert des Batch-Index ist 0 und die Anzahl der Batches ist 1.
+ `proxy-url`— Konfigurieren Sie alle Tests so, dass der Verkehr über diese URL weitergeleitet wird.
+ `tags`— Führt nur Feature-Tags aus. Kann mit '&' überschnitten werden
+ `test-id-prefix`— Ein gemeinsames Präfix, das auf alle testspezifischen Ressourcen angewendet wird, einschließlich AWS Ressourcennamen und Tags. Die Standardeinstellung ist ein „gg“ -Präfix.
+ `test-log-path`— Verzeichnis, das die Ergebnisse des gesamten Testlaufs enthalten wird. Der Standardwert ist „TestResults“.
+ `test-results-json`— Markierung, um festzustellen, ob ein resultierender Cucumber-JSON-Bericht generiert und auf die Festplatte geschrieben wird. Standardwert ist „true“.
+ `test-results-log`— Markierung, um festzustellen, ob die Konsolenausgabe generiert und auf die Festplatte geschrieben wird. Standardwert "false".
+ `test-results-xml`— Markierung, um festzustellen, ob ein JUnit resultierender XML-Bericht generiert und auf die Festplatte geschrieben wird. Standardwert ist „true“.
+ `test-temp-path`— Verzeichnis zum Generieren lokaler Testartefakte. Standardmäßig wird ein zufälliges temporäres Verzeichnis mit dem Präfix gg-testing verwendet.
+ `timeout-multiplier`— Für alle Test-Timeouts wird ein Multiplikator bereitgestellt. Standard = 1.0.

# Tutorial: Führen Sie end-to-end Tests mit dem Greengrass Testing Framework und dem Greengrass Development Kit durch
<a name="run-e2e-tests-tutorial"></a>

AWS IoT Greengrass Testing Framework (GTF) und Greengrass Development Kit (GDK) bieten Entwicklern Möglichkeiten, Tests durchzuführen. end-to-end Sie können dieses Tutorial abschließen, um ein GDK-Projekt mit einer Komponente zu initialisieren, ein GDK-Projekt mit einem end-to-end Testmodul zu initialisieren und einen benutzerdefinierten Testfall zu erstellen. Nachdem Sie Ihren benutzerdefinierten Testfall erstellt haben, können Sie den Test ausführen.

In diesem Tutorial führen Sie folgende Aufgaben aus:

1. Initialisieren Sie ein GDK-Projekt mit einer Komponente.

1. Initialisieren Sie ein GDK-Projekt mit einem Testmodul. end-to-end

1. Erstellen Sie einen benutzerdefinierten Testfall.

1. Fügen Sie dem neuen Testfall ein Tag hinzu.

1. Erstellen Sie das Test-JAR.

1. Führen Sie den Test aus.

**Topics**
+ [Voraussetzungen](#run-e2e-tests-tutorial-prerequisites)
+ [Schritt 1: Initialisieren Sie ein GDK-Projekt mit einer Komponente](#init-gdk-with-component)
+ [Schritt 2: Initialisieren Sie ein GDK-Projekt mit einem Testmodul end-to-end](#init-gdk-with-e2e-test)
+ [Schritt 3: Erstellen Sie einen benutzerdefinierten Testfall](#run-e2e-tests-tutorial-instructions)
+ [Schritt 4: Fügen Sie dem neuen Testfall ein Tag hinzu](#add-tag-to-test-case)
+ [Schritt 5: Erstellen Sie das Test-JAR](#build-test-jar)
+ [Schritt 6: Führen Sie den Test aus](#run-test-gtf)
+ [Beispiel: Erstellen Sie einen benutzerdefinierten Testfall](#build-test-case-example)

## Voraussetzungen
<a name="run-e2e-tests-tutorial-prerequisites"></a>

Zum Durcharbeiten dieses Tutorials ist Folgendes erforderlich:
+ GDK Version 1.3.0 oder höher
+ Java
+ Maven
+ Git

## Schritt 1: Initialisieren Sie ein GDK-Projekt mit einer Komponente
<a name="init-gdk-with-component"></a>
+ Initialisieren Sie einen leeren Ordner mit einem GDK-Projekt. Laden Sie die in Python implementierte `HelloWorld` Komponente herunter, indem Sie den folgenden Befehl ausführen.

  ```
  gdk component init -t HelloWorld -l python -n HelloWorld
  ```

  Dieser Befehl erstellt ein neues Verzeichnis mit dem Namen `HelloWorld` im aktuellen Verzeichnis.

## Schritt 2: Initialisieren Sie ein GDK-Projekt mit einem Testmodul end-to-end
<a name="init-gdk-with-e2e-test"></a>
+ Mit GDK können Sie die Vorlage für das Testmodul herunterladen, die aus einer Funktion und einer schrittweisen Implementierung besteht. Führen Sie den folgenden Befehl aus, um das `HelloWorld` Verzeichnis zu öffnen und das vorhandene GDK-Projekt mithilfe eines Testmoduls zu initialisieren.

  ```
  cd HelloWorld
  gdk test-e2e init
  ```

  Dieser Befehl erstellt ein neues Verzeichnis mit dem Namen `gg-e2e-tests` innerhalb des `HelloWorld` Verzeichnisses. Dieses Testverzeichnis ist ein [Maven-Projekt](https://maven.apache.org/), das von der eigenständigen Greengrass-Testing-JAR abhängig ist.

## Schritt 3: Erstellen Sie einen benutzerdefinierten Testfall
<a name="run-e2e-tests-tutorial-instructions"></a>

Das Schreiben eines benutzerdefinierten Testfalls besteht im Großen und Ganzen aus zwei Schritten: Erstellen Sie eine Feature-Datei mit einem Testszenario und implementieren Sie die Schrittdefinitionen. Ein Beispiel für die Erstellung eines benutzerdefinierten Testfalls finden Sie unter[Beispiel: Erstellen Sie einen benutzerdefinierten Testfall](#build-test-case-example). Gehen Sie wie folgt vor, um Ihren benutzerdefinierten Testfall zu erstellen:

1. Erstellen Sie eine Feature-Datei mit einem Testszenario

   Ein Feature beschreibt in der Regel eine bestimmte Funktionalität der Software, die getestet wird. In Cucumber wird jedes Feature als einzelne Feature-Datei mit einem Titel, einer detaillierten Beschreibung und einem oder mehreren Beispielen für bestimmte Fälle, die als Szenarien bezeichnet werden, spezifiziert. Jedes Szenario besteht aus einem Titel, einer detaillierten Beschreibung und einer Reihe von Schritten, die die Interaktionen und erwarteten Ergebnisse definieren. Szenarien werden in einem strukturierten Format mit den Schlüsselwörtern „gegeben“, „wann“ und „dann“ geschrieben.

1. Implementieren Sie Schrittdefinitionen

   Eine Schrittdefinition verknüpft den [Gherkin-Schritt im](https://cucumber.io/docs/gherkin/reference/#steps) Klartext mit dem Programmcode. Wenn Cucumber in einem Szenario einen Gherkin-Schritt identifiziert, sucht es nach einer passenden Schrittdefinition, die ausgeführt werden kann.

## Schritt 4: Fügen Sie dem neuen Testfall ein Tag hinzu
<a name="add-tag-to-test-case"></a>
+ Sie können den Funktionen und Szenarien Tags zuweisen, um den Testprozess zu organisieren. Sie können Tags verwenden, um die Teilmengen von Szenarien zu kategorisieren und Hooks auch unter bestimmten Bedingungen auszuführen. Features und Szenarien können mehrere durch ein Leerzeichen getrennte Tags haben.

  In diesem Beispiel verwenden wir die `HelloWorld` Komponente.

  Fügen Sie in der Feature-Datei ein neues Tag mit dem Namen `@HelloWorld` neben dem `@Sample` Tag hinzu.

  ```
  @Sample @HelloWorld
  Scenario: As a developer, I can create a component and deploy it on my device
  ....
  ```

## Schritt 5: Erstellen Sie das Test-JAR
<a name="build-test-jar"></a>

1. Erstellen Sie die Komponente. Sie müssen die Komponente erstellen, bevor Sie das Testmodul erstellen.

   ```
   gdk component build
   ```

1. Erstellen Sie das Testmodul mit dem folgenden Befehl. Dieser Befehl erstellt die Test-JAR im `greengrass-build` Ordner.

   ```
   gdk test-e2e build
   ```

## Schritt 6: Führen Sie den Test aus
<a name="run-test-gtf"></a>

Wenn Sie einen benutzerdefinierten Testfall ausführen, automatisiert GTF den Lebenszyklus des Tests sowie die Verwaltung der Ressourcen, die während des Tests erstellt wurden. Es stellt zunächst ein zu testendes Gerät (DUT) als AWS IoT Ding bereit und installiert die Greengrass-Kernsoftware darauf. Anschließend wird eine neue Komponente erstellt, die nach dem in diesem Pfad angegebenen Rezept benannt `HelloWorld` wird. Die `HelloWorld` Komponente wird dann über eine Greengrass-Dingbereitstellung auf dem Kerngerät bereitgestellt. Anschließend wird überprüft, ob die Bereitstellung erfolgreich ist. Der Bereitstellungsstatus wird `COMPLETED` innerhalb von 3 Minuten auf einen Wert geändert, wenn die Bereitstellung erfolgreich ist.

1. Gehen Sie zu der `gdk-config.json` Datei im Projektverzeichnis, um die Tests mit dem `HelloWorld` Tag als Ziel festzulegen. Aktualisieren Sie den `test-e2e` Schlüssel mit dem folgenden Befehl.

   ```
     "test-e2e":{
       "gtf_options" : { 
            "tags":"HelloWorld"
        }
     }
   ```

1. Bevor Sie die Tests ausführen, müssen Sie AWS Anmeldeinformationen für das Hostgerät angeben. GTF verwendet diese Anmeldeinformationen, um die AWS Ressourcen während des Testprozesses zu verwalten. Stellen Sie sicher, dass die von Ihnen angegebene Rolle über die erforderlichen Berechtigungen verfügt, um die im Test enthaltenen erforderlichen Vorgänge zu automatisieren.

   Führen Sie die folgenden Befehle aus, um die AWS Anmeldeinformationen bereitzustellen.

   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. Führen Sie den Test mit dem folgenden Befehl aus.

   ```
   gdk test-e2e run
   ```

   Mit diesem Befehl wird die neueste Version von Greengrass Nucleus in den `greengrass-build` Ordner heruntergeladen und Tests damit ausgeführt. Dieser Befehl zielt auch nur auf die Szenarien ab, die mit dem `HelloWorld` Tag gekennzeichnet sind, und generiert einen Bericht für diese Szenarien. Sie werden sehen, dass die AWS Ressourcen, die während dieses Tests erstellt wurden, am Ende des Tests verworfen werden.

## Beispiel: Erstellen Sie einen benutzerdefinierten Testfall
<a name="build-test-case-example"></a>

**Example**  
Das heruntergeladene Testmodul im GDK-Projekt besteht aus einer Beispielfunktion und einer Datei zur schrittweisen Implementierung.  
Im folgenden Beispiel erstellen wir eine Feature-Datei zum Testen der Ding-Deployment-Funktion der Greengrass-Software. Wir testen die Funktionalität dieser Funktion teilweise mit einem Szenario, das die Bereitstellung einer Komponente über Greengrass AWS Cloud durchführt. Dies ist eine Reihe von Schritten, die uns helfen, die Interaktionen und die erwarteten Ergebnisse dieses Anwendungsfalls zu verstehen.  <a name="build-test-case-example-steps"></a>

1. 

**Erstellen Sie eine Feature-Datei**

   Navigieren Sie zu dem `gg-e2e-tests/src/main/resources/greengrass/features` Ordner im aktuellen Verzeichnis. Sie können das Beispiel finden`component.feature`, das wie das folgende Beispiel aussieht.

   In dieser Feature-Datei können Sie die Thing-Bereitstellungsfunktion der Greengrass-Software testen. Sie können die Funktionalität dieser Funktion teilweise mit einem Szenario testen, das eine Bereitstellung einer Komponente über die Greengrass-Cloud durchführt. Das Szenario besteht aus einer Reihe von Schritten, die dazu beitragen, die Interaktionen und die erwarteten Ergebnisse dieses Anwendungsfalls zu verstehen.

   ```
   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 enthält die Schrittdefinitionen aller folgenden Schritte, mit Ausnahme des genannten Schritts:`And I call my custom step`.

1. 

**Implementieren Sie Schrittdefinitionen**

   GTF Standalone JAR enthält die Schrittdefinitionen aller Schritte mit Ausnahme eines Schritts:`And I call my custom step`. Sie können diesen Schritt im Testmodul implementieren.

   Navigieren Sie zum Quellcode der Testdatei. Sie können Ihren benutzerdefinierten Schritt mithilfe einer Schrittdefinition verknüpfen, indem Sie den folgenden Befehl verwenden.

   ```
   @And("I call my custom step")
   public void customStep() {
       System.out.println("My custom step was called ");
   }
   ```

# Tutorial: Verwenden Sie einen Konfidenztest aus der Konfidenztestsuite
<a name="confidence-tests-tutorial"></a>

AWS IoT Greengrass Testing Framework (GTF) und Greengrass Development Kit (GDK) bieten Entwicklern Möglichkeiten, Tests durchzuführen. end-to-end Sie können dieses Tutorial abschließen, um ein GDK-Projekt mit einer Komponente zu initialisieren, ein GDK-Projekt mit einem end-to-end Testmodul zu initialisieren und einen Konfidenztest aus der Confidence Test Suite zu verwenden. Nachdem Sie Ihren benutzerdefinierten Testfall erstellt haben, können Sie den Test ausführen.

Ein Konfidenztest ist ein generischer Test von Greengrass, der das Verhalten grundlegender Komponenten validiert. Diese Tests können modifiziert oder erweitert werden, um spezifischeren Anforderungen der Komponenten gerecht zu werden. 

Für dieses Tutorial werden wir eine HelloWorld Komponente verwenden. Wenn Sie eine andere Komponente verwenden, ersetzen Sie die HelloWorld Komponente durch Ihre Komponente.

In diesem Tutorial führen Sie folgende Aufgaben aus:

1. Initialisieren Sie ein GDK-Projekt mit einer Komponente.

1. Initialisieren Sie ein GDK-Projekt mit einem Testmodul. end-to-end

1. Verwenden Sie einen Test aus der Confidence Test Suite.

1. Fügen Sie dem neuen Testfall ein Tag hinzu.

1. Erstellen Sie das Test-JAR.

1. Führen Sie den Test aus.

**Topics**
+ [Voraussetzungen](#confidence-tests-tutorial-prerequisites)
+ [Schritt 1: Initialisieren Sie ein GDK-Projekt mit einer Komponente](#init-gdk-with-component)
+ [Schritt 2: Initialisieren Sie ein GDK-Projekt mit einem Testmodul end-to-end](#init-gdk-with-e2e-test)
+ [Schritt 3: Verwenden Sie einen Test aus der Confidence Test Suite](#confidence-tests-tutorial-instructions)
+ [Schritt 4: Fügen Sie dem neuen Testfall ein Tag hinzu](#add-tag-to-test-case)
+ [Schritt 5: Erstellen Sie das Test-JAR](#build-test-jar)
+ [Schritt 6: Führen Sie den Test aus](#run-test-gtf)
+ [Beispiel: Verwenden Sie einen Konfidenztest](#build-confidence-test-case-example)

## Voraussetzungen
<a name="confidence-tests-tutorial-prerequisites"></a>

Zum Durcharbeiten dieses Tutorials ist Folgendes erforderlich:
+ GDK Version 1.6.0 oder höher
+ Java
+ Maven
+ Git

## Schritt 1: Initialisieren Sie ein GDK-Projekt mit einer Komponente
<a name="init-gdk-with-component"></a>
+ Initialisieren Sie einen leeren Ordner mit einem GDK-Projekt. Laden Sie die in Python implementierte `HelloWorld` Komponente herunter, indem Sie den folgenden Befehl ausführen.

  ```
  gdk component init -t HelloWorld -l python -n HelloWorld
  ```

  Dieser Befehl erstellt ein neues Verzeichnis mit dem Namen `HelloWorld` im aktuellen Verzeichnis.

## Schritt 2: Initialisieren Sie ein GDK-Projekt mit einem Testmodul end-to-end
<a name="init-gdk-with-e2e-test"></a>
+ Mit GDK können Sie die Vorlage für das Testmodul herunterladen, die aus einer Funktion und einer schrittweisen Implementierung besteht. Führen Sie den folgenden Befehl aus, um das `HelloWorld` Verzeichnis zu öffnen und das vorhandene GDK-Projekt mithilfe eines Testmoduls zu initialisieren.

  ```
  cd HelloWorld
  gdk test-e2e init
  ```

  Dieser Befehl erstellt ein neues Verzeichnis mit dem Namen `gg-e2e-tests` innerhalb des `HelloWorld` Verzeichnisses. Dieses Testverzeichnis ist ein [Maven-Projekt](https://maven.apache.org/), das von der eigenständigen Greengrass-Testing-JAR abhängig ist.

## Schritt 3: Verwenden Sie einen Test aus der Confidence Test Suite
<a name="confidence-tests-tutorial-instructions"></a>

Das Schreiben eines Konfidenztestfalls besteht darin, die bereitgestellte Feature-Datei zu verwenden und, falls erforderlich, die Szenarien zu ändern. Ein Beispiel für die Verwendung eines Konfidenztests finden Sie unter[Beispiel: Erstellen Sie einen benutzerdefinierten Testfall](run-e2e-tests-tutorial.md#build-test-case-example). Gehen Sie wie folgt vor, um einen Konfidenztest zu verwenden:
+ Verwenden Sie die bereitgestellte Feature-Datei.

  Navigieren Sie zum `gg-e2e-tests/src/main/resources/greengrass/features` Ordner im aktuellen Verzeichnis. Öffnen Sie die `confidenceTest.feature` Beispieldatei, um den Konfidenztest zu verwenden.

## Schritt 4: Fügen Sie dem neuen Testfall ein Tag hinzu
<a name="add-tag-to-test-case"></a>
+ Sie können den Funktionen und Szenarien Tags zuweisen, um den Testprozess zu organisieren. Sie können Tags verwenden, um die Teilmengen von Szenarien zu kategorisieren und Hooks auch unter bestimmten Bedingungen auszuführen. Features und Szenarien können mehrere durch ein Leerzeichen getrennte Tags haben.

  In diesem Beispiel verwenden wir die `HelloWorld` Komponente.

  Jedes Szenario ist mit gekennzeichnet`@ConfidenceTest`. Ändern oder fügen Sie Tags hinzu, wenn Sie nur einen Teil der Testsuite ausführen möchten. Jedes Testszenario wird oben in jedem Konfidenztest beschrieben. Das Szenario besteht aus einer Reihe von Schritten, die dazu beitragen, die Interaktionen und erwarteten Ergebnisse der einzelnen Testfälle zu verstehen. Sie können diese Tests erweitern, indem Sie Ihre eigenen Schritte hinzufügen oder die vorhandenen ändern.

  ```
  @ConfidenceTest
  Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected
  ....
  ```

## Schritt 5: Erstellen Sie das Test-JAR
<a name="build-test-jar"></a>

1. Erstellen Sie die Komponente. Sie müssen die Komponente erstellen, bevor Sie das Testmodul erstellen.

   ```
   gdk component build
   ```

1. Erstellen Sie das Testmodul mit dem folgenden Befehl. Mit diesem Befehl wird das Test-JAR im `greengrass-build` Ordner erstellt.

   ```
   gdk test-e2e build
   ```

## Schritt 6: Führen Sie den Test aus
<a name="run-test-gtf"></a>

Wenn Sie einen Konfidenztest durchführen, automatisiert der GTF den Lebenszyklus des Tests sowie die Verwaltung der Ressourcen, die während des Tests erstellt wurden. Es stellt zunächst ein zu testendes Gerät (DUT) als AWS IoT Ding bereit und installiert die Greengrass-Kernsoftware darauf. Anschließend wird eine neue Komponente erstellt, die nach dem in diesem Pfad angegebenen Rezept benannt `HelloWorld` wird. Die `HelloWorld` Komponente wird dann über eine Greengrass-Dingbereitstellung auf dem Kerngerät bereitgestellt. Anschließend wird überprüft, ob die Bereitstellung erfolgreich ist. Der Bereitstellungsstatus wird `COMPLETED` innerhalb von 3 Minuten auf einen Wert geändert, wenn die Bereitstellung erfolgreich ist.

1. Gehen Sie zu der `gdk-config.json` Datei im Projektverzeichnis, um die Tests mit dem `ConfidenceTest` Tag oder dem in Schritt 4 angegebenen Tag als Ziel festzulegen. Aktualisieren Sie den `test-e2e` Schlüssel mit dem folgenden Befehl.

   ```
     "test-e2e":{
       "gtf_options" : { 
            "tags":"ConfidenceTest"
        }
     }
   ```

1. Bevor Sie die Tests ausführen, müssen Sie AWS Anmeldeinformationen für das Hostgerät angeben. GTF verwendet diese Anmeldeinformationen, um die AWS Ressourcen während des Testprozesses zu verwalten. Stellen Sie sicher, dass die von Ihnen angegebene Rolle über die erforderlichen Berechtigungen verfügt, um die im Test enthaltenen erforderlichen Vorgänge zu automatisieren.

   Führen Sie die folgenden Befehle aus, um die AWS Anmeldeinformationen bereitzustellen.

   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. Führen Sie den Test mit dem folgenden Befehl aus.

   ```
   gdk test-e2e run
   ```

   Mit diesem Befehl wird die neueste Version von Greengrass Nucleus in den `greengrass-build` Ordner heruntergeladen und Tests damit ausgeführt. Dieser Befehl zielt auch nur auf die Szenarien ab, die mit dem `ConfidenceTest` Tag gekennzeichnet sind, und generiert einen Bericht für diese Szenarien. Sie werden sehen, dass die AWS Ressourcen, die während dieses Tests erstellt wurden, am Ende des Tests verworfen werden.

## Beispiel: Verwenden Sie einen Konfidenztest
<a name="build-confidence-test-case-example"></a>

**Example**  
Das heruntergeladene Testmodul im GDK-Projekt besteht aus einer bereitgestellten Feature-Datei.  
Im folgenden Beispiel verwenden wir eine Feature-Datei, um die Ding-Deployment-Funktion der Greengrass-Software zu testen. Wir testen die Funktionalität dieser Funktion teilweise mit einem Szenario, das die Bereitstellung einer Komponente über Greengrass AWS Cloud durchführt. Dies ist eine Reihe von Schritten, die uns helfen, die Interaktionen und die erwarteten Ergebnisse dieses Anwendungsfalls zu verstehen.  <a name="build-confidence-test-case-example-steps"></a>
+ 

**Verwenden Sie die bereitgestellte Feature-Datei.**

  Navigieren Sie zu dem `gg-e2e-tests/src/main/resources/greengrass/features` Ordner im aktuellen Verzeichnis. Sie können das Beispiel finden`confidenceTest.feature`, das wie das folgende Beispiel aussieht.

  ```
  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
  ```

  Jedes Testszenario wird oben in jedem Konfidenztest beschrieben. Das Szenario besteht aus einer Reihe von Schritten, die dazu beitragen, die Interaktionen und erwarteten Ergebnisse der einzelnen Testfälle zu verstehen. Sie können diese Tests erweitern, indem Sie Ihre eigenen Schritte hinzufügen oder die vorhandenen ändern. Jedes der Szenarien enthält Kommentare, die Ihnen helfen, diese Anpassungen vorzunehmen.