실제타겟 환경에서의 소프트웨어 테스트 방법 차량용소프트웨어개발 증가 전자 산업이 발달하면서 자동차 분야의 많은 기계식 제어 장치들이 전자식 제어로 빠르게 변화하고 있다. 차량의 성능을 개선할 뿐만 아니라 사용자의 편의를 향상시킬 수 있다는 장점 때문에 전자제어 장치의 수는 계속해서 늘어나고 있으며, 차량 한 대에 들어가는 ECU 수와 하나의 ECU가 처리해야 하는 소프트웨어의 양도 점차 증가 하고 있다. 최근 발생한 도요타 차량의 급발진 사고는 소프트웨어의 결함이 원인으로 밝혀졌으며, SW를제대로 검증하지 않은 책임에 대해 도요타 측에 거액의 벌금이 부과 되었다. 소프트웨어 양의 증가는 동일한 수준의 복잡도 증가로 이어진다. 그리고 소프트웨어 복잡도의 증가는결함이 발생할 수 있는 확률을 증가시키게 된다. 결국 이러한 결함은 도요타 차량 급발진과 같은 회사 존립에 치명적인 사고로 이어질 수 있다는 것이 확인된 것이다. 결국 차량 오작동으로 인한 사고의 발생 빈도수가 점점 증가하는 현실에서 결함 없는 소프트웨어의 개발은 제품과 기업의 경쟁력을 좌우하는 기준이 된다. 
[그림1]차량내 ECU증가 추이와 차량 전장화율 전망 결함이 없는 소프트웨어 개발과 시뮬레이션 기반 테스트의한계 이렇듯 소프트웨어를 개발하다 보면 장애를 발생시킬 가능성이 포함된, 결함이 있는 코드를 작성하는 오류를 범할 수 있다. *오류(Error): 문법을 따르지 않는 등의 부정확한 결과를 초래하는 개발자의 실수나 활동 *결함(defect): 코드상에 개발자에 의해 저질러진 오류, 흔히 Bug라고 함 *장애(failure): 결함이나 환경적인원인에 의해 발생하는 문제점 (기능을 수행할 수 없거나, 정의되지 않은 동작을 수행하는 등 예상과 실제결과가 편차를 보이는 것). ECU에 탑재되는 소프트웨어는 여러 개의 함수가 모여 모듈을 이루고여러 개의 모듈이 모여 전체 프로그램으로 구성된다. 따라서 결함이 없는 소프트웨어를 개발하기 위해서는작은 단위의 프로그램에서 오류를 제거한 코드를 합쳐 좀더 큰 단위의 프로그램으로 결합해 나가는 과정이 필요하다. 이러한 접근 방식을 Bottom-up 이라고 하며, Top-down 방식보다 좀 더 쉽고 효율적으로결함을 발견할 수 있는 장점이 가진다. 궁극적으로 개발자는 결함을 제거하고 통합하는 과정을 통해 디버깅 시간을 단축시킬 수 있다. 그리고 기능과 성능, 안정성, 요구사항에 만족하는 소프트웨어를 개발할 수 있게 된다. *Bottomp-up(상향식) 테스트 : 가장 낮은(작은) 단위의 구성요소들을 먼저 테스트하여 통합해 나가는 테스트 방법이다. 계층의 최상위 요소가 테스트 될 때까지 반복한다. *Top-down(하향식) : 최상위 모듈을 먼저 테스트하고, 각각의 하위 구성요소들을테스트해나가는 방법이다. 연관된 마지막 모듈이 테스트 될 때까지 반복한다. <위키피디아 “Integration testing” 참고> 그런데 보통의 소프트웨어 테스트는 Desktop 기반의 시뮬레이션 환경에서 이루어지는 경우가많다. 문제는 시뮬레이션 테스트의 경우 interrupt 나 exception, floating point 연산과 같은 실제 타겟 환경의 영향으로 발생가능한 현상이 고려되지 않아 수행 결과가 예상과 다를 수 있다는 것이다. 결국 장애 발생률을 현저히 낮추기 위해서는 다시 실제 타겟 환경에서 SW를 동작해보는 검증을 수행해야 한다. 따라서 본 글에서는 프로그램을 실제 타겟 프로세서에서 수행한 결과를 도출할 수 있는 테스트방법을 소개할 것이다. 이를 통해실제 프로그램 동작 결과를 검증할 수 있다. 그리고 실제 테스트 환경에서 주로 사용하는 Test Harness 방식이 아닌, 실제 타겟에 다운로드 될 프로그램 그대로를 가지고 테스트하는 방안을 제시하도록 하겠다. 실제 타겟 환경에서의 테스트 방법 프로그램을 테스트하기 위해서는 코드가 다운로드 된 타겟과 원하는 프로그램의 위치에서 입력 값을 변경하고 출력 값을 가져오기 위해 코어의 동작을 멈추고 실행할 수 있는 디버깅 장비가 필요하다. 그리고 수많은 테스트 케이스를 적용하여 결과를 출력해야 하기 때문에 반복된 작업을 자동화 할 수 있는 방법이 필요하다. 다행히도 TRACE32 디버거와 PowerView 소프트웨어를 이용하면 별도의 스크립트 프로그램을 이용하여 손쉽게 테스트를 수행할 수 있다. 먼저 개발자는 테스트하길 원하는 함수 또는 모듈의 시작과 끝, 그리고 입력과 출력 변수를 지정할 수 있다. 테스트의 시작점은 프로그램상의 입력 값이 결정되는 지점이며, 끝 지점은 변경된입력 값에 따라 테스트 영역의 코드가 수행된 후 출력 값이 결정되는(결과 값을 확인하고 싶은) 지점이 된다. 그리고 입력과 출력 데이터는 실제 타겟 프로그램에서 사용되는 변수 이름을 선택하면 된다. 
[그림2] 테스트를 원하는 시작과 끝 지점(테스트닛 영역설정)은 개발자가 지정한다. 이렇게 테스트 자동화 스크립트에서 사용할 데이터(테스트시작/끝 주소, 입/출력 변수명, 테스트 케이스 입력)를 설정하고,개발자가 해야 할 일은 자동화 스크립트를실행해 주는 것이다. 이 후의 테스트 과정은 TRACE32 PowerView 소프트웨어가 알아서 수행한다. 스크립트프로그램을 활용한 테스트 아래는 간단한 유닛 테스트와 그 자동화의 예이다. TRACE32 PowerView 소프트웨어는 스크립트 프로그램을 수행하면서 테스트 케이스가 저장된 파일에서 한 세트의 케이스 조합을 읽어 들인다. 그리고 프로세서가입력 값을 변경해야 할 위치의 코드를 수행할 때 프로그램을 멈추고, 테스트케이스 값을 입력 변수에 입력한다. 이어서 결과 값을 출력할 프로그램 위치까지 프로세서가 동작하도록 한 뒤에 지정된 출력 변수의 값을 별도의 파일에 저장하게 된다. 
[그림3] TRACE32 Powerview 상에서 스크립트를 이용하여 자동으로 테스트를 진행중인 화면 
[그림4] 테스트 자동화 스크립트수행 결과 입력 변수에 테스트 케이스를 적용하여 프로그램 수행 후 출력 변수 값을 파일로 저장 이러한 TRACE32 디버거와 PowerView 소프트웨어의 스크립트를 활용한 테스트의 장점은 블랙박스 테스트를 실행한 뒤, 입-출력 간의 문제가 발생하는 경우에 대해 바로 코드 레벨에서 자세한 디버깅을 실행할 수 있다는 것이다. 이는 프로그램 오류를 찾아 내는데 있어서 시간과 노력의 측면에서 큰 효율성을 가지게 해준다. 앞으로의 자동차 시장에서 소프트웨어가 차지하는 비율은 점점 커질 것이다. 그리고 소프트웨어와 프로세서는 점점 고성능의 기능수행을 위해 복잡한 연산을 수행하게 된다. 개발자에게 시뮬레이션 환경이 아니라 실제 타겟 환경에서의 동작 결과를 바탕으로 하는테스트는 신뢰성 높은 소프트웨어를 만들기 위해 꼭 필요한 과정이다. 앞에서 설명한 바와 같이 TRACE32 디버거와 Powerview는 이러한 검증 절차를 정확하고 편리하게 할 수 있도록 한다. 이는 오류 없는 소프트웨어 개발을 보다 효율적으로 빠르게 진행하여 개발 소요 시간을 줄일 수 있을 뿐만 아니라, 이후 유지보수에 드는 비용 또한 줄일 수 있도록 도와 줄 것이다. 문의: trace32@mdstec.com | 
