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

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

저자: Jan Tretmans

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

ISO 9646 표준에 기반한 프로토콜 적합성 테스팅(conformance testing) 프로세스에 대해 기술한 자료 

---

프로토콜 적합성 테스팅(protocol conformance testing)

• 컴퓨터 기능(프로세싱, 정보 저장, 휴먼 인터액션 등)이 여러 컴퓨터 시스템에 분산되어 있는 분산 시스템 개발에서는 시스템 간 정보 교환이 필요하며, 이를 위해서는 잘 정의된 규칙(프로토콜)에 따라 통신이 이루어져야 한다.
• ‘프로토콜’은 컴퓨터 시스템이 다른 컴퓨터 시스템과 통신할 때 반드시 준수해야 하는 규칙들을 기술한다. ‘프로토콜 엔터티’는 프로토콜에 따라 통신을 하는 것을 책임지고 있는 컴퓨터 시스템의 일부이다.
• 제조 업체가 다른 다수의 컴퓨터 시스템 간 성공적 통신을 위해서는 프로토콜이 독립적으로 개발되기 보다는 특정 제조 업체 그룹(또는 사용자 그룹)의 표준을 따르게 된다. 일례로 ‘개방형 시스템을 위한 OSI 참조 모델(OSI Reference Model for Open Systems)’은 컴퓨터 시스템이 통신할 수 있게 하는 일련의 표준들의 프레임워크 역할을 한다.
• 성공적인 통신을 보장하기 위해서는 통신 프로토콜을 명세하고 표준화하는 것만으로 충분하지 않으며, 프로토콜 구현이 실제로 표준 프로토콜 명세 대로 동작하는지 확인해야 한다. 이를 수행하는 한 가지 방법이 프로토콜 구현을 테스팅하는 것인데, 이 활동을 ‘프로토콜 적합성 테스팅(protocol conformance testing)’이라고 한다.
• 프로토콜 적합성 테스팅은 프로토콜 엔터티의 구현을 그 명세를 기준으로 테스트하는 테스팅의 한 종류이다(즉, 프로토콜 엔터티 구현이 명세에 기술된 요구사항들을 준수하는지 확인함). 이 테스팅은 프로토콜 명세가 정확하고 유효하다고 가정하며, 명세의 정확성/유효성 자체를 검증하는 것은 적합성 테스팅의 범위가 아니다. 따라서 명세 자체에 설계 에러가 포함되었다면, 적합성 테스트 프로세스가 올바르게 수행되었고 구현이 테스트를 통과했더라도 에러가 존재하게 된다.

프로토콜 적합성 테스팅 수행자

프로토콜 적합성 테스팅은 여러 당사자에 의해 수행될 수 있다.

• 제품의 구현자 또는 공급 업체가 자신들의 제품을 판매하기 전에 테스트
• 제품 사용자 또는 사용자를 대표하는 조직이 제품의 기능이 정확한지를 테스트
• 통신 관리자가 제품을 자신의 네트워크에 연결하기 전에 체크(부정확하게 구현된 제품이 네트워크 장애를 야기하는 것을 예방하기 위함)
• 독립적인 제 3자인 테스트 실험실이 위에 언급한 당사자들을 대신하여 적합성 테스트를 수행함. 테스트 실험실은 인증 시스템을 통해 테스트를 통과한 구현을 인증해 줄 수 있다. 

ISO 9646 표준

‘ISO 9646: OSI 적합성 테스트 방법론 및 프레임워크(OSI Conformance Testing Methodology and Framework)’는 프로토콜이 자연어로 명세되었다는 가정 하에 프로토콜 적합성 테스팅을 위한 방법론과 프레임워크를 정의한 것이다. 원래 OSI 프로토콜 용으로 개발되었지만 ISDN이나 ATM 프로토콜과 같은 다른 종류의 프로토콜을 테스트하는 데에도 사용된다. ISO 9646 표준은 아래와 같은 다섯 부분으로 구성된다.

• 파트1: 적합성 테스팅의 일반 개념을 다룸
• 파트2: 추상적 테스트스위트(abstract test suite) 명세 프로세스를 기술함
• 파트3: 테스트 표기법 TTCN을 정의함
• 파트4: 테스트 실행에 대해 다룸
• 파트5: 적합성 평가 프로세스 동안 테스트 실험실 및 고객에게 요구되는 요구사항을 기술함

적합성 테스팅 프로세스(Conformance Testing Process)

적합성 테스팅 프로세스는 크게 세 단계로 구분될 수 있다.

• 단계1: 특정 (OSI) 프로토콜을 위한 추상적 테스트스위트를 명세하는 단계로 ‘테스트 생성(test generation)’ 또는 ‘테스트 도출(test derivation)’이라고 부른다. 테스트스위트가 추상적이라는 것은 테스트가 특정 구현에 종속되지 않고 독립적으로 개발되었다는 의미
• 단계2: 특정 테스트스위트의 실행 수단을 현실화하는 단계로 ‘테스트 구현(test implementation)’이라고 부른다. 추상적 테스트스위트의 추상적 테스트케이스들이 실제 테스팅 기기(또는 테스팅 시스템) 상에서 실행될 수 있는 실행가능한 테스트로 변환된다. 테스팅 환경과 IUT라 불리는 구현물의 특이점들이 반영된다.
• 단계3: ‘테스트 실행(test execution)’이라 부르며, 구현된 테스트케이스들을 특정 IUT로 실행하고 그 결과 동작을 관찰한다. IUT가 표준 프로토콜 명세에 부합하는지에 대한 판정을 내린다. 테스트 실행 결과는 ‘PCTR 보고서(protocol conformance test report)’에 문서화된다. 

[적합성 테스팅 프로세스]

구현물의 표준 적합성이란

어떤 IUT가 프로토콜 표준에 명시된 적용가능한 모든 적합성 요구사항(conformance requirements)을 준수할 때 IUT가 그 명세에 부합한다고 말할 수 있다. 프로토콜 표준이 하나의 프로토콜을 고유하게 명세하기 보다는 프로토콜 클래스를 명세하므로, 대부분의 표준은 특정 프로토콜 구현에서 구현하거나 또는 구현하지 않을 수 있는 많은 옵션을 남겨 둔다. 구현자는 구현할 옵션 세트를 선택하게 되며, 특정 프로토콜 구현의 모든 구현되는 옵션을 ‘PICS(Protocol Implementation Conformance Statement)’에 나열한다. 따라서 테스터는 어떤 옵션이 테스트되어야 하는지를 PICS를 보고 알 수 있다. PICS 작성을 지원하기 위해 PICS 서식(proforma)이 프로토콜 표준에 첨부되어 있다.

 

옵션 선택에 대한 제한(restrictions)은 표준의 ‘정적 적합성 요구사항(static conformance requirements)’에 기술된다. 정적 적합성 요구사항은 구현물이 제공해야 하는 최소 기능과 여러 옵션의 조합 및 일관성에 대한 요구사항을 정의하고 있다.

예 3.1 ISO/OSI Transport 프로토콜에 5개 클래스(0 .. 4)가 존재하는데, 특정 구현에서 모든 클래스를 구현할 필요는 없지만 그렇다고 선택이 완전히 자유로운 것도 아니다. 예를 들어 클래스 4가 구현되는 경우 클래스 2도 반드시 구현되어야 한다. 이러한 제한은 정적 적합성 요구사항의 일부로 프로토콜 표준에 기술되어 있다.

 

프로토콜 표준의 주요 부분은 ‘동적 적합성 요구사항(dynamic conformance requirements)’으로 구성된다. 동적 적합성 요구사항은 어떤 구현물이 그 환경과 통신하는데 있어서 관찰가능한 동작(observable behaviour)에 대한 요구사항을 정의한다. 예를 들면 PDU(프로토콜 데이터 유닛)와 ASP(추상 서비스 프리미티브)의 송수신, PDU 상의 정보 코딩, 여러 PDU의 정보 콘텐츠 간의 관계 같은 관찰가능한 이벤트의 허용된 순서(ordering)에 관심을 가진다. 

예 3.2 ISO/OSI Transport 프로토콜의 동적 적합성 요구사항 예가 아래와 같다. “피어 엔티티로부터 T-PDU-connect-request를 수신 후, T-SP-connect-indication 서비스-프리미티브를 통해 Transport 엔터티의 사용자에게 통지가 되거나 또는 T-PDU-disconnect-request가 피어 엔티티에게로 전송되어야 한다.”

요약하면, 어떤 구현물이 정적 및 동적 적합성 요구사항을 모두 충족시키고 PICS에 명시된 기능과 일치하는 경우에 해당 구현물이 표준 적합성을 가진다고 정의한다. 따라서 적합성 테스팅이란 IUT가 모든 정적 및 동적 적합성 요구사항을 충족시키는지를 확인하는 활동이다. 정적 적합성 요구사항의 경우 IUT와 함께 제공되는 PICS를 검토하는 프로세스를 의미하며, 이를 ‘정적 적합성 검토(static conformance review)’라고 부른다. 동적 적합성 요구사항의 경우는 IUT에 여러 테스트를 실행시키는 것을 의미한다. 이 때 하나의 테스트를 명세한 것을 ‘테스트케이스’라고 하며, ‘테스트스위트’는 테스트케이스들의 완전한 집합, 즉 특정 프로토콜의 모든 동적 적합성 요구사항을 테스트하는 하나의 세트를 말한다.

테스트 생성

적합성 테스트 프로세스의 첫 단계인 테스트 생성(test generation)은 추상적 테스트스위트를 개발하는 것을 목표로 한다. 즉, 구현으로부터 독립적이고, 잘 정의된 테스트 표기 언어(test notation language)로 명세되며, 표준화하기에 적합하고, 프로토콜의 모든 측면을 충분히 자세하게 테스트 할 수 있는 테스트케이스 집합을 생성한다. 정적 적합성 요구사항은 PICS 검토를 통해 체크되므로, 프로토콜 표준의 동적 적합성 요구사항 집합이 테스트 생성의 시작점이 된다. 

동적 적합성 요구사항으로부터 테스트케이스를 체계적으로 도출하는 절차가 아래와 같다.

• 스텝1: 각 적합성 요구사항에 대한 하나 또는 하나 이상의 ‘테스트 목적(test purposes)’이 도출된다. 테스트 목적이란 특정 적합성 요구사항이 충족되었는지에 대한 판단을 하기 위해서 무엇이 테스트되어야 하는지를 정밀하게 기술한 것이다.
• 스텝2: 각 테스트 목적을 위한 ‘포괄적 테스트케이스(generic test case)’를 도출한다. 포괄적 테스트케이스란 테스트 목적을 달성하는데 필수적인 액션들을 상위 레벨에서(실제 테스팅 실행 시 요구되는 테스트 방법이나 환경은 고려하지 않음) 기술한 것을 말한다. 
• 스텝3: 각 포괄적 테스트케이스에 대한 추상적 테스트케이스(abstract test case)를 도출한다. 이 단계에서는 특정 ‘테스트 방법(test method)’에 대한 선택이 이루어지며, 테스팅이 수행되는 환경으로 인한 제한(restrictions)에 대해서도 고려한다.

테스트 방법(Test methods)

프로토콜 표준은 프로토콜 엔터티의 동작을 프로토콜의 상위 접근점과 하위 접근점에서 명세한다. 따라서 상/하위 접근점이 엔터티를 테스트하기 위한 이상적인 지점이 되지만, 이곳이 항상 테스터(테스트 장치)의 직접 액세스를 허용하는 것은 아니다. 테스터가 IUT를 제어하고 관찰할 수 있는 지점을 ‘PCO(Points of Control and Observation)’라고 하는데, PCO가 IUT의 경계와 일치할 수도 있고 그렇지 않을 수도 있다. 일반적으로 프로토콜 적합성 테스트에는 두 개의 PCO가 있는데, 하나는 IUT의 상위 접근점에 다른 하나는 하위 접근점에 상응한다. 상위 접근점에 연결된 PCO를 제어/관찰하는 테스터 부분을 ‘상부 테스터(UT)’라 하고, 하위 접근점에 연결된 PCO를 제어/관찰하는 부분을 ‘하부 테스터(LT)’라고 한다. 

테스트 방법은 테스터가 어떻게 IUT에 접근할지를 PCO와 그것의 OSI 참조 모델 내에서 위치 측면에서 모델화한 것이며, 아래와 같은 것들을 고려한다  

• PCO의 존재 여부: 접근점 중 어느 것도 액세스 할 수 없는 경우 해당 접근점을 위한 PCO가 존재하지 않는다.
• PCO와 접근점 사이에 다른 프로토콜 계층이 존재하는지 여부와 통신되는 이벤트 종류(ASP 또는 PDU)
• IUT와 동일한 컴퓨터 시스템(SUT라 불림)에서 PCO의 위치
• 테스터의 내적 기능(테스트 기능이 LT와 UT에 어떻게 분배되었는지)과 이 기능들의 조정(coordination)을 정의한 규칙(테스트 조정 절차)

 

위 사항들을 다양하게 함으로써 여러 다른 테스트 방법이 얻어진다. 예를 들어 표준화된 테스트 방법으로 아래 그림과 같은 로컬 단일층 테스트 방법(LS-method)과 분산 단일층 방법(DS-method)이 존재한다. 모든 표준화된 테스트 방법에서 IUT의 하위 접근점은 항상 접근가능하지만 상위 접근점은 숨겨져 있을 수도 있다. 아래 두 방법은 각각 두 개의 PCO를 가지고 있지만, 원격 단일층 테스트 방법(RS-method)처럼 PCO가 한 개인 경우도 있다(RS-method에서는 상부 테스터가 없음).

 

표준화된 추상적 테스트스위트는 특정 테스트 방법을 참조하게 된다(가장 적합한 방법을 선택).

테스트 표기법(Test notation)

표준화된 추상적 테스트스위트를 얻기 위해서는 잘 정의되었고, 특정 구현으로부터 독립적이며, 일반적으로 수용되는 테스트 표기법(test notation)을 사용하여 테스트스위트를 명세를 해야 한다. IS-9646은 반 정형 언어인 TTCN(Tree and Tabular Combined Notation)을 테스트 표기법으로 권장한다.

 

TTCN에서는 테스트케이스의 동작(behaviour)이 PCO에서 발생하는 입력 및 출력 이벤트 시퀀스로 명세된다. 시퀀스는 여러 다른 대안을 가질 수 있다(예를 들어 IUT의 출력값, 타이머 만료, 테스터의 내부 패러미터값 등에 따라서 여러 다른 후속 동작이 선택될 수 있음). 연속 이벤트는 들여 쓰기 레벨을 증가시켜 표시하고, 대체 이벤트는 동일한 들여쓰기 레벨에 기술한다. 하나의 시퀀스는 시퀀스 실행이 종료될 때 결정되는 판정(verdict)을 명세하면서 끝을 맺는다. 여러 대체 동작들의 판정이 각기 다를 수 있는데, 정확한 동작을 기술하는 일부는 긍정적 판정(Pass)으로 잘못된 동작을 기술하는 일부는 부정적 판정(Fail)으로 마무리 된다. 또한 올바르지만 의도한 동작이 아닌 경우 미확정(Inconclusive) 판정이 내려질 수도 있다.

 

TTCN은 자동 실행이 가능하도록 정의되어야 한다. TTCN 동작의 간단한 예가 아래 그림과 같다.

 

테스트케이스 동적 동작
테스트케이스 이름: Conn_Estab 그룹: transport/connection 목적: 원격 이니셔티브(remote initiative)와의 커넥션 확립을 체크한다.
동작	제약	판정
+preamble LT ! T-PDU-connect-request UT ? T-SP-connect-indication UT ! T-SP-connect-response LT ? T-PDU-connect-confirm OTHERWISE LT ? T-PDU-disconnect-request OTHERWISE		Pass Fail Inconclusive Fail

[간단한 TTCN 예]

테스트 분류(Classification of tests)

테스트는 적합성을 나타내는 정도에 따라 분류될 수 있으며, 아래와 같이 구분된다. 

• 기본 상호연결 테스트(basic interconnection tests): 테스터와 IUT 간의 기본 수준의 상호연결성을 보장하는데 사용됨. 경제성이 이 테스트의 주 목적. 즉, 값비싼 테스트 환경이 개발되기 전에 IUT의 일부 기본 기능(예, 테스터와 IUT 간의 커넥션 확립)을 체크한다.
• 기능 테스트(capability tests): 구현된 옵션과 PICS에 명시된 옵션 간의 적합성을 확인하는 역할을 함
• 동작 테스트(behaviour tests): 이 테스트가 테스트스위트의 주요 부분을 구성함. 기술적으로 경제적으로 타당한 범위 내에서 프로토콜 표준의 동적 적합성 요구사항을 상세히 테스트하며, 적합성에 대한 최종 판결의 근거가 된다.
• 적합성 해결 테스트(conformance resolution tests): 실제 적합성 테스트에 속하지 않음. 문제에 직면하거나 에러를 추적하는 경우 필요한 추가 테스트를 하는데 사용될 수 있는 보충용 테스트. 이 테스트는 휴리스틱 성격을 가지며, 표준화되지 않았고, 최종 판결의 근거로 사용될 수도 없다.

테스트 구현(Test Implementation)

테스트 구현에서는 실제 테스트 기기로부터 독립적으로 명세된 추상적 테스트스위트를 ‘실행 가능한 테스트스위트(특정 테스트 기기에서 IUT를 실행시킬 수 있음)’로 변환한다. 추상적 테스트스위트를 명세하는데 사용된 테스트 표기법의 시맨틱에 따라 테스트가 정확하게 구현되도록 주의를 기울여야 한다.

 

추상적 테스트스위트에는 특정 프로토콜의 모든 가능한 옵션에 대한 모든 가능한 테스트가 포함되어 있는데, PICS에 따라 구현에서 빠진 옵션은 테스트할 필요가 없다. 따라서 구현을 시작하기에 앞서서 PICS를 기반으로 IUT와 관련된 테스트를 선택하는 작업이 수행되는데, IS-9646에서 이것을 ‘테스트 선택(test selection)’이라고 한다.

 

PICS가 프로토콜에 종속적인 정보를 포함하고 있지만 실행 가능한 테스트를 도출하기에 이것만으로 충분하지 않으며, IUT와 그 환경에 대한 정보가 반드시 제공되어야 한다. 이러한 정보를 ‘PIXIT(Protocol Implementation eXtra Information for Testing)’라고 부른다. PIXIT가 IUT 주소 정보, 테스트스위트를 구현하는데 필요한 패러미터와 타이머 값 등을 포함하고 있을 수 있다. PICS와 마찬가지로 PIXIT는 IUT 공급 업체에 의해 테스트 실험실에 제공된다. 테스팅 실험실은 ‘PIXIT 서식’을 제공함으로써 PIXIT 생성을 돕는다.

테스트 실행(Test Execution)

테스트 실행 단계에서는 IUT가 실제로 테스트되어 해당 IUT의 적합성에 대한 판정이 내려진다. 첫 번째로 정적 적합성 검토(static conformance review)가 수행되는데, IUT의 PICS를 내부 일관성 측면에서 체크하고 표준의 정적 적합성 요구사항과 비교한다. 두 번째로 실행가능한 테스트케이스들을 실제 테스터 상에서 실행시켜 IUT 반응을 관찰하고 테스트케이스에 명세된 반응과 비교한다. 각 테스트케이스에 대해 합격(pass), 불합격(fail), 또는 미확정(inconclusive)을 판단한다. 합격은 테스트가 성공적으로 실행되었고 테스트 목적이 달성되었음을 의미하고, 불합격은 구현이 그 명세에 부합하지 않음을 나타낸다. 미확정은 명세 미준수의 증거가 발견되지는 않았지만 테스트 목적이 달성되지 않았음을 의미한다.

예 3.3 위 TTCN 예제의 테스트 목적이 Transport 프로토콜의 올바른 커넥션 확립을 확인하는 것이고, 이를 위해 T-PDU-connect-request, T-SP-connect-indication, T-SP-connect-response, T-PDU-connect-cofirm의 액션 시퀀스를 테스트한다고 가정해보자. IUT가 T-PDU-connect-request를 수신한 후 T-PDU-disconnect-request를 반응으로 보내는 경우 ‘미확정’ 판정이 내려진다. Transport 표준에 따르면 이 동작이 허용되지만, 테스트 목적이 달성되지 못했기 때문에 합격 판정을 줄 수 없다.

마지막으로 정적 적합성 검토 결과와 모든 테스트케이스의 판정 결과를 종합하여 IUT의 프로토콜 적합성에 대한 판정을 내린다. 일반적으로 불합격 판정을 받은 개별 테스트가 하나도 없는 경우에만 최종 판정이 합격으로 결정된다. 최종 판정을 포함한 모든 결과는 PCTR(Protocol Conformance Test Report)에 문서화된다.