[도서] 개발자도 알아야할 소프트웨어 테스팅 실무 - 파트 2

 

📚 도서 요약

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

본 포스팅은 개인적으로 남기고 싶은 부분만을

요약하여 작성함을 알려드립니다.

 

 

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

2.1 SW 개발 모델

개발 수명주기 모델(Life cycle model)에 기반하여 테스트 접근법을 다르게 적용해야 한다.

 

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

- 요구사항 정의 및 분석, 시스템 설계, 구현, 테스팅이라는 일련의 단계를 통해 소프트웨어를 개발하는 폭포수 개발 모델에 근간을 두고 있다.

 

< V모델에서 제시하는 테스트 레벨 >

- 단위(컴포넌트) 테스팅

- 통합 테스팅

- 시스템 테스팅

- 인수 테스팅

 

각각의 테스트 레벨은 서로 독립적이어서, 각각 다른 테스트 계획과 전략을 필요로 하고, 일반적으로 수행하는 주체(조직)가 다르다..(이하 생략)

각 레벨은 서로 종속성을 지니기때문에 하나의 테스트 레벨에서 다른 테스트 레벨로 옮겨 가기 위한 종료 및 시작 조건(Exit and entry criteria)을 갖추는 것이 바람직하다. 

 

개발 초기에 테스팅을 수행한다는 것은 개발 산출물을 리뷰(Review) 형태로 검토하면서 결함을 발견하는 정적 테스팅을 의미한다. 정적 테스팅 동안 테스터는 테스팅 관점에서 TC를 만들면서 결함을 발견하며 리뷰에 기여 할 수 있다.

 

베리피케이션

개발 단계의 산출물이 그 단계의 초기에 설정된 조건을 만족하는지 여부를 검증하는 프로세스

 

밸리데이션

개발 중에 또는 개발 단계 말에 명시된 또는 명시되지 않았지만 사용자의 관점에서의 요구사항이 만족하는지를 평가하는 프로세스

 

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

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

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

 

* 리그레션 테스팅은 첫 번째 반복 단계에서 테스팅 한 이후로 모든 반복 단계에서 수행되어야 하므로 반복 단계가 거듭될수록 중요해진다. 

 

2.2 테스트 레벨

테스트 목표, 테스트 베이시스, 테스트 대상, 주로 발견되는 장애와 결함의 종류, 테스트 수행 주체 등과 같은 항목은 각 테스트 레벨의 특징에 맞게 다르게 정의 되고 식별되어야 한다. 

 

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

단위 테스팅이라고도 불리는 컴포넌트 테스팅은 테스트가 가능한 (최소)단위로 나누어진 소프트웨어 내에서 결함을 찾고 그 기능을 검증하는 것이다. 스텁과 드라이버, 시뮬레이터 등이 필요 할 수 있다. 

 

구조적인 테스팅(분기 커버리지 등)은 물론 기능성 테스트와 리소스 관련(메모리 유출) 테스팅 또는 강건성(Robustness) 테스팅과 같은 특정 비기능 테스팅을 포함한다. 

 

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

 

코드를 중심으로 수행하며, 단위 테스트 프레임워크 또는 디버깅 툴 같은 개발 환경의 지원을 필요로 한다. 실무에서는 보통 코드를 작성한 프로그래머가 직접 테스트에 참여하며, 결함을 발견할 때마다 바로 수정하고, 결함에 대한 기록 과정은 생략하는 것이 일반적이다. 그러나 테스트 프로세스 관리와 개선을 위해 테스트에서 발견되는 결함에 대한 통계적인 데이터가 필요한 경우에는 인시던트(또는 결함) 기록 과정이 있어야 한다. 

 

<컴포넌트 테스팅의 일반적인 목적>

- 기본 경로(Path) 확인

- 모든 오류 처리 경로(Error handling path)를 확인

- 컴포넌트 내의 인터페이스 확인

- 로컬 데이터 확인, 경계값 확인

 

컴포넌트 테스팅의 접근법 중에는 코딩 전에 TC를 준비하고 자동화하는 방법이 있다. 이것이 테스트 중심 개발 방법론이다. 

 

2.2.2 통합 테스팅 ( Integration testing ) 

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

 

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

 

상향식, 하향식, 백본통합과 같은 순차적이고 체계적인 통합 전략이 한 번에 통합하는 빅뱅 전략보다 리스크를 줄이는데 효과적이다. 

 

기능적 특성은 물론 비기능적 특성(성능, 연결성 등)을 테스팅 해야 한다. 

 

2.2.3 시스템 테스팅 ( System testing )

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

- 기능 및 비기능 요구 사항을 모두 검증해야 한다. 

- 요구 사항은 텍스트나 모델의 형태로 존재하는데 테스트 엔지니어는 불완전하거나 문서 형태를 갖추지 못한 요구사항을 기반으로 테스트하게 되는 경우도 고려해야 한다. 

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

- 실무에서는 시스템 테스팅과 인수 테스팅 사이에 출시 여부를 결정하기 위한 일종의 검수 테스팅이 존재하는 경우가 있다.

 

2.2.4 인수 테스팅 ( Acceptance testing )

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

 

인수테스팅의 목적 : 시스템이나 시스템 일부 또는 특정한 비기능적인 특성에 대해 확신을 얻는 것이다. 

결함을 찾는 것이 주된 관심사가 아니다. 

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

반드시 최종 테스팅이라고 보기는 어렵다.

 

< 인수 테스팅의 형태 >

- 사용자 인수 테스팅

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

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

- 알파 테스팅과 베타 (또는 필드) 테스팅

 

2.3 테스트 유형

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

 

2.3.1 기능 테스팅 ( Functional testing )

문서화 되어 있거나 테스터가 알고 있는 기능과 특징, 그리고 그것들과 특별한 시스템과의 상호 운용성을 고려하여 수행하며 모든 테스트 레벨에서 수행될 수 있다. 

예를 들어, 컴포넌트 테스트 레벨에서의 기능 테스팅은 컴포넌트 명세를 기반으로 한다. 

 

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

 

- 보안성 테스팅은 악의적인 코드와 같은 외부로부터 위협을 감지해 내는 것과 관련이 있는 기능(방화벽)을 확인한다. 

 

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

성능 테스팅, 부하 테스팅, 스트레스 테스팅, 사용성 테스팅, 유지보수성 테스팅, 신뢰성 테스팅, 이동성 테스팅 등을 포함한다.

이는 소프트웨어 제품 특성 테스팅이라고도 하며, 시스템이 "어떻게" 동작 하는가를 테스팅한다.

 

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

- 다양한 척도 또는 비율로 정량화 가능한 소프트웨어나 시스템의 특성을 측정하는 테스트를 의미한다.

- 신뢰성, 사용성, 효율성, 유지보수성, 이식성이라는 품질 특성으로 분류 할 수 있다.

 

2.3.3 구조적 테스팅 ( Structual testing )

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

 

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

- 모든 테스트 레벨에서 수행이 가능하다. 

 

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

결함을 수정하기 위한 디버깅(debugging)은 개발 활동이며 테스팅 활동으로 보지 않는다.

리그레션 테스팅은 이미 테스트된 프로그램의 테스팅을 반복하는 것으로, 결함 수정 이후 변경의 결과로 새롭게 만들어 지거나, 이전 결합으로 인해 발견되지 않았던 또 다른 결함을 발견하는 것이다. 

 

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

- 기능, 비기능, 구조적 테스팅에 적용할 수 있다. 

 

2.4 유지보수 테스팅 ( Maintenance testing )

이미 운영되고 있는 시스템에서 수행되며, 소프트웨어나 시스템이 변경, 단종 되었거나 마이그레이션이 될 때 발생한다.  

변경(Modification)은 (릴리즈 기반으로) 계획된 개선 활동에 의한 변경, 요구 사항 변경에 의한 수정과 긴급 변경, 환경의 변경 등이 존재한다. 이러한 변경에는 계획된 OS 또는 DB 업그레이드, OS의 새로 드러난 취약점 패치 등이 있을 수 있다.

 

- 기존 시스템이 어떻게 영향을 받는지 결정하는 것이 영향도 분석이며, 얼마나 많은 리그레션 테스팅을 수행할지 결정하는데 이용된다.

- 명세가 오래 되었거나, 없다면 명세서를 근간으로 수행하기는 어려울 수 있다.

 

 

💁🏻‍♂️ 2장 느낀점  

서로 다른 테스트 레벨(컴포넌트, 통합, 시스템, 인수 테스팅)이 필요한 이유와 선택된 개발 생명주기 모델에 적합한 테스트 접근법과 각각의 테스팅의 특징을 조금 더 자세히 알게 되었음.