엔드-투-엔드 테스트

요약

엔드-투-엔드(e2e) 테스트는 함께 동작하도록 설계된 모든 마이크로서비스와 구성 요소의 통합을 포함하여, 애플리케이션이 전체 소프트웨어 스택과 아키텍처 전반에서 기대한 대로 동작하는지 확인하는 전략입니다. GitLab은 다음과 같이 테스트합니다.

엔드-투-엔드 테스트 개요#

엔드-투-엔드(e2e) 테스트는 함께 동작하도록 설계된 모든 마이크로서비스와 구성 요소의 통합을 포함하여, 애플리케이션이 전체 소프트웨어 스택과 아키텍처 전반에서 기대한 대로 동작하는지 확인하는 전략입니다.

GitLab 테스트 방식#

GitLab은 다음과 같이 테스트합니다.

CNG로 GitLab 클라우드 네이티브 패키지를 빌드합니다.
orchestrator CLI 도구로 이 패키지를 배포해 E2E 테스트를 실행할 GitLab 인스턴스를 띄웁니다.

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

나이틀리 빌드 테스트#

Omnibus가 만든 나이틀리 빌드를 테스트하기 위해 매일 밤 예약 파이프라인을 실행합니다. 이 파이프라인은 https://gitlab.com/gitlab-org/gitlab/-/pipeline_schedules에서 확인할 수 있습니다(Developer 권한 필요). 결과는 #e2e-run-master Slack 채널에 보고됩니다.

스테이징 테스트#

스테이징을 테스트하기 위해 매일 밤 예약 파이프라인을 실행합니다. 이 파이프라인은 https://gitlab.com/gitlab-org/quality/staging/pipelines에서 확인할 수 있습니다(Developer 권한 필요). 결과는 #e2e-run-staging Slack 채널에 보고됩니다.

머지 리퀘스트에서 코드 테스트#

엔드-투-엔드 테스트 파이프라인 문서는 머지 리퀘스트 안에서 E2E 테스트를 실행하는 파이프라인 구성을 설명합니다.

test-on-omnibus job 사용#

qa 스테이지의 e2e:test-on-omnibus-ee 수동 작업을 실행하면 머지 리퀘스트에 대해 엔드-투-엔드 테스트를 실행할 수 있습니다(포크에서는 사용할 수 없습니다).

이 작업은 머지 리퀘스트의 변경 사항으로 빌드한 커스텀 EE(Ultimate 라이선스 포함) Docker 이미지를 대상으로 엔드-투-엔드 테스트를 실행합니다.

엔드-투-엔드 테스트를 시작하는 수동 작업은 gitlab-org/omnibus-gitlab 머지 리퀘스트에서도 제공됩니다.

머지 결과 파이프라인 사용#

머지 결과 파이프라인에서는 소스 브랜치와 대상 브랜치를 병합한 결과를 담은 새 ref에서 파이프라인이 실행됩니다.

머지 결과 파이프라인의 엔드-투-엔드 테스트는 머지 리퀘스트 소스 브랜치의 HEAD 대신 이 새 ref를 사용합니다.

Mermaid 다이어그램 (9줄)

소스 코드 보기

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 수동 job을 실행해 확인할 수 있습니다. 수동 job의 이름(재생 아이콘이 아님)을 선택하면 변수를 입력하라는 안내가 표시됩니다. gitlab-qa와 함께 사용할 수 있는 변수 외에 다음 변수도 사용할 수 있습니다.

변수	설명
`QA_SCENARIO`	실행할 시나리오입니다(기본값 `Test::Instance::Image`).
`QA_TESTS`	실행할 테스트입니다(기본값 없음, 즉 시나리오의 모든 테스트를 실행). RSpec으로 테스트를 실행할 때와 같은 방식으로 파일 경로를 사용합니다. 예를 들어 `qa/specs/features/ee/browser_ui`는 모든 `EE` UI 테스트를 포함합니다.
`QA_RSPEC_TAGS`	추가할 RSpec 태그입니다(기본값 `--tag quarantine`).

현재는 커스텀 변수를 사용하는 수동 job 이 재시도 시 같은 변수를 사용하지 않으므로, 같은 테스트를 여러 번 실행하려면 각 custom-parallel job에 같은 변수를 지정해야 합니다(실행하려는 만큼, 최대 10개 job까지).

선택적 테스트 실행#

머지 리퀘스트에서 실행되는 테스트 수를 제한하기 위해 실행할 테스트를 동적으로 선택하는 기능이 있습니다. 실행할 테스트를 결정하는 알고리즘은 변경된 파일과 머지 리퀘스트 레이블을 기준으로 합니다. 다음 기준에 따라 실행할 테스트가 정해집니다.

qa 프레임워크 코드가 변경되면 전체 스위트를 실행합니다.
qa 폴더의 특정 _spec.rb 파일이 변경되면 해당 테스트만 실행합니다. 이 경우 knapsack으로 job을 병렬 실행하지 않습니다.

코드 경로 매핑 기반 선택적 테스트 실행#

coverband gem을 backend MR의 E2E 선택적 테스트 실행에 비표준 방식으로 사용합니다.
coverband는 COVERBAND_ENABLED 환경 변수가 설정된 경우에만 GitLab 애플리케이션에서 활성화됩니다. 이 변수는 master의 예약된 e2e:test-on-cng 파이프라인에서만 설정되며 MR 파이프라인에서는 설정되지 않습니다.
소스 코드 경로는 내부 API를 사용해 각 E2E 예제가 시작되기 전과 각 E2E 예제가 끝난 후에 매핑됩니다.
통합된 전체 매핑은 GCS의 code-path-mappings 버킷에 업로드됩니다.

코드 경로 매핑은 예약된 test-on-cng 파이프라인이 생성합니다. 자세한 내용은 에픽 47을 참고합니다.

선택적 테스트 실행 재정의#

선택적 테스트 실행을 재정의하고 전체 스위트를 실행하려면 해당 머지 리퀘스트에 pipeline:run-all-e2e 레이블을 추가합니다.

엔드-투-엔드 테스트 건너뛰기#

엔드-투-엔드 테스트 스위트를 실행할 필요가 없는 경우도 있습니다.

다음과 같은 예가 있습니다.

~"Stuff that should Just Work"
소규모 리팩터링
리뷰 중 요청된 작은 변경으로, 전체 스위트를 다시 실행할 필요가 없는 경우

머지 리퀘스트에 pipeline:skip-e2e 레이블을 적용하면 엔드-투-엔드 테스트 실행을 건너뜁니다.

Warning

엔드-투-엔드 테스트를 건너뛰는 데는 위험이 따릅니다. 이 레이블은 신중하게 판단해 적용합니다. 엔드-투-엔드 테스트 스위트는 변경 사항이 기본 브랜치에 병합되기 전 마지막 방어선입니다. 이 테스트를 건너뛰면 코드베이스에 회귀가 유입될 위험이 커집니다.

동적 병렬 job 스케일링#

파이프라인 실행 시간을 일정하게 유지하기 위해, 각 E2E 테스트 스위트의 CI/CD job 수는 해당 스위트에 포함된 테스트의 총 실행 시간에 따라 동적으로 조정됩니다. generate_e2e_pipelines Rake 작업은 다음을 수행하는 CI/CD YAML 파일을 생성합니다.

적절한 수의 병렬 job을 생성합니다.
실행할 테스트가 없으면 해당 job을 아예 건너뜁니다.

이 기능은 선택적 테스트 실행과 함께 동작하여, 머지 리퀘스트의 변경 사항에 맞춰 파이프라인 실행 시간과 비용을 최대한 최적화합니다.

설계 개요#

동적 job 스케일링은 Test Scenario 클래스를 기반으로 합니다. 이 추상화는 다음을 캡슐화합니다.

특정 시나리오가 실행해야 할 RSpec 태그.
시나리오를 특정 스펙 파일로 제한할 수 있는 선택적 스펙 파일 패턴.
특정 시나리오가 머지 리퀘스트 파이프라인에서 실행될 파이프라인 유형과 job을 정의하는 파이프라인 매핑.

PipelineCreator 클래스는 병렬 job 수가 동적으로 조정된 파이프라인 YAML 파일을 생성합니다. 파이프라인 YAML을 생성하기 전에 PipelineCreator는 정의된 모든 Test Scenario 클래스를 순회하며 각 CI/CD job의 총 테스트 실행 시간을 계산한 매핑을 만듭니다. 이 정보를 바탕으로 병렬 job 수가 올바르게 조정된 파이프라인 YAML 파일이 생성됩니다.

PipelineCreator는 여기에 더해 선택적 테스트 실행의 입력을 받아 실행할 테스트의 총 개수를 더 줄입니다.

머지 리퀘스트 파이프라인에서 실행되고 병렬 job을 동적으로 조정하는 새 시나리오를 만드는 예는 E2E 테스트 파이프라인에 새 job 추가를 참고합니다.

테스트 파이프라인 도구 및 구성#

테스트 병렬화#

GitLab의 CI 설정은 테스트 병렬화를 위해 knapsack gem을 사용합니다. Knapsack 보고서는 자동으로 생성되어 gitlab-qa-resources 프로젝트의 knapsack-reports GCS 버킷에 저장됩니다. KnapsackReport 헬퍼가 보고서 생성과 업로드 과정을 관리합니다.

테스트 메트릭#

테스트 상태 가시성을 높이기 위해, 별도의 구성으로 파이프라인의 테스트 실행 결과를 GCS 버킷에 내보내고 그 결과를 Snowflake 대시보드에서 시각화합니다.

테스트 보고서#

Allure 보고서#

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

QA 프레임워크는 Allure 테스트 보고서의 소스 파일을 생성하기 위해 Allure RSpec gem을 사용합니다. 파이프라인의 추가 job은 다음을 수행합니다.

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

보고서 업로드용 공통 CI 템플릿은 allure-report.yml에 있습니다.

머지 리퀘스트#

이 테스트가 머지 리퀘스트 범위에서 실행되면 Allure 보고서가 S3 버킷에 업로드됩니다. 보고서 링크는 e2e-test-report job 로그 끝에 출력됩니다.

예약 파이프라인#

이 테스트의 예약 파이프라인에는 Report 스테이지에 generate-allure-report job 이 포함됩니다. 이 파이프라인도 현재 테스트 보고서 링크를 출력합니다. 예약 파이프라인 유형마다 스테이지에 따라 최신 테스트 보고서의 고정 링크를 생성합니다. 목록은 GitLab 핸드북에서 확인할 수 있습니다.

프로비저닝#

모든 구성 요소의 프로비저닝은 engineering-productivity-infrastructure 프로젝트가 수행합니다.

CI에서 메트릭 내보내기#

메트릭 내보내기는 다음 환경 변수로 구성합니다.

변수	필수 여부	정보
`QA_RUN_TYPE`	`false`	`e2e:test-on-omnibus-ee`와 같은 테스트 실행의 임의 이름입니다. 라이브 환경 테스트 실행에서는 프로젝트 이름에서 자동으로 추론됩니다. 기본값은 없습니다.
`QA_EXPORT_TEST_METRICS`	`false`	GCS 로의 메트릭 내보내기를 활성화 또는 비활성화하는 플래그입니다. 기본값은 `false` 입니다.

테스트 실행 방법#

머지 리퀘스트에서 코드를 테스트하는 경우가 아니라면, 테스트를 실행하는 방법은 크게 두 가지입니다. 기존 테스트를 실행 중인 GitLab 인스턴스나 사전 빌드된 Docker 이미지를 대상으로 실행하려면 GitLab QA orchestrator를 사용합니다. orchestrator로 실행할 수 있는 테스트 시나리오 예시도 함께 참고합니다.

반면 로컬 개발용 GitLab 환경을 대상으로 실행하려면 GitLab Development Kit(GDK)를 사용할 수 있습니다. QA README의 안내와 아래 절을 참고합니다.

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

로컬 환경에서 실행하려면 특별한 설정이나 고려가 필요한 테스트를 수행하는 방법을 확인합니다.

테스트 작성 방법#

새 테스트를 작성하기 전에 GitLab QA 아키텍처를 검토합니다.

테스트 환경 오케스트레이션 시나리오와 인스턴스 수준 시나리오를 어디에 둘지 정한 다음에는 GitLab QA README, GitLab QA orchestrator README, 이미 존재하는 인스턴스 수준 시나리오를 살펴봅니다.