[ISTQB] 2.3 테스트 유형

ISTQB CTFL Syllabus 2011

테스트 유형

Test Types

Terms

• 블랙박스 테스팅 Black-box testing

• 코드 커버리지 Code coverage

• 기능성 테스팅 Functional testing

• 상호운용성 테스팅 Interoperability testing

• 부하 테스팅 Load testing

• 유지보수성 테스팅 Maintainability testing

• 성능 테스팅 Performance testing

• 이식성 테스팅 Portability testing

• 신뢰성 테스팅 Reliability testing

• 보안성 테스팅 Security testing

• 스트레스 테스팅 Stress testing

• 구조적 테스팅 Structural testing

• 사용성 테스팅 Usability testing

• 화이트박스 테스팅 White-box testing

출처 : http://dic.sten.kr/

Background

• 테스트 활동의 일부는 테스트를 하는 특정 이유나 타겟을 기반으로 소프트웨어 시스템(이나 시스템의 일부분)을 확인하는 것을 목표로 할 수 있다.

• 특정한 테스트 목적에 중점을 둔 테스트 유형

- 소프트웨어가 수행하는 기능

- 신뢰성이나 사용성과 같은 비기능적 품질 특성

- 소프트웨어나 시스템의 스트럭처나 아키텍쳐

- 변경사항과 관련한 테스트

   확인테스팅 : 수정된 결함 확인

   리그레션 테스팅 : 의도하지 않은 변경 탐색

• 특정 테스트에서 개발, 사용되는 소프트웨어 모델

- 구조적 테스팅 : 제어 흐름 모델(Control flow model), 메뉴 구조 모델(Menu structure model)

- 비기능 테스팅 : 성능 모델(Performance model), 사용성 모델(Usability model), 보안 위협 모델(Security threat modeling)

- 기능성 테스팅 : 프로세스 흐름 모델(Process flow model), 상태 전이 모델(state transition model), 평문 언어 명세(plain language specification)

2.3.1 기능 테스팅 (기능성 테스팅)

• 기능(Functions)

- 요구명세서, 사용 케이스, 기능적 명세서와 같은 작업산출물에 기술되어 있거나, 문서화 되어 있지 않을 수 있다.

- 시스템이 하는 무엇(What)

• 기능 테스트

- 기능과 특징(문서에 기술되어 있거나 테스터가 이해한 것), 특정 시스템과의 상호운용성에 기반한다.

- 모든 테스트 레벨에서 수행 (e.g. 컨포넌트 명세 기반의 컴포넌트 테스트)

• 명세기반 기법 : 소프트웨어나 시스템의 기능성으로 부터 테스트 조건과 테스트 케이스를 도출.
• 기능성 테스트는 소프트웨어의 외부적 행동을 고려한다 (블랙박스 테스팅)

• 기능성 테스팅의 종류

- 보안성 테스팅 : 바이러스와 같은 악의적인 외부의 위협을 감지하는 것과 관련된 기능(e.g. 방화벽) 시험

- 상호운용성 테스팅 : 하나 이상의 특정한 컴포넌트나 시스템과 상호작용하는 기능 평가

2.3.2 비기능적 소프트웨어 특성 테스팅 (비기능 테스팅)

• 비기능 테스팅의 종류

- 성능테스팅

- 부하 테스팅

- 스트레스 테스팅

- 사용성 테스팅

- 유지보수성 테스팅

- 신뢰성 테스팅

- 이식성 테스팅

• 비기능 테스팅

- 시스템이 어떻게(How) 동작하는 지 테스트

- 모든 테스트 레벨에서 수행될 수 있다.

- (성능 테스팅의 응답시간과 같이) 다양한 규모에서 정량화 될 수 있는 시스템과 소프트웨어의 특성을 측정하는 데 필요한 테스트

- 비기능 테스팅은 소프트웨어의 외부적 행동을 고려하고, 이를 완수하기 위해 대부분 블랙박스 테스트 디자인 기법을 사용한다.

2.3.3 소프트웨어 Structure / Architecture 테스팅 (구조적 테스팅)

• 구조적(white-box) 테스팅은 모든 레벨에서 수행될 수 있다.
• 구조적 기법은 구조 유형 커버리지 평가에 대한 테스팅의 완전성을 측정하기 위해 명세 기반 기법 이후 사용되되는 것이 가장 적합하다.

• 커버리지

- 테스트 스위트에 의해 테스트가 수행된 구조의 범위

- 커버된 요소들의 퍼센티지(Percentage)로 표현

- 커버리지가 100%가 아닌 경우 누락된 요소들을 테스트하도록 커버리지를 확대하기 위해 더 많은 테스트를 설계

• 모든 테스트 레벨, 특히 컴포넌트 테스팅과 컴포넌트 통합 테스팅에서, 선언이나 결정과 같은 요소들의 코드 커버리지를 측정하기 위해 도구(Tools)를 사용할 수 있다.
• 구조적 테스팅은 하이어라키(Hierarchy)로 부르는 시스템 아키텍처(Architecture)에 기반한다.
• 구조적 테스팅 접근방식은 시스템, 시스템 통합이나 인수 테스팅 레벨에서도 적용할 수 있다. (e.g. 비즈니스 모델, 메뉴구조)

2.3.4 변경사항에 관련된 테스팅 : 재테스팅과 리그레션 테스팅

• 확인 테스팅 

- 결함이 발견되고 수정되면, 소프트웨어는 기존의 결함이 완전히 사라졌는 지 확인하기 위해 재테스트 되어야 한다.

• 디버깅 

- 결함의 위치를 찾고 수정

- 테스트 활동이 아닌 개발 활동이다.

• 리그레션 테스팅

- 수정된 이후 변경사항의 결과물로서 이미 알려졌거나 발견되지 않은 결함을 발견하기 위해 이미 테스트된 프로그램의 테스팅 반복

- 이러한 결함들은 테스트 중인 소프트웨어에 존재할 수도 있고, 관련이 있거나 관련없는 다른 소프트웨어 컴포넌트에 있을 수 있다.

- 소프트웨어나 환경이 변경되었을 때 수행

- 이미 실행된 소프트웨어에서 발견되지 않은 결함의 리스크를 기반으로 범위를 정한다.

- 확인 테스팅으로 사용되거나 리스레션 테스팅을 지원하는 테스트는 반복이 가능하다.

- 모든 레벨에서 수행.

- 기능적, 비기능성, 구조적 테스팅 포함.

- 리그레션 테스트 스위트는 여러번 수행되며 일반적으로 천천히 변화하기 때문에 강력한 자동화 후보이다.

---

2014/09/01 - [공부/ISTQB] - [ISTQB] 2. 소프트웨어 생명주기에서의 테스팅