테스트 레벨과 테스트 유형

1. 테스트 레벨

테스트 레벨은 테스트 활동을 그룹화하여 함께 조직하고 관리하는 것이다. 각 테스트 레벨은 특정 개발 단계의 소프트웨어에 대해 수행되는 테스트 프로세스의 일부분을 나타낸다. 이는 개별 컴포넌트에서 전체 시스템 또는 시스템 간 통합(system of systems)에 이르기까지 다양하다.

테스트 레벨은 SDLC 내의 다른 활동과 관련이 있다. 순차적 SDLC 모델에서는 각 테스트 레벨의 종료 기준이 다음 레벨의 시작 기준에 포함되는 경우가 많다. 반복적 모델에서는 이 규칙이 적용되지 않을 수 있다. 개발 활동은 여러 테스트 레벨에 걸쳐 수행될 수 있으며, 테스트 레벨이 시간적으로 겹칠 수도 있다.

---

1-1. 테스트 레벨의 유형

본 섹션에서는 다음 다섯 가지 테스트 레벨을 설명한다.

• 컴포넌트 테스트(유닛 테스트): 개별 컴포넌트를 독립적으로 테스트한다. 주로 개발 환경에서 개발자가 수행하며, 테스트 하네스(test harness) 또는 유닛 테스트 프레임워크와 같은 지원 도구가 필요할 수 있다.
• 컴포넌트 통합 테스트(유닛 통합 테스트): 컴포넌트 간의 인터페이스와 상호작용을 테스트한다. 바텀업(bottom-up), 탑다운(top-down), 빅뱅(big-bang)과 같은 통합 전략에 따라 달라질 수 있다.
• 시스템 테스트: 전체 시스템 또는 제품의 전반적인 동작과 기능을 테스트한다. 기능 테스트와 비기능 테스트를 포함하며, 사용성 테스트와 같은 경우 전체 시스템에서 대표적인 테스트 환경을 필요로 할 수 있다.
• 시스템 통합 테스트: 테스트 대상 시스템과 외부 시스템 및 서비스 간의 인터페이스를 테스트한다. 실제 운영 환경과 유사한 테스트 환경이 요구된다.
• 인수 테스트: 시스템이 사용자의 비즈니스 요구를 충족하는지 확인하고 배포 준비 상태를 검증한다. 일반적으로 최종 사용자가 테스트를 수행하며, 사용자 인수 테스트(UAT), 운영 인수 테스트, 계약 및 규제 준수 테스트, 알파 테스트, 베타 테스트 등이 있다.

테스트 레벨은 다음과 같은 속성들로 구분된다.

• 테스트 대상
• 테스트 목표
• 테스트 베이시스
• 결함과 실패
• 접근 방식 및 책임

각 테스트 레벨은 독립적으로 수행되지만, 서로 밀접하게 연계되어 있으며, 각 레벨에서 사용되는 도구와 기법이 다르다. 테스트 레벨의 연계성과 도구 활용을 명확히 이해하는 것이 테스트 효율성을 높이는 데 중요하다.

1. 테스트 레벨 간의 연계성
   • 컴포넌트 테스트에서 시스템 테스트로: 컴포넌트 테스트 단계에서 발견되지 않은 결함은 시스템 테스트에서 드러날 수 있다. 따라서 각 단계에서 발견된 결함 데이터를 공유하고, 이를 통해 테스트 케이스를 개선하는 것이 필요하다.
   • 시스템 통합 테스트와 인수 테스트: 시스템 통합 테스트는 외부 시스템과의 상호작용을 확인하며, 이 결과는 인수 테스트에서 사용자 관점의 테스트 기준으로 사용될 수 있다.
2. 테스트 도구 활용
   • 컴포넌트 테스트: JUnit, NUnit, PyTest와 같은 유닛 테스트 프레임워크를 활용해 컴포넌트 수준에서 테스트를 자동화한다.
   • 시스템 테스트: Selenium, Appium과 같은 도구를 사용해 웹 및 모바일 애플리케이션의 시스템 테스트를 수행한다.
   • 회귀 테스트 자동화: Jenkins, GitLab CI/CD와 같은 도구를 사용해 지속적 통합 파이프라인에 자동화된 회귀 테스트를 포함시킨다.

---

1-2. 테스트 유형

프로젝트에서 다양한 테스트 유형이 사용될 수 있다. 본 교재에서는 다음 네 가지 테스트 유형을 다룬다.

• 기능 테스트: 컴포넌트나 시스템이 수행해야 할 기능("무엇을" 수행하는지)을 평가한다. 기능의 완전성, 정확성, 적합성을 검증하는 데 초점을 맞춘다.
• 비기능 테스트: 시스템의 비기능적 속성("얼마나 잘 작동하는지")을 평가한다. 성능, 호환성, 사용성, 신뢰성, 보안, 유지보수성, 이식성 등의 특성을 검증한다.
  • 예를 들어, 부하 테스트를 통해 시스템이 높은 사용자 트래픽을 처리할 수 있는지 평가하거나, 보안 테스트를 통해 잠재적 취약점을 식별한다.
• 블랙박스 테스트: 외부 명세를 기반으로 테스트 케이스를 도출하며, 시스템이 명세에 따라 동작하는지 확인한다.
• 화이트박스 테스트: 시스템의 내부 구조(코드, 아키텍처 등)에 기반하여 테스트를 설계하며, 구조를 적절히 커버하는지 확인한다.
  • 예: 로그인 페이지에서 잘못된 비밀번호 입력 시 적절한 오류 메시지가 표시되는지 확인.
    화이트박스 테스트는 코드 커버리지를 극대화하고 결함을 더 구체적으로 찾기 위해 내부 구조를 분석한다.
  • 예: 조건 커버리지 테스트를 통해 모든 조건문이 올바르게 실행되는지 확인.

위 네 가지 테스트 유형은 모든 테스트 레벨에서 적용될 수 있으며, 각 레벨에서 중점은 다를 수 있다.

---

1-3. 확인 테스트와 회귀 테스트

컴포넌트나 시스템은 새로운 기능 추가 또는 결함 수정을 위해 변경된다. 이때 테스트에는 확인 테스트와 회귀 테스트가 포함된다.

• 확인 테스트: 결함이 성공적으로 수정되었는지 확인한다.
  • 이전에 결함으로 실패했던 모든 테스트 케이스를 다시 실행한다.
  • 수정된 부분을 테스트하는 새로운 테스트 케이스를 추가한다.
  • 수정된 영역에 초점을 맞춘 테스트 케이스를 신속히 작성하고 실행하여 수정의 성공 여부를 검증한다.
  • 이전 실패 사례를 기반으로 재현 가능한 테스트를 우선 수행한다.
• 회귀 테스트: 변경 사항이 기존 기능에 부정적인 영향을 미치지 않았는지 확인한다.
  • 영향을 받을 가능성이 있는 모든 부분을 테스트한다.
  • 영향을 미치는 소프트웨어 부분을 파악하기 위해 영향 분석을 수행하는 것이 권장된다.
  • 회귀 테스트는 자주 반복되므로 자동화의 주요 대상이다. 자동화된 회귀 테스트는 CI/CD 파이프라인에 포함되어 매 빌드 시 실행되며, 릴리스 주기를 단축시킨다.
  • 자동화를 위해 Selenium, TestNG와 같은 도구를 사용하며, 테스트 커버리지를 모니터링하기 위해 SonarQube와 같은 분석 도구를 병행하여 활용한다.

회귀 테스트는 반복적으로 실행되며, 테스트 케이스의 수는 반복 또는 릴리스마다 증가한다. 따라서 회귀 테스트는 자동화를 위한 강력한 후보이며, 프로젝트 초기 단계에서 시작하는 것이 좋다. CI(지속적 통합)를 사용하는 경우 자동화된 회귀 테스트를 포함하는 것이 좋은 실천 방법이다.