볼프강 하르티그 (Wolfgang Hartig)
아시아태평양 오토모티브 마케팅 책임자
Vector Informatik GmbH
wolfgang.hartig@vector-informatik.de
알버트 하베르만 (Albert Habermann)
eASEE 프로세스 툴 프로젝트 매니저, 커스터머 서비스 부문
Vector Informatik GmbH
albert.habermann@vector-informatik.de
주르켄 모토크 (Jurgen Mottok)
컴퓨터 과학부 교수, 레겐스베르크 응용과학 대학교
juergen.mottok@e-technik.fh-regensburg.de

소프트웨어 엔지니어링은 매우 큰 혁신 잠재력을 지닌 컴퓨터 과학 분야이다. 소프트웨어의 복잡성과 결과적인 정보 과잉으로 인해 모델과 코드의 일관성을 효율적으로 보장하는 방법과 관련된 품질 보증 문제가 제기되고 있다. 개발 초기 단계에 사용된 테스트 전략과 프로세스는 기술 및 설계 오류들을 조기에 발견할 수 있도록 해줘 이들을 한층 더 비용 효율적으로 수정할 수 있게 한다.
모델-기반 개발은 소프트웨어 엔지니어링 방법으로 시스템을 문서화하는 것 외에도 대부분의 테스트 문서를 생산하는 자동 생성 기능으로도 활용한다. 실제로 대부분의 테스트 케이스들은 여전히 수작업으로 생성되고 있다. 전통적인 문서-기반 접근법의 경우, 테스트 케이스들이 요구사항들로부터 파생되어 테스트 사양에 기술된다. 이러한 사양을 바탕으로 테스트를 실행해 ECU에 적합한 소프트웨어 구현 방법을 검증한다.
지난 5년 동안 자동차 OEM들은 임베디드 소프트웨어를 개발하기 위해 모델-기반 방법들을 더욱 많이 적용해 왔다. 이러한 모델-기반 방법들을 개발 프로세스에 통합할 수 있는 접근법들 중 하나는 기능 모델들을 개발하면서 소프트웨어를 수작업으로 ECU 내에 구현하는 것이다(그림 1). 실행 가능한 기능 모델들을 개발하는 것은 요구사항 분석 및 개발에서의 품질 향상을 의미한다. 우선, 기능 모델은 기능을 정의한 다음 해당 요구사항과 관련해 이를 검증한다. 테스트 사양은 기능 모델을 검증하는 데 사용되어야만 한다. 이같은 프로세스를 통해 에러와 불일치들을 초기 개발 단계에서 발견해 이후, 즉 시스템 또는 승인 테스트 후에 이들을 수정할 때 필요한 비용의 일부만으로 수정할 수 있게 된다. 보드 툴 지원, 즉 자동으로 생성된 생산 코드를 사용해 ECU 소프트웨어 개발 기간의 최소화를 보장한다.
복잡한 기능 모델의 단계식 개발 및 검증을 위해 효율적인 테스트 방법을 사용한다. 개발 프로세서의 각 단계에서 에러들이 유입되지 않았는지를 검증하기 위해서 확인 작업을 수행해야 한다. 모델-기반 테스트로 알려진 프로세스에서 테스트 케이스 제너레이터는 기능 모델을 사용해 자동으로 테스트 케이스를 생성한 다음 이를 자동으로 실행하고 평가해 문서화할 수 있다.
그 외 쟁점으로는 자동으로 생성된 테스트 케이스를 어디에 적용하는 것이 타당한지, 그리고 이것들이 임베디드 차량 시스템들의 개발에 어떠한 장점들을 제공하는지 등이 있다. 새로운 접근법은 반복적인 기능 모델 개발, 예를 들면 회귀 테스트를 위한 테스트 케이스를 자동으로 생성하는 데 사용될 수 있다. 또한 ECU 승인 테스트 등과 같은 개발 프로세스의 후반부 테스트 단계에서 이러한 개발 단계에서 생성한 테스트 케이스를 재사용할 수도 있다.

테스트 케이스 제너레이터를 통한 회귀 테스트의 단순화

요구사항은 종종 변경되기 쉽다. 요구사항 정의에서 발견된 특정 에러를 수정하고, 개발중인 시스템의 기능을 확장하기 위해서 새로운 기능들을 추가할 수 있다. 후반부 개발 프로세스에서의 실행은 모든 기능을 유지하면서 종종 재구조화되거나 단순화되곤 한다. 이미 개발이 완료된 기능 모델들은 새로운 조건에 맞게 조정된다. 이러한 프로세스에서 개발자들은 기능 모델의 변경이 새로운 에러나 바람직하지 않은 영향을 기능에 유입시키지 않도록 보장해야 한다. 이같은 요구는 회귀 테스트(recession test)를 통해 달성될 수 있다[1]. 이러한 목표를 달성하기 위해서는 3가지 단계가 필요하다.

- 회귀 테스트를 위해 적합한 MiL(Model-in-the-Loop) 테스트 환경이 개발되어야만 한다.
- 다음으로 이러한 MiL 테스트 환경 내에서 테스트 케이스들이 실행되어야 한다. 
- 회귀 테스트가 자동적으로 평가되어야 한다.

회귀 테스트의 중요한 측면은 이전 버전과 수정된 기능 모델의 품질 비교이다. 품질의 측정기준 중 하나는 코드 커버리지이며, 이것이 기능 모델의 각기 다른 버전들을 비교하는데 최대 가능 커버리지가 필요한 이유이다. 요구사항들과 관련된 테스트 케이스에서 코드 커버리지가 더 클수록 막대한 노력이 부과되는데 커버리지 격차가 존재할 경우에 관련 코드 섹션들이 분석되어야 하고, 필요한 코드 커버리지가 확보될 때까지 그 외 다른 요구사항-기반 테스트 케이스들을 수작업으로 생성해야 할 수도 있기 때문이다. 이러한 막대한 노력으로 인해 수작업으로 회귀 테스트를 위한 테스트 케이스를 생산하는 것을 더 이상 권고할 수 없다.
하나의 답은 매스웍스(Mathworks)의 Simulink Design Verifier 또는 IBM의 Telelogic Rhapsody ATG 등과 같은 새롭게 상용으로 제공되고 있는 테스트 케이스 제너레이터를 사용하는 것이다. 획득될 특정 코드 커버러지를 지정하고 나면 테스트 케이스들이 자동으로 생성된다. 다음으로 테스트 케이스들은 비교 품질을 증대시킨다. 뿐만 아니라, 툴들은 대개의 경우 MiL 테스트 환경을 동시에 생성하고, 테스트 보고서를 자동으로 생성할 수 있다. 이를 통해 작업 처리 시간이 매우 짧은 작업 방법을 시스템 전반에 사용할 수 있다. 다시 말해 이로 인해 기능 모델들에 대한 회귀 테스트의 실행이 단순해져서 비용과 시간을 줄일 수 있다.
그림 2는 MiL 테스트 환경에서의 회귀 테스트의 실행을 나타낸 것이다. 기능들은 Simulink/Stateflow에서 모델링되며 Simulink Design Verifier가 테스트 케이스를 생성한다. 테스트 케이스 제너레이터를 통해 테스트 케이스들을 획득할 수 있다면 원칙적으로 다른 모델링 툴들도 사용할 수 있다.
다이어그램에 나타낸 ‘테스트 케이스(Test Case)’ 블록은 자동으로 생성된 테스트 케이스를 포함하고 있으며, 테스트 과정에서 ‘테스트 유닛(Test Unit)’ 시스템을 시뮬레이션한다. 이것은 수정된 기능 모델을 나타낸다. ‘기대 결과’ 블록은 이 기능 모델의 이전 버전의 레퍼런스 출력들을 포함하고 있다. ‘회귀 테스트 애널라이저(Regression Test Analyzer)’ 블록에서 수정 기능 모델로부터 새롭게 생성된 출력을 시뮬레이션의 각 단계에서 레퍼런스 출력과 비교된다. 테스트를 수행한 후 스크립트는 자동으로 테스트 보고서를 생성하고 이를 요구되는 출력 포맷으로 변경한다. 이 사례의 경우, 출력 포맷이 벡터 인포르마틱의 CANoe 테스트 보고서와 일치한다. 평가 결과 출력에서 차이가 발견되면, 확인 과정을 통해 차이가 수용 가능한지 또는 에러인지를 확인해야만 한다.
이때 반복 접근법이 지속적인 개선을 지원하고 기능 모델을 새로운 요구사항들에 맞게 조정하는 데 있어서 효율적인 방법이다. 이것은 또한 기능 모델의 품질을 개선시킨다. 뿐만 아니라, 개발 프로세스 각 단계에서의 검증 작업을 통해 품질을 한층 더 개선하면서 새로운 에러가 유입되지 않았다는 것을 보장할 수 있다. 이러한 모델 기반 접근법을 통해 기능을 개발하는 경우에 테스트 케이스들을 활용할 수 있다. 목표는 기능 모델의 회귀 테스트를 위해서뿐만 아니라 ECU 승인 테스트와 같은 자동차 소프트웨어 엔지니어링 프로세스의 후반부 테스트 단계들을 위해 이러한 테스크 케이스들을 사용하는 것이다.

ECU 승인 테스트에서 테스트 케이스의 재사용

승인 테스트의 목표는 공급업체들이 ECU 내에 구현한 소프트웨어 기능들이 사양에서 정의된 바와 같이 동작하는지를 검증하는 것이다. 승인 테스트를 수행하기 위해서 지정된 기능을 테스트하는 데 알맞은 테스트 케이스들이 생성되어야 한다. 확실한 것은 모델 기반 개발을 통해 생성된 테스트 케이스들을 재사용할 수 있는 잠재적인 방법이 HiL(Hardware-in-the-Loop) 테스트 환경 내에 있다는 것이다. 이때의 장점은 테스트 케이스들을 수작업을 통해 재생성할 필요가 없다는 것이다.
테스트 케이스들을 재사용하기를 원하는 테스터들은 테스트 환경을 MiL(Model-in-the-Loop)에서 HiL(Hardware-in-the-Loop)로 변경하는 것 또한 테스트 한계를 변화시킨다는 것을 알 수 있다. MiL 테스트 환경 내의 테스트 케이스들은 기능 모델의 논리적 입력 및 출력 신호들을 다시 참조한다. 반면 HiL 테스트 환경 내의 테스트 케이스들은 시스템을 시뮬레이션하고 시스템 동작을 평가하는 데 있어서 CAN 신호와 같은 물리적 신호가 필요하다. 따라서 관련 CAN 신호에 대해 논리적 신호들을 맵핑하는 것을 포함해 테스트 케이스들을 변환해야 한다(그림 3).
또한 변환을 수행할 때 모델링 툴 내의 테스트 케이스들이 HiL 테스트를 위한 툴, 즉 CANoe 내의 테스트 케이스와 데이터 구조 또는 데이터 포맷이 반드시 같지는 않는다는 것을 기억해야 한다.
사실상 이와 같은 변환을 수행하는 데 XSLT 스타일시트(XSLT Stylesheet)를 사용할 수 있다. 예를 들어, 이것은 테스트 케이스들이 모델링 툴로부터 XML 포맷으로 익스포트 될 수 있다는 것을 가정한다. 테스트 케이스들을 해당 HiL 테스트 환경에 알맞은 실행 가능 테스트 스크립트로 변환하기 전에 중간 단계가 반드시 필요하다: 예를 들어 엑셀(Exel) 테이블의 사용과 같은 신호 맵핑이 필요하다. 애플리케이션을 위한 비주얼 베이직(Visual Basic)은 맵핑이 실행된 XSLT 스타일시트와 관련 아이템들을 대체한다. 마지막으로 변환된 테스트 케이스들은 링크되고 자동으로 CANoe에서 실행된다. 자동으로 생성된 테스트 보고서는 테스트 결과를 평가할 수 있도록 해준다. 이 툴 체인에서 반드시 필요한 단계들 모두를 자동화시킬 수 있기 때문에 시간과 비용을 절감할 수 있다.
재사용 가능한 테스트 케이스들을 통한 승인 테스트를 통해 이제 소프트 통합성과 하드웨어 통합성 모두를 테스트한다. 테스트는 소프트웨어 컴포넌트가 지정된 인터페이스들을 통해 다른 소프트웨어 컴포넌트들과 알맞게 상호 동작하는 지를 검증한다[1]. 또한 ECU 하드웨어를 통한 전체 소프트웨어 시스템의 상호작용을 HiL 테스트 환경에서 테스트한다. 이를 통해 ECU 내에서의 전체 실행을 검증한다.