istqb 1-소프트웨어테스팅기초-2015

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

Upload: jongwon-lee

Post on 28-Jul-2015

211 views

Category:

Software


9 download

TRANSCRIPT

Page 1: Istqb 1-소프트웨어테스팅기초-2015

2015, 봄

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

ISTQB-1

소프트웨어 테스팅기초

Page 2: Istqb 1-소프트웨어테스팅기초-2015

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

Page 3: Istqb 1-소프트웨어테스팅기초-2015

소프트웨어 테스팅의 필요성v 소프트웨어가 올바로 동작하지 않을 경우

– 금전적인 손실– 시간 낭비– 비즈니스의 이미지 손상– 부상– 사망 등

v 테스팅의 필요성– 소프트웨어 시스템의 문제를 최소화

Page 4: Istqb 1-소프트웨어테스팅기초-2015

오류(Error)

결함(Defect), 결점(Fault), 버그(Bug)

인시던트(Incident), 이슈(Issue)

장애(Failure)

리스크(Risk)

테스팅 용어

Page 5: Istqb 1-소프트웨어테스팅기초-2015

테스팅 용어에러(오류)에러(오류)

결 함결 함

장 애장 애

사람의 실수에 의한 에러원인은 사람

defect, bug, fault에러에 의해 발생한 것

에러가 실제로 코드에 구현된 것

Failure결함을 가진 SW실행하면 발생

Visible하게 보임

모든 결함이 장애로 가지는 않는다.모든 결함이 장애로 가지는 않는다.

Page 6: Istqb 1-소프트웨어테스팅기초-2015

소프트웨어 결함의 원인v 소프트웨어의 결함을 발생시키는 원인 2가지

사람의 실수는 소프트웨어 또는 시스템 코드에

결함을 야기

전자파, 자석, 공해, 자연현상등과 같은 주변 환경의 영향으로 소프트웨어 또는 시스템이 사용하는 하드웨어에영향을 주어 오류를발생

인간의 실수 주변 환경에 의한 결함

소프트웨어의결함

Page 7: Istqb 1-소프트웨어테스팅기초-2015

소프트웨어의 개발,유지보수,운영과 테스팅

v 소프트웨어 개발과정에서 테스팅은?– 개발 초기부터 정적분석을 통해 시작– 개발 단계에 대응하는 테스트 레벨에 따라 테스팅 실행– 테스트 조직의 독립성 문제

v 운영 테스팅– 기존 운영 시스템의 변경/단종/환경변화 등으로 변경된

시스템에 대한 테스팅

Page 8: Istqb 1-소프트웨어테스팅기초-2015

테스팅과 품질

v 소프트웨어 품질특성– ISO/IEC 9126– 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성

v 테스팅은– 기능 테스팅– 비기능 테스팅

Page 9: Istqb 1-소프트웨어테스팅기초-2015

어느 정도의 테스팅이 적절한가? [1]v 테스팅은 많이 할수록 좋겠지만, 현실적인 제약이 있다.

일정 비용조직의성숙도

제약사항

Page 10: Istqb 1-소프트웨어테스팅기초-2015

v 적절한 테스팅의 정도는?– 리스크(Risk) 수준을 우선적으로 고려해야– 그외

• 기술적인 내용• 비즈니스• 제품 리스크• 프로젝트 리스크• 시간• 비용 등 고려

어느 정도의 테스팅이 적절한가? [2]

Page 11: Istqb 1-소프트웨어테스팅기초-2015

어느 정도의 테스팅이 적절한가? [3]

기술적 요인, 비즈니스적 요인, 제품의 특성, 제품의 리스크 수준 등과 같은 다양한 요소들에 대한 고민이 필요

의사결정권자(경영진, 프로젝트 관리자)에게 소프트웨어에 대한 충분한 정보(필요일정, 비용 등)를 제공해서 테스팅 규모를산정할 수 있도록 해야 한다.

Page 12: Istqb 1-소프트웨어테스팅기초-2015

테스팅의 정의v 테스팅

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

Page 13: Istqb 1-소프트웨어테스팅기초-2015

소프트웨어 테스팅의 정의

프로그램의 동작(기능)과 성능, 안정성이사용자가 요구하는 수준을 만족하는지 확인하기 위해

결함을 발견하는 방법

Page 14: Istqb 1-소프트웨어테스팅기초-2015

소프트웨어 테스팅의 목적 [1]전통적 테스트 개념전통적 테스트 개념

소프트웨어의정상 작동 여부 확인

현재의 테스트 개념현재의 테스트 개념

사용자의 기대수준과요구사항에 맞게

구현되고 동작하는지확인

최종 목표최종 목표

결함 데이터를 근간으로 소프트웨어의리스크 정보를 정량적 수치화하여

의사결정권자에게 전달

Page 15: Istqb 1-소프트웨어테스팅기초-2015

소프트웨어 테스팅의 목적 [2]v 주요 이유

– 잔존 결함 발견– 개발 시스템/SW에 대한 자신감 부여– 결함을 미연에 방지– 명세 충족 확인– 사용자 및 비즈니스의 요구 충족 확인– 비즈니스 리스크를 감소시키는 정보 제공(발견된 결함 기

반의 수치 데이터 제공)v 기타 이유

– 개발 프로세스 점검– 논리적 설계의 구현 검증– 시스템/SW가 적절히 동작함을 확인

Page 16: Istqb 1-소프트웨어테스팅기초-2015

소프트웨어 테스팅의 목적 [3]v 테스팅의 목적은 테스트의 상황이나 관점에 따라 달라질

수 있다.v 개발과정: 소프트웨어의 결함을 찾아내고 수정하기 위해

서 가능한 많은 장애의 원인을 발생시킴v 인수과정: 예상된 대로 시스템이 동작하는지 확인하고,

요구사항에 맞는지 확신을 얻는 과정v 품질평가: 특정시간에 시스템을 출시하는 것의 리스크를

개발 프로젝트 관련자에게 전달v 유지보수: 변경사항을 추가적으로 개발하는 중에 새로운

결함이 유입되었는지 확인하는 테스팅 과정 포함v 운영: 신뢰성 또는 가용성과 같은 시스템의 특성을 평가

Page 17: Istqb 1-소프트웨어테스팅기초-2015

테스팅과 디버깅의 차이v 결함을 발견하기 위한 활동v 테스트는 공정상의 결함을 발견할 수 있다.v 시스템이 정지되는 결함과 정지가 되지 않는 결함

이 모두 포함된다.

테스팅

디버깅 v 결함의 원인을 찾고, 코드를 수정하는 개발활동v 디버깅 후 테스터에 의해 확인 테스팅을 수행하여

결함이 제대로 고쳐졌는지 확인이 필요

Page 18: Istqb 1-소프트웨어테스팅기초-2015

테스팅의 특성v 완벽한 테스트는 불가능

– 한 프로그램 내의 내부조건이 무수히 많을 수 있음– 입력이 가질 수 있는 모든 값의 조합이 무수히 많음– 이벤트 발생순서에 대한 조합도 무수히 많음

v 테스트는 결함이 없음을 보이려는 것이 아님v 본인이 만든 프로그램의 결함을 발견하기는 쉽지 않음

v 현실적인 테스팅의 목적– 주어진 리소스(시간, 인력 등)로 리스크가 높은 시스템 부

분의 결함을 발견할 확률을 극대화 -> 리스크 최소화

Page 19: Istqb 1-소프트웨어테스팅기초-2015

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

Page 20: Istqb 1-소프트웨어테스팅기초-2015

ISTQB에서 제시하는 테스팅 원칙 [1]

1. 테스팅은 결함이 존재함을 밝히는 활동이다.

•테스팅은 결함이 있다는 것을 보여줄 수 있지만, 결함이 없다는 것을 증명할 수는 없다.

•테스팅은 소프트웨어에 존재하는 결함 수를 낮출 수있지만, 가령 테스팅을 통해 아무런 결함을 발견하지못했다고 하여도 결함이 전혀 없다고는 증명할 수 없다.

Page 21: Istqb 1-소프트웨어테스팅기초-2015

ISTQB에서 제시하는 테스팅 원칙 [2]

2. 완벽한 테스팅은 불가능하다.

•일반적으로 평범한 경우를 제외하고 모든 것(모든input과 전제 조건의 조합)에 대한 테스팅은 불가능하다.

•완벽한 테스팅 대신, 리스크와 중요도가 높은 영역에집중하는 것이 좋다.

Page 22: Istqb 1-소프트웨어테스팅기초-2015

ISTQB에서 제시하는 테스팅 원칙 [3]

3. 테스팅을 개발 초기에 시작한다.

•테스팅 활동은 소프트웨어 또는 시스템 개발 수명주기의 초기부터 시작되어, 수명주기와 상응하는 목적들에 집중하여야 한다.

•개발초기 테스팅이란?•요구사항 분석서, 설계서 등 개발 산출물을 분석하여 테스트 케이스를 도출하는 과정에서 결함 발견

Page 23: Istqb 1-소프트웨어테스팅기초-2015

ISTQB에서 제시하는 테스팅 원칙 [4]

4. 결함 집중

•대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보임

• 복잡한 구조를 가진 모듈• 인터페이스가 복잡한 모듈• 개발 난이도가 높은 모듈• 최신 기술을 사용한 모듈• 새로 만든 모듈• 크기가 큰 모듈• 경험이 부족한 개발팀에서 개발한 모듈

Page 24: Istqb 1-소프트웨어테스팅기초-2015

ISTQB에서 제시하는 테스팅 원칙 [5]

5. 살충제 패러독스

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

Page 25: Istqb 1-소프트웨어테스팅기초-2015

ISTQB에서 제시하는 테스팅 원칙 [6]

6. 테스팅은 정황에 의존적이다.

•테스팅은 그 대상에 따라 다르게 수행되어야 한다.•예를 들어, 안전을 중요시하는 소프트웨어는 일반 웹사이트의 테스트와 다르게 수행되어야 하는 것을 말한다.

Page 26: Istqb 1-소프트웨어테스팅기초-2015

ISTQB에서 제시하는 테스팅 원칙 [7]

7. 오류-부재의 궤변

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

Page 27: Istqb 1-소프트웨어테스팅기초-2015

1. 계획과 통제

2. 분석 및 설계

3. 구현과 실행

4. 완료 조건의 평가와 리포팅

5. 테스트 마감 활동

조직구성테스트 베이시스 필요

테스트 기법 필요테스트 베이시스 필수테스트 설비/환경구축

테스트 베이시스: 테스트 설계 및 구현에 필요한 각종 개발 산출물

v ISTQB에서 제시하는 테스트 프로세스

테스팅 프로세스

Page 28: Istqb 1-소프트웨어테스팅기초-2015

1. 테스트 계획과 제어(통제) [1]v 테스트 계획

– 테스트 계획은 테스팅의 미션과 목표를 정의하고 이를만족시키기 위한 테스트 활동들을 수립하는 과정

– 테스트 계획은 모니터링 및 통제 활동의 피드백에 따라조치를 할 수 있도록 수립되어야 할 것

1. 테스트를 위한 자원 파악(인적자원, 테스트환경, PC사양 등)2. 테스트 정책 및 테스트 전략 수립3. 테스트 분석 및 설계 업무 일정 관리4. 테스트의 적용, 실행, 평가에 대한 일정 관리5. 완료조건 결정

해야할 일

Page 29: Istqb 1-소프트웨어테스팅기초-2015

1. 테스트 계획과 제어(통제) [2]v 테스트 제어(통제)

– 테스트 통제는 실제 진행 상황과 계획을 비교하고 보고하는 활동

– 여기에는 프로젝트의 미션과 목표를 위해 조치가 이루어질 수 있음

– 이를 위해 프로젝트의 진행이 지속적으로 모니터링 되어야 할 것

1. 결과 측정 및 분석2. 모니터링 및 문서화의 진행, 테스트 범위, 종결기준3. 결과반영(수정, 변경 등) 활동4. 의사결정

해야할 일

Page 30: Istqb 1-소프트웨어테스팅기초-2015

2. 테스트 분석과 설계v 테스트 계획에서 제시된 목표를 테스트 케이스로 반영

1. 테스트 베이시스 리뷰(요구사항, 디자인 등)2. 테스트 대상 아이템 또는 명세, 구조 분석을 통해 테스트

상황을 식별하고 우선 순위 선정3. 테스트 케이스 설계와 우선 순위 선정4. 비공식적인 기법으로 테스트 케이스 추가 도출 및 보완5. 테스트 상황과 테스트 케이스에 필요한 테스트 데이터 식

별6. 테스크 환경 구축에 대한 디자인과 요구되는 기반 시설 및

도구 식별

해야할 일

Page 31: Istqb 1-소프트웨어테스팅기초-2015

3. 테스트 구현 및 실행v 효과적/효율적 테스트를 위해 테스트 케이스를 조합하고, 테

스트 프로시저/테스트 스크립트 작성v 테스트 환경이 구축되어 있어야 함

1. 테스트 데이터 생성2. 효과적인 테스트를 위한 테스트 프로시저 생성3. 테스트 하네스 준비4. 테스트 환경이 제대로 설정되었는지 확인5. 계획된 절차에 따라 테스트 케이스를 직접 또는 툴을 사용하여 수행6. 테스트 실행결과를 기록하고 테스트 수행 대상 및 소프트웨어 버전을

기록7. 예상 결과와 실제 결과를 비교8. 불일치하는 결과가 나오는 원인을 기록9. 각각의 불일치에 대한 반복적인 활동

해야할 일

Page 32: Istqb 1-소프트웨어테스팅기초-2015

용어

v 테스트 하네스– 테스트 드라이버 + 테스트 스텁– 테스트 드라이버 : 하위 모듈을 테스트하기 위해 이 모듈을 호출해주

는 상위의 임시 모듈– 테스트 스텁 : 상위 모듈을 테스트하기 위해 이 모듈에서 호출하는

하위의 임시 모듈

B() {bbb;

}

A() {B();

}

B() {bbb;

}

드라이버 {B();

}

스텁 {bbb;

}

A() {B();

}

호출(call) 리턴(복귀)

Page 33: Istqb 1-소프트웨어테스팅기초-2015

용어

v 테스트 오라클(Oracle)– 테스트 실행 결과가 올바른 결과인지를 판별할 수 있는 메커니즘– 참 오라클(True Oracle) : 모든 입력값에 대한 결과값 생성

• 개발에 시간/비용 (거의 불가능)– 샘플링 오라클 : 특정 몇몇 입력값에 대한 결과를 제공

• 단점: 다른 입력값에 대한 오류 검증은 못함• 장점: 비교적 쉽게 작성 가능

– 휴리스틱 오라클 : 몇몇 입력값 대한 결과 + 나머지는 휴리스틱으로결과값 제공

– 일관성 검사 오라클(Consistent Test Oracle)• 이전 버전의 프로그램 결과와 현재 버전의 프로그램 결과의 일관

성 유지 여부 검사• 대부분의 상업용 테스트 도구에서 지원하는 형태

Page 34: Istqb 1-소프트웨어테스팅기초-2015

불일치(결함)의 원인 분석

v 테스트 케이스 결함– 프로그램이 아니라 테스트 케이스 자체의 결함

v 테스트 정황 결함– 테스트 수행상의 오류, 데이터 입력 오류 등

v 어플리케이션 결함– 테스트 대상의 결함(SW, HW, 설치결함, 코드 결함 등)

v 어플리케이션 정황 결함– 사용상 오류, 테스트 환경과 관련된 SW결함

Page 35: Istqb 1-소프트웨어테스팅기초-2015

결함 유형 분류v 기획 시 유입되는 결함

– 요구사항의 표준 미준수, 테스트 불가능, 불명확, 불완전, 불일치, 기타 결함

v 설계 시 유입되는 결함– 설계 표준 미준수, 테스트불가능, 불명확, 불완전, 불일치,

인터페이스 결함, 기타 결함v 코딩시 유입된 결함

– 코딩 표준 미준수, 불완전, 불일치, 인터페이스 결함, 데이터 결함, 기타 결함

v 테스트 부족으로 유입된 결함v 마무리 부족, 팀간 의사소통 부족, 코딩 실수

Page 36: Istqb 1-소프트웨어테스팅기초-2015

결함 심각도 별 분류v 결함심각도 분류 사례

– 치명적, 매우 심각, 심각, 보통, 경미– 치명적 결함, 주요 결함, 일반 결함, 사소한 결함, 개선사

항 (37쪽 참조)

v 부적절한 사례– Major, Minor, Trifle(하찮은 것)– A,B,C

Page 37: Istqb 1-소프트웨어테스팅기초-2015

결함 우선순위v 결함 심각도와 결함 우선순위는 구분해야한다.v 모든 경우 결함심각도가 가장 높다고 해서 가장 먼저 그 결

함을 수정해야 하는 것은 아니다.

v 결함 우선순위 표현 사례– 즉시 해결– 주의 요망– 대기– 낮은 순위

Page 38: Istqb 1-소프트웨어테스팅기초-2015

4. 완료조건의 평가와 리포팅v 테스트 수행 결과를 목적과 비교하여 평가

1. 테스트 계획에 정의된 완료 기준에 따라 테스트 로그 확인2. 추가 테스트가 필요한지에 대한 평가를 하거나 완료 기준

을 변경3. 이해관계자들을 위한 테스트 요약 보고 작성

해야할 일

Page 39: Istqb 1-소프트웨어테스팅기초-2015

리포팅 내용v 발견된 결함과 미해결 결함의 추이 및 우선순위v 테스트 진척도v 리스크 및 메트릭으로 실증된 조언v 테스트 환경의 가용성v 테스트 커버리지, 결함발견 효과성/효율성, 품질평가 결과,

결함 상태별 결함 수, 소프트웨어 사이즈 대비 결함 수 등

Page 40: Istqb 1-소프트웨어테스팅기초-2015

효과적/효율적v 효과적(Effective)

– 계획되었거나 원했던 테스트 결과산출– 효과적 테스터는 테스팅 노력으로부터 어떤 결과를 도출

할 것인지 결정함v 효율적(Efficient)

– 원했던 테스트 결과 산출을 생산적으로 수행– 효율적 테스터는 가용한 리소스(시간, 자금, 인력)를 적절

하고 현명하게 배치

효과적

효율적

Page 41: Istqb 1-소프트웨어테스팅기초-2015

5. 테스트 마감 활동v 모든 테스트 활동에서 경험, 테스트 도구, 사실, 통계를 종합

하기 위해 데이터를 수집하고 완료

1. 계획된 산출물이 산출되었는지에 대한 확인, 개별 요소에대한 보고 완료, 또는 아직 수행중인 활동의 변경 기록에대한 이슈 제기

2. 시스템 인수와 관련된 문서 확인3. 유지보수 조직에 테스트 도구 인계4. 사후 관리 및 테스트 성숙도 향상 수준 분석

해야할 일

Page 42: Istqb 1-소프트웨어테스팅기초-2015

테스팅의 독립성

개발자가테스트를 설계하는

경우(낮은 수준의 독립성)

개발팀내다른 조직의 인력이테스트를 설계하는

경우

사내다른 조직의 인력이테스트를 설계하는

경우(별도의 테스트팀)

다른 조직 또는기업의 인력이

테스트를 설계하는경우

(외부기관 인증)

Part 5에서 보다 자세하게 다룸

Page 43: Istqb 1-소프트웨어테스팅기초-2015

테스팅의 심리학

v 테스트 대상 제품이나 개발자에 대한 비판으로 오해

v 좋은 대인관계가 필수적– 다툼보다는 협력으로 시작: 더 좋은 제품을 만들기 위한

공통목표– 사람에 대한 비평을 배제하고, 중립적이고 사실에 근거한

제품의 결함만 전달하려고 노력– 다른 사람의 반응에 대한 이해– 의사소통 내용을 상대방이 정확하게 이해했는지 확인

Page 44: Istqb 1-소프트웨어테스팅기초-2015

테스팅의 제약

테스팅을 투자가아닌 불필요한

비용으로 간주함

관리자나 테스터가테스팅에 대하여단편적인 지식만

가지고 있음

부족한 인력과자원으로 인해테스팅에 대한투자여력 없음

의사결정권자나프로젝트 관리자가

테스팅에 대한인식이 부족함

Page 45: Istqb 1-소프트웨어테스팅기초-2015

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

다.v 테스트는 개발 이후의 작업이다.v 개발일정에 따라 테스트는 생략될 수 있다.