공부/ISTQB

[ISTQB] 2.2 테스트 레벨

모카젤리 2014. 9. 5. 15:22

ISTQB CTFL Syllabus 2011


테스트 레벨

Test Level




Terms

  • 알파 테스팅 Alpha testing
  • 베타 테스팅 Beta testing, 현장 테스팅 Field testing
  • 컴포넌트 테스팅 Component testing

- 개별적인 소프트웨어 컴포넌트에 대한 테스트. 단위테스팅(Unit testing)

  • 드라이버
  • 기능 요구사항 Functional requirement

- 컴포넌트나 시스템이 수행해야 하는 기능을 명세한 요구사항.

  • 통합 Integration
  • 통합 테스팅 Integration testing
  • 비기능 요구사항 Non-functional requirement

- 기능성이 아닌, 신뢰성, 효율성, 사용성, 유지보수성과 이식성과 같은 속성과 관련된 요구사항.

  • 강건성 테스팅 Robustness testing

- 소프트웨어 제품의 강건성을 측정하기 위한 테스팅.

  • 스텁 Stub, 테스트 스텁 Test stub

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

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

-스텁은 호출된 컴포넌트를 대체한다.

  • 시스템 테스팅 System testing
  • 테스트 환경 Test environment
  • 테스트 레벨 Test level
  • 테스트 주도 개발 Test driven development

- 테스트케이스를 실행하기 위한 소프트웨어가 개발되기 전에, 테스트케이스를 먼저 개발하고 주로 자동 실행되도록 한 후, 해당 데스트를 통과하도록 소프트웨어를 개발하는 방법.

  • 사용자 인수 테스팅 User acceptance testing, 인수 테스팅 Acceptance testing

- 시스템이 인수조건을 만족시키는지, 사용자, 고객 또는 다른 인가된 개체가 시스템을 인수할 지 결정할 수 있도록 사용자의 필요, 요구, 그리고 비즈니스 프로세스를 고려하여 수행하는 공식적인 테스팅.

- 계약상의 요구사항이 만족되었는 지 확인하기 위해, 설치 후 구입자 운영 환경에서 납품자도 참가하여 구입자에 의해 실시되는 시스템 또는 기능 단위의 공식적인 테스팅.

- 고객(구입자)이 개발된 시스템을 인수할 것인지 결정하는 결과물 도출


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


Background

  • 각 테스트 레벨에서 다음과 같은 것을 식별할 수 있다.

- 일반적인 목적

- 테스트케이스를 도출하는 데 참조가 되는 개발 산출물(테스트 베이시스),  

- 테스트 대상(i.e. 테스트된 어떤 것)

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

- 테스트 하네스 요구사항과 지원되는 툴

- 특별한 접근방법과 책임

  • 시스템 설정 데이터 테스팅은 테스트 계획 중에 고려되어야 한다.


2.2.1 컴포넌트 테스팅

  • 테스트 베이시스

- 컴포넌트 요구사항

- 구체적인 설계

- 코드

  • 일반적인 테스트 대상

- 컴포넌트

- 프로그램

- 데이터 변환 / 프로그램 이전(migration)

- 데이터베이스 모듈


  • 컴포넌트 테스팅(AKA 유닛, 모듈, 프로그램 테스팅)은 개별적으로 테스트할 수 있는 소프트웨어 모듈, 프로그램, 오브젝트, 클래스 등에서 결함을 찾고 기능을 검증한다.
  • 개발 생명주기와 시스템 콘텍스트에 의존적이면서, 시스템의 다른 부분에서 분리되어 수행될 수 있다.
  • 스텁, 드라이버, 시뮬레이터를 사용할 수 있다.
  • 컴포넌트 테스팅은 구조 테스팅(e.g. 결정 커버리지)뿐 아니라, 기능성과 리소스활동(e.g. 메모리 누수 검색)이나 강건성 테스팅과 같은 특정 비기능적 특성을 포함한다.
  • 테스트케이스는 컨포넌트 명세서, 소프트웨어 설계나 데이터 모델같은 작업 산출물로부터 도출된다.
  • 일반적으로 테스트 중인 코드에 접근하고, 유닛 테스트 프레임워크나 디버깅 툴과 같은 개발환경의 지원으로 수행된다.
  • 실무에서 코드를 작성한 프로그래머가 참여하며, 결함을 찾으면, 공식적인 관리 없이 바로 고쳐진다.
  • 코딩 전에 테스트케이스를 준비하고 자동화 하는 컴포넌트 테스팅 방식을 테스트 우선방식(test-first approach) 혹은 테스트 주도 개발(test-driven development)이라고 부른다.
  • 이러한 접근방식은 상당히 반복적이며, 코드의 작은 부분들을 설계, 통합하고 이것이 통과할 때까지 컴포넌트 테스트를 실행을 반복하는 주기에 기반한다.


2.2.2 통합 테스팅

  • 테스트 베이시스

- 소프트웨어와 시스템 설계

- 아키텍쳐

- 워크플로우

- 사용 케이스

  • 일반적인 테스트 대상

- 서브시스템

- 데이터베이스 구현

- 인프라

- 인터페이스

- 시스템 설정과 설정 데이터


  • 통합 테스팅은 다음을 테스트한다.

- 컴포넌트들 사이의 상호작용

- 운영체제, 파일시스템, 하드웨어와 같은 시스템의 다른 부분들 사이의 상호작용

- 시스템들 사이의 상호작용


  • 통합 테스팅은 하나 이상의 레벨이 있을 수 있고, 다양한 규모를 대상으로 수행될 수 있다.

- 컴포넌트 통합 테스팅은 소프트웨어 컴포넌트 사이의 상호작용을 테스트하며, 컴포넌트 테스팅 이후 수행된다.

- 시스템 통합 테스팅은 다른 시스템들이나 하드웨어와 소프트웨어 사이의 상호작용을 테스트하며, 시스템 테스팅 이후 수행될 수 있다. 이러한 경우, 개발 기관은 인터페이스의 한 부분만 제어할 수 있으며, 이것은 위험으로 간주될 수 있다. 워크플로우로 구현된 비즈니스 프로세스는 시스템의 연속을 포함할 수 있으며, 크로스 플랫폼 이슈는 상당히 중요하다.

  • 통합의 범위를 넓히면 특정 컴포넌트나 시스템으로부터 결함을 분리하기 어려워지고, 이것은 리스크 증가와 문제 해결 시간 연장을 초래한다.
  • 체계적인 통합 전략은 (top-down과 bottom-up과 같은) 시스템 아키텍쳐, 기능적 작업, 트랜젝션 프로세스 시퀀스나 시스템 혹은 컴포넌트의 일부 다른 측면를 기반으로 할 수 있다.
  • 장애 분리를 용이하게 하고, 결함을 일찍 찾기 위해서 통합은 일반적으로 "빅뱅big bang"보다 점진적이어야 한다.
  • 기능성 테스팅 뿐만 아니라 특정한 비기능적 특성(e.g. 성능) 테스팅 역시 통합 테스팅에 포함될 수 있다.
  • 통합의 각 스테이지에서 테스터는 통합 자체에만 집중해야 한다. 예를들에 모듈A와 모듈B를 통합할 때, 컴포넌트 테스팅에서 완료된 각 모듈의 기능성은 배제하고 모듈간의 의사소통 테스팅에 집중한다. 
  • 통합 테스팅에서는 기능적이고 구조적 접근법 모두 사용될 수 있다.
  • 이상적으로 테스터는 아키텍쳐를 이해하고, 통합 계획을 세워야 한다.
  • 통합 테스트가 컴포넌트나 시스템이 구축되기 전에 계획되면, 컴포넌트들은 가장 효율적인 테스팅이 적합하도록 설계될 수 있다.

2.2.3 시스템 테스팅

  • 테스트 베이시스

- 시스템과 소프트웨어 요구명세서

- 사용 케이스

- 기능석 명세서

- 위험 분석 보고서

  • 일반적인 테스트 대상

- 시스템, 사용자, 운영 매뉴얼

- 시스템 설정 및 설정 데이터

  • 시스템 테스팅은 전체 시스템/제품의 동작과 관련이 있다.
  • 테스팅 범위는 마스터나 해당 레벨에서의 레벨 테스트 계획 안에서 명확하게 다루어져야 한다.
  • 시스템 테스팅에서, 테스팅에서 발견할 수 없는 환경 제한적 장애의 리스크를 최소화하기 위해 테스트 환경은 최종 타겟이나 제품 환경과 일치해야 한다.
  • 시스템 테스팅은 리스크나 요구 명세서, 비즈니스 프로세스, 유즈케이스나 다른 고수준의 텍스트 설명, 시스템 동작의 모델들, 운영체제의 통합, 시스템 리소스에 기반한 테스트를 포함할 수 있다.
  • 시스템 테스팅은 시스템의 기능적, 비기능적 요구사항과 데이터 품질 특성을 조사해야 한다.
  • 테스터는 불완전하거나 문서화되지 않은 요구사항도 고려해야 한다.
  • 기능 요구사항의 시스템 테스팅은 테스트될 시스템의 일부분에 가장 적절한 명세 기반 기법(black box)을 사용하여 시작할 수 있다. 예를들어 결정테이블은 비즈니스 룰로 설명된 결과들의 조합으로 생성될 수 있다.
  • 구조 기반 기법(white box) 은 메뉴 구조나 웹 페이지 네비게이션과 같은 구조적 요소에 대해 수행한 테스팅의 완전성을 평가하기 위해 사용될 수 있다.
  • 시스템 테스팅은 주로 독립적인 테스트팀이 수행한다.

2.2.4 인수 테스팅

  • 테스트 베이시스

- 사용자 요구사항

- 시스템 요구사항

- 사용 케이스

- 비즈니스 프로세스

- 위험 분석 보고서

  • 일반적인 테스트 대상

- 전체 시스템 통합이 이루어진 비즈니스 프로세스

- 운영 및 유지보수 프로세스

- 사용자 프로시저

- 형식 Forms

- 보고서

- 설정 데이터


  • 인수 테스팅은 주로 시스템 구매자 혹은 사용자가 전담한다.
  • 다른 이해관계자도 관련될 수 있다.
  • 인수테스팅의 목적

- 시스템, 시스템의 일부, 특정 비기능적 특성에 대한 확신을 갖는 것.

- 주요 목적은 결함을 찾는 것이 아니다.

- 배포와 사용에 대한 시스템의 준비 평가.

- 테스팅의 마지막 레벨이라고 할 수 없다. (대규모 시스템 통합 테스트는 시스템 인수 테스팅 이후에 이루어 짐)

  • 인수 테스팅은 생명주기 내 다양한 시간에 수행될 수 있다.

- 상용 소프트웨어(COTS)의 인수테스팅은 설치하거나 통합될 때.

- 컴포넌트 사용성의 인수테스팅은 컴포넌트 테스팅이 수행되는 동안.

- 새로운 기능 개선의 인수테스팅은 시스템 테스팅 이전에.


  • 사용자 인수 테스팅 

- 시스템의 사용 적합성을 비즈니스 사용자가 확인.

  • 운영상의 (인수) 테스팅 

- 시스템 운영자에 의한 시스템 인수는 다음을 포함한다.

- 백업 / 복원 테스팅

- 재난 복구

- 사용자 관리

- 유지보수 작업

- 데이터 로드와 이전(마이그레이션) 작업

- 보안 취약점의 정기 검사

  • 계약과 규제 인수 테스팅

- 계약 인수 테스팅 : 생산된 사용자 정의 개발(맞춤) 소프트웨어가 계약의 인수 기준을 만족했는 지에 대해 수행.

     인수 기준은 당사자들이 계약에 동의했을 때 정의.

- 규제 인수 테스팅 : 정부, 법적, 안정성 규제 등의 규칙을 준수했는 지에 대해 수행.

  • 알파, 베타(현장) 테스팅

- 소프트웨어가 상업적으로 출시되기 이전에 잠재적 고객이나 기존 고객으로 부터 피드백을 받기 위해 수행.

- 알파 테스팅 : 개발 조직 위치 내에서 개발팀이 아닌 사람들이 수행. (공장 인수 테스팅)

- 베타 테스팅 (현장 테스팅) : 사용자나 잠재 고객이 현장에서 수행. (사이트 인수 테스팅)



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


저작자표시 비영리 변경금지 (새창열림)