본문 바로가기
SW QA

3. 테스트 설계 기법

by spare8433 2026. 3. 10.

1. 테스트 설계 및 구현 프로세스

테스트 설계 과정은 테스트 조건(Test Condition)을 식별하고 이를 기반으로 테스트 케이스를 설계하는 과정이다.

테스트 조건이란 기능, 트랜잭션, 품질 특성, 시스템 구성 요소 등 테스트를 통해 확인해야 할 항목이나 이벤트를 의미한다.

테스트 조건과 요구사항 및 명세(Test Basis) 사이의 추적성(Traceability) 을 유지하면 다음이 가능하다.

  • 요구사항 변경 시 영향도 분석
  • 요구사항 대비 테스트 커버리지 확인
  • 누락된 테스트 식별



1.1 테스트 케이스

테스트 케이스의 목적은 목표한 보장성(Coverage)을 만족하면서 최소한의 테스트로 결함을 발견하는 것이다.

테스트 케이스 작성 시 테스트 환경과 수행자가 다를 수 있기 때문에 수행 절차(Test Step)의 상세 수준을 적절하게 결정해야 한다.

일반적으로 테스트 단계는 7단계 이내로 작성하는 것이 바람직하다.

테스트 설계 시에는 다양한 테스트 설계 기법을 함께 활용하는 것이 일반적이다.
각 기법은 발견하기 쉬운 결함의 유형이 다르기 때문에 여러 기법을 조합하여 사용하는 것이 효과적이다.

예시

  • 명세 기반 테스트 : 요구사항이나 명세와 실제 동작이 다른 경우의 결함 발견
  • 경험 기반 테스트 : 명세에 정의되지 않았지만 실제 사용 과정에서 발생할 수 있는 문제 발견

테스트 케이스 구성 요소

소프트웨어 테스트 문서 표준 IEEE 829 에서는 테스트 케이스 문서의 기본 구조를 정의하고 있다.

구성 요소 설명
ID 테스트 케이스를 식별하기 위한 고유 식별자
테스트 케이스명 테스트 목적이나 검증 기능을 간단히 설명하는 이름
사전 조건 테스트 수행 전에 충족되어야 하는 시스템 상태
테스트 수행 절차 (Test Step) 테스트를 실행하기 위한 단계별 수행 방법
기대 결과 정상 동작 시 나타나야 하는 결과 (데이터, 상태 변화 등)
결과 실제 테스트 수행 후의 결과 기록
추적성 관련 요구사항 또는 명세와의 연결 정보
중요도 테스트의 우선순위 또는 비즈니스 중요도
비고 추가 설명이나 특이사항 기록



1.2 테스트 프로시저

테스트 케이스를 설계한 이후에는 실행 순서를 고려하여 테스트 프로시저(Test Procedure) 를 작성한다.

테스트 프로시저란 효율적인 테스트 수행을 위해 테스트 케이스의 실행 순서를 정의한 명세서이다.

테스트 프로시저 = 1개 이상의 테스트 케이스를 실행 순서대로 정리한 것


테스트 프로시저

1. 로그인 테스트
2. 사용자 정보 조회
3. 사용자 정보 수정
4. 로그아웃



2. 테스트 설계 기법의 종류

테스트 케이스 설계 시 여러 설계 기법을 동시에 사용하는 경우가 많다.


2.1 블랙박스와 화이트박스 구분

블랙박스 테스트

  • 명세 기반 / 경험 기반 테스트에 해당
  • 내부 코드 구조를 고려하지 않고 테스트 수행
  • 요구사항, 명세, 사용자 관점에서 테스트 케이스 도출
  • 기능 중심 테스트 및 시스템 동작 검증에 적합

화이트박스 테스트

  • 구조 기반 테스트에 해당
  • 소프트웨어 코드 구조를 기반으로 테스트 케이스 도출
  • 코드 흐름 및 내부 로직 검증 가능
  • 코드 커버리지 측정 가능

2.2 설계의 근원 기준

명세 기반

  • 요구사항, 설계 명세 기반 테스트
  • 명세 기준 커버리지 측정 가능
  • 구조 기반보다 커버리지 범위는 제한적

구조 기반

  • 코드 구조 기반 테스트
  • 프로그램 내부 로직을 기반으로 테스트 케이스 생성
  • 코드 커버리지 측정 가능

경험 기반

  • 테스터, 개발자, 사용자 경험 기반 테스트
  • 직관 및 경험을 활용한 테스트



3. 명세 기반 기법

명세 기반 테스트는 요구사항이나 명세를 기반으로 테스트 케이스를 도출하는 방법이다.

소프트웨어 구현 이전에도 테스트 케이스 설계가 가능하므로 개발 초기 단계부터 테스트 활동을 수행할 수 있다.

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

3.1 동등 분할 (Equivalence Partitioning)

입력값의 범위 중 동일한 결과를 생성하는 영역을 하나의 등가 집합(Equivalence Class) 으로 분할하여 대표값을 선택해 테스트하는 기법이다.

입력 데이터를 여러 그룹으로 나누고 각 그룹에서 하나의 대표값만 테스트한다.


특징

  • 테스트 수 감소
  • 유효 / 무효 데이터 모두 테스트 가능

모든 테스트 레벨과 테스트 유형에서 사용 가능하다.


적용 대상

동등 분할은 입력값뿐 아니라 다음 항목에도 적용 가능하다.

  • 출력값
  • 내부 상태 값
  • 시간 관련 값
  • 모듈 간 인터페이스 파라미터
  • 조건값 등



1️⃣ 입력값이 하나인 경우 동등 분할 예시

온라인 서비스에서 나이(age) 를 입력받는다고 가정한다.

조건

  • 나이는 0 이상 120 이하만 유효하다.

동등 클래스 분할

입력 범위를 다음과 같이 나눌 수 있다.

동등 클래스 설명 예시 값
E1 age < 0 -5
E2 0 ≤ age ≤ 120 30
E3 age > 120 150

테스트 케이스 선택

각 동등 클래스에서 대표값 하나씩 선택한다.

테스트 케이스 입력값
TC1 -5
TC2 30
TC3 150

이처럼 각 동등 클래스에서 대표값을 하나 선택하여 테스트하는 방식이 동등 분할 테스트이다.




2️⃣ 입력값이 2개 이상인 경우 예시

※ 입력값이 여러 개일 때는 동등 클래스 간 조합 방식에 따라 약한 동등 분할과 강한 동등 분할로 나뉜다.

온라인 쇼핑몰에서 나이(age)회원등급(membership) 을 입력받는다고 가정한다.


나이 (Age)

동등 클래스 설명 대표값
A1 age < 0 -5
A2 0 ≤ age ≤ 19 15
A3 20 ≤ age ≤ 64 30
A4 age ≥ 65 70

회원 등급 (Membership)

동등 클래스 설명 대표값
M1 일반 회원 normal
M2 VIP 회원 vip



약한 동등 분할 (Weak Equivalence)

약한 동등 분할은 각 동등 클래스의 대표값을 한 번씩만 사용하는 방식이다.
즉, 모든 조합을 만들지 않고 각 등가 집합을 최소 한 번씩만 검증한다.

위 예시 기준 테스트 케이스

테스트 케이스 Age Membership
TC1 -5 normal
TC2 15 vip
TC3 30 normal
TC4 70 vip

강한 동등 분할 (Strong Equivalence)

강한 동등 분할은 여러 입력 조건이 존재할 경우 등가 집합 간 가능한 조합을 고려하여 테스트하는 방식이다.

각 조건의 등가 집합을 조합하여 테스트 케이스를 생성한다. 따라서 더 높은 커버리지를 확보할 수 있지만 테스트 수가 증가하는 특징이 있다.

TC Age Membership
TC1 -5 normal
TC2 -5 vip
TC3 15 normal
TC4 15 vip
TC5 30 normal
TC6 30 vip
TC7 70 normal
TC8 70 vip

따라서 실제 테스트에서는 시스템 복잡도와 테스트 범위를 고려하여 약한 동등 분할과 강한 동등 분할을 적절히 선택하여 적용한다.




3.2 경계값 분석 (Boundary Value Analysis)

동등 분할에서 경계 영역에서 결함이 발생할 확률이 높다는 점을 이용한 테스트 기법으로 가장 많이 사용되는 테스트 설계 기법 중 하나**이다.


한계점

  • 복잡한 일련의 상태 변화 테스트에는 부적합
  • 입력값 조합이 많으면 테스트 수 증가
  • 입력 변수 간 의존성이 있는 경우 적용 어려움
  • 출력 결과가 여러 조건에 의해 복잡하게 결정되는 경우 분할이 어려움

입력 범위

1 ~ 100

테스트 값

0
1
2
99
100
101

3.3 결정 테이블 테스팅 (Decision Table Testing)

결정 테이블은 여러 입력 조건과 그에 따른 시스템 동작을 테이블 형태로 표현하는 테스트 기법이다.

복잡한 비즈니스 규칙이나 조건 조합을 테스트할 때 매우 유용하다.

  • 조건과 결과 관계 명확
  • 비즈니스 로직 검증에 적합

테이블의 각 컬럼은 하나의 규칙(rule) 을 의미하며 이는 하나 이상의 테스트 케이스로 변환될 수 있다.


결정 테이블 예시

로그인 정책

조건 Rule1 Rule2 Rule3 Rule4
ID 입력 Y Y N N
비밀번호 입력 Y N Y N
로그인 시도 성공 실패 실패 실패

테스트 케이스 예

TC1 : ID=입력 / PW=입력 → 로그인 성공
TC2 : ID=입력 / PW=미입력 → 로그인 실패
TC3 : ID=미입력 / PW=입력 → 로그인 실패
TC4 : ID=미입력 / PW=미입력 → 로그인 실패

원인-결과 그래프 (Cause-Effect Graph)

결정 테이블을 논리적으로 표현한 그래프 형태의 테스트 설계 기법이다.

조건(Cause)과 결과(Effect) 사이의 논리 관계를 그래프로 표현한다.


예)

Cause-Effect Graphing-Black Box Software Testing Technique - Software  Testing Genius

'SW QA' 카테고리의 다른 글

2. 소프트웨어 수명주기와 테스팅  (0) 2026.03.08
1. 소프트웨어 테스팅 기초  (0) 2026.03.07
SW QA 이해  (1) 2026.02.27