本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 使用 AWS IoT Greengrass 测试框架 Greengrass 测试框架 (GTF) 是一系列从客户角度支持自动化的构建模块。 end-to-endGTF 使用 Cuc [u](https://cucumber.io) mber 作为功能驱动程序。 AWS IoT Greengrass 使用相同的构造块来验证不同设备上的软件更改。有关更多信息，请参阅 [Github 上的 Greengrass 测试框架](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1)。 GTF 是通过 Cucumber（一种用于运行自动测试的工具）来实施的，鼓励组件的行为驱动开发（BDD）。在 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 end-to-end 测试框架和 Greengrass 开发套件运行测试](run-e2e-tests-tutorial.md) + [教程：使用置信度测试套件中的置信度测试](confidence-tests-tutorial.md) ## 工作原理 AWS IoT Greengrass 将 GTF 作为由多个 Java 模块组成的独立 JAR 分发。要使用 GTF end-to-end 测试组件，必须在 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`：此模块测试生命周期内为被测设备提供平台级抽象。它包含 APIs 用于与独立于平台的操作系统进行交互，并可用于模拟在设备外壳中运行的命令。 + `aws-greengrass-testing-components`：此模块包含用于测试 Greengrass 核心功能（例如部署、IPC 和其它功能）的示例组件。 + `aws-greengrass-testing-features`：此模块由可重复使用的常用步骤及其定义组成，用于在 Greengrass 环境中进行测试。 **Topics** + [工作原理](#gg-testing-framework-how-gtf-works) + [更改日志](#gtf-changelog) + [Greengrass 测试框架配置选项](configuration-options-gtf.md) + [教程：使用 Greengrass end-to-end 测试框架和 Greengrass 开发套件运行测试](run-e2e-tests-tutorial.md) + [教程：使用置信度测试套件中的置信度测试](confidence-tests-tutorial.md) ## 更改日志 下表介绍每个版本 GTF 的更改。如需了解更多信息，请参阅上的 [GTF 发布页面](https://github.com/aws-greengrass/aws-greengrass-testing/releases)。 GitHub | **版本** | **更改** | | --- | --- | | 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/greengrass/v2/developerguide/gg-testing-framework.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/greengrass/v2/developerguide/gg-testing-framework.html) | | 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/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 IoT Greengrass Core 将担任的 IAM 角色，用于访问 AWS 服务。如果不存在具有给定名称的角色，则系统会创建一个角色并会创建默认访问策略。 + `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 end-to-end 测试框架和 Greengrass 开发套件运行测试 AWS IoT Greengrass 测试框架 (GTF) 和 Greengrass 开发套件 (GDK) 为开发人员提供了运行测试的方法。 end-to-end完成本教程后，您可以使用组件初始化 GDK 项目，使用 end-to-end测试模块初始化 GDK 项目，并生成自定义测试用例。生成自定义测试用例后，就可以运行测试了。 在本教程中，您将执行以下操作： 1. 使用组件初始化 GDK 项目。 1. 使用 end-to-end测试模块初始化 GDK 项目。 1. 构建自定义测试用例。 1. 向新测试用例中添加标签。 1. 生成测试 JAR。 1. 运行测试。 **Topics** + [先决条件](#run-e2e-tests-tutorial-prerequisites) + [步骤 1：使用组件初始化 GDK 项目](#init-gdk-with-component) + [步骤 2：使用 end-to-end测试模块初始化 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：使用 end-to-end测试模块初始化 GDK 项目 + GDK 允许您下载由功能和步骤实现组成的测试模块模板。运行以下命令打开 `HelloWorld` 目录并使用测试模块初始化现有的 GDK 项目。 ``` cd HelloWorld gdk test-e2e init ``` 此命令将在 `HelloWorld` 目录中创建一个名为 `gg-e2e-tests` 的新目录。这个测试目录是一个 [Maven](https://maven.apache.org/) 项目，它依赖于 Greengrass 测试独立 JAR。 ## 步骤 3：构建自定义测试用例 编写自定义测试用例大致包括两个步骤：创建包含测试场景的功能文件和实现步骤定义。有关构建自定义测试用例的示例，请参阅 [示例：构建自定义测试用例](#build-test-case-example)。使用以下步骤构建自定义测试用例： 1. 根据测试场景创建功能文件 功能通常描述正在测试的软件的特定功能。在 Cucumber 中，每个功能都指定为一个单独的功能文件，其中包含标题、详细描述以及一个或多个称为场景的特定案例示例。每个场景都由标题、详细描述以及一系列定义交互和预期结果的步骤组成。场景以结构化格式编写，使用“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` 的新组件。然后通过 Greengrass 事物部署将该 `HelloWorld` 组件部署至核心设备上。然后验证部署是否成功。如果部署成功，部署状态将在 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 测试框架 (GTF) 和 Greengrass 开发套件 (GDK) 为开发人员提供了运行测试的方法。 end-to-end完成本教程后，您可以使用组件初始化 GDK 项目，使用 end-to-end测试模块初始化 GDK 项目，以及使用置信度测试套件中的置信度测试。生成自定义测试用例后，就可以运行测试了。 置信度测试是 Greengrass 提供的通用测试，用于验证基本组件行为。可以修改或扩展这些测试以适应更具体的组件需求。 在本教程中，我们将使用一个 HelloWorld 组件。如果您使用的是其他组件，请用您的 HelloWorld 组件替换该组件。 在本教程中，您将执行以下操作： 1. 使用组件初始化 GDK 项目。 1. 使用 end-to-end测试模块初始化 GDK 项目。 1. 使用置信度测试套件中的测试。 1. 向新测试用例中添加标签。 1. 生成测试 JAR。 1. 运行测试。 **Topics** + [先决条件](#confidence-tests-tutorial-prerequisites) + [步骤 1：使用组件初始化 GDK 项目](#init-gdk-with-component) + [步骤 2：使用 end-to-end测试模块初始化 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：使用 end-to-end测试模块初始化 GDK 项目 + GDK 允许您下载由功能和步骤实现组成的测试模块模板。运行以下命令打开 `HelloWorld` 目录并使用测试模块初始化现有的 GDK 项目。 ``` cd HelloWorld gdk test-e2e init ``` 此命令将在 `HelloWorld` 目录中创建一个名为 `gg-e2e-tests` 的新目录。这个测试目录是一个 [Maven](https://maven.apache.org/) 项目，它依赖于 Greengrass 测试独立 JAR。 ## 步骤 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` 的新组件。然后通过 Greengrass 事物部署将该 `HelloWorld` 组件部署至核心设备上。然后验证部署是否成功。如果部署成功，部署状态将在 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 ``` 每个测试场景的描述均可见于每个置信度测试顶部。该场景包含一系列步骤，有助于了解每个测试用例的交互作用和预期结果。您可以通过添加自己的步骤或修改现有步骤来扩展这些测试。每个场景都包含可帮助您进行这些调整的注释。