프로그램을 잘 설계 개발하는것도 중요하지만 완성된 프로그램이 목적대로 잘 수행하는지 테스트해보는 것도 중요하다.

대부분의 사고는 충분한 테스트가 되지 않은 상태에서 릴리즈되고 숨어있던 사고가 터진다.

하지만 당장 개발하기도 빠듯한데 테스트에 시간을 투자하기가 매우 부담스러운것은 사실이다. 제한된 시간에 효과적으로 테스트하기 위해 고민을 많이 하신 분들의 테스트 기법중 몇가지를 나열한다.


명세기반 기법(Specification based)

강한 동등 분할 : 입력가능한 경우의 수에 대한 모든 조합을 테스트. input 변수가 5개이고 각각 3,5,4,2,10 가지의 입력변수를 가질경우 3 X 5 X 4 X 2 X 10 = 1200가지 경우의 수를 테스트 해보는 방법. 모든 경우의 수에 대한 테스트가 가능하지만 경우의 수가 엄청나게 많아질 수가 있다. 


약한 동등 분할 : 입력가능한 경우의 수 중 가장 많은것 기준으로 조합 테스트. input 변수가 5개 이고 각각 3,5,4,2,10 가지의 입력변수를 가질경우 가장 많은 10개 기준으로 테스트해보는 방법. 10개보다 적은 3,5,4,2 가지의 변수는 10개 이내에서 반복하여 input표를 채운다. 적은 횟수의 테스트가 가능하지만 테스트 누락되는 경우의 수가 존재함


조합테스팅(Pair wise Testing) : 강한 동등 분할과 약한 동등 분할의 중간 방법으로 테스트를 하는데 필요한 값들이 다른 파라미터의 값과 최소한 한번씩은 조합을 이룬다. 조합은 약한 동등 분할과 흡사하게 시작하지만 다른 입력파라미터와의 짝이 겹치지 않게 바꿔주는데 다른 파라미터의 값과 최소한번씩 조합이 없을경우 횟수를 늘려서 약한 동등 분할보다는 테스트횟수가 늘어난다. 하지만 모든 경우의 수를 전부 테스트하지는 않기 때문에 강한 동등 분할보다는 적은 횟수를 테스트한다. 테스트 파라미터 조합을 만드는 것이 어렵기 때문에 종종 tool을 활용한다.


경계값 분석 : 범위값을 테스트하는데 범위중간의 값보다 경계의 값을 위주로 테스트한다. 즉 이상, 초과, 이하, 미만과 같이 >, >=, <, <= 처럼 의미가 모호할 수 있는 부분을 테스트한다. 입력 파라미터에 경계에 해당하는 값을 넣어 테스트해 본다. 사람들의 대화에서 흔히 전달오류가 발생하는 부분을 확인하는 기법이다.


결정테이블(decision table) : 테스트수행에 필요한 입력의 조합을 구하기 위해 사용한다. 결정 명세를 분석하여 원인과 효과를 활용하여 하나의 테이블에 작성한다. input 파라미터가 3개이고 각각 boolean 타입을 가지고 있을 경우 2^3 = 8가지 조합이 나오는데 이에 따른 원인(cause)에 의미가 없는 효과(effect)는 테스트해 볼 필요가 없기 때문에 8가지 조합에서 필요없는 테스트를 제외하면 더 적은 수의 테스트만 할 수 있다.  


상태전이 기법(state transition testing) : 이벤트, 액활동상태상태전이 사이의 관계를 검증하는 테스팅 기법이다시스템의 소프트웨어에서 상태기반 행위가 설계 내용과 일치하는지 검증하는 것이다단순 상태전이도(State transition Diagram)를 도식화하고 스위치레벨(Switch Level)이 얼마나 되는지 확인한다. 주로 임베디드에서 많이 사용하는 기법이나 일반 비즈니스 시스템에서도 화면끼리의 영향을 주는데 파악이 용이하여 활용되고 있다.


구조기반 기법(Structure based)

제어흐름 테스트(Control flow test) : 프로세스 흐름을 도식화한 flow chart 에 따라 모든 flow 경로에 대한 프로그램이 수행하도록 하여 프로그램이 설계된 대로 동작하는지 확인하는 방법이다.


데이터 흐름 테스트(Data flow test) : 제어흐름 뿐 아니라 데이터의 사용도 에러를 유발할 수 있다는 가능성에서 나타난다. 데이터는 정의되거나 사용되거나 삭제된다. 또한 서브루틴에 들어가거나 빠져나온다. 이런 데이터의 흐름조합에 따라 오류가 발생할 수 있는 패턴을 점검한다.


최소비교 테스트(Elementary comparison test)


경험기반 기법(Experience based)

에러추정 기법(Error guessing) : 경험 많은 테스터가 프로그램의 어느 부분에 에러가 많이 나는지 예측하고 테스트 케이스를 도출한다.

+ Recent posts