2015, 봄

게임콘텐츠스쿨이종원 교수

ISTQB-2

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

학습내용v 소프트웨어 개발 수명주기란?v 수명주기와 테스팅의 관계v 테스트 레벨v 테스트 유형

수명주기모든 소프트웨어 개발은 초기 기획에서 사용자가 사용을

하기까지 수명주기(Lifecycle)을 가지고 있다.

초기 컨셉 완성품

수명주기

수명주기 모델[1]

이 부분을 어떻게 할 것인가에 따라다양한 수명주기 모델이 있다.

초기 컨셉요구분석

명세 설계

구현(코딩)테스트

완성품

?

수명주기 모델[2]v 개발하는 제품의 특성을 고려하여 어떤 수명주기 모델을 적

용하느냐에 따라 프로젝트의 성공에 영향을 준다.v 수명주기 모델에 따라 QA활동도 달라진다.v 즉, 수명주기 모델이 해당 프로젝트의 활동기준을 제시한다

고 할 수 있다.

프로젝트의 개발속도, 품질, 진행의 추적 및 관리,

부수적인 활동 또는 비용, 위험, 사용자와의 관계 등을

향상시킬 수 있다.

개발 속도 저하 및불필요한 작업을증가시킬 수 있다.

적절한 수명주기 모델 선택 부적절한 수명주기 모델 선택

폭포수 수명주기 모델[1]v 수명주기 모델의 조상

– 문제점이 많은 모델이지만, 단순한 구조여서 수명주기 모델의 개념을 이해하는데 적합

요구분석(Requirements)

명세(Specification)

설계(Design)

구현(Coding)

테스트

폭포수 수명주기 모델[2]v 폭포수 모델의 특징

– 초기 계획부터 통합테스트까지 단계별로 구성– 각 단계 말에 그 단계의 결과를 점검

• 해당 단계에 문제가 있으면 다음 단계로 가지 못함– 문서화에 중점

• 각 단계의 결과물(문서)이 다음 단계로 전달– 순수 폭포수 모델에서는 단계의 중복이 없음

• 즉, 요구분석 단계가 끝나면 나중에 다시 요구분석을하는 단계는 없다.

• 개량형 폭포수 모델은 앞단계로 되돌아가는 방법 도입

폭포수 수명주기 모델[3]v 장점

– 단계가 명확하여 에러를 초기에 발견하게 해준다– 개발자에게 필요한 명확한 작업을 제공할 수 있다.– 복잡함을 단계별로 나누어 진행할 수 있기 때문에 제품

에 대한 이해도가 높으면서 복잡한 프로젝트에 용이하다.

v 단점– 빠른 개발을 해야 하는 상황 또는 잦은 변경이 필요한 상

황에는 적합하지 않다.

V 모델[1]

요구분석

명세

설계

코딩

인수테스트

시스템테스트

통합테스트

단위테스트

개발단계에 따라테스팅 계획 및 설계

개발활동개발활동

테스트활동

테스트활동

반드시 일대일대응은 아님

각 단계별로 나와야하는 산출물이 정의되어 있다

V 모델[2]v V-모델에서 제시하는 테스트 레벨

– 테스트 레벨은 개발 단계와 대응하는 단위테스트, 통합테스트, 시스템 테스트, 인수테스트를 의미함

– 각 레벨에 따라 테스트 전략, 테스트 기법, 테스트 수행주체, 테스트 완료기준 등이 달라짐

– 각 테스트 레벨은 서로 독립적임

V 모델[3]v 개발 초기부터 수행하는 테스트

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

– 개발 초기의 테스팅을 통해 개발 후반부에서 발생할 테스팅 비용을 줄일 수 있음

– 소프트웨어의 결함을 사전에 예방하는 효과

여기서 잠깐!!!Validation(확인)과 Verification(검증) : V&V1. Validationv 목적 : Are we building the RIGHT product? (올바른 제품

을 만들고 있는가?)v 실제 고객의 요구사항과 분석가가 분석한 내용이 일치하는

지 확인하는 것v 오류가 있는 설계를 가지고 개발자가 열심히 개발해봐야 나

중에 고객은 “이것이 아니다”라고 하면? v Validation이 다 되었으면 “Complete”하다고 한다.v Complete : including all parts, details, facts etc and with

nothing missing (고객의 요구에서 빠진 요소가 없이 모든것을 포함)

여기서 잠깐!!!2. Verificationv 목적 : Are we building the product RIGHT?(제품을 올바르

게 만들고 있는가?)v 제품이 설계에 맞게 만들어지고 있는지를 검사하는 절차

– 해당 단계의 초기에 설정한대로 만들고 있는지v Verification이 다 되었으면 “Correct”하다고 한다.v Correct : If something is correct, it is in accordance with

the facts and has no mistakes. (설계(fact)대로 실수없이 구현하고 있다)

반복적-점증적 개발모델v 반복적-점증적 개발 모델은 폭포수 모델과 달리, 요구분석,

시스템 설계, 구현 및 구현 및 테스팅하는 개발 주기가 짧게연속적으로 반복하는 활동으로 이루어짐

v 특징– 초기 반복단계에서 리스크가 높은 모듈이나 핵심 시스템

에 해당하는 부분을 우선적으로 개발하고– 테스팅을 통해 결함이나 장애를 조기에 발견하고 제거할

수 있는 기회를 확보하기 때문에 개발 리스크를 조기에감소시킬 수 있음

v 주요 모델– 애자일 개발모델– RUP, RAD– 프로토타이핑

여기서 잠깐!!!애자일 테스팅의 특징v 테스트를 미리 설계하지 않을 수 있으며, 누구나 테스트에

적극 참여할 수 있다.(개발자, 사용자, 테스터)v 애자일 테스팅은 결함을 최대한 빨리 발견하도록 해준다. 요

구사항을 개발함과 동시에 결함을 발견할 수 있다.v 애자일 테스팅은 문서를 최소화한다.v 개발완료는 테스트 완료를 의미한다. 즉 개발과 테스트가 같

이 시작되고 때로는 테스트가 먼저 시작된다.

개발수명주기와테스팅v 모든 개발활동은 이에 상응하는 테스팅 활동을 동반함v 각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가짐v 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되

는 개발 활동 동안에 시작되어야함v 개발 수명주기 동안에 개발 산출물의 초안이 작성되면, 테스

터는 이러한 문서를 리뷰하는 활동에 참가해야함

테스트 레벨에 따른 정의v 해당 테스트 레벨의 일반적인 목적이나 목표v 테스트 케이스를 도출하는데 참조되는 개발 산출물(테스트

베이시스)v 테스트 대상v 발견된 전형적인 결함과 장애v 테스트 드라이버/스텁이나 도구의 필요성v 상세한 테스트 접근법v 테스트 수행 주체 또는 조직

테스트 레벨-단위 테스팅[1]v 컴포넌트(component) 테스트, 유닛(unit) 테스트, 모듈테스

트라고도 함v 가능한 최소 단위로 나누어진 소프트웨어(모듈, 프로그램,

클래스 등)내에서 결함을 찾고, 해당 단위의 기능을 검증함v 해당 모듈을 테스트 하기 위해 테스트 드라이버나 스텁이

필요할 수 있음v 단위 테스트에는 기능성 테스트 외에 비기능(메모리 관리

등) 테스트도 포함함v 보통 단위 테스트는 코드를 중심으로 수행하며, 해당 코드를

작성한 프로그래머가 직접 테스트하여 수정하고 결함에 대한 기록은 생략하는 것이 일반적임

테스트 레벨-단위 테스팅[2]v 단위 테스트의 일반적인 목적

– 기본 경로를 확인– 모든 오류 처리 경로를 확인– 컴포넌트 내의 인터페이스 확인– 로컬 데이터 확인, 경계값 확인

테스트 레벨-통합 테스팅[1]v 테스트 대상

– 컴포넌트 간의 인터페이스 테스트– 시스템의 각기 다른 부분과 상호 연동하는 동작 테스트

• 운영체제, 파일 시스템, 하드웨어 또는 시스템 사이의인터페이스 등

v 통합테스팅의 두 종류– 컴포넌트 통합 테스팅 : 소프트웨어 컴포넌트 사이의 상

호작용을 테스트– 시스템 통합 테스팅 : 시스템 사이의 상호작용을 테스트

테스트 레벨-통합 테스팅[2]v 통합 테스트 접근법

백본

(Backbone)

빅뱅

(Big bang)

상향식

(Bottom up)

하향식

(Top down)

방법

가장 중요하고 리

스크가 높은 모듈

부터 통합

모든 모듈을 한번

에 통합

가장 하부 모듈부

터 통합

가장 상부 모듈부

터 통합

드라이버/

스텁

필요에 따라 만들

어 사용

불필요

실제모듈통합드라이버 필요 스텁 필요

장점

결함 격리쉬움

리스크가 높은 결

함을 초기발견

단시간 테스트

결함격리쉬움

하위모듈을

충분히 테스트

결함격리쉬움

설계상의 결함

을 빨리 발견

단점테스트 시간이 오

래 걸릴 수 있음결함격리어려움

수정이 어려운 중

요한 결함을 상부

구조에서 발견가능

수정이 어려운 중

요한 결함을 하부

에서 발견 가능

테스트 레벨-시스템 테스팅v 프로젝트 차원에서 정의된 전체 시스템 또는 제품의 동작에

대해 테스트 수행v 가능한 범위에서 실제 최종 사용 환경 또는 이와 유사한 환

경에서 수행해야 함v 시스템 테스팅은 기능 및 비기능 요구사항을 모두 검증함

– 기능적 요구사항 : 테스트 대상의 특성을 기술한 문서를기반으로 테스트 설계

– 비기능적 요구사항 : 성능테스트, 가용성 테스트, 보안성테스트 등

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

테스트 레벨-인수 테스팅[1]v 인수 테스팅의 목적은 시스템이나 시스템의 일부 또는 특정

한 비기능적인 특성에 대해 “확신”을 얻는 것임v 인수 테스팅은 시스템을 배포하거나 실제 사용할만한 준비

가 되어있는지에 대해 평가함

v 시스템을 사용하는 고객이나 사용자가 전담하여 수행

테스트 레벨-인수 테스팅[2]v 인수 테스팅의 다양한 형태

– 사용자 인수 테스팅: 사용자가 시스템사용의 적절성 확인– 운영상의 인수 테스팅: 시스템 관리자에 의한 테스팅– 계약 인수테스팅과 규정 인수 테스팅: 주어진 계약이나

규정 부합 여부 확인– 알파 테스팅과 베타(필드)테스팅

• 알파 테스팅 : 개발 조직내에서 고객이 수행• 베타 테스팅 : 실제 환경에서 사용자 혹은 잠재 고객에

의해 수행• 공장인수 테스팅=알파 테스팅, 사이트인수 테스팅=베

타 테스팅

테스트 유형v 테스트 유형이란 테스트하는 목적 및 품질 특성(신뢰성, 유

지보수성 등)을 확인하기 위해 소프트웨어 시스템을 검증하는 테스트 활동– 소프트웨어가 수행하는 기능에 대한 테스팅– 호환성, 신뢰성, 사용성과 같은 비기능적인 품질특성 테

스팅– 소프트웨어나 시스템의 구조에 대한 테스팅– 변경 내용에 관련된 테스팅

• 확인 테스팅(재테스팅) : 결함에 대한 수정이 이루어졌는지 확인하는 테스팅

• 리그레션 테스팅(회귀 테스팅) : 결함의 수정으로 다른부분에 의도하지 않았던 결함이 발생하지는 않는지 확인하는 테스팅

테스트 유형 – 기능 테스팅v 기능 : 시스템이 수행하는 그 “무엇”을 의미

– 문서화되어 있거나– 테스터가 알고 있는 기능과 특징을 테스트

v 명세기반기법을 이용해 소프트웨어나 시스템의 기능에서 테스트 조건과 테스트 케이스를 도출하고 소프트웨어의 외부적인 행동을 고려함(블랙박스 테스팅)

v ISO/IEC 9126에서 기능성의 부특성– 적합성, 정확성, 준수성, 상호운용성, 보안성

테스트 유형 – 비기능 테스팅v 비기능테스팅

– 시스템이 “어떻게” 동작하는가를 테스팅v 비기능테스팅의 종류

– 성능 테스팅– 부하 테스팅/스트레스 테스팅– 사용성 테스팅– 유지보수성 테스팅– 신뢰성 테스팅– 이식성 테스팅 등을 포함

v ISO/IEC 9126의 비기능성 품질특성– 신뢰성, 사용성, 효율성, 유지보수성, 이식성

테스트 유형 – 구조적 테스팅v 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보

장성 또는 충분함을 측정하는 것이 목적임

v 커버리지 : 시스템 또는 소프트웨어의 구조가 테스트 케이스에 의해 테스트된 정도를 말하며 커버된 퍼센트로 표시함– 커버리지는 4장에서 자세하게 다룸

테스트 유형 – 확인/재 테스팅v 확인(재) 테스팅(Confirmation/Re Testing)

– 결함이 발견되고 수정한 후에 원래의 결함이 성공적으로제거되었는지 확인하는 테스트

– 결함의 원인을 찾거나 결함을 수정하기 위한 디버깅은개발활동이며 테스트 활동으로 보지 않음

테스트 유형 – 확인/재 테스팅

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

견하는 테스팅

유지보수 테스팅v 이미 사용되고 운영되고 있는 시스템에서 수행하는 테스트v 소프트웨어나 시스템이 변경, 단종되었거나 마이그레이션될

때 발생함– 변경 : 계획된 개선 활동에 의한 변경, 요구사항 변경에

의한 수정, 환경의 변경, OS 또는 DB 업그레이드, OS 패치 등의 변경

– 마이그레이션 : 한 플랫폼에서 다른 플랫폼으로 옮겨가는마이그레이션을 위한 테스팅으로 새로운 환경에서의 운영 테스트도 포함

– 시스템 단종에 의한 유지보수 테스팅은 데이터를 마이그레이션하는 테스팅을 포함할 수 있으며, 데이터 저장 관련 사항도 테스트 해야 함

상위레벨- 고객- 독립적 테스터

인수테스트

시스템테스트

통합테스트

단위테스트

하위레벨- 주로 개발자가

- 베타(실제환경,고객)- 알파(개발조직내,고객)

- 시스템통합테스트- 컴포넌트통합테스트

테스트 레벨

기능테스팅비기능테스팅구조적테스팅

확인테스팅리그레션테스팅

테스트 유형

2장 요약