End-to-end Testing

End-to-end Testing

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

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

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

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

Using the package-and-qa job

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

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

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

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

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

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

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

  4. 当软件包准备就绪并在注册表中可用时， 管道的最后一步将触发新的 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管道中运行的现有场景包括许多测试，但是有时您可能想要运行一个测试或一组与任何现有场景中的组不同的测试.

现在， ，因此，如果要多次运行相同的测试，请在每个custom-parallel作业中指定相同的变量（最多可使用 10 个变量）您要运行的作业）.

Using the review-qa-all jobs

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

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

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

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

如果您不是 ，则有两个主要选项可用于运行测试. 如果您只想对一个实时的 GitLab 实例或一个预先构建的 Docker 映像运行现有测试，则可以使用GitLab QA 协调器 . 另请参见 .

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

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

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

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

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