ISTQB) Part2. 소프트웨어 수명주기와 테스팅

* 이 글은 개발자도 알아야할 소프트웨어 테스팅 실무 제3판을 토대로 작성되었습니다.

* 책에 실린 내용 외 추가적인 정의가 있으며, 교재 목차와 순서가 다소 다를 수 있습니다.

* 2차 가공 및 재배포는 금지합니다.

* 잘못된 개념 혹은 오탈자는 댓글로 알려주세요.

 

1. 소프트웨어 개발 모델

[ V-모델 ( 순차적 개발 모델 ) ]

* 폭포수 모델에 시스템 검증과 테스트 작업을 강조한 모델

   - 일반적으로 4단계의 테스트 레벨과 4단계의 개발 활동을 가지고 있으나 반드시 일대일 대응이 되는 것은 아님

   - 상위층 : 요구사항 추출과 운영

   - 중간층 : 인터페이스 구조 매핑 부분

   - 하위층 : 모듈의 조립과 코딩

 

   - V-모델에서 제시하는 테스트 레벨 : 컴포넌트 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅

   - 테스트 레벨의 필요성 : 실무에서 테스팅을 진행할 때 각 테스트 레벨에 따라 테스트 전략, 테스트 기법, 테스트 수행 주체, 테스트 완료 기준 등이 달라지기 때문

   - 각각의 테스트 레벨은 서로 독립적

 

   - 역할 : 각각의 개발 단계에서 테스팅을 접근하는 방법을 개략적으로 이해하기 쉽게 모델화하여 보여줌

 

   - 검증(Verification) : 소프트웨어의 올바른 구현을 보장하기 위함 ( 개발자 중심의 품질 향상 기법 )

   - 확인(Validation) : 최종 목적의 달성을 위한 사용자 요구사항이 충족되었는지를 확인 ( 사용자 중심의 품질 향상 기법 )

 

[ 반복적 - 점증적 개발 모델 ]

* 개발 주기를 짧게 연속적으로 반복하는 활동

 

* 장점 : 개발 리스크를 초기에 감소시킴

 

* 예 : 애자일 개발 모델, 이해관계자 중심의 소프트웨어 개발, 프로토타이핑

 

[ 개발 생명주기(Life Cycle) 모델 ]

* 모든 개발 활동은 테스팅 활동과 대응

 

* 각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가지고 있음

 

* 주어진 테스트 레벨에 맞는 테스트 분석과 설계는 대응되는 개발 활동 동안에 시작

 

* 테스터는 개발 라이프 사이클 동안에 초안이 준비됨과 동시에 해당 문서를 리뷰하는 활동에 참가

 

2. 테스트 레벨

[ 컴포넌트 테스팅 ( Component Testing ) ]

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

   - 컴포넌트 : 소프트웨어 시스템에서 독립적인 업무 또는 독립적인 기능을 수행하는 모듈로서 이후 시스템을 유지보수하는데 교체 가능한 부품

 

* 목적

   - 컴포넌트의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단

   - 컴포넌트 내에 존재하는 결함 발견

   - 컴포넌트 품질 수준에 대한 자신감 획득

 

[ 통합 테스팅 ( Integration Testing ) ]

* 소프트웨어의 각 모듈 간의 인터페이스 관련 오류와 결함을 찾아내는 체계적인 테스트 기법

 

* 목적

   - 단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지를 확인하는 것

 

* 통합 접근법의 특징

   - 백본(Backbone)

     : 가장 중요하고 위험도가 높은 모듈로 초기 백본(통합) 형성 ( 드라이버 / 스텁 필요에 따라 만들어서 사용 )

 

   - 빅뱅(Big-bang)

     : 모든 테스트 모듈을 동시에 통합 ( 드라이버 / 스텁없이 실제 모듈로 테스트 )

 

   - 상향식(Bottom up)

     : 가장 하부의 모듈로부터 통합해가면서 진행 ( 테스트 드라이버 필요 )

 

   - 하향식(Top down)

     : 가장 상부의 모듈부터 통합해가면서 진행 ( 테스트 스텁 필요 )

 

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

* 드라이버 : 컴포넌트나 시스템을 제어하거나 호출하는 상위 컴포넌트를 대체하는 테스트용의 소프트웨어 컴포넌트 또는 툴

 

[ 시스템 테스팅 ( System Testing ) ]

* 명시된 요구사항을 만족하는지 확인하기 위해 통합된 시스템을 테스트

 

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

 

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

 

* 목적

   - 시스템의 기능/비기능 동작이 설계대로 이루어지는지 검증

   - 완성된 시스템이 기대대로 동작하는지 확인

 

[ 인수 테스팅 ( Acceptance Testing ) ]

* 전체 시스템 또는 제품의 동작이나 능력에 초점을 맞춤

 

* 목적

   - 시스템이나 시스템 일부 또는 특정 비기능적인 특성에 대한 확신을 얻는 것 ( 결함을 찾는게 아님 )

   - 배포 또는 실제 사용할 준비가 되었는지 평가 ( 최종 테스트 단계 아님 )

 

* 프로젝트 전 개발 과정에서 수행 가능

 

* 형태

   - 사용자 인수 테스팅

   - 운영상의 인수 테스팅

   - 계약 인수 테스팅, 규정 인수 테스팅

   - 알파 테스팅, 베타 테스팅

 

3. 테스트 유형, 유지보수 테스팅

[ 테스트 유형 ]

* 테스팅하는 목적 및 품질 특성을 염두에 두고, 소프트웨어 시스템을 검증하는 일련의 테스트 활동

 

* 다음과 같은 특정한 테스트 목적에 중점

   - 소프트웨어가 수행하는 기능에 대한 테스팅

   - 호환성, 신뢰성, 사용성과 같은 비기능적인 품질 특성 테스팅

   - 소프트웨어나 시스템의 구조나 아키텍처에 대한 테스팅

   - 변경 내용에 관련된 테스팅, 예를 들어, 결함에 대한 수정이 이루어졌는지에 대한 확인 테스팅과 의도하지 않은 변경을 찾는 리그레션 테스팅

 

[ 기능 테스팅 ( Functional Testing ) ]

* 소프트웨어가 수행하는 기능에 대한 ( 품질 특성 ) 테스팅

 

* 시스템이 수행하는 그 무엇을 테스팅

 

* 기능성이라는 품질 특성에 적합성, 정확성, 준수성, 상호운용성, 보안성 등의 부특성을 포함

 

* 명세 기반 기법을 이용한 테스팅

   - 블랙박스 테스팅

   - 소프트웨어나 시스템 기능에서 테스트 조건과 테스트 케이스를 도출, 소프트웨어의 외부적인 행동을 고려

 

[ 비기능 테스팅 ( Non-Functional Testing ) ]

* 사용성, 성능 효율성 또는 보안성과 같은 시스템 특성을 평가

 

* 시스템이 어떻게 동작하는가를 테스팅

 

* 가능한 초반에 수행하는 것이 좋음

 

[ 구조적 테스팅 ( Structural Testing ) ]

* 목적

   - 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보장성 또는 충분함을 측정

   - 명세 기반 기법을 적용한 다음에 사용

 

* 커버리지

   - 시스템 또는 소프트웨어의 구조가 테스트 수트에 의해 커버된 정도

   - 구조 종류에 대해 커버된 퍼센트로 표시

   - 커버리지가 100%가 아니라면, 누락된 아이템을 테스트하기 위해 추가로 테스트 설계를 해 커버리지를 높임

 

* 모든 테스트 레벨에서 수행

   - 컴포넌트 통합 테스트 레벨에서 프로그램의 코드 수의 수행 커버리지를 높이는 목적

   - 구조적 테스트 기법(화이트 박스 테스트 기법)을 적용

   - 내부 구조 : 코드, 아키텍처, 시스템 내 데이터 플로우 등

 

[ 확인/회귀 테스팅 ( Confirmation(re-testing) and regression Testing ) ]

* 확인 테스팅

   - 결함이 발견되고 수정된 후에 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트하는 것

 

* 회귀 테스팅

   - 결함 수정 이후 변경의 결과로 도입되었거나 발견되지 않았던 또 다른 결함을 발견

   - 이미 테스트된 프로그램의 테스팅을 반복하는 것

   - 결함은 테스트 중인 소프트웨어에 존재하거나 다른 관련이 있는 또는 전혀 관련이 없는 소프트웨어 컴포넌트에 존재 가능

   - 수행 범위와 정도 : 이전에 정상 동작했던 소프트웨어에서 결함을 발견하지 못해 야기될 수 있는 리스크에 바탕을 둠

   - 기능, 비기능, 구조적 테스팅에 적용 가능

   - 회귀 테스팅 → 반복적 성향 → 자동화 대상

 

[ 유지보수 테스팅 ( Maintenance Testing ) ]

* 이미 운영되고 있는 시스템에서 수행

 

* 소프트웨어나 시스템이 변경, 단종되었거나 마이그레이션될 때 발생

 

* 종류

   - 변경에 의해 : 릴리즈 기반의 계획된 개선을 위한 변경, 요구사항 변경에 의한 수정, 긴급 변경, 환경의 변경

   - 마이그레이션을 위해 : 변경된 소프트웨어에 대한 운영 테스트 뿐만 아니라, 새로운 환경에서의 운영 테스트도 포함

   - 단종에 의한 : 데이터의 보유기간이 필요하다면 데이터 저장관련 사항을 테스팅해야함

   - 범위 : 변경 사항의 리스크 및 크기, 기존 시스템의 크기와 관련됨