소프트웨어테스팅 2장 강의노트

1. 2015, 봄
게임콘텐츠스쿨
이종원 교수
ISTQB-2
소프트웨어 수명주기와
테스팅

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

3. 수명주기
모든 소프트웨어 개발은 초기 기획에서 사용자가 사용을
하기까지 수명주기(Lifecycle)을 가지고 있다.
초기 컨셉 완성품
수명주기

4. 수명주기 모델[1]
이 부분을 어떻게 할 것인가에 따라
다양한 수명주기 모델이 있다.
초기 컨셉
요구분석
명세 설계
구현(코딩)
테스트
완성품
?

5. 수명주기 모델[2]
v 개발하는 제품의 특성을 고려하여 어떤 수명주기 모델을 적
용하느냐에 따라 프로젝트의 성공에 영향을 준다.
v 수명주기 모델에 따라 QA활동도 달라진다.
v 즉, 수명주기 모델이 해당 프로젝트의 활동기준을 제시한다
고 할 수 있다.
프로젝트의 개발속도, 품질,
진행의 추적 및 관리,
부수적인 활동 또는 비용,
위험, 사용자와의 관계 등을
향상시킬 수 있다.
개발 속도 저하 및
불필요한 작업을
증가시킬 수 있다.
적절한 수명주기 모델 선택 부적절한 수명주기 모델 선택

6. 폭포수 수명주기 모델[1]
v 수명주기 모델의 조상
– 문제점이 많은 모델이지만, 단순한 구조여서 수명주기 모
델의 개념을 이해하는데 적합
요구분석
(Requirements)
명세(Specification)
설계(Design)
구현(Coding)
테스트

7. 폭포수 수명주기 모델[2]
v 폭포수 모델의 특징
– 초기 계획부터 통합테스트까지 단계별로 구성
– 각 단계 말에 그 단계의 결과를 점검
• 해당 단계에 문제가 있으면 다음 단계로 가지 못함
– 문서화에 중점
• 각 단계의 결과물(문서)이 다음 단계로 전달
– 순수 폭포수 모델에서는 단계의 중복이 없음
• 즉, 요구분석 단계가 끝나면 나중에 다시 요구분석을
하는 단계는 없다.
• 개량형 폭포수 모델은 앞단계로 되돌아가는 방법 도입

8. 폭포수 수명주기 모델[3]
v 장점
– 단계가 명확하여 에러를 초기에 발견하게 해준다
– 개발자에게 필요한 명확한 작업을 제공할 수 있다.
– 복잡함을 단계별로 나누어 진행할 수 있기 때문에 제품
에 대한 이해도가 높으면서 복잡한 프로젝트에 용이하다.
v 단점
– 빠른 개발을 해야 하는 상황 또는 잦은 변경이 필요한 상
황에는 적합하지 않다.

9. V 모델[1]
요구분석
명세
설계
코딩
인수테스트
시스템테스트
통합테스트
단위테스트
개발단계에 따라
테스팅 계획 및 설계
개발
활동
개발
활동
테스트
활동
테스트
활동
반드시 일대일
대응은 아님
각 단계별로 나와야하는 산출물이 정의되어 있다

10. V 모델[2]
v V-모델에서 제시하는 테스트 레벨
– 테스트 레벨은 개발 단계와 대응하는 단위테스트, 통합테
스트, 시스템 테스트, 인수테스트를 의미함
– 각 레벨에 따라 테스트 전략, 테스트 기법, 테스트 수행주
체, 테스트 완료기준 등이 달라짐
– 각 테스트 레벨은 서로 독립적임

11. V 모델[3]
v 개발 초기부터 수행하는 테스트
– 개발 초기에 테스팅을 수행한다는 것은 개발 산출물(테스
트 베이시스)을 리뷰 형태로 검토하면서 결함을 발견하는
정적테스팅을 의미함
– 개발 초기의 테스팅을 통해 개발 후반부에서 발생할 테
스팅 비용을 줄일 수 있음
– 소프트웨어의 결함을 사전에 예방하는 효과

12. 여기서 잠깐!!!
Validation(확인)과 Verification(검증) : V&V
1. Validation
v 목적 : Are we building the RIGHT product? (올바른 제품
을 만들고 있는가?)
v 실제 고객의 요구사항과 분석가가 분석한 내용이 일치하는
지 확인하는 것
v 오류가 있는 설계를 가지고 개발자가 열심히 개발해봐야 나
중에 고객은 “이것이 아니다”라고 하면?
v Validation이 다 되었으면 “Complete”하다고 한다.
v Complete : including all parts, details, facts etc and with
nothing missing (고객의 요구에서 빠진 요소가 없이 모든
것을 포함)

13. 여기서 잠깐!!!
2. Verification
v 목적 : 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)대로 실수없이 구
현하고 있다)

14. 반복적-점증적 개발모델
v 반복적-점증적 개발 모델은 폭포수 모델과 달리, 요구분석,
시스템 설계, 구현 및 구현 및 테스팅하는 개발 주기가 짧게
연속적으로 반복하는 활동으로 이루어짐
v 특징
– 초기 반복단계에서 리스크가 높은 모듈이나 핵심 시스템
에 해당하는 부분을 우선적으로 개발하고
– 테스팅을 통해 결함이나 장애를 조기에 발견하고 제거할
수 있는 기회를 확보하기 때문에 개발 리스크를 조기에
감소시킬 수 있음
v 주요 모델
– 애자일 개발모델
– RUP, RAD
– 프로토타이핑

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

16. 개발수명주기와 테스팅
v 모든 개발활동은 이에 상응하는 테스팅 활동을 동반함
v 각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가짐
v 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되
는 개발 활동 동안에 시작되어야함
v 개발 수명주기 동안에 개발 산출물의 초안이 작성되면, 테스
터는 이러한 문서를 리뷰하는 활동에 참가해야함

17. 테스트 레벨에 따른 정의
v 해당 테스트 레벨의 일반적인 목적이나 목표
v 테스트 케이스를 도출하는데 참조되는 개발 산출물(테스트
베이시스)
v 테스트 대상
v 발견된 전형적인 결함과 장애
v 테스트 드라이버/스텁이나 도구의 필요성
v 상세한 테스트 접근법
v 테스트 수행 주체 또는 조직

18. 테스트 레벨-단위 테스팅[1]
v 컴포넌트(component) 테스트, 유닛(unit) 테스트, 모듈테스
트라고도 함
v 가능한 최소 단위로 나누어진 소프트웨어(모듈, 프로그램,
클래스 등)내에서 결함을 찾고, 해당 단위의 기능을 검증함
v 해당 모듈을 테스트 하기 위해 테스트 드라이버나 스텁이
필요할 수 있음
v 단위 테스트에는 기능성 테스트 외에 비기능(메모리 관리
등) 테스트도 포함함
v 보통 단위 테스트는 코드를 중심으로 수행하며, 해당 코드를
작성한 프로그래머가 직접 테스트하여 수정하고 결함에 대
한 기록은 생략하는 것이 일반적임

19. 테스트 레벨-단위 테스팅[2]
v 단위 테스트의 일반적인 목적
– 기본 경로를 확인
– 모든 오류 처리 경로를 확인
– 컴포넌트 내의 인터페이스 확인
– 로컬 데이터 확인, 경계값 확인

20. 테스트 레벨-통합 테스팅[1]
v 테스트 대상
– 컴포넌트 간의 인터페이스 테스트
– 시스템의 각기 다른 부분과 상호 연동하는 동작 테스트
• 운영체제, 파일 시스템, 하드웨어 또는 시스템 사이의
인터페이스 등
v 통합테스팅의 두 종류
– 컴포넌트 통합 테스팅 : 소프트웨어 컴포넌트 사이의 상
호작용을 테스트
– 시스템 통합 테스팅 : 시스템 사이의 상호작용을 테스트

21. 테스트 레벨-통합 테스팅[2]
v 통합 테스트 접근법
백본
(Backbone)
빅뱅
(Big bang)
상향식
(Bottom up)
하향식
(Top down)
방법
가장 중요하고 리
스크가 높은 모듈
부터 통합
모든 모듈을 한번
에 통합
가장 하부 모듈부
터 통합
가장 상부 모듈부
터 통합
드라이버/
스텁
필요에 따라 만들
어 사용
불필요
실제모듈통합
드라이버 필요 스텁 필요
장점
결함 격리쉬움
리스크가 높은 결
함을 초기발견
단시간 테스트
결함격리쉬움
하위모듈을
충분히 테스트
결함격리쉬움
설계상의 결함
을 빨리 발견
단점
테스트 시간이 오
래 걸릴 수 있음
결함격리어려움
수정이 어려운 중
요한 결함을 상부
구조에서 발견가능
수정이 어려운 중
요한 결함을 하부
에서 발견 가능

22. 테스트 레벨-시스템 테스팅
v 프로젝트 차원에서 정의된 전체 시스템 또는 제품의 동작에
대해 테스트 수행
v 가능한 범위에서 실제 최종 사용 환경 또는 이와 유사한 환
경에서 수행해야 함
v 시스템 테스팅은 기능 및 비기능 요구사항을 모두 검증함
– 기능적 요구사항 : 테스트 대상의 특성을 기술한 문서를
기반으로 테스트 설계
– 비기능적 요구사항 : 성능테스트, 가용성 테스트, 보안성
테스트 등
v 시스템 테스팅은 독립적인 테스팅 팀이 수행하는 경우가 대
부분임

23. 테스트 레벨-인수 테스팅[1]
v 인수 테스팅의 목적은 시스템이나 시스템의 일부 또는 특정
한 비기능적인 특성에 대해 “확신”을 얻는 것임
v 인수 테스팅은 시스템을 배포하거나 실제 사용할만한 준비
가 되어있는지에 대해 평가함
v 시스템을 사용하는 고객이나 사용자가 전담하여 수행

24. 테스트 레벨-인수 테스팅[2]
v 인수 테스팅의 다양한 형태
– 사용자 인수 테스팅: 사용자가 시스템사용의 적절성 확인
– 운영상의 인수 테스팅: 시스템 관리자에 의한 테스팅
– 계약 인수테스팅과 규정 인수 테스팅: 주어진 계약이나
규정 부합 여부 확인
– 알파 테스팅과 베타(필드)테스팅
• 알파 테스팅 : 개발 조직내에서 고객이 수행
• 베타 테스팅 : 실제 환경에서 사용자 혹은 잠재 고객에
의해 수행
• 공장인수 테스팅=알파 테스팅, 사이트인수 테스팅=베
타 테스팅

25. 테스트 유형
v 테스트 유형이란 테스트하는 목적 및 품질 특성(신뢰성, 유
지보수성 등)을 확인하기 위해 소프트웨어 시스템을 검증하
는 테스트 활동
– 소프트웨어가 수행하는 기능에 대한 테스팅
– 호환성, 신뢰성, 사용성과 같은 비기능적인 품질특성 테
스팅
– 소프트웨어나 시스템의 구조에 대한 테스팅
– 변경 내용에 관련된 테스팅
• 확인 테스팅(재테스팅) : 결함에 대한 수정이 이루어졌
는지 확인하는 테스팅
• 리그레션 테스팅(회귀 테스팅) : 결함의 수정으로 다른
부분에 의도하지 않았던 결함이 발생하지는 않는지 확
인하는 테스팅

26. 테스트 유형 – 기능 테스팅
v 기능 : 시스템이 수행하는 그 “무엇”을 의미
– 문서화되어 있거나
– 테스터가 알고 있는 기능과 특징을 테스트
v 명세기반기법을 이용해 소프트웨어나 시스템의 기능에서 테
스트 조건과 테스트 케이스를 도출하고 소프트웨어의 외부
적인 행동을 고려함(블랙박스 테스팅)
v ISO/IEC 9126에서 기능성의 부특성
– 적합성, 정확성, 준수성, 상호운용성, 보안성

27. 테스트 유형 – 비기능 테스팅
v 비기능테스팅
– 시스템이 “어떻게” 동작하는가를 테스팅
v 비기능테스팅의 종류
– 성능 테스팅
– 부하 테스팅/스트레스 테스팅
– 사용성 테스팅
– 유지보수성 테스팅
– 신뢰성 테스팅
– 이식성 테스팅 등을 포함
v ISO/IEC 9126의 비기능성 품질특성
– 신뢰성, 사용성, 효율성, 유지보수성, 이식성

28. 테스트 유형 – 구조적 테스팅
v 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보
장성 또는 충분함을 측정하는 것이 목적임
v 커버리지 : 시스템 또는 소프트웨어의 구조가 테스트 케이스
에 의해 테스트된 정도를 말하며 커버된 퍼센트로 표시함
– 커버리지는 4장에서 자세하게 다룸

29. 테스트 유형 – 확인/재 테스팅
v 확인(재) 테스팅(Confirmation/Re Testing)
– 결함이 발견되고 수정한 후에 원래의 결함이 성공적으로
제거되었는지 확인하는 테스트
– 결함의 원인을 찾거나 결함을 수정하기 위한 디버깅은
개발활동이며 테스트 활동으로 보지 않음

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

31. 유지보수 테스팅
v 이미 사용되고 운영되고 있는 시스템에서 수행하는 테스트
v 소프트웨어나 시스템이 변경, 단종되었거나 마이그레이션될
때 발생함
– 변경 : 계획된 개선 활동에 의한 변경, 요구사항 변경에
의한 수정, 환경의 변경, OS 또는 DB 업그레이드, OS 패
치 등의 변경
– 마이그레이션 : 한 플랫폼에서 다른 플랫폼으로 옮겨가는
마이그레이션을 위한 테스팅으로 새로운 환경에서의 운
영 테스트도 포함
– 시스템 단종에 의한 유지보수 테스팅은 데이터를 마이그
레이션하는 테스팅을 포함할 수 있으며, 데이터 저장 관
련 사항도 테스트 해야 함

32. 상위레벨
- 고객
- 독립적 테스터
인수테스트
시스템테스트
통합테스트
단위테스트
하위레벨
- 주로 개발자가
- 베타(실제환경,고객)
- 알파(개발조직내,고객)
- 시스템통합테스트
- 컴포넌트통합테스트
테스트 레벨
기능테스팅
비기능테스팅
구조적테스팅
확인테스팅
리그레션테스팅
테스트 유형
2장 요약