블랙박스 테스트로 요구사항과 기능을 검증하는 법

요구사항이 테스트의 기준이 된다

블랙박스 테스트는 내부 구조나 코드 경로를 보지 않고, 요구사항과 기능 명세에 비춰 입력·처리·출력이 맞는지 확인하는 기법이다. 사용자가 접하는 인터페이스와 계약(Contract), 데이터 유효성, 상태 전이가 검증 대상이 된다.

기능이 비즈니스 요구를 충족하는지, 정해진 규격을 따르는지 판단하는 데 쓰인다. 회귀 안정성을 확인하고 릴리스 게이트의 품질 기준을 세울 때도 적용할 수 있다. API, UI, 메시지와 이벤트, 파일과 배치, 데이터 파이프라인처럼 시스템 경계에서 특히 유용하다.

테스트는 요구사항·사용자 시나리오·명세서·API 스키마(OpenAPI/JSON Schema)를 모으는 데서 출발한다. 이후 적합한 기법을 선택해 케이스와 데이터, 오라클(기대 결과)을 정의하고 자동화 스크립트를 작성한다. 실행 결과는 불일치와 결함 리포트, 커버리지 지표, 갱신된 회귀 테스트 패키지로 남긴다.

명세가 모호하면 질의와 명세 보완으로 처리한다. 환경 장애는 재시도나 격리로, 비결정적 결과는 고정 시드와 리트라이 정책으로 다룬다.

명세에서 케이스를 만들고 결과를 판별한다

테스트 케이스는 요구사항, 계약, 상태 다이어그램, 결정 테이블에서 도출한다. 이 방식에서는 명세의 정확성과 추적성이 결과 품질에 직접 영향을 준다. 요구사항 추적 매트릭스(RTM)를 사용하면 커버리지에서 빠진 부분을 체계적으로 찾고 변경도 관리할 수 있다.

입력 공간은 동등 분할, 경계값 분석, 오류 추정, 페어와이즈 조합으로 줄인다. 익명화·샘플링·시드 고정을 포함한 테스트 데이터 관리는 재현성을 뒷받침한다. 출력은 룰·수학식·스냅샷을 쓰는 참조 오라클과 허용 오차·정규식을 쓰는 근사 오라클을 함께 적용해 검증한다.

API 계약 테스트, UI E2E, 배치 검증은 CI 파이프라인에 넣을 수 있다. 스모크에서 기능, 회귀, 비기능(성능/보안)으로 실행 단계를 나누고, 변경 영향도 기반 선택적 실행(Test Impact Analysis)으로 빌드 시간을 최적화한다.

외부에서 보이는 동작을 더 잘 관찰하려면 로깅·메트릭·트레이싱이 필요하다. 테스트 더블(Mock/Stub)은 외부 의존성을 차단한다. Idempotent setup으로 상태를 초기화하고 고정 시드를 사용하면 비결정성을 억제할 수 있다.

품질은 요구사항 커버리지, 데이터 도메인 커버리지, 시나리오(Use case) 커버리지로 관리한다. 결함 검출률, 재현율, flakiness, MTTR, 파이프라인 성공률도 운영 지표로 활용한다.

시스템 경계에서 검증하는 패턴

REST API 계약 테스트에서는 OpenAPI를 기준으로 유효·무효 입력, 경계값, 인증·권한, 레이트 리밋, 실패 코드 매트릭스를 검증한다. Consumer-driven Contract(Pact)는 마이크로서비스 사이의 호환성과 회귀 안정성을 보장하는 데 사용할 수 있다.

전자상거래에서는 장바구니→결제→정산→환불의 상태 전이를 상태 전이 테스트로 확인한다. 쿠폰·환율·부분 환불처럼 조합이 늘어나는 조건은 페어와이즈로 줄인다. 외부 PG와 재고 시스템은 스텁으로 처리하고, 실패와 보상 트랜잭션 시나리오를 우선 검증한다.

데이터 파이프라인과 ETL은 입력 스키마 변화, 널과 이상치, 집계 정확도, 중복·유실 여부를 결정 테이블로 설계한다. 샘플링과 스냅샷 오라클을 조합하면 대용량 환경에서도 빠르게 회귀를 수행할 수 있다.

레거시 시스템의 수용 테스트(UAT)에서는 기능 명세가 없을 때 로그와 운영 시나리오에서 유스케이스를 추출해 블랙박스 회귀 세트를 구성한다. UI 변경에 영향을 덜 받도록 비주얼 회귀를 최소화하고 기능 결과 중심으로 검증하면 변동 비용을 억제할 수 있다.

요구사항 커버리지 80%+를 확보하면 기능 결함 검출률이 2035%p 향상될 수 있으며, 조직 성숙도에 따라 달라진다. 변경 영향도 기반 회귀는 파이프라인 시간을 3060% 단축할 수 있다. flakiness를 2% 이하로 유지하면 재작업 시간을 25% 이상 절감할 수 있다.

이 접근은 사용자 관점의 품질 정렬과 릴리스 신뢰도 향상에도 연결된다. 팀 간 계약이 명확해져 커뮤니케이션 비용이 줄고, 명세-테스트-코드 추적성이 강화돼 규제와 감사에 대응하기 쉬워진다.

테스트 설계부터 회귀 기록까지의 흐름

⤢✕

화이트박스·그레이박스와 비교할 때

지표	블랙박스 테스트	화이트박스 테스트	그레이박스 테스트
성능(설계/실행 속도)	설계 빠름, 실행 병렬화 용이	설계 비용 큼, 단위 실행 빠름	중간
확장성(케이스 재사용)	요구사항 단위 재사용 용이	코드 변경에 민감	인터페이스 단위 재사용
일관성(재현성)	데이터/환경 관리 필요	모듈 고립으로 높음	중간
안정성(변경 영향)	명세 안정 시 영향 적음	리팩터링 영향 큼	중간
운영 편의(유지보수)	명세 중심 관리 용이	커버리지 도구 의존	양쪽 균형 필요

케이스와 실행 환경을 운영 가능하게 설계하기

입력 공간에는 동등 분할·경계값·오류 추정 3종을 최소 적용한다. 비즈니스 규칙은 결정 테이블로 충돌과 누락을 확인하고, 상태 전이에는 허용·금지 전이와 예외·보상 흐름을 포함한다.

테스트 데이터는 시드를 고정하고 마스킹하며 최소 대표 샘플 세트를 구성한다. 오라클은 정밀 일치(=), 허용 오차(±ε), 패턴(정규식), 스냅샷 비교를 병행한다.

파이프라인은 스모크(분 단위) → 회귀(시간 단위) → 야간 비기능(부하/내구)으로 계층화한다. 실패 시에는 1회 재시도하고 텍스트·영상 로그를 아카이브하며, flake 라벨링과 격리를 적용한다.

경계값으로 API 계약을 확인하는 pytest 예시

전제조건은 Python 3.11+, pytest 8+, requests 2+, OpenAPI 스키마 가정이다. 나이(age) 파라미터의 허용 범위인 0~120을 경계값으로 검증한다.

# test_age_boundary.py
import requests
import pytest

BASE = "http://localhost:8080"

@pytest.mark.parametrize("age, status", [
    (-1, 400),  # 하한 미만
    (0, 200),   # 하한
    (1, 200),   # 하한+1
    (119, 200), # 상한-1
    (120, 200), # 상한
    (121, 400), # 상한 초과
])
def test_age_boundary(age, status):
    r = requests.get(f"{BASE}/users?age={age}", timeout=3)
    assert r.status_code == status

이 예시는 유효·무효 입력의 동등 분할과 하한·상한·±1의 경계값을 적용한다. 내부 코드를 노출하지 않고 HTTP status라는 계약만으로 결과를 검증한다.