UI 测试

自定义 UI 测试是一项可选功能,可用于为应用程序创建和自动运行 UI 测试。

概述

AEM 提供了 Cloud Manager 质量关卡集成包,确保对自定义应用程序的顺利更新。 特别是,IT 测试门已经使用 AEM API 创建和自动化定制测试。

UI 测试是打包在 Docker 图像中的基于 Selenium 的测试,允许在语言和框架(如 Java 和 Maven、Node 和 WebDriver.io,或任何其他基于 Selenium 构建的框架和技术)中进行广泛选择。 此外,通过使用 AEM 项目原型,可以轻松生成 UI 测试项目。

UI 测试作为每个 Cloud Manager 管道的特定质量关卡的一部分,通过专用​自定义 UI 测试​步骤执行。 任何 UI 测试,包括回归和新功能,都可以检测和报告错误。

与自定义功能测试(用 Java 编写的 HTTP 测试)不同,UI 测试可以是 Docker 映像,其中包含用任何语言编写的测试,只要它们遵循构建 UI 测试一节中定义的约定。

小贴士

Adobe 建议遵循 AEM 项目原型中提供的结构和语言(JavaScript 和 WDIO)。

客户选择启用

要使Cloud Manager生成并执行您的UI测试,您必须通过向存储库添加文件来选择加入此功能。

  • 文件名称必须为 testing.properties
  • 文件内容必须为 ui-tests.version=1
  • 该文件必须在 UI 测试子模块的 pom.xml 文件旁边的 maven 子模块下。
  • 该文件必须位于内置 tar.gz 文件的根目录下。

如果此文件不存在,将跳过 UI 测试生成和执行。

要在构建工件中包含 testing.properties 文件,请在 assembly-ui-test-docker-context.xml 文件中添加 include 语句。

[...]
<includes>
    <include>Dockerfile</include>
    <include>wait-for-grid.sh</include>
    <include>testing.properties</include> <!-- opt-in test module in Cloud Manager -->
</includes>
[...]
注意

如果您的项目不包括此行,则需要编辑该文件并选择进行 UI 测试。

文件可能包含行,建议不要编辑它。 这是因为该行是在引入选择启用 UI 测试之前引入到您的项目中的,而客户不打算编辑该文件。可放心忽略。

构建 UI 测试

Maven 项目生成 Docker 构建上下文。 此 Docker 构建上下文描述了如何创建包含 UI 测试的 Docker 图像,由 Cloud Manager 用户生成包含实际 UI 测试的 Docker 图像。

本节介绍将 UI 测试项目添加到存储库所需的步骤。

小贴士

AEM 项目原型可以生成 UI 测试项目,因为您对编程语言没有特殊要求。

生成 Docker 构建上下文

为了生成 Docker 构建上下文,您需要一个 Maven 模块:

  • 生成一份档案,其中包含 Dockerfile 以及用测试构建 Docker 图像所需的其他所有文件。
  • 使用 ui-test-docker-context 分类器标记档案。

最简单的方法是配置 Maven Assembly 插件创建 Docker 构建上下文档案并为其分配正确的分类器。

您可以使用不同的技术和框架构建 UI 测试,但本节假设您的项目的布局方式与以下类似。

├── Dockerfile
├── assembly-ui-test-docker-context.xml
├── pom.xml
├── test-module
│   ├── package.json
│   ├── index.js
│   └── wdio.conf.js
└── wait-for-grid.sh

pom.xml 文件负责 Maven 构建。 将执行添加到 Maven Assembly 插件,如下所示。

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-assembly-plugin</artifactId>
    <configuration>
        <descriptors>
            <descriptor>${project.basedir}/assembly-ui-test-docker-context.xml</descriptor>
        </descriptors>
        <tarLongFileMode>gnu</tarLongFileMode>
    </configuration>
    <executions>
        <execution>
            <id>make-assembly</id>
            <phase>package</phase>
            <goals>
                <goal>single</goal>
            </goals>
        </execution>
    </executions>
</plugin>

此执行指示 Maven Assembly 插件根 assembly-ui-test-docker-context.xml 上下文中包含的指令创建档案,在插件的行话中称为​Assembly 描述符。 Assembly 描述符列出了必须作为档案的一部分的所有文件。

<assembly>
    <id>ui-test-docker-context</id>
    <includeBaseDirectory>false</includeBaseDirectory>
    <formats>
        <format>tar.gz</format>
    </formats>
    <fileSets>
        <fileSet>
            <directory>${basedir}</directory>
            <includes>
                <include>Dockerfile</include>
                <include>wait-for-grid.sh</include>
            </includes>
        </fileSet>
        <fileSet>
            <directory>${basedir}/test-module</directory>
            <excludes>
                <exclude>node/**</exclude>
                <exclude>node_modules/**</exclude>
                <exclude>reports/**</exclude>
            </excludes>
        </fileSet>
    </fileSets>
</assembly>

Assembly 描述符指示插件创建 .tar.gz 类型的档案,并将 ui-test-docker-context 分类器分配给它。 此外,它还列出了必须包含在档案中的文件,包括以下内容。

  • 构建 Docker 图像时必须使用 Dockerfile
  • wait-for-grid.sh 脚本,其用途如下所述
  • 实际的 UI 测试,由 test-module 文件夹中的 Node.js 项目实现

Assembly 描述符还排除了在本地运行 UI 测试时可能生成的一些文件。 这保证了更小的档案和更快的构建。

Cloud Manager 会自动拾取包含 Docker 构建上下文的档案,它将在部署管道期间构建包含测试的 Docker 图像。最终,Cloud Manager 将运行 Docker 图像,对应用程序执行 UI 测试。

构建应该生成零或一个档案。 如果它生成零个档案,则默认通过测试步骤。 如果构建生成多个档案,那么选择哪个档案是不确定的。

编写 UI 测试

本节描述包含 UI 测试的 Docker 图像必须遵循的惯例。 Docker 图像是根据上一节所述 Docker 构建上下文构建的。

环境变量

以下环境变量将在运行时传递给 Docker 图像。

变量 示例 描述
SELENIUM_BASE_URL http://my-ip:4444 Selenium 服务器的 URL
SELENIUM_BROWSER chrome Selenium 服务器使用的浏览器实施
AEM_AUTHOR_URL http://my-ip:4502/context-path AEM 作者实例的 URL
AEM_AUTHOR_USERNAME admin 登录 AEM 作者实例的用户名
AEM_AUTHOR_PASSWORD admin 登录 AEM 作者实例的密码
AEM_PUBLISH_URL http://my-ip:4503/context-path AEM 发布实例的 URL
AEM_PUBLISH_USERNAME admin 登录 AEM 发布实例的用户名
AEM_PUBLISH_PASSWORD admin 登录 AEM 发布实例的密码
REPORTS_PATH /usr/src/app/reports 必须保存测试结果的 XML 报告的路径
UPLOAD_URL http://upload-host:9090/upload 要使 Selenium 能够访问文件,必须将文件上载到的 URL

等待 Selenium 就绪

在测试开始之前,Docker 图像负责确保 Selenium 服务器启动并运行。 等待 Selenium 服务需要两个步骤。

  1. SELENIUM_BASE_URL 环境变量中读取 Selenium 服务的 URL。
  2. 定期轮询 Selenium API 公开的状态端点

一旦 Selenium 的状态端点得到肯定响应,测试就可以开始了。

生成测试报告

Docker 图像必须以 JUnit XML 格式生成测试报告,并将其保存在环境变量 REPORTS_PATH 指定的路径中。JUnit XML 格式是一种广泛使用的报告测试结果的格式。 如果 Docker 图像使用 Java 和 Maven,则诸如 Maven Surefire 插件Maven Failsafe 插件等标准测试模块可以立即生成此类报告。

如果 Docker 图像是用其他编程语言或测试运行程序实现的,请查看文档,了解如何生成 JUnit XML 报告。

捕获屏幕快照和视频

Docker 映像可能会产生额外的测试输出(如屏幕快照、视频),并将其保存在环境变量 REPORTS_PATH 指定的路径中。测试结果存档中包括任何可在 REPORTS_PATH 下找到的文件。

如果在执行 UI 测试期间创建了测试结果存档,则测试日志文件在结尾引用测试结果档案的位置。

[...]

===============================================================
The detailed test results can be downloaded from the URL below.
Note: the link will expire after 60 days

    https://results-host/test-results.zip

===============================================================

上载文件

测试有时必须将文件上载到正在测试的应用程序。 为了使 Selenium 的部署相对于您的测试保持灵活性,不可能直接将资产上传到 Selenium。 相反,上载文件需要以下步骤。

  1. UPLOAD_URL 环境变量指定的 URL 处上载文件。
    • 上载必须在一个带有多部分表单的 POST 请求中执行。
    • 多部分表单必须有一个文件字段。
    • 这相当于 curl -X POST ${UPLOAD_URL} -F "data=@file.txt"
    • 查阅 Docker 图像中使用的编程语言的文档和库,了解如何执行此类 HTTP 请求。
  2. 如果上载成功,请求将返回 200 OK 响应,响应类型为 text/plain
    • 响应的内容是一个不透明的文件句柄。
    • 您可以使用此句柄代替 <input> 元素中的文件路径来测试应用程序中的文件上载。

在此页面上