테스트 전략

자동화된 테스트는 다양한 방식으로 앱 품질을 개선하는 데 도움이 됩니다. 예를 들어 검증을 실행하고, 회귀를 포착하고, 호환성을 확인하는 데 도움이 됩니다. 좋은 테스트 전략을 사용하면 자동화된 테스트를 활용하여 중요한 이점인 개발자 생산성에 집중할 수 있습니다.

팀은 인프라 개선과 함께 체계적인 테스트 접근 방식을 사용할 때 생산성 수준을 높일 수 있습니다. 이렇게 하면 코드의 동작 방식에 관한 적절한 시기의 의견을 제공할 수 있습니다. 좋은 테스트 전략은 다음을 수행합니다.

• 문제를 최대한 빨리 포착합니다.
• 빠르게 실행됩니다.
• 문제를 수정해야 하는 경우 명확한 표시를 제공합니다.

이 페이지에서는 구현할 테스트 유형, 테스트를 실행할 위치, 테스트 실행 빈도를 결정하는 데 도움을 줍니다.

android skills add testing-setup

테스트 피라미드

최신 애플리케이션에서는 크기별로 테스트를 분류할 수 있습니다. 소규모 테스트는 코드의 작은 부분에만 집중하므로 빠르고 안정적입니다. 대규모 테스트는 범위가 넓고 유지하기 어려운 복잡한 설정이 필요합니다. 하지만 대규모 테스트는 충실도가 더 높으며 한 번에 훨씬 더 많은 문제를 발견할 수 있습니다.

*충실도는 테스트 런타임 환경과 프로덕션 환경의 유사성을 나타냅니다.

대부분의 앱에는 작은 테스트가 많고 큰 테스트는 상대적으로 적어야 합니다. 각 카테고리의 테스트 분포는 피라미드 형태여야 합니다. 즉, 더 많은 소규모 테스트가 기본을 형성하고 더 적은 대규모 테스트가 끝을 형성해야 합니다.

버그 비용 최소화

좋은 테스트 전략은 버그를 찾는 비용을 최소화하면서 개발자 생산성을 극대화합니다.

비효율적일 수 있는 전략의 예를 살펴보겠습니다. 여기서는 크기별 테스트 수가 피라미드로 구성되지 않습니다. 대규모 엔드 투 엔드 테스트가 너무 많고 구성요소 UI 테스트가 너무 적습니다.

즉, 병합 전에 실행되는 테스트가 너무 적습니다. 버그가 있는 경우 야간 또는 주간 엔드 투 엔드 테스트가 실행될 때까지 테스트에서 이를 포착하지 못할 수 있습니다.

버그를 식별하고 수정하는 비용에 미치는 영향과 테스트 노력을 더 작고 더 자주 실행되는 테스트로 편향하는 것이 중요한 이유를 고려하는 것이 중요합니다.

• 버그가 단위 테스트에 포착되면 일반적으로 몇 분 안에 수정되므로 비용이 저렴합니다.
• 엔드 투 엔드 테스트를 통해 동일한 버그를 발견하는 데 며칠이 걸릴 수 있습니다. 이로 인해 여러 팀 구성원이 참여하게 되어 전반적인 생산성이 저하되고 출시가 지연될 수 있습니다. 이 버그의 비용이 더 높습니다.

하지만 비효율적인 테스트 전략이라도 없는 것보다는 낫습니다. 버그가 프로덕션에 도달하면 수정사항이 사용자의 기기에 적용되는 데 시간이 오래 걸리며(때로는 몇 주) 피드백 루프가 가장 길고 비용이 많이 듭니다.

확장 가능한 테스트 전략

테스트 피라미드는 전통적으로 다음 3가지 카테고리로 나뉩니다.

• 단위 테스트
• 통합 테스트
• 엔드 투 엔드 테스트

하지만 이러한 개념에는 정확한 정의가 없으므로 팀에서 5개 레이어를 사용하는 등 카테고리를 다르게 정의할 수 있습니다.

• 단위 테스트는 호스트 머신에서 실행되며 Android 프레임워크에 종속되지 않는 단일 기능 단위 로직을 확인합니다.
  • 예: 수학 함수의 1씩 차이 오류 확인
• 구성요소 테스트는 시스템의 다른 구성요소와 독립적으로 모듈이나 구성요소의 기능 또는 외관을 확인합니다. 단위 테스트와 달리 구성요소 테스트의 표면적은 개별 메서드와 클래스 위의 더 높은 추상화로 확장됩니다.
  • 예: 맞춤 버튼의 스크린샷 테스트
• 기능 테스트는 두 개 이상의 독립적인 구성요소 또는 모듈의 상호작용을 확인합니다. 기능 테스트는 더 크고 복잡하며 일반적으로 기능 수준에서 작동합니다.
  • 예: 화면의 상태 관리를 확인하는 UI 동작 테스트
• 애플리케이션 테스트는 배포 가능한 바이너리 형태로 전체 애플리케이션의 기능을 확인합니다. 테스트 중인 시스템으로 테스트 후크를 포함할 수 있는 개발자 빌드와 같은 디버깅 가능한 바이너리를 사용하는 대규모 통합 테스트입니다.
  • 예: 폴더블의 구성 변경사항을 확인하는 UI 동작 테스트, 현지화 및 접근성 테스트
• 출시 후보 테스트는 출시 빌드의 기능을 확인합니다. 애플리케이션 바이너리가 축소되고 최적화된다는 점을 제외하면 애플리케이션 테스트와 유사합니다. 이는 앱을 공개 사용자 계정이나 공개 백엔드에 노출하지 않고 프로덕션에 최대한 가까운 환경에서 실행되는 대규모 엔드 투 엔드 통합 테스트입니다.
  • 예: 중요한 사용자 여정, 성능 테스트

이 분류에서는 충실도, 시간, 범위, 격리 수준을 고려합니다. 여러 레이어에 다양한 유형의 테스트가 있을 수 있습니다. 예를 들어 애플리케이션 테스트 레이어에는 동작, 스크린샷, 성능 테스트가 포함될 수 있습니다.

테스트 카테고리 결정

일반적으로 팀에 적절한 수준의 피드백을 제공할 수 있는 피라미드의 가장 낮은 레이어를 고려해야 합니다.

예를 들어 로그인 흐름의 UI와 같은 이 기능의 구현을 테스트하는 방법을 생각해 보세요. 테스트해야 하는 항목에 따라 다른 카테고리를 선택합니다.

경우에 따라 특정 항목이 어느 카테고리에 속하는지는 주관적일 수 있습니다. 인프라 비용, 불안정성, 긴 테스트 시간과 같은 추가적인 이유로 테스트가 위 또는 아래로 이동할 수 있습니다.

테스트 카테고리는 테스트 유형을 지정하지 않으며 모든 기능을 모든 카테고리에서 테스트해야 하는 것은 아닙니다.

수동 테스트도 테스트 전략에 포함될 수 있습니다. 일반적으로 QA팀은 출시 후보 테스트를 수행하지만 다른 단계에도 참여할 수 있습니다. 예를 들어 스크립트 없이 기능의 버그를 탐색적으로 테스트합니다.

테스트 인프라

테스트 전략은 개발자가 지속적으로 테스트를 실행하고 모든 테스트가 통과되도록 보장하는 규칙을 적용할 수 있도록 인프라와 도구로 지원되어야 합니다.

범위별로 테스트를 분류하여 언제 어디에서 어떤 테스트를 실행할지 정의할 수 있습니다. 예를 들어 5계층 모델을 따르는 경우

• 단위 및 구성요소 테스트는 모든 새 커밋에 대해 지속적 통합 시스템에서 실행되지만 영향을 받는 모듈에 대해서만 실행됩니다.
• 모든 단위, 구성요소 및 기능 테스트는 변경사항을 병합하거나 제출하기 전에 실행됩니다.
• 애플리케이션 테스트는 병합 후에 실행됩니다.
• 출시 후보 테스트는 휴대전화, 폴더블, 태블릿에서 매일 밤 실행됩니다.
• 출시 전에 출시 후보 테스트가 많은 기기에서 실행됩니다.

테스트 수가 생산성에 영향을 미치는 경우 이러한 규칙은 시간이 지남에 따라 변경될 수 있습니다. 예를 들어 테스트를 야간 주기로 이동하면 CI 빌드 및 테스트 시간이 줄어들 수 있지만 피드백 루프가 길어질 수도 있습니다.