블랙박스 테스트로 요구사항 기반 품질을 검증하는 방법

구현보다 계약을 기준으로 검증한다

블랙박스 테스트는 내부 코드 구조를 보지 않고 요구사항·명세·사용자 시나리오에 따라 입력과 출력의 기대치를 확인하는 테스트 설계 기법이다. 퍼블릭 API 단위부터 컴포넌트와 서비스 통합, 시스템·엔드투엔드(E2E), 인수 테스트까지 적용 범위가 넓다.

핵심은 입력 도메인을 모델링하고, 기대 결과를 판정할 오라클을 명시하며, 체계적으로 입력을 고르는 데 있다. 화이트박스 테스트가 코드 경로와 분기 커버리지를 중심에 둔다면, 블랙박스 테스트는 요구사항 커버리지와 사용 사례를 우선한다. 그레이박스 테스트는 인터페이스나 데이터 스키마처럼 제한된 내부 지식을 활용하는 중간 접근이다.

입력과 판정 기준을 먼저 설계한다

입력값은 유효·무효 클래스으로 나누고 각 클래스를 대표하는 사례를 선택한다. 경계값을 함께 다루면 입력 범위의 끝에서 발생하는 결함을 찾기 쉽고, 조합 폭발은 체계적인 축약으로 제어할 수 있다. API 스펙, 스키마, 프로토콜 같은 외부 계약은 허용 범위와 제약 조건을 정하는 근거가 된다.

오라클은 단순한 반환값 비교에 그치지 않는다. 기대 결과, 상태 변화, 부작용으로 남는 로그와 메트릭까지 포함해 판정 기준을 합의해야 한다. 결과를 결정하기 어려운 경우에는 휴리스틱·메트릭 기반 오라클이나 통계적 오라클(ML/확률 모델)을 적용할 수 있다.

입력과 흐름의 성격에 따라 설계 기법도 달라진다.

• 동등 분할과 경계값 분석은 입력 범주의 대표값 및 경계 인접값을 선택한다.
• 의사결정표와 원인-결과 그래프는 규칙 조합과 결과 매핑에서 누락·상충을 찾는 데 적합하다.
• 상태전이와 유스케이스 테스트는 상태 또는 시퀀스에 의존하는 로직, 실제 사용자 흐름을 검증한다.

API부터 정산 흐름까지 적용 범위

웹·모바일 API에서는 OpenAPI 또는 JSON Schema를 기반으로 계약 테스트를 구성하고 상태 코드·바디·헤더를 검증할 수 있다. 인증·인가, 레이트리밋, 페이징·정렬·필터는 경계값과 조합 테스트가 필요한 대표 영역이다.

데이터·ETL 파이프라인은 스키마 진화 호환성, 누락·중복 레코드, 집계 정확도에 대한 오라클을 세우는 방식으로 다룬다. 대용량 데이터는 샘플링과 해시 합 비교를 적용하고, 시계열 데이터에서는 윈도우 롤오버 경계 시나리오를 검증한다.

규칙이 복잡한 금융·ERP 로직에서는 의사결정표로 규칙 조합의 완전성을 점검할 수 있다. 예외 요율과 한도 경계, 회계 분개·정산의 상태전이, 보정 시나리오를 회귀 세트에 포함하는 방식이다.

실행 결과가 회귀 세트로 돌아오는 흐름

⤢✕

실행 환경과 데이터가 흔들리면 테스트 결과도 신뢰하기 어렵다. 고정 시드 기반 데이터 생성, ID 네임스페이스·테넌트를 이용한 격리, Infrastructure as Code 기반의 환경 셀프서비스화가 필요한 이유다. 외부 의존성은 계약 기반 목 또는 가짜 서버로 대체하고, 계약 테스트로 안정성을 확보한다.

CI/CD에 통합한 병렬 실행, 플레이키(flaky) 검출·차단도 운영의 일부다. 로그·트레이스·메트릭을 오라클 입력으로 수집하면 실패 원인을 좁히는 시간이 줄어든다.

접근법에 따라 달라지는 유지보수 특성

접근법	성능(실행 효율)	확장성(케이스/시스템)	일관성(결과 재현성)	안정성(변경 내성)	운영 편의(도구·유지보수)
블랙박스	높음: 병렬·원격 실행 용이	높음: 계약 기반 케이스 확대 용이	높음: 구현 변경 영향 최소	높음: 내부 리팩터링에도 견고	높음: 표준 프로토콜/스펙 기반 도구 풍부
화이트박스	중간: 계측·모킹 오버헤드	중간: 코드 변경 시 케이스 갱신 부담	중간: 환경·시드 의존	낮음: 구현 변경에 민감	중간: 런타임/커버리지 도구 필요
그레이박스	중간	중간	중간	중간	중간

블랙박스 테스트는 계약을 중심으로 케이스를 확장할 수 있고, 내부 리팩터링의 영향을 비교적 적게 받는다. 반면 화이트박스 테스트는 구현 변경 시 케이스 갱신 부담이 생기며, 그레이박스는 양쪽 특성을 절충한다.

테스트 설계를 운영 가능한 형태로 만든다

요구사항에서 기능·비기능 항목을 추출하고 테스트 항목과의 트레이서빌리티를 연결한다. 위험 기반 가중치로 우선순위를 정한 뒤 핵심 경로부터 자동화한다.

입력 샘플링에서는 동등 분할로 대표값을 고르고 경계값(−1/0/+1, 최소/최대)을 포함한다. 조합이 과도해지는 상황은 페어와이즈 또는 리스크 기반 부분 조합으로 완화한다.

판정 기준에는 상태 코드, 메시지, 부작용, 지연 상한을 명문화한다. 로그 키와 트레이스 ID, 도메인 메트릭도 함께 수집해야 실행 결과를 추적할 수 있다. 플레이키 격리는 재시도 2회, 지수 백오프, 환경 태깅으로 운영하고, 테스트 데이터는 프로비저닝→사용→정리 자동화의 생애주기로 관리한다.

REST API를 외부 계약으로 검증하는 예시

전제조건: Python 3.11, pytest 8.x, requests 2.x, 네트워크 접근 가능, API 기본 URL 환경변수 BASE_URL 설정.

# tests/test_price_api.py
import os
import pytest
import requests

BASE = os.environ.get("BASE_URL", "http://localhost:8080")

@pytest.mark.parametrize("qty,unit_price,expected_total", [
    # 동등 분할: 정상
    (1, 1000, 1000),
    (5, 199, 995),
    # 경계값: 최소/최대, 할인 경계(예: 10개 이상 5% 할인)
    (0, 1000, 0),            # qty=0 허용 정책
    (9, 100, 900),
    (10, 100, 950),          # 할인 적용
])
def test_calculate_total_ok(qty, unit_price, expected_total):
    r = requests.post(f"{BASE}/v1/calc/total", json={"qty": qty, "unit_price": unit_price})
    assert r.status_code == 200
    body = r.json()
    assert body["total"] == expected_total

@pytest.mark.parametrize("payload", [
    # 무효 입력 클래스
    {"qty": -1, "unit_price": 100},
    {"qty": 1, "unit_price": -100},
    {"qty": "NaN", "unit_price": 100},
])
def test_calculate_total_invalid(payload):
    r = requests.post(f"{BASE}/v1/calc/total", json=payload)
    assert r.status_code in (400, 422)
    assert "error" in r.json()

이 예시는 정상 입력과 무효 입력 클래스를 분리하고, 최소·최대 및 할인 경계를 검증한다. 운영에서는 OpenAPI 스키마 검증을 계약 테스트에 추가하고, 테스트 데이터 생성 시 랜덤 시드를 고정해 재현성을 확보한다. pytest -n auto를 통한 병렬 실행과 엔드포인트 스로틀링 한도 조정도 함께 검토한다.

요구사항 중심 자동화가 만드는 효과

요구사항 커버리지와 체계적 샘플링을 적용하면 기능 결함 유출률이 20~40% 감소할 것으로 추정된다. 이는 동급 조직 벤치마크 기반이며 도메인·성숙도에 따라 편차가 존재한다.

병렬 실행과 계약 테스트를 도입하면 E2E 중심 회귀 대비 실행 시간을 50% 이상 절감할 수 있다. 내부 리팩터링의 영향을 최소화하는 구조는 테스트 유지보수 비용을 30% 내외 절감하는 효과로 이어진다.

입력 도메인 모델링과 명시적 오라클을 기반으로 계약·상태·의사결정 중심 기법을 조합해야 한다. 여기에 관측 가능성과 환경 격리를 더하고, 리스크 기반 우선순위로 핵심 경로부터 적용하는 방식이 블랙박스 테스트를 운영 가능한 회귀 체계로 만든다.