문서요약 - OSI 적합성 테스팅의 개요 by Tretmans

시스템유형별/분산

문서요약 - OSI 적합성 테스팅의 개요 by Tretmans

grapevine9700 2018. 4. 30. 06:30

제목: OSI 적합성 테스팅의 개요(An Overview of OSI Conformance Testing)

저자: Jan Tretmans, 네덜란드

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

ISO IS-9646 표준(CTMF로도 알려짐)에 기반한 프로토콜 적합성 테스팅에 대하여 설명한 자료

분산 시스템의 통신 프로토콜

컴퓨터 기능(예, 프로세싱, 정보 저장, 사용자 상호작용)이 여러 다른 컴퓨터 시스템에 퍼져있는 분산 시스템에서는 시스템들간의 정보 교환이 필요함. 즉, 컴퓨터 시스템이 타 컴퓨터 시스템들과 의사소통 하려면 잘 정의된 규칙을 따라야만 하는데 프로토콜(protocol)은 이런 규칙들을 기술한다.
제조업자가 다양한 컴퓨터 시스템들간의 성공적인 의사소통을 위해서는 프로토콜 표준화가 요구되는데, 일례로 ‘개방형 시스템을 위한 OSI 참조 모델(OSI Reference Model for Open Systems)’ 개발을 들 수 있다.
시스템간 성공적인 통신을 위해서는 프로토콜 명세 및 표준화 외에도 프로토콜 구현이 표준 프로토콜 명세대로 동작하는지(즉, 표준을 준수하는지) 확인하는 것이 중요하며, 그 방법 중 하나가 ‘프로토콜 적합성 테스팅(protocol conformance testing)’이다.

프로토콜 적합성 테스팅

프로토콜 엔터티의 구현을 그 명세와 대조하여 정확성을 확인한다.
주어진 프로토콜 명세가 정확하다고 가정하며 명세 자체의 유효성(validity) 확인은 그 범위가 아니다. 명세의 정확성에 대한 체킹은 ‘프로토콜 검증(protocol validation)’이라는 별개 영역에서 다루어짐
명세서를 기준으로 프로토콜 구현의 관측 가능한 동작만이 테스트 된다는 점에서 일종의 블랙박스 테스팅이다(구현의 내부 구조에 대해서는 테스팅에서 참고하지 않음)
구현된 프로토콜 엔터티가 타 엔터티(peer protocol entities)와 성공적으로 통신할 수 있는지 확인하는 기능 동작 측면의 적합성 테스팅 만으로는 시스템들간의 성공적인 통신을 보장하지 못하며 프로토콜 구현의 다른 측면도 테스트가 필요하다.
예, 상호운용성 테스팅(interoperability testing), 성능 테스팅(performance testing), 장애 상황에서의 견고성 테스팅(robustness testing), 일정 기간의 정상 운영을 보장하는 신뢰성 테스팅(reliability testing) 등
적합성 테스팅은 여러 이해 관계 집단에 의해 수행될 수 있다(예, 개발자/제품 공급자, 제품 사용자/사용자 대표 조직, 네트워크 오너, 독립적인 제 3 테스트 조직/인증 기관)

적합성 테스팅의 표준화(Standardization of conformance testing)

프로토콜 명세가 종종 국제적으로 표준화되므로 프로토콜 테스팅이 일반적으로 받아들여지는 잘 정의된 절차와 표준에 의해 수행되었음을 믿을 수 있게 되면 여러 다른 네트워크 오퍼레이터에 의한 테스트의 반복이 필수적이지 않을 수 있다.
이를 위해 국제 표준화 단체인 ISO가 CCITT와 함께 IS-9646 표준 또는 CTMF(OSI Conformance Testing Methodology and Framework)로 알려진 개방형 시스템의 적합성 테스팅 표준을 개발함
이 표준의 목적은 테스트 방법론, 적합성 테스트 스위트(conformance test suites) 명세를 위한 프레임워크, 테스팅 절차 등을 정의하여 여러 다른 테스트 조직에서 생성된 테스트 결과를 서로 비교 가능하거나 전반적으로 받아들일 수 있게 하는 것이다. 이를 통해 동일한 시스템에 대한 적합성 테스팅을 반복하는 것을 최소화할 수 있게 된다.
이 표준은 특정 프로토콜을 위한 테스트를 명세하지는 않지만 그러한 테스트를 개발 및 실행 할 수 있는 지침이 되는 프레임워크를 정의한다.

ISO IS-9646 표준 개요

원래는 OSI 프로토콜 테스팅을 위한 프레임워크를 제공하고 공통 용어를 정의하기 위해 개발된 표준
OSI 프로토콜은 더 이상 자주 사용되지 않지만 이 표준에 정의된 개념은 여전히 다른 종류의 프로토콜(예, ISDN, ATM 등)을 테스팅 하는데 적용 가능
프로토콜이 자연어로 명세 되었다는 가정하에 프로토콜 적합성 테스팅의 방법론과 프레임워크를 정의하였으며, 아래와 같은 5개 부분으로 구성된다.
- part 1: 서론과 일반적인 개념에 대하여 기술
- part 2: 추상화된 테스트 스위트 명세(abstract test suite specification) 프로세스를 기술
- part 3: TTCN 테스트 표기법을 정의
- part 4: 테스트 실행에 대하여 기술
- part 5: 적합성 평가 프로세스(conformance assessment process)에 대하여 기술

적합성 테스팅 프로세스

IS-9646 표준 기반의 적합성 테스팅 프로세스는 아래와 같은 3 단계로 나뉘어진다.

테스트 생성(test generation) 또는 테스트 도출(test derivation): 특정 프로토콜을 위한 추상적 테스트 스위트(an abstract test suite)를 명세. 추상적이라는 것은 테스트가 특정 구현에 종속적이지 않음을 의미한다.
테스트 구현(test implementation): 테스트 스위트를 실행할 방법을 현실화 함. 즉, 추상적 테스트 스위트에 속해 있는 추상화된 테스트 케이스들을 테스트 대상 구현인 IUT(Implementation Under Test)의 특수한 테스팅 환경과 구현을 고려하여 실제 테스팅 기기나 시스템에서 실행 가능한 테스트로 변형한다.
테스트 실행(test execution): 구현된 테스트 케이스로 IUT를 실행하고 그 결과를 관측하여 IUT가 상응하는 표준 프로토콜 명세와 일치하는지 판정을 내린다.

단계1: 테스트 생성(Test Generation)

프로토콜 명세로부터 체계적으로 테스트 케이스를 도출하는 이 단계의 목표는 특정 구현에 종속적이지 않고, 잘 정의된 테스트 표기 언어로 명세 되며, 표준화에 적합하고, 프로토콜의 모든 측면을 충분히 상세하게 테스팅 하는 ‘추상화된 테스트 스위트’를 개발하는 것이다.

1) 프로토콜 표준의 정적 및 동적 적합성 요구사항

적합성 테스팅에서는 특정 프로토콜의 구현이 프로토콜 표준에 명시된 모든 적합성 요구사항(conformance requirements)을 충족해야만 정확한 것으로 판단한다. 적합성 요구사항은 프로토콜 구현이 해야 할 것(긍정 명세 요구사항)과 하지 말아야 할 것(부정 명세 요구사항)을 기술
프로토콜 표준은 특정한 하나의 프로토콜을 명세하는 것이 아니라 특정 타입의 프로토콜들에 대하여 명세하므로 대부분의 표준이 많은 옵션을 남겨둔다. 이 옵션들은 특정 프로토콜 구현에서 구현될 수도 있고 아닐 수도 있으며, 구현이 된 경우는 정확하게 구현되었는지 반드시 확인해야 함
특정 프로토콜 구현에서 구현된 모든 옵션은 ‘PICS(Protocol Implementation Conformance Statement)’에 열거되며, 테스터는 이를 통해 어떤 옵션이 테스트 되어야 하는지 알 수 있다. ‘PICS proforma(옵션 선정에 대한 모든 가능성을 열거한 질의서)’는 PICS의 생성을 돕는 일종의 지침 문서로 프로토콜 표준에 첨부되어 있음
아래 주어진 예와 같이 옵션의 조합과 일관성에 대한 제약(restrictions)이 있을 수 있으며, 이런 옵션 선정에 대한 제약은 프로토콜 표준의 ‘정적 적합성 요구사항(static conformance requirements)’에 기술되어 있다.
프로토콜 표준의 주된 부분을 차지하는 ‘동적 적합성 요구사항(dynamic conformance requirements)’은 프로토콜 구현이 주변 환경과 통신함에 있어서 관측 가능한 동작(이벤트 순서)에 대한 요구사항을 정의한다. 예, PDU(protocol data units)와 ASP(abstract service primitives)의 전송/수신, PDU에서의 정보 코딩 등

<옵션 선정의 제약 예>

ISO/OSI Transport 프로토콜에서는 5개 클래스 (0 .. 4)가 구분되는데, 구현에서 모든 클래스를 구현할 필요는 없지만 선택이 완전히 자유로운 것도 아니다. 예를 들어, 클래스 4가 구현되면 클래스 2도 반드시 구현되어야 한다.

2) 테스트 케이스 생성 프로세스

다시 정리하면 적합성 테스팅은 IUT가 프로토콜 표준의 정적 및 동적 요구사항 모두를 충족시키는지 체킹하는 일이다.
정적 적합성 요구사항은 IUT와 함께 전달된 PICS를 검토하여 체킹하며 이는 ‘정적 적합성 검토(static conformance review)’ 활동으로 알려져 있다.
동적 적합성 요구사항은 IUT에 다수의 테스트를 실행시켜 체킹한다. 즉, 동적 적합성 요구사항 집합이 테스트 생성의 시작점이며, 각각의 테스트를 ‘테스트 케이스(test case)’라 하고 이런 테스트 케이스들의 완전한 집합을 ‘테스트 스위트(test suite)’라 한다.

테스트 케이스는 동적 적합성 요구사항으로부터 아래 절차를 통해 도출된다.

① 각 적합성 요구사항에 대한 하나 또는 그 이상의 ‘테스트 목적(test purposes)’을 도출한다. 테스트 목적은 특정 적합성 요구사항이 충족되는지 판단하기 위해 무엇이 테스트 될 것인지를 정확하게 기술한 것

② 각 테스트 목적에 대해 ‘포괄적 테스트 케이스(generic test case)’를 도출한다. 포괄적 테스트 케이스는 테스트 목적을 오퍼레이션화(operationalization) 한 것이다. 즉, 테스트 목적을 달성하기 위해 필요한 액션들이 테스트 방법이나 실제 테스팅이 수행될 환경을 고려하지 않고 상위 레벨로 기술된 것이다.

③ 각 포괄적 테스트 케이스에 대한 ‘추상화된 테스트 케이스’를 도출한다. 이 단계에서는 특정 테스트 방법(다음 섹션에서 설명)에 대한 선택이 이루어지고 테스팅이 수행될 환경의 환경적 제약도 고려된다.

3) 테스트 방법(Test methods) ß 논문에서는 이 용어를 썼지만 '테스트 아키텍쳐'가 더 적절한 듯

프로토콜 표준은 프로토콜 엔터티의 동작을 프로토콜의 상위 액세스 포인트((N)-SAP)와 하위 액세스 포인트((N-1)-SAP)에서 명세하므로 이 SAP(Service Access Point)들이 엔터티를 테스트할 이상적인 지점이 된다.
하지만 테스트 시스템이 항상 이 SAP에 직접 액세스 할 수 있는 것은 아니다. 테스트 시스템이 IUT를 통제하고 관측하는 포인트는 ‘PCO(Points of Control and Observation)’라 불린다. PCO는 IUT의 경계(boundaries)와 일치할 수 있지만 반드시 그럴 필요는 없다.
프로토콜 적합성 테스팅에는 대개 2개의 PCO가 있으며, 하나는 IUT의 상위 액세스 포인트(upper access point)에 상응하고 다른 하나는 하위 액세스 포인트(lower access point)에 상응한다. 테스트 시스템도 유사하게 개념을 나누어 상위 액세스 포인트와 연결된 PCO를 통제 및 관측하는 부분은 ‘UT(Upper Tester)’라 하고, 하위 액세스 포인트와 연결된 PCO를 통제 및 관측하는 부분은 ‘LT(Lower Tester)’라 한다.
테스트 방법은 테스트 시스템의 IUT 접근성(accessibility)에 대한 모델을 PCO와 OSI 참조 모델에서의 PCO 위치 측면에서 정의하는 것으로, 아래와 같은 것들이 구별된다.
- PCO의 존재: 만약 액세스 포인트 중 하나가 액세스가 가능하지 않다면 해당 액세스 포인트를 위한 PCO가 없다.
- PCO와 액세스 포인트 간에 타 프로토콜 층이 있는지 여부와 통신되는 이벤트의 타입(ASP 또는 PDU)
- SUT(System Under Test)라 불리는 IUT와 동일한 시스템에서의 PCO의 위치
- 테스트 시스템의 내부 기능(즉, LT와 UT에 분산된 테스팅 기능)과 이들의 협업을 정의한 규칙인 TCP(test coordination procedures)
위에 나열된 사항들을 다르게 함으로써 여러 다른 테스트 방법이 얻어지며, 아래와 같은 일부 방법은 표준화된 추상적 테스트 스위트에서 사용되도록 IS-9646에 포함되어 있다.
- Local Single-layer 테스트 방법(LS-method)
- Distributed Single-layer 테스트 방법(DS-method)
- Coordinated Single-layer 테스트 방법(CS-method)
- Remote Single-layer 테스트 방법(RS-method)

<표준화된 프로토콜 테스트 방법 예>

모든 표준화된 테스트 방법에서 IUT의 하위 액세스 포인트는 대개 기저 서비스(underlying service)를 통해 항상 액세스 가능하지만 상위 액세스 포인트는 숨겨져 있을 수도 있다. 아래 좌측의 RS-method는 하나의 PCO를 가진 테스트 방법이고(UT가 없음), 우측의 DS-method는 두 개의 PCO를 가진다.

RS-method 예

DS-method 예

4) 테스트 표기법(Test notation)

IS-9646은 반정형 언어(semi-formal language)인 ‘TTCN(Tree and Tabular Combined Notation)’을 사용하여 표준화된 추상적 테스트 스위트를 명세할 것을 추천함
TTCN에서 테스트 케이스의 동작은 PCO에서 발생하는 입력 및 출력 이벤트 시퀀스에 의해 명세 된다.
하나의 시퀀스가 여러 다른 대안 경로(alternatives)를 가질 수 있음(즉, IUT가 생성한 출력 값, 타이머 종료, 테스트 시스템의 내부 패러미터 값 등에 따라 후속 동작이 다르게 선택 될 수 있다).
표기 시 연속적인 이벤트(successive events)는 들여쓰기 레벨을 증가시켜서 나타내고, 대안 이벤트(alternative events)는 동일한 들여쓰기 레벨에 기술된다.
각 시퀀스는 시퀀스 실행이 종료될 때 주어지는 ‘판정(verdict)’을 명세하여 완성한다. 여러 다른 대안 동작에 대한 판정(pass, fail, inconclusive)이 각기 다를 수 있음
TTCN은 자동 실행(automatic execution)이 가능하도록 정의된다.

[TTCN으로 표기된 테스트 케이스 예]

[위 테스트 케이스를 도식으로 표현한 예]

5) 테스트 분류(Classification of tests)

테스트는 보장할 수 있는 적합성 정도에 따라 아래와 같이 분류된다.

기본 상호연결 테스트(basic interconnection tests): 테스트 시스템과 IUT간의 기본 수준의 상호연결을 보장하는데 사용됨. 경제적인 목적이 있음. 즉, 비싼 테스트 환경을 개발하기 전에 먼저 IUT의 일부 기본적인 기능을 체크함(예, 테스트 시스템과 IUT 간의 연결성 확보)
능력 테스트(capability tests): 구현된 옵션과 PICS에 명시된 옵션 간의 순응(compliance) 여부를 확인하는 역할
동작 테스트(behaviour tests): 테스트 스위트의 주된 부분을 차지하는 테스트로 프토토콜 표준의 동적 적합성 요구사항을 기술적 및 경제적으로 타당한 범위 내에서 최대한 자세하게 테스트한다. 이 테스트가 적합성(Conformance)에 대한 최종 판정의 기준이 된다.
적합성 보충 테스트(conformance resolution tests): 실제 적합성 테스트에 속하지 않음. 문제 발생의 경우나 에러 추적 등을 위해 추가적으로 수행하는 보충 테스트(supplementary tests)이다. 이 테스트는 본질적으로 표준화되지 않고 휴리스틱 성질을 가지며 따라서 최종 판정의 기준으로는 사용할 수 없다.

6) 테스트의 계층적 구조

테스트 스위트(test suite)는 특정 프로토콜의 적합성 테스팅을 위한 하나의 완전한 테스트 집합체이며 실행 순서가 정해지지 않은 테스트 케이스 들로 구성된다.
테스트 그룹(test group)은 관련된(같은 테스트 목표를 가지는) 테스트 케이스들을 논리적으로 묶어 형성한다. 그룹핑은 여러 다른 레벨에서 일어날 수 있다.
하나의 테스트 케이스 내에서는 테스트 스텝(test step)과 테스트 이벤트(test event)가 구별된다.
- 최소 단위인 테스트 이벤트는 PCO에서의 개별 인터액션을 나타낸다(예, 하나의 PDU를 전송하거나 수신하기).
- 모듈화에 기여하는 테스트 스텝은 연속적인 테스트 이벤트를 묶는 역할을 한다. IUT를 테스트 케이스의 body가 수행될 수 있는 상태로 만드는 이벤트 시퀀스인 ‘프리엠블(preamble)’과 테스트 케이스 body가 실행된 후에 IUT를 특정 상태(예, 초기 상태)로 되돌려 놓는 ‘포스트엠블(postamble)’이 테스트 스텝의 예이다.
- 공통적으로 사용되는 테스트 스텝을 라이브러리로 구성하면 매번 반복해서 명세할 필요가 없어 효율적임

단계2: 테스트 구현(Test Implementation)

표준화된 추상적 테스트 스위트를 ‘실행 가능한 테스트 스위트(executable test suite)’로 변환. 즉, 특정 IUT로 특정 테스팅 기기 상에서 실행 가능한 테스트 스위트를 개발한다.
추상적 테스트 스위트는 특정 프로토콜의 모든 가능한 테스트와 옵션을 포함하므로 구현을 시작하기 전에 반드시 현 IUT와 관련된 테스트만을 PICS에 기반하여 선별해야 한다(구현되지 않는 옵션은 테스트 할 필요가 없음). IS-9646에서는 이 작업을 ‘테스트 선정(test selection)’이라고 부른다.
PICS가 프로토콜에 의존적인 정보를 포함하지만 실행 가능한 테스트를 도출하기에는 PICS 만으로는 충분하지 않으며 IUT 및 그 환경에 대한 정보를 제공하는 ‘PIXIT(Protocol Implementation eXtra Information for Testing)’가 필요하다. PIXIT는 IUT의 어드레스 정보나 또는 테스트 스위트를 구현하는데 필요한 패러미터 값과 타이머 값을 포함한다.
PIXIT는 PICS와 마찬가지로 IUT 공급자가 테스트 수행 조직에게 제공한다. 테스팅 수행 조직은 PIXIT 생성을 위한 지침으로 ‘PIXIT proforma’를 제공한다.
구현 시 추상적 테스트 스위트의 명세에 사용된 테스트 표기법(test notation)의 시멘틱에 따라 테스트가 정확하게 구현되도록 주의를 기울여야 한다.

단계3: 테스트 실행(Test Execution)

특정 IUT가 실제 테스트되고 해당 IUT의 적합성(conformance)에 대한 판정이 내려진다.
1단계로는 정적 적합성 검토(static conformance review)가 이루어진다. 즉, IUT의 PICS가 내적 일관성 측면에서 체크되고 표준의 정적 적합성 요구사항과 비교된다.
2단계에서는 실행 가능한 테스트 케이스를 실제 테스트 시스템에서 실행하고 IUT의 반응(reactions)을 관측하여 테스트 케이스에 명세된 반응과 비교한다. 각각의 테스트 케이스에 대해 pass, fail, 또는 inconclusive의 판정을 내린다.
- Pass는 테스트가 성공적으로 실행되었고 테스트 목적이 달성되었음을 나타내고,
- Fail은 구현이 명세에 부합되지 않음을 나타내며,
- Inconclusive는 비준수(non-conformance)의 증거는 찾지 못했지만 테스트 목적이 달성되지 않았음을 나타냄
마지막 단계에서는 정적 적합성 검토의 결과와 모든 테스트 케이스의 판정을 종합하여 IUT의 프로토콜 명세 적합성에 대한 최종 판정을 내린다(대개 Fail 판정을 받은 테스트 케이스가 하나도 없어야만 최종 판정이 Pass가 됨). 최종 판정을 포함한 모든 테스트 실행 결과는 프로토콜 적합성 테스트 보고서인 ‘PCTR(Protocol Conformance Test Report)’에 문서화된다.

<Inconclusive 판정 예>

위에 나온 TTCN 예의 테스트 목적은 액션 시퀀스(T-PDU-connect-request, T-SP-connect-indication, T-SP-connect-response, T-PDU-connect-confirm)를 테스트하여 Transport 프로토콜의 올바른 연결 확립을 체크하는 것임. 만약 IUT가 T-PDU-connect-request를 수신한 후에 T-PDU-disconnect-request로 반응하면 inconclusive 판정이 내려진다(이것이 Transport 프로토콜 표준에서 허용되는 동작이기는 하지만 의도한 테스트 목적이 달성되지 않았으므로 pass 판정을 줄 수 없음)

저작자표시 비영리 변경금지