[CTFL] 4장. 테스트 분석과 설계

ISTQB-CTFL 실러버스 4장 정리하기

2026년 06월 05일

4장. 테스트 분석과 설계

용어

인수 조건: 사용자 스토리가 완료되었다고 판단하기 위해 충족해야 하는 조건
인수 테스트 주도 개발(ATDD): 인수 조건을 기반으로 테스트 케이스를 먼저 작성한 후 개발을 진행하는 테스트 우선 접근법
블랙박스 테스트 기법: 내부 구조를 참조하지 않고 명세된 동작을 기반으로 테스트 케이스를 도출하는 기법
경계값 분석(BVA): 동등 분할의 경계값을 기반으로 테스트 케이스를 도출하는 기법
분기 커버리지: 제어 흐름 그래프에서 모든 분기(참/거짓)가 실행되었는지를 측정하는 커버리지 기준
체크리스트 기반 테스팅: 사전에 작성된 체크리스트를 기반으로 테스트를 설계하고 수행하는 기법
협업 기반 테스트 접근법: 팀 협업과 커뮤니케이션을 통해 결함 예방과 품질 향상에 초점을 둔 접근법
커버리지: 테스트 수행 범위를 측정하는 지표
커버리지 항목: 커버리지 측정을 위한 개별 측정 단위
결정 테이블 테스팅: 조건 조합에 따른 시스템 동작을 테이블로 정리해 테스트 케이스를 도출하는 기법
동등 분할(EP): 테스트 대상 데이터를 동일하게 처리되는 분할로 나누어 테스트 케이스를 도출하는 기법
오류 추정: 테스터의 경험과 지식을 바탕으로 오류, 결함, 장애를 예측하는 테스트 기법
경험 기반 테스트 기법: 테스터의 지식과 경험을 활용해 테스트 케이스를 도출하는 기법
탐색적 테스팅: 테스트 설계와 실행을 동시에 수행하며 테스트 대상을 탐색하는 기법
상태 전이 테스팅: 시스템의 상태 변화를 모델링하여 테스트 케이스를 도출하는 기법
구문 커버리지: 코드의 모든 실행 가능한 구문이 적어도 한 번 실행되었는지를 측정하는 커버리지 기준
테스트 기법: 테스트 케이스를 체계적으로 도출하기 위한 방법론
화이트박스 테스트 기법: 내부 구조와 처리 방식을 기반으로 테스트 케이스를 도출하는 기법

4.1 테스트 기법 개요

테스트 기법은 테스터의 테스트 분석(무엇을 테스트할지) 과 테스트 설계(어떻게 테스트할지) 작업을 지원한다.

CTFL 실러버스는 테스트 기법을 블랙박스, 화이트박스, 경험 기반으로 분류하고 있다.

블랙박스 테스트 기법: 명세 기반 기법으로 내부 구조를 참조하지 않고 테스트 대상의 명시된 동작에 대한 분석을 기반으로 한다. 테스트 케이스는 SW 구현 방식에 의존하지 않기 때문에 구현이 바뀌더라도 필요한 동작이 동일하다면 테스트 케이스는 여전히 유효하다.
화이트박스 테스트 기법: 구조 기반 기법으로 테스트 대상의 내부 구조와 처리에 대한 분석을 기반으로 한다. 테스트 케이스는 SW 설계 방식에 의존하기 때문에 테스트 대상의 설계나 구현이 끝난 후에 만들 수 있다.
경험 기반 테스트 기법: 테스터의 지식과 경험을 테스트 케이스 설계 및 구현에 효과적으로 활용하게 한다. 테스터의 능력에 따라 효과의 범위가 넓으며 위 두 가지 기법으로 식별할 수 없는 결함을 찾을 수 있게 해준다.

4.2 블랙박스 테스트 기법

대표적인 블랙박스 테스트 기법은 다음과 같다.

동등 분할
경계값 분석
결정 테이블 테스팅
상태 전이 테스팅

4.2.1 동등 분할

동등 분할(EP, Equivalence Partitioning) 은 테스트 대상이 하나의 분할에 포함된 모든 요소를 동일한 방식으로 처리할 것이라는 가정하에 데이터를 분할 단위로 나눈다. 이 기법의 근거 이론은 동등 분할에 속한 특정 값을 테스트하는 테스트 케이스로 결함을 식별할 수 있다면, 같은 동등 분할의 다른 어떤 값을 테스트하는 테스트 케이스라도 해당 결함을 식별할 수 있어야 한다는 것이다.

따라서 각 분할에 대해 하나의 테스트만 수행하면 충분하다.

분할은 연속적이거나 연속적이지 않을 수도 있으며 정렬되어 있거나 유한 또는 무한일 수 있다. 분할은 서로 겹치지 않아야 하며 값이 없는 공집합일 수는 없다.

유효 분할: 유효한 값을 포함하는 분할
비유효 분할: 유효하지 않은 값을 포함하는 분할

분할 집합이 다수인 경우 가장 간단한 커버리지 기준을 Each Choice Coverage(이치 초이스 커버리지) 라고 한다. 이치 초이스 커버리지는 테스트 케이스가 모든 분할 집합의 각 분할을 최소 한 번은 실행할 것을 요구한다.

※ 이치 초이스 커버리지에서는 분할의 조합을 고려하지 않는다.

4.2.2 경계값 분석

경계값 분석(BVA, Boundary Value Analysis) 은 동등 분할의 경계 실행을 기반으로 하는 테스트 기법이다. 따라서 경계값 분석은 정렬된 분할에만 사용할 수 있다. 분할의 최솟값과 최댓값이 경계값이 된다.

2-value BVA: 각 경계값에 대해 두 개의 커버리지 항목을 도출한다. (경계값과 경계값 외부에 있는 경계와 가장 가까운 값을 선정하여 테스트 케이스 생성)
3-value BVA: 각 경계값에 대해 세 개의 커버리지 항목을 도출한다. (경계값, 경계 내부와 외부에서 경계와 가장 가까운 값을 선정하여 테스트 케이스 생성)

3-value BVA는 2-value BVA보다 엄격하다. 2-value BVA로 식별할 수 없는 결함을 3-value BVA로 식별할 가능성이 크다.

4.2.3 결정 테이블 테스팅

결정 테이블은 서로 다른 조건 조합으로 달라지는 결과를 나타내는 방식으로, 요구사항이 제대로 구현되었는지를 테스트하는 데 사용한다. 결정 테이블은 비즈니스 규칙과 같은 복잡한 논리를 기록하는 효과적인 방법이다.

결정 테이블에서는 조건들과 그에 따른 시스템의 동작 결과를 테이블의 행에 구성한다. 열은 각각 하나의 결정 규칙을 나타내며 어떤 고유한 조건 조합을 연관 동작과 함께 정의한다.

제한-입력(limited-entry) 결정 테이블: 모든 조건과 동작 결괏값을 부울값으로 표시한다.
확장-입력(extended-entry) 결정 테이블: 조건 및 동작 결괏값의 일부 또는 전부가 복수의 값을 취할 수 있다.

조건의 표기법은 다음과 같다.

T: 조건이 충족됨을 의미
F: 조건이 충족되지 않았음을 의미
-: 해당 조건 값이 결과에 영향이 없음을 의미
N/A: 해당 규칙에서 조건이 실행 불가능함을 의미

결과 동작은 다음과 같다. 기타 표기법도 사용 가능하다.

X: 동작이 발생해야 함을 의미
공백: 동작이 발생하지 않아야 함을 의미

결정 테이블 테스팅의 강점은 간과했을 수도 있는 조합을 포함한 모든 조건 조합을 식별하는 체계적인 방법을 제공한다는 점이다. 또한 누락되거나 모순되는 요구사항을 찾는 데 도움이 된다.

※ 조건의 수에 따라 규칙의 수는 기하급수적으로 늘어나기 때문에 모든 결정 규칙을 실행하는 데 오랜 시간이 걸릴 수 있다. 이런 경우 결정 테이블을 최소화하거나 리스크 기반 접근법을 사용할 수 있다.

4.2.4 상태 전이 테스팅

상태 다이어그램은 가능한 상태와 유효한 상태 전이를 표시해 시스템 동작을 모델링한다. 전이는 하나의 이벤트에 의해 발생하며 별도의 가드(guard) 조건이 있을 수 있다.

상태 테이블에서 행(row)은 상태를 나타내고 열(column)은 이벤트를 (가드 조건이 있는 경우 함께) 나타낸다. 테이블 항목(셀, cell)은 전이를 나타내며 정의되어 있는 경우에는 목표 상태와 그에 따른 결과 동작도 포함한다. 상태 전이 다이어그램과 달리 상태 테이블은 유효하지 않은 전이를 빈 셀로 명확하게 보여준다.

상태 전이 테스팅에는 여러 가지 커버리지 측정 기준이 있다. CTFL에서는 다음 세 가지를 다룬다.

모든 상태 커버리지(All state coverage): 커버리지 항목은 상태이며 100% 달성을 위해 모든 상태가 실행되도록 테스트 케이스를 구성해야 한다.
유효 전이 커버리지(Valid transitions coverage, 0-스위치 커버리지): 각 유효 전이가 커버리지 항목이 된다. 100% 달성을 위해 테스트 케이스가 모든 유효 전이를 실행해야 한다.
모든 전이 커버리지(All transitions coverage): 커버리지 항목은 상태 테이블에 표시된 모든 전이들이다. 100% 달성을 위해 모든 유효 전이를 실행하고 비유효 전이의 실행도 시도해야 한다.

※ 하나의 테스트 케이스에서 오직 하나의 비유효 전이만을 테스트하는 것은 결함 마스킹을 방지하는 데 도움이 된다. 즉 하나의 결함이 다른 결함 탐지를 방해하는 상황을 방지할 수 있다.

커버리지 간 포함 관계는 다음과 같다.

모든 전이 커버리지 만족 → 유효 전이 커버리지 만족
유효 전이 커버리지 만족 → 모든 상태 커버리지 만족
역은 성립하지 않음

4.3 화이트박스 테스트 기법

안전이나 미션에 치명적이거나 무결성이 높아야 하는 환경에서는 보다 철저한 코드 커버리지를 달성하기 위해 더 엄격한 화이트박스 기법이 사용된다.

간단하면서 널리 사용되는 기법으로는 다음과 같다.

구문 테스팅
분기 테스팅

4.3.1 구문 테스팅과 구문 커버리지

구문 테스팅에서 커버리지 항목은 실행 가능한 구문이 된다.

100% 구문 커버리지를 달성하면 코드의 모든 실행 가능한 구문을 적어도 한 번은 실행했다는 것이 보장된다. 그러나 100% 구문 커버리지가 모든 결정 논리를 테스트했다고 보장하는 것은 아니다. 예를 들어 코드의 모든 분기가 실행되지 않았을 수 있다.

4.3.2 분기 테스팅과 분기 커버리지

분기는 제어 흐름 그래프에서 두 노드 간 제어의 이동으로, 테스트 대상에서 소스 코드 구문의 실행 가능 순서를 보여준다.

분기 커버리지는 구문 커버리지를 포함한다. 즉 100% 분기 커버리지를 달성하는 테스트 케이스 집합은 100% 구문 커버리지도 달성하지만, 그 반대의 경우는 성립하지 않는다.

4.3.3 화이트박스 테스팅의 가치

모든 화이트박스 테스트 기법의 근본적인 강점은 전체 소프트웨어 구현을 고려하므로 소프트웨어 명세가 모호하거나 뒤떨어지고 불완전한 경우에도 결함을 쉽게 감지할 수 있다는 점이다.

블랙박스 테스팅만 수행해서는 실제 코드 커버리지 측정치를 얻을 수 없다. 화이트박스 커버리지 측정치는 객관적인 커버리지 측정값을 제공하고, 이 커버리지를 높이기 위한 추가 테스트 생성 정보도 함께 제공함으로써 코드 신뢰도를 높일 수 있다.

4.4 경험 기반 테스트 기법

CTFL에서 다루는 경험 기반 테스트 기법은 다음과 같다.

오류 추정
탐색적 테스팅
체크리스트 기반 테스팅

4.4.1 오류 추정

오류 추정이란 테스터의 지식을 기반으로 오류, 결함, 장애 발생을 예측하는 데 사용하는 테스트 기법이다.

결함 공격(fault attack) 은 오류 추정을 구현하는 방법 중 하나이다.

4.4.2 탐색적 테스팅

탐색적 테스팅에서는 테스터가 테스트 대상에 대해 배워가면서 테스트의 설계, 실행, 평가를 동시에 하게 된다.

탐색적 테스팅은 명세가 부족하거나 부적합한 경우 또는 테스트에 시간적 압박이 심할 때 유용하다.

4.4.3 체크리스트 기반 테스팅

체크리스트 기반 테스팅에서 테스터는 체크리스트를 활용해 테스트 컨디션을 확인하는 테스트를 설계, 구현, 실행한다. 체크리스트는 경험, 사용자에게 중요한 것에 대한 지식, 또는 SW가 실패하는 이유와 방법에 대한 이해를 바탕으로 작성할 수 있다.

다음 항목은 체크리스트에 포함해서는 안 된다.

자동으로 점검할 수 있는 항목
시작 조건, 종료 조건으로 더 적합한 항목
너무 일반적인 항목

4.5 협업 기반 테스트 접근법

위에서 언급한 각 테스트 기법은 결함 식별과 관련해 특정 목표를 가진다. 반면 협업 기반 접근법은 협업과 커뮤니케이션을 통한 결함 예방에도 초점을 둔다.

4.5.1 협업 기반 사용자 스토리 작성

사용자 스토리는 시스템이나 소프트웨어의 사용자 또는 구매자에게 가치를 제공하는 기능을 나타낸다.

사용자 스토리는 다음 세 가지 중요 요소(3C)를 가지고 있다.

카드(Card): 사용자 스토리를 설명하는 매체
대화(Conversation): 소프트웨어 사용 방법에 대한 설명
확인(Confirmation): 인수 조건

사용자 스토리의 가장 일반적인 형식은 다음과 같으며, 이후 인수 조건이 뒤따른다.

[역할]로서 [목표]를 달성해 [역할이 얻게 될 비즈니스 가치]를 얻기를 원한다.

좋은 사용자 스토리는 INVEST 기준을 만족한다.

Independent (독립적)
Negotiable (협상 가능)
Valuable (가치 있음)
Estimable (추정 가능)
Small (작음)
Testable (테스트 가능)

4.5.2 인수 조건

인수 조건은 보통 3C 중 대화(Conversation) 를 통해 결정된다.

인수 조건은 다음을 위해 사용된다.

사용자 스토리 범위 정의
이해관계자 간 합의 도출
긍정과 부정 시나리오 설명
사용자 스토리 인수 테스팅의 베이시스 제공
정확한 계획 및 추정

다양한 사용자 스토리의 인수 조건 작성법이 있으며 가장 일반적인 두 가지는 다음과 같다.

시나리오 기반: 행위 주도 개발(BDD)에서 사용하는 Given/When/Then 형식
규칙 기반

4.5.3 인수 테스트 주도 개발 (ATDD)

인수 테스트 주도 개발(ATDD) 은 테스트 우선 접근법이다. 테스트 케이스는 사용자 스토리 구현 전에 만들어진다.

우선 사용자 스토리와 인수 조건을 분석하고 토론해서 작성한다. 이후에 테스트 케이스를 만드는 것이다. 테스트 케이스는 인수 조건을 기반으로 하며 소프트웨어가 어떻게 작동하는지에 대한 예제로 볼 수 있다.

일반적으로 테스트 케이스는 다음 순서로 작성한다.

긍정/유효 테스트 케이스 우선
비유효/부정 테스트 케이스
비기능 품질 특성

테스트 케이스는 이해관계자가 이해할 수 있도록 일반적으로 전제 조건, 입력값, 사후 조건을 포함하여 자연어 문장으로 구성한다. 테스트 케이스는 사용자 스토리의 모든 특성을 다뤄야 하며 스토리를 벗어나면 안 된다.

참고

ISTQB 공식 Syllabus