고정 헤더 영역
상세 컨텐츠
본문
반응형
이번에는 살짝~ 테스트 케이스 디자인 기법에 대해서 살펴보도록 하자.
예전에 잘 알려져 있지 않지만, 아마존에서 PDCA/Test by William Lewis를 산적이 있었다. 이 책은 특이하게도 링 바인드로 되어 있어서 책이라기 보다는 코스 교재에 가까운 출판물의 형태를 띠고 있다. 저자의 이력을 보니 또 특이하게도 KAIST에서 소프트웨어 테스팅 코스를 가르쳤던 경력이 있었다!
이 책의 뒷 부분은 각종 테스트 기법들을 나열하고 간략한 설명을 하고 있는데 (물론 1998년에 나온 것이라 현대의 많은 기법들은 소개되지 않고 있다.) 그중 상태 변이 테스팅(state transition testing)에 대한 예제를 가지고 나름 재구성해서 TC(Test Case)를 도출한 과정을 소개하고자 한다. (이 내용은 상태 변이 테스팅에 대한 심도있는 주제보다는 다른 내용이 주를 이룰 것이다. 상태 변이 테스팅에 대해서는 너무 방대한 주제라 간단치 않다. ^^)
(예제 프로그램의 상태 변이 테이블)
이것을 가지고 고민을 하던 중, Unique한 조합만을 산출하면서 실용적인 테스트 케이스 다운 케이스를 디자인하는 과정을 설명하겠다.
먼저, 예제 프로그램에 대한 설명을 하면, 예제 프로그램으로 부터 스펙을 거꾸로 도출하면 다음과 같다고 생각한다.
이제 이러한 스펙을 가지고 고민을 해보자.
먼저 가장 단순하게 생각할 수 있는 것은 각각의 조건에만 걸리는 입력 파일을 만들어 프로그램에 입력하는 것이다.
즉, 다음과 같은 파일을 만들고 돌리면 된다.
COUNTER7의 카운터를 증가시키는 레코드 한개 + COUNTER3의 카운터를 증가시키는 레코드 한개 + COUNTER1의 카운터를 증가시키는 레코드 한개 + EOF
따라서, 단 한개의 파일(테스트 케이스)만 있으면 테스트가 완료될 듯이 보인다!
하지만, 정말 그런가? 좀 더 고민을 해보자.
여기서 주의할 점은 레코드를 읽어들이자 마자 아무런 레코드가 없이 바로 EOF가 나오는 경우도 있다는 것이고, EOF가 끝을 나타내기 때문에 EOF - EOF의 파일은 의미가 없다는 것이다. 그래서 EOF와 짝을 이후는 조합은 "불가능"이라고 표시했다.
세어보면, 13개가 된다. (야호!!!)
위의 테이블을 트리 형태로 다시 표현해 보자. 그러면 이렇게 될 것이다.
그러면, 이제 13개의 파일을 만들어서 테스트 하면 될까? 물론 테스트 케이스는 13개면 될 것이다.
앞에서의 사고를 찬찬히 다시 따져보자.
이제 우리는 테스트 케이스의 수를 줄일 수 있는 (입력 파일의 개수를 줄이는) 힌트를 얻었다.
다음과 같이 단 두개의 조합을 조합 안에서의 짝은 그대로 두고 섞어 보자.
1) 먼저 각각의 두 쌍의 데이터를 그룹으로 모두 써 넣는다.
3) 이제 그룹의 모든 요소가 숫자로 되어 있는 것들만 서로 연결해 본다.
음, 매우 정신이 없다. 이것으로는 무언가 알아볼 수가 없다. 그렇다. 기법도 재료에 따라 달리 써야지 아무렇게나 갖다가 쓰면, 더 정신이 없는 것이다. 결국 이 테스팅에는 표 몇개의 결합과 중복 제거만 사용하면 되는 것이다. 이것은 상태 변이 다이어그램의 본래 속성에서도 드러나는데 STD(state transition diagram)은 "Testing in the LARGE"인 것이지, "Testing in the SMALL"은 아닌 것이다.
테스팅 기법에 대한 고찰은 여기서 마친다. 소프트웨어 테스팅에 매진하고 계시는 여러 분들의 건투를 빈다. ^_^
예전에 잘 알려져 있지 않지만, 아마존에서 PDCA/Test by William Lewis를 산적이 있었다. 이 책은 특이하게도 링 바인드로 되어 있어서 책이라기 보다는 코스 교재에 가까운 출판물의 형태를 띠고 있다. 저자의 이력을 보니 또 특이하게도 KAIST에서 소프트웨어 테스팅 코스를 가르쳤던 경력이 있었다!
이 책의 뒷 부분은 각종 테스트 기법들을 나열하고 간략한 설명을 하고 있는데 (물론 1998년에 나온 것이라 현대의 많은 기법들은 소개되지 않고 있다.) 그중 상태 변이 테스팅(state transition testing)에 대한 예제를 가지고 나름 재구성해서 TC(Test Case)를 도출한 과정을 소개하고자 한다. (이 내용은 상태 변이 테스팅에 대한 심도있는 주제보다는 다른 내용이 주를 이룰 것이다. 상태 변이 테스팅에 대해서는 너무 방대한 주제라 간단치 않다. ^^)
PROGRAM: FIELD-COUNT
Dowhile not EOF
read record
if FIELD_COUNTER > 7 then
increment COUNTER_7 by 1
else
if FIELD_COUNTER > 3 then
increment COUNTER_3 by 1
else
increment COUNTER_1 by 1
endif
endif
End_While
End
[파일에서 레코드를 읽어 조건 비교를 통해 카운터를 세는 프로그램 예제]
저자는 이 예제에 대한 상태 변이 테이블을 작성해 테스트하는 답을 게재해 놓았다.
|
Initial State |
Test Case (Transition) |
Final State |
|
COUNTER_7 = X1 |
1. EOF |
COUNTER_7 = X1 |
|
COUNTER_3 = X2 |
COUNTER_3 = X2 | |
|
COUNTER_1 = X3 |
COUNTER_1 = X3 | |
|
Exit Program | ||
|
COUNTER_7 = X1 |
2. Next Record with FIELD_COUNTER > 7 |
COUNTER_7 = (X1+1) |
|
COUNTER_3 = X2 |
COUNTER_3 = X2 | |
|
COUNTER_1 = X3 |
COUNTER_1 = X3 | |
|
Successful | ||
|
COUNTER_7 = X1 |
3. Next Record with FIELD_COUNTER < = 7 and FIELD_COUNTER >3 |
COUNTER_7 = X1 |
|
COUNTER_3 = X2 |
COUNTER_3 = (X2+1) | |
|
COUNTER_1 = X3 |
COUNTER_1 = X3 | |
|
Successful | ||
|
COUNTER_7 = X1 |
4. Next Record with FIELD_COUNTER < = 3 |
COUNTER_7 = X1 |
|
COUNTER_3 = X2 |
COUNTER_3 = X2 | |
|
COUNTER_1 = X3 |
COUNTER_1 = (X3+1) | |
|
Successful |
(예제 프로그램의 상태 변이 테이블)
이것을 가지고 고민을 하던 중, Unique한 조합만을 산출하면서 실용적인 테스트 케이스 다운 케이스를 디자인하는 과정을 설명하겠다.
먼저, 예제 프로그램에 대한 설명을 하면, 예제 프로그램으로 부터 스펙을 거꾸로 도출하면 다음과 같다고 생각한다.
- 이 프로그램의 입력은 순차적인 레코드를 담고 있는 파일이다.
- 파일의 끝에는 항상 더 이상의 레코드가 존재하지 않는다는 EOF(End Of File) 표시가 있다.
- 프로그램은 EOF를 만날때까지 루프를 돌며 순차적으로 한 개씩 레코드를 읽어 들인다. (이 스펙이 매우 중요하다!)
- 읽어들인 레코드가 IF 문의 조건에 맞는 경우 해당 카운터를 증가시킨다.
아울러, 입력인 파일의 구조는 다음과 같을 것이다.
이제 이러한 스펙을 가지고 고민을 해보자.
먼저 가장 단순하게 생각할 수 있는 것은 각각의 조건에만 걸리는 입력 파일을 만들어 프로그램에 입력하는 것이다.
즉, 다음과 같은 파일을 만들고 돌리면 된다.
COUNTER7의 카운터를 증가시키는 레코드 한개 + COUNTER3의 카운터를 증가시키는 레코드 한개 + COUNTER1의 카운터를 증가시키는 레코드 한개 + EOF
따라서, 단 한개의 파일(테스트 케이스)만 있으면 테스트가 완료될 듯이 보인다!
하지만, 정말 그런가? 좀 더 고민을 해보자.
- 일단 파일의 구조와 읽어들이는 로직상 인접한 두 개 레코드들의 조합이 존재한다.
- 레코드가 아무리 많더라도 인접해 있고 순차적으로 읽어들이기 때문에, IF 조건은 3개가 존재하지만 단 두개 레코드의 조합으로 설명할 수 있다. (!)
- 즉, 입력값으로 들어갈 수 있는 것들중 단 두개의 고유한 조합만을 찾으면 된다는 결론이 나온다.
결국, 다음과 같은 표에 의해서 나올 수 있는 모든 조합을 산출할 수 있다.
여기서 주의할 점은 레코드를 읽어들이자 마자 아무런 레코드가 없이 바로 EOF가 나오는 경우도 있다는 것이고, EOF가 끝을 나타내기 때문에 EOF - EOF의 파일은 의미가 없다는 것이다. 그래서 EOF와 짝을 이후는 조합은 "불가능"이라고 표시했다.
세어보면, 13개가 된다. (야호!!!)
위의 테이블을 트리 형태로 다시 표현해 보자. 그러면 이렇게 될 것이다.
그러면, 이제 13개의 파일을 만들어서 테스트 하면 될까? 물론 테스트 케이스는 13개면 될 것이다.
앞에서의 사고를 찬찬히 다시 따져보자.
레코드가 아무리 많더라도 인접해 있고 순차적으로 읽어들이기 때문에, IF 조건은 3개가 존재하지만 단 두개 레코드의 조합으로 설명할 수 있다. (!)그렇다! 레코드 단 두개의 고유한 조합만 가지고 있다면 입력 파일의 개수는 (다시 말하면 테스트 케이스의 개수는) 상관이 없다는 말이다.
이제 우리는 테스트 케이스의 수를 줄일 수 있는 (입력 파일의 개수를 줄이는) 힌트를 얻었다.
다음과 같이 단 두개의 조합을 조합 안에서의 짝은 그대로 두고 섞어 보자.
1) 먼저 각각의 두 쌍의 데이터를 그룹으로 모두 써 넣는다.
77, 73, 71, 7EOF
37, 33, 31, 3EOF
17, 13, 11, 1EOF
EOF
2) 각각을 연결이 가능한 대로 묶어 본다. (두개의 조합은 해치지 않으면서 겹치기 시도)
3) 이제 그룹의 모든 요소가 숫자로 되어 있는 것들만 서로 연결해 본다.
77, 73 => 773
71, 17 => 717
33, 31 => 331
37, 13 => 137
31, 11 => 311
331, 311 => 3311
3311, 137 => 331137
331137, 717 => 33113717
33113717, 773 => 3311371773
4) 전체 테스트 케이스를 도출한다.
TC1) 3311371773EOF (3EOF 포함됨) ER: COUNTER1은 3의 값. COUNTER3은 4의 값. COUNTER7은 3의 값을 가지고 종료함.
TC2) 331137177EOF (7EOF 포함됨) ER: COUNTER1은 3의 값. COUNTER3은 3의 값. COUNTER7은 3의 값을 가지고 종료함.
TC3) 3311371EOF (1EOF 포함됨) ER: COUNTER1은 3의 값. COUNTER3은 3의 값. COUNTER7은 1의 값을 가지고 종료함.
TC4) EOF 만으로 구성된 레코드 ER: COUNTER1, 3, 7 모두 0의 값을 가지고 종료함.
이렇게 총 4개의 테스트 케이스 (입력 파일)이 생성되었다! 앞의 13개와 비교하면 어떤가? ^^
또 이렇게 산출된 것은 또 앞의 13개에 비해서 장점이 존재한다.
1) 단 하나의 체크되는 레코드만 가진 파일이 아닌 조금은 더 긴 연속적인 레코드를 사용한다.
2) 케이스의 개수가 적다. (당연!)
3) 13개의 각각의 조건만 체크하는 테스트 케이스에 비해서 각각의 조건에 모두 걸리게 하거나 해서 누적 카운터 값이 조건마다 다르게 해서 누적 계산 (+1)에 대한 테스트도 함께 한다.
자, 이제 상태 변이에 대한 얘기를 하지 않았는데 위의 테스트 조건들을 상태 변이 다이어그램으로 그리면 다음과 같을 것이다. (상태 변이 다이어그램을 그리고 나서 테스트 케이스를 작성하는 것이 아닌, 좀 거꾸로 된 느낌은 있다. ^^)
음, 매우 정신이 없다. 이것으로는 무언가 알아볼 수가 없다. 그렇다. 기법도 재료에 따라 달리 써야지 아무렇게나 갖다가 쓰면, 더 정신이 없는 것이다. 결국 이 테스팅에는 표 몇개의 결합과 중복 제거만 사용하면 되는 것이다. 이것은 상태 변이 다이어그램의 본래 속성에서도 드러나는데 STD(state transition diagram)은 "Testing in the LARGE"인 것이지, "Testing in the SMALL"은 아닌 것이다.
테스팅 기법에 대한 고찰은 여기서 마친다. 소프트웨어 테스팅에 매진하고 계시는 여러 분들의 건투를 빈다. ^_^
반응형
댓글 영역