KR101019209B1

KR101019209B1 - 임베디드 소프트웨어의 인터페이스 자동 추출 장치 및 그방법

Info

Publication number: KR101019209B1
Application number: KR1020070040127A
Authority: KR
Inventors: 최병주; 서주영; 성아영; 라광현; 강성봉; 이기철; 김용훈
Original assignee: 이화여자대학교 산학협력단; 삼성전자주식회사
Priority date: 2007-04-25
Filing date: 2007-04-25
Publication date: 2011-03-04
Also published as: US8255874B2; US20080270996A1; KR20080095527A

Abstract

여기에 개시된 임베디드 소프트웨어의 인터페이스 자동 추출 방법은 임베디드 소프트웨어의 인터페이스를 테스트하기 위하여 임베디드 소프트 웨어의 인터페이스를 테스트 항목으로 정의하고, 정의된 각 테스트 항목에 대응하는 인터페이스 심볼을 생성한다.

Description

임베디드 소프트웨어의 인터페이스 자동 추출 장치 및 그 방법{Device of automatically extracting Interface of Embedded Software and Method thereof}

도 1은 본 발명에 따른 실시예를 도시한 블록도이다.

도 2는 본 발명에 따른 임베디드 시스템의 인터페이스를 예시한다.

도 3은 도 2에 도시된 임베이드 시스템의 인터페이스를 도시한다.

도 4는 LCD 디바이스 드라이버에 대한 표준 파일 오퍼레이션을 나타낸다.

도 5는 도 4에 도시된 표준 파일 오퍼레이션에 대한 실시예를 도시한다.

도 6 내지 도 13은 표 2에 표시된 LCD 디바이스 드라이버의 인터페이스 테스트 항목을 도시한다.

도 14는 OPI_{3_6} Kernel Stack과의 충돌 테스트에 대한 테스트 스크립트를 나타낸다.

도 15는 본 발명에 따른 임베디드 소프트웨어의 인터페이스를 테스트하기 위한 테스트 케이스 생성을 도시한 블록도이다.

도 16은 본 발명에 따른 임베디드 소프트웨어의 인터페이스를 테스트하기 위한 테스트 케이스를 생성하는 방법을 도시한 순서도이다.

*도면의 주요 부분에 대한 부호의 설명*

10 : 호스트 시스템 20 : 이뮬레이터

30 : 평가 보드 40 : 리눅스 서버

11 : 테스트 타겟 분석기 12 : 테스트 케이스 생성기

13 : 테스트 실행 엔진 14 : 결과 분석기

본 발명은 임베디스 소프트웨어 테스트(Embedded Software Test)에 관한 것으로, 좀 더 구체적으로는 테스트 케이스 자동 생성 방법에 관한 것이다.

종래의 임베디드 소프트웨어는 이뮬레이터의 모니터링 및 디버깅을 통해 테스팅되었다. 이뮬레이터를 이용한 실행 환경의 임베디드 소프트웨어를 디버깅하기 위한 방법으로 synchronous monitoring과 asynchronous monitoring이 존재한다. Synchronous monitoring은 linsyssoft사의 리눅스 소스 코드 디버거인 KGDB과 같이 소스 코드 내의 특정 위치에서 실행 중인 프로그램을 정지 시킨 후, 해당 위치의 값을 모니터링 하는 방법이다. Asynchronous monitoring은 독립적인 모니터링 데몬을 두어 전체 임베디드 소프트웨어 모니터링 하는 방법으로 모니터링 하고자 하는 소스 코드에 대해 부정확한 한 값이 측정될 수 있다.

이뮬레이터를 이용한 실행 환경의 임베디드 소프트웨어를 디버깅 하기 위한 방법으로 synchronous monitoring과 asynchronous monitoring이 존재하며, 두 방법 모두 디버깅을 위해 코드 영역, 데이터 영역, 전역 변수, 스택을 모니터링 할 수 있으나, 이때 모니터링 해야 하는 심볼의 결정 및 결과 분석은 개발자의 개인적인 경험 및 지식 수준에 따라 달라지기 때문에 객관적인 테스트이기 보다는 ad-hoc 방식의 테스트가 이루어 진다. 또한 단순한 모니터링 방법은 테스팅 수행 자동화에 초점이 맞추어져 있는 반면, 테스트 케이스의 입력이 되는 테스트 타겟 식별, 테스트 케이스 생성, 테스트 결과 분석과 같이 테스트와 관련된 작업은 지원을 하지 못하고 있다.

임베디드 소프트웨어는 하드웨어, HAL(Hardware Abstraction Layer), OS Kernel, 다른 디바이스 드라이버, 그리고 upper-level 어플리케이션 소프트웨어와 유기적으로 연동된다. 임베디드 시스템에서는 하드웨어, HAL, OS 커널, 디바이스 드라이버(Device Driver), 어플리케이션(Application)과 같은 이질적 계층(layer)간 상호작용이 핵심이며, 서로 다른 계층들간의 인터페이스들이 테스트되어야 한다. 하지만, 종래기술만으로는 이를 해결할 수 없다.

따라서, 본 발명의 목적은 임베디드 소프트웨어의 인터페이스를 테스트하기 위하여 인터페이스 심볼을 자동으로 추출하는 장치 및 그 방법을 제공하는 데 있다.

본 발명의 또 다른 목적은 임베디드 소프트웨어의 인터페이스를 테스트하기 위한 테스트 케이스를 자동으로 생성하는 장치 및 그 방법을 제공하는 데 있다.

상술한 바와 같은 본 발명의 목적을 달성하기 위한 본 발명의 특징에 의하면 임베디드 소프트웨어의 인터페이스 자동 추출 방법은 임베디드 소프트웨어의 인터페이스를 테스트하기 위하여 임베디드 소프트 웨어의 인터페이스를 테스트 항목으로 정의하고, 정의된 각 테스트 항목에 대응하는 인터페이스 심볼을 생성한다.

(실시예)

이하, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 본 발명의 기술적 사상을 용이하게 실시할 수 있도록 본 발명의 실시예를 첨부된 도면을 참조하여 설명한다.

본 발명은 실제 제품이 개발되기 이전에, 평가 보드를 에뮬레이트 할 수 있는 개발환경에서 LCD 디바이스 드라이버의 인터페이스를 테스트 하기 위한 테스트 케이스 자동 생성하는 것을 예시한다. 즉, 본 발명에서 임베디드 소프트웨어는 LCD 디바이스 드라이버를 예시한 것이다.

도 1은 본 발명에 따른 실시예를 도시한 블록도이다.

도 1을 참조하면, 임베디드 소프트웨어의 테스트 시스템(100)은 호스트 시스템(Host System ; 10), 이뮬레이터(Emulator ; 20), 평가 보드(Evaluation Board ; 30), 및 임베디드 소프트웨어(41)를 포함하는 리눅스 서버(LINUX Server ; 40)를 포함한다.

호스트 시스템(10)은 임베디드 소프트웨어의 인터페이스를 테스트하기 위한 테스트 케이스를 생성한다. 또한, 생성된 테스트 케이스는 이뮬레이터(20)에 의하여 실행되도록 제어한다. 이뮬레이터(20)는 호스트 시스템(10)으로부터 생성된 테스트 케이스를 실행하고, 결과를 출력한다. 평가 보드(30)는 임베디드 소프트웨 어(41)를 하드웨어와 함께 테스트하기 위하여 제공된다. 리눅스 서버(40)는 임베디드 소프트웨어(41)를 포함하며, 이뮬레이터(20)의 제어에 따라 임베디스 소프트웨어(41)를 평가 보드(30)에 로딩한다.

본 발명은 리눅스 기반 LCD 디바이스 드라이버 인터페이스 테스트를 위한 테스트 케이스 생성 방법을 제공한다. 따라서, 리눅스 기반 LCD 디바이스 드라이버의 인터페이스 식별, 리눅스 기반 LCD 디바이스 드라이버의 인터페이스 테스트를 위한 테스트 케이스 자동 생성 방법을 제공한다.

호스트 시스템(10)은 테스트 타겟 분석기(11), 테스트 케이스 생성기(12), 테스트 실행엔진(13), 및 결과 분석기(14)를 포함한다. 테스트 타겟 분석기(11)는 리눅스 서버(40)으로부터 임베디드 소프트웨어(41)의 소스 코드(Source Code) 또는 오브젝트 코드(Object code)를 전송 받는다. 테스트 타겟 분석기(11)는 각 인터페이스에 해당하는 인터페이스 심볼이 소스 코드 또는 오브젝트 코드에서 매핑되는 위치를 ELF(Executable Linker Format) 파일로부터 자동으로 식별한다. 테스트 케이스 생성기(12)는 임베디드 소프트웨어(41)의 인터페이스를 테스트하기 위한 테스트 케이스를 생성한다. 테스트 케이스 생성기(12)는 이뮬레이터(30)에서 실행할 수 있도록 스크립트 형태의 테스트 케이스를 제공한다. 테스트 실행엔진(13)은 테스트 케이스 생성기(12)로부터 제공된 테스트 케이스를 이뮬레이터(20)에 제공하고, 이뮬레이터(20)가 실행되도록 제어한다. 결과 분석기(14)는 이뮬레이터(20)로부터 테스트 케이스가 실행된 결과를 제공받고, 제공된 결과를 분석한다.

본 발명은 임베디드 시스템(즉, Mobile AP)에 탑재되는 임베디드 소프트웨 어(즉, LCD Device Driver)의 구조와 LCD 이뮬레이션 테스트(emulation test)에 있어서 인터페이스를 테스트한다.

도 2를 참조하면, 임베디드 시스템은 물리적인 하드웨어 계층(Hardware Layer ; 31), HAL(Hardware Abstraction Layer ; 32), OS 계층(Operation System Layer ; 35), 및 어플리케이션 계층(Application Layer ; 36)을 포함한다.

임베디드 시스템은 USB 및 Serial과 같이 데이터 전송에 관련된 디바이스 드라이버, AC97 및 IrDA와 같이 Sound에 관련된 디바이스 드라이버 등 평가 보드(30)에 탑재된 물리적인 장치(physical device)를 지원하기 위한 다양한 디바이스 드라이버를 포함한다.

임베디드 소프트웨어(33)는 각 계층에 있는 소프트웨어 유닛들이 서로 연동(tightly coupled) 되어 작동한다. 각 계층에 존재하는 소프트웨어 유닛은 SU_k, SU_d, 및 SU_p로 구분된다. SU_k (Kernel-dependent Software Unit)는 커널에 의존적인 소프트웨어로, 운영체제의 API (Application Program Interface)와 같은 운영체제 서비스이다. SU_d(Device-dependent Software Unit)는 LCD Controller와 같이 물리적 장치(device)를 지원하기 위한 소프트웨어이다. SU_p (Processor-dependent Software Unit)는 HAL의 소프트웨어로서, 하드웨어 장치 초기화 및 설정(configuration)과 같이 대상 프로세서(processor)에 의존적인 소프트웨어이다.

도 2와 도 3을 참조하면, 임베디드 소프트웨어는 앞에서 언급한 소프트웨어 유닛 뿐 아니라 하드웨어 유닛(Hardware Unit)과도 연동된다. 소프트웨어 유닛이 하드웨어 유닛과 직접적으로 연결되는 것은 램(RAM) 또는 레지스터(Register)를 통하여 값을 독출하고 기입할 때이다. 따라서, 하드웨어 유닛은 소프트웨어 유닛과 결합(coupled)된 방법에 따라 HU_d와 HU_i로 세분화된다. HU_d (Hardware Unit_d)은 램 또는 레지스터와 같이 직접적으로 소프트웨어에서 하드웨어에 독출/기입이 가능하다. HU_i(Hardware Unit_i)은 UART, USB, WDT(Watch Dog Timer)와 같이 HU_d의 주소를 통해 독출/기입이 간접적으로 제어된다.HPI₁은 SU_d 또는 SU_p에서 HU_d에 접근하여 값을 독출/기입하고, HPI₂은 SU_d 또는 SU_p에서 HU_d의 주소를 통해 HU_d를 제어한다.

본 발명에서 예시한 LCD 디바이스 드라이버의 LCD CONTROLLER는 HU_i에 해당한다.

계속해서 도 2와 도 3을 참조하면, 운영체제 계층과의 인터페이스 분석을 위해 운영체제의 제어 흐름은 프로세스 관리(process management), 프로세스간 통신 및 동기(Inter-process communication and synchronization), 예외 처리(exception handling), 가상메모리 관리(virtual memory management), 물리메모리 관리(physical memory management), 시간 관리(time management), 인터럽트 처리(interrupt handling), 입출력 관리(IO management), 네트워킹(networking), 및 파일 시스템(file system)과 같은 운영체제 서비스 종류에 따라 달라진다. 즉, 운 영체제 서비스 별 제어 흐름을 바탕으로, 운영체제와의 인터페이스는 OPI₁ ,OPI₂ , 및 OPI₃로 구분된다. OPI₁은 SU_d 또는 SU_p에서 HU_d및 HU_i 제어와 관련이 없는 SU_k를 호출한다. 이때, SU_k는 프로세스 관리, 프로세스 간 통신, 예외 처리를 위한 API가 해당된다. OPI₂는 SU_d 또는 SU_p 에서 가상 메모리 제어와 관련이 있는 SU_k를 호출한다. 이때, SU_k는 가상 메모리 관리를 위한 API가 해당된다. OPI₃는 SU_d 또는 SU_p에서 HU_d및 HU_i 제어와 관련이 있는 SU_k를 호출한다. 이때, SU_k는 물리 메모리 관리, 시간 관리, 인터럽트 처리, IO 관리, 네트워킹, 파일 시스템 관리를 위한 API가 해당된다.

도 3에서 도시한 5가지 인터페이스는 임베디드 소프트웨어의 인터페이스 테스트를 위한 테스트 커버리지(coverage)의 기준(criteria)이 된다. 또한 이 인터페이스는 테스트 케이스 선정 및 테스트 데이터의 통과/실패 판정을 위한 심볼의 위치가 되며, 디버깅(debugging) 과정에서 결함 원인을 찾기 위한 모니터링(monitoring) 위치가 된다. 따라서, 인터페이스의 테스트 커버리지는 테스트 대상 임베디드 소프트웨어에서 인터페이스 특징에 따라 결정되는 모든 인터페이스에 대하여 실행된 인터페이스의 수를 의미한다.

본 발명의 예시적인 LCD 디바이스 드라이버의 운영체제는 리눅스를 기준으로 한다. 따라서, 디바이스 드라이버는 리눅스의 표준 파일 오퍼레이션(file operations)을 준수하며, 상위 어플리케이션 소프트웨어는 함수 open(), 함수 close(), 함수 read(), 함수 write(), 함수 mset(), 및 함수 ioctl()과 같은 표준 파일 오퍼레이션을 통해서만 디바이스 드라이버를 활성화(invoke)시킬 수 있다.

도 4는 LCD 디바이스 드라이버에 대한 표준 파일 오퍼레이션인 함수 fb_open(), 함수 fb_release(), 함수 fb_read(), 함수 fb_write(), 함수 fb_mmap(), 및 함수 fb_ioctl()을 나타내고, 도 5는 도 4에 도시된 표준 파일 오퍼레이션에 대한 실시예를 도시한다. 표 1은 함수 fb_write()에 대한 인터페이스를 나타낸다.

LCD 디바이스 드라이버의 인터페이스는 LCD 파일 오퍼레이션에 정의된 함수들이 SU_k, SU_d, SU_p와 HU_d, HU_i 사이에 호출(call) 관계로 존재하는 부분이다.

도 4와 도 5를 참조하면, 함수 write()를 통해 활성화 된 함수 fb_write()가 함수 get_con_display()를 통해 램에 값을 쓰는 HPI₁와, 함수 copy_from_user()를 통해 유저(user)로부터 입력 받은 값을 램에 쓰는 OPI₃가 존재한다.

SU _k	SU _d	SU _p	HU _d	HU _i	Pattern
-	-	get _ con _ display ()	RAM	-	HPI ₁
copy _ from _ user ()	Fb _ write ()	-	RAM	-	OPI ₃

LCD 디바이스 드라이버는 함수 s32440fb_init(), 함수 fb_open(), 함수 fb_release(), 함수 fb_read(), 함수 fb_write(), 함수 fb_mmap(), 및 함수 fb_ioctl()에 대해 총 74개의 인터페이스가 존재한다. 이들은 인터페이스 패턴에 따라 32개의 HPI₁, 2개의 HPI₂, 40개의 OPI₃으로 구분한다. 표 2에서는 LCD 디바이스 드라이버의 인터페이스 테스트 특성과 각 특성 별로 모니터링 해야 할 심볼(symbol)인 인터페이스 심볼(Interface Symbol)을 기술한다.

인터페이스 테스트 특성			Interface Symbol
Memory	Memory Map Boundary Check	HPI₁ _{_1}Static Memory Map Boundary Check 정적 할당 변수의 가상 메모리 영역이 물리 메모리 맵 경계에 할당 되었는지에 대한 테스트	LCD 디바이스 드라이버에서 정적으로 선언한 심볼의 주소, 크기
	Memory Collision	HPI₁ _{_2}Kernel Stack Collision Test 정적 할당 변수와 커널 스택 공간이 충돌 나는 지에 대한 테스트	LCD 디바이스 드라이버에서 정적으로 선언한 심볼의 타입, 주소, 크기
	Memory Collision	HPI₁ _{_3}User Stack Collision Test 정적 할당 변수와 사용자 스택 공간이 충돌 나는 지에 대한 테스트	LCD 디바이스 드라이버에서 정적으로 선언한 심볼의 타입, 주소, 크기
Timer	Frame Buffer Performance	HPI₂ _{_1}Frame Buffer Response Time Test 프레임 버퍼 성능에 대한 테스트	LCD 디바이스 드라이버의 fb_mmap()의 시작과 완료(return) 시점
Interrupt	Interrupt Handler	OPI₃ _{_1}Interrupt Context Recovery Test 인터럽트 서비스 전, 후의 context를 올바르게 복구하는 지에 대한 테스트	__irq_svc, stmia and ldmia of do_irq()의 called address
	Interrupt Handler	OPI₃ _{_2}Interrupt Latency Test 인터럽트 발생 후 복구까지의 서비스 성능 측정에 대한 테스트	__irq_svc, stmia and ldmia of do_irq()의 called address
	Interrupt Service Routine	OPI₃ _{_3}Normal Interrupt Service Routine Test 발생한 인터럽트에 해당 서비스 루틴이 호출되는 지에 대한 테스트	do_irq()의 called address
	Interrupt Service Routine	OPI₃ _{_4}Abnormal Interrupt Service Routine Test 과도한 인터럽트 발생에 따른 서비스 루틴이 정확히 호출되는 지에 대한 테스트	do_irq()의 called address
Memory Management	Memory Map Boundary	OPI₃ _{_5}Dynamic Memory Map Boundary Check 동적 할당 변수의 가상 메모리 영역이 물리 메모리 맵 경계에 할당 되었는지에 대한 테스트	LCD 디바이스 드라이버에서 kmalloc()을 통해 동적으로 선언한 심볼의 주소, 크기
	Memory Collision	OPI₃ _{_6}Kernel Stack Collision Test 동적 할당 변수가 커널 스택 공간과 충돌하는 지에 대한 테스트	LCD 디바이스 드라이버에서 get_user(), __arch_copy_from_user(), __arch_strncpy_from_user() 의 called address
		OPI₃ _{_7}User Stack Collision Test 동적 할당 변수가 사용자 스택 공간과 충돌하는 지에 대한 테스트	LCD 디바이스 드라이버에서 put_user(), __arch_clear_user(), __arch_copy_to_user()의 called address
		OPI₃ _{_8}Heap Collision Test 동적 할당 변수가 다른 변수의 메모리 영역과 충돌하는 지에 대한 테스트	LCD 디바이스 드라이버에서 memset(), __memzero(), memcpy()의 called address
	Memory Free	OPI₃ _{_9}Memory Leakage Test 동적 할당된 메모리 영역이 올바르게 해제되는 지에 대한 테스트	LCD 디바이스 드라이버에서 kfree()의 called address
	Memory Free	OPI₃ _{_10}Memory Free Latency Test 메모리 해제 성능 측정에 대한 테스트	LCD 디바이스 드라이버에서 kfree()와 kmem_cache_free_one()의 called address
	Page Fault	OPI₃ _{_11}Miss-Align Check 주소의 정렬 (align)에 대한 테스트	init section, code section, data section에 있는 심볼의virtual address
	Critical Region	OPI₃ _{_12}Critical Region Test 임계 영역이 FIQ로부터 보호되는 지에 대한 테스트	LCD 디바이스 드라이버에서 msr, orr/bic, mrs의 address

본 발명의 테스트 타겟 분석기(11)는 표 2에서 기술한 LCD 디바이스 드라이버의 인터페이스 테스트 특성의 인터페이스 심볼이 테스트 타겟 소스코드에서 맵핑(Mapping)하는 위치를 타겟 소스의 ELF(Executable Linker Format) 파일로부터 식별한다. ELF(Executable Linker Format) 파일이란 디버거(Debugger)를 사용하기 위해 개발자가 프로그램한 소스에 관한 모든 정보를 내장한다. Objdump는 backtrace 등으로 콜스택을 확인하기 어려운 경우, 소스의 주소를 확인하는 명령어이고, Readelf는 ELF 파일 포맷의 정보를 보여주는 명령어이다.

도 6 내지 도 13은 표 2에 표시된 LCD 디바이스 드라이버의 인터페이스 테스트 항목을 도시한다. 도 6 내지 도 13을 참조하면, HPI₁에 속하는 Memory 관련 인터페이스 테스트 특성이 소스코드에 매핑되는 위치를 찾기 위해서는, 심볼의 사이즈와 주소를 objdump -t 명령어에 의해 생성된 ELF로부터 추출하고, 심볼의 type을 readelf -wi 명령어에 의해 생성된 ELF 파일로부터 추출한다.

HPI₁ _{_1}Static Memory Map Boundary Check는 전역(global)으로 선언한 정적 변수(static global variable)가 도 6에서 도시된 바와 같이 물리 메모리 맵 경계에 걸쳐져 있는지를 테스트한다. 전역으로 선언한 정적 변수에 대한 주소와 크기가 HPI_{1_1}의 인터페이스이다.

HPI_{1_2}Kernel Stack Collision Test는 도 7의 점선과 같이 전역으로 선언한 정적 변수가 Kernel Stack과 충돌이 발생하는지를 테스트한다. 전역으로 선언한 정적 변수에 대한 주소, 크기, 타입이 HPI_{1_2}의 인터페이스이다.

HPI_{1_3}User Stack Collision Test는 도 8의 점선과 같이 static global variable가 User Stack과 충돌이 발생하는지를 테스트한다. static global variable의 주소, 크기, 타입이 HPI_{1_3}의 인터페이스이다.

HPI₂에 속하는 Timer 관련 인터페이스 테스트 특성이 소스코드에 매핑되는 위치를 찾기 위해서는 Frame Buffer의 Timer와 관련된 심볼을 objdump -t 명령어에 의해 생성된 ELF 파일로부터 추출한다. Frame Buffer Response Time Test는 프레임 버퍼의 응답 시간 테스트를 위하여 어플리케이션의 함수 mmset()에 의해 활성화된 함수 fb_mmap()에 대한 시간을 측정한다. 함수 fb_mmap()의 시작부터 메모리 매핑을 완료한 함수 fb_mmap()의 return까지의 소요 시간을 측정한다. 따라서 함수 fb_mmap()이 호출된 주소(called address)가 HPI_{2_1}의 인터페이스이다.

OPI₃에 속하는 Interrupt 및 Memory Management 관련 인터페이스 테스트 특성이 소스코드에 매핑되는 위치를 찾기 위해서는, OPI₃의 인터페이스 심볼에 대한 주소를 objdump -lS 명령어에 의해 생성된 ELF로부터 추출한다.

Interrupt Context Recovery Test는 인터럽트를 수행한 후, 인터럽트가 발생하기 이전에 수행한 문맥(context)이 제대로 복귀(recover)되었는지를 테스트한다. 도 9와 같이 __irq_svc가 호출된 후, do_IRQ에서 레지스터 저장과 복구를 위한 stmia, 및 ldmia 명령어가 호출된 주소가 OPI₃ _{_1}의 인터페이스이다.

Interrupt Latency Test는 인터럽트 발생 직후, 문맥을 저장한 시점부터 저장한 문맥이 복귀한 시점까지의 소요 시간을 측정한다. 따라서, do_IRQ에서 레지스터 저장과 복구를 위한 stmia, 및 ldmia 명령어가 호출된 주소가 OPI₃ _{_2}의 인터페이스이다.

Normal Interrupt Service Routine Test는 발생한 인터럽트에 대한 ISR(Interrupt Service Routine)이 정확히 수행되는지를 테스트한다. 도 10과 같이 인터럽트가 발생하여 do_IRQ가 호출되면 R0 Register로부터 IRQ 번호를 식별한 후, irq_desc[irq].action -> handler에 의해 IRQ 번호에 해당하는 ISR을 호출한다. 따라서 do_IRQ가 호출된 주소가 OPI₃ _{_3}의 인터페이스이다.

Abnormal Interrupt Service Routine Test는 과도하게 발생하는 인터럽트에 대해, 발생한 인터럽트 횟수만큼 도 10과 같이 해당 인터럽트 서비스 루틴이 정확히 수행되는지를 테스트한다. 따라서 do_IRQ가 호출된 주소가 OPI_{3_4}의 인터페이스이다.

Dynamic Memory Map Boundary Check는 함수 kmalloc()에 의해 동적으로 할당한 심볼이 도 6과 같이 물리 메모리 맵 경계에 걸쳐져서 할당되었는지를 테스트한다. 따라서, 함수 kmalloc()의 호출된 주소가 OPI_{3_5}의 인터페이스이다.

Kernel Stack Collision Test는 도 7의 실선과 같이 함수 __arch_copy_from_user(), 함수 __arch_strncpy_from_user(), 및 함수 get_user()에 의해 kernel space에 접근 시 Kernel Stack과의 충돌 여부를 테스트한다. 따라서, 함수 __arch_copy_from_user(), 함수 __arch_strncpy_from_user(), 및 함수 get_user()이 호출된 주소가 OPI₃ _{_6}의 인터페이스이다.

User Stack Collision Test는 도 8의 실선과 같이 함수 copy_to_user(), 함수 put_user(), 및 함수 __arch_clear_user()에 의해 커널 공간의 데이터가 user space로 이동 될 때, User Stack과의 충돌 여부를 테스트한다. 따라서, 함수 copy_to_user(), 함수 put_user(), 및 함수 __arch_clear_user()이 호출된 주소가 OPI₃ _{_7}의 인터페이스이다.

Heap Collision Test는 도 7의 실선과 같이, 함수 memset(), 함수 __memzero(), 및 함수 memcpy()이 호출되었을 때, Kernel Data Segment내의 심볼들 사이의 충돌을 테스트한다. 따라서 함수 memset(), 함수 __memzero(), 및 함수 memcpy()이 호출된 주소가 OPI_{3_8}의 인터페이스이다.

Memory Leakage Test는 함수 kmalloc()을 통해 할당 받은 주소가 함수 kfree()를 통해 release 되었는지를 테스트한다. 따라서, 함수 kfree()가 호출된 주소가 OPI_{3_9}의 인터페이스이다.

Memory Free Latency Test는 도 11과 같이 함수 kfree()가 호출되면 함수 kfree()내의 함수 kem_cache_free_one()에서 실제 메모리에서의 링크를 끊는 동작이 일어나기 때문에, 함수 kfree()가 호출된 시점부터 함수 kem_cache_free_one()가 호출된 시점까지의 소요 시간이 Memory Free Latency가 된다. 따라서 함수 kfree()와 함수 kem_cache_free_one()이 호출된 주소가 OPI_{3_10}의 인터페이스이다.

Miss-Align Check는 워드(word) 단위로 정렬이 되어 있어야 코드를 메모리에 로딩할 때 페이지폴트를 막을 수 있기 때문에, 도 12와 같이 init section, code section, data section에 존재하는 심볼의 가상 주소가 0, 4, C, 8로 끝나야 한다. 따라서 각 section 내에 존재하는 모든 심볼의 대한 주소가 OPI_{3_11}의 인터페이스이다.

Critical Region Test는 Critical Region이 FIQ(Fast Interrupt Request)로부터 보호되는지를 테스트한다. 도 13에서와 같이 Critical Region 진입과 동시에 FIQ disable을 위한 mrs, orr, msr명령어의 호출 주소, Critical Region 해제와 동시에 FIQ enable을 위한 mrs, bic, msr 명령어의 호출 주소가 OPI₃ _{_12}의 인터페이스이다.

테스트 케이스 생성기(12)는 테스트 타겟 분석기(11)로부터 파악한 테스트 대상 LCD 디바이스 드라이버 인터페이스를 커버하는 테스트 케이스를 생성한다. 테스트 케이스는 각 인터페이스에서 모니터링 되어야 할 입력에 해당하는 인터페이스 심볼과, 인터페이스 심볼의 데이터, 및 예상 출력으로 구성한다.

테스트 타겟 분석기(11)에서 각 인터페이스 종류에 따라 파악된 LCD 디바이스 드라이버 인터페이스 위치에 따라 LCD 디바이스 드라이버 인터페이스 특성 별로 테스트 케이스가 결정된다. 표 3은 LCD 디바이스 드라이버 인터페이스 특성에 대한 테스트 케이스와 각 테스트 케이스에 대해 Pass/Fail 판단 방법을 나타낸다. 표 3은 예상 출력값 대신 예상 출력을 참조할 수 있는 위치를 나타낸다. 이는 이뮬레이터(20)가 실행되면서 모니터링 하는 순간마다 값이 바뀌기 때문이다.

	인터페이스 심볼	expected output 참조 위치	Pass/Fail 판단 방법
HPI₁ _{_1}	symbol address와 symbol size	물리 메모리를 정보를 담은 memory map	symbol address와 symbol size를 더한 값과 물리 메모리 주소 비교
HPI₁ _{_2}	symbol address와 symbol size	Kernel Stack을 모니터링 하기 위한 R13_SVC 레지스터	symbol address와 symbol size를 더한 값을 kernel stack과 비교
HPI₁ _{_3}	symbol address와 symbol size	User Stack을 모니터링 하기 위한 R13_USR 레지스터	symbol address와 symbol size를 더한 값을 user stack과 비교
HPI₂ _{_1}	fb_mmap의 시작 시점, fb_mmap의 완료 시점	fb_mmap의 시작 시점부터 fb_mmap의 완료 시점까지 시간을 측정하는 변수	fb_mmap의 시작부터 완료까지 시간 측정
OPI₃ _{_1}	__irq_svc에 따른 do_IRQ의 stmia와 ldmia의 호출 주소	Context 정보를 포함하는 R0~R12 레지스터	stmia의 R0~R12 레지스터 값과 ldmia의 R0~R12 레지스터 값 비교
OPI₃ _{_2}	__irq_svc에 따른 do_IRQ의 stmia와 ldmia의 호출 주소	stmia 호출부터 ldmia 호출까지 시간을 측정하는 변수	stmia 호출부터 ldmia 호출까지 시간을 측정
OPI₃ _{_3}	do_IRQ의 호출 주소	호출 직후, IRQ 번호 획득을 위한 R0 레지스터	R0로부터 획득한 IRQ번호에 맞는 ISR 실행 확인
OPI₃ _{_4}	do_IRQ의 호출 주소	호출 직후, IRQ 번호 획득을 위한 R0 레지스터	R0로부터 획득한 IRQ번호에 맞는 ISR 실행 확인
OPI₃ _{_5}	kmalloc()의 호출 주소	호출 직후, 사이즈 획득을 위한 R0 레지스터	kmalloc()의 사이즈 획득
OPI₃ _{_5}	kmalloc()의 호출 주소	물리 메모리를 정보를 담은 memory map	호출 주소와 사이즈 더한 값과 물리 메모리 주소와 비교
OPI₃ _{_6}	__arch_copy_from_user(), __arch_strncpy_from_user(), get_user() 호출 주소	호출 직후, 사이즈 획득을 위한 R2 레지스터	__arch_copy_from_user(), __arch_strncpy_from_user(), get_user()의 사이즈 획득
OPI₃ _{_6}		Kernel Stack을 모니터링 하기 위한 R13_SVC 레지스터	호출 address와 size를 더한 값을 kernel stack과 비교
OPI₃ _{_7}	copy_to_user(), put_user(), __arch_clear_user()의 호출 주소	호출 직후, 사이즈 획득을 위한 R2 레지스터	copy_to_user(), put_user(), __arch_clear_user() 사이즈 획득
OPI₃ _{_7}	copy_to_user(), put_user(), __arch_clear_user()의 호출 주소	User Stack을 모니터링 하기 위한 R13_USR 레지스터	호출 address와 size를 더한 값을 user stack과 비교
OPI₃ _{_8}	memset(), __memzero(), memcpy() 호출 주소의 호출 주소	호출 직후, 사이즈 획득을 위한 R2 레지스터	memset(), __memzero(), memcpy() 사이즈 획득
OPI₃ _{_8}	memset(), __memzero(), memcpy() 호출 주소의 호출 주소	힙 공간 내 destination 심볼 주소를 모니터링 하기 위한 R1 레지스터	호출 address와 size를 더한 값을 destination 심볼 주소와 비교
OPI₃ _{_9}	kfree() 호출 주소	호출 직후 해제할 주소 획득을 위한 R0 레지스터	R0의 값이 0x0000000인지 확인 및 할당 받은 영역에 대한 해제인지 확인
OPI₃ _{_10}	kmem_cache_free_one(), kfree()의 호출 주소	kfree() 호출부터 kmem_cache_free_one() 호출까지 시간을 측정하는 변수	kfree()부터 kmem_cache_free_one()까지 시간 측정
OPI₃ _{_11}	init section, code section, data section에 존재하는 심볼의 가상 주소	각 가상 주소에서의 마지막 bit	각 가상 주소의 마지막 bit가 0, 4, 8, C인지 확인
OPI₃ _{_12}	mrs, orr, msr, 및 mrs, bic, msr의 주소	FIQ bit of Current Program Status Register	mrs, orr, msr, 및 mrs, bic, msr 호출 시 CPSR의 FIQ 비트의 값이 1인지 0인지 확인

테스트 케이스 생성기(12)에서 생성된 테스트 케이스들은 이뮬레이터를 통해 배치-런(Batch Run) 시킬 수 있는 테스트 스크립트 형태로 구성한다. 표 3의 인터페이스 심볼은 테스트 스크립트의 브레이크 포인트(BP:Break Point)를 설정하는 위치이며, 그 위치에서 통과/실패(pass/fail)을 판정하기 위해 모니터링 해야 할 곳은 표 3의 예상 출력 참조 위치이다.

도 14는 OPI_{3_6} Kernel Stack과의 충돌 테스트에 대한 테스트 스크립트를 나타낸다. 도 14를 참조하면, 함수 __arch_copy_from_user(), 함수 __arch_strncpy_from_user(), 및 함수 get_user()가 호출되는 주소에 브레이크 포인트(BP)를 설정하고, 이 위치에서 이뮬레이터내의 R2 레지스터로부터 사이즈를 더한 값이 Kernel의 Stack의 Stack Pointer(SP)와 충돌이 나지 않아야 한다. 이때, Kernel Stack의 스택 포인트(SP)는 R13_SVC 레지스터의 값을 통해 이뮬레이터의 디버거(Debugger)에서 모니터링 한다.

본 발명의 예시적인 실시예는 리눅스 기반 LCD 디바이스 드라이버의 인터페이스 테스트를 위한 인터페이스 테스트 케이스 자동 생성 방법이다. 본 발명의 리눅스기반 LCD 디바이스 드라이버는 TRACE32-ICD 이뮬레이터와 ARM Processor를 갖는 S3C2440 보드 상에서 개발되는 것을 예시한다.

도 15는 본 발명에 따른 임베디드 소프트웨어의 인터페이스를 테스트하기 위한 테스트 케이스 생성을 도시한 블록도이다. 도 15를 참조하면, LCD 디바이스 드라이버의 인터페이스 테스트를 위한 테스트 케이스 자동 생성 방법은 테스트 모델(41)에 기술된 인터페이스 테스트 특성과 각 인터페이스 테스트 특성이 오브젝트 코드에서 매핑되는 위치인 인터페이스 심볼을 자동 식별하고, 이 인터페이스 심볼을 입력하고, 입력된 인터페이스 심볼을 바탕으로 통과(Pass) 및 실패(Fail) 기준을 적용한 테스트 케이스를 자동 생성한다.

도 16은 본 발명에 따른 임베디드 소프트웨어의 인터페이스를 테스트하기 위한 테스트 케이스를 생성하는 방법을 도시한 순서도이다. 본 발명의 실시예는 임베디드 소프트웨어를 LCD 디바이스 드라이버로 예시한다.

도 1과 도 16을 참조하면, 리눅스 서버(40)는 테스트 타겟 분석기(11)에 LCD 디바이스 드라이버(41)의 오브젝트 코드를 제공한다(210). 또한, 리눅스 서버(40)는 테스트 타겟 분석기(11)에 LCD 디바이스 드라이버(41)의 소스 코드를 제공할 수 있다. 테스트 타겟 분석기(11)는 LCD 디바이스 드라이버(41)의 오브젝트 코드로부터 ARM Processor 기반의 objdump -t, objdump -l -S, 및 readelf -wi 명령어를 이용하여 ELF 파일을 생성한다.

테스트 타겟 분석기(11)는 LCD 디바이스 드라이버의 계층을 식별한다(220). 즉, 테스트 타겟 분석기(11)는 LCD 디바이스 드라이브(41)의 계층간 인터페이스를 분류된 정의에 따라 확인한다. 예를 들면, LCD 디바이스 드라이브(41)를 구성하는 서브함수들의 구성이 표 1에서 정의된 인터페이스에 해당하는 지를 확인한다. 테스트 타겟 분석기(11)는 LCD 디바이스 드라이버의 호출 관계를 식별한다.(230) 즉, 실제로 인터페이스들간에 호출되는 서브함수들만을 테스트의 대상으로 선정한다.

인터페이스들간에 호출되는 서브함수들에 대하여, 테스트 타겟 분석기(11)는 표2에서 정의된 LCD 디바이스 드라이버의 인터페이스와 인터페이스에서 테스트 되어야 할 인터페이스 심볼을 식별한다(240). 인터페이스 심볼이 소스코드에서 매핑되는 위치를 자동으로 식별하기 위하여, 테스트 타겟 분석기(11)는 LCD 디바이스 드라이버의 오브젝트 코드와 ELF 파일로부터 HPI₁, HPI₂, OPI₁, OPI₂ _,및 OPI₃에 해당하는 LCD 디바이스 드라이버의 인터페이스 심볼을 매핑한다.(250) 테스트 타겟 분석기(11)는 매핑된 심볼의 위치를 추출한다. 테스트 케이스 생성기(12)는 테스트 타겟 분석기(11)로부터 추출된 인터페이스에 각 브레이크 포인트를 설정한다.(260) 테스트 케이스 생성기(12)는 테스트 타겟 분석기(11)로부터 추출한 인터페이스에 각 브레이크 포인트를 테스트 케이스의 입력으로 설정한다.(270) 테스트 케이스 생성기(12)는 인터페이스 별로 통과 및 실패 판단을 결정하기 위해 모니터링해야 하는 모니터링 심볼들을 결정한다.(280) 즉, 이를 바탕으로 해당 인터페이스에서의 예상 출력(Expected Output)을 설정한다.(290) 즉, 입력과 예상 출력을 이용하여 테스트 케이스로 생성한다. 이때 생성된 테스트 케이스는 이뮬레이터에서 배치-런으로 생성될 수 있도록 스크립트(Script)로 생성된다.(300).

본 발명의 리눅스 기반 LCD 디바이스 드라이버의 인터페이스 테스트를 위한 테스트 케이스 생성 방법은 이뮬레이터의 디버깅 및 모니터링 기능과 인터페이스 테스팅 기능을 결합함으로서, 결함 발견 및 결함 원인 추적을 지원하고, 리눅스 기반 LCD 디바이스 드라이버에 대한 테스트를 자동화 한다.

따라서, 본 발명은 리눅스 기반 LCD 디바이스 드라이버를 비롯하여, 그것과 관계되는 커널을 비롯하여 LCD 디바이스 드라이버와 유기적으로 동작하는 모든 계층의 소프트웨어에 대한 인터페이스 심볼을 자동 식별한다.

또한, 본 발명은 리눅스 기반 LCD 디바이스 드라이버의 인터페이스 테스트를 위한 테스트 케이스를 자동으로 생성한다. 식별한 리눅스 기반 LCD 디바이스 드라이버의 인터페이스를 커버하는 테스트 케이스를 자동 식별하며, 이는 테스트 입력 심볼에 대한 통과 및 실패에 대한 자동 판단 기능을 테스트 케이스에 추가함으로써, 생성한 테스트 케이스가 수행 될 때, 테스트 통과 및 실패를 자동적으로 판단한다.

이상에서와 같이 도면과 명세서에서 최적 실시예가 개시되었다. 여기서 특정한 용어들이 사용되었으나, 이는 단지 본 발명을 설명하기 위한 목적에서 사용된 것이지 의미한정이나 특허청구범위에 기재된 본 발명의 범위를 제한하기 위하여 사용된 것은 아니다. 그러므로 본 기술 분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시예가 가능하다는 점을 이해할 것이다. 따라서, 본 발명의 진정한 기술적 보호 범위는 첨부된 특허청구범위의 기술적 사상에 의해 정해져야 할 것이다.

본 발명은 디바이스 드라이버의 인터페이스 테스트를 위한 테스트 케이스를 자동으로 생성하는 효과가 있다.

또한, 본 발명은 디바이스 드라이버의 인터페이스를 커버하는 테스트 케이스를 자동 식별하며, 이는 테스트 입력 심볼에 대한 통과 및 실패에 대한 자동 판단 기능을 테스트 케이스에 추가함으로써, 생성한 테스트 케이스가 수행될 때, 테스트 통과 및 실패를 자동적으로 판단하는 효과가 있다.

Claims

a) 임베디드 소프트웨어의 인터페이스 테스트 항목을 제공하고; 그리고

b) 상기 임베디드 소프트웨어와 상기 테스트 항목간에 대응되는 인터페이스 심볼을 추출하는 것을 특징으로 하는 임베디드 소프트웨어의 인터페이스 자동 추출 방법.
제 1 항에 있어서,

상기 추출된 인터페이스 심볼로부터 브레이크 포인트와 상기 인터페이스 테스트의 통과/실패 기준을 제공하는 것을 더 포함하는 임베디드 소프트웨어의 인터페이스 자동 추출 방법.
삭제
제 2 항에 있어서,

상기 브레이크 포인트와 상기 통과/실패 기준을 이용하여 상기 임베디드 소프트웨어의 인터페이스를 테스트하기 위한 테스트 케이스를 생성하는 것을 더 포함하는 임베디드 소프트웨어의 인터페이스 자동 추출 방법.
제 4 항에 있어서,

상기 테스트 케이스를 실행하고, 상기 실행된 결과를 출력하는 것을 더 포함하는 임베디드 소프트웨어의 인터페이스 자동 추출 방법.
제 5 항에 있어서,

상기 테스트 케이스는 이뮬레이터를 이용하여 실행하는 것을 특징으로 하는 임베디드 소프트웨어의 인터페이스 자동 추출 방법.
제 6 항에 있어서,

상기 테스트 케이스는 상기 이뮬레이터에서 실행하기 위하여 스크립트 형태로 생성되는 것을 특징으로 하는 임베디드 소프트웨어의 인터페이스 자동 추출 방법.
삭제
삭제
삭제
제 1 항에 있어서,

상기 임베디드 소프트웨어는 소스 코드 또는 오브젝트 코드 중 어느 하나인 것을 특징으로 하는 임베디드 소프트웨어의 인터페이스 자동 추출 방법.
제 1 항에 있어서,

상기 b)는,

상기 임베디드 소프트웨어의 코드로부터 OS와 하드웨어간의 인터페이스들을 구분하고,

상기 구분된 인터페이스들로부터 호출되고, 호출받는 인터페이스들을 확인하고, 그리고

상기 임베디드 소프트웨어의 코드로부터 상기 확인된 각각의 인터페이스들에 대응하는 인터페이스 심볼을 추출하는 것을 포함하는 임베디드 소프트웨어의 인터 페이스 자동 추출 방법.
제 1 항에 있어서,

상기 임베디드 소프트웨어는,

하드웨어, 상기 하드웨어의 구동을 명령하는 어플리케이션 프로그램, 상기 하드웨어의 초기화 및 설정하는 HAL, 및 상기 어플리케이션 프로그램을 구동하기 위한 환경을 제공하는 OS와 연동되는 것을 특징으로 하는 임베디드 소프트웨어의 인터페이스 자동 추출 방법.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
임베디드 소프트웨어의 인터페이스를 테스트 항목을 제공하는 인터페이스 테스트 항목부; 그리고

상기 임베디드 소프트웨어의 코드와 상기 테스트 항목간에 대응되는 인터페이스 심볼을 추출하는 인터페이스 심볼 추출부를 포함하는 임베디드 소프트웨어의 인터페이스 자동 추출 장치.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제