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

처음부터 끝까지 테스트

처음부터 끝까지 테스트란 무엇인가요?

처음부터 끝까지(e2e) 테스트는 애플리케이션이 기대하는 대로 모든 소프트웨어 스택과 아키텍처에서 작동하는지 확인하기 위해 사용되는 전략입니다.

모든 마이크로서비스와 함께 작동해야 하는 구성 요소의 통합을 포함합니다.

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

우리는 Omnibus GitLab를 사용하여 GitLab 패키지를 빌드한 후, qa 디렉토리에 위치한 처음부터 끝까지 테스트를 실행하기 위해 GitLab QA 오케스트레이터 도구를 사용하여 이 패키지를 테스트합니다.

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

야간 빌드 테스트

매일 밤 스케줄된 파이프라인을 실행하여 Omnibus에서 생성된 야간 빌드를 테스트합니다.

이 파이프라인은 https://gitlab.com/gitlab-org/gitlab/-/pipeline_schedules 에서 찾을 수 있습니다.

(개발자 역할이 필요합니다). 결과는 #e2e-run-master Slack 채널에 보고됩니다.

스테이징 테스트

매일 밤 스케줄된 파이프라인을 실행하여 스테이징을 테스트합니다.

이 파이프라인은 https://gitlab.com/gitlab-org/quality/staging/pipelines 에서 찾을 수 있습니다.

(개발자 역할이 필요합니다). 결과는 #e2e-run-staging Slack 채널에 보고됩니다.

병합 요청에서 코드 테스트

test-on-omnibus 작업 사용하기

병합 요청에 대해 qa 단계에서 e2e:test-on-omnibus 수동 작업을 호출하여 처음부터 끝까지 테스트를 실행할 수 있습니다.

(포크에 대해 사용 가능하지 않음).

이는 병합 요청의 변경 사항에서 빌드된 커스텀 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: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. 개발자는 build-qa-image 및 build-assets-image 작업이 완료된 후 사용할 수 있는 수동 작업인 e2e:test-on-omnibus를 트리거합니다. 이는 GitLab 병합 요청에서 찾을 수 있습니다.
2. E2E 하위 파이프라인은 gitlab-org/build/omnibus-gitlab-mirror에서 다운스트림 파이프라인을 트리거하고 결과 상태를 폴링합니다. 우리는 이를 _상태 귀속_이라고 부릅니다.
gitlab-org/build/omnibus-gitlab-mirror 파이프라인에서:
1. Docker 이미지가 빌드되고 컨테이너 레지스트리에 푸시됩니다.
2. Docker 이미지가 빌드되고 푸시된 후 테스트 단계의 작업이 시작됩니다.
테스트 단계에서:
1. gitlab-org/build/omnibus-gitlab-mirror 레지스트리에 저장된 Docker 이미지 컨테이너가 실행됩니다.
2. 처음부터 끝까지 테스트가 gitlab-qa 실행 가능 파일로 실행되며, 이는 gitlab-org/gitlab 레지스트리의 끝에서 끝까지 이미지에 대한 컨테이너를 실행합니다.

참고: 우리는 gitlab-org/build/omnibus-gitlab-mirror를 사용하고 있습니다,

gitlab-org/omnibus-gitlab 대신.

이는 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에서 만들어졌습니다.

e2e:test-on-omnibus 파이프라인에 새로운 테스트 작업을 추가하는 CI/CD 설정 및 문서에 대한 더 많은 기술 세부정보는 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 인스턴스에 대해 엔드 투 엔드 테스트를 실행하는 하위 파이프라인을 생성합니다.

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

병합 결과 파이프라인에서

병합 결과 파이프라인에서는 파이프라인이 소스 및 대상 브랜치의 병합 결과를 포함하는 새로운 ref에서 실행됩니다.

병합 결과 파이프라인에서의 엔드 투 엔드 테스트는 머지 요청 소스 브랜치의 HEAD 대신 새로운 ref를 사용합니다.

graph LR A["x1y1z1 - master HEAD"] B["d1e1f1 - merged results (CI_COMMIT_SHA)"] A --> B B --> C["병합 결과 파이프라인"] C --> D["E2E 테스트"]

사용자 정의 테스트 실행

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

예를 들어, 우리가 격리 해제해야 하는 불안정한 테스트가 있을 때, 먼저 그것이 더 이상 불안정하지 않은지 확인하고 싶습니다.

우리는 _ee:quarantine 수동 작업을 실행하여 이를 확인할 수 있습니다.

수동 작업의 이름(재생 아이콘이 아님)을 선택할 때 변수를 입력하라는 메시지가 표시됩니다.

다음과 같은 변수를 사용할 수 있습니다:

변수	설명
`QA_SCENARIO`	실행할 시나리오 (기본값 `Test::Instance::Image`)
`QA_TESTS`	실행할 테스트 (기본값 없음, 즉 시나리오의 모든 테스트를 실행). 예를 들어 `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 보고서는 자동으로 생성되어 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:test-on-omnibus`. 라이브 환경 테스트 실행을 위해 프로젝트 이름으로 자동 유추됩니다. 기본값 없음.
`QA_EXPORT_TEST_METRICS`	`false`	InfluxDB로 메트릭 내보내기를 활성화하거나 비활성화하는 플래그. 기본값은 `false`입니다.
`QA_SAVE_TEST_METRICS`	`false`	메트릭을 JSON 파일로 저장할지 여부를 활성화하거나 비활성화하는 플래그. 기본값은 `false`입니다.

테스트 보고서

Allure 보고서

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

QA 프레임워크는 Allure 테스트 보고서를 위한 소스 파일을 생성하기 위해
Allure RSpec
젬을 사용하고 있습니다. 파이프라인의 추가 작업:

모든 테스트 작업에서 이러한 소스 파일을 가져옵니다.
보고서를 생성하고 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 오케스트레이터를 사용하세요.
또한 오케스트레이터를 통해 실행할 수 있는 테스트 시나리오 예시를 참조하세요.

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

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

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

테스트를 어떻게 작성합니까?

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

test environment orchestration scenarios와 instance-level scenarios를 어디에 두어야 할지 결정한 후, GitLab QA README, GitLab QA orchestrator README, 그리고 이미 존재하는 instance-level scenarios를 살펴보세요.

엔드 투 엔드 테스트를 작성하지 않는 것을 고려하세요

엔드 투 엔드 테스트를 위해 다음과 같은 모범 사례를 따라야 합니다:

하위 수준 기능 테스트가 존재하는 경우 엔드 투 엔드 테스트를 작성하지 마세요. 엔드 투 엔드 테스트는 더 많은 작업과 자원을 요구합니다.
엔드 투 엔드 테스트의 문제 해결은 테스트 대상 애플리케이션에 대한 연결이 알려져 있지 않기 때문에 더 복잡할 수 있습니다.

계속 읽기:

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

Slack의 #test-platform 채널에서 질문할 수 있으며 (GitLab 내부)

작업하고 싶은 문제를 gitlab 이슈 트래커에서 찾거나

gitlab-qa 이슈 트래커에서 찾을 수 있습니다.

처음부터 끝까지 테스트