문서요약 - 임베디드 소프트웨어 제품의 테스팅 by Auriga

제목: 임베디드 소프트웨어 제품의 테스팅(Testing of Embedded Software Products)

저자: Auriga(소프트웨어 개발 업체), 미국

문서유형: 산업계 페이퍼(총 8 페이지)

 

역외(offshore) 개발/테스팅 팀 관점에서 본 임베디드 소프트웨어 테스팅의 특징을 기술한 자료

---

다른 소프트웨어 타입과 임베디드 소프트웨어의 차이

• 최종 사용자에게 보여지는 부분이 크게 감소(콘솔 기반 텍스트 메뉴, 단순 커맨드라인 인터페이스, 디지털 입/출력 값 등이 존재할 수 있지만 대개 그 이상의 사용자 인터페이스는 제공되지 않음). 반면에 컴포넌트 간 인터페이스는 매우 풍부하고 복잡할 수 있음(상위 레벨 소프트웨어나 다양한 통신/데이터교환/컨트롤/표준 구현과의 API가 포함됨). 따라서 임베디드 소프트웨어 테스팅의 중점은 사용자 인터페이스 보다는 최종 사용자에게는 보이지 않는 컴포넌트를 테스트하는데 있음
• 임베디드 소프트웨어는 하드웨어에 가장 가까운 소프트웨어 레벨이며, 다른 소프트웨어 타입(예, 운영 체제, 애플리케이션)은 BIOS 또는 부트로더 같은 임베디드 소프트웨어가 제공하는 인터페이스 상에서 구축될 수 있다. 따라서 임베디드 소프트웨어는 하드웨어에 특정한 사항(hardware specifics)에 더 의존적일 수 밖에 없다.
• 임베디드 소프트웨어는 특정 하드웨어 장치를 위해 설계되는데, 종종 이 하드웨어 장치가 임베디드 소프트웨어와 병행하여 개발된다(즉, 생성되는 소프트웨어가 생성되는 하드웨어 장치에서 실행되는 첫 소프트웨어가 됨). 운영 체제나 다양한 소프트웨어를 실행하는 하드웨어 자체의 능력이 이미 잘 검증된 애플리케이션 개발 환경과는 다르며, 개발된 소프트웨어가 특정 하드웨어 버전(hardware revisions)에 고유한 솔루션이나 해결법(workarounds)을 가지게 될 수도 있다.
• 임베디드 소프트웨어의 오퍼레이션은 애플리케이션 레벨 소프트웨어에서는 대개 신경 쓰지 않는 사항에도 의존적일 수 있다(예, 케이블 길이, 마우스 타입, 시리얼 포트 주파수, 동일한 버스에 연결된 디바이스 타입 등). 즉, 임베디드 소프트웨어의 성공적인 실행이 특정 하드웨어 장치(또는 동일한 버스나 네트워크에 있는 다른 장치의 동작)에 크게 의존한다.
• 경쟁 상황(race conditions)이 전통적인 경우처럼 내부 소프트웨어 컴포넌트의 상호작용에 의해서 생기는 대신에 주로 소프트웨어와 주변 환경과의 상호작용에 의해 초래된다. 즉, 오퍼레이션에 영향을 줄 수 있는 요인(factors)과 패러미터의 수가 일반 애플리케이션의 경우 보다 크며, 따라서 결함 재생(reproduction)도 더 어렵다.
• 지원 오퍼레이션(예, 소프트웨어 전개, 업그레이드, 디버그 정보 수집)도 전통적인 애플리케이션 레벨 소프트웨어의 그것과는 달라진다.
  - 임베디드 소프트웨어의 업데이트 프로세스를 길고 불편하게 만드는 여러 요인이 존재. 예) 소프트웨어를 특수한 모드로 만들어야 함, EEPROM 쓰기 보호(write-protection)를 비활성화 시켜야 함, 파일 배포 서버에 부착이 요구됨, 여러 번의 리부트가 필요함, 소프트웨어를 저장하는 디바이스가 제한된 횟수의 re-write 사이클을 지원함 등
  - 이런 특성은 심지어 개발 단계에서도 다른 형태의 소프트웨어에 비하여 임베디드 소프트웨어의 버전 업데이트가 적게 시행되는 경향으로 이어짐
  - 전통적인 애플리케이션 레벨 소프트웨어에 비해 디버깅 및 결함 정보 수집을 어렵게 만드는 요인도 존재 예) 비휘발성(non-volatile) 저장 장치가 아예 없거나 제한적임, 동일 시스템상에서 디버거를 실행할 수 없음, 기저 운영 체제가 없거나 제한된 버전(reduced version)만 가용함에 따라 원격 디버깅 방법이 부재하게 됨
  - 임베디드 소프트웨어를 위한 디버깅이 더 어렵기 때문에 개발팀은 종종 특수한 디버그 빌드 또는 타겟 소프트웨어의 특별 디버그 모드(향상된 로깅 기능을 가짐)를 사용함
• 상위 레벨 애플리케이션 소프트웨어의 기반(base)이 되는 임베디드 소프트웨어는 더 높은 수준의 견고성(robustness)을 요구한다.

임베디드 소프트웨어 테스팅의 어려운 점(challenges)

• 사람이 대상이 아닌 인터페이스(non-human interfaces)에 중점이 있으므로 수작업 인터페이스 테스팅 방법(manual interface testing approach)을 사용할 수 없음
• 개발된 임베디드 소프트웨어를 테스트하기 위한 추가 소프트웨어를 개발할 필요가 있음. 즉, 자극(stimulus)을 주고 non-human 인터페이스를 통한 반응(response)을 캡쳐하는 특수한 애플리케이션과 테스트 에이전트(test agents)가 생성될 필요가 있다. 자극(입력)에 대한 임베디드 소프트웨어 동작을 테스트 하기 위해서 다양한 데이터 라인(data lines) 상에서 특정 전자 신호 패턴(electrical signal patterns)을 에뮬레이션 할 필요가 있을 수 있으며, 이는 특수한 하드웨어/소프트웨어 복합체(complex)을 사용하여 달성된다. 이 복합체를 통제하기 위한 특별한 테스트 에이전트도 필요할 수 있음
• 임베디드 소프트웨어의 하드웨어에 대한 의존성이 높고 임베디드 소프트웨어와 그 하드웨어가 종종 병행하여 개발되다 보니 새롭게 개발된 하드웨어의 샘플이 몇 개 안되어 접근에 제약이 있을 수 있다(즉, 테스팅 팀 멤버들이 제한된 수의 하드웨어 장치를 공유하거나 또는 물리적 접근이 불가능한 특정 하드웨어로의 원격 접근을 계획해야만 함).
• 임베디드 소프트웨어와 병행하여 생성된 신규 하드웨어가 테스팅 프로세스 동안에 높은 하드웨어 결함율을 보일 수 있다(즉, 임베디드 소프트웨어 테스팅 동안에 발견된 결함이 소프트웨어 뿐만 아니라 하드웨어와 관련될 수 있다).
• 테스트 대상 소프트웨어가 적용되는 하드웨어 장치 타입의 범위가 상당히 넓을 수 있으며, 임베디드 소프트웨어가 하드웨어의 한 버전과는 잘 동작하지만 다른 버전과는 그렇지 못할 수도 있다.
• 임베디드의 경우 결함 재현이 더 어려우므로 테스팅 프로세스에서 결함 원인을 찾기 위한 정보를 최대한 많이 수집할 필요가 있지만 임베디드 제품의 디버깅 기능에 제약이 많은 현실이 이를 어렵게 만든다.
• 견고성(robustness) 및 가용성(availability)에 대한 높은 요구사항이 매우 철저한 스트레스 테스팅의 필요성으로 이어진다. 스트레스 하에서의 경쟁 상황(race conditions)을 체크하기 위해 빠르게 이어지는 이벤트 시퀀스를 에뮬레이션 할 필요가 있음
• 테스트를 위해 개발된 지원 소프트웨어(예, 테스트 에이전트, 자동화 프레임워크)는 그 자체가 반드시 검증되어야 한다. 즉, 타겟 임베디드 소프트웨어 제품의 테스팅과 마찬가지로 테스트 지원 인프라구조에 대한 테스트 설계, 실행, 커버리지 분석 등의 테스트 활동이 수행되어야 함. 또한 결함 관리에서도 이를 반영하여 각 결함에 대한 가능한 원천지(source)로 ‘타겟 소프트웨어’, ‘기저 하드웨어’, ‘테스트 지원 인프라구조’가 모두 고려되어야 한다.