구조 기반 기법 (White-box Testing)
소프트웨어나 시스템의 내부 구조를 중심으로 테스팅을 설계하고 수행하는 기법입니다. 테스트 대상의 내부 논리 구조를 가시화(도식화)하고, 그중 얼마나 많은 경로를 확인했는지(커버리지) 측정하는 것을 목적으로 합니다.
1. 테스팅 레벨에 따른 분석 단위의 변화
구조 기반 테스팅은 레벨이 올라갈수록 '현미경으로 보던 것을 망원경으로 보는 것'처럼 관점이 확장됩니다.
- 컴포넌트(단위) 레벨: 분석 단위는 '코드 줄(Statement)'이나 '개별 조건문'입니다.
if문 안의 변수 하나하나가 어떻게 참/거짓이 되는지 미세한 분기를 따집니다. - 통합 레벨: 분석 단위는 '함수 간의 인터페이스'나 '모듈 간의 호출'입니다. A 함수가 B 함수를 정확한 시점에 호출하는지 그 연결 고리를 구조화합니다.
- 시스템 레벨: 분석 단위는 '전체 비즈니스 프로세스'나 '거대한 호출 흐름'입니다. 사용자 시나리오(예: 로그인 -> 상품 검색 -> 결제)가 시스템 전체 코드망에서 어떤 경로를 타고 흐르는지를 따집니다.
2. 테스팅 목적 비교
- 명세 기반 테스팅 (Black-box): "우리가 만들기로 한 게 빠짐없이 다 들어갔나?"를 확인 (Focus: 요구사항 충족)
- 구조 기반 테스팅 (White-box): "코드가 돌아가는 길목 중에 우리가 안 가본 곳이 있나?"를 찾아냄 (Focus: 논리적 빈틈 발견)
💡 핵심 포인트: 구조 기반 기법은 특정 커버리지 달성을 목표로 테스트 케이스를 도출하므로, '테스트 설계 기법'과 '커버리지 지표'의 관계가 매우 명확합니다.
핵심 용어 및 커버리지 종류
1. 용어 정의
- 전체 조건식 (Decision / 결정):
if나while문 등에 사용되는 조건문 전체를 의미하며, 계산되어 나오는 최종 결과값(True 또는 False)을 가집니다. - 개별 조건식 (Condition / 조건):
AND(&&)나OR(||)등의 논리 연산자로 구분되어 있는 개개의 조건식(A, B, C 등)을 의미합니다.
2. 커버리지 종류 및 강도
- 구문 커버리지 (Statement Coverage): 코드 내의 모든 실행 가능한 구문(문장)을 최소 한 번 이상 실행 (가장 약한 수준)
- 결정 커버리지 (Decision Coverage): 결정 포인트 내의 전체 조건식 결과가 최소 한 번은 True, 한 번은 False가 되도록 테스트
- 조건 커버리지 (Condition Coverage): 전체 조건식의 결과와 상관없이, 개별 조건식이 각각 최소 한 번은 True, 한 번은 False가 되도록 테스트
- 조건/결정 커버리지 (Condition/Decision Coverage): 전체 조건식의 결과도 True/False를 한 번씩 갖게 하면서, 개별 조건식도 각각 True/False를 최소 한 번씩 만족하도록 테스트
- 변경 조건/결정 커버리지 (MC/DC): 각 개별 조건이 다른 개별 조건식의 결과에 영향을 받지 않고, 독립적으로 전체 결정 결과에 영향을 주도록 테스트 케이스를 설계 (안전 필수 시스템에서 주로 요구됨)
- 다중 조건 커버리지 (Multiple Condition Coverage): 개별 조건식들의 발생 가능한 모든 논리적 조합을 100% 검증 (가장 강력하나 케이스 수가 폭발함)
3. 커버리지 간의 포함 (우세) 관계
강도와 포괄 범위에 따른 서열은 다음과 같습니다.
다중 조건 커버리지 > MC/DC > 조건/결정 커버리지 > 결정 커버리지 ≈ 조건 커버리지 > 구문 커버리지
⚠️ 주의 (결정과 조건의 관계)
조건 커버리지가 결정 커버리지를 포함하는 개념으로 생각되기 쉬우나 그렇지 않습니다. 개별 조건식이 모두 True/False를 가졌다고 해서, 전체 조건식(결정)이 모두 True/False를 가지는 것은 아닙니다. 반대의 경우도 마찬가지이므로 두 커버리지는 서로를 보장하지 못합니다. (그럼에도 세부 로직을 확인한다는 측면에서 조건 커버리지가 조금 더 면밀할 수 있습니다.)
주요 기법별 특징 및 설계 의도
1. 구문 테스팅 (Statement Testing)
- 테스트 스위트에 의해 실행된 구문의 백분율(%)을 측정합니다.
- 단순 분기문 내의 누락된 경로 등을 검증하지 못하므로 상대적으로 낮은 커버리지 보장성을 가집니다.
2. 결정 테스팅 (Decision Testing)
- 의도: "프로그램의 모든 화살표(분기 경로)를 다 타보자!" (거시적 흐름 검증)
- 프로그램 내의 제어 흐름(분기)을 중점적으로 보며, 결정 포인트(
if,switch등) 전체가 만드는 결과값(T/F)에 집중합니다. - 공식적인 화이트박스 테스트 설계 기법으로, 단위 테스트나 통합 테스트 단계에서 널리 활용됩니다.
- 순서도보다는 제어 흐름 그래프(CFG) 형태로 시각화하여 테스트 누락 경로를 직관적으로 추적할 수 있습니다.
- 결정 포인트를 기준으로 들어오는 흐름과 나가는 흐름의 조합(트리 형태)을 모두 고려하므로 구조적 결함을 찾기에 적합합니다.
3. 조건 테스팅 (Condition Testing)
- 의도: "모든 잠금장치(개별 조건 변수)를 다 건드려보자!" (미시적 세부 로직 검증)
if문 괄호 안에 있는 개별 조건식들이 각각 어떻게 동작하는지를 파악하고 누락된 논리를 찾습니다.
변형 조건/결정 커버리지 (MC/DC) 상세 분석
1. MC/DC 달성 조건 및 규칙
- 최소 테스트 케이스 수: N + 1 개 (N은 개별 조건식의 개수)
- 만족 기준:
- 전체 조건식(결정)의 결과가 적어도 한 번은 True, 한 번은 False여야 합니다.
- 각 개별 조건식의 결과도 적어도 한 번은 True, 한 번은 False여야 합니다.
- 핵심: 다른 개별 조건식들은 고정시킨 채, 특정 조건 하나만 바꿨을 때 전체 결과(결정)가 반전되는 독립적 영향력 쌍(Pair)이 모든 조건마다 존재해야 합니다.
2. 실례 분석: Z = (A \ && \ B) \ || \ C
조건식이 3개(A, B, C)이므로 MC/DC를 만족하기 위한 최소 테스트 케이스 수는 3 + 1 = 4개입니다.
📌 올바른 독립성 증명 쌍 매칭 (조합 1 분석 리팩토링)
작성하신 조합 1의 4가지 케이스를 바탕으로, 각 변수의 독립적 영향력을 올바르게 매핑한 진리표와 쌍(Pair) 분석입니다.
| 케이스 ID | A | B | C | 전체 결정 (Z) | 설명 및 독립성 증명 역할 |
|---|---|---|---|---|---|
| TC-1 | F | T | T | T | C의 독립성 확인을 위한 케이스 (TC-2와 쌍) |
| TC-2 | F | T | F | F | A와 C의 독립성을 증명하는 핵심 기준점 |
| TC-3 | T | F | F | F | B의 독립성 확인을 위한 케이스 (TC-4와 쌍) |
| TC-4 | T | T | F | T | A와 B의 독립성을 증명하는 핵심 기준점 |
🔍 조건별 독립적 영향력 입증 과정
- 조건 C의 영향력 확인 (TC-1 vs TC-2)
- A와 B는
(F, T)로 고정되어 있습니다. - 이 상태에서 C가
T에서F로 바뀔 때, 전체 결과 Z도T에서F로 반전됩니다. - 👉 C의 독립적 영향력 입증 완료!
- A와 B는
- 조건 A의 영향력 확인 (TC-2 vs TC-4)
- B와 C는
(T, F)로 고정되어 있습니다. - 이 상태에서 A가
F에서T로 바뀔 때, 전체 결과 Z도F에서T로 반전됩니다. - 👉 A의 독립적 영향력 입증 완료!
- B와 C는
- 조건 B의 영향력 확인 (TC-3 vs TC-4)
- A와 C는
(T, F)로 고정되어 있습니다. - 이 상태에서 B가
F에서T로 바뀔 때, 전체 결과 Z도F에서T로 반전됩니다. - 👉 B의 독립적 영향력 입증 완료!
- A와 C는
💡 결론:
[FTT, FTF, TFF, TTF]이 4가지 테스트 케이스 조합은 A, B, C 세 조건 모두의 독립적 영향력을 교차 증명할 수 있으므로, 최소 개수(N+1=4)로 MC/DC 커버리지 100%를 완벽하게 달성합니다.
'SW QA' 카테고리의 다른 글
| 순서도(Flowchart)와 활동다이어그램(Activity Diagram) 가이드 (0) | 2026.03.25 |
|---|---|
| 유즈케이스 다이어그램 (Use Case Diagram) (0) | 2026.03.24 |
| 3-3. 유즈케이스 테스팅 (0) | 2026.03.24 |
| 3-2. 상태 전이 테스팅 (0) | 2026.03.14 |
| 3-1. 테스트 설계 기법과 명세 기반 기법 (0) | 2026.03.10 |