화이트박스 테스트

화이트박스 테스트란

화이트박스 테스트(White-box Test)는 소프트웨어의 내부 구조와 실행 로직을 직접 들여다보며 코드가 의도한 경로대로 동작하는지 검증하는 구조 기반 테스트 기법이다. 명세나 외부 동작이 아니라 프로그램이 내부에서 거치는 제어 흐름과 데이터 흐름이 검증의 출발점이 된다.

테스트 설계자가 소스 코드를 읽을 수 있다는 전제 위에서 성립하므로, 개발자나 코드를 이해하는 검증 인력이 주로 수행한다. SWEBOK에서도 구조 기반 기법은 명세 기반 기법과 더불어 테스트 설계의 두 축으로 다루어진다.

제어 흐름 관점의 검증

화이트박스 테스트의 핵심은 프로그램이 분기와 반복을 통해 만들어내는 경로를 빠짐없이 짚어 보는 데 있다. 조건문 하나가 참과 거짓 두 갈래로 나뉘면, 각 갈래가 적어도 한 번씩 실행되도록 입력을 설계해야 숨어 있던 결함이 드러난다.

정상 흐름만 확인하고 예외 분기를 건드리지 않으면, 평소에는 잠잠하다가 특정 조건에서만 터지는 결함을 놓치게 된다. 따라서 어느 경로가 검증되었고 어느 경로가 비어 있는지를 명시적으로 관리하는 일이 곧 이 기법의 본질이다.

커버리지라는 기준

구조 기반 테스트가 신뢰를 얻으려면 검증이 어디까지 도달했는지를 수치로 표현할 수 있어야 한다. 이때 사용하는 척도가 커버리지이며, 구문 커버리지는 모든 문장이 한 번씩 실행되었는지를, 분기 커버리지는 모든 조건이 참과 거짓 양쪽으로 평가되었는지를 본다.

구문만 채워도 분기는 비어 있을 수 있으므로, 분기 커버리지가 구문 커버리지보다 강한 기준이 된다. 다만 커버리지 수치가 높다고 해서 결함이 없다는 보장은 아니며, 도달했으나 검증 단언이 부실하면 통과만 하고 결함은 남는다.

수치는 검증의 충분조건이 아니라 빈 곳을 가리키는 지표로 다루어야 한다.

블랙박스와의 역할 분담

화이트박스 테스트는 내부를 모른 채 입출력만으로 검증하는 블랙박스 테스트와 짝을 이루어 서로의 빈틈을 메운다. 블랙박스 테스트는 사용자 관점의 요구와 명세 충족 여부를 확인하지만 코드 내부의 특정 경로가 검증되었는지는 알지 못한다.

반대로 화이트박스 테스트는 경로를 촘촘히 살피지만 명세 자체가 잘못되었거나 누락된 요구는 잡아내기 어렵다. 두 기법은 우열의 관계가 아니라 검증 대상의 층위가 다른 보완 관계이며, 단위 검증은 구조 기반을, 인수 검증은 명세 기반을 중심에 두는 식으로 배치하는 것이 일반적이다.

적용의 한계와 비용

모든 경로를 빠짐없이 검증하려는 시도는 이상적으로 들리지만 현실에서는 경로의 수가 분기 결합에 따라 급격히 늘어나 전수 검증이 불가능해진다. 그래서 위험이 높은 핵심 로직과 결함 시 영향이 큰 모듈에 구조 기반 검증을 집중하고, 단순한 영역은 명세 기반으로 가볍게 다루는 선택과 집중이 필요하다.

또한 코드가 바뀌면 내부 경로도 함께 변하므로 화이트박스 테스트는 코드 변경에 민감하게 영향을 받는다. 이 취약성을 줄이려면 구현 세부가 아니라 의미 있는 동작 단위로 테스트를 설계해 유지보수 부담을 낮추어야 한다.

실무에서의 운영 방식

현장에서 화이트박스 테스트는 단위 테스트 자동화와 결합되어 지속적 통합 파이프라인 위에서 반복 실행되는 형태로 자리 잡는다. 코드를 커밋할 때마다 테스트가 돌고 커버리지가 측정되면, 어떤 변경이 어떤 경로의 검증을 깨뜨렸는지 즉시 드러난다.

이때 커버리지 목표를 무리하게 높게 잡아 형식적 통과만 양산하기보다, 결함이 자주 나는 영역의 실질 검증을 끌어올리는 방향이 효과적이다. 구조 기반 검증의 가치는 숫자를 채우는 데 있는 것이 아니라, 위험한 경로가 누락 없이 살펴졌다는 근거를 남기는 데 있다.