이번 포스팅에서는 화이트 박스 테스트와 블랙 박스 테스트에 대해서 이야기 해 보고자 한다.
물론 “지식 제로부터 배우는 소프트웨어 테스트” 를 읽고 공부한 내용이다.

화이트 박스 테스트 란 무엇인가?

소프트웨어의 내부구조를 철저하게 분석하여 논리 구조가 올바른지 분석하는 테스트를 말한다. 정의 대로 논리 구조를 검증하는 테스트이므로 소프트웨어 사양이 잘못된 것은 검증할 수 없다.
이 책에서는 두 가지 정도를 이야기 하고 있다.

첫째, 제어 흐름 테스트 ( 소프트웨어의 동작 흐름 테스트 )이다. 제어 흐름 테스트는 말 그대로 논리적 흐름에 대한 테스트를 하는 것을 말한다. 여기서 커버리지라는 개념이 나오는데, 사전적 의미로 “범위” 를 말한다.

커버리지는 두 가지가 있는데, 스테이트먼트 커버리지와 브랜치 커버리지 이다. 스테이트먼트 커버리지는 말그대로 명령문만 테스트 하는 것을 말한다. 이것이 무슨 의미인가?
예를 들어 아래 코드에서 (a) 가 동작하는 경우와 (b)가 동작하는 경우만 테스트 하는 것을 말한다.
테스트 케이스로 i=1 이고 k=2인 경우를 테스트하면 (a)와 (b)를 테스트 할 수 있다.

if(i>0){
   j = i+1;   //(a)
}
if(k<3){
   j = i-1;   //(b)
}

하지만 그 이외의 경우 i=0 이고 k=3 인 상황은 검증이 되지 않는다

그래서 브랜치 커버리지를 확인 해야 한다.
브랜치 커버리지는 분기를 테스트 하는 것을 말한다. i>0 조건의 True 인 상황과 False 인 상황을 검증하고 k<3 조건이 True 인 상황과 False 인 상황 모두를 검증 하는 것이다.

둘째, TDD (Test Driven Development)

TDD(테스트주도개발)는 사실 개발 방법론의 하나로 알고 있다. 저자도 말하고 있는 것은 TDD의 본질은 확실하게 품질을 보증하겠다는 의미보다는 변경에 강인하고 신속한 개발을 위한 방법이라는 것이다.
이 부분에 대해서는 따로 공부를 해봐야겠다.

실무에서는 화이트 박스 테스트는 테스터가 하기엔 어려움이 있고, 개발자가 주로 유닛테스트를 통해 진행하는 듯하다.

블랙 박스 테스트 란 무엇인가?

블랙 박스 테스트는 프로그램을 일종의 블랙박스로 보고 다양한 입력을 실행함으로써 소스 코드를 이용하지 않고 테스트를 수행 하는 방법이다. 대부분의 실무에서 블랙박스 테스트 방법을 수행하고 있다.
블랙 박스 테스트의 기본적인 방법으로 등가 분할과 경계값 분석이 있다.

if( a >0 && a <100 && b>0 && b<100 )
{
    c = a*b;
}
else
{
    // input error
}

등가분할

‘등가분할’ 이란 입력 영역을 ‘등가 클래스’라는 부분 집합으로 분할 하고, 그 부분 집합에서 선택한 입력값을 모두 같은 값(등가)라고 보는 작업이다.

예를 들어 입력 A 를 1~99 까지 입력 가능하고, 입력 B 를 1~ 99 까지 입력이 가능 하다고 가정 할 때
출력 C = A B 의 결과 출력하는 프로그램이 있다고 하자.
여기서 입력 할 수 있는 값을 A,B 모두 1~99 까지다. 사실상 1~99 사이의 어느 값 하나씩만 넣어 보면 c = ab 의 결과는 동일하게 출력 된다. 이 부분을 유효 등가라고 하고 -1 을 입력 하거나 100 이상을 입력 하였을 경우는 에러가 된다. 이를 무효 등가라고 부른다.

유효 등가 클래스와 무효 등가 클래스로 각각 케이스를 만들어 보자.

유효 등가 테스트 케이스
(1) A=50 B=50

무효 등가 테스트 케이스
(2) A = -1, B = -1
(3) A = -2, B = 101
(4) A = 0, B = 50
(5) A = 50, B = 0
(6) A = 50, B = 101
(7) A = 101, B = 60
(8) A = 110, B = 110
(9) A = 105, B = -5
(10) A = 0, B = 0

총 10가지의 케이스가 나올 수 있다. 이렇게 간단한 경우에도 무효 등가가 9개나 있기 때문에 효율적으로 테스트하기 위해서는 케이스를 줄여야 한다. 저자는 이를 ‘실천적 등가 클래스 테스트(Weak Robust Equivalent Test’ 라고 부른다.
위의 예제에서 보면 (2)와 (8)이 무효 등가를 모두 포함하고 있음을 알 수 있다. 그래서 (1) 유효등가와 (2),(8),(10) 의 무효등가만 테스트하면 된다.( 여기서 A가 0 이고 B 가 0 인 경우는 항상 특별한 값이므로 입력할 수 있을 때는 항상 케이스에 포함하라고 한다. - 이유는 좀 알아봐야겠다. 잘 모르겠음.)

경계값 분석

소프트웨어에서 경계가 되는 부분의 값에 버그가 있을 확률이 높다고 한다. 그래서 이 부분을 테스트 해야 하는데 이를 경계값 분석이라고 한다. 여기서 경계가 되는 부분이라 함은 유효등가와 무효등가의 경계를 말한다. 소프트웨어에서는 무효등가와 유효등가 사이에 반드시 조건문이 필요한데, 이러한 조건문을 올바르게 작성하지 않는 경우가 있기 때문에 테스트 해야 한다고 한다.

디시전 테이블 (Decision Table)

모든 입력의 조합을 표로 만든 다음에 이에 해당하는 동작이나 출력하는 방법을 말한다. 이 방법은 복잡한 상태가 얽힌 기능 테스트에 도움이 된다고 한다. 위의 예제로 디시전 테이블을 만들어 보도록 하겠다.

경우1 : A,B 모두 입력 값이 올바른 경우
경우2 : A는 올바른 입력이나 B 는 잘못된 입력인 경우
경우3 : A 는 잘못된 입력이나 B 는 올바른 입력인 경우
경우4 : A,B 둘다 잘못된 입력인 경우

이 방법은 단점이 있는데 아주 작은 소프트웨어거나 대규모 소프트웨어 일부분을 테스트 할 때만 사용할 수 있다. 예를 들어 1000개의 넘는 항목일 경우는 경우의 수가 너무 많아져서 테스트 할 수 없다.
대신 항목이 적고 복잡하게 움직이는 소프트웨어에 대해서는 특정 경우가 빠지는 것을 막을 수 있기 때문에 유용한 방법이다.
책을 읽으면서 계속 느끼는 것이지만, 하나의 소프트웨어 안에서도 기능에 따라 적합한 테스트 방법을 적용 해야 효율적인 테스트를 할 수 있다.
상태 전이 테스트

일반적으로 요즘 소프트웨어는 항상 같은 상태에 있는 것이 아니라 상태를 변화 시켜 소프트웨어의 조작을 쉽도록 한다. 예를 들어 워드 프로세서와 같은 프로그램에서 파일을 열기 위해 파일 열기 메뉴를 클릭 했을 때 파일 열기 대화 상자가 표시되는 것은 상태 변화 이다. 만약에 이런 상태 변화가 없다면 사용하기 매우 어려운 소프트웨어가 될 것이다.

상태 전이 테스트는 UI 를 테스트 할 때 유용한 테스트가 된다. 이 때 발견할 수 있는 버그는 기대하지 않은 상태로 전이하는 버그 ( 쌩뚱맞은 화면으로 넘어가는 버그 ), 전이 자체가 일어 나지 않는 버그 ( 화면이나 동작의 변경이 없는 버그 ) 가 있다.

마찬가지로 상태 전이 테스트도 문제점이 있는데, 상태의 수가 너무 많은 경우 테스트 항목이 너무 늘어나서 테스트 할 수 없게 된다. 게다가 모델링 시간이 너무 걸리게 되어 실제 테스트 하는 시간이 부족해 진다. 20~30개 정도의 상태 전이가 일어나는 소프트웨어는 직접 모델링 할 수 있으나, 100개 이상의 상태 전이가 일어나는 소프트웨어는 반드시 지원 도구를 사용해야 모델링에 효율을 높일 수 있다.

무작위 테스트 ( Monkey Test )

아무것도 생각하지 않고 입력이나 조작을 수행하는 방법을 말한다. 에드혹(Ad-hoc) 테스트, 애드립 테스트, 무작위 테스트, 몽키 테스트 와 같이 굉장히 다양한 이름으로 불리고 있다. 그러니 누군가가 몽키 테스트 라는 것 아느냐 라고 물어 본다면 당황하지 말길..
이 테스트 방법도 전혀 효과가 없는 것은 아니니 빼먹지 않고 써보면 좋을 듯 하다. (의외로 많은 버그가 이 방법으로 발견되곤 한다. 소프트웨어를 이해하지 못한 사용자가 써보면 그게 무작위 테스트가 되는 것은 아닐까? 그래서 처음 사용하는 사용자가 버그를 많이 발견 해내나?)

소프트웨어 테스팅의 주요 목적은 많은 버그를 찾는 것이다. 하지만 보다 중요한 것은 효율적으로 버그를 찾는 것이다. 똑똑하지 않은 테스트를 많은 시간을 들여서 했다고 그만큼 소프트웨어의 품질이 올라가지 않는다는 뜻이다. 소프트웨어 테스팅 기법이라는 도구들로 똑똑한 테스트를 해 보자.