제 2장 소프트웨어 생명주기와 테스팅 (2)

2.2 테스트 레벨(Test levels)

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

• 
  테스트 레벨의 일반적인 구분
  • 단위(component or Unit)
    • 테스트가 가능한 최소 단위로 나누어진 소프트웨어 모듈, 프로그램, 객체, 클래스 등에서 결함을 찾고 그 기능을 검증 -> 개발자
      • 소프트웨어 각각의 단위를 다른 부분과 연계성을 고려하지 않고 격리해서 독립적으로 테스트 수행
      • 스텁, 드라이버, 시뮬레이터 사용
    • 일반적으로 프로그램 소스 코드를 대상 -> 구조기반(화이트 박스)
    • 컴포넌트 테스트의 일반적인 목적
      • 기본 경로 확인
      • 모든 오류 처리 경로 확인
      • 컴포넌트 내의 인터페이스 확인
      • 로컬 데이터 확인, 경계값 확인

• 통합(Integration)
  • 컴포넌트간에 인터페이스를 테스트하는 것은 물론 OS, 파일 시스템, 하드웨어 또는 시스템간 인터페이스와 같은 시스템의 각기다른 부분과 상호 연동하는 동작을 테스트
  • 컴포넌트 통합 테스트
  • 시스템 통합 테스트
  • 통합 테스팅은 기능적 특성은 물론 비기능적 특성(성능, 연결성등)을 테스팅 수행
  • 통합 테스팅 설계는 기능적 접근법, 구조적 접근법을 모두 사용
    • 통합 그 자체에만 집중하는 오류 주의!

• 시스템(System)
  • 개발 프로젝트 차원에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트 -> 리스크 최소화를 위해 실제 환경과 유사한 상태
  • 시스템 관려 고객의 요구사항이 완벽하게 실행되는지를 테스트
  • 테스트 베이시스(개발 산출물) 이용
    • 리스크 분석서, 요구사항 명세, 비즈니스 프로세스, 유즈 케이스, 기타 비즈니스 레벨의 시스템 동작 명세, OS 및 시스템 리소스와 상호작용 명세
  • 기능 및 비기능 요구사항 모두 검증
    • 기능적 테스트: 명세기반(블랙박스) 기법으로 수행 - 문서 기반
    • 비기능적 테스트: 기능적 외의 나머지 부분에 대한 요구사항 검증
  • 일반적으로 독립적인 테스트 팀이 수행 -> 검수 테스팅(출시)
• 인수(Acceptance)
  • 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 확신을 얻는 것 -> 결함 발견이 목적이 아님
  • 품질에 대한 확신
  • 시스템을 배포하거나 실제 사용할 준비가 되었는지 평가
  • 인수 테스팅 이후에 대규모 시스템 간의 통합 테스트 수행
    • 인수 테스팅이 반드시 최종 단계의 테스팅은 아님
  • 인수 테스팅은 프로젝트 전체 개발 과정에서 수행
    • 사용 SW 제품은 설치, 통합 하면서 테스팅
    • 컴포넌트의 사용성에 대해서는 컴포넌트 테스팅 동안 실행 가능
    • 새로운 기능 개선에 대해서는 시스템 테스팅 전에 실행 가능
  • 인수 테스팅 형태
    • 사용자 인수 테스팅(비즈니스 사용자가 확인)
    • 운영사의 테스팅: 백업/복원, 재난 복구, 사용자 관리, 유지보수 작업, 보안 취약성 점검
    • 계약 인수 테스팅과 규정 인수 테스팅: 맞춤식-개발 SW가 계약상의 인수 통과 조건/규정을 준수하는지 확인
    • 알파 테스팅과 베타(필드) 테스팅 -> 고객의 피드백
      • 알파 테스트: 개발 조직 내에서 고객에 의해 수행
        • 고객 사이트로 이동하기 전에 개발 완료 후 테스팅인 공장 인수 테스팅을 의미
      • 베타 테스트: 실제 환경에서 사용자 혹은 잠재 고객에 의해 수행
        • 고객 사이트로 이동한 후에 테스팅하는 사이트 인수 테스팅을 의미