엔드 투 엔드 테스트

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

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

GitLab을 어떻게 테스트하나요?

우리는 GitLab 패키지를 빌드하기 위해 Omnibus GitLab를 사용하고, 이후 이러한 패키지를 테스트하기 위해 GitLab QA orchestrator 도구를 사용하여 qa 디렉터리에 있는 엔드 투 엔드 테스트를 실행합니다.

추가로, 빠른 테스트 피드백을 위해 신속하게 배포할 수 있는 테스트 환경으로 GitLab Development Kit (GDK)을 사용합니다.

매일 밤 빌드 테스트

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

스테이징 테스트

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

병합 요청에서 코드 테스트

패키지 및 테스트 작업 사용

병합 요청에 대한 엔드 투 엔드 테스트를 실행할 수 있습니다. 이를 위해 qa 단계에서 e2e:package-and-test 수동 동작을 트리거할 수 있습니다(변경 사항을 포함한 사용자 정의 EE(최종 라이선스) Docker 이미지에 대한 엔드 투 엔드 테스트를 실행합니다). 이 작업은 포크에 대해 사용할 수 없습니다.

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

작동 방법

현재 우리는 엔드 투 엔드 파이프라인을 Omnibus GitLab에 대해 실행하기 위해 _멀티 프로젝트 파이프라인_과 유사한 접근 방식을 사용하고 있습니다.

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:package-and-test` 작업] 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:package-and-test 수동 작업을 트리거합니다 (build-qa-image 및 build-assets-image 작업이 완료된 후 사용 가능), 이는 GitLab 병합 요청에서 찾을 수 있습니다. 이로써 엔드 투 엔드 테스트 하위 파이프라인이 시작됩니다.
2. 엔드 투 엔드 자식 파이프라인이 gitlab-org/build/omnibus-gitlab-mirror에서 하향 파이프라인을 트리거하고 결과 상태를 폴링합니다. 이를 _상태 속성_이라고 합니다.
gitlab-org/build/omnibus-gitlab-mirror 파이프라인에서:
1. Docker 이미지가 빌드되어 컨테이너 레지스트리에 푸시됩니다.
2. Docker 이미지가 빌드되고 푸시된 후 test 단계의 작업이 시작됩니다.
Test 단계에서:
1. 컨테이너 레지스트리에 저장된 Docker 이미지의 컨테이너가 생성됩니다.
2. 엔드 투 엔드 테스트가 gitlab-org/gitlab 레지스트리의 엔드 투 엔드 이미지를 위해 컨테이너를 생성하는 gitlab-qa 실행 파일로 실행됩니다.

참고: (GitLab 권한 모델의 기술적 제한으로 인해 우리는 gitlab-org/build/omnibus-gitlab-mirror 대신에 gitlab-org/omnibus-gitlab을 사용합니다. 기본 브랜치에 대한 파이프라인을 실행할 수 있는 권한은 해당 브랜치로 푸시/병합할 수 있는 권한에 의해 결정되기 때문입니다. 즉, gitlab-org/omnibus-gitlab의 기본 브랜치에 대해 파이프라인을 트리거할 수 있어야 하는 개발자는 이 프로젝트에 대해 Maintainer 권한을 갖고 있어야 합니다. 보안 및 영향을 고려하여 우리는 모든 개발자에게 기본 브랜치를 오픈할 수 없었습니다. 이에 따라 우리는 개발자와 Maintainer가 기본 브랜치로 푸시/병합할 수 있는 mirror를 만들었습니다. 이 문제는 https://gitlab.com/gitlab-org/gitlab-qa/-/issues/63#note_107175160에서 발견되었고, “mirror” 해결책이 https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4717에서 제안되었습니다. 파이프라인 실행에 대한 접근 제어를 푸시/병합할 수 있는 능력으로부터 분리하는 것과 관련된 기능 제안도 https://gitlab.com/gitlab-org/gitlab/-/issues/24585에서 생성되었습니다.

CI/CD 설정 및 e2e:package-and-test 파이프라인에 새로운 테스트 작업을 추가하는 문서에 대한 기술적 세부 정보는 e2e:package_and_test 설정 문서에서 확인할 수 있습니다.

`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를 참조하세요.

병합된 결과 파이프라인 사용

병합된 결과 파이프라인에서, 파이프라인은 소스 브랜치와 대상 브랜치의 병합 결과를 포함하는 새로운 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개 작업까지).

`review-qa-all` 작업 사용

test 단계 중에 매번 파이프라인에서 review-qa-smoke 작업이 자동으로 시작됩니다. 이는 레뷰 앱에 대해 QA 스모크 스위트를 실행합니다.

또한 수동으로 review-qa-all을 시작할 수 있습니다. 이 작업은 레뷰 앱에 대해 전체 QA 스위트를 실행합니다.

이는 병합 요청의 변경 사항으로부터 빌드된 공식 GitLab Helm 차트를 기반으로 하는 레뷰 앱에 대해 종단간 테스트를 실행합니다. 또한 사용자 정의된 클라우드 네이티브 컴포넌트로 배포됩니다.

자세한 내용은 레뷰 앱(Review Apps)을 참조하세요.

선택적 테스트 실행

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

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

선택적 테스트 실행 무시하기

선택적 테스트 실행을 무시하고 전체 스위트를 트리거하려면 특정 병합 요청에 pipeline:run-all-e2e 라벨을 추가해야 합니다.

병렬로 테스트 실행하기

CI에서 테스트를 병렬로 실행하려면 Knapsack 젬을 사용합니다. Knapsack 보고서는 자동으로 생성되어 GCS 버킷 knapsack-reports에 gitlab-qa-resources 프로젝트에 저장됩니다. 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:package-and-test`와 같이 프로젝트 이름에서 자동으로 유추되는 테스트 실행을 위한 임의의 이름입니다. 기본 값은 없습니다.
`QA_EXPORT_TEST_METRICS`	`false`	InfluxDB로의 메트릭 내보내기를 활성화 또는 비활성화하는 플래그입니다. 기본값은 `false`입니다.
`QA_SAVE_TEST_METRICS`	`false`	메트릭을 JSON 파일로 저장하는 것을 활성화 또는 비활성화하는 플래그입니다. 기본값은 `false`입니다.

테스트 보고서

Allure 보고서

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

QA 프레임워크는 Allure RSpec 젬을 사용하여 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 인스턴스 또는 빌드된 Docker 이미지에 대해 실행하려면 GitLab QA orchestrator를 사용하세요. 또한 orchestrator를 통해 실행할 수 있는 테스트 시나리오의 예시를 참조하세요.

반면에 로컬 개발 GitLab 환경에 대해 실행하려면 GitLab Development Kit (GDK)를 사용할 수 있습니다. QA README와 아래 섹션의 지침을 참조하세요.

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

로컬 환경에서 실행에 특별한 설정이나 고려를 필요로 하는 테스트를 수행하는 방법을 배워보세요.

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

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

테스트 환경 오케스트레이션 시나리오 및 인스턴스-레벨 시나리오를 둘 곳을 결정한 후 GitLab QA README, GitLab QA 오케스트레이터 README 및 이미 존재하는 인스턴스-레벨 시나리오를 살펴보세요.

무슨 종단 간 테스트를 작성하지 않는 것을 고려하세요

우리는 종단 간 테스트에 대한 다음의 모범 사례를 따르아야 합니다:

더 낮은 수준의 기능 테스트가 이미 존재한다면 종단 간 테스트를 작성하지 마십시오. 종단 간 테스트는 더 많은 작업과 자원을 필요로 합니다.
종단 간 테스트의 문제 해결은 테스트 대상 응용프로그램과의 연결이 알려지지 않아 더 복잡할 수 있습니다.

추가로 읽기:

도움을 받을 수 있는 곳은 어디인가요?

GitLab 내부의 Slack #test-platform 채널에서 질문을 할 수 있거나, 작업하고 싶은 이슈를 gitlab 이슈 트래커나 gitlab-qa 이슈 트래커에서 찾을 수 있습니다.

엔드 투 엔드 테스트