개발자도 알아야 할 소프트웨어 테스팅 실무 요약2

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

2.1 sw 개발 모델

2.1.1 v 모델

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

 

v 모델에서 제시하는 테스트 레벨 

컴포넌트 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅

각 레벨은 서로 독립적이어서 각각 다른 테스트 계획과 전략을 필요로 하고 수행 주체가 다르고 적용하는 테스트 기법의 종류와 형태가 상당 부분 다르며 별도의 보고를 필요로 한다.

 

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

 

sw 개발 기간 중의 개발 산출물(work products) 비즈니스 시나리오 또는 유즈케이스, 요구사항 명세, 설계 문서나 코드 는 하나 또는 그 이상의 테스트 레벨에서 테스트 베이시스가 된다.

 

베리피케이션(verification)

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

주로 인스펙션과 같은 리뷰 활동을 통해서 검증하지만 테스트 레벨의 목적에 맞는 동적 테스팅을 통해서도 검증할 수 있다.

 

밸리데이션 (validation)

정적, 동적 모두 검증 가능하다.

 

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

짧게 연속적으로 반복(iteration)하는 활동으로 이루어진다.

초기 반복 단계에서 리스크가 높은 모듈이나 주요 아키텍처에 해당하는 시스템 일부를 우선적으로 개발하고 테스팅을 통해 결함이나 장애를 조기에 발견하고 제거할 수 있는 기회를 확보한다.

 

반복적으로 개발하는 모델의 예는 애자일 개발 모델, RUP(Rational unified process), RAD(Rapid application development), 이해관계자 중심의 sw 개발 (outside-in sw development), 프로토 타이핑(prototyping)

 

애자일한 테스팅은 테스트를 미리 설계하지 않을 수 있으며, 누구나 테스트에 적극 참여할 수 있다. 문서를 최소화하며 결함을 최대한 빨리 발견하도록 해준다. 개발완료는 테스트 완료를 의미한다. 즉 개발과 테스트가 같이 시작되고 때로는 테스트가 먼저 시작된다. 

 

 

2.1.3 개발 수명주기 모델에서 테스팅

 

2.2 테스트 레벨

2.2.1 컴포넌트 테스팅

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

 

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

 

tc는 컴포넌트 명세서, sw 상세 설계 또는 데이터 모델과 같은 개발 산출물에서 도출한다.

 

컴포넌트 테스팅의 목적

기본 경로 path 를 확인, 모든 오류 처리 경로 error handling path 를 확인

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

로컬 데이터 확인, 경곗값 확인

 

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

테스트 중심 개발 방법론(test driven development, test-first approach) 이다. 

 

2.2.2 통합 테스팅(integration testing)

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

 

하나 이상의 테스트 레벨이 있을 수 있으며, 대상에 대해 수행된다.

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

 

2.2.3 시스템 테스팅

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

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

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

 

독립적인 팀이 수행하는 경우가 대부분

검수 테스팅이 존재하는 경우가 있다.

 

2.2.4 인수 테스팅

시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 확인(confidence)를 얻는 것이다. 

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

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

 

사용자 인수 테스팅

운영상의 인수 테스팅

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

 

알파 테스팅과 베타 테스팅

시장에서 판매 또는 상용 COTS SW 개발자는 종종 SW가 상업적으로 판매되기 전에 목표 시장의 기존 고객이나 잠재 고객으로부터 피드백을 받고 싶어한다. 

알파 테스팅은 개발 조직 내에서 고객에 의해 수행된다.

베타 테스팅 또는 필드 테스팅은 실제 환경에서 사용자 혹은 잠재 고객에 의해 수행된다.

 

2.3 테스트 유형

2.3.1 기능 테스팅 Functional testing

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

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

 

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

 

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

시스템으로 침투하는 보호되지 않는 진입점(트랩도어)파악

 

2.3.2 비기능 테스팅

성능, 부하, 스트레스, 사용성, 유지보수성, 신뢰성, 이동성(portability) 테스팅 등을 포함하는 개념이다. 

이는 sw 제품 특성 테스팅(testing of sw product characteristics)이라고도 하며, 시스템이 어떻게 동작하는지 테스팅한다.

 

모든 레벨에서 수행되며, 다양한 척도/비율(scale)로 정량화 가능한 sw나 시스템의 특성(characteristics)을 측정하는 테스트를 의미한다. 

 

비기능성을 신뢰성, 사용성, 효율성, 유지보수성, 이식성 품질 특정(quality characteristics)으로 분류하고 각 품질 특성을 3~5가지의 품질 부특성으로 세분화한다. 

 

2.3.4 확인/리그레션 테스팅(confirmation (retesting) and regression testing)

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

 

보다 상세하고 철저하게(intensive and higher-depth) 수행한다.

모든 테스틀 레벨에서 수행할 수 있으며 기능, 비기능 그리고 구조적 테스팅에 적용할 수 있다. 

부가 기능 (contributing functions)

 

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

변경 modification 은 계획된 개선 활동에 의한 변경, 요구사항 변경에 의한 수정과 긴급 변경, 환경의 변경 등이 존재한다. 계획된 os, 또는 db 업그레이드, os의 새로 드러난 취약점 패치 등이 있을 수 있다. 

 

영향도 분석(impact analysis) 을 하며 얼마나 많은 리그레션 테스팅을 수행할지 결정하는데 이용된다. 

명세(specification) 오래 되면 명세서를 근간으로 수행해 어려울 수 있다.