2015, 봄

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

ISTQB 강의노트 4-1

테스트 설계 기법[1]

학습내용v 테스트 케이스의 구조 사례v 테스트 설계 기법의 종류v 명세기반설계기법의 종류v 명세기반설계기법

– 동등분할– 경계값분석– 결정테이블테스팅

테스트 설계 진행 방식

테스트 설계 진행 방식 결정시 고려사항

테스트 조직 구성

테스트정황(Test

Context)

테스팅과 개발 프로세스의 성숙도

시간적 제약

참여 인원

테스트 분석 과정에서는v 테스트 베이시스를 분석하여 테스트 상황 식별v 테스트 조건

– 하나 이상의 테스트 케이스로 확인 가능한 항목 또는 이벤트

– 기능, 트랜잭션, 품질특성, 구조적 요소 등v 테스트 조건과 명세 및 요구사항 사이에 추적성 부여

– 요구사항이 변경되었을 때 영향도 분석– 테스팅에 의한 요구사항 커버리지 달성 여부 확인

v 리스크를 기반으로 적절한 테스트 설계 기법 선정

테스트 설계 과정에서는v 테스트 설계기법을 이용하여 테스트 케이스와 테스트 데이

터를 설계하고 명세화v 테스트 케이스

– 특정 프로그램 경로의 실행, 구체적인 요구사항과의 일치여부 확인을 위해 디자인된 입력값의 묶음, 실행 사전조건, 기대결과와 실행 사후조건의 집합

– 특정 테스트 조건을 확인하기 위해 개발

테스트되어야 하는 특정 조건+입력값+기대결과

테스트 분석과 설계

테스트 베이시스

요구사항명세서설계서코딩 등

테스트 조건- 기능- 트랜잭션- 품질특성- 구조적요소 등

테스트 케이스+

테스트 데이터

추적가능

테스트 분석 테스트 설계

테스트설계기법

IEEE 829 소프트웨어 테스트 문서 표준

테스트 케이스의 구성요소

v ID(식별번호) : 테스트 케이스 구별하기 위한 번호v 사전조건 : 테스트가 수행되기 위해 필요한 조건

– 구동환경, 테스트 데이터 등v 테스트 수행 절차 : 구체적인 테스트 수행단계v 기대결과 : 테스트 실행결과가 의도한 대로 동작하였는지 판

단하는 근거(필수속성)v 추적성 : 해당 테스트 케이스의 바탕이 된 요구사항 등 기록v 중요도 : 시간적 제약이 있을 경우 테스트 대상을 선택하기

위한 기준v 합격/불합격 : 수행 결과에 대한 최종 확인v 비고 : 테스트 케이스의 의도 등 관련 내용 기술v IEEE 829: 소프트웨어 테스트 문서 표준

테스트 케이스 양식 사례

ID 구분 사전조건 수행절차 기대결과 P/F추적성

중요도

비고

xx1.1

전화번호검색(이름)

소프트웨어탑재-테스트 데이터: 홍길동,

ㄱ현빈, 12345,@*$1

1.전화번호부 페이지로이동2. 전화번호찾기창에서이름으로 검색

-해당 이름의 존재 여부가 검색됨- 입력값에따른 반응

설계기준서a.7.3

중간 전화번호검색기능확인

테스트 케이스 양식 사례v 절차가 간단한 경우

– 너무 자세하지 않으므로 테스트시 테스터가 다양하게 수행 가능

v 절차가 상세한 경우– 절차가 자세함– 테스트의 일관성 유지 가능– 테스터의 역량이나 이해가 조금 부족해도 실행 가능

v 테스트 수행절차를 얼마나 자세하게?– 테스터의 스킬, 능력, 해당 시스템에 대한 이해 등을 고려

하여 상세함을 조정

테스트 케이스의 목적

v 요구되는 보장성을 갖는 최소한의 테스트 케이스로 가능한많은 결함을 발견할 수 있도록

v 테스트 대상을 가능한 범위에서 빠짐없이 테스트하여 일정수준의 테스트 보장성(커버리지)을 확보

테스트 프로시저/테스트 스크립트

테스트 케이스

1 2 34

테스트 프로시저= 테스트 스크립트(수동) (자동)

테스트 실행 스케줄(누가, 언제 실행)

효율적인테스트를 위한테스트 케이스실행순서

테스트 케이스 실행 순서

v 테스트 구현단계에서 테스트 케이스를 개발하고 우선순위를선정하고 배치하여 테스트 프로시저 명세서를 만듬– 테스트 프로시저는 효율적인 테스트를 위한 테스트 케이

스의 실행 순서임v 작성된 테스트 프로시저를 언제 누가 수행할 것인지에 대한

테스트 실행 스케줄을 구성함

테스트 케이스의 범위

요구사항(기획) 실제 구현된 것

1. 요구사항에명시되어 있는데구현되지 않은 경우

요구사항을기반으로 테스트케이스만들어서 실행

2. 요구사항대로구현되었는데 때에 따라정상동작 하지 않는 경우

요구사항을기반으로 테스트케이스만들어서 실행+ 추가 테스트케이스

3. 요구사항에 없는데구현되어 있는 경우

비공식적테스트 추가 실행요구사항변경 또는해당부분 제거

4. 요구사항에 없는데구현되어 있는 부분이정상동작 안함

비공식적테스트추가 실행

- 3,4의 경우 요구사항변경하지 않으면 모두 결함- 기대결과 없어서 케이스만들기 어려움

테스트 케이스 개발 방법v 공식적인 기법을 사용하여 우선 개발

v 경험 기반의 비공식적인 기법으로 보완 개발

테스트 설계 기법의 종류[1]

v 전통적 분류– 블랙박스 테스트– 화이트박스 테스트

v 최근 분류– 명세기반 기법– 구조기반 기법– 경험기반 기법

명세기반

블랙박스

경험기반

구조기반

화이트박스

블랙박스와 화이트박스v 블랙박스

– 테스트 베이시스, 개발자/테스터/사용자의 경험을 분석하여 기능적/비기능적 테스트 조건으로 테스트 케이스 작성

v 화이트박스– 소프트웨어의 내부 구조에 바탕을 두고 테스트 케이스

작성

v 명세 기반 기법– 일반적으로 공식적/비공식적 모델을 사용– 테스트 케이스를 모델로부터 체계적으로 도출– 문서 기반

v 구조 기반 기법– 코드와 설계 등 구조를 보여주는 정보로부터 테스트 케이스 도출– 테스트 커버리지 측정가능하고 커버리지를 높이기 위해 추가적 테스

트 케이스를 체계적으로 도출v 경험 기반 기법

– 테스터, 개발자, 사용자 등의 지식 활용– 발생 가능한 결함과 그 분포 등에 대한 지식– 문서화 필요

테스트 설계 기법의 종류[2]

명세기반 기법

v 명세 기반 기법의 종류– 동등 분할(Equivalence partitioning)– 경계값 분석(Boundary value analysis)– 결정 테이블 테스팅(Decision table testing)– 상태 전이 테스팅(State transition testing)– 유즈케이스 테스팅(Use case testing)

명세기반기법-동등분할

v 특정 범위의 입력값이 같은 결과값을 출력할 경우 이러한입력값의 범위를 하나의 그룹으로 간주함

v 입력값/출력값을 유한개의 독립적인 집합으로 나누고, 각 집합의 원소 중 대푯값을 하나 선택하여 테스트 케이스를 작성함

v 동등 분할 그룹은 유효한 입력 데이터뿐 아니라 유효하지않은 입력 데이터도 포함할 수 있음

v 동등 분할은 모든 테스트 레벨 및 모든 테스트 유형에서 적용이 가능함

명세기반기법-동등분할 예제[1]

2.50V 2.80V 3.30V 3.80V 4.30V

v 배터리 용량 표시

2.50V ≤용량

< 2.80V

2.80V ≤용량

< 3.30V

3.30V ≤용량

< 3.80V

3.80V ≤용량

< 4.30V

4.30V ≤용량

용량< 2.50V

명세기반기법-동등분할 예제[2]

테스트 케이스 1 2 3 4

배터리용량 2.75 2.99 3.55 4.05

테스트된 분할2.50V ≤

용량< 2.80V

2.80V ≤용량

< 3.30V

3.30V ≤용량

< 3.80V

3.80V ≤용량

< 4.30V

기대결과

v 테스트 케이스

명세기반-경계값 분석

v 경계값 분석은 동등 분할의 경계 부분에 해당되는 입력값에서 결함이 발견될 확률이 경험적으로 높기 때문에 경계값까지 포함하여 테스트 하는 기법임

v 해당 분할영역의 최댓값과 최솟값은 그 영역의 경계값이 됨v 유효한 분할영역의 경계값은 유효 경계값이 되며, 비유효한

분할영역의 경계값은 비유효 경계값이 됨v 경계값 분석은 모든 테스트 레벨 및 모든 테스트 유형에서

적용이 가능함

명세기반-경계값 분석 예제[1]

v 배터리 용량 예제

2.50V 2.80V 3.30V 3.80V 4.30V

2.50V ≤용량

< 2.80V

2.80V ≤용량

< 3.30V

3.30V ≤용량

< 3.80V

3.80V ≤용량

< 4.30V

4.30V ≤용량

용량< 2.50V

경계값

명세기반-경계값 분석 예제[2]

v 경계값 분석에 의한 테스트 케이스

테스트케이스

1 2 3 4 5 6 7 8 9

입력값

2.49 2.50 2.79 2.80 3.29 3.30 3.79 3.80 4.29

기대결과

명세기반-결정테이블

v 결정 테이블은 논리적인 조건이나 상황을 구현하는 시스템에서 요구사항을 도출하거나 내부 시스템 설계를 문서화하는데 유용함

v 시스템이 구현해야 하는 비즈니스 규칙을 문서화하는데 사용

v 결정 테이블에서 입력조건과 기대결과는 참과 거짓으로 표현함

v 결정 테이블의 각 컬럼당 적어도 하나의 테스트 케이스를생성

명세기반-결정테이블v 장점

– 논리적으로 의존적인 가능한 모든 조건들의 조합을 생성– 요구사항 등 테스트 베이시스의 문제점을 효과적으로 발

견하기 위한 테스트 케이스 생성 가능

v 단점– 작성에 많은 노력과 시간이 소요될 수 있음– 복잡한 시스템을 표현하기 어려울 수 있음– 논리적으로 작성시 실수 가능성 있음

명세기반-결정테이블 실습

16세에서 65세 사이의 그룹은 세금을 내야 한다.

소득이 20,000달러 미만인 사람은 20% 세금을 내야하고,

그 외 사람은 50% 세금을 내야 한다.

만약 이 사람들 중 아이가 있으면 10% 감세를 받을 수 있다.

명세기반-결정테이블 실습

속성 1 2 3 4 5 6 7 8

나이

16~65

소득

<20000

자녀=Y

세금20%

세금50%

감세10%

예상결과

테스트조건

명세기반-결정테이블 실습

속성 1 2 3 4 5 6 7 8

나이

16~651 1 1 1 0 0 0 0

소득

<200001 1 0 0 1 1 0 0

자녀=Y 1 0 1 0 1 0 1 0

세금20% ● ●

세금50% ● ●

감세10% ● ●

예상결과

테스트조건

명세기반-결정테이블 실습v 테스트 케이스

속성 1 2 3 4 5 6 7 8

나이

16~6516 65 30 64 15 66 99 1

소득

<2000019999 15000 20000 99000 1000 10000 21000 30000

자녀=Y Y N Y N Y N Y N

기대결과소득*20%*90%

소득*20%

소득*50%*90%

소득*50%

0% 0% 0% 0%

명세기반-결정테이블 실습(105쪽)

유료 PC(인터넷) 사용

로직테스트 케이스ID

1 2 3 4 5 6

테스트조건

유효한 지폐 N Y - - - -

유효한 카드 - - N Y Y Y

유효한 암호 - - Y N Y Y

허가된 금액 - - - - N Y

예상결과

지폐 거부 Y N N N N N

카드 거부 N N Y Y N N

낮은 금액 입력 요청 N N N N Y N

인터넷 사용시간 판매 N Y N N N Y