Red Hat Forum 2012 - JBoss RHQ - Java Application Monitoring & Management Pla...
167 Pdfsam 2003 S 236
1. 제 5장 Test 환경 구축 및 실행
제 1절 테스트 정의
DVB‐MHP의 표준이 공개되어 있으며 이 표준을 분석, 설계, 구현하는
형태가 일반적인 구현업체의 Workflow 가 된다. 표준의 이해와 해석이
각각의 업체에 따라 다를 수 있으며, 표준을 지향하지만 보다 효과적인
기능을 확장하기 위해 업체 고유의 기능을 부여할 수 있다. 이와 같이
다양성이 존재하는 만큼 표준의 의미가 희석될 수 있는 위험성 또한
존재하므로 MHP Expert Group(이하 MEG) 에서는 표준의
적합성(Conformance)을 확인하는 방법으로 Test Suite를 제공하여 해당
구현이 적합하게 구현되었는지를 평가할 수 있게 하고 있다.
1. 테스트 슈트 구조
테스트 슈트는 크게 5 가지 형태의 패키지를 포함하고 있다. 각 각의
패키지들은 고유한 영역으로 나누어져 있고 이렇게 나누어진 영역은 MEG
와 그에 연관 있는 특정 업체가 분담하여 제작되어있다.
<표 5-1> 테스트 주관 기관
주관기관 설명
Micronas Porter Duff rule Test
MHP Test Consortium MHP 플랫폼 및 API Test(4개 Submission 구성)
OpenTV Persistent storage Test(2개 패키지로 구성)
Sony MHP API Signature Test
Sun Microsystems Java 플랫폼 그리고 API 클래스 Test
Micronas 社 에서 제공하는 Porter‐Duff Rule Test 는 Graphics 와 Video
또는 특정 영역과 같은 서로 다른 Layer(또는 plane)로 구성되는 환경에서
특정 Layer 에 대한 표현 우선권(Composition)을 주는 방법을 나타내는
것으로서 MHP 표준에서 8 가지의 Rule 을 제시하고 있다. 이 테스트를
통해 Porter Duff 8 가지 규칙을 Test 한다.
MHP Test Consortium 에서 제공되는 MHP 플랫폼 및 API Test 패키지는
- 147 -
2. MHP 표준에서 정의되는 일반적인 Core 들을 테스트하는 패키지로서 4
가지 Submission으로 구성된다.
OpenTV 社 에서 제공하는 Persistent storage (영속 저장장치) 테스트는
각 Receiver 에 따라 구성 방법이 다른 Persistent Storage (예, flash RAM,
HDD 등.) 접근에 대한 테스트를 수행하는 것으로서 보안과 밀접한 관계를
가지고 있다. 다음과 같이 두 가지 서브 패키지를 포함한다.
● Persistent storage 에 대한 보안 접근 테스트
● 4096‐bit RSA Authentication 테스트
Sony 社 에서 제공되는MHP API Signature Test 패키지는 MHP 표준에서
정의되는 API 들에 대한 Signature Test로서 다음과 같이 크게 4가지
관점에서 테스트를 진행한다.
● constructor 클래스의 인스턴스를 생성하는 생성자 검사
● event 이벤트 클래스의 객체 및 이벤트 소스를 검사
● exception 예외관련 클래스 및 예외 메시지 검사
● reflection 클래스의 public 멤버 변수 등을 검사
Sun MicroSystems 社 에서 제공하는 Java 플랫폼 그리고 API 클래스
Test는 MHP 표준에서 정의하는 Personal Java 규격(JVM 및 Java Core
API)과 확장 패키지(Java TV, JMF) 들을 Test하는 Java™ Technology
Compatibility Kit 이다.
2. 실행환경
각 각의 적합성을 Test 하는 Test 패키지에 대한 Test 기반 환경은 크게
두 가지로 나뉘게 된다. MHP 관련 Test 환경과 Java™ Technology Test
환경이 그 것이다. 이 두 가지 방식에 포함되는 각 각의 적합성 Test
패키지는 다음과 같다.
MHP 관련 Test 환경
◇ Porter Duff rule Test
◇ MHP 플랫폼 및 API Test
- 148 -
3. ◇ Persistent storage Test
◇ MHP API Signature Test
Java™ Technology Test 환경
◇ PersonalJava™ Compatibility Kit (pJCK) 1.2
◇ JavaTV™ TCK 1.0
◇ Java™ Media Framework (JMF) 1.0
◇ Java™ Secure Socket Extension (JSSE) 1.0.2
그러므로 두 가지 기반 환경에서 적합성 Test가 진행되어야 한다.
MHP Test Consortium 에서 제공되는 MHP 플랫폼 및 API Test 패키지에
대해서 각 각의 Submission 에 포함되는 Test Case 리스트를 나열하고, 그
Test Case에 대해서Test를 진행한다.
제 2절 테스트 설계
1. MHP 플랫폼 및 API Test
MHP 플랫폼은 4가지 Submission 의 구조로 분류되는데 분류 기준은
모호하나 단 Submission 5.1 은 HAVi Test에 국한 되어 있다. 각각의
리스트들은 다음과 같다.
<표 5‐2> Submission 3.2 리스트
Test 클래스 이름 개수
appmodel.BroadcastApps 4
appmodel.DVBJModel 4
appsig.ApplicationSignalling 18
capabilities.PlatformCapabilities 18
contentformat.MIMETypes 4
contentformat.Static 5
DVBJPlatform.dataaccess 13
DVBJPlatform.fundamentals 4
DVBJPlatform.others 11
DVBJPlatform.permissions 33
- 149 -
11. org.havi.ui.HSinglelineEntryLook 14
org.havi.ui.HSound 1
org.havi.ui.HStaticAnimation 43
org.havi.ui.HStaticIcon 20
org.havi.ui.HStaticRange 43
org.havi.ui.HStaticText 23
org.havi.ui.HStillImageBackgroundConfiguration 6
org.havi.ui.HText 57
org.havi.ui.HTextButton 72
org.havi.ui.HTextLook 17
org.havi.ui.HToggleButton 77
org.havi.ui.HToggleGroup 16
org.havi.ui.HUIException 2
org.havi.ui.HVideoConfigTemplate 10
org.havi.ui.HVideoConfiguration 2
org.havi.ui.HVideoDevice 8
org.havi.ui.HVisible 143
<표 5‐5> Submission 6.1 리스트
Test 클래스 이름 개수
objectcarousel.objectcarousel 5
org.davic.media.SubtitlingLanguageControl 10
org.dvb.dsmcc.DSMCCStreamEvent 5
org.dvb.media.SubtitleAvailableEvent 1
org.dvb.media.SubtitleNotAvailableEvent 1
org.dvb.media.SubtitleNotSelectedEvent 1
org.dvb.media.SubtitleSelectedEvent 1
org.dvb.media.SubtitlingEventControl 3
security.certmgmt 14
2. 적합성 테스트 시스템
테스트 슈트에 포함된 테스트 케이스를 수행하기 위해서 필요한 시스템
환경은 개념적인 모델은 그림 5‐1과 같다.
- 157 -
12. <그림 5‐1> 적합성 테스트 시스템(Conformance Test System)의 개념적인
모델
각 모듈의 정의는 다음과 같다.
● Test Server 각각의 Test Case 들에 관련된 자료(A/V Stream, Test
Application, etc) 보관하는 저장소로서 역할을 수행.
● Test Client Test를 실행하고 그 Test 의 결과를 기록함.
● Broadcast chain Test Application 과 Application 과 관련된 Data를 전송.
Reset for next test 많은 Test Case 들은 하나하나씩 연속적으로
진행되는데 새로운 Test가 진행될 때 마다 Test Client를 초기화를
수행.
● Test log Test Application 에 의해 기록되는 중간 결과 값.
● Test completed/time out Test Application 의 종료 결과 값.
● Access to log Test Application 에 의해 작성된 Log 에 대한 접근.
- 158 -
13. <그림 5‐2> 적합성 테스트 시스템에서의 실행 순서
3. 스트림 생성
한 테스트 케이스에 대해서 하나의 스트림을 생성될 수 있도록 테스트
슈트에서 요구하고 있다. 스트림에 포함되는 요소들은 다음과 같다.
● A/V Source
● Test Application Binary(Library 포함)
● Test Application 에 관련된 환경 설정 파일.
● Test Application 에 관련된 기타 파일(예. Image 파일) (선택사항)
각 각의 테스트 케이스는 스트림을 생성 정보 파일을 제공하고 있다. 그
파일은 Test Class Home Directory(하단 그림에서 표기됨) 에 xml
파일로서 제공된다.
각 각의 Test Case를 수행하기 위해서는 이 xml 파일을 분석하여야 한다.
이 xml 파일의 명명규칙은 Test case 이름c?q?.xml 형태로 구성되며
- 159 -
14. 다음과 같은 기본 정보들을 포함하고 있다.
● A/V Source 파일의 위치.
● PSI/SI 정보(PAT, PMT, NIT, SDT, AIT, etc)
● Object Carousel 되는 파일들에 대한 위치 정보 및 Object Carousel 하는
구성 정보.
이 xml 파일은 dvb‐ts.dtd 의 형식으로 구성된 것인데 제공되는 Test Suite
CD 에는 현재 이 파일이 없는 관계로 MS Explorer Browser 에서 Parsing
에러로 파일 내용이 보이지 않는다. XML 분석 툴을 이용해 DTD를
생성하거나 직접 XML 분석 툴에서 Browsing 하는 방법을 선택하여 내용을
확인하여야 한다.
Root Element
<그림 5-3> Object Carousel 구성정보
Root Element 인 transport‐streams 내에 3 가지의 Child Element 들이
포함된다. 각 각의 Element 내용은 다음과 같다.
- 160 -
15. 가. ocplay‐control Element
A/V Source를 선택할 수 있도록 filename 에 파일 경로를 지정하고
있으며 PAT, NIT, PMT, AIT 의 PID를 포함하고 있다.
<그림 5-4> ocplay‐control Element
나. NIT Element
NIT 에 대한 정보를 담고 있는 Element로서 network ID 와 Network 이름
(다국 언어지원)에 관련된 내용을 포함하고 있는 network‐name‐descriptor를
포함하고 있다.
<그림 5-5> NIT Element
- 161 -
16. 다. transport‐stream Element
Stream 의 전반적인 내용을 담고 있는 Element로서 stream ID, original
network ID, satellite_delivery_system_descriptor, service_list_descriptor,
elementary‐stream element, object‐carousel 의 group 정보,
object‐carousel element, program element를 포함하고 있다.
<그림 5-6> transport‐stream Element
라. elementary‐stream Element
이 Element 에서는 AIT 와 object carousel 을 전송하는 ES 에 대한
정보를 기술한다. AIT 에서 Application 의 control code(Auto start,
Present, etc) 와 Application 식별자(Identifier), application‐descriptor,
application‐name‐descriptor, transport‐protocol‐descriptor‐oc,
dvb‐j‐application‐descriptor, dvb‐j‐application‐location‐descriptor를 내용을
- 162 -
20. 4. 테스트 케이스 구조
테스트 슈트는 복잡한 구조로 다양한 테스트 패키지를 포함하고 복잡한
형태의 디렉토리 구조를 가지고 있다. 그 중 관련 테스트 케이스를
추출하여 스트림 생성작업이 쉬운 일이 아니다. 다음의 구조를
파악함으로써 스트림 생성에 필요한 정보들을 원활히 찾을 수 있게 된다.
<그림 5‐10> 테스트 슈트 전체 디렉토리 구조
- 166 -
21. MHP Test Consortium 에서 제공하는 테스트 패키지는 4가지의
Submission으로 구성되어있다. 각 각의 Submission 들은 중복될 수도
있지만 독자적으로 Image, Library, TS 그리고 각 각의 Test Set 을
포함하고 있다.
<그림 5‐11> 테스트 케이스 디렉토리 구조
- 167 -
22. 각 Test Class Home Directory 에는 각 Test Case 마다 2 종류의
파일이 존재한다. 그 종류는 다음과 같다.
● Stream 생성 정보 XML 파일 ‐ 본 문서 상단에 Stream 생성 부분 참조
● Test 목록 파일. (html, xml) ‐ Test Case 에 대한 일반적인 해설 및
Assertion 내용을 포함하고 있다.
각 Test Case Home Directory 에는 Test Case 에 대한 Test
Application 의 Source Code 와 Test Case 에 대한 실행 정보를 담고
있는 Configuration 파일(testlet.cfg)이 존재한다.
Configuration 파일은 두 단락으로 분할될 수 있다. 첫 번째는 모든
Test Case 에서 동일하게 사용되는 단락과 각 Submission 에서
사용되는 단락으로 분류된다.
모든 Test Case 에서 동일하게 사용되는 단락으로 Test Case Home
디렉토리에 testlet.cfg 파일에 기본적으로 포함된 내용들로서 다음과
같은 내용이다. 별다른 사유가 없다면 변경하지 않는다.
TESTLET_CLASS
Defines the class of this application code.
TESTLET_TEST_ID
The external‐id name of the test purpose as defined by the manifest file (see the Test Manifest
Specification for more details).
TESTLET_TP_NUMBER
The tpnum of the test purpose of this application.
TESTLET_SI_VERSION
The version number used in many SI tables for the first transport stream of the sequence used in
this test purpose.
TESTLET_APP_NUMBER
The application number of this application within this test purpose.
TESTLET_NUM_APPS
The total number of applications within this test purpose.
TESTLET_NO_RES_APPS
A comma separated list of applications in this test purpose that will not supply a result code.
TESTLET_CERT
The certificate used to sign this application, null if the application is not signed.
TESTLET_APP1_CERT
This entry is only found in testlet files that are not application 1. It is the certificate used to sign
application 1, or null if the first application is not signed.
TESTLET_SIGNDIRS
- 168 -
23. A list of directories within the object carousel which are to be signed by the signing tool (invoked
from the test harness). The value is a whitespace separated list. Each item has the form
<algorithm>,<path>,<commandfile>,<cert1>[,<cert2>...]. Each directory specified by <path> needs
to be recursively signed, using the hashing algorithm specified by <algorithm>, and the signing
certificate specified by <cert>.
TESTLET_DEBUG_LEVEL
The level of debugging output to produce in the test application. 0 (or less) indicates no debugging;
10 or more is the most verbose level currently used.
각 Submission 에서 사용되는 단락은 플랫폼에 연관된 Parameter 들을
기술하는 곳이다. 각 testlet.cfg 파일에 포함되어있지 않는 내용이므로
테스트를 진행하는 시스템(사람 포함)에서 이 내용을 포함시켜야 한다.
- 169 -
24. 5. Test Application 구조
한 테스트 케이스 당 하나의 Test Application 이 존재하지만 모든 Test
Application 의 Initial Class 는 org.mhptest.ctl.TestSupervisor 클래스로
획일하게 통일되어있다. 이 클래스는 동적으로 Test Application 의
클래스를 생성하도록 org.mhptest.ctl.BaseTestContext 에 위임한다.
BaseTestContext 클래스는 testlet.cfg 파일에 기술된 Parameter 들과
Value를 저장하고 그 중 TESTLET_CLASS 의 Parameter 의 Value 는
해당 Test Case 의 Test Application 의 클래스명을 나타내는 것이며
TestSupervisor 에서 xlet 의 구동 메소드인 startXlet() 에서
BaseTestContext 에 보관된 이 클래스명을 가져와서 클래스의
인스턴스를 생성하고, TestSupervisor 의 Member 인 Testlet
인터페이스형의 testlet 에 할당한 후에 Testlet 인터페이스의 메소드인
runTest() 메소드를 호출함으로서 Test Application이 구동된다.
<그림 5‐12> Test Application Class Diagram
- 170 -
25. <그림 5‐13> Test Application Sequence Diagram
A. BaseTestContext 클래스가 생성되면서 testlet.cfg 의 포함된
Parameter 와 Value를 읽어와 그 내용을 보관한다.
B. 이 과정은 Java 의 Reflection API를 이용하여 Instance 생성한다.
C. Thread 클래스에서 정의하는 run() 메소드임으로 Thread 환경에서
동작한다.
- 171 -
26. 6. Test 클래스 구현
Test 클래스의 구현은 윗 단락의 클래스 다이어그램에서 도식화된
것처럼 Test Application 의 중간 결과, 최종 종료 상황, Test Server 에
특별한 요청에 대한 메시지를 기록하기 위해서 DVBTest 클래스를
이용한다. 이 부분에 대한 구현은 구현업체에 따라 달라지도록 충분한
확장성을 제공하도록 표준에서는 정의하고 있다.
DVBTest 가 기록하는 메시지는 3 가지로 분류된다.
● Intermediate result Log
● Termination Log
● Prompt Log
<표 5-5> DVBTest 분류
Intermediate Result Log Termination Log Prompt Log
Test Application 실행 Test Application 실행 Test Application 실행중
중에 발생되는 여러 상황을 결과를 기록하는 Log Test Server 와
기록하는 Log 동기화시키는 기능으로서
특정 시점에서 필요한
기능을 요구하도록
기록하는 Log
DVBTest.log() DVBTest.terminate() DVBTest.prompt()
가. 저장 정보 및 구현 방법
Intermediate Result, Termination 에 관한 메시지를 기록하는 Log
에서는 다음과 같은 정보를 추가적으로 선택적으로 기록할 수 있다.
● 구현된 표준문서의 버전
● 컴파일러의 버전 또는 옵션
● 빌드 버전
● time stamp
● 날짜
● 디버깅 정보
- 172 -
27. ● 사용자 정의 정보
Intermediate Result의 메시지는 Test Application 을 구현하는 기관에서
Test Application 의 중간 결과값을 기술하는 이유로 특정한 양식이 존재
하지 않는다. 표준에서는 Message 의 종류를 두 가지로 정의하는데
하나는 String 형태와 int 형태로 제공된다.
Termination 에 관한 메시지는 표준에 몇 개의 값을 미리 정의하고
있다.
● FAIL 테스트 어플리케이션이 성공하지 못하고 종료됨으로써 비표준
방식으로 동작되는 경우.
● HUMAN_INTERVENTION 어플리케이션이 표준에 맞게 동작될 수 없는
상황에서 인위적으로 표준에 맞게 구동될 수 있게 중개를 요청함을
나타내는 경우.
● OPTION_UNSUPPORTED 테스트 환경하에 플랫폼에서 특정 옵션을
포함하지 않는 구현체가 테스트를 적절히 수행하지 않았음을 나타내는
경우. 이 경우의 테스트 결과는 플랫폼의 표준여부를 결정할 때 고려되지
않는다.
● PASS 테스트 어플리케이션이 성공적으로 종료됨으로써 표준 방식으로
동작됨을 나타내는 경우.
● UNRESOLVED 어플리케이션이 수행하기 위해서 반드시 필요한 기능이 셋업
되지 않아 실패했기 때문에 테스트 어플리케이션의 결과가 unknown 이
됨으로써 비표준 방식으로 동작되었을 것으로 추정되는 경우.
● UNTESTED 테스트 어플리케이션이 성공적으로 실행되었으나 특정 테스트의
수행되지 않는 경우.
Prompt 관한 메시지는 Server 에 특정 기능을 요청하는 것으로서 Test
Application 이 수행 중에 현재 Presentation 되는 A/V 영상을 확인을
요청할 수 있고 또는 Remote Controller 의 입력이 필요한 경우를
메시지로 기록하는 것이다. 자동화된 시스템의 경우 이를 분석하여
자동으로 A/V 영상을 저장하거나 Remote Controller의 키 입력을 시도할
것이며 수동화된 Test 환경에서는 사람이 직접 이 Log를 확인하고 Log
내용을 토대로 수행하게 될 것이다. 이에 관련해서 몇 개의 동작에
- 173 -
28. 대해서 기정의 하고 있는 내용은 다음과 같다.
● PROMPT_START_VIDEO_CAPTURE
● PROMPT_STOP_VIDEO_CAPTURE
● PROMPT_START_AUDIO_CAPTURE
● PROMPT_STOP_AUDIO_CAPTURE
● PROMPT_RC_SEQ
● PROMPT_PLAY_TS
Intermediate Result, Termination 에 관한 메시지를 기록하는 Log 에
대한 구현 방법은 표준에서 어떤 형태로 지정하지 않고 있다. 다만 각
플랫폼에 맞는 가장 효과적은 방법을 선택하여 구현하는 확장성을
제공한다. 다음은 표준에서 정의 하는 여러 구현 방법에 대한
리스트이다.
● local file system
● remote file system
● RAM disk
● RS‐232
● IP/UDP 기반의 Remote Host
Prompt 관한 메시지는 기록하는 방법은 위 두 개의 메시지를 기록하는
방법과 약간 다르다. 표준에서 권고하는 예는 다음과 같다.
● RS‐232(도는 다른 방식의 시리얼 포트) 통신
● IP/UDP 기반의 메커니즘
● 테스트 진행자
- 174 -
29. 나. 간단한 DVBTest 클래스의 구현
DVBTest 클래스의 구현의 방식이 표준에서 정의한대로 여러 가지
존재한다. 가장 간단한 예는 로컬 시스템에서 메시지를 구현하도록 하는
것이다. 각 각의 Log 들은 통합하거나 따로 분리해서 처리도 가능하다.
현재 구현된 방식은 Logger 라는 추상 클래스를 통해 모든 동작을
정의하고 실제 사용되는 Concrete 클래스는 이를 상속하여 정의함으로
원격 파일 시스템을 이용하거나 RAM disk 또는 RS‐232 통신 및 IP/UDP
통신을 이용할 수 있도록 한다. 가장 간단한 예로 File을 이용하는 예로
다음과 같이 구성하였다.
이 Logger 클래스를 DVBTest 클래스에서 Composition하여 Framework
기반의 프로그래밍(Concrete 클래스를 직접 사용하지 않고)을 하는데
상황에 따라서 다양한 Concrete 클래스를 생성할 수 있는 확장성을
가지게 된다.
- 175 -
31. 제 3절 테스트 수행
1. Test Case 실행 순서.
다음과 같은 순서에 의해 테스트를 수행한다.
① testlet.cfg 구성
② Signed Test 의 경우 signature 그리고 hash 파일을 재생성함.
③ testnamec?q?.xml 에 기술된 것처럼 A/V 소스, Application,
Application Data 와 SI 정보를 포함시켜 Stream 을 생성.
④ 생성된 stream 을 전송.
⑤ 수신되는 STB 에서 xlet 실행.
위 실행순서를 기반으로 하여 특정 Case를 선택하여 Local Test를
진행하였다. 실제 진행된 내용은 다음과 같다.
대상
◇ MHPTC_32
▷ org.dvb.media.VideoTransformation.VideoTransformation120
순서
① Testlet.cfg을 찾아 들어갈 파라미터 설정.
TESTLET_DEBUG_LEVEL=0
TESTLET_CLASS=org.mhptest.tset.org.dvb.media.VideoTransformation120
TESTLET_TEST_ID=DVB‐org.dvb.media.VideoTransformation‐120
TESTLET_TP_NUMBER=120
TESTLET_SI_VERSION=5
TESTLET_APP_NUMBER=1
TESTLET_NUM_APPS=1
TESTLET_NO_RES_APPS=
TESTLET_CERT=
TESTLET_SIGNDIRS=
MHP_EB_PROFILE_SUPPORTED=true
MHP_IB_PROFILE_SUPPORTED=false
MHP_IA_PROFILE_SUPPORTED=false
- 177 -
32. MHP_BROADCAST_IP_MULTICAST_SUPPORTED=false
MHP_SUPPORTS_DSMCC_ON_RC=true
MHP_SUPPORTS_HTTP_ON_RC=false
MHP_SUPPORTS_CONTROLS_ON_DRIPFEEDDATASOURCE=true
MHP_SUPPORTS_CLIPPING=true
MHP_SUPPORTS_ARBITRARY_VERTICAL_SCALING=true
MHP_SUPPORTS_ARBITRARY_HORIZONTAL_SCALING=true
MHP_FULL_SCREEN_WIDTH=320
MHP_FULL_SCREEN_HEIGHT=240
MHP_DISPLAY_ASPECT_RATIO=4:3
MHP_DFC_LB_14_9_SUPPORTED=false
MHP_DFC_LB_2_21_ON_16_9_SUPPORTED=false
MHP_DFC_LB_2_21_ON_4_3_SUPPORTED=false
MHP_JAVA2_SUPPORTED=true
MHP_INTERLACED_VIDEO_POSITION_RESTRICTED=false
MHP_SUPPORTS_VIDEO_POSITION_ANYWHERE=false
MHP_SUPPORTS_VIDEO_POSITION_ANYWHERE_ON_SCREEN=false
MHP_SUPPORTS_VIDEO_POSITION_ANYWHERE_ON_SCREEN_EVEN_LINES=fals
e
MHP_SUPPORTS_DSMCC_PREFETCHING=true
MHP_CAROUSEL_FORMATID=true
MHP_OVERLAPPING_HSCENE_COMPONENTS_SUPPORTED=true
MHP_COMPONENT_BASED_JMF_PLAYERS_SUPPORTED=false
MHP_NUM_NETWORK_INTERFACES=1
MHP_DELIVERY_SYSTEM_TYPE=sat
MHP_DE_IS_TIME_STAMPING=true
MHP_MEDIA_TYPE_GIF_SUPPORTED=true
MHP_TXT_LINE_ORIENTATION_VERTICAL_SUPPORTED=false
MHP_TXT_START_CORNER_UPPER_RIGHT_SUPPORTED=false
MHP_TXT_START_CORNER_LOWER_LEFT_SUPPORTED=false
MHP_TXT_START_CORNER_LOWER_RIGHT_SUPPORTED=false
MHP_SINGLE_SERVICE=true
MHP_EIT_BASE_TIME=1000000
MHP_XLET_DEBUG=1
② VideoTransformation120c1q1.xml 파일에서 object‐carousel
element에 들어가는 파일들을 찾아서 임시 디렉토리에 구조에
맞게 복사한다. 다음과 같은 디렉토리 구조로 구성되면 각 각의
디렉토리내에 xml 파일에 기술된 파일들이 들어가게 된다.
- 178 -
33. <그림 5‐15> VideoTransformation120 디렉토리 구조
③ 이 파일을 STB 의 /dvbmw/classes 에 업로드한다.
④ /dvbmw/apps/objectCarousel/ 디렉토리에는 전송된 Application
을 보관하며 최초 실행되는 Entry Point 로서 이 곳에 testlet.cfg
파일을 복사한다. Initial Class 인 Test Supervisor 의
BaseTestContextClass 에서 이 파일을 참조하기 때문이다.
⑤ /dvbmw/src/com/iset/main/Main.java 의 main() 내에 runXlet()
메소드는 class 이름이나 locator를 Argument 로 받는데 이
메소드는 실제 M/W 구동될 때 기본적으로 실행되는 Application
을 지정하는 기능을 가지고 있다. 그러므로 Test Application 을
통일된 Initial Class 명을 Argument로 전달하여야 한다. 즉
org.mhptest.ctl.TestSupervisor 으로 코드를 수정한다.
⑥ /dvbmw 디렉토리로 이동해서 build를 수행한다.
/dvbmw# bin/build
⑦ M/W 기동하면서 항상 /dvbmw/apps/objectCarousel 디렉토리의
내용을 모두 삭제하도록 Shell Script 가 구성되어있다. 하지만 이
곳에서 참조하는 testlet.cfg가 지워지므로 Shell Script를
수정한다.
#!/bin/bash
#read config file
exportd config file
- 179 -
34. export DISPLAY=:0.0
export DTVMW_HOME=/dvbmw
. $DTVMW_HOME/conf/system.conf
echo reading config $DTVMW_HOME/conf/system.conf
#set java
JAVA=$JAVA_HOME/bin/java
# remove all existing message queue
rmq.sh
# run middleware
echo Starting DTV Middleware
echo using CLASSPATH = $CLASSPATH
echo $CLASSPATH
cd /dvbmw/apps/objectCarousel
#rm ‐rf * 이 부분을 주석으로 처리한다.
$JAVA $JAVA_OPTIONS ‐Djava.library.path=$DTVMW_HOME/lib
‐Ddtvmw.home=$DTVMW_HOME
com.iset.main.Main
DISPLAY=:0.0
⑧ /dvbmw 디렉토리에서 M/W 를 실행한다.
/dvbmw# bin/mwstart
⑨ 실행 결과를 확인한다.
실행 결과
DVBTest Class 에서 Composition 된 Logger 클래스의 Concrete
클래스인 FileLogger 는 메시지 기록을 /dvbmw/logs/ 디렉토리에
testsuite.log 라는 파일에 기록하고 있다. 이 파일을 해당 결과를
확인한다.
MHP Specification Version 1.0.1
Java Compiler Version 1.3.1
REQ TERMINATION(id, terminationCondition) :
(DVB‐org.dvb.media.VideoTransformation‐120 PASSED)
- 180 -