페이퍼요약 - TTCN-3 분산 시스템 블랙박스 테스팅을 위한 신규 테스트 명세 언어 by Grabowski

제목: TTCN-3 분산 시스템 블랙박스 테스팅을 위한 신규 테스트 명세 언어(TTCN-3 - A new Test Specification Language for Black-Box Testing of Distributed Systems)

저자: Jens Grabowski, 독일

문서유형: 학계 페이퍼(총 14페이지)

 

OSI 프로토콜 적합성 테스팅을 위한 테스트 케이스 명세 언어인 TTCN을 재설계한 TTCN-3에 대하여 소개한 자료

---

TTCN(Tree and Tabular Combined Notation)

• 프로토콜 적합성 테스팅(conformance testing)의 테스트 케이스 명세를 위한 잘 확립된 표기법(텍스트 기반 명세 언어)
• 적합성 테스팅 표준인 IS-9646: OSI Conformance Testing Methodology and Framework(CTMF)의 Part 3에 정의 및 표준화되어 있음
• CTMF와 TTCN 테스트 케이스는 OSI 프로토콜의 기능 동작 측면 블랙박스 테스팅 수행에 사용되며 또한 OSI 계층형 구성(layering scheme)을 따르는 다른 종류의 시스템에도 적용된다. 예) ISDN, ATM 등

TTCN-3

• 멀티미디어, 홈뱅킹, 화상회의 같은 선진 애플리케이션과 함께 새로운 소프트웨어 아키텍쳐(예, ODP, CORBA, TINA, DCE)가 등장하면서 테스팅에 대한 요구사항이 변화함. 이런 변화에 부합하기 위해 CTMF와 TTCN의 확장이 요구됨
• 1998년 10월부터 유럽 전기통신 표준 협회 ETSI(European Telecommunications Standards Institute)가 현대적이고 강력한 테스트 명세 언어(test specification language)를 목표로 TTCN의 세 번째 개정판인 TTCN-3를 개발 중(2000년 10월 완료 예정)
• TTCN-3는 일반 프로그래밍 언어와 유사한 모습이며 테스트에 고유한 확장 부분을 가진다. 예) 테스트 판정 핸들링, IUT의 반응을 예상 반응과 비교하기 위한 매칭 메커니즘, 타이머 핸들링, 테스트 시스템 프로세스 분산 등
• TTCN-3는 동기식(synchronous) 및 비동기식(asynchronous) 통신과 모니터링을 지원하며, 통신 분야(telecommunications area)에서는 ASN.1과 결합하여 사용될 수 있다.

TTCN-3 언어 개요

TTCN-3 표현 형식(presentation formats)

• TTCN-3의 다양한 표현 형식은 TTCN-3 명세에 대한 애플리케이션 위주의 뷰를 사용자에게 제공한다.
• 애플리케이션 분야에 따라 TTCN-3나 또는 특정 표현 형식이 테스트 케이스를 명세하고 가시화하기 위해 사용된다.
• TTCN-3 표준과 함께 두 개의 특수한 표현 형식이 표준화됨. 표 형식(tabular format)은 기존 TTCN 버전들의 적합성 테스팅 뷰를 지원하고, MSC/UML 기반 표현 형식은 MSC/SDL과 MSC/UML 위주의 테스팅 뷰를 제공한다.

[TTCN-3에 대한 사용자의 뷰]

애플리케이션 전용 애트리뷰트(Application specific attributes)

• 대개 애플리케이션을 테스팅 하려면 해당 애플리케이션 고유의 정보를 필요로 하는데, TTCN-3 언어 요소(language elements)와 연관된 애트리뷰트를 정의하여 이런 정보를 추가하는 것이 가능하다.
• 아래 예는 프로토콜 적합성 테스팅을 위한 TTCN-3 테스트 스위트에서 MyPDU라는 record를 정의한 것으로 애트리뷰트들은 with 구문을 통해 MyPDU와 연관된다. 애트리뷰트 display는 MyPDU가 PDU(Protocol Data Unit)임을 나타내며, encode는 MyPDU 인스턴스 인코딩이 ASN.1 BER(Basic Encoding Rules)에 따름을 나타낸다.
• 애트리뷰트 값 ‘PDU’와 ‘BER’은 해당 애플리케이션에 고유하며 프로토콜 적합성 테스팅의 영역 밖에서는 거의 사용되지 않는다.

[애트리뷰트 정의 예]

TTCN-3 모듈(modules)

• 모듈은 TTCN-3의 최상위 레벨 단위이다. 하나의 모듈을 여러 서브모듈로 나눌 수는 없지만 타 모듈들의 모듈정의(definition)를 import 하는 것은 가능하다. 또한 모듈이 여러 다른 테스트 환경에 적응이 용이하도록 패러미터화 될 수 있다.
• 아래 예처럼 TTCN-3 모듈은 ‘모듈 정의 부분(module definitions part)’과 ‘모듈 통제 부분(module control part)’으로 구성된다. 모듈 정의 부분에서는 TTCN-3 모듈(예, 테스트 컴포넌트, 통신 포트, 데이터 타입, 상수, 테스트 데이터 템플리트 등)의 최상위 레벨 정의를 명세 한다.
• 모듈 통제 부분은 C 또는 C++ 프로그램의 main 함수의 역할과 유사하며 모듈 정의 부분에 명세된(또는 import 된) 테스트 케이스를 실행한다. 통제 부분은 필수적이지 않으며 통제 부분이 없는 TTCN-3 모듈은 테스트 라이브러리로 간주된다. 

[TTCN-3 모듈 구조 예]

데이터 타입, 메시지, 메시지 템플리트

• TTCN-3는 사전 정의된 여러 데이터 타입을 포함하고 있다(대부분이 타 프로그래밍 언어에서도 사용되는 잘 알려진 것들). TTCN에 고유한 타입인 verdicttype은 그 값으로 none, pass, inconclusive, fail, error를 가진다(테스트 결과 판정 값).
• TTCN-3는 메시지 교환을 통한 비동기식 통신을 지원하지만 명백한 메시지 데이터 타입이 없다. 즉, TTCN-3에서는 어떤 타입의 어떤 값이든 메시지로 사용될 수 있고, 테스트 구성(test configuration)에서 허용하면 이런 메시지가 IUT나 타 테스트 컴포넌트로 전송될 수 있다. 대개의 경우 메시지는 record 타입으로 정의된다.
• TTCN-3에서 템플리트는 단일 테스트 값이나 테스트 값 전체 집합을 위한 placeholder(차후 대체 될 다른 정보를 대신하는 심볼)이다. 통신 오퍼레이션에 사용된 템플리트는 전송될 값을 명세하거나 수신된 메시지가 예상한 값을 가졌는지 체크한다. 템플리트 명세를 용이하게 하기 위해 TTCN-3는 여러 매칭 방법(matching mechanisms)을 제공한다.

[템플리트 정의와 사용 예]

프로시져 시그니쳐(Procedure signatures)

• 프로시져 시그니쳐는 동기식 통신에 필요하다.
• 프로시져는 IUT에서 invoke 되거나(즉, 테스트 시스템이 call을 수행) 또는 테스트 시스템에서 invoke 된다(즉, IUT가 call을 수행). 양쪽 경우 모두 완전한 프로시져 시그니쳐가 TTCN-3 모듈에 정의되어야만 한다.
• 시그니쳐 정의 내에서 패러미터 목록은 패러미터 식별자, 패러미터 타입과 방향(in, out, inout)을 포함할 수 있다. 

[시그니쳐 정의 예]

테스트 구성(Test configurations)

• 테스트 구성은 잘 정의된 통신 포트와 테스트 시스템 인터페이스(테스트 시스템의 경계를 분명하게 정의)를 가진 상호연결된 테스트 컴포넌트의 집합으로 구성된다. TTCN-3는 병행하는(concurrent) 여러 테스트 구성의 명세를 허용한다.
• 테스트 구성 각각에는 하나의 MTC(Main Test Component)가 있으며 그 외 모든 다른 테스트 컴포넌트는 PTC(Parallel Test Component)라 불린다.
• MTC는 각 테스트 케이스 실행의 시작 시점에 자동으로 생성되며 테스트 케이스 바디에 정의된 동작이 이 컴포넌트에서 실행된다. PTC는 create와 stop 오퍼레이션 사용을 통해 테스트 케이스 실행 동안에 동적으로 생성되고 중단될 수 있다.

[전형적인 TTCN-3 테스트 구성의 개념 뷰]

테스트 케이스(Test cases)

• IUT가 테스트를 통과하는지 아닌지 판단하기 위해 실행되는 테스트 케이스는 모듈 정의 부분에서 정의되고 모듈 통제 부분에서 호출된다.
• 각 테스트 케이스는 테스트 판정 값(즉, none, pass, fail, inconclusive, error)을 반환한다.
• 아래 예에서 정의된 MyTestCase라는 테스트 케이스는 integer 타입의 MyPar라는 inout 패러미터를 가지며, runs on 절에 MTC의 타입을 정의하고 system 절에는 테스트 시스템 인터페이스의 타입을 명세 한다. 테스트 케이스가 호출될 때 자동으로 시작되는 body 부분에는 MTC의 동작(behaviors)을 정의한다.

[테스트 케이스 정의 예]

함수(Functions)

• TTCN-3에서는 테스트 동작을 표현하거나 모듈에서 컴퓨테이션을 구조화하는데(예, 단일 값 계산, 변수 집합을 초기화) 함수가 사용된다.
• 함수는 패러미터를 가질 수 있고, return 키워드를 사용하여 결과 값을 반환할 수도 있다. return이 명세 되지 않으면 함수 결과가 void이다(void를 위한 별도의 키워드는 존재하지 않음)
• 함수가 테스트 동작을 정의하는 경우 이 동작이 올라가 실행되는 테스트 컴포넌트의 타입을 runs on 절에 명세해야 한다.

[함수 정의 예]

통신 오퍼레이션(Communication operations)

• TTCN-3는 메시지 기반 통신(비동기식)과 프로시져 기반 통신(동기식)을 지원한다.
• 비동기식 통신에서 send 오퍼레이션은 나가는(outgoing) 메시지 기반 포트에 값을 가져다 놓고, receive 오퍼레이션은 들어오는(incoming) 메시지 포트 큐로부터 값을 수신한다. send는 ‘non-blocking’이고(MTC 프로세싱이 send 후 즉시 계속됨), receive는 ‘blocking’이다(send 메시지를 수신할 때까지 IUT를 막음).
• 원격 프로시져 호출(remote procedure calls)과 관련된 동기식 통신에서 call 오퍼레이션은 원격 프로시져를 호출하고, getreply 오퍼레이션은 그 응답(reply)을 처리하며, catch 오퍼레이션은 응답 대신 수신할 수도 있는 예외(exceptions)를 처리한다. 호출 받는 쪽에서는 getcall 오퍼레이션이 원격으로부터의 호출(calls)을 받아들이고, reply 오퍼레이션은 호출에 응답하며, raise 오퍼레이션은 예외 상황을 제기한다. call은 ‘blocking’이고(IUT로부터 응답/예외를 수신할 때까지 MTC 프로세싱을 막음), getcall도 ‘blocking’이다(call을 수신할 때까지 IUT를 막음).

비동기식 send/receive 예	완전 동기식 call 예

TTCN-3에 특수한 동작 구문(special behavior statements)

• 대안 동작 구문(alternative behavior statement): alt 구문은 통신 이벤트 수신 또는 타이머 이벤트 수신에 의한 통제 흐름(control flow)의 분기를 기술한다.
• 디폴트 처리(default handling): 디폴트는 발생할 수 있지만 테스트 목표에는 기여하지 않는 통신 이벤트를 처리하는데 사용된다. 예를 들어 ISDN 시스템의 call forwarding 기능을 테스트 시 charging 정보를 언제든 수신할 수 있지만 이 정보는 테스팅 목표와 관련 없으므로 테스트 평가에서 무시될 수 있다. 테스트 동안에 이런 정보를 포함하는 실행 메시지나 calls을 수신할 수 있으므로 자동으로 확장 가능한(활성화/비활성화) 디폴트를 통해 이를 처리한다.
• 끼워넣기 동작(interleaved behavior): de-coupled 포트의 경우 메시지, 호출, 응답, 예외를 임의의 순서로 수신할 수 있다. interleave 구문은 이런 임의의 순서(arbitrary order)를 표현하는 것을 허용한다(interleave 구문 없이는 모든 유효한 순서가 분명하게 명세 되어야만 함).