논문요약 - 임베디드 소프트웨어 테스팅 방법론 by Lepistö

제목: 임베디드 소프트웨어 테스팅 방법론(Embedded Software Testing Methods)

저자: Juho Lepistö, 핀란드

문서유형: 학사논문(총 73페이지), 2012년

 

핀란드의 임베디드 제품 설계 업체인 Efore Group의 현행 개발 프로세스를 개선하여 개발 주기 후반에 치중된 임베디드 소프트웨어 테스팅을 초기 단계부터 적용하도록 제안한 자료

 

---

 

이 논문은 Efore Group 제품 개발을 위해 작성되었다. Efore Group은 1975년 핀란드에서 설립되었으며, 현재 Efore는 고성능, 신뢰성 및 효율성을 요구하는 맞춤형 설계 임베디드 파워 제품에 중점을 둔 국제적인 기술 회사이다. Efore는 제품 개발에 있어 에너지 효율을 향상시켜 에너지 소비를 최소화함으로써 환경 친화에 기여하는 데 중점을 두고 있다. 

 

이 논문의 목적은 Efore 제품 개발 부서의 요구에 맞는 초기-단계 임베디드 소프트웨어 테스트 방법을 개발하는 것이다. 다양한 유형의 8비트 및 16비트 마이크로컨트롤러와 I/O 구성을 테스트하기 위한 솔루션을 만들고, 테스트 환경의 하드웨어 구현을 설계하고, 최종적으로 실제 제품을 사용하여 시스템을 실제로 테스트하는 것이다. 테스트 플랫폼 설계의 목표는 이것이 낮은 수준의 단위 테스트에서 완전한 코드 테스트까지 바로 사용되도록 하는 것이다. 즉, 에뮬레이트된 하드웨어 환경에서 첫 번째 프로토타입이 등장하기 훨씬 전에 하드웨어 환경에서 소프트웨어 테스트를 시작할 수 있도록 하는 것이다. 이렇게 하면 생명주기의 초기 단계에서 결함 발견 및 수정에 중점을 두게 되어 품질 관리와 결함 수정 리드 타임을 개선할 수 있다.

 

임베디드 시스템

• 하나 또는 여러 개의 특정 작업(tasks)을 전담하는 컴퓨터 시스템으로 최소한의 유연성만을 제공
• 임베디드 시스템은 종종 실시간 컴퓨팅을 다룬다(즉, 시스템이 반드시 실시간 자극에 반응해야 함).
• 임베디드 시스템은 단순 인터페이스 애플리케이션부터 대규모 통제/모니터링 시스템까지 다양하게 존재. 아래 그림은 임베디드 시스템과 타 컴퓨팅 시스템과의 관계를 표현

 

[임베디드 시스템과 타 컴퓨팅 시스템]

 

임베디드 시스템 아키텍쳐

• 처리 장치(processing unit)는 대개 마이크로컨트롤러(microcontroller) 또는 디지탈 신호 처리기(digital signal processor: DSP)이며, 규모가 큰 시스템은 다수의 처리 장치를 포함할 수 있다.
• 시스템은 센서를 통해 신호를 수신하고 환경을 조작하는 액터(actors)로 출력을 보냄으로써 실 세계와 실시간으로 상호작용한다. 센서와 액터를 포함한 환경은 종종 플랜트(plant)로 불린다.
• 임베디드 시스템은 애플리케이션에 고유한 빌트인 주변 장치(예, A/D 변환기, D/A 변환기, 인스트루멘테이션 증폭기, 플래시 메모리 회로)를 포함한다.
• 임베디드 시스템의 소프트웨어는 비휘발성 메모리(예, ROM 또는 Flash)에 저장되며, 또는 시스템 시작 시 네트워크나 위성을 통해 다운로드 될 수도 있다.

[임베디드 시스템의 일반적인 설계]

 

임베디드 소프트웨어의 특징

• 전통적 컴퓨터 시스템은 다양한 애플리케이션을 실행할 수 있고 하드웨어 추가(add-ons)에 대한 확장이 가능하도록 최대한 유연하게 설계되지만 임베디드 시스템은 특정 프레임워크를 동작시키는데 전념하는 간결한(compact) 컴퓨터 시스템이다.
• 임베디드 시스템의 리소스(예, 메모리 파워, 프로세싱 파워)는 종종 매우 제한적이며, 이는 소프트웨어 코드가 작성되는 방식에도 영향을 미친다.
• 임베디드 소프트웨어가 작성되는 특수한 하드웨어 환경으로 인해 임베디드 소프트웨어는 프로세서 레지스터의 직접적인 조작에 의존한다.
• 임베디드 시스템에서 표준 기능 라이브러리가 존재하지 않고 모든 것을 처음부터 작성해야만 하는 상황이 통상적이다.
• 하드웨어 자원이 빈약한 임베디드 시스템에서 최적화가 낮은 코드는 시스템 성능에 악영향을 줄 수 있으므로 코드가 최대한 간결하고 효율적 이여야 한다. 최적화 및 효율성이 강조되는 또 다른 이유는 시스템이 종종 실시간 자극에 즉각적으로 반응해야 하기 때문이다. 따라서 최대한 효율적인 프로세싱 파워 사용을 보장하기 위해 일부 시간에 민감한 코드 부분이(또는 코드 전체가) 어셈블리어로 쓰여진다.
• 임베디드 시스템은 종종 장시간 동안 중단 없이 실행될 필요가 있으므로 신뢰성(reliability)도 중요한 이슈이다. 다행인 점은 임베디드 소프트웨어가 특정 프로세서(또는 특정 하드웨어)를 위해 컴파일 되므로 코드 최적화(code optimization)가 더 쉽고 하드웨어와 소프트웨어 간의 충돌을 피할 수 있어서 신뢰성도 증가된다.

 

임베디드 소프트웨어 테스팅

• 소프트웨어 테스팅의 기본 규칙이 임베디드 소프트웨어에도 마찬가지로 적용되지만 임베디드 소프트웨어를 테스팅 시 고려해야 할 특별한 요구사항과 추가적인 요인들이 존재한다.
• 전통적으로 네 개 테스팅 단계(단위, 통합, 시스템, 승인)가 존재하는데 임베디드 시스템에서는 두 번째 단계인 통합 테스팅이 다시 ‘소프트웨어 통합 테스팅’과 ‘소프트웨어/하드웨어 통합 테스팅’으로 나뉜다. ‘소프트웨어/하드웨어 통합 테스팅’에서는 소프트웨어 컴포넌트와 하드웨어 도메인(예, 빌트인 주변 기기, 플랜트) 간의 인터페이스 및 상호작용이 테스트된다.
• 임베디드 소프트웨어가 실행되는 실제 환경이 대개 소프트웨어와 병행하여 개발되므로 프로젝트의 나중 단계까지는 하드웨어 환경 결핍으로 인해 포괄적인 테스팅이 수행될 수 없는 문제가 있음. 이 문제는 하드웨어 테스팅 플랫폼을 개발하여 실제 환경이 가용하기 전에 시뮬레이션 환경에서 테스트가 수행될 수 있도록 함으로써 해결된다. 

 

TEmb: 임베디드 소프트웨어 테스팅 방법론

Broekman과 Notenboom가 제안한 TEmb는 특정 임베디드 시스템에 적합한 테스팅 접근 방법을 계획하는데 도움이 된다. TEmb에서 테스트 접근 방법은 어떤 프로젝트에서든 공통 적용되는 일반 요소(generic elements)와 애플리케이션에 특화된 조치들(application specific measures)로 나뉜다.

 

1. TEmb 일반 부분(Generic parts)

• TEmb 일반 부분은 LITO라고 불리는 4개의 초석(cornerstones)으로 구성됨: 생명주기(Lifecycle), 하부구조(Infrastructure), 기법(Techniques), 조직(Organization)
• ‘생명주기’는 시간에 따른 실제 계획(무엇이 언제 수행될지)을 포함하며, 아래 그림처럼 계획통제(planning & control), 준비(preparation), 명세(specification), 실행(execution), 완성(completion)의 5단계로 나뉠 수 있다. 생명주기 프로세스의 주 기능은 테스팅 프로세스의 작업흐름(workflow)을 촉진하고 조직화하는 것이다.
• ‘하부구조’는 테스팅을 수행하는데 필요한 모든 설비(테스트 환경, 도구, 자동화 환경, 사무실 환경 등)들로 구성된다. 테스트 환경은 테스팅이 일어나는 실제 환경으로 예를 들면 프로토타입, 하드웨어 에뮬레이션 환경, 컴퓨터 시뮬레이션, 생산 장치 등이 존재한다. 테스트 환경은 테스트 결과, 테스트 케이스, 시뮬레이션 런 등을 기록하기 위한 테스트 데이터베이스도 포함한다(반복성을 위해 요구됨).
• ‘기법’은 테스팅 자체에서 사용되는 기법 뿐만 아니라 프로세스 통제/추적과 결과 평가에 사용되는 기법들 또한 정의한 지원 프로세스이다. 즉, 전략 개발, 테스트 설계, 안전성 분석, 테스트 자동화 등에서 사용하기 위해 선택된 신, 구 기법들의 집합
• ‘조직’은 테스팅을 수행하는 사람 그룹을 나타내며, 조직 구조, 역할, 교육훈련 절차, 관리통제 절차를 포함한다.

[라이프사이클 모델]

 

2. TEmb 애플리케이션에 특정한 부분

• 위에 언급된 일반 테스트 방법(TEmb generic의 LITO)은 구체적이지 않으므로 상세 사항(예, 어떤 설계 기법을 적용할지, 어떤 도구를 사용할지)을 추가 보완해야 하며, 이를 위해서는 테스트 대상 시스템(System Under Test: SUT)의 고유한 특징을 정의해야 한다.
• 애플리케이션에 고유한 특징은 SUT를 위한 특별한 테스트 케이스를 계획하거나 위험 분석(risk analysis)을 수행하는데 좋은 도구가 된다.
• 선정된 애플리케이션 특유의 조치들은 TEmb generic 방법과 유사하게 생명주기(Lifecycle), 하부구조(Infrastructure), 기법(Techniques), 조직(Organization)으로 분리될 수 있다.

 

SUT를 분류하는 도구 중 하나로 아래처럼 특징(features)을 구분한 체크리스트를 사용할 수 있다. SUT가 아래 특징 중 하나 또는 여러 개에 해당 될 수 있으며, 이렇게 식별된 특징이 테스트 계획 프로세스를 안내하는(guide) 역할을 한다.

• 고안전(safety critical) 시스템: 실패(failure)가 심각한 물리적 피해나 인명 피해를 야기할 수 있는 시스템. 이런 시스템에서는 위험 분석(risk analysis)이 대단히 중요하며 신뢰성을 분석하고 보장하기 위한 엄격한 기법이 요구된다.
• 기술과학 알고리즘(technical-scientific algorithms): 복잡한 과학적 알고리즘을 수행해야만 하는 애플리케이션으로 많은 양의 프로세싱과 데이터 트래픽을 요구함(예, 자동차, 미사일, 로봇 등을 통제하는 통제 애플리케이션). 이런 시스템 동작의 가장 복잡한 부분은 시스템 외부에서는 실질적으로 보이지 않으므로 테스팅이 개발 초기 화이트박스 레벨에 집중되며 블랙박스 기반 시스템 테스팅과 승인 테스팅은 적게 요구됨
• 자치적인 시스템(Autonomous systems): 시작 후 사람의 간섭이나 상호작용 없이 운영되도록 설계된 시스템(예, 교통 신호 시스템, 무기 시스템). 무기한의 시간 주기 동안 간섭 없이 독립적이고 지속적으로 동작하는 이런 종류의 시스템에서는 수작업 테스팅이 어렵거나 불가능. 따라서 테스트 케이스를 실행하고 그 결과를 분석하기 위해 특수한 테스트 환경과 특수한 테스트 도구가 요구된다.
• 유일한 일회 시스템(Unique one-shot systems): 한번만 릴리즈되며 유지보수가 될 수 없는 시스템. 단 한번에 정확하게 구축되도록 설계된 주문맞춤 시스템(bespoke systems). 예, 위성(satellites). 단 한번만 릴리즈되므로 장기간의 테스팅 목표(long-term goals)가 불필요하며, 유지보수나 재사용의 측면과 관련하여 테스팅 방법의 재고가 필요하다.
• 혼합 신호 시스템(Mixed signal systems): 이진 신호(binary signals)에 더불어 아날로그 신호를 포함하는 시스템. 입력과 출력이 정확한 값을 가지지는 않지만 수락되는 테스트 출력에 대한 유연한 경계를 정의한 허용치(tolerances)를 가짐. 경계(boundaries)는 테스트 출력이 승인되는지 거부되는지에 대한 테스터의 결정이 요구되는 중간 영역(grey area)을 포함하기도 한다. 이런 종류의 시스템은 종종 수작업으로 테스트 됨
• 하드웨어 제약(hardware restrictions): 하드웨어 자원의 제약이 소프트웨어에 특정한 제약(예, 메모리 사용, 파워 소비)을 주며, 또한 대부분의 하드웨어 타이밍 이슈가 소프트웨어에서 해결되게 된다. 이런 이슈들은 특화되고 기술적인 테스팅 방법을 요구함
• 상태 기반(State-based): 상태 기반 동작은 특정 이벤트에 의해 유발된 트랜지션(한 상태에서 다른 상태로의 전이)을 통해 기술됨. 응답(response)은 입력 뿐만 아니라 이전 이벤트와 상태의 이력(history)에도 의존한다. 상태 기반 시스템에서는 동일한 입력이 항상 수락되는 것은 아니며, 수락된다 해도 완전히 다른 출력을 생성할 수도 있다. 이런 타입의 시스템을 테스팅 하려면 신중한 테스트 케이스 계획과 테스트 자동화가 요구된다.
• 하드 리얼타임 시스템(hard real-time system): 자극(stimulus)이 발생하는 정확한 순간이 시스템 동작에 영향을 미친다. 이런 타입의 시스템을 테스팅 할 때 테스트 케이스는 입력과 출력의 타이밍에 대한 상세한 정보를 반드시 포함해야 한다. 또한 테스트 케이스가 종종 연속순서(sequence)에 의존적이므로 일정 수준의 자동화를 요구한다.
• 통제 및 극한 환경(control and extreme environments): 통제 시스템은 지속적인 피드백 시스템(continuous feedback system)에 따라 환경과 상호작용 한다. 시스템의 출력이 환경에 영향을 미치고, 이 영향은 다시 통제에 영향을 주는 시스템으로 반환된다. 따라서 시스템의 동작이 독립적으로 기술될 수 없으며, 환경에서의 이벤트와 밀접하게 연결된다. 이런 종류의 시스템은 환경 동작의 정확한 시뮬레이션을 요구하며, 시스템이 극한 환경(예, 고열, 혹한, 기계적 스트레스, 화학물질, 방사능)에 노출되는 상황도 테스팅에서 고려해야 한다.

 

 

Efore Group의 임베디드 소프트웨어 테스팅

• Efore의 현 소프트웨어 개발 프로세스는 폭포수(waterfall) 모델 기반이며, 소프트웨어를 첫 프로토타입에서부터 최종 릴리즈 버전으로 정제하기 위한 반복적인 루프를 포함한다.
• 실질적인 소프트웨어 테스팅 방법으로는 프로세스 단계 간의 정적 검토(static reviews)와 소프트웨어 검증(SW Verification) 단계에서의 최종 검증 테스팅(final verification testing)이 존재함
• 현 프로세스는 엄격하게 정의된 저레벨(low level) 테스팅이 결여되어 있고 소프트웨어 테스팅 정책도 개선이 필요함. 저레벨 소프트웨어 테스팅 계획이 없고 테스팅이 단순히 코딩 프로세스의 보이지 않는 부분으로 간주됨에 따라 소홀해지기 쉽고 문서화도 안됨
• 본 논문은 Efore Group의 소프트웨어 개발 프로세스에 엄격한 소프트웨어 테스팅 구현이 가능하도록 TMMi(Test Maturity Model integration), 나선형 프로세스 모델(spiral process model), 테스트 주도 개발(Test Driven Development: TDD)의 3개 세그먼트로 구성된 방법을 제안함 

 

[Efore의 현행 소프트웨어 개발 프로세스]

 

 

[제안된 소프트웨어 개발 프로세스]

 

 

테스팅 플랫폼

임베디드 시스템과 주변 기능을 광범위하게 테스트하려면 타겟 환경을 시뮬레이션해야 한다. 시뮬레이션은 소프트웨어적으로 또는 하드웨어적으로 수행할 수 있다.

 

이 프로젝트에서는 다양한 마이크로컨트롤러와 혼합 신호의 필요성 때문에 하드웨어 시뮬레이션을 선택했다. 하드웨어 테스트 플랫폼을 사용하면 실제 타겟 환경을 시뮬레이션하고 타겟 프로세서에서 단위 및 통합 테스트를 수행할 수 있다. 이를 통해 첫 번째 하드웨어 프로토타입이 준비되기 전에 소프트웨어를 엄격하게 테스트할 수 있으며, 심지어 소프트웨어/하드웨어 통합 테스트도 수행할 수 있다.

 

플랜트를 시뮬레이션하려면 플랫폼이 최대 +5V의 아날로그 전압을 생성하고, 아날로그 신호를 수신하고, 최대 50개의 디지털 입력/출력을 처리하고, PWM 신호를 생성하고, SPI, I2C 및 UART 프로토콜을 통해 통신할 수 있어야 한다.

 

플랫폼의 기능은 별도의 마이크로프로세서에 의해 제어되는 데, USB를 통해 호스트 컴퓨터에서 스크립트로 작성된다. 플랫폼은 테스트 신호를 생성하고 그 결과 아날로그 및 디지털 신호를 수신할 수 있다. 또한 플랫폼은 UART(Universal Asynchronous Receiver Transmitter), I2C 또는 SPI(Serial Peripheral Interface) 버스를 통해 프로세서 보드와 통신할 수 있다. 테스트 프로세스 및 신호 생성을 완전히 자동화하기 위해 출력을 스크립트화 할 수 있다. 이런 방식으로 테스트가 항상 동일하게 반복 가능하며 그 결과가 자동으로 수집될 수 있다. 

 

[소프트웨어 테스팅 플랫폼 블록 다이어그램]

 

 

[테스트 스크립트 예]