Brain412. 블랙박스 테스트 (Black-box Test) - 입력/출력 기반 명세 검증
⚠️ 소프트웨어의 내부 소스 코드나 구조를 전혀 알 필요 없이, 오직 사용자의 관점(요구사항 명세서)에서 "무엇을 입력했을 때, 어떤 결과가 나와야 하는가"에 집중하여 결함을 찾아내는 **블랙박스 테스트(Black-box Test)**의 원리와 주요 기법을 다룹니다.
핵심 인사이트 (3줄 요약)
- 본질: 블랙박스 테스트 (Black-box Test)는 시스템 내부 로직을 보이지 않는 검은 상자로 간주하고, 오직 외부 인터페이스를 통한 '입력(Input)'과 그에 따른 '출력(Output)'이 명세서(Specification)와 일치하는지만을 검증하는 기능 테스트다.
- 가치: 소스 코드에 종속되지 않으므로, 개발자가 실수로 빼먹은 '누락된 로직(Missing Logic)'이나 명세서 해석의 오류를 찾아내는 데 탁월하다. 이는 내부 코드가 100% 실행되더라도 요구사항 자체가 구현되지 않았다면 잡아낼 수 없는 화이트박스 테스트(White-box Test)의 맹점을 완벽히 보완한다.
- 기술 체계: 동등 분할 (Equivalence Partitioning), 경계값 분석 (Boundary Value Analysis), 원인-결과 그래프 (Cause-Effect Graphing) 등의 논리적/수학적 기법을 사용하여, 무한대에 가까운 입력값 조합 중 가장 결함 확률이 높은 대푯값(Representative Value)들을 추출해 테스트 케이스의 개수를 최적화한다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
-
개념: 블랙박스 테스트 (Black-box Test)는 '명세 기반 테스트(Specification-based Testing)' 또는 '행위 기반 테스트(Behavioral Testing)'라고도 불린다. 테스터는 코드가 C++로 짜였는지 Java로 짜였는지, 내부에 if-else 문이 몇 개인지 전혀 신경 쓰지 않는다. 오직 "비밀번호를 5회 틀리면 계정이 잠겨야 한다"는 비즈니스 요구사항(명세서)이 주어졌을 때, 실제로 그렇게 동작하는지에만 집중한다.
-
필요성: 개발자는 코드를 작성하면서 자신이 만든 로직(Logic)에 매몰되는 경향이 있다. 자신이 짠 내부 논리를 기준으로 테스트(화이트박스 테스트)를 수행하면, "애초에 요구사항에서 요구했으나 코드로 구현하지 않고 빼먹은 기능"은 영원히 발견할 수 없다. 사용자는 내부 코드가 얼마나 아름다운지 관심이 없으며 오직 "내가 원하는 기능이 제대로 작동하는가"에만 돈을 지불한다. 따라서 사용자 관점을 대변하는 독립적인 블랙박스 테스트가 필수적이다.
-
적용 단계: 단위 테스트(Unit Test)보다는, 주로 시스템이 하나의 완전한 형태를 갖춘 후반부인 **시스템 테스트 (System Test)**와 인수 테스트 (Acceptance Test) 단계에서 광범위하게 적용된다.
-
📢 섹션 요약 비유: 새로 산 스마트폰이 좋은지 나쁜지 검사할 때, 드라이버로 폰을 다 뜯어서 안에 칩이 몇 개인지 구경하는 대신(화이트박스), 겉에서 화면을 막 터치해 보고 사진도 찍어보면서 "우와 잘 나오네!" 하고 겉모습과 결과만 확인하는 것과 같습니다.
Ⅱ. 블랙박스 vs 화이트박스 트레이드오프
블랙박스 테스트는 화이트박스 테스트와 대척점에 있으며, 상호 보완적인 관계(Complementary)를 갖는다.
┌────────────────────────────────────────────────────────────────────┐
│ 블랙박스 테스트 vs 화이트박스 테스트 비교 도해 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ [블랙박스 테스트] [화이트박스 테스트] │
│ (명세/기능 기반) (구조/논리 기반) │
│ │
│ 입력값 (Input) 입력값 (Input) │
│ │ │ │
│ ▼ ▼ │
│ ┌───────┐ ┌─▶[ if (x > 0) ]─┐ │
│ │ │ │ │ │
│ │ ??? │(내부 구조 모름) │ [ a = x + 1 ] │ │
│ │ │ │ ▼ │
│ └───────┘ └───────────▶[ return a] │
│ │ │ │
│ ▼ ▼ │
│ 출력값 (Output) 출력값 (Output) │
│ │
│ * 초점: "요구사항을 만족하는가?" * 초점: "모든 코드가 실행되었는가?"│
│ * 발견 가능 결함: 누락된 기능, UI 오류 * 발견 가능 결함: 무한 루프, 데드 코드│
│ * 주체: 전문 QA, 최종 사용자 * 주체: 개발자 본인 │
└────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 블랙박스는 시스템을 불투명한 상자로 취급하여 명세서의 입력과 출력(I/O) 매핑에만 집중한다. 반면 화이트박스는 투명한 상자로 취급하여 내부의 조건 분기(if-else), 루프(for, while)를 모두 한 번씩 타보는 코드 커버리지(Code Coverage)에 집중한다. 따라서 실무에서는 개발 단계에서 개발자가 화이트박스 테스트를 수행하고, 시스템 통합 후 QA(Quality Assurance) 엔지니어가 블랙박스 테스트를 수행하는 투 트랙(Two-track) 방식을 채택한다.
- 📢 섹션 요약 비유: 식당에서 음식을 평가할 때, 주방에 들어가서 요리사가 레시피대로 파를 몇 cm로 썰고 있는지 감시하는 것(화이트박스)이 아니라, 손님 테이블에 앉아 완성된 요리를 먹어보고 "짜다/싱겁다"를 평가하는 것(블랙박스)입니다.
Ⅲ. 주요 기법 1: 동등 분할과 경계값 분석
무한대에 가까운 모든 입력값을 테스트하는 것은 불가능하다. 예를 들어 "1부터 100 사이의 나이를 입력하세요"라는 폼을 테스트할 때, 1, 2, 3... 100까지 100번을 모두 테스트하는 것은 비효율적이다.
-
동등 분할 (Equivalence Partitioning):
- 입력 영역을 시스템이 '동일하게 취급할 것으로 예상되는' 여러 그룹(클래스)으로 나눈다.
- 각 클래스에서 대푯값 하나만 뽑아 테스트하면, 그 클래스의 나머지 값들도 동일한 결과를 낼 것이라고 수학적으로 가정한다.
- 예: 나이 입력 (유효 클래스: 1~100, 무효 클래스 1: 0 이하, 무효 클래스 2: 101 이상). 대푯값 50, -5, 150 세 번만 테스트한다.
-
경계값 분석 (Boundary Value Analysis):
- 프로그래머들이 주로 부등호(
<,<=,>,>=)를 사용할 때 경계(Boundary)에서 가장 많은 버그(Off-by-one Error)를 만들어낸다는 경험적 통계에 기반한다. - 동등 분할의 경계(가장자리)에 위치한 값들을 집중적으로 테스트한다.
- 예: 1~100 사이라면, 최소 경계 주변(0, 1, 2)과 최대 경계 주변(99, 100, 101)을 찌른다.
- 프로그래머들이 주로 부등호(
┌─────────────────────────────────────────────────────────────┐
│ 나이 입력(1~100) 폼의 동등 분할 및 경계값 분석 │
├─────────────────────────────────────────────────────────────┤
│ │
│ [무효 클래스 1] [유효 클래스] [무효 클래스 2] │
│ ───────────┼──────────────┼───────────────┼───────────▶ │
│ 0 │ 1 50 100 │ 101 │
│ │ │ │
│ 동등 분할: -5 (대푯값) 50 (대푯값) 150 (대푯값) │
│ │
│ 경계값 분석: 0, 1 (경계 없음) 100, 101 │
│ (최소값 근처) (최대값 근처) │
└─────────────────────────────────────────────────────────────┘
[다이어그램 해설] 이 기법을 적용하면 100번 넘게 해야 할 테스트를 단 5~6번의 핵심 테스트 케이스(0, 1, 50, 100, 101)로 압축할 수 있다. 이 6개의 값이 전체 입력 도메인의 결함 발생 확률을 90% 이상 커버(Coverage)한다는 것이 소프트웨어 테스팅의 핵심 원리다.
- 📢 섹션 요약 비유: 사과 상자에서 사과가 썩었는지 확인할 때, 100개를 다 베어 무는 대신(전수 테스트), 상자 윗부분, 아랫부분, 가운데에서 하나씩만 뽑아서(동등 분할) 맛을 보는 영리한 검사법입니다.
Ⅳ. 주요 기법 2: 의사 결정 테이블 (Decision Table)
입력 조건이 단일한 숫자가 아니라, 여러 조건의 논리적 조합(AND, OR, NOT)일 경우 동등 분할만으로는 해결할 수 없다.
- 개념: 시스템이 수행해야 할 다양한 논리적 조건(Cause)과 그에 따른 행동(Effect)을 진리표(Truth Table) 형태의 표로 구성하여 누락된 비즈니스 규칙이 없는지 촘촘하게 검증하는 기법이다.
- 적용 시나리오: 금융권의 대출 승인 로직, 항공권 할인 조건 등 비즈니스 룰이 복잡하게 얽혀 있는 경우.
| 테스트 케이스 ID | TC-01 | TC-02 | TC-03 | TC-04 |
|---|---|---|---|---|
| 조건 (Conditions) | ||||
| 1. VIP 회원인가? | Y | Y | N | N |
| 2. 구매액이 10만원 이상인가? | Y | N | Y | N |
| 행동 (Actions) | ||||
| 무료 배송 제공 | X | X | X | |
| 20% 할인 쿠폰 제공 | X | |||
| 혜택 없음 | X |
-
장점: 개발자가 코드를 짜면서 미처 생각하지 못한 '예외적인 논리 조합(예: VIP가 아니면서 10만 원을 넘긴 경우)'을 표를 그리는 과정에서 시각적으로 발견하고 강제할 수 있다.
-
📢 섹션 요약 비유: 복잡한 사다리 타기 게임을 할 때, 헷갈리지 않도록 펜으로 모든 경우의 수(출발점)를 그어서 도착점을 미리 표로 정리해 두고 하나씩 확인해 보는 것과 같습니다.
Ⅴ. 기타 확장 기법 및 한계점
블랙박스 테스트는 단순히 값을 넣고 빼는 것을 넘어, 시스템의 '상태'나 '행위 흐름'을 모델링하여 테스트하기도 한다.
- 상태 전이 테스트 (State Transition Testing):
- 시스템이 특정 이벤트에 따라 상태(State)가 어떻게 변하는지 검증한다. (예: ATM 기기에서 '카드 삽입' -> '비밀번호 입력' -> '잠김' 또는 '인증됨' 상태로의 전이)
- 오류 예측 (Error Guessing):
- 테스터의 과거 경험, 직관, 기술적 감각에 의존하여 "이런 상황에서는 아마 버그가 있을 것이다"라고 추측하여 찔러보는 휴리스틱(Heuristic) 기법이다. (예: 특수문자를 넣거나 네트워크를 갑자기 끊어보기)
한계점:
-
미실행 코드 (Unreachable Code) 방치: 시스템 내부에서 절대로 실행되지 않는 잉여 코드(Dead Code)나 백도어(Backdoor) 악성코드가 심어져 있더라도, 정상적인 명세서의 입출력만 테스트하므로 이를 결코 찾아낼 수 없다.
-
따라서 무결성이 극도로 중요한 항공, 의료, 금융 시스템에서는 반드시 블랙박스 테스트와 화이트박스 테스트를 1:1 비율로 교차 검증(Cross Validation)해야 한다.
-
📢 섹션 요약 비유: 집을 보러 온 사람이 수압이 좋은지, 전등이 잘 켜지는지는 확인할 수 있지만(블랙박스 테스트), 벽 안쪽에 부실한 전선이 꼬여서 합선 위험이 있는지는 벽을 뜯어보기 전(화이트박스 테스트)까지는 절대 모르는 한계와 같습니다.
👶 어린이를 위한 3줄 비유 설명
- 자판기에 동전을 넣고 콜라 버튼을 누르면 콜라가 툭 튀어나와야 정상이죠?
- 자판기 안에 무슨 복잡한 기계가 있는지, 톱니바퀴가 어떻게 도는지는 전혀 알 필요가 없어요.
- 그저 **명세서(자판기 설명서)**에 적힌 대로 "1,000원을 넣고 버튼을 누르면 콜라가 나오는지" 겉에서 돈을 넣어보고 확인하는 방법이 바로 블랙박스 테스트랍니다!