2-2. 테스트 레벨

테스트 레벨

- 한번에 총체적으로 조직화하고 관리 하는(관리하기 위한) 테스트 활동의 묶음

- 개발 단계와 대응하는 컴포넌트(단위) 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅을 의미

- 각각의 테스트 레벨은 서로 독립적, 각각 다른 테스트 계획과 전략을 필요로 함

1. 테스트 레벨에 따라 독립적으로 정의할 수 있는 사항(식별 가능한 내용)

1) 테스트 레벨의 일반적인 목표(목적)

2) 테스트 케이스를 도출해 내는데 참조되는 개발 중간 산출물(테스트 베이시스)

3) 테스트 대상(테스트할 그 무엇)

4) 발견된 전형적인 결함과 장애

5) 테스트 하네스(드라이버 / 스텁) 필요여부와 툴 지원의 필요성

6) 상세한 테스트 접근법

7) 담당책임: 테스트 수행 주체 또는 조직

2. 테스팅 레벨의 각 테스팅 수행 주체

1) 개발 주체가 테스팅: 컴포넌트 테스팅, 통합 테스팅

2) 독립적인 테스트 팀이 테스팅: 시스템 테스팅, 검수 테스팅

3) 시스템을 사용하는 고객, 사용자 또는 다른 이해관계자가 테스팅: 인수 테스팅

컴포넌트 테스팅(Component Testing) = 유닛 테스팅(Unit Testing)

- 테스트가 가능한 (최소)단위로 나누어진 소프트웨어(모듈, 프로그램, 객체, 클래스 등) 내에서 결함을 찾고 그 기능을 검증

- 개발 수명주기의 정황과 시스템에 의존적이면서도 시스템 다른 부분에서 격리하여 독립적으로 수행해야 함

- 테스트 케이스는 개발 산출물에서 도출

- 프로그램 소스코드(원시코드)를 시험 대상으로 하며 주된 테스트 방법은 구조기반(화이트 박스) 테스팅임

- 해당 개발자에 의해서도 수행될 수 있고 타 개발자나 제 3자에 의해서도 실시됨

1. 컴포넌트 테스팅의 목적

1) 기본 경로(path) 확인

2) 모든 오류 처리 경로(Error handling path)를 확인

3) 컴포넌트 내의 인터페이스 확인

4) 로컬 데이터 확인, 경계값 확인

2. 컴포넌트 테스트 기법

- 컴포넌트 테스트에 활용할 수 있으면 컴포넌트 테스트 기법임

1) 구조 기반 기법

- 제어흐름(Contorl Flow) 테스팅

- 조건/결정(Condition decision(branch)) 커버리지 테스팅

- 최소비교(Elementary comparison test) 테스팅

2) 명세 기반 기법

- 등가 분할 & 경계 값 테스팅

3. 컴포넌트 테스트 완료 조건

1) AI(Applicaiton Integrator)가 통합 테스트로의 Entry Citeria를 만족 시켰다고 판단하는 경우

- 품질 수준을 개발 프로젝트 리더, 팀 리더와 결정

- 기 결정한 테스트 커버리지 달성

- 특정 테스트 기법 사용 확인

- 단위 테스트 케이스와 수행 결과를 검토하고 워크스루 하는 것을 통해 결정

2) QA Entrance 조건을 만족 시킴

- 통합 테스트와 단위 테스트를 구분하지 않는 경우

3) 개발 관리자가 완료로 결정

통합 테스팅(Integration Testing)

- 컴포넌트간의 인터페이스를 테스트 하는 것은 물론 OS, 파일 시스템, 하드웨어 또는 시스템 간 인터페이스와 같은 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트

- 시스템이나 시스템 구성요소 또는 소프트웨어 프로그램의 데이터 및 기능의 인터페이스가 정상적으로 작동 하는지에 중점을 두고 수행하는 테스트

- 단위 테스트를 통과한 개발 소프트웨어/하드웨어 컴포넌트(모듈)간 인터페이스 및 연동 기능 등을 구조적으로 접근하여 테스트 하는 방법

- 기능적 특성은 믄 물론 비기능적 특성(성능, 연결성 등)을 테스팅 해야 함

- 통합 테스팅의 설계는 기능적 접근법, 구조적 접근법을 모두 사용하여 통합 그 자체에만 집중하는 오류를 범하지 않아야 함

- 개발자가 효과적으로 테스트 할 수 있는 방법, 이상적으로는 테스터가 아키텍쳐에 대한 이해를 바탕으로 통합 테스트 계획에 관여해야 함

1. 통합 테스트 종류

- 통합하는 범위가 클수록 장애나 결함의 위치를 찾아 격리하기 어려움, 개발의 리스크를 증가 시킴

- 상향시, 하향식, 백본 통학과 같은 순차적이고 체계적인 통합 전략이 한번에 통합하는 빅뱅 통합 전략보다 리스크를 줄이는데 효과적

1) 빅뱅(Big-bang) 통합

2) 상향식(Bottom up) 통합

3) 하향식(Top down) 통합

4) 백본(Backbone) 통합

5) 중심(Central) 통합

6) 협업(Collaboration) 통합

7) 계층(Layer) 통합

2. 통합 접근법의 특징 및 장단점

	백본(Backbone)	빅뱅(Big-bang)	상향식(Bottom up)	하향식(Top down)
수행방법	가장 중요하고 위험도가 높은 모듈로 초기 백본(통합) 형성	모든 테스트 모듈을 동시에 통합	가장 하부의 모듈 부터 통합해 가면서 진행	가장 상부의 모듈부터 통합해 가면서 진행
드라이버 /스텁	드라이버/스텁을 필요에 따라 만들어 사용, 위험도 높은 순으로 개발하고 테스트하여 드라이버 스텁을 대치	드라이버/스텁 없이 실제 모듈로 테스트	테스트 드라이버(상위)가 필요하며 점차 개발되고 테스트된 상부 모듈로 대치	테스트 스텁(하위)이 필요하며 점차 개발되고 테스트된 하부 모듈로 대치
장점	결함 격리가 쉬움 리스크가 높은 결함을 초기에 발견	단시간 테스트	결함 격리 쉬움 하위 모듈을 충분히 테스트할 수 있음	결함 격리 쉬움 설계상의 결함을 빨리 발견
단점	테스트 시간이 오래 걸릴 수 있음	결함 격리 어려움	큰 문제(설계상의 결함)를 상부에서 발견 가능, 비지니스 로직 반영이 어려움	수정이 어려운 큰 문제를 하부에서 발견 가능 예) 디자인 결함을 가진 DB

- 빅뱅 통합은 시스템 대부분이 안정화 되어 있고 몇몇 새로운 모듈만 추가되는 경우, 시스템이 작은 경우, 모듈이 매우 강하게 연결되어 있어 단계별로 통합이 어려운 경우만 성공적으로 적용 가능

• 스텁

- 골격만 있는 또는 특별한 목적의 소프트웨어 컴포넌트를 구현한것

- 스텁을 호출하거나 또는 스텁에 의존적인 컴포넌트를 개발하거나 테스트할 때 사용함

- 스텁은 호출된 컴포넌트를 대체함

• 드라이버

- 컴포넌트나 시스템을 제어하거나 호출하는 (실제) 상위 컴포넌트를 대체하는 테스트용의 소프트웨어 컴포넌트 또는 툴 

시스템 테스팅(System Testing)

- 개발 프로젝트 차원(범위)에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트 하는 것

- 실 사용 환경과 동일한 모의 시스템을 구성, 테스트 수행

(환경 특성 장애(Environment Specific Failure)를 일으킬 리스크를 최소화)

- 단위/통합 시험이 완료되어 기능상 문제가 없는 상태여야 함

1. 시스템 테스팅의 수행 근간: 상위 레벨의 테스트 베이시스(개발 산출물)

- 리스크 분석서

- 요구사항 명세

- 비지니스 프로세스

- 유즈 케이스

- 기타 비지니스 레벨의 시스템 동작 명세

- OS 및 시스템 리소스와의 상호 작용을 명세

2. 기능적 요구사항의 시스템 테스팅, 비기능적 요구사항 시스템 테스팅

- 시스템 테스팅은 기능 및 비기능 요구사항을 모두 검증

1) 기능적 요구사항의 시스템 테스팅

- 명세기반(블랙박스) 기법으로 수행

- 테스트 대상의 특성을 상세하게 명세한 문서를 기반으로 테스트 설계

2) 비기능적 요구사항의 시스템 테스팅

- 구조기반 기법: 메뉴 구조 또는 웹 페이지 네비게이션 등의 구조적 요소에 대한 테스팅 커버리지

- 소프트웨어의 기능적 품질 특성 외의 나머지 부분에 대한 요구사항 검증을 수행해야 함

(예: 성능테스트, 가용성 테스트, 보안성 테스트)

3. 시스템 테스팅의 수행 주체

- 독립적인 테스트 팀이 수행하는 경우가 대부분

- 개발조직과 테스트 조직이 원활히 정보를 공유하고 협력하여야 함

인수 테스팅(Acceptance Testing)

- 시스템을 사용하는 고객, 사용자가 전담하여 테스팅을 수행하는 경우가 대부분, 다른 이해관계자의 참여도 가능

1. 인수 테스팅의 목적

1) 시스템이나 시스템 일부 또는 특정 비기능적인 특성에 대한 확신을 얻는 것

- 결함을 찾는 것은 인수 테스팅의 주된 관심사가 아님

2) 배포 또는 실제 사용할 준비가 되었는지를 평가

- 최종 단계의 테스팅은 아님

- 인수 테스팅 이후 대규모 시스템 통합 테스트가 수행 될 수도 있음

2. 인수 테스팅과 테스트 레벨

- 인수 테스팅은 프로젝트 전 개발 과정에서 수행 가능

1) 상용 소프트웨어 제품은 설치되거나 통합되면 인수 테스팅 수행 가능

2) 컴포넌트의 사용성에 대한 인수 테스팅은 컴포넌트 테스팅 동안에 수행 가능

3) 프로그램의 유지보수성에 대한 인수 테스팅은 컴포넌트 테스트 실행 전에 수행 가능

4) 새로운 기능상의 개선에 대한 인수테스팅은 시스템 테스팅 전에 수행 가능 

3. 인수 테스팅의 형태

1) 사용자 인수 테스팅

- 비지니스 사용자가 시스템 사용의 적절성을 확인

- 계약상의 요구사항이 만족되었는지 확인하기 위해, 설치 후 실시 되는 시스템 또는 기능 단위의 공식 테스트, 결과를 기초로 고객(구입자)이 개발된 시스템을 인수할 것인지를 결정

2) 운영상의 인수 테스팅

- 시스템 관리자에 의한 테스트 활동

a. 테스트 항목

- 백업/복원 테스팅

- 재난 복구

- 사용자 관리

- 유지보수 작업

- 보안 취약성에 대한 정기적인 점검

3) 계약 인수 테스팅, 규정 인수 테스팅

a. 계약 인수 테스팅

- 맞춤식-개발(Custom-developed) 소프트웨어가 계약상의 인수 통과 조건을 준수하는지 확인하는 테스트

- 인수 조건은 계약이 체결될 때 정의되어야 함

b. 규정 인수 테스팅

- 정부 지침, 법률 또는 안전 규정 등 준수해야 하는 규정에 맞게 개발되었는지 확인하는 테스팅

4) 알파 테스팅과 베타(필드) 테스팅

a. 알파 테스팅

- 개발 조직 내에서 고객에 의해 수행

- 공장 인수 테스팅(Factory acceptance testing)과 같은 의미: 고객사의 사이트로 이동하기 전에 개발 완료 후 테스팅

b. 베타(필드) 테스팅

- 실제 환경에서 사용자 혹은 잠재 고객에 의해 수행

- 사이트 인수 테스팅(Site acceptance testing)과 같은 의미: 고객사의 사이트로 이동한 후 테스팅