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

2.1 소프트웨어 개발 모델

2.1.1 V모델

Requirements -> Specification -> Desgin -> Code 

Vs 

Unit Testing -> Integration Testing -> System Testing -> Acceptance Testing 

- 실제 업무에서 프로젝트나 소프트웨어 제품의 특성에 따라 V-모델에서의 개발 단계 및 테스트 레벨을 더 많이 구성할 수도 있고 적게 구성 할 수도 있다. 예를 들어, 컴포넌트 테스팅 이후에 컴포넌트 통합 테스팅이 있을 수 있고, 시스템 테스팅 이후에 시스템 통합 테스팅이 존재할 수 있다. 

- 일반적인 개발 산출물은 CMMI(Capability Maturity Model Integration)나 소프트 웨어 라이프 사이클 프로세스(Software life cycle process)(IEEE/IEC 12207)를 참고 하도록 한다. 

- 개발 초기에 테스팅을 수행 한다는 것은 개발 산출물을 리뷰(Review) 형태로 검토하면서 결함을 발견하는 정적 테스팅을 의미한다.

- 베리피케이션과 밸리데이션(Verification and validation)은 소프트웨어 개발 수명주기에 전 단계에서 수행될 수 있다. 

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

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

 

2.1.2 반복적-점증적(Iterative-incremental) 개발 모델

- 반복적-점증적인 개발방법은 요구사항 분석, 시스템 설계, 구현 및 테스팅하는 개발 주기가 짧게 연속적으로 반복(Iteration)하는 활동으로 이루어진다. 

- 개발 리스크를 조기에 감소시킬 수 있는 장점

- 모델의 예는 Agile, RUP, RAD, 이해관계자 중심의 소프트웨어 개발, 프로토타이핑이 있다.

 

2.1.3 개발 수명주기(Life cycle) 모델에서의 테스팅

- 성공적인 테스팅을 위해서는, 그 개발 수명주기 모델에 관계 없이 다음과 같은 요건들이 필요하다.

1) 모든 개발 활동은 이에 상응하는 테스팅 활동을 동반한다.

2) 각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가지고 있다.

3) 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되는 개발 활동 동안에 시작되어야 한다.

4) 개발 수명주기 동안에 개발 산출물의 초안이 작성되면, 테스터는 이러한 문서를 리뷰하는 활동에 참가해야 한다. 

- 테스트 레벨은 프로젝트나 시스템 아키텍처의 성격에 따라 재조정되거나 합쳐질 수 있다. 

 

2.2 테스트 레벨

2.2.1 컴포넌트 테스팅(Component testing)

- 단위 테스팅(Unit testing)이라고도 불리는 컴포넌트 테스팅은 테스트가 가능한 (최소) 단위로 나누어진 소프트웨어(모듈, 프로그램, 객체, 클래스 등) 내에서 결함을 찾고 그 기능을 검증하는 것이다. 

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

- 테스트 케이스는 컴포넌트 명세서, 소프트웨어 상세 설계 또는 데이터 모델과 같은 개발 산출물에서 도출한다. 

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

- 컴포넌트 테스팅의 일반적인 목적
1) 기본 경로(Path)를 확인
2) 모든 오류 처리 경로(Error handling path)를 확인
3) 컴포넌트 내의 인터페이스 확인
4) 로컬 데이터 확인, 경계값 확인 

 

2.2.2 통합 테스팅(Integration testing)

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

- 통합 테스팅은 하나 이상의 테스트 레벨이 있을 수 있으며, 다양한 크기의 테스트 대상에 대해 수행될 수 있다. 

- 통합하는 범위가 크면 클수록 장애나 결함의 위치를 찾아 격리하기가 쉽지 않다. 이는 개발의 리스크(Risk)를 증가시키기도 한다. 
따라서 상향식(Bottom-up), 하향식(Top-down), 백본(Back-bone) 통합과 같은 순차적이고 체계적인 통합 전략(Incremental approach)이 한 번에 통합하는 빅뱅(Big-bang) 전략보다 리스크를 줄이는데 효과적이다.

 

2.2.3 시스템 테스팅(System testing)

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

- 테스팅에서 발견하지 못하여 발생할 수 있는 "환경 특성 장애" 리스크를 최소화하기 위해서 시스템 테스팅은 가능한 범위에서 실제 최종 사용 환경 또는 이와 유사한 환경에서 수행해야 한다. 

- 시스템 테스팅 수행의 근간은 아래와 같은 상위 레벨의 테스트 베이시스이다.

1) 리스크 분석서
2) 요구사항 명세
3) 비즈니스 프로세스
4) 유즈 케이스
5) 기타 비즈니스 레벨의 시스템 동작 명세
6) OS 및 시스템 리소스와의 상호작용 명세 

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

- 기능적 요구 사항의 시스템 테스팅은 테스트 대상의 특성을 가장 상세하게 명세한 문서를 기반으로 테스트를 설계하는 명세기반(블랙박스) 기법을 수행한다. 예를 들어, 비즈니스 룰에 표현된 결과들의 조합을 테스트하기 위해 결정 테이블(Decision table) 기법을 사용할 수 있다. 
그런 다음, 메뉴 구조나 웹 페이지 네비게이션과 같은 구조적인(비기능적인) 요소에 대한 결합에 문제가 없는지 평가하기 위해 구조 기반 기법을 사용할 수 있다. 

- 비기능적 요구 사항의 시스템 테스팅은 소프트웨어의 기능적 품질특성 외의 나머지 부분에 대한 요구사항 검증을 수행한다. 

- 시스템 테스팅은 독립적인 테스트 팀이 수행하는 경우가 대부분이다. 실무에서는 시스템 테스팅과 인수 테스팅 사이에 출시 여부를 결정하기 위한 일종의 '검수' 테스팅이 존재하는 경우가 있다. 

 

2.2.4 인수 테스팅(Acceptance testing)

- 인수 테스팅은 시스템을 사용하는 고객이나 사용자가 전담하여 수행하는 경우가 대부분인데, 다른 이해관계자도 참여할 수 있다.

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

- 인수 테스팅은 시스템을 배포하거나 실제 사용할만한 준비가 되었는지에 대해 평가한다. 

- 한 시스템에 대한 인수 테스팅 이후에 대규모 시스템간의 통합 테스트가 수행 될 수도 있기 떄문에 인수 테스팅이 반드시 최종 단계의 테스팅이라고 보기는 어렵다. 

- 고객사의 사이트로 이동하기 전에 개발 완료 후 테스팅하는 소위 '공장 인수 테스팅'은 알파 테스팅이다.

- 고객 사이트로 이동한 후에 테스팅하는 '사이트 인수 테스팅'은 베타 테스팅이다.

2.3 테스트 유형

기능 테스팅(Functional testing)

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

- 문서화 되어 있거나 테스터가 알고 있는 기능과 특징, 그리고 그것들과 특별한 시스템과의 상호 운용성을 고려하여 수행

- 명세 기반 기법(Specification-based technique)을 이용해 소프트웨어나 시스템의 기능에서 테스트 조건(Test condition)과 테스트 케이스를 도출 하고, 소프트웨어의 외부적인 행동을 고려한다.(블랙 박스 테스팅)

- 기능 테스팅의 한가지 형태인 보안성 테스팅(Security testing)은 악의적인 코드(바이러스)와 같은 외부의 위협을 감지해 내는 것과 관련 있는 기능을 확인한다.

 

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

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

- 비기능 테스팅이라는 용어는(성능 테스팅에서의 응답시간과 같이) 다양한 척도 또는 비율(Scale)로 정량화 가능한 소프트웨어나 시스템의 특성(Characteristics)을 측정하는 테스트를 의미한다.

 

구조적 테스팅(Structural testing)

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

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

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

- 자동화 툴을 사용하여 프로그램 코드의 구문(Statements) 혹은 결정문(Decisions)과 같은 커버리지 요소를 측정 하게 한다.
=> 소나큐브 

 

확인 테스팅(Confirmation tesing)

- 결함이 발견되고 수정된 후에 소프트웨어는 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트 되어야 한다. 이것을 확인 테스팅이라고 부른다. 

- 결함의 원인을 찾거나 결함을 수정하기 위한 디버깅(Debugging)은 개발 활동이며 테스팅 활동으로 보지 않는다. 

 

리그레션 테스팅(Regression testing)

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

- 리그레션 테스팅(Regression testing)은 이미 테스트된 프로그램의 테스팅을 반복하는 것으로, 결함 수정 이후 변경의 결과로 새롭게 만들어 지거나, 이전 결함으로 인해 발견되지 않았던 또 다른 결함을 발견하는 것이다(단어 의미 그대로 '퇴행(Regression)' 여부를 확인하는 테스팅이다).