极狐 GitLab

端到端测试

什么是端到端测试？#

端到端 (e2e) 测试是一种用于验证您的应用在整个软件栈和架构层面（包括所有应协同工作的微服务与组件的集成）是否按预期工作的策略。

如何测试极狐GitLab？#

为了测试极狐GitLab，我们：

  1. 使用 CNG 构建极狐GitLab 云原生软件包。
  2. 通过 orchestrator CLI 工具部署这些软件包，以创建一个运行中的极狐GitLab 实例，从而运行 E2E 测试。

此外，我们使用 GitLab Development Kit (GDK) 作为测试环境，该环境可以快速部署，以便更快地获得测试反馈。

测试每夜构建版#

我们每晚运行定时流水线来测试由 Omnibus 创建的每夜构建版本。你可以在 https://jihulab.com/gitlab-cn/gitlab/-/pipeline_schedules（需要开发者角色）找到这些流水线。测试结果会报告在 #e2e-run-master Slack 频道中。

测试预发布环境#

我们每晚运行定时流水线来测试预发布环境。你可以在 https://jihulab.com/gitlab-cn/quality/staging/pipelines（需要开发者角色）找到这些流水线。测试结果会报告在 #e2e-run-staging Slack 频道中。

测试合并请求中的代码#

端到端测试流水线 描述了负责在合并请求中运行 E2E 测试的流水线设置。

使用 test-on-omnibus 任务#

可以通过触发 qa 阶段中的 e2e:test-on-omnibus-ee 手动操作来为合并请求运行端到端测试（不适用于 fork 项目）。

此操作会针对由合并请求更改构建的自定义 EE（具有旗舰版许可证）Docker 镜像运行端到端测试。

启动端到端测试的手动操作也适用于 gitlab-org/omnibus-gitlab 合并请求中。

使用合并结果流水线#

在合并结果流水线中，流水线运行在一个包含源分支和目标分支合并结果的新引用（ref）上。

合并结果流水线上的端到端测试会使用这个新引用，而不是合并请求源分支的头部。

Rendering chart...
运行自定义测试#

在下游 gitlab-qa-mirror 流水线中运行的现有场景 包含许多测试，但有时你可能希望运行与现有场景不同的测试或测试组。

例如，当我们解除隔离一个不稳定的测试时，我们首先想确保它不再不稳定。我们可以通过运行 _ee:quarantine 手动任务来实现。在选择手动任务的名称（而不是播放图标）时，系统会提示你输入变量。你可以使用任何可用于 gitlab-qa 的变量以及以下这些变量：

变量描述
QA_SCENARIO要运行的场景（默认 Test::Instance::Image）
QA_TESTS要运行的测试（无默认值，意味着运行场景中的所有测试）。使用文件路径，就像使用 RSpec 运行测试时一样，例如 qa/specs/features/ee/browser_ui 会包括所有 EE UI 测试。
QA_RSPEC_TAGS要添加的 RSpec 标签（默认 --tag quarantine）

目前，带有自定义变量的手动任务在重试时不会使用相同的变量，因此如果你想多次运行相同的测试，则需要在每个 custom-parallel 任务中指定相同的变量（最多可以运行 10 个可用任务中的任意多个）。

选择性测试执行#

为了限制合并请求中执行的测试数量，存在动态选择要执行哪些测试的机制。选择运行哪些测试的算法基于更改的文件和合并请求标签。以下条件决定将运行哪些测试：

  1. qa 框架代码的更改会执行整个测试套件
  2. qa 文件夹中特定 _spec.rb 文件的更改只会执行该特定测试。在这种情况下，不会使用 knapsack 来并行运行任务。
基于代码路径映射的选择性测试执行#
  • coverband Gem 以非标准方式用于 backend 合并请求中的 E2E 选择性测试执行。
  • coverband 仅在设置了 COVERBAND_ENABLED 环境变量时在极狐GitLab 应用中启用。这仅在 master 分支上的定时 e2e:test-on-gdk 流水线中设置，在合并请求流水线中不会设置。
  • 源代码路径映射在每个 E2E 示例开始前和每个 E2E 示例完成后通过内部 API执行。
  • 完整的合并映射会上传到 code-path-mappings 存储桶中的 GCS。
  • 该映射用于选择 backend 合并请求中的测试。

基于映射的选择性测试执行目前用于 test-on-gdk 流水线。更多信息，请参阅史诗 47。

覆盖选择性测试执行#

要覆盖选择性测试执行并触发完整测试套件，需要为特定合并请求添加 pipeline:run-all-e2e 标签。

跳过端到端测试#

在某些情况下，可能不需要运行端到端测试套件。

示例包括：

  • ~“理应正常工作的内容”
  • 小型重构
  • 审查期间请求的微小更改，不值得再次运行整个套件

可以通过向合并请求添加 pipeline:skip-e2e 标签来跳过端到端测试。

警告： 跳过端到端测试存在风险。使用此标签时请谨慎斟酌。端到端测试套件是更改合并到默认分支之前的最后一道防线。跳过这些测试会增加将回归引入代码库的风险。

动态并行任务扩缩#

为了保持一致的流水线运行时间，每个特定 E2E 测试套件的 CI/CD 任务数量会根据套件中测试的总运行时间动态扩缩。 generate_e2e_pipelines Rake 任务会创建 CI/CD YAML 文件，这些文件：

  • 创建正确数量的并行任务。
  • 如果不会执行任何测试，则完全跳过特定任务。

此功能与选择性测试执行协同工作，以根据合并请求中的特定更改尽可能优化流水线运行时间和成本。

设计概览#

动态任务扩缩依赖测试场景类。此类抽象封装了以下内容：

  • 特定场景应执行的 RSpec 标签。
  • 一个可选的 spec 文件模式，可将场景限制为特定的 spec 文件。
  • 一个流水线映射，定义了特定场景在合并请求流水线中运行时应使用的流水线类型和任务。

PipelineCreator 类会生成带有动态调整的并行任务计数的流水线 YAML 文件。在流水线 YAML 生成之前，PipelineCreator 会遍历所有已定义的 测试场景 类，并创建一个映射，其中包含每个 CI/CD 任务的计算测试总运行时间。基于此信息，流水线 YAML 文件将生成并正确调整并行任务计数。

PipelineCreator 还会从选择性测试执行中获取输入，以进一步减少将要执行的测试总数。

有关如何创建新场景并使其在合并请求流水线中运行并动态扩缩并行任务的示例，请参阅向 E2E 测试流水线添加新任务。

测试流水线工具与配置#

测试并行化#

我们的 CI 设置使用 knapsack Gem 来实现测试并行化。Knapsack 报告会自动生成并存储在 gitlab-qa-resources 项目中的 knapsack-reports GCS 存储桶中。KnapsackReport 助手管理报告的生成和上传过程。

测试指标#

为了提高测试健康度的可见性，我们定制了一个设置，将流水线的测试执行结果导出到 GCS 存储桶，并在 Snowflake 仪表板中对结果进行可视化。

测试报告#

Allure 报告#

为了提供额外的测试结果可见性，流水线上运行的测试会生成并托管 Allure 测试报告。

QA 框架使用 Allure RSpec Gem 为 Allure 测试报告生成源文件。流水线中有一个额外的任务：

  • 从所有测试任务中获取这些源文件。
  • 生成报告并将其上传到位于 AWS 组项目 eng-quality-ops-ci-cd-shared-infra 中的 S3 存储桶 gitlab-qa-allure-report。

用于上传报告的通用 CI 模板存储在 allure-report.yml 中。

合并请求#

当这些测试在合并请求的范围内执行时，Allure 报告会上传到 GCS 存储桶，并添加一个机器人评论，链接到其对应的报告。

定时流水线#

这些测试的定时流水线在 Report 阶段下包含一个 generate-allure-report 任务。它们还会输出当前测试报告的链接。每种类型的定时流水线都会根据其阶段生成一个指向最新测试报告的静态链接。你可以在极狐GitLab 手册中找到这些链接的列表。

资源配置#

所有组件的资源配置由 engineering-productivity-infrastructure 项目执行。

在 CI 中导出指标#

使用以下环境变量配置指标导出：

变量是否必需信息
QA_RUN_TYPEfalse测试执行的任意名称，例如 e2e:test-on-omnibus-ee。对于实时环境测试执行，会从项目名称自动推断。无默认值。
QA_EXPORT_TEST_METRICSfalse启用或禁用导出指标到 GCS 的标志。默认为 false。

如何运行测试？#

如果你不是在合并请求中测试代码，那么运行测试主要有两种选择。如果你想针对一个实时极狐GitLab 实例或预构建的 Docker 镜像运行现有测试，可以使用 GitLab QA orchestrator。另请参阅可以使用 orchestrator 运行的测试场景示例。

另一方面，如果你想针对本地开发极狐GitLab 环境运行测试，可以使用 GitLab Development Kit (GDK)。请参考 QA README 中的说明和以下部分。

运行需要特殊设置的测试#

了解如何执行需要在本地环境进行特殊设置或考虑的测试。

如何编写测试？#

在编写新测试之前，请先查阅 GitLab QA 架构。

在决定好 测试环境编排场景 和 实例级场景 的放置位置后，请查看 GitLab QA README、GitLab QA orchestrator README 以及 已有的实例级场景。

考虑 不 编写端到端测试#

我们应该遵循以下端到端测试的最佳实践：

  • 如果存在更低级别的功能测试，就不要编写端到端测试。端到端测试需要更多的工作和资源。
  • 端到端测试的故障排除可能更复杂，因为与被测应用之间的连接状态未知。

延伸阅读#

E2E 测试入门#

  • 初学者指南：帮助新贡献者入门 E2E 测试的入门指南
    • 流程：用于在测试中捕获可复用操作序列的 流程 概述
    • 页面对象：页面对象及其在测试设计中的作用的解释
    • 资源：用于创建测试数据的 资源 类概述

最佳实践#

测试基础设施#

运行与排查测试#

其他#

从哪里可以获得帮助？#

你可以在 Slack 上的 #s_developer_experience 频道（极狐GitLab 内部）提问，也可以在 gitlab 议题追踪器 中寻找你想处理的议题。