보통의 SW 테스트는 데스크톱 기반의 시뮬레이션 환경에서 이뤄지는 경우가 많다. 문제는 시뮬레이션 테스트의 경우 interrupt나 exception, floating point 연산과 같은 실제 타깃 환경의 영향으로 발생 가능한 현상이 고려되지 않아 수행 결과가 예상과 다를 수 있다는 것이다. 결국 장애 발생률을 현저히 낮추기 위해서는 다시 실제 타깃 환경에서 SW를 동작해 보는 검증을 수행해야 한다. 이 글에서는 프로그램을 실제 타깃 프로세서에서 수행한 결과를 도출할 수 있는 테스트 방법을 소개한다.

차량용 SW 개발 증가

전자산업이 발달하면서 자동차 분야의 많은 기계식 제어장치들이 전자식 제어로 빠르게 변화하고 있다. 차량의 성능을 개선할 뿐만 아니라 사용자의 편의를 향상시킬 수 있다는 장점 때문에 ECU(전자제어장치)의 수는 계속해서 늘어나고 있으며, 차량 한 대에 들어가는 ECU 수와 하나의 ECU가 처리해야 하는 SW의 양도 점차 증가 하고 있다.

최근 토요타 차량의 급발진 사고는 SW의 결함이 원인으로 밝혀졌으며, SW를 제대로 검증하지 않은 책임에 대해 토요타 측에 거액의 벌금이 부과됐다. 이 판결에 결정적인 역할을 한 바(BARR) 그룹의 조사 보고서에 의하면 ETCS(Electronic Throttle Control)에 오류(버그)가 있었으며, 이를 커버해 주는 방어수단도 작동하지 않았다는 것이 증명됐다. 결국 SW결함으로 인한 급발진으로 인해 토요타는 12억 달러(1조 2,800억 원)의 벌금과 손해배상금 300만 달러 이상의 손실을 떠안게 됐다.



SW 양의 증가는 동일한 수준의 복잡도 증가를 의미한다. 그리고 SW 복잡도가 증가하면 결함이 발생할 수 있는 확률을 증가시키게 된다. 이러한 결함은 위 토요타 사례에서 확인할 수 있듯이 회사 존립에 치명적인 사고로 이어질 수 있다. 따라서 차량 오작동으로 인한 사고의 발생 빈도수가 점점 증가하는 현실에서 결함 없는 SW의 개발은 제품과 기업의 경쟁력을 좌우하는 기준이 된다.

결함 없는 SW 개발과 시뮬레이션 기반 테스트 한계

이렇듯 SW를 개발하다 보면 장애를 발생시킬 가능성이 있거나 결함이 있는 코드를 작성하는 오류를 범할 수 있다.

- 오류(Error): 문법을 따르지 않는 등의 부정확한 결과를 초래하는 개발자의 실수나 활동
- 결함(defect): 코드 상에 개발자에 의해 저질러진 오류, 흔히 Bug라고 함
- 장애(failure): 결함이나 환경적인 원인에 의해 발생하는 문제점(기능을 수행할 수 없거나, 정의되지 않은 동작을 수행하는 등 예상과 실제결과가 편차를 보이는 것).

ECU에 탑재되는 SW는 여러 개의 함수가 모여 모듈을 이루고, 여러 개의 모듈이 모여 전체 프로그램으로 구성된다. 따라서 결함이 없는 SW를 개발하기 위해서는 작은 단위의 프로그램에서 오류를 제거한 코드를 합쳐 좀더 큰 단위의 프로그램으로 결합해 나가는 과정이 필요하다. 이러한 접근 방식을 Bottomup이라고 하며, Top-down 방식보다 좀 더 쉽고 효율적으로 결함을 발견할 수 있는 장점이 있다. 궁극적으로 개발자는 결함을 제거하고 통합하는 과정을 통해 디버깅 시간을 단축시킬 수 있다. 그리고 기능과 성능, 안정성, 요구사항에 만족하는 SW를 개발할 수 있게 된다.

- Bottomp-up(상향식) 테스트: 가장 낮은 (작은) 단위의 구성요소들을 먼저 테스트하여 통합해 나가는 테스트 방법이다. 계층의 최상위 요소가 테스트 될 때까지 반복한다.
- Top-down(하향식): 최상위 모듈을 먼저 테스트하고, 각각의 하위 구성요소들을 테스트해 나가는 방법이다. 연관된 마지막 모듈이 테스트 될 때까지 반복한다<위키피디아 “Integration testing” 참고>.

그런데 보통의 SW 테스트는 Desktop 기반의 시뮬레이션 환경에서 이루어지는 경우가 많다. 문제는 시뮬레이션 테스트의 경우 interrupt나 exception, floating point 연산과 같은 실제 타깃 환경의 영향으로 발생 가능한 현상이 고려되지 않아 수행 결과가 예상과 다를 수 있다는 것이다. 결국 장애 발생률을 현저히 낮추기 위해서는 다시 실제 타깃 환경에서 SW를 동작해 보는 검증을 수행해야 한다.

따라서 본 글에서는 프로그램을 실제 타깃 프로세서에서 수행한 결과를 도출할 수 있는 테스트 방법을 소개할 것이다. 이를 통해 실제 프로그램 동작 결과를 검증할 수 있다. 그리고 실제 테스트 환경에서 주로 사용하는 Test Harness 방식이 아닌, 실제 타깃에 다운로드 될 프로그램 그대로를 가지고 테스트하는 방안을 제시하도록 하겠다.

실제 타깃 환경에서의 테스트 방법

프로그램을 테스트하기 위해서는 코드가 다운로드된 타깃과 원하는 프로그램의 위치에서 입력 값을 변경하고 출력 값을 가져오기 위해 코어의 동작을 멈추고 실행할 수 있는 디버깅 장비가 필요하다. 그리고 수많은 테스트 케이스를 적용해 결과를 출력해야 하기 때문에 반복된 작업을 자동화 할 수 있는 방법이 필요하다. 다행히도 TRACE32 디버거와 PowerView SW를 이용하면 별도의 스크립트 프로그램을 이용해 손쉽게 테스트를 수행할 수 있다.

먼저 개발자는 테스트하길 원하는 함수 또는 모듈의 시작과 끝, 그리고 입력과 출력 변수를 지정할 수 있다. 테스트의 시작점은 프로그램 상의 입력 값이 결정되는 지점이며, 끝 지점은 변경된 입력 값에 따라 테스트 영역의 코드가 수행된 후 출력 값이 결정되는 (결과 값을 확인하고 싶은) 지점이 된다. 그리고 입력과 출력 데이터는 실제 타깃 프로그램에서 사용되는 변수 이름을 선택하면 된다.

이렇게 테스트 자동화 스크립트에서 사용할 데이터(테스트 시작/끝 주소, 입/출력 변수명, 테스트 케이스 입력)를 설정하고, 개발자가 해야 할 일은 자동화 스크립트를 실행해 주는 것이다. 이 후의 테스트 과정은 TRACE32-PowerView SW가 알아서 수행한다.

스크립트 프로그램 활용한 테스트

아래는 간단한 유닛 테스트와 그 자동화의 예이다. TRACE32-PowerView SW는 스크립트 프로그램을 수행하면서 테스트 케이스가 저장된 파일에서 한 세트의 케이스 조합을 읽어 들인다. 그리고 프로세서가 입력 값을 변경해야 할 위치의 코드를 수행할때 프로그램을 멈추고, 테스트 케이스 값을 입력 변수에 입력한다. 이어서 결과 값을 출력할 프로그램 위치까지 프로세서가 동작하도록 한 뒤에 지정된 출력 변수의 값을 별도의 파일에 저장하게 된다.

이러한 TRACE32 디버거와 PowerView SW의 스크립트를 활용한 테스트의 장점은 블랙박스 테스트를 실행한 뒤, 입-출력 간의 문제가 발생하는 경우에 대해 바로 코드 레벨에서 자세한 디버깅을 실행할 수 있다는 것이다.
이 방법은 프로그램 오류나 결함(버그)을 찾아내는데 필요한 시간과 노력을 상당히 줄여주므로 개발 효율 제고에 큰 효과를 발휘한다.

앞으로 자동차시장에서 SW가 차지하는 비중은 점점 커질 것이다. 그리고 SW와 프로세서는 점점 고성능의 기능 수행을 위해 복잡한 연산을 수행하게 된다. 개발자에게 시뮬레이션 환경이 아니라 실제 타깃 환경에서의 동작 결과를 바탕으로 하는 테스트는 신뢰성 높은 SW를 만들기 위해 꼭 필요한 과정이다.

앞에서 설명한 바와 같이 TRACE32 디버거와 Powerview는 이러한 검증 절차를 정확하고 편리하게 할 수 있도록 한다. 이는 오류 없는 SW 개발을 보다 효율적으로 빠르게 진행하여 개발 소요 시간을 줄일 수 있을 뿐만 아니라, 이후 유지보수에 드는 비용 또한 대폭 절감시켜 개발 생산성이 높아질 것이다.