[소프트웨어 공학] 테스팅이란? 테스트 방법 및 기법 정리(블랙박스 vs 화이트박스)
테스팅이란?
소프트웨어 테스트란?
소프트웨어 테스트란 실제 결과가 예상 결과와 일치하는지 확인하여 소프트웨어 시스템의 결함을 찾아내는 작업이다.
소프트웨어 테스팅에 쓰이는 용어는 아래와 같다.
실제 실행 결과(Actual Output) : Input으로 Test Item을 실행한 실제 결과
기댓값(Expected Result) : 실행 결과로서 나올것으로 기대하는 결과값. 즉 정상적으로 작동할 경우 나와야할 값이다.
테스트 결과(Test result) : 예상 결과와 실행 결과를 비교한 값이다. 테스트 결과가 fail일 때 결함을 검출 할 수 있으므로 성공이라고 할 수 있다.
테스트 대상(Test Item) : 테스트가 될 대상이다. 함수/클래스/요소/시스템 등이 될 수 있다.
테스트 케이스(Test Case) : 명세 기반 테스트의 설계 산출물, 설계된 입력값, 실행조건, 기대 결과 등이다.
*테스트 대상은 테스트 레벨에 따라 달라질 수 있다.
ex) Unit/Component Test, Integration Test, System Test
테스트의 종류
테스트는 분류에 따라 다양하게 나뉜다. 그 분류는 대표적으로 테스트 케이스 기반, 레벨 기반 명세 기반 등이 있다. 그중 단계(레벨)에 기반한 테스트로는 아래의 세 가지가 있다.
단위 테스트(Unit/Component Test)
개별적 함수, 클래스 등에 초점을 두는 테스트 방법. 테스트가 가능한 최소 단위로 나누어서 테스트를 진행한다. 시스템의 다른 부분에서 격리하여 독립적으로 수행하여야 하는 테스트이다.
통합 테스트(Integration Test)
각 컴포넌트간의 연결에 초점을 두는 테스트 방법. 단위 테스트에서 각 부분들이 정상 작동되는 것이 확인되면, 이 부분들을 연동하여 테스트를 수행하게 된다.
단위 테스트에서 발생하지 않은 문제가 각 단위를 통합하는 과정에서 발생할 수도 있기 때문에 실행하는 테스트라고 할 수 있다.
시스템 테스트(System Test)
하나의 시스템에 초점을 두고 테스트하는 방법. 이전과 다르게 처리시간 등의 비기능적인 요소들도 함께 검사하게 된다. 주로 black Box레벨에서 수행하게 된다. 시스템에 대한 지식이 없어도 테스트를 수행 할 수 있다.
*소프트웨어의 요구명세의 각 사항은 테스트의 특성이 될 수 있다. 예를 들어 기능적 요구사항, 품질 요구사항(성능), 품질요구사항2(보안) 등은 각 테스트가 검사해야할 특성이 될 수 있다.
테스트 케이스 디자인 테크닉
Test Case Design Techniques
테스트 케이스를 작성하는 데에는 테크닉이 필요하다. 앞서 언급한 단위, 통합, 시스템 테스트는 테스트 단계에 기반하고 있다면, 아래에서 설명할 방법들(블랙박스 테스팅, 화이트박스 테스팅)은 테스트케이스 디자인에 기반하고 있다.
*기반하는 점이 다른 테스트들은 서로 독립적으로 존재할 수 있다. 예를 들어 통합 테스트 단계에서 블랙박스 테스트를 실행 할 수도, 화이트 박스 테스트를 실행할 수도 있다. (그러나 일반적으로 통합 단계에서는 블랙박스 테스트를 진행하는 경우가 더 많다.)
이상적인 테스트의 경우는 모든 경우의 수를 다 포함하여 검사하는 것이겠지만, 이 경우 막대한 비용이 든다.
Exhaustive Testing is impossible!(완벽한 테스트는 불가능하다!)
완벽한 테스트의 예로는 아래의 상황이 있겠다.
한 모듈이 두 개의 Integer를 입력받는다.
문제점:
이 모듈의 모든 입력 가능한 경우의 수는 2^64이다.(os나 컴파일러에 따라 32일 수도 있지만 64라고 가정)
만약 각 테스트 케이스에 대해 걸리는 시간이 10^-7이라면?(이는 무척이나 적은 시간이다.)
계산해보면 무려 58,494라는 시간이 걸리게 된다. 단 두 개의 인트값만으로!
이러한 비용 문제를 해결하기 위해 필요한 것이 바로 테스트 케이스 디자인이다.
이 테스트 케이스 디자인의 목적은 결함의 검출이며, "적당히 많은" 테스트 케이스를 존재하여야한다. 즉, 각 테스트 디자인의 차이는 "적당히 많은"을 어떤 방식으로 접근하느냐라고 할 수 있다.
블랙 박스 테스팅(Black Box Testing)
처음으로 볼 테스트 케이스 디자인은 바로 블랙박스 테스팅이다.
블랙박스 테스팅이란 소프트웨어 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 테스트 방법이다. 쉽게 말해 개발자 입장이 아닌 사용자의 입장에서 기대하는 바와 제품이 일치하는지를 테스트하는 것이다.
블랙박스 테스팅에 사용되는 기법
• 동등 분할 기법(Equivalance partitionning)
정상적인 입력값과 비정상적인 입력값의 개수를 균등하게 정하고 해당 입력값에 맞는 결과의 출력값을 확인하는 기법
예를 들어 이차방정식의 해의 개수를 구하는 경우 테스트 케이스는 아래와 같이 나눌 수 있다.
1) b^2 – 4ac(이하 판별식) > 0인 경우
2) 판별식 = 0인 경우
3) 판별식 < 0인 경우
4) 판별식 = 0인 경우,
즉, 동등 분할 기법에서 균등하다는 것은 결함 발생 가능성이 균등하다는 것을 의미한다.
• 경계값 분석 기법 (Bounddary-value analysis)
입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법. 이는 일반적으로 입력조건의 중간값보다 경계값이 오류 발생 확률이 높다는 점을 전재로 하는 기법이다.
2-value boundary value analysis
2-value boundary를 사용하는 경우 왼쪽의 경계에서 2개, 오른쪽의 경계에서 2개를 선택하여 사용한다.
예를 들어 값이 1<= X < 10이라면 테스트 케이스트는 0과 1(조건을 충족시키지 않는 값과 조건을 충족시키는 값) 그리고 9와 10이 될 것이다.
일반적으로 경계값 분석 기법은 2-value boundary value analysis로 이루어진다.
3-value boundary value analysis
3-value boundary value analysis를 사용하는 경우 왼쪽의 경계에서 3개, 오른쪽의 경계에서 3개를 선택하여 사용한다. 범위 내부의 값을 포함한다는 점이 다르다.
즉, 0 1 2와 8 9 10이 사용된다.
• 페어와이즈 테스팅(Pair-wise testing)
대부분의 결함은 두 요소의 상호작용에서 기인한다는 데에서 착안한 테스팅 방법이다. 두 요소의 모든 조합을 커버하도록 테스트하는 기법이다.
예를 들어 한 함수에 여러개의 파라미터가 주어질 때 가능한 경우의 수는 무척 다양하다.
void format(type, size, method, filesystem)이라는 함수가 있고 각 파라미터에 가능한 값이 4개라면, 4*4*4*4 = 256의 경우의 수가 존재한다.
이때, 각 조합쌍(type-size, type-method...)들의 경우의 수를 만족하도록 파라미터를 정하게 된다.
예시 1)
파라미터가 3개가 있므며, 가능한 경우의 수는 각 2개씩이다. 정리하자면 아래와 같다.
파라미터1: 1,2
파라미터2: a,b
파라미터3: A,B
이 경우 페어와이즈 테스트 케이스는 아래와 같다.
| 파라미터1 | 파라미터2 | 파라미터3 |
| 1 | b | A |
| 1 | a | B |
| 2 | b | B |
| 2 | a | A |
파라미터1-파라미터2(1-b, 1-a, 2-b, 2-a), 파라미터1-파라미터3(1-A, 1-B, 2-A, 2-B),파라미터2-파리미터3(a-A, a-B, b-A, b-B) 이라는 모든 조합쌍이 테스트케이스로 작성된 것을 확인할 수 있다.
*페어와이즈 테스트 케이스를 직접 작성하는 것은 힘든 일이다. pict라는 툴을 사용하면 테스트 케이스를 쉽게 작성 할 수 있다.(위의 예도 pict를 이용해 작성되었음)
화이트 박스 테스팅(White Box Testing)
화이트박스 테스팅은 블랙박스 테스팅과 반대로 소프트웨어나 제품의 내부구조, 동작을 세밀하게 검사하는 테스트 방법이다.
화이트박스 테스팅에 사용되는 기법
• 문장 검증 기준 검사(Statement Coverage Test)
각 테스트 케이스가 소스 내의 각 문장을 한 번 이상 실행하도록 설계하는 방법이다.
예를 들어 문장이 3개가 있을 때, 테스트케이스1이 1, 2를 실행하고 테스트 케이스2가 2, 3을 실행하도록 하는 방법이다.(혹은 테스트 케이스 1이 1, 2, 3을 모두 실행하는 수도 있다. 중요한 것은 모든 문장이 모두 실행되도록 테스트 케이스를 작성하는 것)
• 분기 커버리지 검사(Branch Coverage Test or Decision Coverage Test)
조건문의 전체 브런치를 모두 조사하는 기법이다.
즉 if문을 만났을 때 true인 경우로 실행되는 분기 문장과 false인 경우로 실행되는 분기 문장, 모든 경우를 조사한다.
Branch Coverage는 Statement Coverage를 포함한다. 따라서 branch coeverage가 100%라면 statement coverage역시 100%가 된다.
예를 들어 한 함수에 if(a = 1)이라는 문장과 if(b==2)라는 문장이 있다면, 각각의 if문이 false가 되는 case와 true가 되는 case를 각각 테스트 케이스로 포함한다.
테스트 케이스 예시)
if(a ==1) ...
if(b == 2) ...
TC1 : a= 1, b = 3(True, False)
TC2 : a = 2, b = 2(False, True)
• 조건 검사(Condition Coverage Test)
조건 문 내에 존재하는 개별적인 조건에 대해서 검사하는 기법이다.
앞서 브렌치 커버리지 테스트에서는 분기가 true인 경우와 false인 경우를 조사했다면, 조건 검사에서는 조건문 내의 각 경우가 true, false가 나오도록 테스트 케이스를 작성한다.
예1)
if(a >= 2 && b == 0)
이 문장에서 a >= 2가 true인 경우, false인 경우 b == 0가 True인 경우 false인 경우에 대해 테스트 케이스를 작성한다.
테스트 케이스 예시)
TC1 : a = 2, b = 0(True, True) _ Coverage: 2/4
TC2 : a = 1, b = 3(False, False) _ Coverage: 2/4
총 coverage = 4/4
예2)
if(a >= 2 && b ==0 && c==1)
이 문장에서 역시 각 조건이 true인 경우와 false인 경우가 포함되도록 테스트 케이스를 작성한다.
테스트 케이스 예시)
TC1 : a = 2, b = 0, c = 1(True, True, True)
TC2 : a = 2, b = 1, c =0(True, False, False)
TC3 : a =0, b = 0, c = 1(False, True, True)
• 조건/분기 커버리지 검사(Condition/Decision Coverage Test)
앞서 설명한 condition coverage test와 decision coverage test를 합친 것이다.
즉, 조건문 내의 모든 문장이 true, false가 되는 케이스를 포함하도록, 그리고 모든 분기가 실행되도록 테스트 케이스를 작성한다.
다시 말해 컨디션 커버리지 테스트와 디시젼 커버리지 테스트를 모두 충족시켜야한다.
*decision/condition coverage는 decision coverage와 condition coverage를 포함한다.
• 다중조건 커버리지 검사(Multiple-condition Coverage Test or Compound condition coverage))
앞서 컨디션 커버리지 테스트에서는 각 조건을 독립적으로 검사했다. 즉 각 조건이 true와 false가 나오도록 테스트 케이스를 작성하였다. 즉 a와 b라는 조건이 있다면, 테스트 케이스에 a가 true, false인 경우, b가 true, false인 경우만 포함되면 되었다.
multiple-condition coverage에서는 각 조건의 모든 조합을 검사한다.
예1)
if(a >= 2 && b == 0)의 경우,
충족시켜야 할 경우
| 1 | a >=2, b =0 (True, True) |
| 2 | a >=2, b != 0 (True, False) |
| 3 | a < 2, b = 0 (False, True) |
| 4 | a <2, b != 0 (False, False) |
의 경우를 모두 포함하는 테스트 케이스를 작성하게 된다.
테스트 케이스 예시)
TC1 : a = 2, B = 0(True, True) _ Coverage: 1/4
TC2 : A = 1, B = 3(False, False) _ Coverage: 1/4
TC3 : A = 3, B = 1(True False) _ Coverage: 1/4
TC4 : A = 0, B = 0(False, True) _ Coverage: 1/4
총 coverage = 4/4
예2)
if(a >= 2 && b ==0 && c==1)
이 문장에서 역시 각 조건의 모든 경우의 수를 포함하도록 테스트케이스를 작성한다,
충족시켜야 할 경우
(True ==1, False == 0)
| 1 | a < 2, b != 0, c != 1 (000) |
| 2 | a < 2, b != 0, c == 1(001) |
| 3 | a < 2, b == 0, c != 1(010) |
| 4 | a < 2, b == 0, c == 1(011) |
| 5 | a >= 2, b != 0, c != 1(100) |
| 6 | a >= 2, b != 0, c == 1(101) |
| 7 | a >= 2, b == 0, c != 1(110) |
| 8 | a >= 2, b == 0, c == 1(111) |
즉, 조건의 개수가 n개라면 필요한 테스트 케이스의 개수는 2^n개이다.
*multiple-condition coverage는 decision/condition coverage를 항상 충족한다. 조건에 대한 모든 경우의 수를 포함하기 때문이다.
• Modified Condition Decision Coverage Test(MCDC)
앞서 multiple condition coverage test의 경우 2^n이라는 무척 많은 경우의 수를 포함하여야한다. 만약 조건이 100개라면 2^100이라는 어마무시한 숫자를 커버하여야 할 것이다.
이런 문제를 해결하기 위한 방법 중 하나가 바로 mcdc이다. mcdc는 n+1(최고)과 2*n(최악) 사이의 테스트 케이스 개수를 요구하게 된다.
mcdc란 각 조건이(각 조건의 변경이) 조건의 결과에 영향을 주는 것만을 선택하겠다는 것이다.
ex) if(a >=0 || b ==0)
이 경우 multiple condition coverage로 할 경우 조사해야할 케이스는 true-true, true-false, false-true, flase-false이다.
만약 mcdc로 할 경우, 결과에 영향을 주는 조건만을 사용하게 된다. 예를 들어 아래 표를 보면,
| 조건 a | 조건 b | 결과값 |
| true | true | true |
| true | false | true |
| false | true | true |
| false | false | false |
- 주황색 부분의 경우, a값이 true일 때, b의 값이 true가 false로 바뀌었으나 결과값에 영향을 미치지 못하고 있다.(true->true) 이 경우는 선택하지 않는다.
- 반면 하늘색 부분을 보면 a값이 false일 때, b값의 변화가 결과값에 영향을 끼친다(결과값: true->false)이 경우는 선택한다.
마찬가지로 초록색 부분을 보면, b값이 false일 때, a값의 변화가 결과값에 영향을 끼친다. 이 경우 역시 선택하게 된다.
이처럼 각 나머지 조건이 고정일 때, 한 조건의 변화가 변화가 결과값에 영향을 끼치는 경우만 검사하는 것이 mcdc이다.
화이트 박스 테스트 기법 요약
| Coverage | Covered Element |
| Statement Coverage | 모든 문장 |
| Decision Coverage | 모든 결정/분기 |
| Condition Coverage | 모든 조건 |
| Condition/Decision Coverage | 모든 분기와 조건 |
| MCDC | 각 조건이 결정에 영향을 끼치는 경우의 조건 |
| Multiple Condition Coverage | 모든 조건의 조합 |
블랙박스 테스트 VS 화이트박스 테스트
블랙박스 테스트와 화이트박스 테스트의 차이는 아래의 표와 같다.
| 블랙박스 테스트 | 화이트박스 테스트 | |
| 정의 | 테스터에게 디자인이나 구현등을 알리지 않는다. | 테스터에게 디자인, 구현 등을 알린다. |
| 테스트 케이스의 바탕 | 명세서 | 코드 |
| 구현에 대한 지식 | 필요하지 않음 | 필요 |
| 주로 적용되는 단계 | 시스템 테스팅 Acceptance Testing |
유닛 테스팅 Integration 테스팅 |
| 실행하는 사람 | (일반적으로) 개발자가 아닌 테스터 | (일반적으로) 개발자 |
블랙 박스 테스트는 누락된 요소를 검출하는 데에 용이하다
반면 화이트박스 테스트는 구현된 부분(코드)만을 대상으로 하기 때문에 누락된 요소를 검출할 수는 없다.
다만, 화이트박스 테스트는 코드, 문장 단위의 오류를 검출할 수 있으나 블랙박스 테스트는 그렇지 않다. 다만 오류가 발생했다는 것만을 알 뿐, 어디에서 오류가 발생했는지는 검출 할 수 없다.