Istqb 4-테스트설계기법-2015-2-1-배포

2015, 봄학기

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

ISTQB 강의노트 5

테스트 설계 기법[2]

학습내용

v 명세기반 설계기법– 상태전이테스팅, 유즈케이스테스팅

v 구조기반 설계기법– 커버리지– 구문테스팅, 결정테스팅

상태 전이 테스팅이란?

v 시스템은 현재 상황과 이전의 이력을 반영하는 상태 및 그변화에 따라 다르게 동작할 수 있음– 시스템을 상태 사이의 관계로 파악

v 상태 전이 다이어그램으로 표현할 수 있으며, 이 다이어그램을 바탕으로 테스트 케이스를 도출함– 상태간의 전이– 상태를 변화시키는 이벤트와 입력값– 상태의 변화로 유발되는 동작 등 파악

v 시스템의 상태기반 행위가 명세된 내용과 일치함을 검증

상태 전이 다이어그램 예제

v 음료 자판기의 상태전이 다이어그램

음료선택

금액투입대기

ev취소/투입금액반환;라이트리셋()

ev음료버튼선택/캔방출();잔액반환();잔량수정()

ev금액투입[투입금액>=가격]

ev취소/투입금액반환()

ev금액투입[투입금액<가격]



상태 전이 테스팅이란?

v 상태 전이 다이어그램을 기반으로 상태-이벤트 테이블 작성v 임베디드 시스템, 자동화가 필요한 부분에서 주로 사용

v 상태 전이 테스팅을 통한 테스트 설계 방식– 전형적인 상태의 순서를 커버하는 방식– 모든 상태를 커버하는 방식– 모든 상태 전이를 실행하는 방식– 특정한 상태 전이 순서를 실행하는 방식– 불가능한 상태 전이를 테스트하는 방식

상태 다이어그램 표기법

v 다이어그램 표기법 : 106쪽 표 4.7 참조

요소 설명 표기법

상태하나 또는 그 이상의 이벤트를 기다리는 시스템 모드

원, 원 안에 상태명 표시

전이이벤트에 의해 한가지 상태에서다른 상태로의 변경

화살표

이벤트 상태의 전이를 유발하는 요인화살표에 이름과 값으로 표시(예: ev취소)

가드 이벤트가 발생하는 조건이벤트 오른편의 [ ]안에 조건이나 값으로 표시

액션상태의 전이에 따라서 유발되는동작

화살표에 이름과 값으로 표시(예: ev취소/투입금액반환)

상태전이테스팅으로 발견할 수 있는 결함

v 명세가 잘못된 경우(모델상의 결함)– 초기 상태 누락– 전이 또는 액션의 누락– 가드를 전이 대신 표기함– 가드의 중복 또는 불일치

v 구현이 잘못된 경우– 상태: 여분/누락/훼손– 액션이 틀리거나 누락됨– 스니크 패스, 트랩도어

인스펙션리뷰정적분석툴

동적 테스팅

테스트 케이스 도출 순서

v 상태 전이 다이어그램을 바탕으로 테스트 케이스 도출 순서

① 상태-이벤트 테이블 구성② 전이 트리 구성③ 반응(유효) 테스트 케이스 구성④ 무반응(비유효) 테스트 케이스 구성⑤ 가드 또는 조건 테스트 케이스 구성⑥ 테스트 프로시저 구성

상태 전이 테스팅 예제

v 음료 자판기의 상태전이 다이어그램(117쪽)

음료선택

금액투입대기

ev취소/투입금액반환;라이트리셋()

ev음료버튼선택/캔방출();잔액반환();잔량수정()


ev취소/투입금액반환()





v 상태-이벤트 테이블 구성

상태이벤트

대기 금액투입 음료선택


음료선택 음료선택


금액투입 금액투입

ev음료버튼선택 대기

ev취소 대기 대기


v 전이트리

대기

음료선택

금액투입

대기

대기

음료선택

금액투입

대기

음료선택

대기

대기

음료선택

금액투입

음료선택

금액투입

path 1

path 2

path 3

path 4

path 5

path 6

path 7

path 8

path 9


v 반응(유효) 테스트 케이스 구성

StartState

Event Action NextState

Event Action FinalState

V001(path1)

대기

ev금액투입[투입금

액>=가격]* 1000원

-음료선택

ev음료버튼선택

캔방출;잔액반화(700원);잔량업데이터(9)

대기

V002(path2)

대기

ev금액투입[투입금

액>=가격]* 1000원

-음료선택 ev취소

투입금액반환(1000

원);라이트리

셋

대기

유즈케이스 테스팅이란?

v 유즈케이스나 비즈니스 시나리오를 기반으로 테스트를 명세화 할 수 있음

v 시스템이 유즈케이스로 모델링되어 있을 때 유즈케이스에서테스트 케이스를 도출하는 테스트 설계기법– 아직 완전하게 정립된 상태가 아님

v 유즈케이스 명세서– 시스템이 제공하는 기본 단위 기능을 정의– 유즈케이스와 액터(사용자, 시스템)간의 상호작용

유즈케이스 테스팅

v 유즈케이스는 시스템을 실제 사용하는 방식에 기반하여 프로세스 흐름을 기술함

v 따라서 유즈케이스에 기반하여 생성된 테스트 케이스는 시스템이 실제 사용되는 프로세스 흐름에서 결함을 발견하는데 유용함

v 인수테스팅에 유용함

유즈케이스 테스팅의 종류

v 컴포넌트(단위) 레벨 유즈케이스 테스팅– 액터와 유즈케이스 간의 상호작용 테스팅– 개별적인 유즈케이스에 대한 단위테스팅

v 시스템 레벨 유즈케이스 테스팅– 유즈케이스 간의 상호작용과 활동을 테스팅

유즈케이스 테스팅 예제

v 123쪽 예제v 기본흐름과 대체흐름 각각을 시나리오로 보고 테스트 케이

스로 매핑

기본흐름S0-정상출금

A1) 비유효 카드S1-카드 판독 불능

A3) 2회 부정확한 암호S3-부정확한 암호 A4) 잔액 부족

S4-잔액부족

A2) 부정확한 암호S2-부정확한 암호(재시도 허용)

유즈케이스 테스팅 예제

v 출금 유즈케이스의 테스트 케이스

테스트케이스

시나리오 카드번호 암호 출금금액 계좌잔액 예상결과

TC0 S0 Valid Valid 금액<=잔액 정상출금

TC1 S1 Invalid N/A N/A N/A카드

판독불능메시지

유즈케이스 예제

v 요구사항: 채용담당자는 채용공고를 게시할 때 신용카드로 결제할 수 있다.

주 행위자(액터) 채용 담당자

전제조건 채용정보가 입력되었지만 아직 볼 수는 없다.

성공보장 채용공고가 등록되었음. 채용담당자의 신용카드로 결제되었음.

주 성공시나리오(기본흐름)

1. 채용담당자는 신용카드번호, 날짜, 인증정보등을 입력한다.2. 시스템은 신용카드를 검증한다.3. 시스템은 신용카드 결제를 수행한다.4. 등록한 채용공고를 구직자들이 조회할 수 있다.5. 채용담당자는 고유한 등록 확인 번호를 부여받는다.

확장(대체흐름) 2a. 시스템이 처리할 수 없는 카드 종류다.2a1. 시스템은 사용자에게 다른 카드를 사용하라고 통지한다.

2b. 카드의 ID번호가 잘못되었다.2b1. 시스템은 사용자에게 다른 카드를 사용하라고 통지한다.

2c. 카드의 유효기간이 지났다.2c1. 시스템은 사용자에게 다른 카드를 사용하라고 통지한다.

3a. 카드의 신용한도가 부족하다.3a1. 시스템은 결제할 수 있는 만큼 결제한다.3a2. 사용자는 이에 대해 통지받고, 잔액결제를 위해 두번째 카드를

정보를 입력하라는 요청을 받는다. 단계2에서 계속된다.

유즈케이스 예제

v 주 성공 시나리오(기본 흐름)– 1, 2, 3, 4, 5

v 대체 흐름– 1, 2, 2a, 2a1, 2, 3, 4, 5– 1, 2, 2b, 2b1, 2, 3, 4, 5– 1, 2, 2c, 2c1, 2, 3, 4, 5– 1, 2, 3, 3a, 3a1,3a2, 2, 3, 4, 5

구조기반 기법[1]

v 구조기반기법– 소프트웨어 코드나 설계 등 구조를 보여주는 정보로부터

테스트 케이스 도출– 소프트웨어의 커버리지 정도가 기존 테스트 케이스로부

터 측정되고 커버리지를 늘리기 위해 추가적 테스트 케이스를 체계적으로 도출

구조기반기법[2]

v 컴포넌트 레벨– 구문(문장), 결정 또는 분기문 등 코드 그 자체– 화이트 박스 테스트

v 통합 레벨– 한 모듈이 다른 모듈을 호출하는 관계를 도식화한 콜 트

리

v 시스템 레벨– 메뉴 구조, 비즈니스 프로세스, 웹 페이지 구조 등

커버리지

v 커버리지– 시스템 또는 소프트웨어의 구조가 테스트 스위트(test

suite)에 의해 테스트된 정도– 테스팅의 충분함을 측정– 커버리지가 100%가 아니면 누락된 아이템을 테스트하기

위해 추가적인 테스트 설계

v 결정포인트– 조건식 등

커버리지 종류

v 구문 커버리지v 결정(분기) 커버리지(Decision coverage, DC)v 조건 커버리지v 조건/결정 커버리지v 변경조건/결정 커버리지(Modified Condition/DC)v 다중 조건 커버리지

제어흐름도

v 노드와 간선(edge)으로 제어(실행) 흐름을 표현한 것v 경로(path): 노드의 실행 순서를 표시

– 완전경로: 시작노드와 종료노드를 포함한 전체 경로– 부분경로: 완전경로에 포함되는 경로

v 결정포인트: 분기노드 -> 소스코드 상의 if, while, for, switch문

D

and, or 연산

v AND연산(A&&B=C)

A B C

0 0 0

0 1 0

1 0 0

1 1 1

v OR연산(A||B=C)

A B C

0 0 0

0 1 1

1 0 1

1 1 1

결정포인트(조건식)

if ( a > b and a < c )

전체 조건식개별 조건식개별 조건식

요약

if (A and B) {1을 실행;

}else {

2를 실행;}

Dpoint(결정포인트) A B

0 1 0

1 1 1

결정커버리지


0 1 0

0 0 1

조건커버리지


0 0 0

1 1 1

조건/결정커버리지

결정포인트

구문 테스팅과 커버리지

v 구문 커버리지– 테스트 스위트에 의해 실행된 구문이 몇 %인지 측정– 코드의 모든 구문을 실행할 수 있는 입력값이나 이벤트

등의 테스트 데이터로 실시– 100% 구문 커버리지는 프로그램내의 모든 구문을 적어

도 한번씩 접근하여 테스트하는 것을 의미v 적은 개수의 테스트 케이스로 쉽게 달성v 코드상에 존재하는 가능한 경우를 모두 검증하지 못함v 커버리지 중 보장성이 가장 낮음

결정 테스팅과 커버리지

v 테스트 케이스 스위트에 의해 실행된 조건문(if문의 참,거짓) 분기가 전체 가능한 분기의 몇 %인지 측정

v 결정포인트 내의 전체 조건식이 참, 거짓 양쪽 경우 모두 테스팅– 129쪽 표 4.20 참조– 테스트 케이스는 최소 2개

v 결정포인트에 해당하는 제어 흐름을 다루므로 제어흐름 테스팅의 한 형태– 제어흐름테스트는 공식적인 화이트박스 테스트 설계기법

v 분기테스팅, 분기커버리지라고도 함

제어흐름테스트: 133쪽

D2

D3

2

5 6

7

D1

1

3 4

8

1.모든 흐름을 최소한번씩 지나가도록

2.(각 결정포인트 간) 흐름의 조합을 모두지나가도록

3.반복적인 흐름을 포함하는 모든 경우를고려

D2

D3

2

5 6

7

D1

1

3 4

8





TC1: (1,2,8,3,5,7)


D2

D3

2

5 6

7

D1

1

3 4

8




TC2: (1,3,6,8,4,7)


D2

D3

2

5 6

7

D1

1

3 4

8




134쪽, 135쪽 참조

v 다음 코드에서 100% 구문 커버리지를 달성하려면 얼마나많은 테스트를 해야 하나?

1 if (x==3) then2 display_messageX;3 if (y==2) then4 display_messageY;5 else6 display_messageZ;7 else8 display_messageZ;

X==3

msgZ

y==2

msgZ

msgX

msgY

Istqb 4-테스트설계기법-2015-2-1-배포

Software

Transcript of Istqb 4-테스트설계기법-2015-2-1-배포