End-to-end Testing

原文：https://docs.gitlab.com/ee/development/testing_guide/end_to_end/

End-to-end Testing

What is end-to-end testing?

端到端测试是一种策略，用于检查您的应用程序在整个软件堆栈和体系结构中是否按预期工作，包括应该协同工作的所有微服务和组件的集成.

How do we test GitLab?

我们使用Omnibus GitLab构建 GitLab 程序包，然后使用GitLab QA 协调器工具测试这些程序包，该工具是 API 和 UI 的黑盒测试框架.

Testing nightly builds

我们每天晚上运行预定的管道，以测试 Omnibus 创建的每晚构建. 您可以在https://gitlab.com/gitlab-org/quality/nightly/pipelines （需要开发人员访问权限）中找到这些夜间管道. 结果在#qa-nightly Slack 频道中报告.

Testing staging

我们每天晚上运行预定的管道以测试阶段. 您可以在https://gitlab.com/gitlab-org/quality/staging/pipelines （需要开发人员访问权限）中找到这些夜间管道. 结果在#qa-staging Slack 频道中报告.

Testing code in merge requests

Using the package-and-qa job

通过在test阶段触发package-and-qa手动操作，可以对合并请求运行端到端测试，最终在gitlab-qa-mirror项目的管道中运行（不适用于 fork） ）.

这将针对根据合并请求的更改构建的自定义 CE 和 EE（具有终极许可证）Omnibus 程序包进行端到端测试.

Omnibus GitLab中的合并请求中也提供了启动端到端测试的手动操作.

您可以在下面阅读有关如何使用它以及如何工作的更多信息.

How does it work?

当前，我们正在使用类似多项目管道的方法来运行质量检查管道.

图 LR A1 -.-> | 1. 触发 omnibus-gitlab-mirror 管道并等待它完成| A2 B2 [Trigger-qa阶段 Trigger：qa-test工作] -.-> | 2. 触发 gitlab-qa-mirror 管道并等待它完成| A3 子图” gitlab-foss / gitlab 管道” A1 [test阶段 “打包和质量检查”工作]结束子图” omnibus-gitlab 管道” A2 [Trigger-docker阶段 Trigger：gitlab-docker作业]-> |一旦完成| B2 结束子图” gitlab-qa-镜像管道” A3> QA 作业运行] -.-> | 3. 将管道结果报告给”打包和质量检查”作业 并将结果发布到经过测试的原始提交| A1 端

  1. 开发人员触发手动操作，可以在 GitLab 合并请求中找到该操作. 这将启动多个项目中的一系列管道.

  2. 正在执行的脚本触发Omnibus GitLab Mirror 中的管道，并等待结果状态. 我们将此称为状态归因 .

  3. 在Omnibus GitLab Mirror管道中正在构建 GitLab 软件包. 然后将程序包推送到其容器注册表.

  4. 当软件包准备就绪并在注册表中可用时， Omnibus GitLab Mirror管道的最后一步将触发新的 GitLab QA 管道（具有访问权限的人可以在https://gitlab.com/gitlab-org/gitlab-qa-mirror/pipelines查看它们） https://gitlab.com/gitlab-org/gitlab-qa-mirror/pipelines ）. 它还等待结果状态.

  5. GitLab QA 从注册表中提取图像，旋转容器，并针对刚刚由gitlab-qa工具精心策划的测试环境运行测试.

  6. GitLab QA 管道的结果正在通过 Omnibus 上游传播回 GitLab 合并请求.

请注意，我们计划添加有关gitlab-qa-mirror中运行的每个作业/场景中包含的测试的更多特定信息 .

With Pipeline for Merged Results

在”合并结果的管道”中，管道在包含源分支和目标分支的合并结果的新引用上运行. 但是，此参考不适用于gitlab-qa-mirror管道.

因此，在”合并结果”管道上的端到端测试将使用合并请求源分支的头部.

graph LR A[“a1b1c1 - branch HEAD (CI_MERGE_REQUEST_SOURCE_BRANCH_SHA)”] B[“x1y1z1 - master HEAD”] C[“d1e1f1 - merged results (CI_COMMIT_SHA)”] A —> C B —> C A —> E[“E2E tests”] C —> D[“Pipeline for merged results”]

Running custom tests

在下游gitlab-qa-mirror管道中运行的现有场景包括许多测试，但是有时您可能想要运行一个测试或一组与任何现有场景中的组不同的测试.

例如，当我们对一个薄片状测试进行隔离时，我们首先要确保它不再是薄片状的. 我们可以使用ce:custom-parallel和ee:custom-parallel作业来做到这一点. 两者都是手动作业，您可以使用自定义变量进行配置. 单击并行作业之一的名称（而不是播放图标）时，系统将提示您输入变量. 您可以使用gitlab-qa可以使用的任何变量以及这些变量 ：

Variable Description
QA_SCENARIO 要运行的方案（默认Test::Instance::Image ）
QA_TESTS 要运行的测试（没有默认设置，这意味着运行方案中的所有测试）. 通过 RSpec 运行测试时，请使用文件路径，例如， qa/specs/features/ee/browser_ui将包括所有EE UI 测试.
QA_RSPEC_TAGS 要添加的 RSpec 标记（无默认值）

现在， 具有自定义变量的手动作业在重试时将不会使用相同的变量 ，因此，如果要多次运行相同的测试，请在每个custom-parallel作业中指定相同的变量（最多可使用 10 个变量）您要运行的作业）.

Using the review-qa-all jobs

在test阶段的每个管道上，都会自动启动review-qa-smoke作业：它将针对Review App运行 QA 烟雾套件.

您还可以手动启动review-qa-all ：它针对Review App运行完整的质量检查套件.

This runs end-to-end tests against a Review App based on the official GitLab Helm chart, itself deployed with custom Cloud Native components built from your merge request’s changes.

有关审阅应用程序的更多详细信息，请参见审阅应用程序.

How do I run the tests?

如果您不是在合并请求中测试代码 ，则有两个主要选项可用于运行测试. 如果您只想对一个实时的 GitLab 实例或一个预先构建的 Docker 映像运行现有测试，则可以使用GitLab QA 协调器 . 另请参见可以通过 Orchestrator 运行的测试方案示例 .

另一方面，如果您想在本地开发的 GitLab 环境中运行，则可以使用GitLab 开发工具包（GDK） . 请参考质量检查自述文件和以下部分中的说明.

Running tests that require special setup

了解如何执行需要特殊设置或考虑才能在本地环境上运行的测试 .

How do I write tests?

为了编写新的测试，您首先需要了解有关 GitLab QA 体系结构的更多信息. 请参阅有关文档 .

一旦决定了将测试环境业务流程场景和实例级场景放置在何处，请查看GitLab QA 自述文件 ， GitLab QA Orchestrator 自述文件和已经存在的实例级场景 .

继续阅读：

Where can I ask for help?

您可以在 Slack 上的#quality频道（GitLab 内部）上gitlab ，或者在gitlab-qa 问题跟踪器或gitlab-qa问题跟踪器中找到您要gitlab-qa问题 .