차량용 소프트웨어 개발 테스트 환경 및 자동화

소프트웨어를 개발할 때 테스트는 기본적으로 같이 이루어져야 한다. 이 글에서는 차량용 소프트웨어를 개발할 때 ASPICE 프로세스를 기준으로 어느 단계에서 어떤 테스트가 이루어져야하는지를 간단히 소개하고 이를 CI와 연결하여 자동으로 테스트할 수 있는 방법에 대해서 이야기해보고자 한다.

ASPICE Overview

 

이론은 크게 어렵지 않지만 실제 개발에 적용하기란 단계에 따라 상당히 어려울 수 있다. 이유도 가지 각색으로 정말 다양하다. 개발 리소스, CI 리소스, 하드웨어 리소스 문제, 안정성 문제, Component/SW Elements 등에 대한 정의의 문제, 의존성 문제 등등 말이다. 이 각각의 문제를 필자의 경험을 토대로 어떻게 하면 해결할 수 있을까 또는 왜 그렇게 어려운가에 대해서 하나씩 풀어보고자 한다.

 

https://www.atlassian.com/ko/continuous-delivery/software-testing/types-of-software-testing 글에서 보면 일반적인 소프트웨어의 다양한 테스트 유형이 있다. 단위 (Unit) 테스트, 통합 (Integration) 테스트, 기능 (Feature) 테스트, 엔드 투 엔트 (End-to-End) 테스트, 수용 테스트 (Acceptance) 테스트, 성능 (Performance) 테스트, 스모크 (Smoke) 테스트 등이 있으며 각각의 테스트가 의미하는 것은 위의 링크를 가서 읽어보기 바란다.

 

이 글에서는 자동차 소프트웨어 개발시 많이 회자되는 프로세스인 ASPICE의 Software Level (SWE)의 테스트인 Software Unit Verification, Software Integration Test, Software Qualification Test 를 설명하고 다음글에서 System Level(SYS)의 System Integration Test, System Qualification Test에 대해서 이야기해보고자 한다.

 

아래 SWE 4,5는 대부분 개발팀에서 테스트가 이루어지고 SWE 6은 개발팀이 일부 통합 검증 팀에서 일부 진행하기도 한다. 물론 회사마다 프로젝트 정책마다 다르긴 하다.

SW Tests in ASPICE

SW Unit Verification (SWE.4)

이 테스트의 목적은 소프트웨어 단위가 소프트웨어 상세 설계 및 비기능적 소프트웨어 요구 사항을 준수한다는 증거를 제공하기 위해 소프트웨어 단위와 컴포넌트를 검증하는 것이다.

 

여기서 사용할 수 있는 테스트 방법은 유닛 테스트, 컴포넌트 테스트, 정적 분석, 코드 리뷰, MIRSA 규칙 적용, 테스트 커버리지 등이 있다. 

https://www.flecsim.de/images/download/AutomotiveSpiceShortened/Automotive%20Spice%203.1/SWE.4.html 에 더 자세한 내용들이 있다.

Software Integration Test (SWE.5)

이 테스트의 목적은 소프트웨어 아키텍처 설계와 일치하지 확인하기 위한 테스트이다. 이름처럼 소프트웨어 유닛간 통합 전략에 따라 인터페이스를 포함한 것들을 SW Element와 Sub System 수준에서 테스트하고 통합을 한다.

 

여기서 사용할 수 있는 테스트 방법은 SW Element 테스트, UI 테스트, Smoke Test 등이 있다. 컴포넌트 내에서의 통합 테스트도 있지만 컴포넌트 개념이 확장된 의존성 있는 컴포넌트 들의 집합인 SW Elements 테스트도 가능하다. 필자의 회사에서는 Yocto 기반의 리눅스인 경우 QEMU에서 oeqa으로 integration test를 정의하여 사용하고 있고 각 팀의 테스트 케이스도 각각 따로 정의되어 있다. https://www.flecsim.de/images/download/AutomotiveSpiceShortened/Automotive%20Spice%203.1/SWE.5.html 에 더 자세한 내용들이 있다.

SW Qualification Test (SWE.6)

이 테스트의 목적은 통합된 소프트웨어가 요구사항을 준수하는지 Sub System과 통합된 System 수준에서 검증하는 것이다.

 

여기서 사용할 수 있는 테스트 방법은 Feature 테스트, Security Test, 유저 시나리오 테스트 등이 있다. https://www.flecsim.de/images/download/AutomotiveSpiceShortened/Automotive%20Spice%203.1/SWE.6.html 에 더 자세한 내용들이 있다.

Test Automation

SWE.4에 컴포넌트 저장소 내에서의 테스트 자동화는 대부분 CI를 통해 어렵지 않게 진행될 수 있다. 실제 하드웨어에서 하기도 하지만 Virtual/Emulator 환경이나 빌드하는 동안 Linux/Windows 환경에서도 돌아갈 수 있도록 구성하여 테스트를 가능하도록 한다.

 

SWE.5는 약간 개념이 확정되어 컴포넌트 저장소 외에 의존성 있는 컴포넌트와 같이 묶여서 테스트를 하는 경우가 생겨 Virtual/Emulator 환경이나 실제 하드웨어에서 자동화가 이루어진다. Virtual/Emulator 환경을 가지고 있는 경우 CI와 연동하여 빌드 후 바로 실제 하드웨어 없이 자동화를 구성할 수 있고 필자의 회사에서도 QEMU Emulator 환경에서 구성하여 사용하고 있다. 하지만 구성상 문제로 안정성이 떨어져 개선을 지속적으로 하고 있다. 실제 하드웨어에서도 자동화 테스트를 붙이는 작업을 하고 있지만 하드웨어 안정성, 리소스 확보에 대한 이슈로 실험적인 환경에 있다.

 

SWE.6은 실제 하드웨어에서 테스트를 하도록 가이드 권장을 하고 있고 결과는 Yocto 기반 리눅스의 경우 MR/PR (Merge Request / Pull Request)를 Yocto 레이어에 생성할 때 Jira 의 Test Management 티켓을 생성하여 실제 하드웨어에서 Smoke 테스트나 기본 기능 테스트를 하여 첨부하도록 하고 있다. 위에서 이야기한 것처럼 자동화는 구축중이며 현재는 수동으로 진행하고 있다.

정리

컴포넌트마다 SW Element 마다 명확하게 아키텍처적으로 정의를 해야하고 각각의 테스트 케이스를 규정하여 잘 관리하면 좋다. 이론적으로는 모든 것이 가능하지만 수백개의 스크럼 팀이 같이 개발하는 환경에서는 상당히 어려움이 많다. 템플릿을 정의해도 각 팀의 상황에 따라 약간씩 달라질 수 있고 실제로는 개발팀이 그 기능등에 대한 것을 잘 알고 있기 때문에 협조를 잘해서 함께 해야하지만 의사소통 문제, 리소스 문제, 개발팀의 테스트에 대한 이해도 등에 따라 잘되는 팀이 있고 어려운 팀이 있다.

 

자동화의 문제도 위와 비슷한 문제를 겪고 있고 추가적으로 하드웨어 리소스 및 안정성 등에 대한 문제가 생긴다. 지속적으로 위에서 언급한 문제를 해결하기 위해 노력하고 있고 이번 양산의 경험을 토대로 개발 프로세스, 테스트 등 많은 것들을 개선시키는 중에 있다.

 

점점 더 복잡해져가는 소프트웨어 복잡도를 해결하면서 빠른 개발 프로세스와 품질의 안정성을 동시에 가지고 가기 위해 다양한 시도를 진행하고 있다. 여전히 갈길은 멀다 :)

Reference

• ASPICE: https://www.flecsim.de/images/download/AutomotiveSpiceShortened/