블랙박스 테스트

블랙박스 테스트(Black-box testing)는 시스템을 닫힌 상자로 취급합니다. 입력을 주고, 출력을 관찰하고, 명세에 정해진 결과와 비교합니다. 테스터는 프로그래밍 언어, 아키텍처, 코드 구조를 알 필요가 없습니다. 기능 테스트, 시스템 테스트, API 테스트, 인수 테스트의 대부분이 블랙박스 테스트입니다.

예시

송금 API가 1부터 10,000까지의 금액을 허용한다고 합시다. 블랙박스 테스터는 코드를 전혀 보지 않고 규칙에서 테스트를 도출합니다.

• 동등 분할: 범위 미만(0), 유효(500), 범위 초과(10,001), 숫자가 아닌 값("abc").
• 경계값: 0, 1, 2, 9,999, 10,000, 10,001.
• 기대 결과: 유효한 금액은 201 Created를 반환하고, 유효하지 않은 금액은 오류 메시지와 함께 400 Bad Request를 반환하며 돈이 이동하지 않습니다.

여기서 사용한 동등 분할과 경계값 분석, 그리고 결정 테이블, 상태 전이 테스트, 페어와이즈 테스트가 핵심적인 블랙박스 테스트 설계 기법입니다.

블랙박스 테스트와 화이트박스 테스트

	블랙박스	화이트박스
기준	요구사항과 명세	내부 코드 구조
필요한 지식	시스템이 무엇을 해야 하는지	코드가 어떻게 작성되었는지
주요 테스트 레벨	시스템, API, 인수	단위, 일부 통합
측정 지표	요구사항 커버리지	코드 커버리지(구문, 분기)
찾아내는 것	누락되거나 잘못된 동작, 명세 불일치	테스트되지 않은 경로, 죽은 코드, 로직 오류

어느 쪽도 다른 쪽을 대체하지 못합니다. 블랙박스 테스트는 아예 구현되지 않은 기능을 찾아낼 수 있지만, 화이트박스 테스트는 살펴볼 코드가 없으니 이를 찾지 못합니다. 반대로 화이트박스 테스트는 명세에 언급되지 않은 경로를 찾아낼 수 있습니다. **그레이박스 테스트(Grey-box testing)**는 둘을 결합합니다. API 호출 후 데이터베이스를 확인하거나 요청이 어느 서비스에 도달하는지 아는 것처럼, 내부 지식을 일부 활용하면서 인터페이스를 통해 테스트합니다.

장점과 한계

블랙박스 테스트는 구현과 독립적이므로 리팩터링 후에도 유지되며, 코드가 존재하기 전에 요구사항만으로 작성할 수 있습니다. 한계는 어떤 내부 경로를 놓쳤는지 알 수 없다는 점이며, 체계적인 기법 없이 진행하면 뻔한 정상 경로(happy path)만 테스트하기 쉽습니다.