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

2.1 소프트웨어 개발 모델

1. V-모델(순차적 개발 모델)
요구사항 정의 및 분석 > 시스템 설계 > 구현 > 테스팅 단계
소프트웨어 생명 주기를 모형화한 것으로, Waterfall model에 근간을 둠
구현에는 유닛 테스트(컴포넌트), 디자인은 통합 테스트, 분석에는 시스템 테스트, 요구사항에는 인수 테스트
그러나 반드시 일대일 대응되는 것은 아니다.

2. 반복적-점증적(Iterative-incremental) 개발 모델
요구사항 분석, 시스템 설계, 구현 및 테스팅하는 개발 주기가 짧고 연속적으로 반복되는 활동
초기 리스크가 높은 모듈이나 아키텍처를 우선 개발하고 테스팅하므로 개발 리스크를 조기에 감소시킴
애자일 모델, RUP(Rational Unified Process), RAD(Rapid Application Development), 프로토타이핑, 이해관계자 중심의 소프트웨어 개발

* 애자일 테스팅(Agile testing)
 - 테스트를 미리 설계하지 않을 수 있다. 누구나 테스트에 참여할 수 있다.
 - 결함을 최대한 빨리 발견할 수 있다. 요구사항을 개발함과 동시에 결함을 발견
 - 애자일 테스팅은 문서를 최소화한다.
 - 개발완료는 테스트 완료를 의미한다.

3. 개발 수명주기(Life Cycle)모델에서의 테스팅
 - 모든 개발 활동은 이에 상응하는 테스팅 활동을 동반
 - 각 테스트 레벨은 그 레벨에 맞는 특정한 목적이 있다.
 - 주어진 테스트 레벨에 맞는 분석과 설계는 대응되는 개발 활동 동안에 시작되어야 한다.
 - 개발 수명주기 동안 개발 산출물의 초안이 작성되면, 이를 리뷰하는 활동에 참여한다.
 - 각 테스트 레벨은 프로젝트나 아키텍처의 성격에 따라 재조정되거나 합쳐질 수 있다.

 

2.2 테스트 레벨 

각각의 테스트 레벨은 서로 독립적이며 종속성을 지니기 때문에 각 레벨별 종료 및 시작 조건을 갖추어야 한다.
개발 초기 테스트는 개발 산출물을 리뷰 형태로 검토하며 결함을 발견하는 것으로 정적 테스팅을 의미함
 - 후반부에서 발생할 테스팅 비용과 시간을 줄일 수 있으며 결함을 사전 예방
베리피케이션 : 개발 단계의 산출물이 그 단계의 초기 설정된 조건을 만족하는지를 확인(리뷰, 인스펙션)
벨리데이션 : 개발 중, 또는 개발단계 말에 사용자의 관점에서 요구사항들을 만족하는지 확인

[컴포넌트 테스팅] - (Component/Unit testing)
 - 테스트가 가능한 최소 단위로 나누어진 SW내에서 결함을 찾고 기능을 점검하는 것
 - 주로 구조 기반(White-box)테스팅 방법을 사용함
  > 제어흐름(control flow)테스팅, 조건/결정 커버리지 테스팅, 최소비교 테스팅 등
 - 테스트 베이시스 : 컴포넌트 명세서, SW 상세 설계, 코드 등
 - 프로그래머가 함께 참여하여 결함을 발견할 때마다 수정하고, 기록을 생략하는 것이 일반적

[통합 테스팅] - (Integration testing)
 - 컴포넌트간의 인터페이스, OS, 파일 시스템, 각기 다른 부분과의 상호 연동 등을 테스트
 - 상향식, 하향식, 백본 통합과 같은 방법이 빅뱅 전략보다 리스크를 줄이는데에 효과적이다.
 - 백본(Backbone) : 중요하고 리스크가 높은 모듈로 초기 통합, 결합 격리가 쉽고 초기 발견 가능, 테스트 시간이 오래걸림
 - 빅뱅(Big bang) : 모든 모듈을 동시에 통합, 단시간 테스트가 가능하나 결함 격리가 어려움
 - 상향식(Bottom up) : 가장 하부의 모듈부터 통합, 결함 격리가 쉬움, 수정이 어려운 결함을 상부에서 발견할 수 있음, 비스니스 로직의 반영이 어려움
 - 하향식(Top down) : 가장 상부의 모듈부터 통합, 결함 격리가 쉬움, 설계상의 결함을 빠르게 발견, 수정이 어려운 결함을 하부에서 발견할 수 있음 ex) 디자인적인 결함을 가진 DB
통합 테스팅은 기능적 특성은 물론 성능, 연결성 등의 비기능적 특성까지도 테스트해야하며 기능적, 구조적 접근법을 모두 사용

[시스템 테스팅] - (System testing)
개발 프로젝트 차원에서 정의된 전체 시스템 또는 동작을 테스트, 명세기반(블랙박스) 기법을 사용
환경특성장애 리스크를 최소화하기 위해 최종 사용환경과 유사하게 수행해야한다.
독립적인 테스트팀이 수행하는 경우가 대부분

[인수 테스팅] - (Acceptance testing)
고객이나 사용자가 전담하여 수행하는 경우가 대부분
시스템이나 비기능적 특성에 대해 확신(confidence)를 얻기 위함이며, 결함을 찾는 것이 주목적이 아니다.
사용자 인수 테스팅 : 비즈니스 사용자가 시스템 사용의 적절성을 확인
운영상의 (인수)테스팅 : 시스템 관리자에 의해 백업/복원, 재난 복구, 사용자 관리, 유지보수, 보안 등을 테스트
계약 인수 테스팅과 규정 인수 테스팅 : 계약상의 인수 통과 조건을 준수하는지, 법률 또는 지침에 맞게 개발되었는지 확인
알파 테스팅 : 개발 조직내에서 고객에 의해 테스팅
베타 테스팅 : 실제 고객의 환경에서 사용자, 혹은 잠재 고객에 의해 테스팅

2.3 테스트 유형

1. 기능 테스팅(Functional testing)
시스템이 수행해야하는 모든 기능을 테스트
문서화되어 있거나 테스터가 알고 있는 특징, 또한 그것들과 시스템의 상호 연동을 고려, 모든 테스트 레벨에서 수행될 수 있음
명세 기반 기법(블랙박스)을 이용하여 SW나 시스템의 테스트 조건과 케이스를 도출하고, SW의 외부적인 행동을 고려한다.
보안성 테스팅 : 보안정책, 트랩도어, 가용성, 무결성, 기밀성, 부인방지 등의 보안성을 평가
상호운용성 테스팅 : 컴포넌트나 시스템이 서로 상호 작용하는 SW의 능력을 평가

2. 비기능 테스팅(Non-functional testing)
모든 테스트레벨에서 수행될 수 있다.
다양한 척도 또는 비율로 정량화 할 수 있는 SW나 시스템의 특성을 측정
신뢰성/사용성/효율성/유지보수성/이식성/성능/부하/스트레스/이동성 등을 테스트

3. 구조적 테스팅(Structural testing)
특정 유형에 대한 커버리지를 평가하여 테스팅의 보장성 또는 충분함을 평가
**커버리지란 : 시스템 또는 SW의 구조가 테스트 수트(Test suit)에 의해 테스트된 정도, 퍼센테이지로 표기함
모든 테스트레벨에서 수행할 수 있다.
커버리지를 높이기 위해 구조적 테스트기법(화이트 박스)을 적용할 수 있다.
툴을 사용하여 코드의 구문 또는 결정문과 같은 커버리지 측정
시스템, 통합, 또는 인수 테스팅의 레벨에서 비즈니즈 모델이나 구조도를 사용하여 구조적 테스트 설계를 통해 수행 가능

4. 확인/리그레션 테스팅(Confurmation and regression testing)
결함이 수정된 이후 성공적으로 제거되었는지 확인하기 위한 활동
디버깅은 결함을 수정하는 개발활동이기에 테스트 활동으로 보지 않는다.
이미 테스트된 SW의 테스팅을 반복하는 것으로, 결함 수정 이후 새롭게 발생했거나, 발견되지 않았던 또다른 결함을 발견하는 것
이전에 정상 동작했던 SW에서 결함을 발견하지 못해 야기될 수 있는 리스크에 바탕을 둔다.
모든 테스트레벨에서 수행할 수 있으며 반복적인  성향을 띈다. 자동화 대상으로 고려

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

릴리즈 이후, SW나 시스템이 변경, 단종되었거나 마이그레이션 될 때 발생
변경된 부분에 대한 테스팅 외에도 변경되지 않는 요소의 리그레션 테스트도 고려해야 한다.
유지보수 테스팅의 범위 : 변경 사항의 리스크 및 크기, 기존 시스템의 크기를 고려
변경으로 인해 기존 시스템에 주는 영향을 고려(영향도 분석)하여 테스팅 양을 결정
명세가 오래되었거나 없는 경우 수행이 어려울 수 있다.