소프트웨어 테스트의 분류

• 테스트 단계에 따른 분류
  
  • 단위 테스트
    • 개별적으로 테스트할 수 있는 소프트웨어 기능만을 따로 분리하여 기능을 검증
    • 일반적으로 코드 접근을 허용하고, 디버깅 도구의 지원 하에 실행하며, 코드를 직접 작성한 개발자가 수행
    • 모듈은 독립된 프로그램이 아니기 때문에 테스트 드라이버(Driver) 또는 스터브(Stub)가 필요
      • Driver : 테스트를 위한 제어 프로그램으로, 가상의 주 프로그램 기능
      • Stub : 테스트를 위한 종속 프로그램으로, 가상의 부 프로그램 기능
    • 단위 테스트의 유형
      • 인터페이스 테스트
        다른 모듈과의 데이터 인터페이스에 대한 테스트
      • 자료구조 테스트
        모듈 내의 자료 구조상 오류가 없는가를 테스트
      • 수행 경로 테스트
        구조 및 루프 테스트 등에 의한 논리 결로 테스트
      • 오류 처리 테스트
        각종 오류들이 모듈에 의해 적절하게 처리되는가를 테스트
      • 경계 테스트
        오류가 발생하기 쉬운 경계 값들을 테스트 케이스를 만들어 테스트
  • 통합 테스트
    • 소프트웨어 컴포넌트 간의 상호 작용을 검증하는 프로세스
    • 소프트웨어 엔지니어가 하위 수준 관점을 배제하고 통합하고 있는 레벨의 관점, 즉 컴포넌트 간, 서브시스템 간의 통합에 집중해야 하는 활동
    • 통합 테스트의 유형
      • 하향식(Top-down) 통합 테스트
        • 주요 제어 모듈은 테스트 드라이버로 사용되고, 스터브는 주요 제어 모듈에서 직접 종속되는 모든 모듈로 교체
        • 깊이 우선이나 넓이 우선의 선택적 통합 접근법을 정하고, 하위 스터브는 실제 컴포넌트들로 한 번에 하나씩 대체
        • 테스트들은 각 컴포넌트가 통합됨으로써 수행
        • 각 테스트가 완성되면 다른 스터브들이 실제 컴포넌트들로 대체
      • 상향식(Bottom-up) 통합 테스트
        • 하위 수준의 컴포넌트들은 특별한 소프트웨어 보조 기능을 수행하는 클러스터(혹은 build)로 결합
        • 입.출력 테스트 케이스를 통합하기 위해 드라이버가 사용
        • 클러스터가 테스트 됨
        • 드라이버는 지워지고 클러스터들은 프로그램 구조의 상위로 이동하여 결합됨
      • 혼합식(Snadwich) 통합 테스트
        • 하향식 통합 전략과 상향식 통합 전략을 절충한 방식
        • 우선적으로 통합을 시도할 중요 모듈들을 선정한 후 그 모듈을 중심으로 통합
      • 비점진적 테스트(Big Bang)
        • 모든 모듈을 한꺼번에 통합하여 테스트
        • 단위 테스트에 많은 시간이 필요
        • 시스템의 중요 부분과 부수적인 부분을 구별하지 않음
        • 일정 계획에 융통성이 없음
        • 오류가 있는 경우 어떤 모듈이 변경되어야 하는지 파악하기 어려움
  • 시스템 테스트
    • 전체 시스템의 수행 결과를 테스트
    • 시스템 테스트 시 주요 테스트 대상
      • 시스템의 비기능적 요구 사항 : 시스템의 안전성, 속도, 정확도, 신뢰도 등
      • 외부 인터페이스 : 다른 응용 프로그램, 하드웨어, 운영 환경에 대한 외부 인터페이스
           
  ※ 단위 테스트 시에는 개발자가 자기 프로그램을 테스트할 수 있으나, 통합 테스트와 시스템 테스트 시에는 개발자가 직접 테스트하지 않는다.
•    
•    
• 테스트 목적에 따른 분류
  • 인수(Acceptance) / 인증(Qualification) 테스트
    • 시스템이 자신들의 요구 사항을 만족시키는지에 대해 고객들이 시스템 수행 결과를 검사
    • 시스템 개발자도 인수/인증 테스트 활동에 포함 가능
  • 설치(Installation) 테스트
    • 소프트웨어 인수 테스트를 끝낸 후 목표 환경에 설치하여 소프트웨어를 검증
    • 하드웨어 구성 요구 사항에 따라 다시 수행되는 시스템 테스트로 볼 수 있으며, 설치 결과 및 설치 과정도 검증 가능함.
  • 알파 테스트와 베타 테스트
    • 소프트웨어를 출시하기 전에 소규모로 대표되는 잠재적 사용자들에게 사내(알파 테스트) 또는 외부(베타 테스트)에서 시범 사용하여 제품의 문제점을 파악
    • 알파 테스트와 베타 테스트의 비교

구분	알파 테스트	베타 테스트
테스트 주체	사용자	사용자
테스트 환경	개발 Site에서 테스트 관리 가능한 환경	사용자 Site에서 테스트 관리 불가능한 환경
개발자 참여	부분적 참여	불참

• 적합성(Conformance) 테스트 / 기능 테스트/ 정확도(Correctness) 테스트
  • 테스트하는 소프트웨어에 대해 관찰된 결과가 명세를 따르고 있는지의 여부 확인
• 회귀(Regression) 테스트
  • 이미 테스트를 통과한 소프트웨어가 특정 수정 후에도 여전히 테스트를 통과한다는 것을 검증
• 성능(Performance) 테스트
  • 소프트웨어가 지정된 성능적 요구 사항과 응답 시간을 만족했는지 확인
• 스트레스(Stress) 테스트
  • 최대 설계 또는 그 이상의 부하로 소프트웨어를 테스트 하는 것
• 복구(Recovery) 테스트
  • 자체 결함, 하드웨어 고장, 데이터의 오류 등이 발생한 후 소프트웨어가 새로이 시작할 수 있는지를 검증
  • 복구가 자동적으로 실행되면 재초기화, Check Point 절차, 데이터 복구, 재착수의 정확성을 평가하는 것이 가능
• 사용 용이성(Usability) 테스트
  • 최종 사용자가 사용자 매뉴얼을 포함해 얼마나 쉽게 소프트웨어를 배우고 사용할 수 있는지를 검증
  • 소프트웨어가 사용자 업무를 지원할 때 얼마나 효과적인가를 검증
  • 사용자 오류로부터 복원하는 능력이 있는지 등을 평가
• 백 투 백(Back-to-Back) 테스트
  • 소프트웨어 제품의 두 가지 구현 버전을 놓고 일회성 테스트 집합을 시행한 후 그 결과들을 비교하여 오류를 도출
• 형상(Configuration) 테스트
  • 소프트웨어가 제각기 다른 사용자 환경을 위해 만들어진 경우, 형상 테스트는 지정된 다양한 형상에 대하여 소프트웨어를 분석하기 위해 실시
       

※ 성능테스트와 스트레스 테스트는 시스템의 비기능적 요구 사항에서 명시된 사항에 대해 검증하는 활동