ISTQB 2.2 테스트 레벨

2-2. 테스트 레벨

1. 테스트 레벨의 일반적인 개념

  • 테스트 레벨의 일반적인 구분
    • 단위(Component or Unit)
    • 통합(Integration)
    • 시스템(System)
    • 인수(Acceptance)
  • 테스트 레벨에 따라 독립적으로 정의할 수 있는 사항
    • 테스트 레벨의 일반적인 목표(목적)
    • 테스트 케이스를 도출해 내는데 참조되는 개발 산출물(베이시스)
    • 테스트 대상(테스트할 그 무엇)
    • 발견된 전형적인 결함과 장애
    • 테스트 하네스(드라이버/스텁) 필요 여부와 툴 지원의 필요성
    • 상세한 테스트 접근법
    • 테스트 수행 주체 또는 조직

2. 단위 테스트(Unit Test)

  • 테스트가 가능한 최소 단위로 나누어진 소프트웨어 모듈, 프로그 램, 객체, 클래스 등에서 결함을 찾고 그 기능을 검증→ 개발자
    • 소프트웨어 각각의 단위를 다른 부분과 연계성을 고려하지 않고 격리해 서 독립적으로 테스트 수행
    • 스텁, 드라이버, 시뮬레이터 사용
  • 일반적으로 프로그램 소스 코드를 대상 → 구조기반(화이트 박스)
  • 컴포넌트 테스트의 일반적인 목적
    • 기본 경로 확인
    • 모든 오류 처리 경로 확인
    • 컴포넌트 내의 인터페이스 확인
    • 로컬 데이터 확인, 경계값 확인
  • 테스트 유형: 구조적 테스팅, 기능 테스팅, 비기능 테스팅
  • 주요 테스팅 접근법
    • 테스트 우선 접근법(Test-First-Approach): 코딩 전에 테스트 케이스를 준비하고 자동화
    • 테스트 주도 개발(Test-Driven-Development)

3. 통합 테스팅(Integration Testing)

  • 컴포넌트간에 인터페이스를 테스트하는 것은 물론 OS, 파일 시 스템, 하드웨어 또는 시스템간 인터페이스와 같은 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트
  • 컴포넌트 통합 테스트
  • 시스템 통합 테스트
  • 통합 테스팅은 기능적 특성은 물론 비기능적 특성(성능, 연결성 등)을 테스팅 수행
  • 통합 테스팅 설계는 기능적 접근법, 구조적 접근법을 모두 사용
    • 통합테스팅 그 자체에만 집중하는 오류 주의
구분 Big Bang(빅뱅) Bottum up(상향식) Top down(하향식) Backbone(백본)
실행방법 모든 모듈을 동시에 통합하여 테스트 가장 하부의 모듈부터 통합 가장 상부의 모듈부터 통합 가장 중요하고 리스크가 높은 모듈로 초기 백본 형성
드라이버 / 스텁 드라이버 / 스텁 없이 실제 모듈로 테스트 테스트 드라이버가 필요하며 점차 개발되고 테스트된 상부 모듈로 대치 테스트 스텁이 필요하며 점차 개발되고 테스트된 하부 모듈로 대치 필요시 드라이버 / 스텁 사용, 리스크가 높은 순으로 개발 / 테스트하며 드라이버 / 스텁을 대치
장점 단시간 테스트 결함 격리 쉬움, 하위 모듈을 충분히 테스트 결함 격리 쉬움, 설계상의 결함을 빨리 발견 결함 격리 쉬움 높은 리스크 순으로 통합 결함 발견
단점 결함 격리 어려움 큰 문제(설계상 결함)를 상부에서 발견할 가능성 있음, 비즈니스 로직 반영 어려움 수정이 어려운 큰 문제를 하부에서 발견할 가능성 있음(ex: 디자인 결함을 가진 DB) 테스트 시간이 오래 걸릴 수 있음

4. 시스템 테스팅(System Testing)

  • 개발 프로젝트 차원에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트 → 리스크 최소화를 위해 실제 환경과 유사한 상태
  • 시스템 관련 고객의 요구사항이 완벽하게 실행되는지를 테스트
  • 테스트 베이시스(개발 산출물) 이용
    • 리스크 분석서, 요구사항 명세, 비즈니스 프로세스, 유즈 케이스, 기타 비 즈니스 레벨의 시스템 동작 명세, OS 및 시스템 리소스와 상호작용 명세
  • 기능 및 비기능 요구사항 모두 검증
    • 기능적 테스트 : 명세기반(블랙박스) 기법으로 수행 – 문서 기반
    • 비기능적 테스트 : 기능적 외의 나머지 부분에 대한 요구사항 검증
  • 일반적으로 독립적인 테스트 팀이 수행 → 검수 테스팅(출시)

5. 인수 테스팅(Acceptance Testing)

  • 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 확신을 얻는 것 → 결함 발견이 목적이 아님
  • 품질에 대한 확신
  • 시스템을 배포하거나 실제 사용할 준비가 되었는지 평가
  • 인수 테스팅 이후에 대규모 시스템 간의 통합 테스트 수행
    • 인수 테스팅이 반드시 최종 단계의 테스팅은 아님
  • 인수 테스팅은 프로젝트 전(全) 개발 과정에서 수행
    • 상용(COTS) SW 제품은 설치, 통합 하면서 테스팅
    • 컴포넌트의 사용성에 대해서는 컴포넌트 테스팅 동안 실행 가능
    • 새로운 기능 개선에 대해서는 시스템 테스팅 전에 실행 가능
  • 인수 테스팅 형태
    • 사용자 인수 테스팅(비즈니스 사용자가 확인)
    • 운영상의 테스팅
      • 백업/복원, 재난 복구, 사용자 관리, 유지보수 작업, 보안 취약성 점검
    • 계약 인수 테스팅과 규정 인수 테스팅
      • 맞춤식-개발 SW가 계약상의 인수 통과 조건/규정을 준수하는지 확인
    • 알파 테스팅과 베타(필드) 테스팅 → 고객의 피드백
      • 알파 테스트 : 개발 조직 내에서 고객에 의해 수행
        • 고객 사이트로 이동하기 전에 개발 완료 후 테스팅인 공장 인수 테스팅을 의미
      • 베타 테스트 : 실제 환경에서 사용자 혹은 잠재 고객에 의해 수행
        • 고객 사이트로 이동한 후에 테스팅하는 사이트 인수 테스팅을 의미