• 엔드투엔드 테스팅이란?
• GitLab을 어떻게 테스트하나요?
  • 매일 밤 빌드 테스트
  • 스테이징 테스트
  • Merge Request에서 코드 테스트
    • 패키지 및 테스트 작업 사용
      • 작동 방식은?
    • test-on-gdk 작업 사용하기
      • 작동 방식은?
    • 합병된 결과 파이프라인을 통해
      • 사용자 지정 테스트 실행
    • 선택적 테스트 실행
    • 선택적 테스트 실행 재정의
  • 병렬로 테스트 실행
• 테스트 지표
  • 프로비저닝
  • CI에서 메트릭스 내보내기
• 테스트 보고서
  • Allure 보고서
• 테스트 실행 방법
  • 특별한 설정이 필요한 테스트 실행
• 테스트를 어떻게 작성하나요?
  • 엔드 투 엔드 테스트를 작성하지 않는 것을 고려해 보세요
• 도움을 받을 수 있는 곳은 어디인가요?

엔드투엔드 테스팅

엔드투엔드 테스팅이란?

엔드투엔드(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에서 코드 테스트

패키지 및 테스트 작업 사용

Merge Request에 대한 엔드투엔드 테스트를 실행하는 것이 가능하며, 이를 위해 e2e:package-and-test 매뉴얼 작업을 qa 단계에서 트리거하여 사용합니다 (포크된 리포지터리에서는 사용할 수 없음).

이 작업은 Merge Request의 변경 내용으로부터 빌드된 사용자 지정 EE(권리 전체) 도커 이미지에 대해 엔드투엔드 테스트를 실행합니다.

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

작동 방식은?

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

1. gitlab-org/gitlab 파이프라인에서:
   1. 개발자가 e2e:package-and-test 매뉴얼 작업을 트리거합니다 (build-qa-image 및 build-assets-image 작업이 완료된 후 사용 가능), 이는 GitLab Merge Request에서 찾을 수 있습니다. 이를 통해 엔드투엔드 자식 파이프라인이 시작됩니다.
   2. 엔드투엔드 자식 파이프라인이 gitlab-org/build/omnibus-gitlab-mirror에서 하향 파이프라인을 트리거하고 결과 상태를 폴링합니다. 이를 _상태 어트리뷰션_이라고 부릅니다.
2. gitlab-org/build/omnibus-gitlab-mirror 파이프라인에서:
   1. 도커 이미지가 빌드되어 컨테이너 레지스트리에 푸시됩니다.
   2. 도커 이미지가 빌드되고 푸시된 후 test 단계에서 작업이 시작됩니다.
3. Test 단계에서:
   1. 컨테이너 레지스트리에 저장된 도커 이미지용 컨테이너가 활성화됩니다.
   2. gitlab-qa 실행 파일을 사용하여 엔드투엔드 이미지용 컨테이너가 활성화됩니다. 이를 통해 엔드투엔드 테스트가 실행됩니다.

test-on-gdk 작업 사용하기

대부분의 Merge Request에서 자동으로 e2e:test-on-gdk 작업이 실행되며, 이는 Merge Request의 변경으로부터 GDK 인스턴스를 빌드하고 설치한 후 해당 GDK 인스턴스에 대해 엔드투엔드 테스트를 실행하는 하위-파이프라인을 트리거합니다.

작동 방식은?

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

1. build-gdk-image 작업는 Merge Request의 코드를 사용하여 GDK 인스턴스용 도커 이미지를 빌드합니다.
2. e2e:test-on-gdk 트리거 작업은 이전 작업에서 빌드된 이미지를 사용하여 엔드투엔드 테스트를 실행하는 하위 파이프라인을 만듭니다.

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

합병된 결과 파이프라인을 통해

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

합병된 결과 파이프라인에서의 엔드투엔드 테스트는 Merge Request 소스 브랜치의 최신 커밋이 아닌 새로운 ref를 사용합니다. ```mermaid graph LR

A[“x1y1z1 - 마스터 HEAD”] B[“d1e1f1 - 합병된 결과 (CI_COMMIT_SHA)”]

A –> B

B –> C[“합병된 결과 파이프라인”] C –> D[“엔드투엔드 테스트”] ```

사용자 지정 테스트 실행

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

예를 들어, 변덕스러운 테스트를 해제할 때에는 먼저 해당 테스트가 더는 변덕스럽지 않음을 확인하고 싶습니다. 그것은 _ee:quarantine 매뉴얼 작업을 실행함으로써 할 수 있습니다. 매뉴얼 작업의 이름(재생 아이콘이 아님)을 선택하면 변수를 입력하라는 메시지가 표시됩니다. 여기에는 gitlab-qa와 함께 사용할 수 있는 변수를 사용할 수 있습니다. 또한 다음과 같은 변수를 사용할 수 있습니다:

현재는 사용자 정의 변수로 실행된 매뉴얼 작업이 재시도될 때 동일한 변수를 사용하지 않습니다 그러므로 동일한 테스트를 여러 번 실행하려면 각 custom-parallel 작업에 동일한 변수를 지정하십시오 (실행할 수 있는 최대 10개의 작업).

선택적 테스트 실행

Merge Request에서 실행할 테스트의 양을 제한하기 위해, 실행할 테스트를 동적으로 선택하는 기능이 있습니다. 실행할 테스트의 알고리즘은 변경된 파일과 Merge Request 레이블에 기반합니다. 다음 기준은 어떤 테스트가 실행될지 결정합니다:

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

선택적 테스트 실행 재정의

선택적 테스트 실행을 재정의하고 전체 스위트를 트리거하려면 특정 Merge Request에 pipeline:run-all-e2e 레이블을 추가하십시오.

병렬로 테스트 실행

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

테스트 지표

추가 테스트 품질 가시성을 위해 InfluxDb 인스턴스로 테스트 실행 결과를 내보내고 Grafana 대시보드에서 결과를 시각화하는 사용자 정의 설정을 사용합니다.

프로비저닝

모든 컴포넌트의 프로비저닝은 engineering-productivity-infrastructure 프로젝트에서 수행됩니다.

CI에서 메트릭스 내보내기

메트릭스 내보내기를 구성하려면 다음 환경 변수를 사용하십시오:

테스트 보고서

Allure 보고서

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

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

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

테스트가 Merge Request의 범위에서 실행될 때 Allure 보고서는 GCS 버킷에 업로드되고 각각의 보고서에 링크가 추가됩니다.

일정된 파이프라인

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

정적 보고서 링크

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

• master
• staging-full
• staging-sanity
• staging-sanity-no-admin
• canary-sanity
• production
• production-sanity

테스트 실행 방법

Merge Request에서 코드를 테스트하는 경우가 아닌 경우, 테스트를 실행하는 두 가지 주요 옵션이 있습니다. 기존 테스트를 라이브 GitLab 인스턴스나 미리 빌드된 Docker 이미지에 대해 실행하려면 GitLab QA 오케스트레이터를 사용합니다. 또한 오케스트레이터를 통해 실행할 수 있는 테스트 시나리오의 예제를 참조하십시오.

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

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

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

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

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

Test 환경 조작 시나리오와 인스턴스 수준 시나리오를 넣을 위치를 결정한 후에, GitLab QA README, GitLab QA orchestrator README, 그리고 이미 존재하는 인스턴스 수준 시나리오를 살펴보세요.

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

엔드 투 엔드 테스트에 대해 다음과 같은 모범 사례를 따를 필요가 있습니다:

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

계속된 독해:

• 초보자 가이드
• 스타일 가이드
• 최상의 실천법
• 피처 플래그로 테스트하기
• 흐름
• RSpec 메타데이터/태그
• 실행 컨텍스트 선택
• 문제 해결

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

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