翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AWS IoT Greengrass テストフレームワークを使用する Greengrass テストフレームワーク (GTF) は、顧客の立場から見たエンドツーエンドの自動化をサポートする構成要素の集まりです。GTF は機能ドライバーとして [Cucumber](https://cucumber.io) を使用します。 は、同じ構成要素 AWS IoT Greengrass を使用して、さまざまなデバイスでソフトウェアの変更を認定します。詳細については、[Github の「Greengrass テストフレームワーク」](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1)を参照してください。 GTF は、コンポーネントの動作主導型開発 (BDD) を促進するために、自動テストを実行するツールである Cucumber を使用して実装されています。Cucumber では、このシステムの機能の概要は、`feature` という特殊なタイプのファイルにまとめられています。各機能は、自動テストに変換できる仕様を持つ、シナリオと呼ばれる人間が読める形式で記述されています。各シナリオは、Gherkin と呼ばれるドメイン固有の言語を使用して、テスト対象のシステムの相互作用と結果を定義する一連のステップとして概説されています。[Gherkin ステップ](https://cucumber.io/docs/gherkin/reference/#steps)は、仕様をテストフローに固定するステップ定義と呼ばれる方法を使用してプログラミングコードにリンクされます。GTF のステップ定義は Java で実装されます。 **Topics** + [仕組み](#gg-testing-framework-how-gtf-works) + [変更ログ](#gtf-changelog) + [Greengrass テストフレームワークの設定オプション](configuration-options-gtf.md) + [チュートリアル: Greengrass テストフレームワークと Greengrass 開発キットを使用してエンドツーエンドのテストを実行する](run-e2e-tests-tutorial.md) + [チュートリアル: 信頼度テストスイートからの信頼度テストを使用する](confidence-tests-tutorial.md) ## 仕組み AWS IoT Greengrass は、複数の Java モジュールで構成されるスタンドアロン JAR として GTF を配布します。GTF をコンポーネントのエンドツーエンドのテストに使用するには、Java プロジェクト内でテストを実装する必要があります。テスト用スタンドタブル JAR を Java プロジェクトの依存関係として追加すると、GTF の既存の機能を使用したり、独自のカスタムテストケースを作成することで拡張したりできるようになります。カスタムテストケースを実行するには、Java プロジェクトを構築し、[Greengrass テストフレームワークの設定オプション](configuration-options-gtf.md) で説明されている設定オプションを使用してターゲット JAR を実行します。 ### GTF スタンドアロン JAR Greengrass は Cloudfront を [Maven](https://maven.apache.org/) リポジトリとして使用し、GTF スタンドアロン JAR の異なるバージョンをホストしています。GTF バージョンの全リストについては、[GTF リリース](https://github.com/aws-greengrass/aws-greengrass-testing/releases)を参照してください。 GTF スタンドアロン JAR には以下のモジュールが含まれています。これらのモジュールだけに限定されるものではありません。これらの依存関係をプロジェクト内で個別に選択することも、[テスト用スタンドアロン JAR ファイル](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1/aws-greengrass-testing-standalone)ですべての依存関係をプロジェクトに一度に含めることもできます。 + `aws-greengrass-testing-resources`: このモジュールは、テスト中に AWS リソースのライフサイクルを管理するための抽象化を提供します。これを使用して抽`ResourceSpec`象化を使用してカスタム AWS リソースを定義し、GTF がそれらのリソースの作成と削除を自動的に処理できるようにします。 + `aws-greengrass-testing-platform`: このモジュールは、テストライフサイクル中にテスト対象のデバイスをプラットフォームレベルで抽象化します。プラットフォームとは独立して OS とやりとりするための API が含まれており、デバイスシェルで実行されるコマンドをシミュレートするために使用できます。 + `aws-greengrass-testing-components`: このモジュールは、デプロイメント、IPC、その他の機能などの Greengrass のコア機能のテストに使用されるサンプルコンポーネントで構成されています。 + `aws-greengrass-testing-features`: このモジュールは、Greengrass 環境でのテストに使用される再利用可能な共通ステップとその定義で構成されています。 **Topics** + [仕組み](#gg-testing-framework-how-gtf-works) + [変更ログ](#gtf-changelog) + [Greengrass テストフレームワークの設定オプション](configuration-options-gtf.md) + [チュートリアル: Greengrass テストフレームワークと Greengrass 開発キットを使用してエンドツーエンドのテストを実行する](run-e2e-tests-tutorial.md) + [チュートリアル: 信頼度テストスイートからの信頼度テストを使用する](confidence-tests-tutorial.md) ## 変更ログ 次の表に、GTF の各バージョンの変更をまとめています。詳細については、GitHub の「[GTF リリースページ](https://github.com/aws-greengrass/aws-greengrass-testing/releases)」を参照してください。 | **バージョン** | **変更** | | --- | --- | | 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/greengrass/v2/developerguide/gg-testing-framework.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/greengrass/v2/developerguide/gg-testing-framework.html) | | 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/greengrass/v2/developerguide/gg-testing-framework.html) | | 1.0.0 | 当初のバージョン | # Greengrass テストフレームワークの設定オプション ## GTF の設定オプション Greengrass テストフレームワーク (GTF) では、エンドツーエンドのテストプロセスの開始時に特定のパラメータを設定して、テストフローを調整できます。これらの設定オプションは GTF スタンドアロン JAR の CLI 引数として指定できます。 GTF バージョン 1.1.0 以降には、以下の設定オプションがあります。 + `additional-plugins` – (オプション) 追加の Cucumber プラグイン + `aws-region` – AWS のサービスの特定のリージョンレベルのエンドポイントをターゲットにします。デフォルトは、AWS SDK が検出するものです。 + `credentials-path` – オプションの AWS プロファイル認証情報のパス。デフォルトは、ホスト環境で検出された認証情報です。 + `credentials-path-rotation` – AWS 認証情報のオプションのローテーション期間。デフォルトで 15 分または `PT15M` に設定されます。 + `csr-path` – デバイス証明書の生成に使用される CSR のパス。 + `device-mode` – テスト対象のターゲットデバイス。デフォルトはローカルデバイスです。 + `env-stage` – Greengrass のデプロイ環境をターゲットに設定します。デフォルトは本番です。 + `existing-device-cert-arn` – Greengrass のデバイス証明書として使用する既存の証明書の ARN。 + `feature-path` – 追加の機能ファイルを含むファイルまたはディレクトリ。デフォルトでは、追加の機能ファイルは使用されません。 + `gg-cli-version` – Greengrass CLI のバージョンをオーバーライドします。デフォルトは `ggc.version` にある値です。 + `gg-component-bucket` – Greengrass コンポーネントを格納する既存の Amazon S3 バケットの名前。 + `gg-component-overrides` – Greengrass コンポーネントのオーバーライドのリスト。 + `gg-persist` – テスト実行後に保持されるテスト要素のリスト。デフォルトでは、何も保持しないよう設定されています。許容される値は、`aws.resources`、`installed.software`、および `generated.files` です。 + `gg-runtime` – テストがテストリソースとどのようにインタラクションするかに影響する値のリスト。これらの値は `gg.persist` パラメータよりも優先されます。デフォルトが空の場合、インストールされている Greengrass ランタイムを含む、すべてのテストリソースがテストケースによって管理されると想定されます。許容される値は、`aws.resources`、`installed.software`、および `generated.files` です。 + `ggc-archive` – アーカイブされた Greengrass nucleus コンポーネントへのパス。 + `ggc-install-root` – Greengrass nucleus コンポーネントをインストールするディレクトリ。デフォルトは test.temp.path とテスト実行フォルダです。 + `ggc-log-level` – テスト実行の Greengrass nucleus ログレベルを設定します。デフォルトは「INFO」です。 + `ggc-tes-rolename` – AWS のサービスにアクセスするために AWS IoT Greengrass Core が引き受ける IAM ロール。指定された名前のロールが存在しない場合は、ロールとデフォルトのアクセスポリシーが作成されます。 + `ggc-trusted-plugins` – Greengrass に追加する必要がある、信頼されたプラグインのパス (ホスト上) のカンマ区切りリスト。DUT 自体のパスを指定するには、パスの前に「dut:」というプレフィックスを付けます。 + `ggc-user-name` – Greengrass nucleus の user:group posixUser の値。デフォルトは、ログインしている現在のユーザー名です。 + `ggc-version` – 実行中の Greengrass nucleus コンポーネントのバージョンをオーバーライドします。デフォルトは ggc.archive にある値です。 + `log-level` – テスト実行のログレベル。デフォルトは「INFO」です。 + `parallel-config` – JSON 文字列としてのバッチインデックスとバッチ数のセット。バッチインデックスのデフォルト値は 0、バッチ数は 1 です。 + `proxy-url` – この URL を介してトラフィックをルーティングするようにすべてのテストを設定します。 + `tags` – 機能タグのみを実行します。「&」を使用して組み合わせることができます + `test-id-prefix` – AWS リソース名とタグを含むすべてのテスト固有のリソースに適用される共通のプレフィックス。デフォルトは「gg」プレフィックスです。 + `test-log-path` – テスト実行全体の結果を含むディレクトリ。デフォルトは「testResults」です。 + `test-results-json` – 結果として得られる Cucumber JSON レポートがディスクに書き込まれた状態で生成されるかどうかを決定するフラグ。デフォルトは true です。 + `test-results-log` – コンソール出力がディスクに書き込まれた状態で生成されるかどうかを決定するフラグ。デフォルトは false です。 + `test-results-xml` – 結果として得られる JUnit XML レポートがディスクに書き込まれた状態で生成されるかどうかを決定するフラグ。デフォルトは true です。 + `test-temp-path` – ローカルテストアーティファクトを生成するディレクトリ。デフォルトは、gg-testing というプレフィックスが付いたランダムな一時ディレクトリです。 + `timeout-multiplier` – すべてのテストタイムアウトに提供される乗数。デフォルトは 1.0 です。 # チュートリアル: Greengrass テストフレームワークと Greengrass 開発キットを使用してエンドツーエンドのテストを実行する AWS IoT Greengrass Testing Framework (GTF) と Greengrass Development Kit (GDK) は、開発者がend-to-endのテストを実行する方法を提供します。このチュートリアルでは、コンポーネントで GDK プロジェクトを初期化し、エンドツーエンドのテストモジュールで GDK プロジェクトを初期化し、カスタムテストケースを構築する方法を説明します。カスタムテストケースの作成後、テストを実行できます。 このチュートリアルでは、以下の作業を行います。 1. GDK プロジェクトをコンポーネントで初期化します。 1. エンドツーエンドのテストモジュールで GDK プロジェクトを初期化します。 1. カスタムテストケースを構築します。 1. 新しいテストケースにタグを追加します。 1. テスト JAR をビルドします。 1. テストを実行します。 **Topics** + [前提条件](#run-e2e-tests-tutorial-prerequisites) + [ステップ 1: GDK プロジェクトをコンポーネントで初期化する](#init-gdk-with-component) + [ステップ 2: エンドツーエンドのテストモジュールで GDK プロジェクトを初期化する](#init-gdk-with-e2e-test) + [ステップ 3 : カスタムテストケースを構築する](#run-e2e-tests-tutorial-instructions) + [ステップ 4 : 新しいテストケースにタグを追加する](#add-tag-to-test-case) + [ステップ 5: テスト JAR を構築する](#build-test-jar) + [ステップ 6 : テストを実行する](#run-test-gtf) + [例: カスタムテストケースを構築する](#build-test-case-example) ## 前提条件 このチュートリアルを完了するには、以下が必要です。 + GDK バージョン 1.3.0 以降 + Java + Maven + Git ## ステップ 1: GDK プロジェクトをコンポーネントで初期化する + 空のフォルダーを GDK プロジェクトで初期化します。以下のコマンドを実行して Python で実装された `HelloWorld` コンポーネントをダウンロードします。 ``` gdk component init -t HelloWorld -l python -n HelloWorld ``` このコマンドで、現在のディレクトリに `HelloWorld` という名前の新しいディレクトリが作成されます。 ## ステップ 2: エンドツーエンドのテストモジュールで GDK プロジェクトを初期化する + GDK を使用して、テストモジュールテンプレートをダウンロードできます。このテンプレートには、特定の機能とステップの実装が含まれています。以下のコマンドを実行して `HelloWorld` ディレクトリを開き、テストモジュールを使用して既存の GDK プロジェクトを初期化します。 ``` cd HelloWorld gdk test-e2e init ``` このコマンドで、`HelloWorld` ディレクトリに `gg-e2e-tests` という名前の新しいディレクトリが作成されます。このテストディレクトリは Greengrass のテスト用スタンドアロン JAR に依存する [Maven](https://maven.apache.org/) プロジェクトです。 ## ステップ 3 : カスタムテストケースを構築する カスタムテストケースの作成は、大きく分けて 2 つのステップで構成されます。テストシナリオを持つ機能ファイルを作成することと、もう 1 つはステップ定義を実装することです。カスタムテストケースの作成例については、[例: カスタムテストケースを構築する](#build-test-case-example) を参照してください。以下の手順でカスタムテストケースを構築してください。 1. テストシナリオを持つ機能ファイルを作成する 機能は通常、テスト対象のソフトウェアの特定の機能を表します。Cucumber では、各機能はタイトル、詳細な説明、シナリオと呼ばれる特定のケースの 1 つまたは複数の例を含む個別の機能ファイルとして指定されます。各シナリオは、タイトル、詳細な説明、相互作用と期待される結果を定義する一連のステップで構成されています。シナリオは、「given」、「when」、「then」というキーワードを使用して構造化された形式で記述されます。 1. ステップ定義を実装する ステップ定義は、プログラマティックコードに [Gherkin ステップ](https://cucumber.io/docs/gherkin/reference/#steps) をプレインランゲージでリンクします。Cucumber はシナリオ内の Gherkin ステップを識別すると、一致するステップ定義を探して実行します。 ## ステップ 4 : 新しいテストケースにタグを追加する + 機能やシナリオにタグを割り当てて、テストプロセスを整理できます。タグを使用してシナリオのサブセットを分類したり、実行するフックを条件付きで選択したりできます。機能とシナリオには、スペースで区切ることで複数のタグを付けることができます。 この例では、`HelloWorld` コンポーネントを使用します。 機能ファイルに、`@Sample` タグの横に `@HelloWorld` という名前の新しいタグを追加します。 ``` @Sample @HelloWorld Scenario: As a developer, I can create a component and deploy it on my device .... ``` ## ステップ 5: テスト JAR を構築する 1. コンポーネントを構築します。テストモジュールを構築する前に、コンポーネントを構築する必要があります。 ``` gdk component build ``` 1. 次のコマンドを使用してテストモジュールを構築します。このコマンドは、`greengrass-build` フォルダーにテスト用 JAR を構築します。 ``` gdk test-e2e build ``` ## ステップ 6 : テストを実行する カスタムテストケースを実行すると、GTF はテスト中に作成されたリソースを管理するとともに、テストのライフサイクルを自動化します。まず、テスト対象デバイス (DUT) を AWS IoT モノとしてプロビジョニングし、そのデバイスに Greengrass コアソフトウェアをインストールします。次に、そのパスで指定されたレシピを使用して `HelloWorld` という名前の新しいコンポーネントを作成します。その後、`HelloWorld` コンポーネントは Greengrass デバイスデプロイメントを通じてコアデバイスにデプロイされます。その後、デプロイが成功したかどうかが検証されます。デプロイが成功すると 3 分以内にデプロイステータスが `COMPLETED` に変わります。 1. プロジェクトディレクトリ内の `gdk-config.json` ファイルに移動し、`HelloWorld` タグを持つテストをターゲットにします。次のコマンドを使用して、`test-e2e` キーをアップデートします。 ``` "test-e2e":{ "gtf_options" : { "tags":"HelloWorld" } } ``` 1. テストを実行する前に、ホストデバイスに AWS 認証情報を指定する必要があります。GTF は、テストプロセス中にこれらの認証情報を使用して AWS リソースを管理します。指定したロールに、テストに含まれる必要な操作を自動化する権限があることを確認してください。 認証情報を指定するには、次のコマンドを実行します 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. 次のコマンドを使用してテストを実行します。 ``` gdk test-e2e run ``` このコマンドは、`greengrass-build` フォルダーにある Greengrass nucleus の最新バージョンをダウンロードし、それを使用してテストを実行します。また、このコマンドは、`HelloWorld` タグを持つシナリオのみをターゲットにし、それらのシナリオのレポートを生成します。このテスト中に作成された AWS リソースは、テストの最後に破棄されます。 ## 例: カスタムテストケースを構築する **Example** GDK プロジェクトにダウンロードされたテストモジュールは、サンプル機能とステップ実装ファイルで構成されています。 以下の例では、Greengrass ソフトウェアのデバイスデプロイ機能をテストするための機能ファイルを作成します。Greengrass  AWS クラウド を介してコンポーネントをデプロイするシナリオを使用して、この機能の機能を部分的にテストします。これは、このユースケースの相互作用と期待される結果を理解するのに役立つ一連のステップです。 1. **機能ファイルを作成する** 現在のディレクトリの `gg-e2e-tests/src/main/resources/greengrass/features` フォルダーに移動します。次の例のような `component.feature` サンプルがあります。 この機能ファイルでは、Greengrass ソフトウェアのデバイスデプロイ機能をテストできます。Greengrass クラウドを介してコンポーネントをデプロイするシナリオを使用して、この機能の機能を部分的にテストできます。このシナリオは、このユースケースの相互作用と期待される結果を理解するのに役立つ一連のステップです。 ``` 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 には、`And I call my custom step` という名前のステップを除く以下のすべてのステップのステップ定義が含まれています。 1. **ステップ定義を実装する** GTF スタンドアロン JAR には、`And I call my custom step` ステップを除くすべてのステップのステップ定義が含まれています。このステップをテストモジュールに実装できます。 テストファイルのソースコードに移動します。以下のコマンドを使用すると、ステップ定義を使用してカスタムステップをリンクできます。 ``` @And("I call my custom step") public void customStep() { System.out.println("My custom step was called "); } ``` # チュートリアル: 信頼度テストスイートからの信頼度テストを使用する AWS IoT Greengrass Testing Framework (GTF) と Greengrass Development Kit (GDK) は、開発者がend-to-endのテストを実行する方法を提供します。このチュートリアルでは、コンポーネントで GDK プロジェクトを初期化し、エンドツーエンドのテストモジュールで GDK プロジェクトを初期化し、信頼度テストスイートの信頼度テストを使用します。カスタムテストケースの作成後、テストを実行できます。 信頼度テストは、Greengrass が提供する一般的なテストで、基本的なコンポーネントの動作を検証します。これらのテストは、より具体的なコンポーネントニーズに合わせて変更または拡張できます。 このチュートリアルでは、HelloWorld コンポーネントを使用します。別のコンポーネントを使用する場合は、HelloWorld コンポーネントを自分のコンポーネントに置き換えます。 このチュートリアルでは、以下の作業を行います。 1. GDK プロジェクトをコンポーネントで初期化します。 1. エンドツーエンドのテストモジュールで GDK プロジェクトを初期化します。 1. 信頼度テストスイートからのテストを使用します。 1. 新しいテストケースにタグを追加します。 1. テスト JAR をビルドします。 1. テストを実行します。 **Topics** + [前提条件](#confidence-tests-tutorial-prerequisites) + [ステップ 1: GDK プロジェクトをコンポーネントで初期化する](#init-gdk-with-component) + [ステップ 2: エンドツーエンドのテストモジュールで GDK プロジェクトを初期化する](#init-gdk-with-e2e-test) + [ステップ 3: 信頼度テストスイートからのテストを使用する](#confidence-tests-tutorial-instructions) + [ステップ 4 : 新しいテストケースにタグを追加する](#add-tag-to-test-case) + [ステップ 5: テスト JAR を構築する](#build-test-jar) + [ステップ 6 : テストを実行する](#run-test-gtf) + [例: 信頼度テストを使用する](#build-confidence-test-case-example) ## 前提条件 このチュートリアルを完了するには、以下が必要です。 + GDK バージョン 1.6.0 以降 + Java + Maven + Git ## ステップ 1: GDK プロジェクトをコンポーネントで初期化する + 空のフォルダーを GDK プロジェクトで初期化します。以下のコマンドを実行して Python で実装された `HelloWorld` コンポーネントをダウンロードします。 ``` gdk component init -t HelloWorld -l python -n HelloWorld ``` このコマンドで、現在のディレクトリに `HelloWorld` という名前の新しいディレクトリが作成されます。 ## ステップ 2: エンドツーエンドのテストモジュールで GDK プロジェクトを初期化する + GDK を使用して、テストモジュールテンプレートをダウンロードできます。このテンプレートには、特定の機能とステップの実装が含まれています。以下のコマンドを実行して `HelloWorld` ディレクトリを開き、テストモジュールを使用して既存の GDK プロジェクトを初期化します。 ``` cd HelloWorld gdk test-e2e init ``` このコマンドで、`HelloWorld` ディレクトリに `gg-e2e-tests` という名前の新しいディレクトリが作成されます。このテストディレクトリは Greengrass のテスト用スタンドアロン JAR に依存する [Maven](https://maven.apache.org/) プロジェクトです。 ## ステップ 3: 信頼度テストスイートからのテストを使用する 提供された機能ファイルを使用する信頼度テストケースを書き、必要に応じてシナリオを変更します。信頼度テストの使用例については、「[例: カスタムテストケースを構築する](run-e2e-tests-tutorial.md#build-test-case-example)」を参照してください。信頼度テストを使用するには、次のステップを使用します。 + 提供された機能ファイルを使用します。 現在のディレクトリの `gg-e2e-tests/src/main/resources/greengrass/features` フォルダーに移動します。サンプル `confidenceTest.feature` ファイルを開き、信頼度テストを使用します。 ## ステップ 4 : 新しいテストケースにタグを追加する + 機能やシナリオにタグを割り当てて、テストプロセスを整理できます。タグを使用してシナリオのサブセットを分類したり、実行するフックを条件付きで選択したりできます。機能とシナリオには、スペースで区切ることで複数のタグを付けることができます。 この例では、`HelloWorld` コンポーネントを使用します。 各シナリオには `@ConfidenceTest` がタグ付けされています。テストスイートのサブセットのみを実行する場合は、タグを変更または追加します。各テストシナリオは、各信頼度テストの上部に記載されています。このシナリオは、各テストケースのインタラクションと期待される結果を理解するのに役立つ一連のステップです。これらのテストは、独自のステップを追加するか、既存のステップを変更することで拡張できます。 ``` @ConfidenceTest Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected .... ``` ## ステップ 5: テスト JAR を構築する 1. コンポーネントを構築します。テストモジュールを構築する前に、コンポーネントを構築する必要があります。 ``` gdk component build ``` 1. 次のコマンドを使用してテストモジュールを構築します。このコマンドは、`greengrass-build` フォルダーにテスト用 JAR を構築します。 ``` gdk test-e2e build ``` ## ステップ 6 : テストを実行する 信頼度テストを実行すると、GTF はテスト中に作成されたリソースを管理するとともに、テストのライフサイクルを自動化します。まず、テスト対象デバイス (DUT) を AWS IoT モノとしてプロビジョニングし、そのデバイスに Greengrass コアソフトウェアをインストールします。次に、そのパスで指定されたレシピを使用して `HelloWorld` という名前の新しいコンポーネントを作成します。その後、`HelloWorld` コンポーネントは Greengrass デバイスデプロイメントを通じてコアデバイスにデプロイされます。その後、デプロイが成功したかどうかが検証されます。デプロイが成功すると 3 分以内にデプロイステータスが `COMPLETED` に変わります。 1. プロジェクトディレクトリ内の `gdk-config.json` ファイルに移動し、`ConfidenceTest` タグまたはステップ 4 で指定したタグをもつテストをターゲットにします。次のコマンドを使用して、`test-e2e` キーをアップデートします。 ``` "test-e2e":{ "gtf_options" : { "tags":"ConfidenceTest" } } ``` 1. テストを実行する前に、ホストデバイスに AWS 認証情報を指定する必要があります。GTF は、テストプロセス中にこれらの認証情報を使用して AWS リソースを管理します。指定したロールに、テストに含まれる必要な操作を自動化する権限があることを確認してください。 認証情報を指定するには、次のコマンドを実行します 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. 次のコマンドを使用してテストを実行します。 ``` gdk test-e2e run ``` このコマンドは、`greengrass-build` フォルダーにある Greengrass nucleus の最新バージョンをダウンロードし、それを使用してテストを実行します。また、このコマンドは、`ConfidenceTest` タグを持つシナリオのみをターゲットにし、それらのシナリオのレポートを生成します。このテスト中に作成された AWS リソースは、テストの最後に破棄されます。 ## 例: 信頼度テストを使用する **Example** GDK プロジェクトにダウンロードされたテストモジュールは、サンプル機能ファイルで構成されています。 以下の例では、Greengrass ソフトウェアのデバイスデプロイ機能をテストするための機能ファイルを使用します。Greengrass  AWS クラウド を介してコンポーネントをデプロイするシナリオを使用して、この機能の機能を部分的にテストします。これは、このユースケースの相互作用と期待される結果を理解するのに役立つ一連のステップです。 + **提供された機能ファイルを使用します。** 現在のディレクトリの `gg-e2e-tests/src/main/resources/greengrass/features` フォルダーに移動します。次の例のような `confidenceTest.feature` サンプルがあります。 ``` 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 ``` 各テストシナリオは、各信頼度テストの上部に記載されています。このシナリオは、各テストケースのインタラクションと期待される結果を理解するのに役立つ一連のステップです。これらのテストは、独自のステップを追加するか、既存のステップを変更することで拡張できます。各シナリオには、これらの調整に役立つコメントが含まれています。