책 발췌 – 테스트케이스 도출을 위한 정보 소스

출처: 책 SOFTWARE TESTING AND QUALITY ASSURANCE Theory and Practice, KSHIRASAGAR NAIK, PRIYADARSHI TRIPATHY, 2008년, 18~20페이지

 

 

테스트 엔지니어가 테스트 케이스(시나리오)를 뽑아낼 수 있는 정보 소스로 어떤 것들이 있는지 설명한다.

 

---

 

 

테스트 케이스를 설계하는 것은 여전히 연구 커뮤니티와 실무자들의 주요 관심사이다. 소프트웨어 개발 프로세스가 요구사항 문서, 설계 문서, 소스 코드 같은 많은 양의 정보를 생성한다. 테스트 설계자는 보다 저렴한 비용으로 효과적인 테스트를 생성하기 위해 아래 정보 소스를 분석한다.

• 요구사항 명세와 기능 명세
• 소스 코드
• 입력 도메인과 출력 도메인
• 운영 프로파일
• 결함 모델

 

 

요구사항 명세서와 기능 명세서(Requirements and functional specifications)

소프트웨어 개발 프로세스는 사용자 요구(user needs)를 파악하는 것으로 시작된다. 시스템 개발 초기에 식별되는 사용자 요구의 성격과 양은 채택된 생명 주기 모델에 따라 달라진다. 예를 들어 폭포수(Waterfall) 모델에서는 요구사항 엔지니어가 대부분의 요구사항을 포착하려고 애쓰는 반면 XP나 Scrum 같은 애자일 소프트웨어 개발 모델에서는 초기에 오로지 몇 가지 요구사항만 식별한다. 어떤 생명 주기 모델이 채택되었든 간에 테스트 엔지니어는 프로그램이 충족하는 모든 요구사항을 고려해야 한다.

 

요구사항이 텍스트, 수식, 그림, 플로우차트 등이 혼합된 비정형적 형식으로 명세되었을 수 있다. 이러한 형식의 요구사항 명세는 모호할 수 있지만 고객이 이해하기 쉽다는 이점이 있다. 예를 들어, Bluetooth 명세는 다양한 Bluetooth 인터페이스 서브시스템이 어떻게 동작해야 하는지를 설명하는 약 1100페이지의 문서로 구성되며, 이 문서들은 수학 방정식, 상태 다이어그램, 표, 그림을 포함하는 일반 텍스트 형식으로 작성되어 있다. 한편 일부 시스템은 요구사항이 유스케이스, 엔터티-관계 다이어그램, 클래스 다이어그램 같은 형태로 명세되었을 수 있다. 때로는 시스템의 요구사항이 Z, SDL, Estelle, 유한 상태 머신 같은 정형화된 언어(formal language) 및 표기법(notation)으로 명세되기도 한다. 비정형 명세서와 정형 명세서 모두 테스트케이스의 주요 소스이다.

 

 

소스 코드

요구사항 명세가 시스템의 의도된 동작(intended behavior)을 기술하는 반면 소스 코드는 시스템의 실제 동작(actual behavior)을 기술한다. 상위 레벨의 가정과 제약 사항들이 구현에서는 구체적인 형태를 취하게 된다. 소프트웨어 설계자가 상세 설계서를 생성한다 할지라도 프로그래머가 시스템에 추가적인 세부 사항을 도입해야 할 수 있다. 예를 들어, 상세 설계서의 어떤 단계가 "배열 A를 정렬한다"일 때, 배열 정렬에 사용할 수 있는 특성이 다른 정렬 알고리즘이 다수 존재한다(반복형, 재귀형, 임시 배열 활용 등). 따라서 테스트 케이스가 프로그램을 기반으로 설계되어야 한다.

 

 

입력 도메인과 출력 도메인(Input and output domains)

프로그램의 입력 도메인에 있는 일부 값은 특별한 의미를 가지므로 별도로 다루어야 한다. 이를 설명하기 위해 계승 함수(factorial function)를 살펴보자. 음이 아닌 정수 n의 계승은 다음과 같이 계산된다.

 

factorial(0) = 1;

factorial(1) = 1;

factorial(n) = n * factorial(n-1);

 

어떤 프로그래머가 n = 0인 특별한 경우를 고려하지 못하고 계승 함수를 다음과 같이 잘못 구현할 수 있다.

 

factorial(n) = 1 * 2 * ... * n;

 

위의 잘못된 구현이 모든 양수 값 n에 대해서는 올바른 결과를 내지만 n = 0일 때 실패한다.

 

때때로 일부 출력 값도 특별한 의미를 가질 수 있으므로 그 특별한 값을 생성하는 모든 가능한 원인에 대해 프로그램을 테스트해야 한다. 위의 예에서 출력 값 1은 특별한 의미를 가진다. 그것이 (i) 계승 함수에 의해 계산되는 최소값이고 (ii) 두 개의 다른 입력에 대해 생성되는 유일한 출력 값이다.

 

 

운영 프로파일(Operational profile)

운영 프로필은 어떻게 시스템이 사용되는지에 대한 정량적 특성으로, 테스트 엔지니어가 시스템 사용(system usage) 샘플을 통해 테스트 케이스(입력)를 선택하도록 가이드하기 위해 만들어졌다. ‘운영 프로필(operational profiles)’ 또는 ‘사용 프로필(usage profiles)’이라는 개념은 IBM의 Mills et al.(클린룸 소프트웨어 공학 연구 그룹)과 AT&T Bell 연구소의 Musa가 더 높은 신뢰성을 가진 소프트웨어 시스템 개발을 돕기 위해 각각 개발하였다. 이것의 아이디어는 관찰된 테스트 결과로부터 소프트웨어가 실제로 사용될 때의 미래 소프트웨어 신뢰성을 추론하는 것이다. 이를 위해서 테스트 입력이 실제 운영 상에서 발생하는 확률 분포 또는 프로필에 따라 할당된다. 테스트 엔지니어가 시스템을 작동하기 위해 테스트 케이스를 선택하는 방식이 실제 사용자가 시스템을 작동하는 방식과 크게 다를 수 있다. 그러나 시스템의 신뢰성을 정확하게 추정하기 위해서는 실제 현장에서 사용되는 것과 동일한 방식으로 시스템을 테스트해야 한다. 예를 들면 이 개념이 테스트 케이스 선택을 위해 웹 서버로부터 사용자 세션 데이터(user session data)를 수집하는 웹 애플리케이션 테스트에서 사용된다.

 

예시) 아래는 표 형식과 그래프 형식의 두 가지 방식으로 표현된 도서관정보시스템의 운영 프로파일을 보여준다.

표 15.1 도서관정보시스템 운영 프로파일 예

 

그림 15.2 도서관정보시스템 운영 프로파일의 그래픽 표현

 

운영 프로파일의 개념은 테스트 엔지니어가 테스트 케이스를 선택하는 것을 안내하기 위해 만들어졌다. 이상적으로는 하나의 오퍼레이션을 테스트하는 데 적어도 하나의 테스트 케이스가 선택되어야 하며, 모든 오퍼레이션이 테스팅 동안 커버되어야 한다. 소프트웨어 신뢰성이 실패 강도(failure intensity)의 개념과 매우 밀접하게 연관되어 있기 때문에 더 자주 사용되는 오퍼레이션을 먼저 테스트함으로써 주어진 시간 내에 더 나은 신뢰성을 가진 소프트웨어 시스템을 생성할 수 있다. 운영 프로파일은 얼마나 많이 테스트할지, 소프트웨어 시스템의 어느 부분에 더 많은 주의를 기울여야 하는지에 대한 결정을 내리는 데 사용될 수 있다.

 

 

결함 모델(Fault model)

과거에 발생한 결함은 새로운 테스트 케이스를 설계할 때 훌륭한 정보 소스가 된다. 알려진 오류는 초기화 결함, 논리 결함, 인터페이스 결함 같은 다양한 클래스로 분류되어 저장소에 저장된다. 테스트 엔지니어는 테스트를 설계할 때 이러한 데이터를 사용하여 특정 클래스의 결함이 프로그램에 상주하지 않도록 확인할 수 있다.

 

결함 기반 테스트에는 에러 추측(error guessing), 에러 심기(error seeding), 뮤테이션 분석(mutation analysis)의 세 가지 유형이 있다. 에러 추측에서 테스트 엔지니어는 자신의 경험을 적용하여 (i) 어디에 어떤 종류의 결함이 존재할 수 있는지 추측하고 (ii) 그러한 유형의 결함을 구체적으로 노출하기 위한 테스트를 설계한다. 에러 심기에서는 기 알려진 결함을 프로그램에 주입하고, 여기에 테스트 스위트(test suite)를 실행하여 그 효과성을 평가한다. 즉, 심어진 결함을 찾아내는 테스트 스위트가 다른 결함도 발견할 가능성이 있다고 가정한다. 뮤테이션 분석은 에러 심기와 유사하지만 테스트 스위트의 결함 발견 능력을 판단하기 위해 프로그램 명령문의 뮤테이션(돌연변이)이 만들어진다는 점이 다르다. 테스트 케이스가 그러한 결함을 드러낼 수 없는 경우, 테스트 엔지니어는 그것을 드러내기 위한 추가적인 테스트 케이스를 지정한다.

 

뮤테이션 테스팅은 결함 시뮬레이션(fault simulation)이라는 아이디어를 기반으로 하는 반면 에러 심기는 결함 주입(fault injection)이라는 아이디어를 기반으로 한다. 에러 주입 접근법에서는 에러가 프로그램에 삽입되고 이렇게 삽입된 에러가 실제로 프로그램을 올바르지 않게 만들었음을 확인(어써션)하는 오라클이 가용하다. 반면에 결함 시뮬레이션에서 프로그램 수정(변이)가 반드시 올바르지 않은 프로그램으로 이어진다는 보장이 없다. 결함 시뮬레이션에서는 원래 프로그램 버전이 잘못된 것이고 이를 수정한 것이 오히려 올바른(정확한) 프로그램인 경우가 있을 수 있다.