Stop! 윈도우 임베디드 CE 시스템 개발! ①

글 : 라영호 / ratharn@naver.com연재 차례1. 윈도우 임베디드 시스템 테스팅2. 부트로더를 통한 개발 준비3. 빌드이야기4. 윈도우 임베디드 CE 6.0 커널 이야기5. 디바이스 드라이버 개발 6. 디스플레이 디바이스 드라이버 7. 원도우 임베디드 시스템, 3D의 세계로... 8. 플래시 메모리를 저장 장치로 9. GPS 디바이스 드라이버의 개발 10. 선 없는 세상으로 11. 멀티미디어 세상속으로-I 12. 멀티미디어 세상속으로-II>>필자소개필자는 윈도우 모바일 관련 스마트폰 개발과 윈도우CE 관련 장치를 개발하고 있다. 개인적으로 운영하고 있는 윈도우CE에 관한 블로그(www.embeddedce.com)를 통해 윈도우CE 개발에 대한 다양한 생각과 방법론을 함께 생각해 보고자 노력 중이다. 아울러 윈도우CE의 포팅 뿐만 아니라 개발에서부터 최종 제품이 나오기까지 거쳐야 할 다양한 테스트 및 신뢰성 문제에도 관심을 가지고 있다.이번호는 실무에 적용할 수 있는 윈도우 임베디드 CE 시스템 개발, 그 첫 회로서 윈도우 임베디드 CE 운영체제에서의 테스트에 관한 사항에 대해 알아보도록 하겠다.흔히들 개발의 단계에서 디버깅이라는 단계를 항상 추가한다.개발한 소프트웨어나 하드웨어를 디버깅 및 테스트를 통해 문제가 없는지 검증하게 된다. 물론 디버깅 및 테스트 없이 완벽한 제품이 나올 수 있다면 그것처럼 더 좋은 일이 없을 것이다. 이런 과정을 피하기 위해서 4세대 언어(4GL)니 각종 새로운 언어 및 개발툴이 등장했지만 실제 효과나 유용성면에서 아직까지 큰 이점을 제공해 주진 못했다.임베디드 시스템 개발에 있어서도 여러 가지 방법을 도입하고는 있지만 실제 적용에는 미진한 부분이 많다. 하지만 임베디드 시스템의 크기나 용량이 PC와 비슷한 정도의 성능에 육박하고 있는 상황에서 앞으로 개발의 효율성을 올리기 위한 방법론이나 기법들을 도입해야 할 것으로 생각된다. 임베디드 시스템이나 일반 PC용 응용 프로그램이나 이러한 주제는 동일할 것이다. 하지만 뭐니 뭐니 해도 잘 설계된 설계를 바탕으로 안정적인 시스템을 만드는 것이 먼저라는 것은 잊어버리지 말아야겠다.윈도우 임베디드 시스템을 수년간 개발하면서 이전 임베디드 시스템 개발에 비해 다소 해택을 받는 느낌이 있다는 것은 개발툴에 관련된 사항들이다. 비주얼 스튜디오로 플랫폼을 개발하고, 플랫폼 빌더를 통해 운영체제 및 관련 구성 요소를 구성하고, 플랫폼 빌더를 통해 운영체제를 디버깅한다. 이러한 개발 툴의 일관성은 임베디드 시스템이라는 한정된 개발 환경에서 개발의 효율성을 높여주는 역할을 했다. 하지만 가장 돋보이는 점의 하나는 개발 환경에서 부터 테스트 환경까지 일관되게 할 수 있다는 점이다.윈도우 임베디드 CE 운영체제에서의 테스트윈도우 임베디드 CE 운영체제를 탑재한 시스템도 물론 테스트를 해야 한다. 제품에 따라서는 LCD가 장착된 PMP나 내비게이션 시스템과 같은 시스템이 있을 수도 있고, 버튼만 장착된 시스템일 수도 있다. 시스템의 사양에 따라 적절한 테스트를 해야 한다. “구슬이 서말이라도 꿰어야 보배가 된다”는 말처럼 윈도우 임베디드 시스템에 아무리 좋은 개발툴이 있더라도 잘 활용을 못하면 무용지물이다. 윈도우 임베디드 CE 시스템에서 개발툴 중의 하나인 CETK를 잘 활용할 수 있는 방법에 대해 살펴보도록 하겠다. CETK는 개발한 윈도우 임베디드 시스템을 자동으로 테스트 할 수 있게 하는 개발툴이다. 그럼 이 CETK에 대해 자세히 살펴보도록 하자.CETK란?CETK는 한마디로 말해서 윈도우 임베디드 CE 시스템의 운영체제 요소를 테스트하기 위한 테스트 툴이다. 윈도우 임베디드 CE 운영체제를 개발한 하드웨어에 포팅이라는 작업을 통해 운영체제가 제대로 동작하도록 만든다. 여기에 디바이스 드라이버 및 응용 프로그램을 개발하고 잘 동작하도록 만든다.이러한 과정이 윈도우 임베디드 CE 운영체제를 가지고 임베디드 CE 시스템을 개발하는 과정이다. 개발한 임베디드 시스템에서 운영체제가 제대로 동작하는지 검증하는 툴이 CETK이다. 다시 말해 CETK는 윈도우 임베디드 CE 운영체제가 개발한 임베디드 시스템에서 제대로 동작하는지 검증하는데 사용한다. 하지만 주의해야 할 것은 CETK를 이용해 테스트를 하고, 그 결과가 모드 ‘통과’라는 결과를 얻더라도 개발한 윈도우 임베디드 CE 시스템이 완벽하고 안정적이라는 것을 검증하는 테스트는 아니다. CETK는 윈도우 임베디드 CE 개발 중에 테스트해야 할 한 항목에 불과 하다는 것이다. 물론 확장 가능성이 있기 때문에 추후 개발한 디바이스 드라이버나 다른 기능의 테스트를 위해 만들 수도 있다. 따라서 MS 윈도우 CE 운영체제의 호환성 테스트 및 자동화 테스트 툴로써 이용할 수 있다. <그림 1>는 CETK의 동작 화면으로써 PC에서 동작하는 그림이다.CETK의 기능을 간단히 살펴본다면 다음과 같다.* 플랫폼 빌더에 포함된 소프트웨어 툴* 윈도우 임베디드 시스템에서 테스트를 위한 전체 프레임 웍(임베디드 시스템에서 부터 테스트를 관장하는 PC용 프로그램까지)* 개발한 윈도우 임베디드 시스템 운영체제를 자동/또는 수동 설정에 의해 자동으로 테스트 할 수 있도록 하는 도구* 사용자가 정의 및 지정한 테스트를 만들 수 있다.* 운영체제 및 임베디드 시스템의 사용 시나리오에 따라 테스트 할 수 있도록 함 * 운영체제 스트레스 툴(Stress Tools)* 응용 프로그램 검증 툴(Application Verifier)CETK로 테스트 할 수 있는 항목윈도우 임베디드 CE 운영체제에 포함되는 운영체제 요소 및 드라이버가 다양한 것처럼 CETK도 다양한 테스트 항목을 가지고 있다. CETK를 제대로 동작시킨다면 테스트만 수 시간이 걸릴 정도로 많은 테스트와 테스트 과정을 가지고 있다. 윈도우 모바일 운영체제의 경우 LTK(Logo Test Kit)를 반드시 통과하고 그 결과에 따라 윈도우 모바일 운영체제를 탑재한 장치를 판매할 수 있다. 하지만 윈도우 임베디드 CE 운영체제의 경우에는 그러한 MS의 제약이 없기 때문에 자유롭게 테스트를 한 후 테스트 결과에 따라 어느 정도 개발이 되었고 안정성이나 호환성을 유지하는지 검증하는 용도로 사용할 수 있다. CETK는 아래처럼 3가지의 큰 테스트 종류로 구분할 수 있다. 각각의 항목에 따라 어떠한 테스트가 있는지 살펴보도록 하겠다.(1) 디바이스 드라이버 테스트- 오디오, 블루투스, 카메라, CDMA, 이더넷, 파일 시스템, 키보드, 터치 등(2) 커널 및 OAL 테스트- 커널의 안정성 및 OAL 호환성 테스트, OAL IOCTL 테스트 등(3) 성능 및 안정성 테스트- 멀티미디어 테스트, NDIS, RDP, Winsock 성능 테스트, 안정성 테스트 등<그림 2>와 <그림 3>은 CETK를 이용하여 윈도우 임베디드 CE 운영체제의 디스플레이 드라이버를 테스트하는 화면이다. LCD 화면에 윈도우 임베디드 CE의 다양한 그래픽 함수를 이용해 잘 동작되는지 테스트 하는 장면이다.이처럼 CETK로 다양한 테스트를 할 수 있다. 또한 사용자가 개발한 사용자 정의 테스트 항목을 추가하여 테스트 할 수 있는 기능을 가지고 있다. CETK를 이용하여 윈도우 임베디드 시스템을 테스트 하는 가장 큰 이유는 개발하는 임베디드 시스템에 탑재된 윈도우 임베디드 CE 운영체제가 추구하는 기본적인 호환성에 적합한지 테스트하는데 있다. 윈도우 임베디드 CE 시스템에는 많은 수의 디바이스 드라이버가 포함된다. 디스플레이 드라이버, 시리얼 드라이버, USB 드라이버 등 각종 디바이스 드라이버들이 포함된다. 프로세서 제조 업체에서 제공해준 BSP에 포함된 드라이버이외에 개발자가 추가해서 제품으로 만들어야 할 경우가 생긴다. 이럴 경우 만든 디바이스 드라이버가 MS의 표준에 제대로 따라가고 있는지 기능 구현에 문제가 없는지 테스트 하는데 사용된다. 또한 기능 구현이외에도 반복으로 읽기/쓰기를 통하여 드라이버가 안정적인지 검증하는데도 사용할 수 있다.CETK를 이용한 윈도우 임베디드 시스템 테스트지금부터 윈도우 임베디드 CE 운영체제를 이용하여 시스템을 개발하고 CETK를 이용하여 테스트 하는 방법에 대해 살펴보도록 하겠다. CETK를 이용하여 테스트를 할 수 있는 환경은 우선 윈도우 임베디드 CE 운영체제가 동작하는 환경이 구성이 먼저 되어야 한다. 그 다음 중요한 요소는 CETK와 윈도우 임베디드 CE 운영체제가 탑재된 장치를 연결하는 방법을 구축해야 한다. 윈도우 임베디드 CE 운영체제에서는 KITL(Kernel Interface Transport Layer)라는 운영체제와 임베디드 시스템간의 통신 프로토콜을 사용해 이더넷, USB, 시리얼을 통해 통신할 수 있는 방법을 제공한다. 보통 실제 개발 중에는 이더넷이나 USB를 통하여 통신을 하고 테스트 하는 방법을 사용한다. 또한 PC와 윈도우 임베디드 CE 장치간 통신을 하는 대표적인 방법인 액티브싱크(ActiveSync)를 통해서도 CETK를 사용할 수 있다. 액티브 싱크(ActiveSync)를 통한 테스트 방법은 장치가 개발된 후에 USB를 통해 간편하게 접속해서 테스트 할 수 있는 장점을 제공한다. 보통 KITL을 통한 테스트 방법은 개발 중에 CETK를 통해 문제점이 있는지 확인하기 위해서 사용하고, 액티브 싱크를 통한 방법은 최종 단계에서 검증을 위해 사용한다. CETK를 이용하여 테스트 하는 절차는 다음과 같다.(1) 윈도우 임베디드 CE 플랫폼 구성일반적으로 CETK를 활용해서 테스트하기 위한 환경은 플랫폼 빌더를 통하여 윈도우 임베디드 CE 운영체제를 구성하고 동작하는 환경이 먼저 있어야 한다. KITL이나 액티브 싱크를 통하여 테스트할 임베디드 시스템과 통신할 수 있어야 한다.(2) CETK 연결 구성CETK를 사용하기 위한 연결 방법을 구성한다. 앞에서 설명했듯이 CETK는 KITL이나 USB를 통해서 연결할 수 있다. KITL을 통해서 연결할 경우에는 플랫폼 빌더에서 시스템의 상태를 보면서 CETK가 동작하는 내용을 확인할 수 있다는 장점이 있다. 보통 개발 중에는 KITL을 통해 CETK를 테스트 하고 어느 정도 완성 단계에서는USB를 통한 엑티브 싱크를 통한 연결을 사용한다. 다음 그림은 USB를 통하여 CETK를 연결하는 모습을 보여준다. CETK가 테스트 하려는 장비와 연결되면 자동으로 테스트 가능한 기능에 대해 검사를 한다. 운영체제에 포함된 디바이스 드라이버에 따라 테스트 가능한 모듈, 테스트 불가능한 모듈에 대한 검사를 하고 CETK 테스트 항목에서 선택할 수 있도록 테스트 항목 목록을 만들게 된다.연결이 되면 PC와 연결된 임베디드 CE 장치는 <그림 5>와 같이 CETK를 테스트 할 수 있는 준비 상태가 된다.(3) CETK 테스트 설정 및 테스트이제 CEKT에서 어떠한 테스트를 할지 설정해야 한다. CETK는 CETK와 연결된 장치에 따라 자동으로 어떠한 테스트를 할 수 있는지 검사하게 된다. 검사 결과에 따라 테스트 할 테스트 항목이 표시되게 된다. CETK 검사 항목을 선택 또는 해제를 통해 테스트 진행을 하게 된다. 선택된 테스트 항목은 CETK 메뉴의 TestsStart/Stop Tests 명령을 통해 테스트를 진행한다. 테스트를 진행하는 동안 테스트 하는 항목은 <그림 6>과 같이 진행 중임을 표시한다.(4) CETK 결과 분석 및 수정전체 테스트는 수 시간이 걸린다. 테스트 및 시스템 상태에 따라 테스트 시간은 달라진다. 테스트에 대한 결과는 ‘Tests’ 명령의 ‘View Results’ 명령을 통하여 테스트 결과를 확인 할 수 있다. 테스트의 결과는 PASSED 및 FAILED 형태로 표시가 된다. 만약 테스트가 제대로 이루어지지 않으면 SKIPPED라는 형태로 테스트가 제대로 이루어지 않았다고 표시된다.CETK에서 생긴 일CETK를 통하여 하는 테스트 중에 대부분의 테스트가 ‘Pass’라는 결과가 로그 파일에 나오며 테스트의 성공을 알릴 것이다. <그림 7. CETK 결과> 참조. 하지만 CETK의 모든 테스트를 통과 하기는 결코 쉽지는 않다. 물론 CETK가 제품에 탑재된 윈도우 임베디드 CE 운영체제의 안정성이나 품질을 보장하는 것이 아니기 때문에 굳이 테스트를 해야 하는 의문이 들 수도 있다. 사실 개발 초기에 받은 프로세서 업체에서 받은 프로세서에 대한 BSP(Board Support Package)도 CETK를 완전히 통과하는 경우도 드물다. 따라서 BSP와 함께 제공된 문서에 있는 해당 BSP에 대한 테스트 결과를 확인하고 개발을 진행해야 한다(윈도우 임베디드 CE 운영체제 5.0 이후부터는 BSP에 대한 기준이 강화되어서 예전보다는 안정된 상태의 BSP를 제공받을 수 있다). 윈도우 임베디드 시스템을 개발하던 수년전 이러한 내용을 모르고 개발에 시작했던 시절이 있다. BSP가 다 해줄 것이라는 믿음과 윈도우 임베디드 CE 운영체제가 만능일 것이라고 생각했던 시절이었다. 이러한 믿음이 깨지기 시작한 것은 오랜 시간이 걸리지 않았다. 테스트 중간에 발생되었던 많은 문제점들 또한 이러한 문제점으로 인해 생기는 알 수 없는 버그들…….BSP가 가지고 있는 문제점이 제대로 해결되지 않은 상태에서 칩 회사에서 BSP 릴리스 되었고 개발 중에 이 문제들 때문에 많은 고생을 했었다. 윈도우 임베디드 CE 운영체제가 5.0, 6.0, 6.2 버전으로 업그레이드되면서 BSP에 관한 정책이 바뀌어서 이런 문제는 발생하지 않을 것이다. 따라서 칩 업체로부터 제공받는 BSP는 대부분 CETK 테스트를 거쳐 어느 정도 안정성을 검증 받거나 테스트 결과를 BSP와 같이 주는 형태로 변했다. 이제야 비로소 안정적인 BSP를 바탕으로 개발을 시작하고 개발된 결과를 CETK를 통해서 재 검증하는 시기가 왔다.CETK의 문제점 해결하기CETK에서 ‘FAILED’로 나오는 문제점은 과연 어떠한 방식으로 해결해야 할까? 하는 의문이 들 것이다. CETK의 테스트는 윈도우 임베디드 CE 운영체제의 각종 API나 기능을 테스트 한다. 따라서 윈도우 임베디드 CE 운영체제가 요구하는 스펙에 맞는다면 대부분 테스트는 통과할 것이다. 하지만 모든 드라이버를 윈도우 임베디드 CE 운영체제를 만든 개발자가 아닌 이상 완벽하게 스펙에 맞게 작성한다는 것은 불가능하다. 사실 제대로 이해하고 작성하는 것도 시간이 많이 걸리는 작업이다. 따라서 우선은 드라이버에 대한 정확한 이해가 필요하다. 그 이후 문제가 생기는 테스트의 내용을 파악해야 한다. CETK 테스트 대부분은 소스 형태로 제공되기 때문에 테스트 결과 파일만 제대로 확인하면 CETK의 어떤 테스트를 하다 문제가 생겼는지 확인할 수 있다. CETK 테스트에 관련된 소스는 플랫폼 빌더를 설치하면 생성되는 소스 ‘WINCE600PrivateTest’에서 확인할 수 있다.쪾 테스트 결과 파일을 통해 어떠한 테스트가 문제가 발생 하였는지 확인쪾 CETK 소스 파일을 통해 테스트 방법 확인쪾 문제점 확인 및 수정을 통해 해당 문제 해결쪾 CETK 재 테스트를 통해 해당 문제 해결되었음을 확인사용자 정의 테스트지금까지는 플랫폼 빌더에 포함된 CETK를 어떻게 사용하는가 하는 관점에서 접근 했다.윈도우 임베디드 CE를 플랫폼 운영체제로 사용해 봤던 개발자라면 대부분 한번쯤 해 봤을 만한 과정이다. 이제는 여러분이 만든 디바이스 드라이버를 어떻게 CETK에 테스트 할 수 있는가에 대해 살펴보도록 하겠다. 궁극적인 목표는 사용자가 만든 디바이스 드라이버나 프로그램 모듈을 CETK를 이용하여 테스트 하는 것이 목적이기 때문이다. CETK를 통해 테스트 자동화를 통해 개발 및 시스템 설계에 시간을 더 쏟고 테스트는 CETK를 통해 자동화 하는 방법을 안다면 좀 더 효율적인 개발이 이루어질 것이다.테스트의 관점은 여러 가지 있을 수 있다. 실제 기기를 사용하는 사용자의 관점, 버그를 발견해야 하는 Q/A(Quality Assurance) 부서의 테스터의 관점, 생산 준비를 위한 생산 테스트 관점, 개발자의 관점 등 모두 제품을 만들고 만든 제품이 잘 동작하도록 하는데 가장 큰 목적이 있다. 그러다 보니 각자의 입장에서 문제점을 보는 입장이 달라진다. 개발자에게는 사소한 버그지만 생산을 담당하는 담당자에게는 큰 버그로 인식될 수 있다.이러한 관점의 차이는 테스트 과정의 표준화 및 테스트 항목을 잘 정의하는 것으로 부터 차이점을 줄일 수 있다.실례로 필자가 겪었던 윈도우 임베디드 모바일 운영체제에 대한 테스트 과정을 예로 들 수 있다. 윈도우 모바일 장치가 흔하지 않았던 시절 윈도우 모바일 장치를 테스트하는 과정은 일반 핸드폰과는 다르게 다른 접근이 필요했었다. 하지만 일반 핸드폰에 익숙해 있던 테스터 및 품질 관리자들은 일반 핸드폰에 관련된 테스트 방법을 그대로 적용해 테스트를 진행했었다. 그러다 보니 대부분이 문제가 생겼다. 최종 제품이나 사용자 관점에서 보면 일반적인 핸드폰과 동일한 테스트 방법 및 테스트 절차가 적용되어야 한다. 하지만 윈도우 모바일 운영체제의 관점에서 보면 일반적인 핸드폰 운영체제와는 다른 사용자 인터페이스 및 동작 환경이 있다. 따라서 테스트 방법이나 절차에 이러한 차이점을 염두해 두어야한다. 이와 같이 테스트 방법이나 테스트 관점에서 여러 가지 차이점 및 시스템 환경을 고려해야 한다.CETK는 윈도우 임베디드 시스템에 있어서 운영체제 및 디바이스 드라이버적인 측면을 테스트 할 수 있는 가장 좋은 툴이다. 따라서 윈도우 임베디드 CE 시스템에서 디바이스 드라이버나 운영체제에 포함된 컴포넌트를 개발할 때 CETK에 포함되지 않은 테스트 구성 요소를 포함시키고 자동으로 테스트 할 수 있게 하는 방법을 사용할 수 있다.CETK를 이용하여 사용자 정의 테스트 만들기지금까지는 CETK를 이용하여 어떻게 잘 이용할 것인가에 대해서 살펴봤다. 하지만 CETK에 개발하는 모든 드라이버를 테스트를 할 수 없다. 따라서 CETK 내에 개발자가 개발한 드라이버나 기능에 대해 테스트를 할 수 있는 기능을 추가하는 방법에 대해 알아야 한다. 지금부터 사용자가 개발한 디바이스 드라이버를 어떻게 CETK에 포함시키고 테스트 루틴을 추가하는지에 대해 살펴보도록 하겠다.스트림 인터페이스 드라이버스트림 인터페이스 형식의 디바이스 드라이버는 윈도우 임베디드 CE 운영체제에서 가장 많이 사용되는 형식의 디바이스 드라이버이다. 파일처럼 디바이스 드라이버를 열고 작업을 할 수 있다는 장점이 있다. 스트림 인터페이스 형태의 드라이버는 다음과 같이 레지스터리 등록을 통해 디바이스 드라이버를 운영체제에 등록하게 된다.[HKEY_LOCAL_MACHINEDriversBuiltInStreamDrv]“Dll” = “StreamDrv.Dll” “Prefix” = “DEM”“Order” = dword:0“FriendlyName” = “StreamDrv Driver”“Ioctl” = dword:0CETK에서 테스트로 사용할 디바이스 드라이버는 ‘DEM’이라는 프리픽스를 갖는 디바이스 드라이버이다. 이 드라이버는 DEM_Deinit(), DEM_Open(), DEM_Close(), DEM_IOControl()이라는 함수들을 드라이버 내에 가지고 있다. 다음 소스는 이 드라이버에서 사용되는 함수들의 소스이다.BOOL DEM_Deinit(DWORD hDeviceContext){OutputDebugString(L”StreamDrv - DEM_Deinitn”);OutputDebugString(L”StreamDrv - ~ DEM_Deinitn”);return TRUE;}// Driver OpenDWORD DEM_Open( DWORD hDeviceContext, DWORD AccessCode, DWORD ShareMode ){OutputDebugString(L”DemoDriver - DEM_Openn”);OutputDebugString(L”hDeviceContext - “);DBGOut(hDeviceContext);OutputDebugString(L”n”);OutputDebugString(L”DemoDriver - ~ DEM_Openn”);return 0x5678;}BOOL DEM_IOControl( DWORD hOpenContext, DWORD dwCode, PBYTE pBufIn, DWORD dwLenIn, PBYTE pBufOut, DWORD dwLenOut, PDWORD pdwActualOut ){ // 중략}CETK 테스트 프로젝트 생성‘New Project or File’ 명령을 통해 새로운 프로젝트를 시작한다. ‘WCE TUX Dynamic-Link Library’ 프로젝트를 통하여 앞에서 만든 스트림 인터페이스 드라이버를 테스트 할 테스트 DLL을 생성한다. 이 프로젝트를 통해 생성되는 소스는 ‘TuxTest.DLL’로 만들어지며 CETK를 통하여 디바이스 드라이버를 테스트하기 위한 테스트 모듈로 사용된다. CETK에서 디바이스 드라이버를 테스트 하는 방법은 디바이스 드라이버에 해당되는 테스트 DLL(Tux DLL이라고 함)을 통하여 테스트 할 디바이스 드라이버들을 테스트 하는 것이다.앞에서 테스트 DLL 프로젝트를 통해 여러 소스가 생성된다. 각 소스는 CETK를 통해 어떻게 테스트 할 것인가를 지정하는 소스들이다. 우선 가장 먼저 살펴봐야 할 소스 및 내용은 ‘FT.h’다. ‘FT.h’는 테스트 할 함수에 대한 정의와 테스트 시 사용될 함수들을 정의하는 용도로 사용된다.FT.hFTH, FTE라는 매크로를 통해 테스트 내용 및 테스트 함수를 정의한다.// CETK 테스트 관련 함수DWORD TuxActivateDevice(LPHANDLE lpDriver);DWORD TuxDeactivateDevice(HANDLE hDriver);BEGIN_FTEFTH(0, “Sample stream driver basic functionality test cases”)FTE(1, “Register / Deregister Device Test”, 1, 0, ActivateDeviceTest)FTE(1, “Open driver for stream access”, 2, 0, LoadUnload) // 중략FTH(0, “Sample stream driver read / write tests”)FTE(1, “Simple Read Write”, 30, 0, SimpleReadWrite Test)FTH(0, “Sample stream driver custom function tests”)FTE(1, “Custom Function Tests”, 40, 0, CustomFunc tionTest)FTH(0, “Sample stream driver performance tests”)FTE(1, “Performance Test”, 60, 0, PerformanceTest)END_FTETest.Cpp앞에서 정의한 테스트 내용을 실제로 구현하는 소스다. 각 테스트는 C/C++의 소스로 이루어지며 CreateFile( _T(“DEM1:”) 호출을 통해 테스트 하려는 함수를 호출하여 실제 테스트를 진행하게 된다.TESTPROCAPI LoadUnload(UINT uMsg, TPPARAM tpParam, LPFUNCTION_TABLE_ENTRY lpFTE){ HANDLE hDriver = INVALID_HANDLE_VALUE; DWORD tprResult = TPR_FAIL; // 중략 UINT loopCount = (UINT)lpFTE->dwUserData; for (UINT i = 0; i <= loopCount; i++) { hDriver = CreateFile( _T(“DEM1:”), 0, 0, NULL, OPEN_EXISTING, 0, NULL ); if (INVALID_HANDLE_VALUE == hDriver) { g_pKato->Log(LOG_FAIL, TEXT(“Failed to open stream driver DEM1: on iteration %u”), i); } else { if (FALSE == CloseHandle(hDriver)) { g_pKato->Log(LOG_FAIL, TEXT(“failed to close stream driver DEM1: on iteration %u”), i); } else { g_pKato->Log(LOG_PASS, TEXT(“Successfully opened and closed stream driver.”)); tprResult = TPR_PASS; } } if(TPR_PASS != tprResult) break; } return tprResult;}// 테스트 디바이스 드라이버를 읽고 쓰기 반복 테스트 하는 함수TESTPROCAPI SimpleReadWriteTest(UINT uMsg, TPPARAM tpParam, LPFUNCTION_TABLE_ENTRY lpFTE){HANDLE hDriver = INVALID_HANDLE_VALUE;DWORD tprResult = TPR_PASS;TCHAR bufferIn[256], bufferOut[256]; DWORD dwBytesWritten = 0, dwBytesRead = 0;StringCchCopy(bufferIn, 256, _T(“This is test data - I could fill the buffer to be interesting”));hDriver = CreateFile( _T(“DEM1:”), 0, 0, NULL, OPEN_EXISTING, 0, NULL );if (!WriteFile(hDriver, bufferIn, 256 * sizeof(TCHAR), &dwBytesWritten, NULL)){g_pKato->Log(LOG_FAIL, TEXT(“Write failurein ReadWriteTest”));tprResult = TPR_FAIL; }else {if (!ReadFile(hDriver, bufferOut, 256 * sizeof(TCHAR), &dwBytesRead, NULL)){g_pKato->Log(LOG_FAIL, TEXT(“ReadFilefailure in ReadWriteTest”));tprResult = TPR_FAIL;}}CloseHandle(hDriver);// 중략}// 디바이스 드라이버를 IOCTL을 통하여 테스트 하는 함수TESTPROCAPI TestIoctl(UINT uMsg, TPPARAM tpParam, LPFUNCTION_TABLE_ENTRY lpFTE){HANDLE hDriver = INVALID_HANDLE_VALUE;DWORD tprResult = TPR_PASS;TCHAR bufferIn[256];TCHAR bufferOut[256];DWORD dwBytesWritten = 0;//중략hDriver = CreateFile( _T(“DEM1:”), 0, 0, NULL, OPEN_EXISTING, 0, NULL );StringCchCopy(bufferIn, 256, _T(“abc”));DWORD dwSize = (_tcslen(bufferIn) + 1) * sizeof(TCHAR);if (FALSE == DeviceIoControl(hDriver,IOCTL_DRIVER_REVSTR,bufferIn,dwSize,bufferOut,dwSize,&dwBytesWritten,NULL)){g_pKato->Log(LOG_FAIL, TEXT(“DeviceIoControl failed”));tprResult = TPR_FAIL;}else{g_pKato->Log(LOG_COMMENT, TEXT(“Revers ed strings is %ls”), bufferOut);TCHAR bufferOut2[256];DeviceIoControl(hDriver,IOCTL_DRIVER_REVSTR,bufferOut,dwSize,bufferOut2,dwSize,&dwBytesWritten,NULL);if (_tcscmp(bufferIn, bufferOut2)){g_pKato->Log(LOG_FAIL, TEXT(“Reversed strings do not match - %ls, %ls”), bufferOut, bufferOut2);tprResult = TPR_FAIL;}}CloseHandle(hDriver);if (tprResult == TPR_PASS){g_pKato->Log(LOG_PASS, TEXT(“Simple IOCTLtest succeeded”)); } return tprResult;}사용자 정의 테스트 추가하기테스트할 내용을 다 추가하면 컴파일 및 빌드하여 ‘TuxTest.DLL’이라는 이름의 테스트 DLL을 만든다. 이 DLL을 CETK에 연결시켜 개발한 장치에서 테스트 하도록 해야 한다. 물론 앞에서 개발한 ‘DEM:’으로 호출되는 스트림 인터페이스 디바이스 드라이버는 운영체제에 포함되어서 동작되고 있어야 한다. CETK에서 User-Defined Test Wizard 명령을 한다. Add a New Test를 통하여 새로운 테스트를 추가할 것을 선택하고 테스트 DLL을 등록한다. <그림 9>는 테스트 DLL을 등록하는 화면이다.이제 제대로 사용자 정의 테스트가 등록이 되면 CETK 화면에 ‘User Test’라는 이름으로 사용자가 등록한 테스트 항목이 보이기 시작할 것이다. <그림 10> 참조. 이것으로 사용자가 정의한 CETK 테스트 항목이 등록이 되었다.끝으로CETK의 사용 및 사용자 정의 테스트에 관한 사항에 대해서 살펴봤다. CETK를 테스트 하는 목적은 보다 안정적인 윈도우 임베디드 CE 시스템을 만들기 위함이다. 하지만 CETK의 장점은 CETK 단순한 자동 테스트 기능보다 개발자의 의지에 따라서 다양한 테스트를 추가할 수 있다는 것이다. CETK를 통해 다양한 사용자가 테스트를 추가하고 사용자의 간섭 없이도 시스템의 안정성을 높이는 효율적인 테스트를 했으면 한다. CETK은 개발 중 테스트해야할 항목의 일부분에 불과하다. 또한 테스트는 지루하고 오랜 시간이 걸리는 작업이다. CETK와 여기에 추가된 개발자의 창의성을 통해 테스트 시간을 최소화하고 문제점을 쉽게 찾는 계기가 되었으면 한다. 본 내용에 소개된 CETK가 실제 동작하는 화면과 관련 소스는 다음 사이트에서 확인하기 바란다. (http://www. embeddedce.com)
이 기사를 공유합니다
저작권자 © 테크월드뉴스 무단전재 및 재배포 금지