Help us learn about your current experience with the documentation. Take the survey.

端到端测试

什么是端到端测试？

端到端（e2e）测试是一种策略，用于检查您的应用程序是否按预期在整个软件栈和架构中正常工作，包括所有应该协同工作的微服务和组件的集成。

我们如何测试 GitLab？

为了测试 GitLab，我们：

  1. 使用 CNG 构建 GitLab 云原生包。
  2. 使用 orchestrator CLI 工具部署这些包，创建一个运行的 GitLab 实例来运行 E2E 测试。

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

测试夜间构建

我们每天运行计划流水线来测试由 Omnibus 创建的夜间构建。你可以在 https://gitlab.com/gitlab-org/gitlab/-/pipeline_schedules 找到这些流水线（需要 Developer 角色）。结果会在 #e2e-run-master Slack 频道中报告。

测试预发布环境

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

测试合并请求中的代码

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

使用 test-on-omnibus 作业

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

这会对从合并请求更改构建的自定义 EE（具有 Ultimate 许可证）Docker 映像运行端到端测试。

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

使用合并结果流水线

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

合并结果流水线上的端到端测试将使用新的 ref 而不是合并请求源分支的头部。

graph LR

A["x1y1z1 - master HEAD"]
B["d1e1f1 - merged results (CI_COMMIT_SHA)"]

A --> B

B --> C["Merged results pipeline"]
C --> D["E2E tests"]
运行自定义测试

现有场景 在下游 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 不会用于并行运行作业。
基于代码路径映射的选择性测试执行

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

覆盖选择性测试执行

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

跳过端到端测试

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

示例可能包括：

  • ~“应该正常工作的东西”
  • 小型重构
  • 审阅期间的小型请求更改，不值得第二次运行整个套件

通过将 pipeline:skip-e2e 标签应用于合并请求来跳过运行端到端测试。

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

动态并行作业扩展

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

  • 创建正确数量的并行作业。
  • 如果没有要执行的测试，则完全跳过特定作业。

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

设计概述

动态作业扩展依赖于 Test Scenario 类。此抽象封装了以下内容：

  • 特定场景应执行的 RSpec 标签。
  • 可选的规范文件模式，可以将场景限制为特定的规范文件。
  • 流水线映射，定义场景在合并请求流水线中运行的流水线类型和作业。

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

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

有关如何创建将在合并请求流水线中运行此场景并动态扩展并行作业的新场景的示例，请参阅 向 E2E 测试流水线添加新作业。

测试流水线工具和配置

测试并行化

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

测试指标

为了增强测试健康可见性，自定义设置将流水线的测试执行结果导出到 InfluxDB 实例，结果在 Grafana 仪表板上可视化。

测试报告

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_INFLUXDB_URL true 应设置为 https://influxdb.quality.gitlab.net。无默认值。
QA_INFLUXDB_TOKEN true 可以在 Gitlab-QA 1Password 保险库中的 Influxdb auth tokens 文档下找到的 InfluxDB 写入令牌。无默认值。
QA_RUN_TYPE false 测试执行的任意名称，如 e2e:test-on-omnibus-ee。对于实时环境测试执行，自动从项目名称推断。无默认值。
QA_EXPORT_TEST_METRICS false 启用或禁用指标导出到 InfluxDB 的标志。默认为 false。
QA_SAVE_TEST_METRICS false 启用或禁用将指标保存为 JSON 文件的标志。默认为 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 测试的入门指南
    • 流程：概述用于在测试中捕获可重用操作序列的 Flows
    • 页面对象：解释页面对象及其在测试设计中的作用
    • 资源：概述用于创建测试数据的 Resources 类

最佳实践

测试基础设施

运行和故障排除测试

其他

你可以在哪里寻求帮助？

你可以在 Slack 的 #s_developer_experience 频道（GitLab 内部）提问，或者可以在 the gitlab issue tracker 中找到你想要处理的问题。