책 요약 – FSM 모델을 활용한 테스트 케이스 생성 by NAIK

출처: SOFTWARE TESTING AND QUALITY ASSURANCE Theory and Practice, KSHIRASAGAR NAIK, PRIYADARSHI TRIPATHY, 2008년, 10장 Test Generation from FSM Models, 265~273페이지

 

이 책의 10장은 유한 상태 머신(FSM: Finite-State Machine) 모델에서 테스트 케이스를 도출하는 방법을 설명한다.

 

---

 

10.1 상태 지향 모델(STATE-ORIENTED MODEL)

소프트웨어 시스템은 상태의 영향을 받지 않는 ‘stateless’ 시스템과 상태에 따라 다음 방향이 정해지는 ‘state-oriented’ 시스템의 두 그룹으로 크게 분류할 수 있다. Stateless 시스템의 액션은 앞서 시스템에 들어온 입력에 의존하지 않는다. 이런 시스템의 예로 컴파일러가 있다(프로그램 컴파일 결과가 이전에 컴파일된 프로그램에 의존하지 않음). 상태 지향 시스템은 지금까지 시스템이 받은 입력 시퀀스를 ‘상태’의 형태로 기억하며, 현재 입력에 대한 시스템의 응답이 과거 입력이 어땠는지에 따라 달라진다. 전화 스위칭 시스템은 상태 지향 시스템의 한 예이다.

 

상태 지향 시스템은 제어 부분(control portion)과 데이터 부분(data portion)을 가진다. 제어 부분은 환경과의 인터액션 시퀀스를 명시하고 데이터 부분은 처리 및 저장할 데이터를 명시한다. 그림 10.1에서 볼 수 있듯이 시스템의 특성에 따라 데이터가 지배적인 시스템이거나, 제어가 지배적인 시스템이거나, 또는 데이터와 제어가 균형 있게 혼합된 시스템 일 수 있다.

 

그림 10.1 소프트웨어 시스템의 스펙트럼

 

데이터 위주 시스템에서 시스템은 사용자 요청(user requests)을 처리하는 데 대부분의 시간을 소비하며, 사용자와의 인터액션 시퀀스는 매우 간단하다. 따라서 그림 10.2에 묘사되었듯이 복잡한 데이터 처리에 비해 제어부가 단순하다. 웹 브라우징 애플리케이션은 데이터 위주 시스템의 한 예이다. 이 시스템은 http 리퀘스트를 만들어 원격 데이터에 액세스하고 이를 화면에 보이기 위한 포맷팅을 하는 데 많은 시간을 소비한다. 이 시스템은 사용자로부터 입력되는 각 명령에 응답하며, 시스템이 반드시 기억해야 하는 상태 정보는 그다지 많지 않다. 상태 정보가 필요한 경우는 백(Back) 오퍼레이션을 수행할 때 정도이다. 또한 웹 브라우징은 시간에 종속적인 애플리케이션이 아니다(기저 TCP/IP 오퍼레이션에 대한 종속성은 제외하고).

그림 10.2 데이터 위주 시스템(Data-dominated systems)

 

제어 위주 시스템에서 시스템은 사용자와 복잡한 인터액션(즉, 여러 시간 종속적이고 긴 시퀀스의 인터액션)을 수행하지만 처리되는 데이터의 양은 상대적으로 적다. 따라서 그림 10.3과 같이 제어 부분은 큰 반면 데이터 처리 기능은 매우 작다. 전화 스위칭 시스템은 제어 위주 시스템의 한 예이다.

그림 10.3 제어 위주 시스템(Control-dominated systems)

 

소프트웨어 시스템의 제어 부분은 시스템과 그 사용자(또는 환경) 간의 인터액션을 표현한 유한 상태 머신(FSM: finite-state machine)으로 모델링될 수 있다. 예를 들어 그림 10.4는 이중 부팅 랩톱 컴퓨터를 사용하는 사용자와의 인터액션을 모델링한 것이다. 처음에 랩톱은 OFF 상태이다. 사용자가 전원 ON 버튼을 누르면 시스템은 BOOT 상태로 바뀌고 여기서 LINUX 또는 WINDOWS의 두 입력 중 하나를 수신한다. 사용자 입력이 LINUX인 경우 시스템은 리녹스 운영체제로 부팅하고 LINUX 상태로 이동한다. 반면 WINDOWS 입력이면 시스템을 윈도우즈 운영체제로 부팅하고 WIN 상태로 이동한다. 랩톱에서 실행되는 것이 리녹스인지 또는 윈도우즈인지 여부에 관계없이 사용자는 머신을 대기 상태로 만들 수 있다. 리녹스 모드의 대기 상태는 LSTND이고 윈도우즈 모드의 대기 상태는 WSTND이다. 컴퓨터는 WAKEUP 입력을 사용하여 대기 상태 LSTND 또는 WSTND에서 작동 상태인 LINUX 또는 WIN으로 각각 되돌릴 수 있다. 랩탑은 RESTART 입력을 사용하여 LINUX와 WIN 상태 간을 이동할 수 있다. 랩톱은 LINUX 또는 WIN 상태에 있는 동안 SHUTDOWN 입력을 사용하여 종료할 수 있다. 전원 버튼을 사용하여 랩톱을 OFF 상태로 전환할 수도 있지만 그림 10.4에서는 이를 포함하지 않는다.

 

그림 10.4 이중 부팅 랩톱 컴퓨터의 FSM 모델

 

시스템의 외부 동작(즉, 시스템과 그 환경과의 인터액션)에 대한 FSM 모델은 시스템에 들어오는 입력 시퀀스와 시스템에서 나가는 예상 출력을 기술하며, 이러한 모델은 테스트 케이스의 주요 소스가 된다.

 

 

10.2 제어 및 관찰 지점(PCO: POINTS OF CONTROL AND OBSERVATION)

제어 및 관찰 지점(PCO)은 시스템과 그 사용자 간의 지정된 인터액션 지점(즉, 시스템이 사용자로부터 입력을 수신하고 사용자를 위해 출력을 생성하는 지점)을 나타낸다. 여기서 사용자라는 용어는 인간 사용자뿐만 아니라 타겟 시스템과 인터액션하는 외부 소프트웨어 및 하드웨어 시스템을 포함하는 넓은 의미로 사용된다.

 

예시)

사용자 간 연결을 제공하는 전화 스위치 PBX를 제어하는 소프트웨어 시스템이 있다고 가정하자. PCO의 개념을 설명하기 위해 기본 전화기의 사용자 인터페이스 세부 정보를 그림 10.6에 나타내고, 이를 표 10.1에서 요약하였다.

 

그림 10.6 전화기 상의 PCO

 

표 10.1 전화 PBX를 테스팅하기 위한 PCO

전화기와 같은 간단한 장치의 경우에도 사용자가 스위칭 소프트웨어와 인터액션하는 데 쓰이는 5개의 고유한 PCO가 있음을 알 수 있다. 현실에서 사용자는 이러한 개별 PCO를 통해 스위칭 소프트웨어와 인터액션하며, 자동화된 테스트 실행 시스템은 이러한 개별 PCO를 반드시 인식해야 한다. 여기서는 FSM 모델에서 테스트 케이스 생성하는 것에 대한 논의를 명확하고 간결하게 하기 위해서 더 적은 수의 PCO를 사용한다. 그림 10.7과 같이 로컬 전화의 모든 PCO는 LP로 지정하고 원격 전화의 모든 PCO는 RP로 지정한다.

 

그림 10.7 PBX

 

 

10.3 유한 상태 머신(FINITE-STATE MACHINE)

유한 상태 머신 M은 아래의 튜플로 정의된다.

 

M = <S, I, O, s₀, δ, λ> 

• S는 상태들의 집합
• I는 입력들의 집합
• O는 출력들의 집합
• s₀는 초기 상태
• δ : S × I → S는 다음 상태 함수
• λ : S × I → O는 출력 함수

 

시스템을 테스트할 때 ‘관찰(observation)’ 개념의 중요성 때문에 입력 및 출력과 관련된 다음 사항에 유의해야 한다.

• 일련의 PCO를 명시적으로 지정함으로써 관찰되는 입력 및 출력을 식별한다. 각 상태 전이(state transition)에 대해 입력이 발생하고 출력이 관찰되는 지점인 PCO를 지정한다.
• 한 상태의 단일 입력에 대해 서로 다른 PCO에서 발생하는 많은 출력이 있을 수 있다.

 

그림 10.8은 사용자와 PBX 시스템 간의 인터액션에 대한 FSM 명세이다. 이 FSM에는 9개의 개별 상태가 존재하며, 표 10.2에서 이를 설명하고 있다. FSM의 초기 상태는 OH이며, 그림에서 이 상태가 두 번 나타나는 이유는 상태 LON, RON 및 IAF에서 맨 위에 있는 OH로 전이 선을 그려야 하는 것을 피하기 위해서이다. LP와 RP라는 두 개의 추상 PCO가 사용되었는 데, 발신자(caller)가 사용하는 로컬 전화와 수신자(callee)를 나타내는 원격 전화를 각각 의미한다.

그림 10.8 PBX의 FSM 모델

 

표 10.2 그림 10.8의 FSM에서 상태 집합

 

표 10.3 그림 10.8의 FSM에서 입력 집합과 출력 집합

 

이 FSM은 5개의 고유한 입력 기호를 받아들인다. NOI는 사용자의 활동이 없음을 나타낸다(즉, 사용자가 특정 상태로의 입력을 제공하지 않음). 이렇게 명시적 NOI의 개념을 도입한 이유는 타임아웃과 같은 내부 이벤트를 도입하지 않고 시스템의 동작을 설명하기 원했기 때문이다. 출력 기호는 7개가 존재하며, 그 중 하나가 don't care 출력(출력이 없거나 사용자가 무시하는 임의 출력을 의미)이다.

 

상태 전이의 입력 및 출력 부분은 다음과 같이 표시한다.

PCO_i : a/PCO_j : b

여기서 입력 a는 PCO_i에서 발생하고 출력 b는 PCO_j에서 발생한다. 상태 전이가 다수의 출력을 생성하는 경우 아래 표기법을 사용한다.

PCO_i : a/{PCO_j : b, PCO_k : c}

여기서 입력 a는 PCO_i에서 발생하고 출력 b는 PCO_j에서 발생하고 출력 c는 PCO_k에서 발생한다.

 

하나의 완전한 상태 전이는 다음 신택스를 사용하여 표현한다. 

<현재 상태, 입력, 출력, 다음 상태> 또는 <현재 상태, 입력/출력, 다음 상태>

 

예를 들어 그림 10.8에 있는 상태 전이 <OH, LP: OFH, LP: DT, AD>는 FSM이 상태 OH에 있고 포트(PCO) LP에서 입력 OFH(오프 후크)를 수신하면 동일한 포트 LP에서 출력 DT(발신음)를 생성하고 상태 AD로 전이되는 것을 의미한다.

 

10.4 FSM에서 테스트 생성

시스템 요구사항을 표현한 FSM 모델을 M이라 하고 이것의 구현을 I_M이라고 했을 때, 직관적인 테스팅 작업은 구현 I_M이 모델 M에서 규정한 대로 동작하는지 확인하는 것이다. 이렇게 구현이 그 명세를 준수하는지 확인하는 테스트 프로세스를 ‘적합성 테스트(conformance testing)’라고 한다. 적합성 테스트의 기본 아이디어를 다음과 같이 요약할 수 있다.

 

• 모델 M에서 상태 전이 시퀀스를 얻는다.
• 각 상태 전이 시퀀스를 테스트 시퀀스로 전환한다.
• 일련의 테스트 시퀀스로 I_M을 테스트하고 I_M이 상응하는 상태 전이 시퀀스를 보유하고 있는지 여부를 관찰한다.
• M과 I_M의 일치(conformanc) 여부는 M에서 충분한 수의 상태 전이 시퀀스를 신중하게 선택함으로써 확인할 수 있다.