화이트 박스 테스트

화이트 박스 테스트

화이트 박스 테스트(White box testing) 기법은 블랙박스 테스트와 같이 기능성만을 검사하는 것이 아니라 사용된 데이터 구조, 내부 설계, 코드 구조, 소프트웨어의 동작 등 내부 구조를 분석한다. 이는 유리 상자 테스트(glass box testing), 투명 상자 테스트(clear box testing) 또는 구조적 테스트(structural testing) 등으로도 불린다. 화이트 박스 테스트는 투명 테스트(transparent testing) 또는 개방형 박스 테스트(open box testing)로도 알려져 있다.

화이트 박스 테스트는 소프트웨어 응용 프로그램의 내부 구조와 동작을 테스트하는 소프트웨어 테스팅 기법으로 테스터는 소스 코드에 접근하고 이를 이용하여 코드 수준에서 소프트웨어의 정확성을 검증하는 테스트 케이스를 설계한다.

 
화이트 박스 테스트는 구조적 테스트 또는 코드 기반 테스트(code-based testing)로도 알려져 있으며, 소프트웨어의 내부 논리, 흐름, 구조를 테스트하는 데 사용된다. 테스터는 코드 경로와 논리 흐름을 검사하는 테스트 케이스를 만들어 지정된 요구 사항을 충족하는지 확인한다.

 

화이트 박스 테스트의 작업 프로세스

• 입력: 요구 사항, 기능 사양, 디자인 문서, 소스 코드.
• 처리: 전체 과정 가이드하기 위해 위험 분석을 수행.
• 적합한 테스트 계획: 코드 전체를 커버할 수 있도록 테스트 케이스를 설계. 오류가 없는 소프트웨어가 도출될 때까지 반복해서 실행. 또한 결과를 전달.
• 출력: 전체 테스트 프로세스의 최종 보고서를 작성.

화이트 박스 테스트 기법

1. 구문 커버리지(Statement coverage)

모든 구문을 적어도 한 번씩 실행하도록 설계된 테스트 케이스를 사용하여 테스트한다.

아래 그림의 경우 모든 노드가 적어도 한 번은 수행되어야 한다.

따라서 2개의 테스트 케이스가 구성되어야 한다.

모든 코드 라인이 커버되므로 잘못된 코드를 파악하는 데 도움이 된다. 

모든 구문 테스트를 위한 2개의 테스트 케이스가 필요하다.

 

2. 결정(분기) 커버리지(Decision(Branch) Coverage)

각 분기점에서 가능한 모든 분기가 적어도 한 번씩 테스트되도록 테스트 케이스를 설계한다.

그림에서는 모든 엣지가 적어도 한 번은 수행되어야 한다.

모든 에지가 커버되는 4개의 테스트 케이스가 필요하다.

 

3. 조건 커버리지(Condition Coverage)

조건 커버리지는 테스트 케이스가 모든 조건문에 대해 최소한 한 번 이상 실행되어야 한다. 결정 커버리지의 하위 기법으로, 결정 커버리지와 유사하지만 개별 조건만 커버한다는 점에서 차이가 있다. 

public boolean isPositive(int number) {
  if (number > 0 && number % 2 == 0) {
    return true;
  } else {
    return false;
  }
}

위의 코드에서, isPositive 함수는 number가 양수이면서 짝수인 경우 true를 반환하고, 그렇지 않은 경우 false를 반환한다. 이 함수를 조건 커버리지를 충족시키도록 테스트하려면 다음과 같은 테스트 케이스를 작성해야 한다.

1. 'number'가 양수이고 짝수인 경우
2. 'number'가 양수이지만 홀수인 경우
3. 'number'가 음수이고 짝수인 경우
4. 'number'가 음수이고 홀수인 경우

위의 테스트 케이스들은 모든 개별 조건을 충족시키며, 각각의 경우에 대해 함수의 결과를 확인할 수 있다. 이것은 조건 커버리지를 통해 모든 조건이 제대로 작동하는지 확인할 수 있게 된다.

 

4. 다중 조건(복합 조건) 커버리지(Multiple Condition Coverage)

각 결정문에서 가능한 각 조건 조합을 테스트하는 화이트 박스 테스트 기법이다. 조건 적용 범위의 확장이며 가능한 모든 부울 조건 조합을 테스트하는 것을 목표로 한다.

public String calculateGrade(int score1, int score2) {
  if (score1 >= 90 && score2 >= 90) {
    return "A";
  } else if (score1 >= 80 && score2 >= 80) {
    return "B";
  } else if (score1 >= 70 && score2 >= 70) {
    return "C";
  } else {
    return "F";
  }
}

위의 코드에서, calculateGrade 함수는 score1과 score2의 점수에 따라 학점을 계산하여 반환한다. 이 함수를 다중 조건 커버리지를 충족시키도록 테스트하려면 다음과 같은 테스트 케이스를 작성해야 한다.

1. 'score1'과 'score2'가 모두 90 이상인 경우
2. 'score1'은 90 이상이고 'score2'는 80 이상인 경우
3. 'score1'은 90 이상이고 'score2'는 70 이상인 경우
4. 'score1'은 80 이상이고 'score2'는 90 이상인 경우
5. 'score1'과 'score2'가 모두 80 이상인 경우
6. 'score1'은 80 이상이고 'score2'는 70 이상인 경우
7. 'score1'은 70 이상이고 'score2'는 90 이상인 경우
8. 'score1'은 70 이상이고 'score2'는 80 이상인 경우
8. 'score1'과 'score2'가 모두 70 이상인 경우
9. 'score1'이 70 미만인 경우
10. 'score2'가 70 미만인 경우

 

5. 기본 경로 테스트(Basis Path Testing)

제어 흐름 그래프(Control Flow Graph)를 코드나 플로우차트에서 작성한 후 사이클로마틱 복잡도(Cyclomatic Complexity)를 계산해 각 독립적인 경로에 대해 최소한의 테스트 케이스를 설계할 수 있는 테스트 기법이다. 

사이클로마틱 복잡도는 제어 흐름 그래프에서 독립적인 경로의 개수를 정의하며, 각 독립적인 경로는 적어도 한 번 실행되어야 한다. 이를 통해 프로그램의 복잡성을 수치화하고, 테스트 케이스를 설계하고 실행할 때 충분한 커버리지를 확보할 수 있다.

 

테스트 스텝은 다음과 같다.

1. 코드나 플로우차트를 사용하여 제어 흐름 그래프(Control Flow Graph)를 작성한다.
2. 사이클로마틱 복잡도(Cyclomatic Complexity)를 계산한다. Cyclomatic Complexity는 제어 흐름 그래프에서 독립적인 경로의 개수를 정의한다. Cyclomatic Complexity (V)는 다음과 같이 계산된다.
   V = E - N + 2
   - E는 제어 흐름 그래프의 에지(edge) 수, N은 노드(node) 수.
3. Cyclomatic Complexity에 따라 독립적인 경로를 찾는다. 이 단계에서는 가능한 모든 독립적인 경로를 식별해야 한다.
4. 각 독립적인 경로에 대해 최소한의 테스트 케이스를 설계한다. 이를 통해 모든 독립적인 경로가 적어도 한 번은 실행될 수 있도록 보장한다.
5. 설계된 테스트 케이스를 실행하고 결과를 분석한다. 이를 통해 테스트 커버리지를 확인하고 테스트를 통과하지 못한 독립적인 경로를 확인할 수 있다. 이후 이러한 경로를 대상으로 추가적인 테스트를 수행할 수 있다.

6. Loop Testing

루프 테스트는 프로그램에서 루프 구조가 적절하게 작동하는지를 확인하는 데 사용되는 테스트 기법이다. 

루프는 많은 프로그램에서 반복적인 작업을 수행하는 데 사용되므로 루프에 대한 테스트는 매우 중요하다.

루프 테스트는 다양한 기법을 사용하여 수행될 수 있다. 예를 들어, 루프 횟수를 변경하여 루프 경계 조건을 테스트할 수 있다. 또한 루프 내에서 발생할 수 있는 오류를 식별하기 위해 루프 내에서 실행되는 모든 코드 경로를 테스트할 수 있다.

루프 테스트를 수행하는 데 있어서는 테스트 계획을 잘 수립하는 것이 중요하다. 테스트 계획을 통해 모든 루프 경로를 식별하고, 테스트 케이스를 설계하여 루프 경계 조건을 충분히 검증할 수 있다. 또한, 테스트 결과를 분석하여 루프에서 발생한 오류를 식별하고 수정하는 데 필요한 조치를 취할 수 있다.

 

1. 단순 루프(Simple loops)

크기가 n인 단순 루프의 경우, 테스트 케이스는 다음과 같이 설계된다.

• Skip the loop entirely
• Only one pass through the loop
• 2 passes
• m passes, where m < n
• n-1 ans n+1 passes

2. 중첩된 루프(Nested loops)

중첩된 루프는 루프 안에 다른 루프가 있는 경우를 말한다. 이 경우 루프가 시작되기 전에 내부 루프가 끝날 때까지 완료되어야 한다. 내부 루프는 외부 루프에 종속되므로 내부 루프가 제대로 작동하지 않으면 외부 루프도 제대로 작동하지 않을 수 있다. 따라서 루프 테스트를 수행할 때 중첩된 루프에서는 외부 루프에서 시작하여 내부 루프로 이동하고 내부 루프에서 모든 가능한 경로를 테스트한 후 외부 루프로 돌아가서 다음 경로를 테스트한다. 이렇게 하면 모든 루프가 제대로 작동하는지 확인할 수 있다. 

 

3. 연결된 루프(Concatenated loops)

연결된 루프(Concatenated loops)란 코드에서 두 개 이상의 독립된 루프가 연속적으로 나타나는 상황을 말한다. 연결된 루프를 테스트하기 위해서는 각 독립된 루프에 대해 간단한 루프 테스트가 적용된다. 루프가 독립적이지 않은 경우에는 중첩된 루프와 같이 처리하고, 이전에 설명한 대로 루프 테스트가 수행된다. 목표는 모든 루프가 독립적으로 테스트되며 모든 가능한 시나리오가 다루어져 소프트웨어가 올바르게 작동되도록 보장하는 것이다. 

 

화이트 박스 테스트 기법 수행 단계 및 도구

화이트 박스 테스트는 소프트웨어의 내부 작동 원리에 대한 이해와 함께 수행되는 테스트 방법이다. 이 방법은 2단계로 수행된다.

1단계: 코드 분석 - 코드를 분석하여 각 경로의 횟수 및 경로 상태를 확인한다. 이 과정에서 경로 분석 도구를 사용할 수 있다.

2단계: 테스트 케이스 작성 - 경로 분석을 기반으로 테스트 케이스를 작성한다. 이 과정에서 테스트 케이스 설계 기법을 사용할 수 있으며, 코드 내 모든 가능한 분기 및 조건에 대해 테스트 케이스를 작성한다. 이후 테스트 케이스를 실행하여 오류를 발견하고 수정한다.

 

화이트 박스 테스트에 사용되는 Tools

• PyUnit
• Sqlmap 
• Nmap
• Parasoft Jtest
• Nunit
• VeraUnit
• CppUnit

화이트 박스 테스트의 특징 및 장단점

화이트 박스 테스트의 특징

1. 코드 커버리지 분석: 화이트 박스 테스트는 애플리케이션의 코드 커버리지를 분석하여 테스트되지 않는 코드 영역을 식별하는 데 도움이 된다.
2. 소스 코드 액세스: 화이트 박스 테스트는 애플리케이션의 소스 코드에 대한 액세스가 필요하므로 개별 함수, 메서드 및 모듈을 테스트할 수 있다.
3. 프로그래밍 언어 지식: 화이트 박스 테스트를 수행하는 테스터는 Java, C++, Python 및 PHP와 같은 프로그래밍 언어에 대한 지식이 필요하여 코드 구조를 이해하고 테스트를 작성할 수 있다.
4. 논리 오류 식별: 화이트 박스 테스트는 무한 루프나 잘못된 조건문과 같은 코드의 논리적 오류를 식별하는 데 도움이 된다.
5. 통합 테스트: 화이트 박스 테스트는 통합 테스트에 유용하다. 서로 다른 애플리케이션 구성 요소가 예상대로 작동하는지 확인할 수 있기 때문이다.
6. 단위 테스트: 화이트 박스 테스트는 개별 코드 단위가 올바르게 작동하는지 확인하는 단위 테스트에도 사용된다.
7. 코드 최적화: 화이트 박스 테스트는 성능 문제, 중복 코드 또는 개선할 수 있는 영역과 같은 코드를 최적화하는 데 도움이 될 수 있다.
8. 보안 테스트: 화이트 박스 테스트는 애플리케이션의 코드에서 취약점을 식별할 수 있기 때문에 보안 테스트에도 사용될 수 있다.

 

화이트 박스 테스트의 장점

 - 화이트박스 테스트는 전체 코드와 구조를 테스트하기 때문에 매우 철저하다.
 - 코드 제거 오류를 최적화하고 추가 코드 줄을 제거하는 데 도움이 된다.
 - 블랙박스 테스트의 경우처럼 인터페이스가 필요 없기 때문에 초기 단계에서 시작할 수 있다.
 - 자동화가 용이하다.
 - 화이트박스 테스트는 소프트웨어 개발 라이프사이클에서 쉽게 시작할 수 있다.
 - 간편한 코드 최적화.

 

화이트 박스 테스트의 단점

 - 비용이 많이 든다.
 - 코드 재설계 및 코드 재작성에는 다시 테스트 케이스를 작성해야 한다.
 - 테스터는 블랙박스 테스팅과는 달리 코드와 프로그래밍 언어에 대한 깊은 이해가 필요하다.
 - 코드 테스트 시 존재하지 않는 기능을 감지할 수 없다.
 - 매우 복잡하며 때로는 현실적이지 않다.
 - 운영 중에 발생할 수 있는 오류의 가능성이 훨씬 높다.