화이트박스 테스트 기법

화이트박스 테스트 기법 중에서도 널리 사용되며 간단한 두 가지 코드 관련 기법인 구문 테스트와 분기 테스트에 중점을 둔다.
안전이 중요한 환경, 미션 크리티컬 환경 또는 고무결성 환경에서는 더 철저한 코드 커버리지를 달성하기 위해 보다 엄격한 기법이 사용된다. 또한, 상위 테스트 레벨(예: API 테스트)이나 코드와 관련되지 않은 커버리지(예: 신경망 테스트에서의 뉴런 커버리지)에 사용되는 화이트박스 테스트 기법도 있지만 FL 레벨에서는 다루지 않는다.

---

1. 구문 테스트와 구문 커버리지

구문 테스트(Statement Testing)에서 커버리지 항목은 실행 가능한 구문이다. 테스트 케이스를 설계하여 코드의 구문을 실행하고, 허용 가능한 커버리지 수준에 도달하는 것이 목표다.
커버리지 측정은 테스트 케이스가 실행한 구문의 수를 코드 내 전체 실행 가능한 구문의 수로 나눈 값이며, 백분율로 표현된다.

100% 구문 커버리지를 달성하면 코드의 모든 실행 가능한 구문이 최소 한 번 이상 실행되었음을 보장한다. 이는 결함이 있는 모든 구문이 실행되었음을 의미하며, 해당 결함으로 인해 실패가 발생할 수 있다.
그러나 구문 실행만으로는 모든 결함을 발견하지 못할 수 있다. 예를 들어, 데이터 종속 결함(분모가 0일 때 발생하는 0으로 나누기 오류 등)은 특정 데이터 값 없이 탐지되지 않을 수 있다. 또한, 100% 구문 커버리지는 모든 분기 로직을 테스트하는 것을 보장하지 않는다.

구문 커버리지 정의 및 측정

• 구문 커버리지 공식: 구문 커버리지 (%) = (테스트된 구문 수 / 전체 실행 가능한 구문 수) × 100
• 100% 구문 커버리지를 달성하면 모든 실행 가능한 구문이 최소 한 번 이상 테스트되었음을 보장한다.
• 예시:

if x > 0:
    y = x + 1
else:
    y = x - 1

• 테스트 케이스 1: x=1x = 1x=1 → if 경로 실행.
• 테스트 케이스 2: x=−1x = -1x=−1 → else 경로 실행.
  위 두 테스트 케이스로 100% 구문 커버리지를 달성한다.

한계점

• 구문 실행만으로는 데이터 종속 결함을 발견하지 못할 수 있다.
  예: 나누기 연산에서 분모가 0일 경우의 오류는 특정 데이터 값이 필요하다.
• 모든 분기 로직이 테스트되었음을 보장하지 않는다(분기 커버리지를 통해 해결 가능).

---

2. 분기 테스트와 분기 커버리지

분기(branch)는 제어 흐름 그래프에서 두 노드 간의 제어 흐름 전환을 의미한다. 이는 코드가 실행되는 가능한 순서를 나타낸다. 제어 흐름은 무조건적(직선 코드) 또는 조건적(결정 결과)에 따라 전환된다.
분기 테스트(Branch Testing)에서 커버리지 항목은 분기이며, 테스트 케이스를 설계하여 코드의 분기를 실행하고, 허용 가능한 커버리지 수준에 도달하는 것이 목표다.
커버리지 측정은 테스트 케이스가 실행한 분기의 수를 코드 내 전체 분기의 수로 나눈 값이며, 백분율로 표현된다.

100% 분기 커버리지를 달성하면 코드의 모든 분기(무조건적 및 조건적)가 테스트 케이스에 의해 실행된다. 조건적 분기는 보통 if-then 결정, switch/case 문, 또는 반복문 내의 종료/계속 여부로 나타난다.
그러나 분기 실행만으로도 모든 결함을 탐지할 수 없을 수 있다. 예를 들어, 특정 경로 실행을 요구하는 결함은 탐지되지 않을 수 있다.

분기 커버리지는 구문 커버리지를 포함한다. 즉, 100% 분기 커버리지를 달성하는 테스트 케이스는 100% 구문 커버리지를 보장하지만, 그 반대는 성립하지 않는다.

분기 커버리지 정의 및 측정

• 분기 커버리지 공식: 
• 100% 분기 커버리지는 모든 조건 및 분기가 최소 한 번 이상 테스트되었음을 보장한다.

구문 커버리지와의 관계

• 100% 분기 커버리지는 항상 100% 구문 커버리지를 포함한다.
• 그러나 100% 구문 커버리지가 100% 분기 커버리지를 보장하지는 않는다.

예1. 조건적 분기

if x > 0 and y > 0:
    z = x + y
else:
    z = x - y

• x=1,y=1: if 분기 테스트.
• x=−1,y=−1x = -1, y = -1x=−1,y=−1: else 분기 테스트.

예2. 반복문

for i in range(3):
    print(i)

 

• =0,1,2: 반복문 실행.
• i=3i = 3i=3: 반복문 종료 분기 테스트.

 

---

3. 화이트박스 테스트의 가치

 

화이트박스 테스트의 주요 강점은 소프트웨어 구현 전체를 테스트에 고려한다는 점이다. 이를 통해 소프트웨어 명세가 모호하거나 오래되었거나 불완전한 경우에도 결함을 탐지할 수 있다.
그러나 소프트웨어가 요구사항 중 일부를 구현하지 않은 경우, 화이트박스 테스트는 누락으로 인한 결함을 발견하지 못할 수 있다.

화이트박스 기법은 정적 테스트(예: 코드 실행 전 드라이 런)에도 사용 가능하다. 이는 실행 준비가 되지 않은 코드, 의사 코드(pseudocode), 고수준 또는 상향식 로직의 검토에 적합하며, 제어 흐름 그래프를 통해 모델링할 수 있다.

단순히 블랙박스 테스트만 수행하는 경우 실제 코드 커버리지 측정이 불가능하다.
화이트박스 커버리지 측정은 객관적인 커버리지 수준을 평가하며, 추가 테스트를 생성하여 커버리지를 높이고, 코드에 대한 신뢰도를 증가시키는 데 필요한 정보를 제공한다.

 

화이트박스 테스트의 주요 장점

1. 구현 세부 사항 검증
   • 블랙박스 테스트는 요구사항 명세를 기반으로 하므로 구현 세부 사항이 누락되거나 잘못된 경우 이를 탐지하기 어렵다.
   • 화이트박스 테스트는 코드를 직접 검토하고 테스트하므로 더 깊은 수준에서 결함을 발견할 수 있다.
2. 정적 테스트에 활용 가능
   • 코드를 실행하지 않고도 정적 분석, 드라이 런, 또는 제어 흐름 그래프를 통해 결함을 탐지할 수 있다.
   • 예: 코드 리뷰 또는 의사 코드(pseudocode) 검토.
3. 객관적인 커버리지 평가
   • 커버리지 메트릭을 통해 테스트 품질을 측정하고, 누락된 테스트 케이스를 보완할 수 있다.
   • 커버리지 목표를 설정하고 이를 달성하기 위한 계획을 수립하는 데 기여한다.

화이트박스 테스트의 한계

1. 요구사항 누락 탐지 어려움
   • 소프트웨어가 구현하지 않은 요구사항은 화이트박스 테스트로 탐지할 수 없다.
   • 예: 명세에 포함되지 않은 기능.
2. 테스트 케이스 설계 비용
   • 코드의 모든 분기와 경로를 테스트하려면 설계와 실행에 많은 시간과 리소스가 필요하다.