AT2_테스트 케이스 설계

3 장 테스트 케이스 설계

107

3. 테스트 케이스 설계 3.1 테스트 계획 3.2 테스트 케이스 3.3 블랙 박스 테스트 3.3.1 동치분해 3.3.2 경계값 테스트 3.3.3 추적 메트릭스 3.3.4 의사 결정 테이블 3.3.5 상태 천이도 3.4 화이트 박스 테스트 3.4.1 개요 3.4.2 테스트 커버리지 3.4.3 McCabe와 기본 경로 테스트 3.5 입력 도메인 분석 기법 3.6 기능 분석 3.7 테스트 케이스 최소화

1) 테스트 케이스의 정의를 배운다.

2) 단위 테스트 기술, 즉 블랙박스, 화이트박스, 입력 도메인 분석 기법, 기능

분석 기법을 익히고 각 방법으로 테스트 케이스를 설계할 수 있는 능력을

배양한다.

3) 각 기법으로 테스트 케이스를 찾고 문서화할 수 있게 한다.

4) 수행 및 재사용이 가능한 테스트 케이스를 설계할 수 있다.

5) 오류를 기록하고 평가할 수 있게 한다.

소프트웨어 테스트 전문기술

108

제 3 장 테스트 케이스 설계

소프트웨어 테스트 작업의 핵심은 테스트 케이스를 작성하는 일이다. 테스트 케

이스를 구체적으로 작성하지 않고 테스트한다는 것은 계획 없이 즉흥적으로 테스트 데이터를 입력해보고 적당히 프로그램이 수행되는 것을 확인하는 작업에 지나지 않

으며 이런 식의 테스트는 프로그램에 내재된 오류를 찾아내기가 어렵다. 테스트 엔지니어를 위한 교육에서 제일 우선되어야 할 작업은 도대체 테스트 케

이스가 어떻게 생긴 것인지 보여주는 것이다. 이것이 테스트 기법을 설명하는 것보

다 중요하다. 왜냐하면 테스트 기법을 잘 이해하였다 하더라도 테스트 케이스가 무

엇인지 모르고 작성할 수 없다면 테스트 작업을 수행할 수 없기 때문이다. 테스트 케이스는 테스트 계획을 이루는 원소와도 같은 존재이다. 마치 TOEFL 테

스트로 영어 능력을 평가한다고 할 때, 각 문항은 수험생의 영어 능력을 테스트하

는 최소 단위의 질의이다. 문제를 출제할 때 각 문항은 비슷한 유형끼리 모아 놓는

다. 예를 들어 독해 능력 평가, 듣기 능력 평가, 문법 이해도 평가와 같이 나누고 분야별 질의 문항을 만들어 나간다.

[그림 3-1] 계획된 작업


109

테스트 계획도 유사한 개념으로 각 문항을 작성하는 것이 테스트 케이스이며 이

를 모아서 테스트 슈트로 구성하고 테스트 슈트들을 모으면 테스트 계획서가 된다. 따라서 테스트 계획이 얼마나 걸릴 것이며 인원, 장비 등 비용 소모에 대한 계산도 테스트 케이스에 근거한 예측이 정확하다.

이 장에서는 우선 테스트 계획과 테스트 슈트 및 테스트 케이스와의 관계를 설명

하고 소규모의 테스트 작업에서 블랙 박스 테스트와 화이트 박스 테스트 방법을 이

용한 테스트 케이스 작성 방법에 대하여 기술한다. 또한 대규모 소프트웨어 시스템

의 테스트에서 가장 중요한 부분인 기능 분석에 의하여 테스트 케이스를 만들어 내

는 과정을 자세히 예를 들어 소개한다. 3.1 테스트 계획

소프트웨어 프로젝트 관리에서 계획이 중요한 것처럼 소프트웨어 테스트에서도

계획이 중요하다. 테스트 계획의 중요성을 다음과 같이 강조하고 있다. “소프트웨어 테스트는 일부 직관적일 수 있으나 크게 보아 시스템적이다. 좋은

테스트는 프로그램이 잘 작동하는지 검사하기 위하여 잠깐 수행시켜 보는 것 이상

의 작업이 포함되어야 한다.” – Cem Kaner “프로그래머, 테스트 엔지니어, 프로그래밍 매니저 누구든 원시코드를 설계하고

테스트하여야 하는 것은 알고 있지만 테스트 자체를 설계하고 수행하여야 한다는 사실은 인지하지 못하는 경우가 많다. 설계 절차가 있다고 해도 잘 따르지 않고 원

시코드의 설계와 테스트 보다는 컨트롤이 심하지 않다.” – Boris Beizer “테스트는 프로젝트 첫날부터 시작된다. 누가 프로젝트를 위하여 좋은 아이디어

가 생각났다고 하자. 옆에 있던 사람이 “좋아, 그러나 작동할까?”라고 질문 하였다

면 그 순간 테스트는 시작되는 것이다.” – Richard Ball

[표 3-1] 테스트 계획의 중요성

테스트 작업에서 겪는 대부분의 어려움은 준비 없이 테스트 작업에 바로 들어가서

비효율적으로 일을 진행하게 된다. 모든 일이 작업 중심적이며 마감을 맞추기 위

한 압력을 받기 때문에 계획을 느슨하게 잡거나 계획 없이 일하게 된다

테스트가 너무 복잡하고 너무 중요하다는 이유로 실패하는 경우는 없다.

테스트 계획을 하는 목적은 테스트 수행을 준비하고 잘 조직화하려는 것이다.


110

3.1.1 테스트 계획의 중요성

테스트 작업 절차를 계획하는 이유는 다음과 같다.

소프트웨어 사용자들은 대부분 예측한 품질 수준 이하의 제품을 사용하는 것

을 참지 못한다. 따라서 계획과 조직 없이 테스트 작업에 투여한 시간과 자원

은 한낮 추측에 불과하며 소프트웨어가 사용될 준비가 되었는지 확인하는 작

업도 단지 피상적인 허상에 불과하다. 최근 시스템은 인터넷, GUI, 클라이언트 서버 등의 새로운 기술로 복잡하고

서로 연관된 다수의 서브시스템이 통합되어 있다. 따라서 간단한 테스트로는 만족할만한 수준의 작업이 되지 않는다.

테스트 계획, 테스트 케이스 개발, 테스트 수행 과정을 나누는 것이 중요하다. 이런 작업들이 분리되지 않고 뒤섞여 있다면 효과적이고 사려 깊은 테스트 케이스를 디자인 할 수 없게 된다.

계획을 잘 하면 테스트 작업을 효과적으로 모니터링할 수 있고 향상시킬 수 있어 불필요한 비용이나 시간을 제거할 수 있다. 효과적인 계획이 없으면 테

스트 작업의 효율성은 떨어진다. 축적된 경험으로부터 가이드라인이나 표준을 만들면 되풀이되는 시행착오를 피할 수 있다.

테스트 케이스 라이브러리를 다시 사용할 수 있도록 잘 구성하면 개발 후 시

스템에 수정이 가해질 때 다시 테스트하는 작업이 수월해진다. 테스트 케이스를 체계적으로 잘 구성하는 것이 효과적인 테스트 케이스 설계

및 테스트 자동화에 필수적이다. 도구는 수동으로 테스트하는 사람에게 손으

로 지시하는 것과 같은 방식을 따라갈 수는 없다. 테스트는 매우 중요하므로 준비와 계획을 작성한 후 수행할 충분한 가치가

있다. 테스트 계획은 시스템이 어떻게 테스트될 것인지를 나타내는 계약서와 같은 것이다.

적절한 테스트를 하기 위하여 시간, 비용, 자원이 필요하다. 테스트를 위하여 소요되는 인력, 장비, 도구 등을 파악한 계획 없이는 테스트를 위한 자원을 예측하고 획득하기가 쉽지 않다.

3.1.2 테스트 계획의 정의와 특성

테스트 계획이란 다음과 같은 사항을 적은 문서를 말한다.

테스트의 목적, 범위, 방향, 접근 방법


111

테스트 환경과 테스트 절차 테스트 시작 조건 테스트 종료 조건 및 결과 보고 조건 테스트 중단 및 재개 조건 가정, 리스크, 전제 조건 자원(인력, 테스트 장비) 계획과 일정

또한 테스트 계획은 아무리 작은 규모의 프로젝트이더라도 우선 순위와 순서가

표시된 테스트 케이스가 포함되어야 한다. 이러한 사항은 자세한 테스트 작업 문서

에 첨부될 수도 있다.

테스트 계획은 다음과 같은 질문의 대답을 찾는 것으로 시작한다.

테스트에 성공하기 위하여 우리가 특히 필요한 것은 무엇인가?

잘 작성 된 테스트 계획

잘 작성된 테스트 계획은 목표와 목적이 잘 정의되어 있어야 한다. 테스트 작업의 주

된 목표는 시스템을 릴리스 할 때 수반되는 리스크에 관한 정보를 주는 것이다.

테스트 계획은 독자, 즉 테스트 엔지니어가 잘 이해하고 수행할 수 있도록 작성되어

야 한다. 논리적이어야 하며 중복을 최소화 하여야 한다. 또한 계속 변경할 수 있어야

하고 현재 테스트 기술, 테스트 케이스 라이브러리, 테스트 도구 및 장비들을 재사용할

수 있도록 효율적으로 작성하여야 한다.

작성된 문서는 (1) 비즈니스 기능, (2) 기술적 및 운영 환경, (3) 테스트 계획 기술,

(4) 실제 테스트 수행할 인력들을 잘 알고 있는 사람이 검토하는 것이 좋다.

테스트 문서에는 자세한 작업 분담, 체크 포인트, 작업 현황을 보고하고, 트래킹 하

며 모니터링할 수 있는 장치가 언급되어야 한다. 무엇보다 테스트 엔지니어의 역할과

의무를 명확히 정의한다. 중간 점검 일정, 목표 일정, 예산도 현실성 있게 작성하여야

한다.

테스트 계획은 개발 초기에 작성되어 분석, 설계, 코딩 작업에 도움이 되어야 한다.

적절한 자동화 도구를 활용하고 테스트 작업에 도움이 될만한 도구와 절차를 사용한

다. 테스트 작업에서 설정한 가정을 명확히 작성한다.


112

테스트 범위는? 누가 테스트를 담당할 것인가(테스트 결과가 누구에게 귀속되는가)? 어떤 정도의 신뢰도와 청결도로 테스트 할 것인가? 명세서가 충분히 테스트 작업을 위한 기준이 되는가? 마감일, 자원의 제약, 예산은 어느 정도인가?

테스트 계획과 관련된 용어

테스트 슈트(test suite) – 연관된 테스트 케이스의 집합. 테스트 슈트는 소프트웨어 시

스템을 구성하는 비즈니스 기능의 일부와 관련된 테스트 케이스의 집합이다. 예를 들어

GUI 테스트, 데이터 베이스 테스트라는 테스트 슈트를 구성할 수 있다. 테스트 타입과

관련된 슈트, 예를 들면 성능 시험, 보안 시험 등과 관련된 테스트 케이스들을 한데 묶

어 테스트 슈트로 구성할 수 있다.

테스트 스펙 – 전체 테스트 계획의 일부로 특정한 테스트 작업을 기술한 것이다. 스펙

에는 (a) 테스트 할 조건이나 기능, (b) 입력 데이터값과 예상 결과, (c) 테스트 케이스

를 수행하기 위한 초기 조건 및 절차가 포함되어 있어야 한다.

테스트 스크립트 – 테스트 조건, 테스트 환경, 테스트 절차가 동일한 테스트 케이스의

패밀리. 테스트 스크립트는 주로 자동화된 테스트 도구에서 수행되기 위하여 작성한 프

로그램을 말한다. 테스트 작업을 수동으로 하는 경우 테스트 절차라고 한다.

테스트 케이스(test case) – 테스트 작업을 위하여 준비된 테스트 입력 데이터와 수행

후 예상되는 결과를 말한다. 입력값은 시험해 보기 위한 실제 데이터 값과 환경 설정을

위한 초기값 등도 포함된다.

테스트 스텝(test step) – 테스트 케이스를 실행하기 위한 최소 작업 단위. 여러 다른 테

스트 케이스에서 공동으로 사용될 수 있다. 예를 들어 고객의 ID 번호로 이름을 찾는

테스트 케이스가 있다고 하자. 이것을 테스트 하려면 사용자와 소프트웨어 시스템 사이

에 키보드와 마우스를 여러 번 작동 작동하여야 한다.

예를 들어 커서를 시작 위치에 이동시켜 놓고 고객 ID를 입력한 후 엔터를 치면 시스템

이 ID를 이용하여 고객을 검색한 후 커서를 원래의 위치로 옮겨 놓는다. 여기까지의 작

업은 더 이상 쪼갤 수 없는 테스트 작업 최소 단위(atomic task)이다. 이를 테스트 스텝

이라 하고 나중에 다른 테스트 작업에 다시 이용될 수 있으며 테스트 자동화에 매우 중

요한 개념이다.

테스트 절차(test procedure) - 테스트 절차는 테스트 케이스를 어떤 순서로 수행시킬


113

것인지 차례로 적어 놓은 것이다. 테스트 절차는 (1) 테스트를 준비하는 단계, (2) 테스

트를 수행하는 단계, (3) 결과를 모으고 분석하는 단계로 나눌 수 있다. 일반적으로 테

스트 절차는 테스트 데이터(입력값, 예상 결과)와 분리하여 작성한다. 테스트 데이터는

테스트 케이스 안에 저장하고 테스트 케이스를 어떻게 수행시키는지 알아보려면 테스트

절차를 참조하면 되도록 구성한다. 여러 테스트 케이스에 공통으로 적용되는 테스트 절

차는 한번만 기술하여 다시 이용할 수 있도록 하면 효과적이다.

테스트 사이클 – 테스트 케이스는 반복적으로 실행된다. 이를 테스트 사이클이라 한다.

테스트 사이클이 사용되는 경우는 다음 세 가지이다. (1) 소프트웨어 시스템이 날짜와

관련된 수행을 하는 경우. 시스템과 데이터베이스가 날짜와 관련된 트랜젝션이나 수

행흐름을 포함하여 테스트 수행에서도 날짜 개념이 고려되어야 한다. 예를 들어 대출

프로그램은 대출이 설정된 후 이자와 원금을 갚는 트랜섹션이 매달 일어나야 한다. 이

렇게 되면 테스트의 매 사이클마다 트랜젝션을 수행시키고 다음 달에 반복 테스트 하여

야 한다. (2) 시스템의 오류로 인하여 수정한 경우, 테스트, 디버깅, 수정이 반복적으로

일어난다. (3) 통합 시험에서 컴포넌트들을 묶어 중간 크기로 시험한 후 중간 크기의 서

브 시스템들을 모아서 또 시험하게 된다. 이 경우도 반복적인 테스트, 즉 사이클이 발

생한다.

3.1.3 테스트 계획의 유형

테스트 계획은 수행되는 테스트의 유형에 따라 다르게 작성하여야 한다. (1) 새로 개발하는 소프트웨어를 위한 테스트

새로 개발하는 소프트웨어는 단위 시험, 통합 시험, 인수 시험 등의 단계에 따라 작성한다. 단위 시험 계획은 시스템 테스트 계획과는 달리 코드 기반으

로 매우 세부적이며 간단하다. 단위 테스트는 작은 모듈 안의 한정된 범위를 다루며 프로그래머가 직접 담당하므로 그렇게 복잡하지 않다. 일반적으로 단

위 테스트를 위한 시험 계획은 공식적으로 작성하지 않는다. 프로그래머가 코

드에 익숙하고 테스트 케이스를 잘 알고 있기 때문이다. 반면 시스템이나 인수 시험 계획은 시스템의 한 부분이 아니라 전체에 대한

기능을 블랙박스로 시험하는 것이 일반적이다. 나중에 시스템 테스트 계획의 사례를 제시할 것이다.


114

[그림 3-2] 테스트 계획과 스펙

테스트 계획은 테스트 작업의 규모에 따라 축소되거나 확장될 수 있다. 예

를 들어 10명이 3개월에 걸쳐 작업하는 테스트와 1주만에 끝날 수 있는 테스

트 작업을 위한 테스트 계획은 달라야 한다. 복잡한 테스트 계획은 작성하는 데만 1주일 이상 걸릴 수 있기 때문에 작업 크기에 따라 계획서의 내용은 조

절되어야 한다.

(2) 변경 및 유지보수를 위한 테스트 유지보수나 기능 향상을 위한 테스트 계획은 다음 세 가지로 구성된다. (a) 변경 자체를 위한 테스트 계획. 변경 요청으로 수정된 부분에 대한 테스

트. (b) 변경에 의하여 영향 받을 수 있는 부분에 대한 테스트.

테스트 계획

시스템기능 테스

트

기능 1 1

기능 2 2,3

테스트 스펙

(테스트 1)

테스트할 기능

테스트 방법

조건

테스트 스크립트

(테스트 1)

테스트 데이터

테스트 절차

1. ____________

2. ____________

3. ____________

테스트 분석 리포트

(테스트 1)

테스트 결과

______________

______________

______________

______________


(테스트 2)

테스트 결과

______________

______________

______________

______________


(테스트 3)

테스트 결과

______________

______________

______________

______________


(테스트 2)

테스트 데이터

테스트 절차

4. ____________

5. ____________

6. ____________


(테스트 3)

테스트 데이터

테스트 절차

7. ____________

8. ____________

9. ____________

테스트 스펙

(테스트 2)

테스트할 기능

테스트 방법

조건

테스트 스펙

(테스트 3)

테스트할 기능

테스트 방법

조건

수행

수행

수행


115

의도하지 않았던 변경의 2차적 영향을 테스트하는 것으로 변경한 부분 이

외에 영향이 있을 것으로 판단되는 부분을 테스트한다. (c) 변경 후에 시스템의 대부분을 시험하는 리그레션 테스트.

(3) 소프트웨어 패키지 설치 테스트

소프트웨어 패키지를 위한 테스트 작업은 맞춤식 개발이나 유지보수와는 다

른 접근 방법이 필요하다. 단위 테스트는 주로 공급자가 수행하며 소프트웨어 패키지는 이미 다른 사용자들이 사용하면서 충분히 필드 테스트한 것이다. 따라서 소프트웨어 패키지 테스트는 설치용도에 맞추려고 표준 패키지에 수정

이 가해진 부분에 초점을 두어야 한다.

(4) 반복/나선형/프로토타이핑 테스트 프로토타이핑 개념으로 시스템을 개발할 때 시스템의 기능에 대한 정확하고

확실한 정의가 없을 수 있다. 시스템의 기능 명세가 계속 바뀌고 개선되어 나

가기 때문이다. 폭포형 개발 단계는 테스트 계획을 작성하는데 충분한 시간을 가지고 준비

할 수 있으나 반복형 개발은 테스트 계획을 준비하고 수행하는 데 시간이 충

분하지 않을 수도 있다. 테스트가 자주 수행되어야 하고 수정이 반복되기 때

문이다. 따라서 전통적인 기능 중심의 일회적 테스트 계획은 적합하지 않을 수 있다.

(5) 컴포넌트 재사용 테스트 컴포넌트 테스트를 위한 계획에는 (a) 통합되기 전 현재 컴포넌트가 무엇인지, (b) 어떤 새로운 컴포넌트가 추가되며 현재 컴포넌트는 무엇이 향상되는지, (c) 어떤 테스트 인프라가 사용 가능한지, (d) 컴포넌트 사이의 인터페이스는 어떻

게 테스트할 것인지, (e) 통합 후 전체 시스템은 어떻게 시험할 것인지 기술하

여야 한다.

(6) 특수 테스트 타입 소프트웨어 시스템의 기능을 테스트하는 것 이외에 여러 가지 특수한 사항,

예를 들면 소프트웨어 형상 테스트, 사용성(usability) 테스트, 보안 테스트, 오류 회복 테스트, 데이터베이스 통합 테스트, 성능 테스트 등이다.

이런 특수 타입의 테스트는 다른 테스트 환경과 기술이 필요하다. 각 타입마

다 고유한 접근 방법과 기술이 적용되어 별도의 테스트 계획으로 작성한다. 별

도로 작성된 계획서를 한데 묶어 테스트 마스터 계획 안에 포함시킬 수도 있다.


116

3.1.4 테스트 계획 아웃트라인

테스트 계획에 포함되어야 할 내용을 간단히 아웃트라인과 함께 소개하면 다음과

같다. [표 3–2] 테스트 계획의 목차

1 배경과 목적

1.1 배경

이 문서는 서점의 주문 입력 시스템에 대한 테스트 계획의 개요를 설명한 것이다. 서점

은 주로 컴퓨터 분야의 책을 취급하고 있고 여러 고객의 책을 주문 받아 공급한다. 주

요한 비즈니스 프로세스는 다음과 같다.

창고에 보관하고 있는 책의 구매 가능에(책값 등) 대한 질의

고객을 위한 책 주문 입력

주문 처리 상태에 대한 질의

1.2 테스트 목적

테스트 목적은 새로운 주문 입력 시스템에 대한 기능과 처리가 만족할 만한 수준으로

신뢰성 있게 개발되었는지 확인하는 것이다.

2. 테스트 접근 방법

2.1 전체적인 접근 방법

테스트 팀은 서점의 경영과 업무를 잘 알고 있는 경험 많은 테스트 엔지니어가 리드한

다.

테스트는 비즈니스 업무를 잘 알고 있는 시스템 사용자, 즉 서점의 직원이 수행한다.

이들의 주 임무는 사용자 대신에 시스템의 기능을 테스트하는 것이다.

시스템의 기능을 살펴보아 테스트 작업 중 자동화가 가능한 부분은 자동화한다.

2.2 시스템 사용자

시스템 사용자는 서점의 직원이다. 서점의 직원은 전화나 우편, 이메일을 이용하여 주

문을 받아 처리한다. 고객 서비스 그룹은 약 25명의 직원이 고용되어 있고 시스템을 사

용할 수 있다.


117

2.3 시스템 개발 상태

주문 처리 시스템은 회사 내부의 팀의 협력을 받아 외부에 있는 컨설팅 업체가 아웃소

싱으로 개발될 것이다.

현재 요구분석이 이루어져 문서로 작성되었고 중간 관리자에 의하여 검토, 승인되었다.

2.4 테스트 범위

테스트 프로젝트는 다음과 같은 범위로 구성된다.

요구 분석에 나와 있는 시스템의 모든 기능을 테스트 한다.

문서 테스트(시스템 유지보수, 시스템 운영, 사용자 매뉴얼, 온라인 핼프)

사용자가 쉽게 사용할 수 있는지 시험하는 사용성 테스트

회계 및 재정 시스템과의 인터페이스 시험

2.5 테스트 범위의 제한

테스트하는 시스템은 다음과 같은 사항은 다루지 않는다.

웹을 통하여 고객이 직접 주문을 내는 것,

출판사가 서점을 통하여 주문을 내는 것.

요금 청구, 요금 수납은 다루지 않는다.

데이터베이스의 변환과 데이터 베이스의 통합성 시험

성능 및 스트레스 시험

보안 제어 시험

강인성, 회복, 서버 다운 시험

Y2K 및 날짜 관계 테스트

내부 변경에 따른 다른 시스템과의 연동 테스트

2.6 리스크 분석

현 시점에 파악된 리스크는 다음과 같다.

예산 부족 – 서점의 경영이 악화되어 시스템을 계속 개발하지 못하고 중단될

경우

서점에 대한 불만족 – 주문이 잘못 처리될 경우 고객이 만족하지 못하고 경쟁

서점으로 옮겨감

3. 테스트 명세

이 시스템의 구체적인 테스트 케이스는 아직 정의되어 있지 않지만 테스트 케이스는 다

음과 같은 가이드라인으로 개발될 것이다.

(1) 시스템의 기능을 중요도(위험성, 사용 빈도)에 따라 상(high), 중(moderate), 하

(low)로 나눌 것이다.


118

(2) 각 기능별로 정상, 비정상 테스트 케이스를 작성할 것이다. 개발될 테스트 케이

스의 수량은 대략 다음과 같다.

기능별 테스트 케이스 개수 기능의 중요도 기능의 개수*

정상 비정상

상 2 8 8

중 4 4 4

하 10 1 1

* 시스템 요구분석서에 나열된 기능을 카운트 한 것임.

대략적인 테스트 케이스의 총 개수는 84개 [(2*16) + (4*8) + (10*2)]

4. 테스트 작업 계획

4.1 작 업

중요한 테스트 작업은 다음과 같다.

1 테스트 계획을 개발한다.

2 테스트 팀을 구성한다.

3 시스템 요구와 기능 스펙을 검토한다.

4 테스트 케이스를 작성하고 테스트 절차를 개발한다(자동화 포함 부분).

5 테스트 계획, 테스트 케이스, 절차의 검토와 승인

6 시스템 기능을 상세한 테스트 계획에 따라 테스트 수행

7 발견된 결함을 보고

8 결함을 수정하고 테스트

9 리그레션 테스트

10 테스트 결과를 문서화

11 테스트 프로젝트 수행 중 중간보고 작성

12 테스트 종료 조건을 기준으로 시스템을 릴리스 할 시점을 결정

13 테스트에서 라이브 오퍼레이션으로 전환

4.2 일 정

테스트 완료 후 시스템을 설치하고 사용하기까지 3주 정도의 기간이 필요함.

5. 테스트 완료 조건

다음 각 항이 수행될 때까지 테스트는 완료된 것으로 간주하지 않는다.


119

3.1.5 테스트 계획의 구조

3.1.2의 용어에서 설명한 것처럼 테스트 계획은 여러 가지 테스트 케이스로 구성

하고 이들을 조직적으로 잘 정리하여야 한다. 테스트 계획을 작성할 때 중요한 질

문 중의 하나는 테스트의 규모가 두 명이 한 주에 다 마칠 수 있는 25개의 작은 테

스트 케이스라면 간단한 계획으로 충분하다. 그러나 300 개의 테스트 케이스가 예

기능 커버리지 – 시스템 요구 분석서에 나와 있는 모든 기능은 적절히 수행된

다는 것을 보여야 한다.

시스템 테스트에서 발견된 모든 심각한 오류를 수정하고 다시 테스트.

시스템을 인수할 것이라는 사용자의 서명

테스트 결과에 대한 고급 관리자의 서명

6. 테스트 프로젝트 자원

6.1 인력 자원

테스트 프로젝트를 위하여 필요한 인력은

사용자 중심 기능의 테스트를 위한 비즈니스 전문가나 서점 점원

테스트 전문가 – 내부인력의 기술과 인원이 충분하지 않아 초빙하는 외부 컨설

턴트. 정확한 인원은 정하지 않았음.

서점 정보시스템 그룹 인력

− 앞으로 이 시스템을 지원하고 유지보수 하여야 할 시스템을 잘 이해하는

IT 인력

− 현 응용 시스템과 데이터베이스를 깊이 파악하고 있는 IT 인력. 이런 지

식은 새 시스템을 테스트하는 데 사용될 것임.

6.2 기술 자원

테스트에 필요한 장비, 자동화 도구, 테스트 데이터베이스. 테스트 프로젝트를 위하여

테스트 엔지니어는 독립적인 테스트 실험실과 장비가 필요하다. 실험실에 갖추어야 할

테스트 장비는 추후 정확히 결정할 것이나 다음 나열한 것이 필요함.

OS, NOS, DBMS가 탑재된 테스트 서버 1, 테스트 클라이언트 3.

테스트 데이터베이스(책, 주문, 배송 정보 등)

클라이언트, 서버 자동화 도구


120

상되어 6명이 8주 걸리는 작업이라면 테스트 계획은 방대하고 따라서 계층적으로 구성되어야 한다.

계획서를 작성할 때 두 번째 이슈는 테스트의 타입과 범위이다. 테스트 케이스가 다 같은 테스트(예를 들면 윈도우 기반의 기능 테스트)만을 수행한다면 테스트 계

획서는 하나로 충분하다. 반면 테스트가 다 다른 타입의 작업, 예를 들면 기능 테스

트, 보안 테스트, 확장성 테스트(scalability test) 등을 하여야 한다면 테스트 계획을 따로 작성한다. 다음 장에 소개하는 마스터 테스트 계획의 각 장에는 이러한 사례

의 목차를 제시하고 있다. 계획서에는 각 테스트 케이스를 카테고리 별로 구분하여 놓은 것이 좋다. 카테고

리는 테스트할 시스템의 구조와 일치하도록 하는 것이 자연스럽다.

[그림 3-3] 테스트 계획의 구조

예를 들어 시스템이 (a) 윈도우 인터페이스, (b)데이터베이스, (c) 네트워크 연결 기

능으로 나뉘어진다면 테스트 계획서 구조는 먼저 이 세 가지로 구성한다. 다른 방

법은 시스템의 기능으로 나누는 방법이다. 예를 들어 회계 업무 시스템의 기능이 미수금, 미지급금, 원장, 급여 시스템, 세금 시스템으로 나누어진다면 5 가지 서브시

스템이 테스트 계획의 첫 단계 구성이 된다. 테스트 계획이 요구 중심이라면 테스트 계획서의 최상위 구조는 요구분석의 복사

테스트할 기능 테스트할 슈트

테스트 케이스

1

테스트 케이스

2

테스트 케이스

3

테스트 절차

1

테스트 절차

2

테스트 절차

3

테스트 스텝

a

테스트 스텝

b

테스트 스텝

c

테스트 스텝

d


121

판이라고 할 수도 있다. 각 테스트 케이스들이 요구를 자동적으로 추적될 수 있기 때문이다.

테스트 계획의 구조를 자세한 사례를 들어 제시하면 다음과 같다. 테스트하려는 기능은 “30일 안에 대금을 지불하지 않은 고객의 독촉장을 인쇄”하는 것이다.

[표 3–3] 테스트 계획의 계층

3.1.6 마스터 테스트 계획

소규모 프로젝트에서 테스트 계획서는 간단한 문서로 작성된다. 반면에 대규모

프로젝트에서는 자세하고 특화된 문서들과 테스트 케이스 라이브러리로 구성된 방

대한 분량의 테스트 계획을 작성하여야 한다. 마스터 테스트 계획은 대규모 프로젝트의 테스트와 품질 보증 작업의 문서들을

서로 연관시켜주고 조정해주는 총서와도 같은 것이다. 프로젝트의 처음부터 종료할

테스트 슈트:

테스트 슈트는 위에서 제시한 요구와 관련된 모든 테스트 케이스의 집합이므로

“예상하는 것처럼 30일 내에 대금을 지불하지 않은 고객의 독촉장을 인쇄하는

지 체크함”

테스트 스펙:

1.3 30일 내에 대금을 지불하지 않은 고객의 독촉장을 인쇄.

테스트 케이스:

1.3.1 30일 동안 지불하지 않는 고객을 위하여 인쇄

1.3.2 31일 동안 지불하지 않는 고객을 위하여 인쇄

1,3,3 45일 동안 지불하지 않는 고객을 위하여 인쇄

테스트 스텝:

1,3,1,1 고객의 계정 번호를 입력한 후 잔고가 마이너스인지 확인(테스트 케이스 1.3.1

에 포함된 여러 스텝 중의 하나. 1.3.2, 1.3.3에서도 다시 사용되는 테스트 스텝임)

테스트 절차:

테스트 스텝을 어떻게 수행하는지 단계별로 설명한 것.


122

때까지 모든 품질 작업, 즉 요구 검증, 코드 인스펙션, 단위 테스트, 통합 테스트, 여러 가지 시스템 테스트, 고객 인수 테스트 등을 커버한다. 마스터 테스트 계획은 결정된 테스트 작업 방침을 기초로 작성하며 이것이 핵심 내용이다.

마스터 테스트 계획에는 테스트 작업 각 부분에 대한 자세한 사항이 포함된다. 예를 들면 리그레션 테스트 라이브러리의 재사용, 백업 및 복구 테스트, 데이터 변

환 테스트, 문서 테스트, 설치 테스트, 네트워크 보안 테스트, 성능 테스트 등이 기

술된다. 마스터 테스트 계획서의 구성을 예로 든다면 [그림 3-3]과 같다.

[그림 3-4] 마스터 테스트 계획서의 구성

마스터 테스트 계획서의 자세한 목차는 [표 3-4]에 소개하였다.

마스터 테스트 계획

0. 최 상위 테스트 작업 방침

1. 품질 보증 계획 2. 테스트 계획 3. 주요 확인일정


123

[표 3–4] 마스터 테스트 계획서의 목차

1. 품질 보증 계획

1.1 품질 목적과 우선순위

1.2 품질 보증 방침

1.2.1 종료 조건, 인스펙션 방법

1.2.1.1 요구분석

1.2.1.2 설 계

1.2.1.3 원시 코드

1.2.1.4 테스트 계획과 테스트 케이스

1.2.2 단위 및 통합 테스트

1.2.3 시스템 및 인수 테스트

1.3 표준과 절차

1.3.1 절 차

1.3.1.1 변경 및 버전 관리

1.3.1.2 문제 추적 및 보고

1.3.1.3 메트릭 데이터 수집과 보고

1.3.1.4 QA 프로젝트 현황 보고

1.3.2 문서화 표준

2. 테스트 계획

2.1 단위 테스트

2.1.1 프로그래밍 표준

2.1.2 복잡도 분석

2.1.3 커버리지 분석

2.1.4 단위 테스트 종료 조건

(단위 테스트 작업은 대부분 시스템 테스트 엔지니어가 수행하지 않기

때문에 마스터 테스트 계획서에는 포함시키지 않음)

2.2 통합 테스트

2.2.1 구조 및 설계 표준

2.2.2 빌드 프로세스

2.2.3 빌드 검토 테스트

2.2.4 어셈블리 테스트

2.2.5 End-to-End 테스트


124

3.2 테스트 케이스 3.2.1 테스트 케이스의 중요성

소프트웨어 테스트를 잘 모르는 사람들은 테스트 작업이 아주 쉽다고 하면서

전문적 기술이나 지식 없이 간단히 테스트를 수행할 수 있다고 이야기 한다. 그러나 실제 테스트 엔지니어가 되어 구현된 시스템이 예상대로 일련의 작업들이 수행되는지 점검하는 일을 하게 되었을 때 경험이 많지 않은 경우 테스트 방법과 적용 기법을 잘 모르기 때문에 대상을 직관적으로 결정하는 사례를 많이 목격할 수 있다.

테스트를 실행하는 과정에 부딪히게 되는 많은 문제들은 테스트 케이스 설계의 미흡함에서 발생한다. 테스트 기술에 대하여 소개 받지 못한 경우 실제 테스트를

2.3 시스템 테스트

2.3.1 기능 테스트

2.3.2 기능 인터액션 테스트

2.3.3 성능 및 스트레스 테스트

2.3.4 보안 제어 테스트

2.3.5 문서 테스트

2.3.6 시스템 테스트 종료 조건

2.4 인수 테스트

2.4.1 베타 테스트

2.4.2 설치 테스트

2.4.3 데이터 베이스 변환 테스트

2.4.4 고객 사이트 테스트

3 주요 확인 일정

3.1 품질 방침 확인

3.2 시스템 및 인수 테스트 계획 확인

3.3 테스트 준비 완료

3.4 테스트 완료

3.5 시스템 설치 및 준비


125

수행하기 위한 케이스들 또는 소프트웨어의 문제점들을 찾아내기 위한 다양한 테스트 케이스의 설계 기법들이 부족하다. 테스트 기술 없이 직관만으로 테스트의 대상을 분석한다면 너무 많은 시간과 과다한 인력을 낭비하게 된다. 반드시 테스트되어야 하는 조건들이 누락될 수 있고 시스템의 복잡도로 인하여 테스트 케이스는 많아지고 따라서 제한된 시간과 인력으로 테스트 성취도는 감소할 것이다.

효과적인 테스트 케이스 설계는 지적인 도전과 깊은 관찰이 필요하다. 또한 테스트 케이스 설계는 작업의 마감시간, 불충분한 자료, 자주 변경되는 요구사항, 비협조적인 개발자와 고객 간의 관계 때문에 소홀히 작성되거나 생략되는 경우가 많다.

테스트 케이스 설계는 테스트 수행 전에 이루어져야 하며 이상적으로는 시스템 개발 초기에 작성되어 시스템 디자인과 요구사항 정의에도 테스트 케이스 설계가 반영되어야 한다.

테스트 케이스 설계 작업 중 난해한 점은 표현이 애매모호하고 일관성이 없거나 생략된 요구 사항들을 포함하고 있는 시스템 요구사항을 다루어야 한다는 것이다. 또 다른 어려운 점은 테스트 케이스의 개발자와 그 테스트 케이스의 수행자가 다를 때 일어날 수 있다. 즉, 원활하지 못한 의사소통으로 인해 잘못된 결과 얻을 수도 있다.

따라서 효율적인 테스트 케이스 설계를 작성하려면 테스트 케이스 설계 전에 테스트의 접근 방법, 위험 분석, 범위, 대상 등을 결정하는 테스트 계획에 대한 모든 고려되어야 하는 정보들을 가지고 있어야 한다.

3.2절에서는 테스트 계획을 작성하는 방법과 테스트 케이스가 무엇이며, 어떻게 효과적인 테스트 케이스를 식별하고 설계할 것인지를 다룬다. 특히 기본 경로 테스트 방법을 중심으로 화이트 박스 테스트를 자세히 설명하고 블랙박스 테스트의 각 유형을 실제 사례를 들어 소개한다. 또한 요구명세에서 기능 테스트를 위한 테스트 케이스를 어떻게 찾아낼 수 있는지 자세히 다룬다 3.2.2 테스트 케이스의 정의

테스트 케이스는 특정 조건 하에서 관련 요구사항의 만족 여부를 확인하기 위해

필요한 입력 값과 예상 결과 값으로 구성된다. 특히 아래를 포함하여 테스트 가능한 형태로 구현할 수 있는 것들을 말한다. 또한 시험을 수행하기 위해 기본이 되는 문서화된 항목이다. 구체적인 내용을 문서화한 것으로 직접 시험을 수행하는 근간이 되고, 시험을 수행했다는 증거가 되며, 시험이 커버하는 범위를 표현하기도 한다. 일반적으로 테스트 케이스는 측정 가능한 상태에 대한 정보, 조건, 이벤트, 입/출력 값을 포함하는 데이터로 구성되어 있다.


126

특히 다음과 같은 범주의 데이터들을 대상으로 테스트 케이스를 만든다.

입력 될 수 있는 하나 또는 그 이상의 데이터 값 필요한 테스트를 시작하게 하는 자극 사건(trigger event) 처리 절차 후 입력의 결과로서 산출 될 수 있는 하나 또는 그 이상의 값 테스트를 수행하기 위해 필요한 도구와 데이터 테스트가 수행되기 위한 순서 또는 명령

종종 테스트 입력 값을 사용자 인터페이스에 입력하는 것만을 생각한다. 하지만

입력 값에 대한 분류는 여러 가지가 있다. 예를 들면 사용자 인터페이스를 통한 입력, 시스템을 통한 입력, 주변 장치를 통한 입력, 파일 입력, 데이터베이스 입력, 상태 입력, 기타 다른 환경으로부터의 입력이 있을 수 있다.

출력 값에 의한 테스트 케이스 종류도 입력만큼이나 다양하다. 사용자 인터페이스를 위한 값, 시스템을 위한 값, 주변 장치를 위한 값, 파일, 데이터베이스, 상태, 반응 시간 등이 될 수 있다.

[사례 1] 테스트 케이스는 여러 포맷으로 작성할 수가 있다. 간단한 SORT 루틴을

위한 테스트 케이스를 작성해 보자. 아래와 같은 포맷은 테스트를 위한 입력을 어떻게 하는지, 테스트를 중단 또는 재개하기 위하여 어떻게 하며 테스트를 종료하는 방법도 자세히 작성한 것이다.

INPUT DATA: 입력 데이터는 LIST 프로그램에 의하여 제공된다. 이 프로그램은 숫자와

글자가 섞인 N 개의 단어를 무작위로 생성한다. 이 프로그램을 호출하려면 RUN LIST(N, M) 과 같이 테스트 드라이버에 써주면 된다. 출력은 LISTBUF라는 전역변수에

출력된다. 다음과 같은 테스트 케이스를 정의한다. CASE 1: LIST를 N=5, M=5로 사용. CASE 2: LIST를 N=10, M=5로 사용. CASE 3: LIST를 N=15, M=5로 사용. CASE 4: LIST를 N=50, M=5로 사용. CASE 5: LIST를 N=100, M=5로 사용. CASE 6: LIST를 N=150, M=5로 사용. INPUT COMMANDS:


127

SORT 루틴은 다음과 같은 명령어를 사용하여 호출한다. RUN SORT (INBUF, OUTBUF) RUN SORT (INBUF) OUTPUT DATA: 두 개의 매개변수를 사용하여 호출하면 정렬된 후의 리스트는 OUTBUF에

저장되며 한 개의 변수만 사용하면 INBUF에 저장된다. SYSTEM MESSAGES: 정렬하는 동안 다음과 같은 메시지가 디스플레이 된다. “Sorting…..please wait…” 정렬이 완료되면 SORT 루틴은 다음과 같은 메시지를 디스플레이한다. “Sorting completed” 테스트 완료되기 전 중단하거나 빠져 나오려면 CONTROL-C를 누른다. TEST PROCEDURE: STEP N: 기능키 4를 누르면 데이터 파일을 억세스한다. STEP N+1: 화면에서 데이터 파일의 이름을 물으면 ‘sys:test.txt’라고 타이핑한다. STEP N+2: 다음과 같은 메뉴가 화면에 보인다. * 파일 삭제 * 파일 변경 * 파일 다른 이름으로 저장 커서를 파일 변경에 위치시키고 리턴키를 누른다. STEP N+3: 화면에서 레코드 번호를 물으면 ‘4017’로 타이핑한다.

STEP N+4: 화면에 4017 레코드를 위한 데이터 필드가 다음과 같이 디스플레이 된다.

Record number: 4017 X: 0042 Y: 0036 Soil type: clay Percolation: 4 mtrs/hr Vegetation: kudzu Canopy height: 25 mtrs Water table: 12 mtrs Construct: outhouse Maintenance code: 3T/4F/9R STEP N+5: 기능키 9: 변경을 누른다.

STEP N+6: 화면의 각 필드가 반전(highlight)되면서 커서가 VEGETATION으로 옮겨간다. ‘kudzu’ 대신에 ‘grass’를


128

입력하고 리턴을 누른다. STEP N+7: 화면의 각 필드가 더 이상 반전되지 않고 VEGETATION

필드는 ‘grass’로 읽혀야 한다. STEP N+8: 기능키 16: 이전 화면으로 복귀를 누른다. STEP N+9: 메뉴가 다음과 같이 나타나면, * 파일 삭제 * 파일 변경 * 파일 다른 이름으로 저장 변경이 저장되었는지 확인하기 위하여 ‘파일 변경’으로

커서를 옮기고 리턴을 누른다. STEP N+10: 화면에 레코드 번호 ‘4017’을 입력한다. STEP N+11: 화면에 레코드 4017을 위한 데이터 필드가 뿌려진다.

Record number: 4017 X: 0042 Y: 0036 Soil type: clay Percolation: 4 mtrs/hr Vegetation: grass Canopy height: 25 mtrs Water table: 12 mtrs Construct: outhouse Maintenance code: 3T/4F/9R [사례 2] 다음은 세가지 타입의 테스트 케이스 정리 포맷을 소개한다. 다음과 같이

일목요연하게 테이블 형태로 작성하는 경우가 많으며 자세한 정도에 따라 다음과 같이 나눈다.

[표 3-5] 상세한 키 입력 과정까지 기술한 테스트 케이스

시나리오 #: 001

목 적: 시동 후 사용될 화면 테스트

특수 요구: 자료 구조의 초기화에 필요한 패스워드의 검증. 사용자 ID와 패스워드의 검증

단계 입력 예상 출력 실행 결과 TR# 특수조건/비고

스크린에 로그온 및 팝업

1. 사용자 ID와 패스워드 없이 로그온을 시도한다.

1 HHD 파워 온 Copyright 화면 표시

2 ‘Beep’를 누름 삑 소리와 함께 화면 반

전

3 ‘계속’ 버튼을 누름 로그인 화면이 보임

4 ‘로그온’ 버튼을 누름 로그인 실패 창이 뜸 실패 메시지를 확인하는

버튼 ‘OK’을 보이고 정상


129

적인 입력 데이터 형식을

보임

5 ‘확인’ 버튼을 누름 로그인 화면으로 리턴

2. 정상 사용자 ID와 패스워드가 없이 로그인을 시도한다.

1 사용자 ID필드 누름 사용자 ID 필드 반전

2 정상 ID BXPWJS1을 입

력

사용자 ID 화면에 보임

3 로그인 누름 로그인 실패 창이 뜸 실패 메시지를 확인하는



보임

4 ‘확인’ 버튼 누름 로그인 화면으로 리턴

3. 사용자 ID의 입력없이 정상적인 패스워드로만 로그인 시도. 로그인 화면에서 빠져 나옴

1 패스워드 필드 누름 패스워드 필드 반전

2 정상 패스워드

mydog002 누름

화면에 보이지 않음

3 ‘확인’ 버튼 누름 로그인 실패 창이 뜸 실패 메시지를 확인하는



보임

[표 3-6] 중간 정도 상세한 키 입력 과정을 기술한 테스트 케이스

시나리오 #: 001

목 적: 시동 후 사용될 화면 테스트

특수 요구: 자료 구조의 초기화에 필요한 패스워드의 검증. 사용자 ID와 패스워드의 검증

단계 설명 예상 출력

1 사용자 ID와 패스워드 없이 로그온을 시도한다

2 정상 사용자 ID와 패스워드가 없이 로그인을 시도한다

3 사용자 ID의 입력없이 정상적인 패스워드로만 로그인 시도. 로그인 화면에서 빠져 나옴

[표 3-7] 가장 간단한 키 입력 과정을 기술한 테스트 케이스

시나리오 #: 001 목 적: 시동 후 사용될 화면 테스트


130

특수 요구: 자료 구조의 초기화에 필요한 패스워드의 검증. 사용자 ID와 패스워드의 검증 단계 설명 예상 출력

1 비정상적인 사용자 ID와 패스워드를 다양하게 입력을 시도한다

2 정상적인 크기의 사용자 ID와 패스워드 입력을 시도한다

3.2.3 테스트 케이스 설계 절차

테스트 케이스 설계 절차를 하찮은 것으로 여긴다면 중요한 테스트 작업을 직관

적으로 계획하게 된다. 이번 절에서는 앞에서 대략적으로 소개된 테스트 케이스 설계 절차를 자세히 설

명하도록 한다. 테스트 케이스 설계 절차는 일반적으로 다음 단계들로 이루어 진다.

[그림 3-5] 테스트 케이스 설계 절차

(1) 테스트하려는 대상을 이해하고 수행하려는 테스트 프로젝트의 범위와

접근방법들을 이해하기 위해 테스트 계획을 재검토한다. (2) 테스트 가능한 시스템 요구사항과 기능에 대한 명세서들이 있는지

위험 평가 및

우선순위결정 테스트 계획 검토 자료 확보

테스트 요구사항

정의 테스트 케이스

구조 설계 테스트 방법 결정

테스트 케이스 정의테스트 케이스

타당성 확인정의 유지 보수


131

확인하고 없다면 테스트하려는 시스템과 프로젝트들에 대한 자료와 정보 그리고 범위들을 확보한다. 시험이 가능한지 따져보는 것(Testability)을 중심으로 요구명세서를

재검토한다. 테스트를 위한 정보가 부족하다면 요구명세서를 수정하고 개선한다.

또한 사용자 중심의 기능(user-oriented features) 뿐만 아니라 시스템을 테스트하는 테스트 엔지니어들에게 요구되는 특징들도 테스트 요구사항에 포함되는지 확인한다.

(3) 시스템과 프로젝트의 위험을 평가하고 테스트의 우선순위를 결정한다.

위험 평가는 어떤 부분에 테스트의 초점을 둘 것인지 결정할 수 있게 한다.

위험 분석(risk assessment)을 통해 대략 얼마나 많은 테스트 케이스를 생성할 것인지 판단할 수 있다.

(4) 예를 들어 테스트를 위해 필요한 것은 무엇인지 등을 나타내는 테스트

요구사항(test requirements)을 정의한다. 시스템 또는 컴포넌트 요구사항, 테스트 대상들을 재검토하고 어떤

특징, 요구사항 또는 조건들을 테스트할 것인지에 대한 테스트 케이스들을 구체적으로 결정한다.

주어진 상황에서 가장 적절한 테스트 케이스 설계 기법을 선택한다. 테스트할 특성, 조건, 기능들을 식별하고 분석한다.

(5) 테스트 스탭, 타입과 같은 테스트 케이스 구조를 설계한다.

관련된 테스트 케이스들이 어떻게 서로 유기적으로 연관성을 갖고 있으며 동일한 범주로 분류(clustering)될 수 있는지 결정한다.

테스트 케이스 구조 체계는 테스트 계획에서 개발한다. 테스트 케이스의 일반적 형식(common format)을 결정한다.

(6) 어떻게 테스트 할 것인가를 결정한다.

어떤 테스트 절차를 따를 것인가? 어떤 테스트 장비(equipment)를 사용할 것인가? 어떤 테스트 데이터 베이스를 사용할 것인가? 어떤 테스트 도구를 사용할 것인가? 어떻게 문서화할 것인가?


132

이러한 항목들은 이미 테스트 계획에서부터 정의한다.

(7) 일반적 접근 방법으로 각 요구사항에 대한 테스트 케이스를 정의한다. (a) 일반적 접근 방법

① 테스트 케이스에 식별번호(ID number)를 부여한다. ② 테스트 케이스의 목적을 문서로 명시하고 설명한다. ③ 표준으로 사용할 테스트 케이스의 형태(format, template)를

결정한다. ④ 해당 테스트 케이스를 수행하기 위한 절차를 결정한다. ⑤ 테스트 케이스에 대해 필요한 데이터 타입과 자원을 결정한다. ⑥ 테스트 케이스에 필요한 기타 지원 인프라(support

infrastructure)를 정의한다 ⑦ 어떻게 테스트 결과를 평가하고 평가 한 값들의 가치를 분류할

것인지 결정한다. ⑧ 테스트 할 요구사항 또는 특징들의 연관성을 찾고 시스템의

버전(version), 환경 또는 테스트 형상관리 등을 위해 테스트 케이스를 참조한다.

(8) 세부적 접근 방법으로 각 요구사항에 대한 테스트 케이스를 정의한다.

(b) 세부적 접근 방법 ① 테스트 케이스를 유도하기 위하여 입력 데이터를 자세히

정의한다. ② 초기 조건을 명시한다. ③ 테스트 환경 즉, 기타 테스트 지원 인프라(support infrastructure)를

기초 한다. ④ 테스트 케이스를 어떤 방법과 단계로 수행한 것인지 절차를

명기 한다. ⑤ 테스트 케이스의 예상 결과와 만족할만한 결과를 자세히 기록

한다. 만약 예상된 결과를 정확하게 미리 정의할 수 없다면 테스트 결과의 평가를 결정하기 위한 규칙들을 정의한다.

⑥ 만약 앞 뒤에 있는 테스트 케이스 간에 관계가 있다면 그 의존성들(dependencies)을 자세히 정의한다.

(9) 테스트 케이스의 타당성을 확인한다.

테스트 케이스를 수행하는 전체 과정을 면밀히 검토한다.


133

테스트 케이스를 시범적으로 수행해 본다. 필요에 따라 테스트 케이스를 디버깅하고 수정한다. 테스트 결과를 적절히 정리하고 평가한다. 차후에 재사용하기 위해 테스트 케이스를 재검토한다. 주요한 특징에서 한 개의 테스트 케이스가 존재하는 조건(condition)까지

모두 수행하고 평가했는지 확인한다. 형상 관리를 마친 후 테스트 케이스를 저장소에 저장한다.

(10) 테스트 케이스를 유지보수한다.

환경 또는 시스템의 기능의 변화에 따라 테스트 케이스를 갱신한다. 정기적으로 테스트 케이스가 여전히 유용한지 검토한다. 테스트 실패를 분석하고 테스트 케이스를 추가하거나 더 확장한다.

3.3 블랙 박스 테스트

블랙 박스 테스트(black-box test)의 개요는 1장의 1.2.4에서 이미 살펴 보았으므로 가장 널리 사용되는 기법들을 중심으로 자세히 살펴 보도록 하겠다.

3.3.1 동등 분할

동등 분할 테스트(equivalence test)란 각각의 클래스로부터 대표 값을 추출하여

테스트 케이스를 생성하고 테스트 데이터의 범주를 식별하는 기법이다. 예를 들면, 2003년 1월 29일에 있었던 입력 값들과 2003년 4월 14일에 있었던 입력 값들이 동일한 부류의 값들이고 또 이러한 값들이 모두 유효하다면 하나의 소프트웨어 안에서는 둘 다 동일한 경로와 방법으로 값들이 처리 될 것이다. 그러므로 소프트웨어를 테스트하기 위해 서로 다른 날의 데이터를 모두 수행하지는 않고 둘 중 어느 하루의 데이터 만을 테스트 케이스로 추출한 후 테스트를 수행하려 할 것이다.

대부분의 사람들은 본능적으로 테스트하는 동안 동등 분할 기법을 사용한다. 만약 유효하든 아니든 어떤 사건으로부터 하나의 테스트 케이스가 생성 된다면 동치로 분류된 다른 테스트 케이스도 같은 방법으로 테스트되고 결과를 생성할 것이다. 예를 들어, 만약 문자열을 숫자 데이터 변수에 입력한다면 에러가 발생할 것이고, 따라서 다른 문자열을 이용하여 숫자 데이터 변수에 입력하려 해도 같은 결과를 예측 할 것이다.


134

동등 분할 테스트 핵심 내용은 모든 가능한 테스트 케이스의 부분집합 중에서 에러를 잘 검사 할 가능성을 지니는 테스트 케이스 찾는 것이다. 동등 분할의 집합은 같은 출력 결과를 생산하는 입력 조건(input conditions) 또는 입력 데이터 값들이다. 만약 동등 분할의 집합 중 하나의 테스트 케이스가 정확하게 수행을 한다면 다른 테스트 케이스도 동일한 행위 또는 같은 결과를 얻으므로 테스트 할 필요가 없다.

다음은 동등 분할의 조건이 될 수 있는 예이다.

입출력에 대한 유효한 값과 유효하지 않은 값 음수, 양수, 0의 정수에 대한 숫자 값 공백이거나 데이터가 있는 문자열 값 공백이거나 데이터가 있는 리스트(list) 파일이 존재하거나 없는 상태 또는 파일들의 읽기, 쓰기 등이 가능한

상태 연도 값이 2000년 이전 또는 2000년 이후, 또는 날짜 표기가 연도만

있는지 아니면 월, 일이 모두 포함되어 있는 표기 달마다 요일의 날 수가 28, 30, 31일 등의 다른 표기 출근과 퇴근시간 데이터 파일의 종류(텍스트, 날짜표기, 그래픽, 비디오, 사운드 등) 파일의 입력 출력 위치(하드 드라이브, 플로피 드라이브, CD-ROM 등)

[사례 3-1] 동등 분할 테스트 케이스의 설계의 예

다음과 같이 학점의 등급을 부여하는 기능의 시스템(generate_grading function)이 있다고 가정하자.

기능: 시험 점수는 75점이 만점이고 과목시간에 부여된 과제의 점수는 25점이 만

점이다. 이 두 점수를 더한 값(total)으로 A부터 D까지 등급을 매긴다. 각 등급의 기

준은 다음과 같다

70<= total : ‘A’ 50<= total < 70 : ‘B’ 30<= total < 50 : ‘C’ total < 30 : ‘D’ total < 0 or total > 100 : ‘FM’ (fault message) 모든 입력 값들은 정수


135

(1) 동등 분할의 분석

테스트 수행자는 테스트를 위해 입력과 출력 값으로 분류된 컴포넌트 모델을 제

공한다. 입력 값과 출력 값은 컴포넌트의 행위에 대한 명세서로부터 추출된다. 분류된 구획은 값들의 집합이고 분류된 구획의 모든 값들은 같은 방법으로 처리

되어야 한다. 즉 동일한 절차로 테스트해야 한다. 또한 정상 값과 비정상 값 모두에 대한 테스트 케이스가 만들어져야 한다. 예를

들면, generate_grading function은 두 가지의 입력이 가능하다.

시험 점수

[그림 3-6] 시험 점수 동등 분할

과제 점수

[그림 3-7] 과제 점수 동등 분할

입력 값에 대해 적용할 수 있는 다른 동등 분할 기준은 입력의 자료형의 일치 여

부가 될 수 있다. 예를 들면 아래와 같다.

시험 점수 = 실수(real number) 시험 점수 = 문자형(alphabetic) 과제 점수 = 실수(real number) 과제 점수 = 문자형(alphabetic)

25 25


136

위와 같은 값들은 비정상적인 범위에 속하는 동등 분할이 될 것이다. 다음은 generate_grading 함수의 출력 값에 대하여 조사해 보자.

등급

[그림 3-8] 등급 별 동등 분할

물론 비정상적인 출력 값도 고려하여야 한다. 정의되지 않은 출력 값을 예상하

기란 쉽지 않은 문제이다. 하지만 명세나 컴포넌트에 대해서 결점들이 발생할 수 있기 때문에 반드시 고려하여야 한다.

예를 들면, 아래와 같은 경우를 비정상적인 출력 값으로 정의할 수 있다.

등급 = ‘E’ 등급 = ‘A+’ 등급 = ‘null’

여기까지 모두 19 개의 동등 분할 사례를 보았다. 동등 분할하는 도중에 테스트 수행자의 주관적인 판단은 불가피하다. 예를 들면 비정상 입력이나 출력 값들이 추

가되는 경우가 있다. 여러 명의 테스트 수행자의 주관으로 인하여 각자 다른 동등 분할을 할 수 있다.

(2) 테스트 케이스 설계

분할된 부분을 수행하기 위한 테스트 케이스를 생성하는 접근 방법은 두 가지가 있다.

1. 각 분할된 영역에 대해 개별적인 테스트 케이스를 기본적으로 하나씩 생성하


137

는 경우 2. 최소한의 테스트 케이스의 집합으로 모든 영역을 테스트하기 위해 같은 테스

트 케이스는 다른 테스트 케이스를 위해 반복 될 수 있다.

위 두 가지 방법에 의해 사용할만한 테스트 케이스를 설계해보자.

1) 각 영역에 대해 하나의 값을 지정한 테스트 케이스

시험 점수의 입력 값을 영역에 따라 분할하는 경우 다음과 같다.

[표 3-8] 시험 점수 동등 분할 테스트 케이스

테스트 케이스 1 2 3

입력(시험 성적) 44 -10 93

입력(과제 성적) 15 15 15

전체 성적 59 5 108

분할 영역 0 <= e <= 75 e < 0 e > 75

예상 출력 ‘B’ ‘FM’ ‘FM’

입력 값에서 과제 성적에 대한 값은 모두 15로 사용하였다. 이렇게 고정시키는 이유는 오류의 결과가 나왔을 때 시험 성적에 의한 변화만을 보기 위함이다. 다음 예는 과제 성적을 동등 분할한 테스트 케이스이다.

[표 3-9] 과제 점수 동등 분할 테스트 케이스

테스트 케이스 4 5 6

입력(시험 성적) 40 40 40

입력(과제 성적) 8 -15 47

전체 성적 48 25 87

분할 영역 0 <= c <= 25 c < 0 C > 25

예상 출력 ‘C’ ‘FM’ ‘FM’

시험 성적은 모두 40으로 고정하였다. 다음은 비정상적인 입력 값에 대한 테스트 케이스이다.


138

[표 3-10] 비정상 입력 값의 테스트 케이스

테스트 케이스 7 8 9 10

입력(시험 성적) 48.7 ‘q’ 40 40

입력(과제 성적) 15 15 12.76 ‘g’

전체 성적 63.7 ? 52.76 ?

분할 영역 real alpha real Alpha

예상 출력 ‘FM’ ‘FM’ ‘FM’ ‘FM’

각 테스트 케이스에 유효하지 않은 값들이 입력되어 있고 모두 ‘FM’을 예상 출력

으로 정의하고 있다. 다음은 비정상적인 출력 값에 대한 동등 분할 테스트 케이스이다.

[표 3-11] 비정상적 출력 값의 테스트 케이스

테스트 케이스 11 12 13

입력(시험 성적) -10 12 32

입력(과제 성적) -10 5 13

전체 성적 -20 17 45

분할 영역 t < 0 0 <= t <= 30 30 <= t < 50

예상 출력 ‘FM’ ‘D’ ‘C’

테스트 케이스 14 15 16

입력(시험 성적) 44 60 80

입력(과제 성적) 22 20 30

전체 성적 66 80 110

분할 영역 50 <= t < 70 70 <= t <= 100 t > 100

예상 출력 ‘B’ ‘A’ ‘FM’

주어진 입력에 대해 모두 정상적인 출력을 보이고 있다. 마지막으로 비정상적인 출력 값에 대하여 동등 분할한 테스트 케이스이다.

[표 3-12] 비정상적 출력 값의 테스트 케이스

테스트 케이스 17 18 19


139

입력(시험 성적) -10 100 Null

입력(과제 성적) 0 10 Null

전체 성적 -10 110 ?

분할 영역 ‘E’ ‘A+’ ‘null’

예상 출력 ‘FM’ ‘FM’ ‘FM’

2) 여러 분할 영역에 대한 최소한의 테스트 케이스

위에서 소개한 동등 분할에 의한 테스트 케이스는 대부분 비슷하지만 적용하고자 하는 동등 분할 된 영역이 서로 다를 뿐이다. 이것은 다수의 분할 영역에 대해 하

나의 테스트 케이스로 테스트할 수 있게 한다. 이런 방법을 이용하면 테스트 수행

자들에게 모든 동등 분할을 테스트하기 위한 테스트 케이스의 수를 줄일 수 있게 할 것이다.

다음의 테스트 케이스를 살펴보면 세 가지의 다중적 동등 분할을 발견할 수 있다.

[표 3-13] 다중적 동등 분할

테스트 케이스 1

입력(시험 성적) 60

입력(과제 성적) 20

전체 성적 80

기대 출력 ‘A’

위 테스트 케이스에 적용한 세 가지의 분할 영역은 다음과 같다. 1. 0 <= 시험 성적 <= 75 2. 0 <= 과제 성적 <= 25 3. 등급 = ‘A’ : 70 <= 시험 성적 + 과제 성적 <= 1000 이와 마찬가지로 비정상적인 값들에 대해 동등 분할 한 테스트 케이스는 다음과

같다.

[표 3-14] 비정상 값에 대한 테스트 케이스

테스트 케이스 2


140

입력(시험 성적) -10

입력(과제 성적) -15

전체 성적 -25

기대 출력 ‘FM’

위 테이블에 표시된 테스트 케이스에 적용한 세가지 다른 동등 분할 기준은 다음

과 같다. 1. 시험 성적 < 0 2. 과제 성적 < 0 3. 등급 = ‘FM’ : 시험 성적 + 과제 성적 < 0

3.3.2 경계값 테스트

경계값 테스트(boundary analysis)는 동등 분할 기법을 확장 시킨 것으로 분할 된

경계에 대한 값들까지 검사하는 기법을 말한다. 동등 분할은 테스트 대상 컴포넌트

에 의해 분할된 유사한 값들의 집합으로 정의된다. 하지만 개발자는 이런 분할된 경계에 대한 값들에 대해 부주의하는 경우가 많다. 예를 들면, 리스트의 원소들을 테스트하려 할 때 동등 분할 기법에서는 하나의 그룹으로 분류한다. 하지만 경험이 부족한 개발자는 리스트의 처음 원소와 마지막 원소에 대하여 정확하고 신뢰성 있

는 처리를 보장하지 못한다. 어떤 소프트웨어가 성능의 한계점에서 잘 작동한다면 보통 상황에서도 반드시 잘

작동할 것이다. 경계 조건은 프로그래밍이 원래 한계점에 민감한 성질을 지녔기 때

문에 중요하다. 경계값 테스트는 보통 동등 분할 집합의 한계들로 이루어진다. 예를 들면

월요일과 일요일의 경계 1월과 12월의 경계 16비트 정수 값에서 32767과 32768 사이의 경계 스크린에서 top-left와 bottom-right 커서 위치 보고서를 프린트할 때 첫 줄과 마지막 줄의 경계 두 자리 연도로 표기하던 기법에서 2000년 1월 1일로 전환할 때 한 개의 문자로만 이루어진 문자열과 최대한의 길이를 가지고 있는 문자열과

같은 경우를 포함하고 있다.


141

테스트 케이스는 분할된 경계값의 양쪽 측면의 테스트를 하기 위해 만들 수 있다.

다음 그림은 경계값을 중심으로 근접한 양쪽의 값과 경계가 되는 값을 테스트 케이

스로 선택하고 있음을 보여주고 있다.

[그림 3-9] 경계값 중심의 테스트 데이터

[사례 3-2] 경계값 테스트 케이스의 예

등등 분할에서 예를 든 generate_grading 함수를 이용하여 경계값 분석 과정을 설

명한다. 예를 들어 시험 성적의 분할 된 영역에 대한 경계값들은 아래 그림에서 보여 주

듯이 -1, 0, 1, 74, 75, 76이 될 수 있다.

[그림 3-10] 경계값 테스트 케이스 예

위에서 분석한 경계값을 적용하면 다음과 같이 테스트 케이스를 생성할 수 있다.

[표 3-15] 경계값 테스트 케이스


142

테스트 케이스 1 2 3 4 5 6

입력(시험 성적) -1 0 1 74 75 76

입력(과제 성적) 15 15 15 15 15 15

전체 성적 14 15 16 89 90 91

경계값(시험 성적) 0 75

예상 결과 ‘FM’ ‘D’ ‘D’ ‘A’ ‘A’ ‘FM’

과제 성적은 일괄적으로 15를 부여하였다. 같은 방법으로 과제 성적에 대해 0과 5에 대한 경계값을 이용한 테스트 케이스를 생성할 수 있다.

[표 3-16] 과제 성적 경계값 테스트 케이값

테스트 케이스 7 8 9 10 11 12

입력(시험 성적) 40 40 40 40 40 40

입력(과제 성적) -1 0 1 24 25 26

전체 성적 39 40 41 64 65 66

경계값(과제 성적) 0 25

예상 결과 ‘FM’ ‘C’ ‘C’ ‘B’ ‘B’ ‘FM’

시험 성적은 일괄적으로 40을 적용하였다. 동등 분할의 시험과 과제 성적에 대해 정수 값이 아닌 경우와 숫자 값이 아닌 경우, 실수와 문자 데이터가 들어가는 비정

상적인 값들을 검사하였다. 그러나 이런 값들이 정상적인 값이라 하더라도 식별할 수 있는 경계값이 아니므로 고려할 대상이 아니다.

등급에 관한 예상 출력 경계값은 0, 30, 50, 70, 100이고 이들에 대한 테스트 케이스

의 구분을 아래 그림과 같이 표현하고 테스트 케이스를 생성할 수 있다.

[그림 3-11] 결과에 대한 경계값


143

다음은 테스트 케이스를 생성한 예이다.

[표 3-17] 결과에 대한 경계값 테스트 케이스1

테스트 케이스 13 14 15 16 17 18 19 20 21

입력(시험 성적) -1 0 0 29 15 6 24 50 26

입력(과제 성적) 0 0 1 0 15 25 25 0 25

전체 성적 -1 0 1 29 30 31 49 50 51

경계값(과제성적) 0 30 50

예상 결과 ‘FM’ ‘D’ ‘D’ ‘D’ ‘C’ ‘C’ ‘C’ ‘B’ ‘B’

[표 3-18] 결과에 대한 경계값 테스트 케이스2

테스트 케이스 22 23 24 25 26 27

입력(시험 성적) 49 45 71 74 75 75

입력(과제 성적) 20 25 0 25 25 26

전체 성적 69 70 71 99 100 101

경계값(과제 성적) 70 100

예상 결과 ‘B’ ‘A’ ‘A’ ‘A’ ‘A’ ‘FM’

동등 분할에서 비정상적인 결과 값으로 ‘E’, ‘A+’, null과 같은 값들을 검사했지만 경계값으로 정의할 수 없기 때문에 테스트 케이스를 만들지 않는다.

다음과 같이 또 다른 경계값의 테스트 케이스를 찾아 볼 수 있다.

시험 성적 > 75 시험 성적 < 0 과제 성적 > 25 과제 성적 < 0 시험 성적 + 과제 성적 > 100 시험 성적 + 과제 성적 <0

이와 같은 영역에 대해 입력 또는 출력의 데이터 타입의 경계값을 추측해 볼 수

있다. 예를 들어 16비트 정수 타입은 32767과 32768이 경계값이 될 수 있다. 따라서 18개의 테스트 케이스를 더 생성할 수 있다. 그 중 시험 성적에 대한 테

스트 케이스는 아래와 같다.


144

[표 3-19] 기타 경계값 테스트 케이스

테스트 케이스 28 29 30 31 32 33

입력(시험 성적) 32766 32767 32768 -32769 -32768 -32767

입력(과제 성적) 15 15 15 15 15 15

경계값(과제 성적) 32767 -32768

예상 결과 ‘FM’ ‘FM’ ‘FM’ ‘FM’ ‘FM’ ‘FM’

이와 유사한 방법으로 과제 성적, 예상 등급 결과에 대해 테스트 케이스를 생성

할 수 있다.

3.3.3 추적 메트릭스(traceability matrix) 추적 메트릭스는 시스템을 개발하는 동안 테스트 케이스를 추적하기 위해 사용하

고 시스템을 검사하고 유지 보수하는 우수한 도구이다. 추적 메트릭스는 요구 사항

과 요구 사항을 반영하여 작업한 설계, 프로그램 등, 추후 검사할 것과의 상호 연관

성을 제시해 준다. 또한 테스트할 요구 사항 목록을 작성하는 출발점을 제공한다. 유지 보수 작업에서 추적 메트릭스는 훨씬 쉽게 테스트 요구 사항을 찾을 수 있고 관련 있는 테스트 케이스를 보여 줄 수 있다.

(1) 추적 메트릭스 테스트 케이스 설계 절차

추적 메트릭스의 테스트 케이스 생성 과정은 다음과 같다.

추적 메트릭스는 먼저 테스트 가능한 요구사항을 식별한다. 1. 테스트할 수 없는 추상적인 요구사항, 기대, 상태, 주장 등을 제거한다. 2. 중복된 요구사항도 제거한다. 3. 각각의 요구사항에 대해 고유 식별 번호를 부여한다. 4. 이들 간의 우선순위를 결정한다.

모든 요구사항의 구현에 대해 검증한다.

(2) 추적 메트릭스 테스트 케이스 설계의 예

다음은 추적 메트릭스의 예이다.


145

[표 3-20] 추적 메트릭스 예

요구분석 설계 추적번호

Sect. 요 약 Sect. 요 약

001

1.1 99.99% 가용성 1.6 1.7 6.1 15.3

듀얼 프로세서 Hot back-pu 온라인 점검 온라인 성능 모니터링

N/A 1.2 선택한 하드웨어가 30일 내

로 확보되어 사용가능 하여

야 한다.

N/A N/A

N/A 1.3 트랜젝션이 분실되지 않아

여 한다.(1.4에 포함) N/A N/A

002 1.4 트랜젝션 입력이 100% 처리

되어야 한다.(1.3에 포함) 2.2 2.3 2.4

프랜젝션 처리 트랜젝션 기록 분실된 트랜젝션의 재전송 요청

위의 표는 요구사항과 설계를 서로 연관 지은 표이다. 이것은 문서작성 전과 후

의 쌍으로 사용될 수 있다. 또한 테스트 과정 중에 테스트에 의해서 요구 사항들이 변경되는 것을 막기 위해 문서화 수단으로 사용된다. 위의 표에 다음과 같은 항목

이 추가될 수 있다.

비 고: 제기될 수 있는 문제들이나 추측 등 우선순위: 요구 사항들에 대한 중요도(테스트 수행 시간을 적절히 분배할 수

있다.) 추적 메트릭스는 시스템을 개발하는 모든 과정들을 추적하기 위해 다중 레벨의

추적을 제공한다. 다음 그림은 4단계의 메트릭스 예이다. 추적 메트릭스 사용 전문

가는 실제 중요한 프로젝트를 수행할 때에는 7단계 이상의 메트릭스를 이용한다고 한다. 또한 이러한 추적 메트릭스는 신속한 유지 보수를 가능하게 한다.

테스트 케이스를 위한 요구 사항의 추적 메트릭스를 부록에서 제공하였다.

3.3.4 의사결정 테이블

의사결정 테이블(decision tables)은 표 형태로 간단히 테스트할 요소들을 보여준다.

의사 결정 테이블은 의사결정의 여러 조합을 정하는 행위나 결과를 식별함으로써 시스템의 예상되는 행위를 파악한다. 또한 블랙 박스 경로 분석의 흐름도(flow chart)에서 보조로 사용되기도 한다.

의사 결정 테이블의 각 열은 테스트 가능한 조건이다. 그리고 흐름도의 구별된


146

하나의 경로로 대응될 수 있다. 또한 의사 결정 테이블은 한 프로세스와 연관된 모든 동작을 표시하거나 프로세

스 수행 중 요구되는 결정이나 조건을 기술하는데 사용한다. 그리고 입력 제어 조

건들의 순서는 고려하지 않는 조합 논리를 나타내는데 적합하며 출력 값을 갖기 위

해 요구되는 입력 값을 테이블 형태로 나타낸다.

[사례 3-3] 의사 결정 테이블 기법 설계의 예

한 회사에서 다음과 같은 주문 절차의 정책을 가지고 있다고 하자. 1. 명령은 현금 지금 또는 신용 인증이 있을 때만 수행된다. 2. 우수 고객은 10%의 할인이 가능하고 다른 모든 고객은 전액 모두 지급한다. 아래 테이블은 5개의 열(columns)을 가지고 있는 의사 결정 테이블의 예이다.

[표 3-21] 의사결정 테이블

테스트 케이스 번호 1 2 3 4 5

현금 주문 Y Y N N N

신용카드 - - Y Y N 의사결정

우수 고객 Y N Y N -

주문 처리 √ √ √ √

주문 거부 √

10% 할인 √ √ 액션

정상 가격 √ √

5개의 열은 5개의 테스트 케이스를 의미한다. “-“ 기호는 “Y” 나 “N” 둘 중 아무

거나 들어와도 아무 상관이 없다는 의미이다. 다른 열과 달리 5번 테스트 케이스는 해당하는 액션이 ‘할인’이나 ‘정상 가격’ 어디에도 해당 사항(“√”)이 없다.

1번 테스트 케이스 경우는 현금으로 주문을 하고 우수 고객이므로 예상되는 결과

는 주문이 수행되고 10%의 할인을 받게 된다. 여기서 3개의 입력 의사결정이 있기 때문에 열의 개수는 모두 8(23)개가 가능하

다. 하지만 8개 중 결과가 같은 것이 있기 때문에 5개를 줄일 수 있다. 예를 들어 5번 째 테스트 케이스의 경우 현금이나 신용카드가 아닌 경우는 우수 고객의 여부에 상관없이 주문이 불가능하기 때문이다.


147

5번 째 테스트 케이스는 8개 중에서 2개가 혼합되어 있어 효과적으로 테스트 케

이스를 줄일 수 있고 이러한 정보는 흐름도로 표현할 때 5개의 경로로 표현할 수 있다. 즉, 하나의 열은 하나의 경로에 해당 된다.

(1) 의사결정 테이블 기법의 적용

의사결정 테이블을 사용하는 데 모든 조합을 테스트 할 수는 없다. 따라서 가장

위험 순위가 높은 경우, 가장 사용이 빈번한 경우 또는 중요하게 성공 요인으로 작

용하는 요소들을 중심으로 테스트하여야 한다.

[표 3-22] 의사 결정 테이블을 사용하기에 적절한 예

요구사항의 정의가 이미 의사 결정 테이블 형태로 정의되어 있거나 쉽게

테이블 형태로 변환이 가능한 경우 의사 결정 테이블의 결과 범위가 너무 폭 넓거나 크지 않은 경우.

큰 범위의 테이블을 작은 범위의 테이블로 분할하여 표현하는 것은

가능하다. 테이블 안의 각 열은 다른 열과 각각 독립적인 경우.

일단 한번만 규칙이 적용되면 다른 규칙들을 고려할 필요가 없기 때

문에 해당 케이스의 경우 외에 있는 행위나 조건의 규칙들과는 연관

성이 없어야 한다.

(2) 의사 결정 테이블 기법의 설계 절차

설계 절차를 간략하게 설명하면 먼저 시스템에서 기대되는 중요한 출력 결과를

식별하고 그 결과에 영향을 주는 요소를 파악하여 의사 결정 테이블의 x 축과 y 축

에 적용 한다. 하지만 위에서 언급했듯이 모든 조합을 테스트할 수는 없기 때문에 중요한 요소를 파악하고 중복을 줄여 간소화하는 작업이 필요하다.

[그림 3-12]는 설계 절차를 단계별로 설명한 것이다.


148

[그림 3-12] 의사 결정 테이블 설계 절차

출력 결과 식별

조건 식별

중복성 및

완전성 검사

테이블 작성

테이블 간편화

논리적 결점

기록

테이블의 검증

1. 시스템의 가능한 출력 결과를 식별한다. 테스트할 가치

가 있는 것들을 파악하고 테이블의 아래 부분(Actions)

에 정의할 출력 결과들의 리스트를 작성한다. 이는 적

용할 범위에서 표준 용어를 정의하도록 도와준다

2. 행위를 일으키거나 결과들에 대해 영향을 주는 조건들

을 식별한다. 테이블의 위 부분(Decisions)에 정의할

입력 요소의 명칭을 정의한다. 만약 이들 입력 조건들

이 두 가지(binary)이고 개수가 n개이면 최대 열의 수

는 2n개가 될 것이다.

3. 각각 가능한 입력 조건들의 조합을 파악하고 해당하는

예상 결과를 조사하여 각 칸을 채워 테이블을 작성한

다.

4. 하나의 조합이 여러 열에서 중복됐는지 또는 각각의

열이 고유한 조합으로 구성되어 있는지 검사한다.

5. 같은 결과를 생성하는 열을 찾아보고 하나의 테스트

케이스로 결합하는 것이 가능한가 찾아서 통합한다.

6. 만약 예상한 결과는 있지만 이 결과를 위한 조합이 불

가능할 경우가 있다. 이와 같은 모순이 있다면 차후를

위해 논리적인 결점에 관해 기록으로 남긴다.

7. 초기에 정의한 요구사항에 맞도록 테이블을 작성했는

지 검사한다.


149

3.3.5 상태 천이도

상태 천이도(state transition diagram)는 시스템 상태나 모드, 그 상태들 사이의 천이,

천이를 일으키는 이벤트, 천이로 인해 생기는 결과적 행위(action)들로 이루어진다. 테스트 케이스는 상태들 사이에서 발생하는 유효한 천이들을 살펴보는 과정에서

설계한다. 추가적인 테스트 케이스로 유추될 수 없고 정의되지 않은 천이에 대한 테스트 케이스를 작성할 수 있다.

[사례 3-4] 상태 천이도의 예; 디스플레이 장치

다음 그림은 시간을 보여주는 디스플레이 모델을 표현한 상태 천이도이다.

[그림 3-13] 상태 천이도

다음은 위 그림에서 보는 상태 천이도의 내용이다.

시간을 보여주는 상태 S1


150

S1과 S3 사이의 천이 상태 S1에서 S3으로의 천이를 일으키는 이벤트 “reset” 천이 S1에서 S3으로 가는 천이 동안 “reset”의 결과로 시간을 보여주는 행위

(1) 정상적인 상태 천이 테스트 케이스

우선 정상적인 상태 천이를 수행하는 과정을 따라 테스트 케이스를 설계한다. 테

스트 케이스를 만들기 위해서는 다음 사항들이 정의 되어야 한다.

시작 상태 입력 예상 출력 예상 종료 상태

[사례 3-4]를 위하여 이러한 요소들을 정의하면 다음과 같은 6개의 테스트 케이스

를 생성 할 수 있다.

[표 3-23] 테스트 케이스 예

테스트 케이스 1 2 3 4 5 6

시작 상태 S1 S1 S3 S2 S2 S4

입 력 CM R TS CM R DS

예상 출력 D AT T T AD D

종료 상태 S2 S3 S1 S1 S4 S2

(2) 비정상적인 상태 천이도의 테스트 케이스

상태 천이를 이용한 테스트 설계에는 정상적인 천이를 기초로 고안하지만 테스트

를 완벽하게 수행하기 위해서는 비정상적인 상태 천이가 일어날 수 있음을 고려해

야 한다. [표 3-23]에 표현한 것은 정상적인 상태 천이만을 고려한 것이다. 즉 [그림 3-13]

의 상태 천이도에 나타난 6가지 상태변화만을 테스트하였다. 다음에는 상태에 변화

를 주는 액션이 아닌 경우, 즉 비정상적인 액션이 발생되었을 때 상태의 변화가 일

어나지 않는지 확인하는 테스트 케이스를 작성한다. 다음과 같이 상태 테이블을 이

용하여 유효하지 않은 천이를 보여 줄 수 있다.


151

[표 3-24] 유효하지 않은 테스트 케이스

CM R TS DS

S1 S2/D S3/AT -I -I

S2 S1/T S4/AD - -

S3 - - S1/T -

S4 - - - S2/D

테이블에서 “-“ 기호의 표시는 천이 실패를 나타내는 무효(null) 천이를 보여준다. 이처럼 정상적인 천이와 함께 유효하지 않은 천이를 테스트 할 수 있다.

3.4 화이트 박스 테스트

3.4.1 개요

일반적으로 테스트 엔지니어들은 프로그램 내의 원시코드들이 실행되는 경로에

대해 알고 싶어한다. 화이트 박스 테스트(White Box Test) 기법은 이러한 테스트할 특정 경로를 선택하고 검사하기 위한 방법들을 제공한다.

화이트 박스 테스트는 원시코드 레벨에 적용 가능하다. 즉 화이트 박스라는 명칭

은 어떻게 논리적으로 프로그램 경로가 수행되는지 정확하게 파악할 수 있다는 의

미를 내포한다. 반면 블랙박스 테스트는 실제적 프로그램 내의 논리를 파악할 수 없고 다만 설명서나 명세서에 의존해야 한다.

3.4.2 검증 기준

화이트 박스 테스트의 검증 기준(coverage)은 폭이 넓다. 단위 프로그램 내의 경로

테스트뿐 아니라 단위 프로그램 사이에 데이터 흐름, 즉 통합테스트와 시스템 수준

까지 그 적용 범위는 다양하다 하겠다. 문장, 분기, 경로 테스트는 테스트 케이스를 작성하기 위해 논리적 흐름을 파악하

는 화이트 박스 테스트 기법이며 테스트 케이스가 원시코드를 충분히 테스트하는지 검증하는 기준이다. 이는 마치 프로그램을 작성한 후 원시코드를 실행하면서 내부

를 파악하는 것과 같다. [그림 3-14]의 왼편에 있는 프로그램의 논리적 흐름을 오른쪽에 있는 논리 흐름도

로 표현할 수 있다. 다음은 간단한 프로그램으로부터 논리 흐름도를 추출한 예이다. 논리 흐름도를 이루는 요소는 다음과 같다.


152

노드(nodes): 프로그램이 수행되는 동안 방문하는 서브프로그램 또는 문장. 간선(edges): 문장 또는 서브프로그램들 사이의 논리적 흐름. 분기 노드(branch nodes): 두 개 이상의 출력 간선을 가진 정점. 분기 간선(branch edges): 분기되는 간선 경로(path): 간선을 따라 정점들을 방문할 수 있는 간선들의 집합.

테스트 케이스는 논리 흐름도에 있는 특정 경로를 따라 노드를 방문하면서 프로

그램이 수행되게 작성한다. 경로는 분기 노드에 있는 다양한 조건에 의하여 여러 갈래의 다른 분기 간선으로

분할된다. 분할된 여러 경로들에 대한 테스트 케이스는 프로그램의 각각 다른 부분

(이를 슬라이스라 함)을 수행하게 된다. 이러한 방법 즉, 흐름도에서 노드, 간선, 경

로들을 방문하는 논리나 순서로부터 분기, 문장, 경로 테스트 케이스가 작성된다.

[그림 3-14] 논리 흐름도


153

(1) 문장 검증기준

문장 검증기준(statement coverage)은 추출된 테스트 케이스들이 테스트하려는 프로

그램의 문장을 적어도 한 번씩 실행해 보는 것이다. 프로그램 내의 모든 문장들을 적어도 한 번씩 방문하여 테스트한다면 100%의 문장 검증기준이라 한다.

다음과 같은 10개의 노드를 가진 논리 흐름도를 살펴보자.

[그림 3-15] 문장 검증기준 논리 흐름도

프로그램 내에서 A, B, D, H, K는 하나의 실행 경로를 나타낸다. 이 수행경로는 10개의 노드 중 5개를 경유했기 때문에 50%의 검증기준을 만족하는 테스트가 되겠다. 하지만 실제 문장 검증기준은 하나의 노드가 얼마나 많은 문장들로 이루어져 있는

지에 따라 수준이 달라진다.

(2) 분기 검증기준

분기 검증기준이란 작성된 테스트 케이스의 집합에 의해 프로그램의 모든 분기 조건을 점검할 수 있는 것을 말한다. 적어도 한 번씩 프로그램 내의 모든 분기 조

건을 테스트 한다면 100%의 해당 테스트를 수행한 것이다.


154

[그림 3-16]은 분기 간선을 방문하고 있는 분기 영역을 표현하고 있다. 테스트 케

이스에 의해 모든 가능한 분기 간선을 방문한다면 100% 적용했다고 할 수 있다. 여

기서는 6개의 분기 노드가 있고, 방문 노드는 A, B, D, H, K가 선택되었다. 그렇다면 이것은 6개의 분기 노드 중 2개가 방문되었으므로 적용 범위는 33%라 하겠다.

[그림 3-16] 분기 영역 논리 흐름도

(3) 경로 검증기준

경로 검증기준(path coverage)은 테스트 케이스에 정의된 집합에 의해 실행하는 경

로를 측정하여 결정한다. 적어도 모든 경로를 한번씩 경유한다면 범위를 100% 적용

했다고 말 할 수 있다. [그림 3-17]은 4개의 경로를 가지고 있다. A, B, D, H, K의 경로는 하나의 경로에 해

당하고 이 경로를 테스트 케이스로 정의하고 테스트를 수행하였다면 25% 적용 범

위라 하겠다.


155

[그림 3-17] 경로 영역 논리 흐름도

(4) 문장, 분기, 경로 검증기준의 차이점

테스트 케이스를 생성할 때 모든 영역을 각각 100% 적용하는 것은 아니다. 100%

분기 검증기준을 적용하지 않고서도 100%의 문장 검증기준을 적용할 수 있다. 즉, 모든 분기 간선들을 경유하지 않고서도 모든 노드들을 방문할 수 있다.

[그림 3-18] 문장 검증기준을 커버하는 분기 경로 흐름도

예를 들면, 위 그림에서 else 부분이 없다. 따라서 then 부분만 수행하면 if 문장을

If A then B;

C


156

모두 실행한 셈이 된다. 또한 모든 경로를 경유하지 않고서 모든 분기 간선을 방문

할 수 있다.

[그림 3-19] 경로 영역을 커버하는 분기 간선 흐름도

여기서 전체 가능한 경로는 4개이지만 2개의 경로만으로도 모든 분기의 true, false

간선들을 테스트할 수 있다.

(5) 검증기준을 고려한 테스트 설계

검증기준을 고려하여 단위 테스트 수행을 위한 테스트 케이스를 작성하는 방법은

다음과 같은 과정으로 이루어진다. ① 흐름도를 작성하기 위한 소스코드 분석 ② 흐름도로부터 테스트 할 적용 범위에 대해 테스트 경로 계획 ③ 각 경로에 대해 테스트 조건들을 평가 ④ 각 조건들에 대한 입력 값과 출력 값을 예상

[사례 3-5] 화이트박스 테스트 케이스 작성

다음은 이진 탐색 수행하는 프로그램이다.

If A then B

else C;

If D then E

else F;


157

[그림 3-20] 이진 탐색

이 프로그램은 처음에 배열의 중간 값을 선택한 후 킷값과 비교한다. 만약 같다

면 프로그램은 종료가 되면서 중간 위치를 반환한다. 만약 일치하지 않는 경우에 중간 값이 킷값보다 작다면 배열에서 찾고자 하는 위치는 중간과 Top 사이에 있을 것이고 그렇지 않고 크다면 중간 값과 Bottom 사이의 위치에 있을 것이다.

이러한 탐색의 과정을 단계 별로 묘사하면 다음과 같다. 시작:

[그림 3-21] 이진 탐색 스텝 1

반복 0:

int Bottom, Top, Mid; int T[ ], Key, n; //n은 T 배열의 크기 char Found[6];

Bottom = 0; Top = n-1; L = (Top + Bottom) /2; Found = FALSE;

while (Bottom <= Top) { Mid = (Top+Bottom)/2; Found = ‘False’ if (Key == T[Mid]) Found = ‘TRUE’;

return Mid; else if (Key > T[Mid]) Bottom = Mid + 1; else Top = Mid - 1; }


158


반복 1:


반복 2:



159

반복 3:


Found는 true가 되면서 프로그램은 Mid 값을 반환하게 된다. 이러한 일련의 절차

를 흐름도로 표현하면 다음과 같다.

[그림 3-26] 이진 탐색 흐름도


160

위 흐름도를 기로로 모든 경로를 테스트하는 테스트 케이스를 제안해 보자. A, B, C, E, F, H, J, B, C, E, G, H, J, B, C, D, J, B, I

하나의 경로로 모든 문장과 분기를 경유하는 예이다. 그러나 이러한 방법은 문

제가 생길 수 있다. A, B, C, D, J, B, C, E, F, H, J, B, C, E, G, H, J, B, I

이와 같은 경우는 B, C, D의 경로를 먼저 실행하게 될 경우에 만약 T(Mid)가 키

값과 같게 되면 반복문이 끝나기 때문에 이하 경로들은 테스트할 수 없게 된다. 일반적으로 위의 흐름도에 같은 경우 영역을 분리하여 테스트 케이스를 설계하여

야 한다. 예를 들면, 키를 발견하기 전에 배열에서 한 번 수행 될 다음 단계를 분석

하여 간단한 반복 구조를 생각하고 나눌 수 있는 영역으로 분리하여 테스트 케이스

의 경로를 선택한다. 다음 두 경우는 적절히 분리하여 테스트 케이스를 적용한 예이다. A, B, C, E, G, H, J, B, C, D, J, B, I A, B, C, E, F, H, J, B, C, D, J, B, I

3.4.3 McCabe와 기본 경로 테스트

기본 경로(basis path) 테스트는 1장에서 이미 살펴 보았듯이 프로그램을 제어 흐름

그래프로 표현하고 그래프상에 존재하는 기본 경로들을 테스트하는 방법이다. 기본 경로 집합은 선형적으로 독립적인 프로그램 경로(linearly independent path)들의 집합

을 말하며 이 경로 집합을 사용하여 프로그램상에 존재하는 어떤 경로도 선형적으

로 조합하여 표현할 수 있는 특징을 지니고 있다. [사례 3-6] 기본 경로 테스트의 예제


161

i = 1; while (i<n) { If (i>10) d = d+10; else d = d-10; i++; } printf(“%d”, d);

[그림 3-27] 기본 경로 테스팅

[그림 3-27]에 주어진 프로그램에서 기본 경로 집합을 구하는 과정을 설명한다. 먼저 제어 흐름 그래프에 있는 각 간선에 고유 번호를 구분하고 프로그램 경로를 간선 벡터(edge vector)를 사용하여 표현한다. 간선 벡터의 크기는 제어 흐름 그래프

의 간선의 개수로 결정되며 벡터 i-번째 항목은 경로를 구성하는데 i-번째 간선이 몇 번 사용되었는지를 나타낸다. 위 그림에서 간선 벡터의 크기는 10이다. 만약 경

로 1-2-3-4-6-8-9-10를 간선 벡터로 나타내면 <1, 1, 1, 1, 0, 1, 0, 1, 1, 1>으로 나타낼 수 있다. 또한 경로 1-2-3-4-6-8-3-4-6-8-9-10은 3, 4, 6, 8 번 간선이 각각 두 번씩 경로에 나타나므로 간선 벡터 <1, 1, 2, 2, 0, 2, 0, 2, 1, 1>로 표현된다. 이 경로는 다음과 같이 다른 경로들의 선형 조합으로 표현할 수 있다:

B1= <1, 1, 1, 1, 0, 1, 0, 1, 1, 1>: 경로 1-2-3-4-6-8-9-10 B2=<1, 1, 0, 0, 0, 0, 0, 0, 1, 1>: 경로 1-2-9-10 B3=<1, 1, 2, 2, 0, 2, 0, 2, 1, 1> : 경로 1-2-3-4-6-8-3-4-6-8-9-10 라 할 때, B3=2 B1+(-1) B2 즉, 경로 B3는 B1과 B2의 선형 조합으로 표현된다.


162

기본 경로 집합을 구하기 위해서는 프로그램 상에 존재하는 선형적으로 독립된 최대 경로 집합을 구하면 된다. 프로그램 경로 집합이 선형적으로 독립되기 위해서

는 경로 집합의 어떤 경로도 집합내의 다른 경로들의 선형 조합으로 표현되어서는 안 된다. [그림 3-27]의 예에서 경로 집합 {1-2-9-10, 1-2-3-4-6-8-9-10, 1-2-3-5-7-8-9-10}은 선형적으로 독립된 경로들의 최대 집합, 즉 기본 경로 집합을 이룬다. 그러나, {1-2-9-10, 1-2-3-4-6-8-9-10, 1-2-3-4-6-8-3-4-6-8-9-10}은 경로 1-2-3-4-6-8-3-4-6-8-9-10이 집합내의 다른 경로들의 선형 조합으로 표현될 수 있기 때문이다. 이와 같이 기본 경로 집합을 구한 후에 이 경로들을 실행할 수 있는 테스트 데이터를 생성하고 테

스트하는 것이 기본 경로 테스트의 목표이다. 기본 경로 테스트는 McCabe가 제안한 테스트 방법으로 소프트웨어 복잡도 척도

중의 하나인 사이클로매틱 복잡도에 바탕을 두고 있다. 사이클로매틱 복잡도는 주

어진 논리 흐름 그래프에서 선형적으로 독립적인 프로그램 경로들의 개수이며 다음

과 같이 구할 수 있다: E-N+2 여기에서 E는 제어 흐름 그래프상에 있는 간선들의 개수이고, N은 노드들의 개수

이다. 제 1장에 소개된 McCabe의 복잡도를 구하는 공식에 의하면 E=10, N=9이므로 기본 경로들의 개수는 10-9+2=3임을 알 수 있다. 따라서 세 개의 기본 경로들에 대

해 테스트를 수행할 수 있다. 사이클로매틱 복잡도는 또한 제어 흐름 그래프의 있는 영역(region)들의 개수와도

관계가 있다. 만약 제어 흐름 그래프 종료 노드에서 시작 노드로 간선을 연결한다

면 제어 흐름 그래프가 간선과 노드들에 의해 둘러싸인 여러 개의 영역들로 분할된

다. 사이클로매틱 복잡도는 이와 같이 분할된 영역들의 개수이다. [그림 3-28]은 [그림 3-27]에 주어진 제어 흐름 그래프의 영역을 보여주며 3개의 영역이 있음을 알 수 있다.

여기에서 종료 노드로부터 시작 노드로 가는 간선을 고려하지 않고 영역의 개수

를 계산하려면 다음의 공식을 사용한다: 사이클로매틱 복잡도 = 영역들의 개수 + 1 보다 간단하게 사이클로매틱 복잡도를 계산하려면 제어 흐름 그래프에 있는 분기


163

노드들을 개수에 1을 더하면 된다. 사이클로매틱 복잡도 = 분기 노드들의 개수 + 1 이 경우에도 위 그림에 주어진 프로그램의 사이클로매틱 복잡도는 3임을 알 수

있다. 사이클로매틱 복잡도는 프로그램를 이해하는 작업과 테스트 및 유지보수작업

이 얼마나 어려운지를 판별하는 기반이 된다. 보통 3-7 정도의 사이클로매틱 복잡도

를 갖는 프로그램은 잘 구조화된 프로그램이라 볼 수 있으며 가급적 10 이하의 복

잡도를 갖도록 프로그램을 구성해야 한다.

[그림 3-28] 제어 흐름 그래프에 존재하는 영역

영역1

영역2

영역3


164

3.4.5 입력 도메인 분석 기법

입력 도메인 분석 기법은 도메인 오류들을 효과적으로 검출하기 위해 개발된 테

스트 방법이다. 도메인 오류란 특정 입력 값으로 프로그램을 실행하는 과정에서 프

로그램의 제어 흐름상의 오류로 잘못된 경로를 따를 때 발생하는 오류를 말한다. 예를 들면 프로그램에 올바른 조건문이 “if x>=10”이지만 “if x>10”와 같이 오류가 있다면 x=10인에 대해 프로그램은 잘못된 경로를 따라 실행할 것이다.

이러한 도메인 오류를 테스트하기 위해 입력 영역을 구분하는 경계나 경계 근처

의 값을 테스트 케이스로 선정한다.

[표 3-25] 도메인 테스트

위 프로그램에서 입력으로 올 수 있는 x와 y의 범위를 10<=x, y<=20이라고 가정

할 때 입력 영역은 다음 그림으로 나타낼 수 있다.

[그림 3-29] 도메인 테스트 영역

여기서 회색 영역이 경로를 실행하기 위한 입력 영역을 만족하는 부분이다. 만약 올바른 조건문이 “if (x>y+1)”라 하면 도메인 테스트가 어떻게 오류를 검출할 수있는

scanf(“%d”, ”%d”, &x, &y);

if (x>=y+1) z = x + 20;

else

z = x – 20;

10 20x

20

y


165

지 살펴보자. 우선 도메인 테스트는 입력 영역의 경계에서 세개의 테스트 데이터를 구한다. 그 중 두개는 입력 경계에 있는 테스트 케이스고 나머지는 하나의 입력 영

역 외부에서 선정한다. 아래 그림은 이러한 과정을 보여준다. 이때 경계에 있는 테

스트 케이스를 ON 포인트라 하며 경계 외부에 있는 케이스를 OFF 포인터라 한다. 그림에서는 (x=13, y=12), (x=18, y=17)를 ON 포인트로 선정했고 (x=15, y=15)를 OFF 포인터로 선정했다.

[그림 3-30] 도메인 테스트의 테스트 케이스 설정

이들 테스트 케이스들에 대해 프로그램을 실행하면 두개의 ON 포인트들에 대해

서 프로그램의 실행값이 기대하는 결과와는 다르게 출력됨을 알 수 있다. 다음 표

는 세개의 테스트 케이스들에 대해 프로그램을 실행하였을 때 실행 결과와 올바른 결과를 보여준다.

[표 3-26] 도메인 테스트 케이스

테스트 케이스 실행 결과 올바른 결과 오류 검출

(x=13, y=12) z =23 z =-7 검출됨

(x=18, y=17) z =28 z =-2 검출됨

(x=15, y=15) z =-5 z =-5 검출안됨

이와 같이 도메인 테스팅은 입력 영역을 이루는 경계로부터 두개의 ON 포인트와 한 개의 OFF 포인트를 테스트 케이스로 선정한다. 3.4.6 기능 분석

10 20x

20

y

ON

OFF

ON


166

기능 분석(functional analysis) 기법은 테스트 케이스를 추출하는데 가장 많이 쓰이

는 방법 중 하나이다. 기본 개념은 아주 간단하다. 즉, 개발자는 원하는 출력을 얻

기 위해 특정 기능을 시스템에 구현한다. 따라서 테스트 케이스는 구축된 시스템이 예상된 결과를 출력하기 위해 정의된 기능들이 실제로 정확하게 수행하는지 검증하

기 위해 만든 것이다. 기능 분석 기법을 수행한다는 것은 다음 두 가지 질문에 대한 물음을 찾는 것이

다.

이 시스템의 예상된 결과는 무엇인가?(이러한 질문의 답은 시스템의 요구사항, 기능 설명서 등에 나타나 있다.)

이 시스템이 정확하게 작동했는지 어떻게 측정할 것인가?(기능에 대한 테스트 케이스를 잘 추출했는지가 답이 된다.)

기능 분석의 규모는 적용하는 대상에 따라 크게 달라 질 수 있다. 적용 대상이

적은 원시코드 라인으로 이루어진 하나의 모듈이라면 가능한 입력과 출력에 대해 적은 테스트 케이스를 만들 수 있다. 그러나 비즈니스 프로세스를 처리하기 위한 통합레벨 시스템의 윈도우 프로그램이라면 작성 가능한 테스트 케이스의 수는 대규

모로 많아질 뿐 아니라 비즈니스의 배경 지식, 상식, 경험, 직관 등 많은 요소들이 테스트 엔지니어들에게 필요할 것이다.

(1) 기능 명세서로부터의 테스트 케이스 추출

“무엇을 테스트 할 것인가?”라는 질문의 대답은 곧 “무엇을 이 시스템에서 예상

할 수 있는가?”라는 물음에 대한 대답과 같은 것이어야 한다. 만약 시스템의 요구 사항을 알 수 없다면 테스트는 어려워진다. 그러므로 전통적인 요구 명세 기반의 테스트처럼 요구명세를 읽고 이해하고 분석하는 첫번째 작업 단계가 필요하다.

예로 본 장의 앞부분에 소개한 요금청수(billing) 시스템에 대한 기능 명세에 대해 자세히 살펴보도록 한다.

[표 3-27] 기능 분석 요구 명세서

요구사항 유효 기간 30일 내에 요금을 지불하지 않은 고객들에 대해 독

촉장 인쇄한다.

표면적으로 보면 이 요구명세는 직관적이고 테스트가 용이하게 보이지만 테스트


167

가능성 측면에서 다시 검토할 필요가 있다. 검토를 위하여 다음과 같이 조금 더 구

체적인 질문이 필요하다. “인수 가능한 테스트 케이스를 만들기 위해 이 요구명세로부터 우리가 알아야 할

것은 무엇인가?” 요구명세서를 분석하고 테스트 케이스를 추출하는데 있어서 위의 질문은 더 많은

세부적 질문으로 이어져야 한다. 요금청수 시스템의 기능명세서를 예로 세부적 질

문들을 살펴본다.

고객이 정확히 30일이 되는 날 지불하지 않았다면 무슨 사건이 발생하는

가? 30일째 되는 당일 날 고객에게 독촉장을 발송하는가? 아니면 31일 째 되는 날 발송하는가?

이러한 기능 요구가 모든 고객에게 적용되는가? 사장의 가족과 같은 고객

은 특별 대우가 있는가? 정확히 30일 후에 프린트되는가? 만약 크리스마스와 같은 국경일이 겹쳐

있다면 어떻게 하는가? 우편으로 프린트 되어야 하는가? 팩스, 또는 이메일과 같은 다른 매체의

사용은 어떠한가? 독촉장을 프린트하는데 드는 추가 비용을 청구할 것인가? 한다면 일부만

부담시키는가? 아니면 전액을 부담시키는가? 이 요구명세 사항처럼 모든 지불과 관련된 항목에 적용시킬 것인가? 만약

대금의 일부만 지급한 상태에서 물품이 고객의 불만으로 반품되었을 경우

에는 어떠한가? 독촉장에 필요한 정보, 형태, 자료 내용들은 무엇인가? 현재 고객이 독촉장을 받을 수 없는 부재중인 상태에도 발송을 할 것인

가? 고객이 여러 물품을 구입했고 같은 날에 지급 만기가 되었을 경우 모든

물품에 대해 각각 독촉장을 만들 것인가?

(2) 테스트가능성을 높이기 위한 요구 명세서

요구 명세서 작성자는 기능 요구 명세서에 테스트 가능성을 높이도록 가독성, 이

해성, 정확성, 완전성, 수정가능성, 문서화 등의 특징을 포함하고 있는 요구명세서를 다시 작성할 필요가 있다. 테스트 가능성이 높은 요구명세서를 다시 작성하면 다음


168

과 같다. 1. 30일 안에 대금을 지불하지 않으면서 계좌의 잔액이 부족하여 결재 안된 모

든 고객에게 각각 독촉장을 발송한다. 2. 30일의 기준은 고객이 마지막으로 대금을 지불하였거나 고객이 독촉장 또는

청구서를 마지막으로 받은 날로부터 계산된다. 3. 독촉장은 발행되는 날을 기준으로 마이너스 잔액이 되는 경우만 인쇄한다. 마

이너스 잔액은 고객에 의하여 소유한 계좌에 예치한 총액을 의미한다. 4. 고객이 대금을 지불하고 주문을 냈을 때, 혹은 주문을 취소하고 리턴 했을 때

총잔액을 다시 계산한다. 5. 고객이 받을 금액이 있는 경우도 있다. 이를 신용잔고(credit balance)라고 한다. 6. 주문이나 이루어지기 전 또는 배송되기 전에 미리 대금을 지불할 수도 있다.

선지급은 독촉장의 발행에 영향을 미치지 않는다. 7. 독촉장은 고객의 이름과 주소 그리고 계좌 번호, 미결재 금액, 주문번호, 제품

정보, 미결재 금액에 대한 설명을 포함하고 있어야 한다. 8. 한 명의 고객에 대해 30일 이내에 결재되지 않은 주문이 여러 개이더라도 하

나의 독촉장만 발송되어야 한다. 9. 30일 안에 마이너스 잔액에 대하여 지불하지 않았다면 이미 발행된 독촉장의

개수와 관계없이 새로운 독촉장을 발송한다. 10. 이 요구사항은 현재 활동 중인 모든 고객에게 해당되고 활동하지 않는 고객

에게는 적용하지 않는다. 11. 독촉장은 우편발송, 팩스, 이메일 중 고객이 선호하는 통신 방법으로 발송한

다. 12. 만약 고객이 선호하는 통신 방법을 선택하지 않았을 경우에는 기본으로 우편

발송한다. 13. 독촉장은 정확히 30일 째 되는 날 발송되어야 하며 3일 안에 고객에게 도착

해야 한다. 14. 30일 안에 분할 납부한 경우라도 독촉장은 발송된다. 다만 14번 항에 속한 경

우는 제외한다. 15. 다음과 같은 경우에는 독촉장을 발송하지 않는다.

① 미납된 주문이 있을지라도 30일이 안 된 미결제 상태의 다른 주문에 대해 독촉장을 발송하지 않는다.

② 잔액이 0이거나 신용 잔액이 있을 경우는 마이너스 잔액이 아니므로 독촉

장을 발행하지 않는다. ③ 고객이 주문하여 받는 물건에 대하여 불만을 제기한 경우


169

④ 15일 이내에 같은 마이너스 잔액에 대하여 독촉장이 이미 발행된 경우. 16. 독촉장의 데이터 내용 및 형태는 고객의 정보에 기반한다. 지금까지 보아온 요구명세는 위에서 제시한 내용보다 내용이 많지만 구체적이기

때문에 테스트하기에 더욱 적절하다. 이렇게 다시 구체적으로 정의된 요구명세는 테스트 엔지니어들이 작업하는 것이 아니라 요구명세서를 작성하면서 기능에 대해 검증하고 재검토하는 과정들이 필요하고 그 결과로 모든 것들이 정의되어있어야 한

다.

(3) 테스트 케이스 작성

위에서 테스트 케이스를 추출하기 쉽도록 요구사항을 재구성하였다. 본 절에서는

각 요구사항에 대한 테스트 케이스를 작성한다.

[표 3-28] 기능 분석 테스트 케이스

1. 주문 발생 후 30일 동안 대금을 지불하지 않고 동시에 계좌의 잔액이 부족한 모

든 고객에게 독촉장을 발송한다.

1.1 잔액이 부족한 계좌를 가지고 있는 모든 고객에게 독촉장 발송을 한다.

1.1.1 발송 당일 날 잔액이 부족한 계좌를 가지고 있는 고객에게 발송

1.1.2 30일 동안 잔액이 부족한 계좌를 가지고있는 않은 고객에게 발송 T/C

1.1.3 30일 기 내에 잔액이 부족한 날이 있었지만 이미 대금을 지불한 경우

1.2 잔액이 부족한 계좌를 가지고 있으면서 다음에 해당하는 기간 동안 대금을

지불하지 않은 고객에게 발송한다.

1.2.1 0일

1.2.2 1일

1.2.3 15일 T/C

1.2.4 29일

1.3 잔액이 부족한 계좌를 가지고 있으면서 다음에 해당하는 기간동안 대금을 지

불하지 않은 고객에게 발송한다.

1.3.1 30일

1.3.2 31일

1.3.3 45일 T/C

1.3.4 90일


170

T/C 1.4 대금을 지불한 후 거래를 취소한 고객에게 독촉장을 발송한다.

2. 30일이라는 기준은 고객이 최후 대금(할부)을 지불한 날 또는 고객이 독촉장 또는

청구서를 마지막으로 받은 날로부터 계산한다.

2.1 미결재된 경우 다음 제시한 날로부터 30일이 지난 고객에게 발송한다.

2.1.1 고객이 최후 대금(할부)을 지급한 날

2.1.2 고객이 마지막으로 청구서를 받은 날 T/C

2.1.3 고객이 마지막으로 독촉장을 받은 날

2.2 미결재된 경우 다음 제시한 날로부터 31일이 지난 고객에게 발송한다.

2.2.1 고객이 최후 대금(할부)을 지급한 날

2.2.2 고객이 마지막으로 청구서를 받은 날 T/C

2.2.3 고객이 마지막으로 독촉장을 받은 날

3. 계좌에 예치된 잔액은 있지만 결재 승인을 하지 않았을 경우 예치된 금액은 독촉

장 발송에 영향을 미치지 않는다.

3.1 잔액을 예치한 후 결재를 마친 고객에게 독촉장을 발송한다.

T/C 3.2 잔액을 예치했지만 결재 승인을 하지 않은 고객에게 독촉장을 발송한

다.

4. 독촉장은 고객의 이름과 주소 그리고 계좌 번호, 미결재 금액, 주문번호, 제품정

보, 미결재 금액에 대한 설명을 포함하고 있어야 한다.

4.1 고객의 이름, 주소, 계좌번호를 정확히 출력했는지 확인한다.

4.2 잔액을 정확히 계산하고 출력했는지 확인한다.

4.3 주문 번호와 상품 정보가 정확한지 확인한다. T/C

4.4 미결제에 대한 내용의 설명이 명확한지 확인한다.

5. 한 명의 고객에 대해 30일 이내에 결재되지 않은 주문이 여러 개이더라도 하나의

독촉장만 발송되어야 한다.

T/C 5.1 결제되지 않은 여러 개의 주문이 있는 상태에서 하나의 독촉장만이 발송

되는지 확인한다.

6. 기존에 발송된 독촉장의 개수와 관계없이 새로이 발송된다.

6.1 미결제된 계좌를 갖고 있는 고객에 대하여 이미 발송된 아래와 같은 독촉장

의 개수와 관련된 경우에 새로이 발송한다.

6.1.1 발송된 독촉장이 하나도 없을 경우

6.1.2 발송된 독촉장이 1개일 경우

T/C

6.1.3 발송된 독촉장이 2 ~ 4개 일 경우


171

6.1.4 발송된 독촉장이 5개 이상일 경우

T/C 6.2 기존에 독촉장을 받았지만 이미 결재를 완료한 고객에 대하여 독촉장을

발송한다.

7. 이 요구사항은 현재 활동 중인 모든 고객에게 해당되고 활동하지 않는 고객에게

는 적용하지 않는다.

T/C 7.1 활동중인 고객에게 독촉장을 발송한다.

T/C 7.2 활동하지 않는 고객에게 독촉장을 발송한다.

T/C 7.3 활동하는 고객에 대해 독촉장을 생성한 후 발송하기 전에 고객의 상태를

활동하지 않는 고객으로 변경하여 발송을 시도한다.

8. 독촉장은 우편발송, 팩스, 이메일 중 고객이 선택한 통신 방법으로 발송한다.

T/C 8.1 위 방법 중 팩스와 이메일을 동시에 발송한다(동등분할기법).

T/C 8.2 고객이 선택한 방법으로 발송한다.

T/C 8.3 팩스를 선택한 고객에게 팩스로 발송한다.

T/C 8.4 팩스를 선택하지 않은 고객에게 팩스로 발송한다.

T/C 8.5 이메일을 선택한 고객에게 이메일로 발송한다.

T/C 8.6 이메일을 선택하지 않은 고객에게 이메일로 발송한다.

9. 만약 고객이 선호하는 통신 방법을 선택하지 않았을 경우에는 기본으로 우편 발

송한다.

T/C 9.1 통신 방법을 선택하지 않은 고객에 대해 우편 발송한다.

10. 독촉장은 정확히 30일 째 되는 날 발송되어야 하며 3일 안에 고객에게 도착해야

한다.

T/C 10.1 표본으로 독촉장 발송을 발송한 후 목적지에 3일 안에 도착하는지 추적

한다.

11. 30일 안에 분할 납부한 경우라도 미결제 상태이면 독촉장이 발송된다. 다만 14번

항에 속한 경우는 제외한다.

T/C 11.1 한번도 분할 납부하지 않은 경우에 대해 독촉장을 발송한다.

T/C 11.2 한번 납부 한 경우에 대해 발송한다.

T/C 11.3 완납하기 바로 전을 기준으로 발송한다(예: 10번 중 9번 납부한 상태).

T/C 11.4 분할 납부가 모두 수행된 상태에서 발송한다.

12. 다음과 같은 경우에는 독촉장을 발송하지 않는다.

12- 미납된 주문이 있을지라도 30일이 안 된 미결제 상태의 다른 주문에 대해 독

촉장은 발송하지 않는다.


172

T/C 12.1 주문 후 30일이 안 된 주문에 대해 독촉장을 발송한다.

12- 미결재된 고객이 한 명도 없을 경우에는 발송하지 않는다.

T/C 12.2 미결제된 고객이 없는 상태에서 임의로 독촉장을 발송한다.

12- 고객이 수령 받은 물품에 대해서 불만을 표현했을 경우에는 발송하지 않는다.

T/C 12.3 불만을 표현한 고객에게 독촉장을 발송한다.

13. 독촉장의 데이터 내용 및 형태는 고객의 정보에 기반한다.

T/C 13.1 고객 정보 데이터 기반의 표준 문서와 독촉장에 사용된 데이터 내용 및

형태를 비교한다.

14. 만약 서기 2000년 전에 시스템이 구현되었다면 다음 테스트 케이스도 고려해야

한다.

T/C 14.1 시스템 시간을 2000년 전으로 세팅한 후 테스트한다.

T/C 14.2 1999년 12월 31일에서 2000년 1월 1일로 시스템 시간을 경과시키면서 테

스트한다.

T/C 14.3 시스템 시간을 정확히 2000년 1월 1일로 세팅한 후 테스트한다.

T/C 14.4 시스템 시간을 2000년 1월 1일 이후의 시간으로 세팅한 후 테스트한다.

3.7 테스트 케이스 최소화

효과적인 테스트 계획의 목표 중 하나는 필요한 테스트 케이스의 개수를 줄이는 것이다. 반대로 너무 적어서 부적절한 테스트가 될 수도 있고 또는 아주 많은 테스

트 케이스의 개수가 대상 시스템의 테스트에 적합하지 않은 경우도 있다. 이는 적

당한 테스트 케이스의 개수는 고정되어 있지 않기 때문이다. 하지만 테스트 케이스

가 간단하고 적은 테스트 케이스로 모든 부분에 대해 테스트 가능하다면 가장 좋은 케이스이며 이에 대한 확인이 필요하다.

테스트 케이스를 줄이는 방법은 여러 가지가 있을 수 있다. 이러한 방법들은 많

은 결점들을 감소시킬 수 있으면서 동시에 효과적인 테스트가 가능하게 한다. 주요

한 테스트 케이스 최소화 방법은 다음과 같다. ① 동등 분할 ② 위험 순위 우선 순위 ③ 테스트 수행 효율 개선: 이는 테스트 케이스의 개수를 줄이는데 직접적인 관

련이 없는 듯 보인다. 하지만 테스트 케이스의 최소화와 같은 목적을 가지고


173

있다. 왜냐하면 테스트 케이스의 수행이 빠르고 비용이 저렴하다면 테스트 케

이스의 최소화에 대해 커다란 관심이 없을 것이기 때문이다. 이러한 방법들은 테스트 상황을 분석하고 위험순위를 정의하고 이미 존재하는 테

스트 케이스를 검토하고 테스트 케이스를 최소화한 전후 관계를 살펴 보아야 한다. 불필요한 테스트 케이스를 줄이는 구체적인 방법은 다음과 같다.

① 테스트 케이스의 목록을 살펴보면서 중복되거나 같은 목적을 갖는 테스트 케

이스가 다른 영역에 있다면 제거한다. ② 동등 분할 기법을 다시 적용해 본다. 이미 적용했을 경우라도 테스트 케이스

를 작성하는 중에 또다시 많은 테스트 케이스가 증가하고 복잡해지기 때문이

다. ③ 테스트 케이스 중 실제 사용할 것과 사용하지 않을 것을 검토한다. ④ 테스트 케이스에 우선 순위를 적용하여 최하위 순위에 해당하는 것을 제거한

다. ⑤ 동등 분할을 적용하여 테스트를 적용할 대상과 범위를 줄인다. ⑥ 테스트 케이스의 목록을 검토하면서 테스트 수행했더라도 오류를 찾아 낼 수

없는 테스트 케이스를 찾아낸다. ⑦ 추적성 메트릭을 작성하면서 요구사항 및 기능들의 적용 범위가 중복되었는

지 확인한다. 최소화 된 테스트 케이스와 원래의 테스트 케이스를 같이 수행하면서 불필요한

테스트 케이스를 확인하는 것도 좋은 방법이 될 수 있다. 즉, 원래의 테스트 케이스

와 최소화된 테스트 케이스를 모두 수행한 후 발견된 오류들을 비교해 차기 수행하

려는 테스트 케이스에 적용한다. 이러한 방법으로 테스트 케이스를 최소화하는데 효과를 얻었다면 테스트 케이스

설계에 대한 전후 상황을 다시 검토하고 얻어진 테스트 케이스를 테스트 슈트 또는 테스트 라이브러리에 저장한다.

Documents

AT2_테스트 케이스 설계