[ISTQB] 2. 소프트웨어 생명주기와 테스팅

2.1 소프트웨어 개발 모델

---

• 테스팅 vs. 소프트웨어 개발
  • 서로 밀접하게 연계
  • 개발 수명 주기에 기반하여 테스팅 접근법을 다르게 적용

2.1.1 V-모델(순차적 개발 모델)

• 개발 산출물 (Work product)
  • 비즈니스 시나리오 또는 유즈케이스, 요구사항 명세, 설계 문서나 코드 → **테스트 베이시스(Basis)**로 사용
• V-모델의 역할
  • 각각의 개발 단계에서 테스팅을 접근하는 방법을 개략적으로 이해하기 쉽게 모델화하여 보여주는 것
  • V-모델을 통해 테스팅 기본 개념 이해
    • 테스트 레벨의 의미
    • 개발 초기 단계에서 테스팅을 수행하다는 것의 의미
    • 결함 예방 차원에서 테스팅이 의미하는 바
    • **V&V(Verification and Validation)**의 의미
• 테스트 레벨의 의미
  • 컴포넌트/단위 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅
    • 테스트 레벨에 따라 테스트 전략, 테스트 기법, 테스트 수행 주체, 테스트 완료 기준 등이 달라짐
    • 테스트 레벨은 독립적
• 개발 초기 단계에서 테스팅을 수행하다는 것의 의미
  • 개발 산출물을 리뷰 형태로 검토하면서 결함을 발견하는 정적 테스팅을 의미
    • 결정 테이블 테스팅, 상태전이 테스팅, 유즈케이스 테스팅 등
  • 개발 초기의 테스팅을 통해서 후반부에서 발생할 비용을 줄임
• 초기에 테스트 설계를 통해 결함을 사전에 예방

---

2.1.2 반복적-검증적 개발 모델

반복적 & 점진적 개발 모델

2.1.3 개발 생명주기 모델에서의 테스팅

• 성공적인 테스팅을 위한 요건
  • 모든 개발 활동은 이에 상응하는 테스트 활동을 동반
  • 각 테스트 레벨은 그 레벨에 맞는 특정한 목적이 있음
  • 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되는 개발 활동 동안에 시작
  • 개발 생명주기 동안에 개발 산출물의 초안이 작성되면, 테스터는 이러한 문서를 리뷰하는 활동에 참가
• 테스팅 레벨 조절
  • 테스팅은 프로젝트나 시스템 아키텍처의 성격에 따라 재조정하거나 합쳐질 수 있음

2.2 테스트 레벨

• 테스트 레벨의 일반적인 구분
  • 단위
  • 통합
  • 시스템
  • 인수

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

2.2.1 컴포넌트 테스팅

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

2.2.2 통합 테스팅

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

2.2.3 시스템 테스팅

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

2.2.4 인수 테스팅

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

---

2.3 테스트 유형

---

• 테스트 유형은 테스트 목적에 따라 구분2.호환성, 신뢰성, 사용성과 같은 비기능적인 품질 특성 테스팅4.변경 내용에 관련된 테스팅(확인 테스팅, 리그레션 테스팅)
• 3.소프트웨어나 시스템의 구조나 아키텍처에 대한 테스팅
• 1.소프트웨어가 수행하는 기능에 대한 테스팅
• 기능적, 구조적 테스팅은 SW 모델 활용
  • 기능적 테스팅 → 명세 기반 기법(블랙 박스)
    • 프로세스 흐름 모델, 상태 전이 모델, 평문 언어 명세 이용
  • 구조적 테스팅 → 구조 기반 기법(화이트 박스)
    • 제어 흐름 모델, 메뉴 구조 모델 이용

2.3.1 기능 테스팅(Functional testing)

• 기능 테스팅
  • 문서화 되어 있거나 테스터가 알고 있는 기능과 특징, 그리고 그것들과 특별한 시스템과의 상호 운용성을 수행하며 모든 테스트 레벨에서 수행 → 시스템이 수행하는 무엇(what)을 의미
    • 명세 기반 기법(블랙 박스 테스팅)을 이용해서 테스트 조건과 테스트 케이스를 도출하고 소프트웨어의 외부적인 행동을 고려
• 보안성 테스팅
  • 악의적인 코드(바이러스 등)와 같은 외부로부터의 위협을 감지해 내는 것과 관련이 있는 기능을 확인
    • 보안 정책 확인, 트랩도어(진입점) 파악, 보안 관련 평가(가용성, 무결성, 기밀성, 부인 방지 등)

2.3.2 비기능 테스팅

• 소프트웨어 제품 특성 테스팅
  • 어떻게(How) 동작하는가를 테스팅
    • 성능 테스팅, 부하 테스팅, 스트레스 테스팅, 사용성 테스팅, 유지보수성 테스팅, 신뢰성 테스팅 그리고 이동성 테스팅 등을 포함한 개념
  • 전문적 지식인과 도구 필요
  • 모든 테스트 레벨에서 수행
  • 다양한 척도 또는 비율로 정량화 가능한 SW 품질 특성 측정
  • 소프트웨어 품질 모델 참조(ISO/IEC 9126)
    • 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성이라는 품질 특성으로 분류

2.3.3 구조적 테스팅(Structural testing)

• 구조적 테스팅
  • 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보장성 또는 충분함을 측정하는 것이 목적인 테스트 유형
  • 커버리지
    • 시스템 또는 SW구조가 **테스트 스위트(test suite)**에 의해 테스트된 정도
    • 테스팅의 충분함을 측정( 100 %로 표시 → 추가 테스트 설계)
  • 모든 테스트 레벨에서 수행 가능
    • 구조적 테스트 기법(화이트 박스 테스트)
    • 시스템 아키텍처에 기반을 두고 수행0
    • 비즈니스 모델이나 메뉴 구조(인수 or 시스템 테스트 레벨)

2.3.4 확인/리그레션 테스팅

• 확인(confirmation/re-testing) 테스팅
  • 결함이 발견되고 수정된 후에 SW는 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트하는 경우
    • 결함을 수정하기 위한 디버깅은 테스팅이 아닌 개발 활동
• 리그레션(regression) 테스팅
  • 이미 테스트된 프로그램의 테스팅을 반복
  • 결함 수정 이후 변경의 결과로 새롭게 만들어지거나 이전 결함으로 인해 발견되지 않았던 다른 결함을 발견
  • SW 또는 환경이 변경되면 실시
  • 모든 테스트 레벨에서 수행
  • 리그레션 테스팅 → 반복적인 성향 → 자동화 대상

---

2.4 유지보수 테스팅

---

• 유지보수 테스팅
  • 이미 운영되고 있는 시스템에서 수행되며, SW나 시스템이 변경, 단종되었거나 마이그레이션될 때 발생
  • 변경에 대한 유지보수 테스팅
    • 계획된 개선을 위한 변경, 수정에 의한 변경과 환경의 변경
    • 계획된 OS, DB 업그레이드, OS의 새로 드러난 취약점 패치
  • 마이그레이션에 대한 유지보수 테스팅
    • 변경된 SW에 대한 운영 테스트 + 새로운 환경에서의 운영 테스트
  • 변경된 것 + 변경되지 않은 시스템 요소(영향도 분석 후)에 대한 방대한 리그레션 테스팅 고려
  • 범위는 변경 범위 및 기존 시스템의 리스크와 크기 고려