테스트설계의 관점과 테스트기법

테스트설계의 관점과 테스트기법

테스트설계의 기본을 이해하기 위하여 필요한 중요관점은 다음과 같다.
① 보다 적은 테스트케이스로
② 보다 많은 버그를 찾을 수 있도록 하여
③ 테스트대상을 빠짐없이 실행한다.
이들을 충족하는 테스트설계를 하기 위하여 테스트기법을 활용할 필요가 있다.
여기서는 몇 가지 기본적인 테스트기법과 모델베이스 테스트기법의 개념을 소개한다. 테스트기법에 대하여 상세한 것을 알고 싶으면, Boris Beizer의 “Software Testing Techniques” 의 참조를 권한다.

“보다 적은 테스트케이스”로 테스트하기 위해 필요한 요점은 기본적으로 “동등클래스(Equivalence class)” 를 들 수 있다. 동등클래스는 테스트에 사용되는 입력 값이 같은 결과를 갖는 경우, 그 입력 값을 “동등” 하다고 부르는 데서 연유했다. 예를 들면, 한자리의 정수(整數) 2개를 합산하는 프로그램이 있다고 하자. “1+1” “1+2”…처럼 모든 정수의 패턴을 빠짐없이 테스트하려고 한다면, 9×9 =81 패턴의 테스트를 생각할 수 있다.
이 경우, 한자리 숫자와 한자리 숫자를 합하여 정수가 결과로서 나오게 되는 것뿐임으로, “1+1=2”가 나왔다면 논리적으로 “2+2”, “3+5”와 또 다른 것도 바른 결과가 나올 것이다. 즉 이 합산처리는 같은 결과를 갖는다고 할 수 있을 것이다. 이와 같이 모든 입력이 같은 결과를 갖는 경우, 그 중 대표 몇 개를 뽑아서 테스트한다면 81회나 테스트하지 않아도 된다고 생각할 수 있다. 이 같은 발상을 기초로 하여 같은 성질을 갖는 값을 모아서 취급 함으로서 보다 적은 테스트케이스로 테스트할 수 있게 되는 것이다.

“보다 많은 버그를 찾기” 위한 기본적인 기법으로는 “경계 테스트(Boundary Test)”를 들 수 있다. 위의 동등클래스중에서 대표를 뽑을 때 가장자리, 즉 경계 값을 뽑기 때문에 이렇게 부르게 되었다. 왜 경계 값을 대상으로 한 테스트로 많은 버그를 찾을 수 있는지 생각해 보자. 그 이유는 의외로 간단하다. 경계 값의 정의는 요건분석에서 프로그래밍에 이르기까지 어느 단계에서도 착각하거나 틀리기 쉽기 때문이다. 예를 들면, 부등호인 “>” 와 “=>” 를 잘못 정의하여 틀리는 경우는 쉽게 발견되는 것들이다. 만일, 어떤 숫자”이상”으로 되어 있는 것을 개발자가 “미만”으로 생각하여 코딩 했다면, 경계 테스트에서 간단히 버그로 발견되었을 것이다.
“부등호의 틀림”이란 단순한 착오정도는 테스트대상으로 생각하지 않았을 경우가 있었다면, 그런 테스트를 하지 않음으로서 생기는 결과는 후에 뼈아픈 상황을 불러올 수도 있다. 이런 불행을 예방하기 위한 테스트가 경계 테스트이다.

그러면 모델베이스(Model-based) 테스트설계에 대해 생각해 보자. “테스트대상을 빠짐없이 실행” 하기 위한 기법으로는 테스트대상의 요건(Specification)을 모두 나열하여 테스트누락을 방지하기 위한 “리스트 커버” 나 테스트요소를 행(行)과 열(列)의 표로 표현하여 같은 효과를 내려는 “매트릭스 커버” 가 있다. 또 단순한 방법으로는 표현하기 어려운 요건, 즉 모델화된 요건을 테스트하기 위해 사용되는 것이 모델을 베이스로 한 테스트기법이다. 설계서 등으로 테스트설계 전에 모델이 존재하고 있는 경우도 있고, 테스트를 설계하는 엔지니어가 설계서 등을 보고 테스트를 위해 모델링하는 하는 경우도 있을 것이다.

여기에 많이 사용되는 대표적인 기법으로 상태천이 테스트(State-transition Test)를 들 수 있다. 이것은 소프트웨어의 동작을 UML(Unified Modeling Language)에서의 상태 챠트(State charts)와 같은 모델로 표현하여 그 노드(Node)와 링크(Link)를 모두 대상으로 하여 테스트하는 것이다.
휴대전화의 예를 들어보자. 휴대전화는 수신대기 상태인 때에 전화가 걸려오면 착신상태가 되고 착신음이 울린다. “착신중에 착신음이 울림” 이란 상태(노드)는 “전화가 걸림” 이란 이벤트(링크)에 의해 인도된다. 그러나 통화중이라면 “전화가 걸림” 이란 이벤트(Event)가 있어도 착신음이 안나고 캐치상태가 된다.
이와 같이 같은 이벤트라도 앞의 상태에 따라 다음에 “천이(遷移)” 되는 상태가 달라진다. 따라서 “앞의 상태와 이벤트” 별로 인도되는 상태가 바른 결과가 되는지를 모두 테스트하지 않으면 안 된다. 모델을 사용하여 이를 빠짐없이 실행하려는 것이 “상태천이 테스트” 이다. 모델베이스 테스트에 대해서는 Microsoft사 Harry Robinson운영의 Web사이트(www.geocities.com / model_based_testing )를 참조하기 바란다.

그런데 사람이 일일이 테스트하는 것은 시간의 제약으로 무리한 경우가 있다. 실제로 상태천이 표(State-transition Table)에 따라 테스트를 설계하면 테스트항목이 수천이나 수만개가 되기도 한다. 그래서 테스트실행을 자동화하여 대량의 테스트케이스를 소화하거나 테스트케이스의 수를 논리적으로 줄이는 방법{직교표(直交表)가 이에 해당}을 취하기도 한다.
상태천이모델인 경우, 모델화 함으로서 이벤트와 액션 상태가 논리적으로 명확하게 된다. 또 논리적으로 정의되어 명백해짐으로 테스트케이스를 자동 생성할 수 있게 된다. 이에 입력데이터와 기대출력결과가 있으면 테스트의 자동실행도 가능하게 된다.(시판의 테스트 툴에도 이런 기능의 제품이 있다.)

다음으로 테스트케이스의 수를 줄이는 방법인데, “보다 많은 버그를 찾을 수 있는” 테스트케이스를 선택하여 우선적으로 실시하는 방법을 생각해 보자. 이를 위해서는 모델중에서 버그가 나올 것 같은 곳을 찾을 필요가 있다. “변칙 경로(Path)”라 불려지는 불규칙적인 패턴을 찾는 방법도 있다.
불규칙적인 패턴이란 바르게 처리되지 않고 오류로 되어 있을 때의 패턴(예외처리) 등을 말한다.
버그의 경향을 분석하여 어떤 잘못을 하기 쉬운가를 찾는 방법도 있다. 이것은 실제의 버그발생경향이 프로젝트에 따라 여러 가지라는 것에 기초를 두고 있다. 버그를 분석해 보면 특정부분(기능이나 모듈)에 버그가 집중되어 있는 경우가 많다. 그 원인은 여러 가지 있겠지만, 개발담당자가 자주 교체되었거나, 검토가 부족한 상태에서 코딩에 들어갔거나, 개발자 개인의 자질에 따른 경우 등인데 결국은 인적요인, 외적/내적요인 등으로 나누어진다.
버그의 발생원인에 경향이 있다면, 이를 분석해 보면 그 특정부분을 찾아낼 수 있다. 결국 버그가 많은 테스트대상의 약점을 집중적으로 테스트함으로서 효율적으로 버그를 찾아낼 수 있게 되는 것이다.

테스트케이스의 자동생성이나 자동실행을 하거나, 하지않거나 간에 모델베이스로 테스트설계를 한다는 것은 합리적으로 망라성(網羅性)을 확보하기 위한 필수적인 테크닉이라 할 수 있다. 예를 들면, 시스템테스트에서 행하여지는 업무흐름이나 이용자수순에 따른 테스트에서는 업무흐름을 Flow-chart 또는 UML에서의 Use case diagram이나 Activity diagram으로 표현하여 모델화한다. 모델화된 요건을 테스트하기 위해서는 그에 따른 테스트기법이 필요하게 된다.
이에는 제어경로(Control-path)테스트를 들 수 있다. 이는 프로그램의 동작경로를 흐름으로 표현한 것을 모두 실행하기 위한 테스트, 즉 코드를 모델화하여 테스트를 실행하는 것이라 할 수 있다.

모델베이스의 테스트기법을 이용하려면 테스트를 설계하는 엔지니어자신이 요건이나 설계서에 있는 모델을 이해하거나, 모델이 없다면 거기서 테스트에 필요한 모델을 도출하는 능력이 필요하게 된다. 빈약한 모델을 기초로 테스트를 설계하면 빈약한 테스트케이스밖에 나오지 않게 될 것이기 때문이다.
한편, 모델베이스 테스트설계에도 한계가 있다. 특히 성능이나 안전 등의 비 기능요건은 모델에서 표현되지 않아 대상이 되지 않는다. 따라서 사람이 아니면 안 되는 고도의 검증은 여기서도 남게 된다. 모델베이스로 테스트를 설계하여 테스트하는 엔지니어는 이제까지 보다 더 많은 모델링 기술이 요구될 것이다.

[주]STEN과 같은 역할을 하는 일본의 TEF(Testing Engineer’s Forum, www.swtest.jp)에서도 소프트웨어테스트 심포지움이 열리고 있고, 이 실행위원회에는 대학을 비롯하여 컴퓨터메이커, 관련기업 등에서 참가하고 있다. 위 글은 그 실행위원들의 토론모임에서 나온 화제(2004.12.3)를 공개(www.atmarkit.co.jp)한 것 중에서 골라 소개하는 것이다. 테스트설계의 관점을 이해하는데 도움이 될 것으로 생각된다. 
 
김증모