2. 소프트웨어 수명주기와 테스팅

 

1. 소프트웨어 개발 모델

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

v-모델은 요구사항 정의 및 분석, 시스템 설계, 구현, 테스팅이라는 일련의 단계(과정)를 통해 소프트웨어(시스템)를 개발하는 폭포수 개발 모델에 근간을 두고 있다. 여기서 테스팅은 한 번에 이루어지는 것이 아니라 각각의 개발 단계에 대응하는 테스트 레벨이 별도로 존재하여 v모양을 이룬다.

일반적 유형의 v-모델에서는 4단계의 테스트 레벨을 제시하고 있고, 이들은 개발 단계의 요구사항 분석, 논리 설계, 물리 설계, 프로그램 코딩의 4단계의 개발 활동과 대응된다.(반드시 일대일 대응은 아님)

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

테스트 레벨의 의미

- 테스트 레벨이 중요한 이유는 실무에서 테스팅을 진행할때 각 테스트 레벨에 따라 테스트 전략, 테스트 기법, 테스트 수행주체, 테스트 완료기준 등이 달라지기 때문이다.

- 각각의 테스트 레벨은 서로 독립적이여서, 각각 다른 테스트 계획과 전략을 필요로 하고, 일반적으로 수행하는 주체가 다르고, 적용하는 테스트 기법의 종류와 형태가 상당 부분 다르며, 별도의 보고를 필요로 한다. 각 레벨은 서로 종속성을 지니기 때문에 하나의 테스트 레벨에서 다른 테스트 레벨로 옮겨가기 위한 종료 및 시작 조건을 갖추는 것이 바람직하다.

Verification and Validation

- 소프트웨어 개발 수명주기의 모든 단계에서 수행될 수 있다.

- verification은 개발 단계의 산출물이 그 단계의 초기에 설정된 조건을 만족하는지 여부를 검증하는 프로세스를 의미한다. 주로 인스펙션과 같은 리뷰 활동을 통해서 검증하지만, 테스트 레벨의 목적에 맞는 동적 테스팅을 통해서도 검증할 수 있다.

- validation은 개발 중에 또는 개발 단계 말에 명시된 또는 명시되지 않았지만 사용자의 관점에서의 요구사항이 만족하는지를 평가하는 프로세스를 의미한다. 정적테스팅과 동적 테스팅 모두에서 검증이 가능하다.

 

반복적 - 점증적 (Interative-incremantal) 개발 모델 

요구사항 분석, 시스템 설계, 구현 및 테스팅하는 개발 주기가가 짧게 연속적으로 반복하는 활동으로 이루어진다. 이 개발 방법론은 초기 반복 단계에서 리스크가 높은 모듈이나 주요 아키텍처에 해당하는 시스템 일부를 우선적으로 개발하고 테스팅을 통해 결함이나 장애를 조기에 발견하고 제거할 수 있는 기회를 확보하기 때문에 개발 리스크를 조기 감소시킬 수 있는 장점을 가진다.

- Agile(애자일) 개발 모델

- RUP(Rational Unified Process)

- RAD(Rapid Application Development)

- 이해관계자 중심의 소프트웨어 개발(Outside-in Software Development)

- 프로토타이핑(Prototyping)

하나의 반복 단계에서 생성한 산출물(프로그램, 시스템)은 일반적으로 테스트 레벨(컴포넌트, 통합, 시스템, 인수 테스팅) 전체 또는 일부를 거치면서 검증될 수 있다. 이전 반복 단계에서 개발한 결과물은 현재의 만복에서 추가 개발한 증분에 의해 규모가 점차 커져 부분 시스템을 형성하게 된다. 이때 해당 반복 단계의 증분도 테스팅해야 하지만 부분 시스템 역시 리그레션 여부의 확인 목적으로 테스팅해야 한다. 

 

2. 테스트 레벨 (Test levels)

컴포넌트 테스팅(Componenet testing)

단위 테스팅이라고도 불리는 컴포넌트 테스팅은 테스트가 가능한 단위로 나뉜 소프트웨어 내에서 결함을 찾고 그 기능을 검증하는 것이다. 개발 수명주기의 정황과 시스템에 의존적이면서도 시스템의 다른 부분에서 격리하여 독립적으로 수행해야 한다. 이때, 스텁과 드라이버, 시뮬레이터 등이 필요할 수 있다.

컴포넌트 테스팅은 구조적인 테스팅은 물론 기능성 테스트와 리소스 관련 테스팅 또는 강건성(Robustness) 테스팅과 같은 특정 비기능 테스팅을 포함한다. 테스트 케이스는 컴포넌트 명세서, 소프트웨어 상세 설계 또는 데이터 모델과 같은 개발 산출물에서 도출한다.

일반적으로 컴포넌트 테스팅은 코드를 중심으로 수행하며, 단위 테스트 프레임웍 또는 디버깅 툴 같은 개발 환경의 지원을 필요로 한다. 

컴포넌트 테스팅은 일반적으로 프로그램 소스코드를 활용하여 테스트를 설계하면 주된 방법은 구조기반(white-box) 테스팅이다. 제어 흐름 테스팅, 조건/결정 커버리지 테스팅, 최소 비교 테스팅 등이 대표적인 구조기반 기법이고, 동등 분할&경계값 분석 테스팅과 같은 명세 기반 기법을 사용하기도 한다.

 

통합 테스팅(Integration testing)

통합 테스팅은 컴포넌트 간의 인터페이스를 테스트하는 것은 물론, os, 파일 시스템, 하드웨어 또는 시스템 간 인터페이스 같은 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트한다. 통합 테스팅은 하나 이상의 테스트 레벨이 있을 수 있으며, 다양한 크기의 테스트 대상에 대해 수행될 수 있다.

통합 테스팅은 기능적 특성, 비기능적 특성을 테스팅해야 한다. 통합 테스팅의 설계는 기능적 접근법, 구조적 접근법을 모두 사용하여, 통합 그 자체에만 집중하는 오류를 범하지 않아야 한다. 이상적으로는 테스터가 아키텍처에 대한 이해를 바탕으로 통합 테스트 계획에 관여해야 한다.

 

시스템 테스팅(System testing)

시스템 테스팅은 개발 프로젝트 차원(범위)에서 정의된 전체 시스템 또는 동작에 대해 테스트하는 것이다.

시스템 테스팅은 기능 및 비기능 요구사항을 모두 검증해야 한다. 기능적 요구사항의 시스템 테스팅은 가장 상세하게 명세한 문서를 기반으로 테스트를 설계하는 명세 기반(블랙박스) 기법을 수행한다. 비기능적 요구 사항의 시스템 테스팅은 소프트웨어의 기능적 품질 특성 외의 나머지 부분에 대한 요구사항 검증을 수행한다. 

시스템 테스팅은 독립적인 테스트 팀이 수행하는 경우가 대부분이다. 

 

인수 테스팅(Acceptance testing)

인수 테스팅은 시스템을 사용하는 고객이나 사용자가 전담하여 수행하는 경우가 대부분이다. 인수 테스팅의 목적은 시스템이나 일부 또는 특정한 비기능적인 특성에 대해 확신을 얻는 것이다. 결함을 찾는 것은 인수 테스팅의 주된 관심사가 아니다. 시스템을 배포하거나 실제 사용할 만한 준비가 되었는지에 대해 평가한다. 프로젝트 모든 개발 과정에서 수행할 수 있다.

사용자 인수 테스팅 : 일반적으로 비즈니스 사용자가 시스템 사용의 적절성을 확인한다.

운영상의 인수 테스팅 : 시스템 관리자에 의한 테스트 활동, 백업/복원 테스팅, 재난 복구, 사용자 관리, 유지보수 작업, 보안 취약성에 대한 정기적인 점검을 테스트한다.

계약 인수 테스팅과 규정 인수 테스팅 : 계약 인수 테스팅은 맞춤식-개발 소프트웨어가 계약상의 인수 통과 조건을 준수하는지 확인하는 테스팅이다. 인수 통과 조건은 계약이 체결될 때 정의되어야 한다. 규정 인수 테스팅은 정부 지침, 법률 또는 안전 규정 등 준수해야 하는 규정에 맞게 개발되었는지 확인하는 테스팅이다.

알파 테스팅과 베타 테스팅 : 시장에서 판매하는 상용 소프트웨어 개발자는 상업적으로 판매되기 전에 목표 시장의 기존 고객이나 잠재 고객으로부터 피드백을 받고 싶어 한다. 알파 테스팅은 개발 조직 내에서 고객에 의해 수행된다. 반면 베타 테스팅 또는 필드 테스팅은 실제 환경에서 사용자 혹은 잠재 고객에 의해 수행된다. 

 

3. 테스트 유형

기능 테스팅(Functional testing)

실행되어야 하는 (서브) 시스템 또는 컴포넌트의 기능은 요구사항 명세, 유즈 케이스 또는 기능적인 명세와 같은 개발 산출물에 기술되어 있거나 문서화되지 않을 수 있다. 기능은 시스템이 수행하는 그 '무엇'을 의미한다.

ISO/IEC 9126에서는 기능성이라는 품질 특성에 적합성, 정확성, 준수성, 상호운용성, 보안성 등의 부특성을 포함시키고 있다. 

 

비기능 테스팅(Non-functional testing)

비기능 테스트는 성능 테스팅, 부하 테스팅, 스트레스 테스팅, 사용성 테스팅, 유지보수 테스팅, 신뢰성 테스팅, 그리고 이동성 테스팅 등을 포함하는 개념이다. 이는 소프트웨어 제품 특성 테스팅이라고도 하며 시스템이 "어떻게" 동작하는 가를 테스팅한다. 

비기능 테스팅은 모든 테스트 레벨에서 수행될 수 있다. 다양한 척도 또는 비율로 정량화 가능한 소프트웨어나 시스템 특성을 측정하는 테스트를 의미한다.

 

구조적 테스팅(Structural testing)

구조적 테스팅은 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보장성 또는 충분함(Thoroughness)을 측정하는 것이 목적인 테스트 유형이다.

커버리지는 시스템 또는 소프트웨어의 구조가 test suites에 의해 테스트된 정도를 말하며 구조 종류에 대해 커버된 퍼센트로 표시한다.  

모든 테스트 레벨에서 수행이 가능하며, 특히 컴포넌트 테스트 레벨과 컴포넌트 통합 테스트 레벨에서 프로그램 코드의 수행 커버리지를 높이는 목적으로 구조적 테스트 기법(화이트 박스 테스트 기법)을 적용할 수 있다.

 

확인(재)/리그레션 테스팅(Confirmation(re-testing) and regression testing)

확인 테스팅 : 결함이 발견되고 수정된 후에 소프트웨어는 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트되어야 한다. 여기서 디버깅은 개발 활동이며 테스팅 활동으로 보지 않는다.

리그레션 테스팅 : 이미 테스트된 프로그램의 테스팅을 반복하는 것으로, 결함 수정 이후 변경의 결과로 새롭게 만들어지거나, 이전 결함으로 인해 발견되지 않았던 또 다른 결함을 발견하는 것이다. 환경이 변해도 수행되어야 한다. 모든 테스트 레벨에서 수행할 수 있으며, 기능, 비기능 그리고 구조적 테스팅이 적용할 수 있다. 

 

4. 유지보수 테스팅 (Maintenance testing) 

소프트웨어 시스템이 일단 배포되면, 일반적으로 수년~수십 년 정도 서비스된다. 이 기간 동안 시스템과 그 환경은 수정되고 변경되거나 확장된다. 유지보수 테스팅은 이미 운영되고 있는 시스템에서 수행되며, 소프트웨어나 시스템이 변경, 단종되었거나 마이그레이션 될 때 발생한다.

유지보수 테스팅은 변경된 부분에 대한 테스팅 이외에도 변경되지 않은 시스템 요소에 대한 방대한 리그레션 테스팅도 고려한다. 유지보수 테스팅의 범위는 변경 사항의 리스크 및 크기, 기존 시스템의 크기와 관련이 있다. 변경된 내용에 따라서, 유지 보수 테스팅은 모든 테스트 유형에 대해 모든 테스트 레벨에서 수행할 수 있다.

 

 

출처 : 개발자도 알아야 할 소프트웨어 테스팅 실무 제3판