테스트 레벨

소프트웨어 테스트 레벨 상세 설명

소프트웨어 테스트 레벨은 소프트웨어 개발 생명주기(SDLC)의 특정 단계에서 수행되는 테스트 활동의 그룹이며, 테스트 대상(Object of Testing)의 범위에 따라 구분됩니다. 각 레벨은 고유한 목적을 가집니다.

1. 컴포넌트 테스트 (Component Testing) - 단위 테스트 (Unit Testing)라고도 불림

• 대상: 개별적인 프로그래밍 단위인 모듈, 컴포넌트, 클래스 또는 함수와 같이 가장 작은 소프트웨어 구성 요소. 일반적으로 독립적으로 테스트 가능하며, 더 이상 작은 논리적인 단위로 분해하기 어려운 대상을 의미합니다.
• 수행 주체: 주로 해당 코드를 개발한 개발자. 독립적인 테스터가 수행하기도 합니다.
• 목적: 각 컴포넌트가 내부 설계 및 동작 요구사항에 따라 올바르게 구현되었는지, 기능이 정상적으로 작동하는지 검증하는 것입니다. 주로 코드의 구조(White-box)를 기반으로 테스트 케이스를 설계하기도 합니다.
• 특징:
  • 자동화 비율이 가장 높습니다.
  • 다른 컴포넌트나 외부 시스템과의 의존성을 배제하고 독립적으로 수행됩니다.
  • Stubs (호출되는 컴포넌트 대역)이나 Drivers (호출하는 컴포넌트 대역)와 같은 테스트 하니스(Test Harness)를 사용하여 테스트 환경을 격리합니다.
  • 가장 빠른 피드백을 받을 수 있는 테스트 레벨입니다.
• 다른 레벨과의 관계: 가장 낮은 레벨의 테스트로, 통합 테스트의 기초가 됩니다. 여기서 발견된 결함은 다른 레벨에서 발견되는 것보다 수정 비용이 가장 적게 듭니다.

2. 통합 테스트 (Integration Testing)

• 대상: 개별적으로 테스트된 컴포넌트들이 결합된 그룹, 서브시스템, 또는 컴포넌트 간의 인터페이스.
• 수행 주체: 개발자 또는 독립적인 테스터 팀.
• 목적: 컴포넌트들이 서로 정확하게 상호작용하고 데이터를 주고받는지, 인터페이스 간의 오류는 없는지 검증하는 것입니다. 각 컴포넌트 자체의 기능보다는 컴포넌트 간의 연동에 초점을 맞춥니다.
• 통합 전략: 컴포넌트들을 통합하는 순서에 따라 다양한 전략이 사용될 수 있습니다.
  • 빅뱅 통합 (Big-Bang Integration): 모든 컴포넌트를 한 번에 통합하여 테스트. 결함 발견 시 원인 파악이 어렵다는 단점이 있습니다.
  • 상향식 통합 (Bottom-Up Integration): 가장 낮은 레벨의 컴포넌트부터 통합하여 테스트. 테스트되지 않은 상위 컴포넌트 대역으로 Driver가 필요합니다.
  • 하향식 통합 (Top-Down Integration): 가장 상위 레벨의 컴포넌트부터 통합하여 테스트. 테스트되지 않은 하위 컴포넌트 대역으로 Stub이 필요합니다.
  • 점진적 통합 (Incremental Integration): 컴포넌트들을 소규모 그룹으로 점진적으로 통합하여 테스트. 상향식, 하향식, 또는 기능 기반으로 수행될 수 있으며, 결함 격리가 용이합니다.
• 다른 레벨과의 관계: 컴포넌트 테스트 후에 시스템 테스트 이전에 수행됩니다. 시스템 테스트의 신뢰도를 높이는 역할을 합니다.

3. 시스템 테스트 (System Testing)

• 대상: 기능적으로 완전하게 통합된 시스템 전체. 독립적인 시스템으로서 모든 컴포넌트가 포함된 상태를 테스트합니다.
• 수행 주체: 독립적인 테스터 팀.
• 목적: 시스템이 명세된 모든 기능적 및 비기능적 요구사항을 충족하는지, 엔드-투-엔드(End-to-End) 시나리오에서 예상대로 동작하는지 종합적으로 검증하는 것입니다. 시스템 레벨의 결함을 발견하는 데 집중합니다.
• 특징:
  • 일반적으로 요구사항 명세(Specification)를 기반으로 블랙박스 기법을 사용하여 테스트 케이스를 설계합니다.
  • 기능 테스트 외에 성능, 보안, 사용성, 신뢰성, 호환성 등 다양한 비기능 테스트가 포함됩니다.
  • 실제 운영 환경과 유사한 테스트 환경에서 수행하는 것이 이상적입니다.
• 다른 레벨과의 관계: 통합 테스트 후에 수행되며, 인수 테스트 이전에 최종적으로 시스템의 품질을 확인하는 단계입니다.

4. 인수 테스트 (Acceptance Testing)

• 대상: 개발이 완료된 최종 시스템.
• 수행 주체: 고객, 최종 사용자, 비즈니스 전문가 또는 규제 기관. 독립적인 테스터 팀이 고객을 대신하여 수행하기도 합니다.
• 목적: 시스템이 비즈니스 요구사항과 사용자 기대를 충족하는지, 운영 환경에 배포될 준비가 되었는지 공식적으로 확인하고 소프트웨어 인수를 결정하는 것입니다.
• 유형:
  • 사용자 인수 테스트 (User Acceptance Testing, UAT): 최종 사용자가 실제 시나리오를 수행하며 시스템을 평가.
  • 운영 인수 테스트 (Operational Acceptance Testing, OAT): 시스템 관리자가 백업, 복구, 설치, 성능 모니터링 등 운영 관련 측면을 평가.
  • 계약 및 규제 인수 테스트 (Contractual and Regulatory Acceptance Testing): 계약 조건이나 특정 규제 및 법규 준수 여부를 확인.
  • 알파 테스트 (Alpha Testing): 개발사 내부에서 실제 사용자 환경과 유사하게 수행하는 테스트.
  • 베타 테스트 (Beta Testing): 잠재적 고객 또는 최종 사용자가 개발사 외부에서 시스템을 테스트.
• 다른 레벨과의 관계: 시스템 테스트 후에 수행되는 마지막 테스트 레벨입니다. 이 테스트를 통과해야 소프트웨어가 최종적으로 출시 또는 배포될 수 있습니다.

이러한 테스트 레벨들은 순차적으로 진행되는 경우가 많지만, 특정 개발 모델(예: Agile)에서는 병렬적으로 또는 반복적으로 수행될 수도 있습니다.