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

엔드 투 엔드 테스트

엔드 투 엔드 테스트란?

엔드 투 엔드(e2e) 테스트는 응용 프로그램이 전체 소프트웨어 스택과 아키텍처 전체에서 기대한 대로 작동하는지를 확인하는 전략입니다. 이는 모든 마이크로 서비스 및 컴포넌트의 통합을 포함하여 함께 작동해야 하는 전체를 검사합니다.

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

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

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

매일 빌드 테스트

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

스테이징 테스트

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

Merge Request에서 코드 테스트

패키지 및 테스트 작업 사용

qa 단계에서 e2e:package-and-test 매뉴얼 작업을 트리거함으로써 Merge Request에 대한 엔드 투 엔드 테스트를 실행할 수 있습니다(포크된 리포지터리에 대해서는 사용 불가).

이것은 Merge Request의 변경 내용에서 빌드된 사용자 EE(Docker 이미지가 있는 Ultimate 라이선스)에 대한 엔드 투 엔드 테스트를 실행합니다.

엔드 투 엔드 테스트를 시작하는 매뉴얼 작업은 또한 gitlab-org/omnibus-gitlab Merge Request에서 사용할 수 있습니다.

작동 원리는 무엇인가요?

현재 우리는 _다중 프로젝트 파이프라인_과 유사한 방식으로 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 Merge Request에서 찾을 수 있습니다. 이는 엔드 투 엔드 테스트 하위 파이프라인을 시작합니다.
2. 엔드 투 엔드 하위 파이프라인은 gitlab-org/build/omnibus-gitlab-mirror에서 하위 파이프라인을 트리거하고 결과 상태를 폴링합니다. 이를 _상태 어트리뷕션_이라고 합니다.
gitlab-org/build/omnibus-gitlab-mirror 파이프라인에서:
1. Docker 이미지가 빌드되어 해당 컨테이너 레지스트리에 푸시됩니다.
2. Docker 이미지가 빌드되고 푸시된 후 test 단계의 작업이 시작됩니다.
Test 단계에서:
1. gitlab-org/build/omnibus-gitlab-mirror 레지스트리에 저장된 Docker 이미지를 위한 컨테이너가 생성됩니다.
2. gitlab-qa 실행 가능을 사용하여 엔드 투 엔드 이미지를 위한 컨테이너를 활성화한 후 엔드 투 엔드 테스트가 실행됩니다.

gitlab-org/build/omnibus-gitlab-mirror 대신 gitlab-org/omnibus-gitlab을 사용하는 것을 알아차리셨을 겁니다. 이것은 GitLab 권한 모델의 기술적인 제한 때문입니다. 보호된 브랜치에서 파이프라인을 실행하는 능력은 해당 브랜치로 푸시/Merge할 수 있는 능력으로 제어됩니다. 즉, gitlab-org/omnibus-gitlab의 기본 브랜치에 대해 파이프라인을 트리거할 수 있도록 하려면 이 프로젝트의 Maintainer 역할이 필요합니다. 보안상의 이유 및 영향으로, 모든 개발자에게 기본 브랜치를 공개할 수 없었습니다. 따라서 모든 개발자가 기본 브랜치에 대해 파이프라인을 트리거할 수 있는 권한을 열 수 없었습니다. 그래서 우리는 개발자 및 유지 관리자가 기본 브랜치로 푸시/Merge할 수 있는 권한이 있는 미러를 생성했습니다. 이 문제는 https://gitlab.com/gitlab-org/gitlab-qa/-/issues/63#note_107175160에서 발견되었으며, “미러” 해결책이 https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4717에서 제안되었습니다. 새로운 테스트 작업을 e2e:package-and-test 파이프라인에 추가하기 위한 CI/CD 설정에 대한 기술적인 세부 정보 및 문서는 e2e:package_and_test 설정 문서를 참조하십시오.

`test-on-gdk` 작업 사용하기

e2e:test-on-gdk 작업은 대부분의 Merge Request에서 자동으로 실행되며, 이는 자식 파이프라인을 트리거합니다. 이 자식 파이프라인은 Merge Request의 변경 사항을 사용하여 GDK 인스턴스를 빌드하고 설치한 다음 해당 GDK 인스턴스에 대해 종단 간 테스트를 실행합니다.

작동 방식은 어떻게 되나요?

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

build-gdk-image 작업은 Merge Request의 코드를 사용하여 GDK 인스턴스용 Docker 이미지를 빌드합니다.
e2e:test-on-gdk 트리거 작업은 이전 작업에서 빌드된 이미지를 사용하여 GDK 인스턴스에서 종단 간 테스트를 실행하는 자식 파이프라인을 생성합니다.

자세한 내용은 e2e:test-on-gdk 파이프라인 문서를 참조하세요.

Merge Result 파이프라인과 함께

Merge된 결과 파이프라인에서는 해당 파이프라인이 원본 브랜치와 대상 브랜치의 Merge Result를 포함한 새 참조에서 실행됩니다.

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

graph LR A["x1y1z1 - 마스터 HEAD"] B["d1e1f1 - Merge된 결과 (CI_COMMIT_SHA)"] A --> B B --> C["Merge Result 파이프라인"] C --> D["종단 간 테스트"]

사용자화된 테스트 실행

하위 gitlab-qa-mirror 파이프라인에서 실행되는 기존 시나리오에는 많은 테스트가 포함되어 있지만, 기존 시나리오의 그룹과는 다른 테스트 또는 테스트 그룹을 실행하고 싶을 때가 있습니다.

예를 들어, 우리는 flaky한 테스트를 해제할 때, 먼저 해당 테스트가 더 이상 flaky하지 않음을 확인하고 싶습니다. 이를 위해 _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 스위트를 실행합니다.

이는 Merge Request의 변경 사항에서 빌드된 사용자 정의 Cloud Native 컴포넌트로 배포된 공식 GitLab Helm 차트를 기반으로 하는 리뷰 앱에 대한 종단 간 테스트를 실행합니다.

리뷰 앱에 대한 자세한 내용은 리뷰 앱을 참조하세요.

선택적 테스트 실행

Merge Request에서 실행되는 테스트의 양을 제한하기 위해 변경된 파일 및 Merge Request 레이블을 기반으로 테스트를 실행할지 여부를 동적으로 선택하는 알고리즘을 사용합니다. 실행할 테스트의 알고리즘은 다음과 같은 기준에 따라 결정됩니다:

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

선택적 테스트 실행 재정의

선택적 테스트 실행을 무시하고 전체 스위트를 실행하려면 특정 Merge Request에 레이블 pipeline:run-all-e2e를 추가해야 합니다.

병렬로 테스트 실행

CI에서 테스트를 병렬로 실행하려면 Knapsack 젬을 사용합니다. Knapsack 보고서는 자동으로 생성되어 gitlab-qa-resources 프로젝트의 GCS 버킷인 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:package-and-test`와 같이 테스트 실행을 위한 임의의 이름입니다. 라이브 환경 테스트 실행을 위해 프로젝트 이름에서 자동으로 추론됩니다. 기본값은 없습니다.
`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에 위치한 S3 버킷 gitlab-qa-allure-report에 업로드합니다.

보고서 업로드를 위한 공통 CI 템플릿은 allure-report.yml에 저장되어 있습니다.

Merge Request

이러한 테스트가 Merge Request의 범위 내에서 실행되는 경우, Allure 보고서는 GCS 버킷에 업로드되고 해당 보고서에 링크가 추가됩니다.

예약된 파이프라인

이러한 테스트용 예약된 파이프라인에는 Report 단계에 generate-allure-report 작업이 포함됩니다. 또한 현재 테스트 보고서에 대한 링크를 출력합니다.

정적 보고서 링크

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

테스트를 실행하는 방법은?

만약 Merge Request에서 코드를 테스트하는 중이 아니라면, 테스트를 실행하는 두 가지 주요 옵션이 있습니다. 기존 테스트를 실시한 후에 라이브 GitLab 인스턴스 또는 사전 빌드된 Docker 이미지 상에서 테스트를 실행하려면 GitLab QA 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 테스트의 문제 해결은 테스트 대상 애플리케이션에 대한 연결이 알려지지 않기 때문에 더 복잡할 수 있습니다.

계속된 독해:

도움을 요청할 수 있는 곳

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

엔드 투 엔드 테스트