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

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

2. 학습내용
v 소프트웨어 테스팅의 정의
v 소프트웨어 테스팅의 필요성
v 소프트웨어 테스트 프로세스
v 소프트웨어 테스트의 한계

3. 소프트웨어 테스팅의 필요성
v 소프트웨어가 올바로 동작하지 않을 경우
– 금전적인 손실
– 시간 낭비
– 비즈니스의 이미지 손상
– 부상
– 사망 등
v 테스팅의 필요성
– 소프트웨어 시스템의 문제를 최소화

4. 오류(Error)
결함(Defect), 결점(Fault), 버그(Bug)
인시던트(Incident), 이슈(Issue)
장애(Failure)
리스크(Risk)
테스팅 용어

5. 테스팅 용어
에러(오류)에러(오류)
결 함결 함
장 애장 애
사람의 실수에 의한 에러
원인은 사람
defect, bug, fault
에러에 의해 발생한 것
에러가 실제로 코드에 구현된 것
Failure
결함을 가진 SW실행하면 발생
Visible하게 보임
모든 결함이 장애로 가지는 않는다.모든 결함이 장애로 가지는 않는다.

6. 소프트웨어 결함의 원인
v 소프트웨어의 결함을 발생시키는 원인 2가지
사람의 실수는 소프트웨
어 또는 시스템 코드에
결함을 야기
전자파, 자석, 공해, 자연현상
등과 같은 주변 환경의 영향
으로 소프트웨어 또는 시스
템이 사용하는 하드웨어에
영향을 주어 오류를발생
인간의 실수 주변 환경에 의한 결함
소프트웨어의
결함

7. 소프트웨어의 개발,유지보수,운영과 테스팅
v 소프트웨어 개발과정에서 테스팅은?
– 개발 초기부터 정적분석을 통해 시작
– 개발 단계에 대응하는 테스트 레벨에 따라 테스팅 실행
– 테스트 조직의 독립성 문제
v 운영 테스팅
– 기존 운영 시스템의 변경/단종/환경변화 등으로 변경된
시스템에 대한 테스팅

8. 테스팅과 품질
v 소프트웨어 품질특성
– ISO/IEC 9126
– 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성
v 테스팅은
– 기능 테스팅
– 비기능 테스팅

9. 어느 정도의 테스팅이 적절한가? [1]
v 테스팅은 많이 할수록 좋겠지만, 현실적인 제약이 있다.
일정 비용
조직의
성숙도
제약사항

10. v 적절한 테스팅의 정도는?
– 리스크(Risk) 수준을 우선적으로 고려해야
– 그외
• 기술적인 내용
• 비즈니스
• 제품 리스크
• 프로젝트 리스크
• 시간
• 비용 등 고려
어느 정도의 테스팅이 적절한가? [2]

11. 어느 정도의 테스팅이 적절한가? [3]
기술적 요인, 비즈니스적 요인, 제품의 특성, 제품의 리스크 수
준 등과 같은 다양한 요소들에 대한 고민이 필요
의사결정권자(경영진, 프로젝트 관리자)에게 소프트웨어에 대
한 충분한 정보(필요일정, 비용 등)를 제공해서 테스팅 규모를
산정할 수 있도록 해야 한다.

12. 테스팅의 정의
v 테스팅
– 결함 발견과 격리 (때로는 예방까지)
– 결함 발견(Defect Detection-QC) 메커니즘
– 제품에 자신감 제공
– 결함 예방(Defect Prevention-QA)과 조화를 이루어야함
– 품질과 리스크에 대한 통찰 제공
– 테스팅은 수명주기와 프로세스를 갖는 프로젝트
– “테스트”는 실제 수행하는 하나하나의 실체

13. 소프트웨어 테스팅의 정의
프로그램의 동작(기능)과 성능, 안정성이
사용자가 요구하는 수준을 만족하는지 확인하기 위해
결함을 발견하는 방법

14. 소프트웨어 테스팅의 목적 [1]
전통적 테스트 개념전통적 테스트 개념
소프트웨어의
정상 작동 여부 확인
현재의 테스트 개념현재의 테스트 개념
사용자의 기대수준과
요구사항에 맞게
구현되고 동작하는지
확인
최종 목표최종 목표
결함 데이터를 근간으로 소프트웨어의
리스크 정보를 정량적 수치화하여
의사결정권자에게 전달

15. 소프트웨어 테스팅의 목적 [2]
v 주요 이유
– 잔존 결함 발견
– 개발 시스템/SW에 대한 자신감 부여
– 결함을 미연에 방지
– 명세 충족 확인
– 사용자 및 비즈니스의 요구 충족 확인
– 비즈니스 리스크를 감소시키는 정보 제공(발견된 결함 기
반의 수치 데이터 제공)
v 기타 이유
– 개발 프로세스 점검
– 논리적 설계의 구현 검증
– 시스템/SW가 적절히 동작함을 확인

16. 소프트웨어 테스팅의 목적 [3]
v 테스팅의 목적은 테스트의 상황이나 관점에 따라 달라질
수 있다.
v 개발과정: 소프트웨어의 결함을 찾아내고 수정하기 위해
서 가능한 많은 장애의 원인을 발생시킴
v 인수과정: 예상된 대로 시스템이 동작하는지 확인하고,
요구사항에 맞는지 확신을 얻는 과정
v 품질평가: 특정시간에 시스템을 출시하는 것의 리스크를
개발 프로젝트 관련자에게 전달
v 유지보수: 변경사항을 추가적으로 개발하는 중에 새로운
결함이 유입되었는지 확인하는 테스팅 과정 포함
v 운영: 신뢰성 또는 가용성과 같은 시스템의 특성을 평가

17. 테스팅과 디버깅의 차이
v 결함을 발견하기 위한 활동
v 테스트는 공정상의 결함을 발견할 수 있다.
v 시스템이 정지되는 결함과 정지가 되지 않는 결함
이 모두 포함된다.
테스팅
디버깅 v 결함의 원인을 찾고, 코드를 수정하는 개발활동
v 디버깅 후 테스터에 의해 확인 테스팅을 수행하여
결함이 제대로 고쳐졌는지 확인이 필요

18. 테스팅의 특성
v 완벽한 테스트는 불가능
– 한 프로그램 내의 내부조건이 무수히 많을 수 있음
– 입력이 가질 수 있는 모든 값의 조합이 무수히 많음
– 이벤트 발생순서에 대한 조합도 무수히 많음
v 테스트는 결함이 없음을 보이려는 것이 아님
v 본인이 만든 프로그램의 결함을 발견하기는 쉽지 않음
v 현실적인 테스팅의 목적
– 주어진 리소스(시간, 인력 등)로 리스크가 높은 시스템 부
분의 결함을 발견할 확률을 극대화 -> 리스크 최소화

19. ISTQB에서 제시하는 테스팅 원칙
1. 테스팅은 결함이 존재함을 밝히는 활동이다.
2. 완벽한 테스팅은 불가능하다.
3. 테스팅은 개발 초기에 시작된다.
4. 결함 집중
5. Pesticide Paradox(살충제 패러독스)
6. 테스팅은 정황(context)에 의존적이다.
7. 오류-부재의 궤변

20. ISTQB에서 제시하는 테스팅 원칙 [1]
1. 테스팅은 결함이 존재함을 밝히는 활동이다.
• 테스팅은 결함이 있다는 것을 보여줄 수 있지만, 결함
이 없다는 것을 증명할 수는 없다.
• 테스팅은 소프트웨어에 존재하는 결함 수를 낮출 수
있지만, 가령 테스팅을 통해 아무런 결함을 발견하지
못했다고 하여도 결함이 전혀 없다고는 증명할 수 없
다.

21. ISTQB에서 제시하는 테스팅 원칙 [2]
2. 완벽한 테스팅은 불가능하다.
• 일반적으로 평범한 경우를 제외하고 모든 것(모든
input과 전제 조건의 조합)에 대한 테스팅은 불가능하
다.
• 완벽한 테스팅 대신, 리스크와 중요도가 높은 영역에
집중하는 것이 좋다.

22. ISTQB에서 제시하는 테스팅 원칙 [3]
3. 테스팅을 개발 초기에 시작한다.
• 테스팅 활동은 소프트웨어 또는 시스템 개발 수명주
기의 초기부터 시작되어, 수명주기와 상응하는 목적들
에 집중하여야 한다.
• 개발초기 테스팅이란?
• 요구사항 분석서, 설계서 등 개발 산출물을 분석하
여 테스트 케이스를 도출하는 과정에서 결함 발견

23. ISTQB에서 제시하는 테스팅 원칙 [4]
4. 결함 집중
• 대다수의 결함들은 소수의 특정 모듈에 집중되어 발
생하는 경향을 보임
• 복잡한 구조를 가진 모듈
• 인터페이스가 복잡한 모듈
• 개발 난이도가 높은 모듈
• 최신 기술을 사용한 모듈
• 새로 만든 모듈
• 크기가 큰 모듈
• 경험이 부족한 개발팀에서 개발한 모듈

24. ISTQB에서 제시하는 테스팅 원칙 [5]
5. 살충제 패러독스
• 같은 테스트 케이스를 가지고 테스트를 계속해서 반
복하면 결국은 버그가 발견되지 않을 것이다.
• 이러한 “살충제 패러독스” 현상을 방지하기 위해서는
지속적으로 테스트 케이스를 검토하고 개정해야 한다.
• 테스트 케이스 업데이트 노력 필요
• 탐색적테스팅 등 경험기반접근법으로 TC추가 개발

25. ISTQB에서 제시하는 테스팅 원칙 [6]
6. 테스팅은 정황에 의존적이다.
• 테스팅은 그 대상에 따라 다르게 수행되어야 한다.
• 예를 들어, 안전을 중요시하는 소프트웨어는 일반 웹
사이트의 테스트와 다르게 수행되어야 하는 것을 말
한다.

26. ISTQB에서 제시하는 테스팅 원칙 [7]
7. 오류-부재의 궤변
• 결함을 찾고 고쳤다고 해도 시스템이 사용자가 원하
는 필요성에 맞도록 개발되지 않았다면 테스팅은 아
무런 도움이 되지 않는다.
• 요구를 충족시키지 못한다면, 결함을 모두 제거했더라
도 품질이 높다고 볼 수 없다.

27. 1. 계획과 통제
2. 분석 및 설계
3. 구현과 실행
4. 완료 조건의 평가와 리포팅
5. 테스트 마감 활동
조직구성
테스트 베이시스 필요
테스트 기법 필요
테스트 베이시스 필수
테스트 설비/환경구축
테스트 베이시스: 테스트 설계 및 구현에 필요한 각종 개발 산출물
v ISTQB에서 제시하는 테스트 프로세스
테스팅 프로세스

28. 1. 테스트 계획과 제어(통제) [1]
v 테스트 계획
– 테스트 계획은 테스팅의 미션과 목표를 정의하고 이를
만족시키기 위한 테스트 활동들을 수립하는 과정
– 테스트 계획은 모니터링 및 통제 활동의 피드백에 따라
조치를 할 수 있도록 수립되어야 할 것
1. 테스트를 위한 자원 파악(인적자원, 테스트환경, PC사양 등)
2. 테스트 정책 및 테스트 전략 수립
3. 테스트 분석 및 설계 업무 일정 관리
4. 테스트의 적용, 실행, 평가에 대한 일정 관리
5. 완료조건 결정
해야할 일

29. 1. 테스트 계획과 제어(통제) [2]
v 테스트 제어(통제)
– 테스트 통제는 실제 진행 상황과 계획을 비교하고 보고
하는 활동
– 여기에는 프로젝트의 미션과 목표를 위해 조치가 이루어
질 수 있음
– 이를 위해 프로젝트의 진행이 지속적으로 모니터링 되어
야 할 것
1. 결과 측정 및 분석
2. 모니터링 및 문서화의 진행, 테스트 범위, 종결기준
3. 결과반영(수정, 변경 등) 활동
4. 의사결정
해야할 일

30. 2. 테스트 분석과 설계
v 테스트 계획에서 제시된 목표를 테스트 케이스로 반영
1. 테스트 베이시스 리뷰(요구사항, 디자인 등)
2. 테스트 대상 아이템 또는 명세, 구조 분석을 통해 테스트
상황을 식별하고 우선 순위 선정
3. 테스트 케이스 설계와 우선 순위 선정
4. 비공식적인 기법으로 테스트 케이스 추가 도출 및 보완
5. 테스트 상황과 테스트 케이스에 필요한 테스트 데이터 식
별
6. 테스크 환경 구축에 대한 디자인과 요구되는 기반 시설 및
도구 식별
해야할 일

31. 3. 테스트 구현 및 실행
v 효과적/효율적 테스트를 위해 테스트 케이스를 조합하고, 테
스트 프로시저/테스트 스크립트 작성
v 테스트 환경이 구축되어 있어야 함
1. 테스트 데이터 생성
2. 효과적인 테스트를 위한 테스트 프로시저 생성
3. 테스트 하네스 준비
4. 테스트 환경이 제대로 설정되었는지 확인
5. 계획된 절차에 따라 테스트 케이스를 직접 또는 툴을 사용하여 수행
6. 테스트 실행결과를 기록하고 테스트 수행 대상 및 소프트웨어 버전을
기록
7. 예상 결과와 실제 결과를 비교
8. 불일치하는 결과가 나오는 원인을 기록
9. 각각의 불일치에 대한 반복적인 활동
해야할 일

32. 용어
v 테스트 하네스
– 테스트 드라이버 + 테스트 스텁
– 테스트 드라이버 : 하위 모듈을 테스트하기 위해 이 모듈을 호출해주
는 상위의 임시 모듈
– 테스트 스텁 : 상위 모듈을 테스트하기 위해 이 모듈에서 호출하는
하위의 임시 모듈
B() {
bbb;
}
A() {
B();
}
B() {
bbb;
}
드라이버 {
B();
}
스텁 {
bbb;
}
A() {
B();
}
호출(call) 리턴(복귀)

33. 용어
v 테스트 오라클(Oracle)
– 테스트 실행 결과가 올바른 결과인지를 판별할 수 있는 메커니즘
– 참 오라클(True Oracle) : 모든 입력값에 대한 결과값 생성
• 개발에 시간/비용 (거의 불가능)
– 샘플링 오라클 : 특정 몇몇 입력값에 대한 결과를 제공
• 단점: 다른 입력값에 대한 오류 검증은 못함
• 장점: 비교적 쉽게 작성 가능
– 휴리스틱 오라클 : 몇몇 입력값 대한 결과 + 나머지는 휴리스틱으로
결과값 제공
– 일관성 검사 오라클(Consistent Test Oracle)
• 이전 버전의 프로그램 결과와 현재 버전의 프로그램 결과의 일관
성 유지 여부 검사
• 대부분의 상업용 테스트 도구에서 지원하는 형태

34. 불일치(결함)의 원인 분석
v 테스트 케이스 결함
– 프로그램이 아니라 테스트 케이스 자체의 결함
v 테스트 정황 결함
– 테스트 수행상의 오류, 데이터 입력 오류 등
v 어플리케이션 결함
– 테스트 대상의 결함(SW, HW, 설치결함, 코드 결함 등)
v 어플리케이션 정황 결함
– 사용상 오류, 테스트 환경과 관련된 SW결함

35. 결함 유형 분류
v 기획 시 유입되는 결함
– 요구사항의 표준 미준수, 테스트 불가능, 불명확, 불완전,
불일치, 기타 결함
v 설계 시 유입되는 결함
– 설계 표준 미준수, 테스트불가능, 불명확, 불완전, 불일치,
인터페이스 결함, 기타 결함
v 코딩시 유입된 결함
– 코딩 표준 미준수, 불완전, 불일치, 인터페이스 결함, 데이
터 결함, 기타 결함
v 테스트 부족으로 유입된 결함
v 마무리 부족, 팀간 의사소통 부족, 코딩 실수

36. 결함 심각도 별 분류
v 결함심각도 분류 사례
– 치명적, 매우 심각, 심각, 보통, 경미
– 치명적 결함, 주요 결함, 일반 결함, 사소한 결함, 개선사
항 (37쪽 참조)
v 부적절한 사례
– Major, Minor, Trifle(하찮은 것)
– A,B,C

37. 결함 우선순위
v 결함 심각도와 결함 우선순위는 구분해야한다.
v 모든 경우 결함심각도가 가장 높다고 해서 가장 먼저 그 결
함을 수정해야 하는 것은 아니다.
v 결함 우선순위 표현 사례
– 즉시 해결
– 주의 요망
– 대기
– 낮은 순위

38. 4. 완료조건의 평가와 리포팅
v 테스트 수행 결과를 목적과 비교하여 평가
1. 테스트 계획에 정의된 완료 기준에 따라 테스트 로그 확인
2. 추가 테스트가 필요한지에 대한 평가를 하거나 완료 기준
을 변경
3. 이해관계자들을 위한 테스트 요약 보고 작성
해야할 일

39. 리포팅 내용
v 발견된 결함과 미해결 결함의 추이 및 우선순위
v 테스트 진척도
v 리스크 및 메트릭으로 실증된 조언
v 테스트 환경의 가용성
v 테스트 커버리지, 결함발견 효과성/효율성, 품질평가 결과,
결함 상태별 결함 수, 소프트웨어 사이즈 대비 결함 수 등

40. 효과적/효율적
v 효과적(Effective)
– 계획되었거나 원했던 테스트 결과산출
– 효과적 테스터는 테스팅 노력으로부터 어떤 결과를 도출
할 것인지 결정함
v 효율적(Efficient)
– 원했던 테스트 결과 산출을 생산적으로 수행
– 효율적 테스터는 가용한 리소스(시간, 자금, 인력)를 적절
하고 현명하게 배치
효과적
효율적

41. 5. 테스트 마감 활동
v 모든 테스트 활동에서 경험, 테스트 도구, 사실, 통계를 종합
하기 위해 데이터를 수집하고 완료
1. 계획된 산출물이 산출되었는지에 대한 확인, 개별 요소에
대한 보고 완료, 또는 아직 수행중인 활동의 변경 기록에
대한 이슈 제기
2. 시스템 인수와 관련된 문서 확인
3. 유지보수 조직에 테스트 도구 인계
4. 사후 관리 및 테스트 성숙도 향상 수준 분석
해야할 일

42. 테스팅의 독립성
개발자가
테스트를 설계하는
경우
(낮은 수준의 독립성)
개발팀내
다른 조직의 인력이
테스트를 설계하는
경우
사내
다른 조직의 인력이
테스트를 설계하는
경우
(별도의 테스트팀)
다른 조직 또는
기업의 인력이
테스트를 설계하는
경우
(외부기관 인증)
Part 5에서 보다 자세하게 다룸

43. 테스팅의 심리학
v 테스트 대상 제품이나 개발자에 대한 비판으로 오해
v 좋은 대인관계가 필수적
– 다툼보다는 협력으로 시작: 더 좋은 제품을 만들기 위한
공통목표
– 사람에 대한 비평을 배제하고, 중립적이고 사실에 근거한
제품의 결함만 전달하려고 노력
– 다른 사람의 반응에 대한 이해
– 의사소통 내용을 상대방이 정확하게 이해했는지 확인

44. 테스팅의 제약
테스팅을 투자가
아닌 불필요한
비용으로 간주함
관리자나 테스터가
테스팅에 대하여
단편적인 지식만
가지고 있음
부족한 인력과
자원으로 인해
테스팅에 대한
투자여력 없음
의사결정권자나
프로젝트 관리자가
테스팅에 대한
인식이 부족함

45. 소프트웨어 테스팅에 대한 오해
v 시간, 인력이 부족해서 테스팅을 제대로 못한다.
v 테스트는 완벽하게 수행될 수 있다.
v 테스트는 그리 어려운 작업이 아니다.
v 아무나 테스트를 수행할 수 있다.
v 프로그램이나 시스템이 잘 수행될 수 있음을 보여주는 것이
다.
v 테스트는 개발 이후의 작업이다.
v 개발일정에 따라 테스트는 생략될 수 있다.