엔드 투 엔드 테스트란 무엇인가요?
GitLab을 어떻게 테스트합니까?
테스트 지표
- 프로비저닝
- CI에서 메트릭 내보내기
테스트 보고서
- Allure 보고서
테스트를 어떻게 실행하나요?
- 특별한 설정이 필요한 테스트 실행 방법
테스트를 어떻게 작성하나요?
- End-to-end 테스트를 작성하지 않는 것을 고려하세요
어디에서 도움을 요청할 수 있나요?

엔드 투 엔드 테스트

엔드 투 엔드 테스트란 무엇인가요?

엔드 투 엔드 (e2e) 테스트는 응용 프로그램이 전체 소프트웨어 스택 및 아키텍처 전체에서 예상대로 작동하는지 확인하는 데 사용되는 전략입니다. 이는 모든 마이크로 서비스 및 함께 작동해야 하는 구성 요소의 통합도 포함합니다.

GitLab을 어떻게 테스트합니까?

GitLab을 빌드하기 위해 Omnibus GitLab을 사용한 다음 이러한 패키지를 테스트하기 위해 GitLab QA orchestrator 도구를 사용하여 qa 디렉토리에 위치한 엔드 투 엔드 테스트를 실행합니다.

또한, 더 빠른 테스트 피드백을 얻기 위해 퀵리 배포할 수 있는 테스트 환경으로 GitLab Development Kit(GDK)을 사용합니다.

매일 밤 빌드 테스트하기

우리는 매일 예약된 파이프라인을 실행하여 Omnibus에서 생성된 매일 밤 빌드를 테스트합니다. 이 파이프라인은 https://gitlab.com/gitlab-org/gitlab/-/pipeline_schedules에서 찾을 수 있습니다(개발자 권한 필요). 결과는 #e2e-run-master 슬랙 채널에 보고됩니다.

스테이징 테스트하기

우리는 매일 예약된 파이프라인을 실행하여 스테이징을 테스트합니다. 이 파이프라인은 https://gitlab.com/gitlab-org/quality/staging/pipelines에서 찾을 수 있습니다(개발자 권한 필요). 결과는 #e2e-run-staging 슬랙 채널에 보고됩니다.

병합 요청에서 코드 테스트하기

test-on-omnibus 작업 사용하기

병합 요청에 대한 엔드 투 엔드 테스트를 실행하는 것은 qa 단계의 e2e:test-on-omnibus 수동 작업을 트리거하는 것이 가능합니다(포크에는 사용할 수 없음).

이 작업은 병합 요청의 변경 사항에서 빌드된 사용자 EE(최종 라이센스) 도커 이미지에 대해 엔드 투 엔드 테스트를 실행합니다.

병합 요청에서 엔드 투 엔드 테스트를 시작하는 수동 작업은 또한 gitlab-org/omnibus-gitlab 병합 요청에서 사용할 수 있습니다.

이 작업은 어떻게 작동합니까?

현재 우리는 Omnibus GitLab에 대한 엔드 투 엔드 파이프라인을 실행하기 위해 _multi-project pipeline_와 유사한 접근 방식을 사용하고 있습니다.

graph TB A1 -.->|한 번 완료되면 트리거할 수 있음| A2 A2 -.->|1. `omnibus-gitlab-mirror` 파이프라인을 트리거하고 완료될 때까지 대기| B1 B2[`Trigger-qa` 단계 `Trigger:qa-test` 작업] -.->|2. `gitlab-qa-mirror` 파이프라인을 트리거하고 완료될 때까지 대기| C1 subgraph "`gitlab-org/gitlab` 파이프라인" A1[`build-images` 단계 `build-qa-image` 및 `build-assets-image` 작업] A2[`qa` 단계 `e2e:test-on-omnibus` 작업] end subgraph "`gitlab-org/build/omnibus-gitlab-mirror` 파이프라인" B1[`Trigger-docker` 단계 `Trigger:gitlab-docker` 작업] -->|한 번 완료되면| B2 end subgraph "`gitlab-org/gitlab-qa-mirror` 파이프라인" C1[엔드 투 엔드 작업 실행] end

gitlab-org/gitlab 파이프라인에서:
1. 개발자는 e2e:test-on-omnibus 수동 작업( build-qa-image 및 build-assets-image 작업이 완료되면 사용 가능)을 트리거합니다. 이 작업은 GitLab 병합 요청에서 찾을 수 있습니다.
2. E2E 자식 파이프라인은 결과 상태를 폴링하며 gitlab-org/build/omnibus-gitlab-mirror에서 하류 파이프라인을 트리거합니다. 우리는 이를 _상태 속성_이라고 부릅니다.
gitlab-org/build/omnibus-gitlab-mirror 파이프라인에서:
1. 도커 이미지가 빌드되어 컨테이너 레지스트리에 푸시됩니다.
2. 도커 이미지가 빌드되고 푸시된 후 test 단계의 작업이 시작됩니다.
Test 단계에서:
1. gitlab-org/build/omnibus-gitlab-mirror 레지스트리에 저장된 도커 이미지를 위한 컨테이너가 시작됩니다.
2. gitlab-qa 실행 파일로 엔드 투 엔드 이미지를 시작하여 엔드 투 엔드 테스트가 실행됩니다.

참고: gitlab-org/omnibus-gitlab 대신 gitlab-org/build/omnibus-gitlab-mirror를 사용하는 것을 확인하셨을 것입니다. 이는 GitLab 권한 모델의 기술적 제한 때문입니다. 보호된 브랜치에 대한 파이프라인을 실행할 수 있는 능력은 해당 브랜치로 푸시/병합할 수 있는 능력에 의해 제어됩니다. 이는 gitlab-org/omnibus-gitlab의 기본 브랜치에 대해 모든 개발자가 이 브랜치에 대해 유지자 역할을 갖고 있어야만 파이프라인을 트리거할 수 있다는 것을 의미합니다. 보안상의 이유와 영향 때문에 우리는 모든 개발자에게 기본 브랜치를 열지 못했습니다. 그래서 우리는 미러를 만들어 개발자와 유지자가 기본 브랜치로 푸시/병합할 수 있도록 했습니다. 이 문제는 https://gitlab.com/gitlab-org/gitlab-qa/-/issues/63#note_107175160에서 발견되었고 “미러” 해결책이 https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4717에서 제안되었습니다. 파이프라인을 실행하는 능력을 푸시/병합하는 능력에서 분리하는 기능 제안은 https://gitlab.com/gitlab-org/gitlab/-/issues/24585에서 생성되었습니다.

CI/CD 설정에 대한 기술적 세부 정보 및 e2e:test-on-omnibus 파이프라인에 새로운 테스트 작업을 추가하기 위한 문서에 대한 자세한 내용은 e2e:test-on-omnibus 설정 문서를 참조하십시오.

`test-on-gdk` 작업 사용

e2e:test-on-gdk 작업은 대부분의 병합 요청에서 자동으로 실행되며, 이로 인해 하위 파이프라인이 트리거됩니다. 이 하위 파이프라인은 병합 요청의 변경 사항으로부터 GDK 인스턴스를 빌드하고 설치한 후 해당 GDK 인스턴스에 대해 종단 간 테스트를 실행합니다.

작동 방식

gitlab-org/gitlab 파이프라인에서:

build-gdk-image 작업 은 병합 요청의 코드를 사용하여 GDK 인스턴스용 Docker 이미지를 빌드합니다.
e2e:test-on-gdk 트리거 작업은 이전 작업에서 빌드된 이미지로부터 시작된 GDK 인스턴스에 대해 종단 간 테스트를 실행하는 하위 파이프라인을 생성합니다.

자세한 내용은 documentation for the e2e:test-on-gdk pipeline를 참조하세요.

병합된 결과 파이프라인으로

병합된 결과 파이프라인에서 해당 파이프라인은 소스 브랜치와 대상 브랜치의 병합 결과를 포함한 새 참조에서 실행됩니다.

병합된 결과 파이프라인에서의 종단 간 테스트는 병합 결과 소스 브랜치의 헤드 대신 새 참조를 사용합니다.

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`	실행할 시나리오(default `Test::Instance::Image`)
`QA_TESTS`	실행할 테스트(기본값 없음. 이는 시나리오의 모든 테스트를 실행하는 것을 의미합니다). RSpec를 통해 테스트를 실행할 때 파일 경로를 사용하세요. 예를 들어, `qa/specs/features/ee/browser_ui`는 `EE` UI 테스트를 모두 포함합니다.
`QA_RSPEC_TAGS`	추가할 RSpec 태그(기본값 `--tag quarantine`)

현재, 사용자 지정 변수를 사용하여 다시 시도하는 경우 동일한 변수를 사용하지 않습니다, 따라서 동일한 테스트를 여러 번 실행하려면 각 custom-parallel 작업에 동일한 변수를 지정하세요. (실행하려는 10개 작업까지)

선택적 테스트 실행

병합 요청에서 실행되는 테스트의 양을 제한하기 위해 파일 변경 및 병합 요청 레이블에 따라 실행할 테스트를 동적으로 선택하는 기능이 있습니다. 실행할 테스트의 알고리즘은 다음과 같은 기준에 기반합니다.

qa 프레임워크 코드의 변경 사항은 전체 스위트를 실행합니다.
qa 폴더의 특정 _spec.rb 파일의 변경 사항은 해당 특정 테스트만 실행합니다. 이 경우 knapsack는 병렬로 작업을 실행하지 않습니다.
백엔드 변경과 레이블 devops::manage을 가진 병합 요청은 manage 단계와 관련된 모든 e2e 테스트를 실행합니다. 이 경우 knapsack를 사용하여 작업을 병렬로 실행합니다.

선택적 테스트 실행 무시

선택적 테스트 실행을 무시하고 전체 스위트를 트리거하려면 특정 병합 요청에 레이블 pipeline:run-all-e2e를 추가하세요.

종단 간 테스트 건너뛰기

일부 경우에는 종단 간 테스트 스위트를 실행할 필요가 없을 수 있습니다.

예를 들면:

~"잘 작동해야 하는 것"
작은 리팩터링
리뷰 중에 작은 요청 변경, 전체 스위트를 두 번 실행할만한 가치가 없는 경우

최종 사용자가 특정 병합 요청에 레이블 pipeline:skip-e2e를 적용하여 종단 간 테스트를 건너뛸 수 있습니다.

경고: 종단 간 테스트를 건너뛰는 것에는 위험이 있습니다. 이 레이블을 적용할 때 신중하고 분별하여 사용하세요. 종단 간 테스트 스위트는 변경 사항이 기본 브랜치에 병합되기 전에 마지막으로 실행되는 테스트입니다. 이러한 테스트를 건너뛰면 코드베이스에 회귀 사항을 도입할 위험이 증가합니다.

병렬로 테스트 실행

CI에서 테스트를 병렬로 실행하기 위해 Knapsack gem이 사용됩니다. Knapsack 보고서는 자동으로 생성되어 GCS 버킷 gitlab-qa-resources의 knapsack-reports에 저장됩니다. KnapsackReport 도우미는 자동 보고서 생성 및 업로드를 처리합니다.

테스트 지표

추가적인 테스트 상태를 확인하기 위해 테스트 실행 결과를 InfluxDb 인스턴스에 내보내고 결과를 Grafana 대시보드로 시각화하는 사용자 정의 설정을 사용하세요.

프로비저닝

모든 구성 요소의 프로비저닝은 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`와 같이 테스트 실행을 위한 임의의 이름입니다. 라이브 환경 테스트 실행에 대해 프로젝트 이름에서 자동으로 추론됩니다. 기본 값은 없습니다.
`QA_EXPORT_TEST_METRICS`	`false`	InfluxDB로의 메트릭 내보내기를 활성화하거나 비활성화하는 플래그입니다. 기본 값은 `false`입니다.
`QA_SAVE_TEST_METRICS`	`false`	메트릭을 JSON 파일로 저장하거나 저장하지 않도록 하는 플래그입니다. 기본 값은 `false`입니다.

테스트 보고서

Allure 보고서

추가적인 테스트 결과 가시성을 위해 파이프라인에서 실행되는 테스트는 Allure 테스트 보고서를 생성하고 호스팅합니다.

QA 프레임워크는 Allure RSpec gem을 사용하여 Allure 테스트 보고서의 소스 파일을 생성합니다. 파이프라인의 추가 작업은 다음과 같습니다:

모든 테스트 작업에서 이러한 소스 파일을 가져옵니다.
보고서를 생성하고 AWS 그룹 프로젝트 eng-quality-ops-ci-cd-shared-infra의 gitlab-qa-allure-report라는 S3 버킷에 업로드합니다.

보고서 업로드에 대한 일반 CI 템플릿은 allure-report.yml에 저장되어 있습니다.

머지 요청

이러한 테스트가 머지 요청 범위에서 실행될 때 Allure 보고서는 GCS 버킷에 업로드되며 해당 보고서에 링크를 추가합니다.

예약된 파이프라인

이러한 테스트에 대한 예약된 파이프라인에는 Report 단계에서 generate-allure-report 작업이 포함되어 있습니다. 또한 현재 테스트 보고서로 연결되는 링크가 출력됩니다.

정적 보고서 링크

각 유형의 예약된 파이프라인은 해당 단계에 따라 최신 테스트 보고서에 대한 정적 링크를 생성합니다:

테스트를 어떻게 실행하나요?

만약 머지 요청에서 코드를 테스트하고 싶지 않다면, 테스트를 실행하는 두 가지 주요 옵션이 있습니다. 기존 테스트를 라이브 GitLab 인스턴스나 미리 빌드된 도커 이미지에 대해 실행하려면 GitLab QA orchestrator를 사용하세요. 또한 orchestrator를 통해 실행할 수 있는 테스트 시나리오의 예도 확인하세요.

반면 로컬 개발 GitLab 환경에서 실행하려면 GitLab Development Kit (GDK)을 사용하세요. 자세한 내용은 QA README 및 아래 섹션을 참조하세요.

특별한 설정이 필요한 테스트 실행 방법

로컬 환경에서 실행하기 위해 특별한 설정이나 고려가 필요한 테스트를 수행하는 방법에 대해 알아보세요. 특별한 설정이나 고려가 필요한 테스트를 수행하는 방법을 확인하세요.

테스트를 어떻게 작성하나요?

새로운 테스트를 작성하기 전에 GitLab QA 아키텍처를 확인하세요.

테스트 환경 조작 시나리오 및 인스턴스 수준 시나리오를 배치할 위치를 결정한 후 GitLab QA README, GitLab QA orchestrator README, 기존 인스턴스 수준 시나리오를 살펴보세요.

End-to-end 테스트를 작성하지 않는 것을 고려하세요

우리는 End-to-end 테스트에 대해 다음과 같은 최선의 방법을 따를 것을 권장합니다:

더 낮은 수준의 기능 테스트가 있는 경우 End-to-end 테스트를 작성하지 마십시오. End-to-end 테스트는 더 많은 작업과 리소스를 필요로 합니다.
End-to-end 테스트의 문제 해결은 테스트 애플리케이션과의 연결이 알려지지 않기 때문에 더 복잡할 수 있습니다.

계속해서 읽어보세요:

어디에서 도움을 요청할 수 있나요?

#test-platform 채널(내부 GitLab)에서 질문을 하거나 원하는 작업을 찾을 수 있습니다. gitlab 이슈 트래커 또는 gitlab-qa 이슈 트래커에서 작업할 문제를 찾을 수 있습니다.

엔드 투 엔드 테스트