임베디드 개발을위한 유닛 테스트시 모범 사례

임베디드 시스템 용으로 작성된 단위 테스트 코드에 대한 모범 사례 전략을 찾고 있습니다. 임베디드 시스템이란 디바이스 드라이버, ISR 핸들러 등과 같은 코드, 금속에 매우 가까운 것들을 의미합니다.

대부분의 단위 테스트는 ICE의 도움으로 하드웨어에서 테스트하지 않으면 불가능합니다. 때로는 내장 된 장치를 기계식 스위치, 스테퍼 모터 및 전구와 같은 다른 자극에 연결해야합니다. 이것은 일반적으로 수동 방식으로 발생하며 자동화는 훌륭하지만 달성하기가 어렵고 비용이 많이 듭니다.

최신 정보

임베디드 프로젝트를 테스트하는 데 성공한 것으로 보이는 C 테스트 프레임 워크를 발견했습니다. 하드웨어 조롱이라는 아이디어를 사용합니다. 확인 유니티 , CMock 가능하고, Ceedling을 .

2016 년 7 월 업데이트

cmocka를 건너 왔다 -더 적극적으로 작업하는 것 같습니다.

가능한 빠른 단계에서 하드웨어 의존성을 피하고 소프트웨어 에뮬레이션 / 테스트 하네스에 시스템을 구축하여 모든 종류의 테스트 프레임 워크를 가능하게합니다. 종종 내 개발 PC를 사용하여 전체 시스템의 95 % 이상을 테스트했습니다. 여분의 오버 헤드 (다른 추상화 계층)의 비용은 해당 추상화의 결과로 생성 된 더 깨끗한 코드에 의해 쉽게 회복되었습니다.

임베디드 시스템의 진정한 베어 메탈 부분에 대한 테스트는 일반적으로 애플리케이션이 달성 할 수있는 것 이상으로 펌웨어를 망치는 별도의 애플리케이션 (단위 테스트?)입니다. 자동화는 비용으로 수행 할 수 있지만 일반적이지 않습니다.

그렇지 않으면 전체 ICE를 포함한 단위 테스트 하드웨어 하네스를 구축 할 예산이 있습니다. 일반적으로 기능 테스트가 작기 때문에 이것은 절대적으로 좋습니다.

개발에 필요한 도구는 신호 인젝터입니다. 임베디드 시스템에는 호스트 시스템과 인터페이스하는 방법이 있습니다 (일반적으로 디버깅 용으로 예약 된 직렬 포트를 통해). 이것을 사용하여 테스트 데이터를 전송하십시오 (최상의 옵션은 간결한 ASCII 형식이므로 사람도 쉽게 시뮬레이션 할 수 있습니다).

"자동화는 훌륭하지만 달성하기가 어렵고 비용이 많이 듭니다."라는 귀하의 질문에이 부분에 완전히 동의하지 않습니다.

직렬 포트 신호 인젝터로 TeraTerm을 사용하고 일부 TeraTerm 매크로 (약 20 분 소요)를 작성하는 경우 드라이버 계층, O / S, 계층 4-5 등 TeraTerm : http://en.sourceforge.jp/projects/ttssh2/

내장형 시스템에서 직렬 포트를 사용할 수없는 경우 하드웨어 도구를 사용하여 USB / 직렬 포트 데이터를 디지털 신호로 변환하십시오 (또한 저렴하고 달성하기 쉽습니다 ). 이 기사를 읽으면서 USB / 직렬을 통해 전송되는 TeraTerm 매크로를 통해 자극을 주입하여 생산을위한 임베디드 시스템을 테스트하기 위해 $ 30 마이크로 컨트롤러 보드 (UBW : http://www.schmalzhaus.com/UBW32/ )를 사용하고 있습니다. 수정 된 펌웨어를 실행하는 마이크로 컨트롤러는 대상 임베디드 시스템의 디지털 입력을 모니터링하고 디지털 출력을 모니터링합니다. 이와 함께, 우리는 파이썬 스크립트 (pyserial 및 pexpect 사용)를 개발하여 데이터 주입 및 데이터 유효성 검사를 자동화했습니다. 그것은 어렵지 않으며 비싸지 않습니다.. 내 경험상, 관리자는 테스트 팀이 경험이없고 이러한 쉬운 솔루션을 생각할 수 없을 때 큰 테스트 비용 (예 : 30,000 달러의 테스트 장비)을 소비합니다. 불행히도 범용 아이언 장비에는 종종 테스트 사례가 포함되지 않습니다 대상 시스템의 최악의 타이밍 등을 포착합니다. 따라서 테스트 적용 범위에는 저렴한 방법이 바람직합니다. 믿거 나 말거나.

이것은 매우 어려운 문제입니다.

실제로 임베디드 시스템에 대한 단위 테스트 하네스를 설계하여 하드웨어 이벤트 / 인터럽트를 시뮬레이션하고 실행 시간을 제어 할 수있었습니다 (동시성으로 인해 가능한 모든 인터리빙을 보장하기 위해). 실제로 구현하고 작동시키는 데 2 ​​년이 넘는 프로그래머. 이 프로젝트는 독자적인 개발이지만 비슷한 (더 단순한 디자인) 프로젝트를 여기서 이용할 수 있습니다 .

그렇습니다. 자동화는 훌륭 할 것입니다. 예, 달성하기가 매우 어렵고 비쌉니다. 예, 때로는 그렇게해야합니다. 드물기는하지만 대부분의 경우 스테퍼 모터와 전구를 사용하여 수동으로 작동하는 것이 더 빠르고 저렴합니다.

편집 : 내 대답은 mattnz에 가깝습니다.

이 문제를 다른 사람과 관련시키고 싶습니다. 시스템 시계, 영구 파일 시스템 또는 데이터베이스와 같은 외부 코드에 의존하는 모든 테스트는 외부 웹 서비스에 연결합니다 ... 나는 두 가지 수준 의 코드로 두 수준 을 분리하여 모든 정책에 대해 동일한 정책을 제안합니다 .

단일 외부 작업 테스트

각 작업을 물리적으로 테스트 할 수 있습니다. 시스템 시계가 정확한 시간을 제공하는지, 파일이 실제로 작성된 내용을 기억하는지 확인하고, 장치가 단일 작업을 수신하는지 확인하십시오.

이 테스트는 :

• 가능한 한 간단해야합니다. 알고리즘 없음, 조건 또는 루프 없음
• 주문 및 기계에 따라 다를 수 있습니다. 따라서 엄격한 순서를 따라 각 하드웨어에서 반복해야합니다.
• 프로젝트 과정에서 대부분 안정적이므로 자주 실행하지 않아도됩니다.
• 따라서 수동으로 실행하는 것이 옵션입니다. 지나치게 복잡하지 않으면 자동화가 훨씬 더 좋습니다.
• 참고 어떤 테스트중인 것은 당신의 코드가 아닙니다은 ,이 테스트를하는 것은 당신을 위해 선택 될 수 있도록 코드의 요구는 ..., 그것은 다른 팀에 의해 수행되었을 수있는 도구입니다 ...

외부 작업을 연결하는 논리 (코드, 알고리즘) 테스트

실제 외부 작업을 수행하는 코드 계층을 보유하고 쉽게 조롱 할 수있는 인터페이스를 숨겨서 논리는 더 이상 실제 물리적 장치에 의존하지 않습니다 ...

일반 프로젝트처럼 더 이상 테스트하기 어려운 코드가없는 경우 간단하게 테스트 할 수 있습니다 .

임베디드 CPU 시뮬레이터는 일반적으로 하드웨어를 시뮬레이션하도록 프로그래밍 할 수 있습니다. Xen 이외의 모든 가상화 기술이이를 수행합니다. 그러나 실제 주소 나 I / O 버스의 주소 인 x86에 레지스터가있는 척하는 코드를 작성해야합니다. 그러면 소프트웨어가 실제 주소 인 것처럼 이러한 주소에 대한 읽기 및 쓰기에 응답해야합니다. 제어 및 상태 레지스터에 액세스 한 칩

이 작업을 수행하려면 QEMU를 수정하는 것이 좋습니다. 그러나 쉽지 않습니다. 이러한 종류의 작업은 일반적으로 마이크로 컨트롤러 및 I / O를위한 다른 코어가있는 사용자 지정 칩을 설계 할 때만 수행됩니다.

ARM Holdings에서 판매하는 개발 시스템은이를 제공하며 QEMU를 해킹하는 것보다 작업하기가 쉽지만 매우 비쌉니다.

단일 서브 루틴을 실행하는 여러 개의 오픈 소스 ARM 에뮬레이터가 있으며,이 서브 루틴 자체는 다른 서브 루틴을 호출 할 수 있으며 하드웨어 액세스에 의존하지 않는 서브 루틴의 성능을 튜닝하는 데 사용할 수 있습니다. 이 중 하나를 사용하여 ARM7TDMI 용 AES 암호화기를 최적화했습니다.

C 또는 C ++로 간단한 단위 테스트 하니스를 작성하고 테스트중인 클래스 또는 서브 루틴을 링크 한 후 시뮬레이터에서 실행할 수 있습니다.

Linux 또는 Mac OS X 커널 코드를 단위로 테스트하는 방법에 대해 수년간 비슷한 문제를 고민해 왔습니다. 가능해야하지만 실제로 시도한 적이 없습니다. 유닛 테스트 프레임 워크를 커널에 직접 연결하여 코드를 개별적으로 테스트하는 대신 전체 커널을 빌드하는 것이 가능합니다. 그런 다음 일종의 외부 인터페이스에서 장치 테스트를 시작합니다.

코드 커버리지 도구를 사용하는 것이 더 생산적 일 수 있으며 외부 인터페이스를 통해 펌웨어를 완전한 패키지로 테스트 할 수 있습니다. 적용 범위 도구는 아직 테스트되지 않은 코드 경로를 찾으므로 더 많은 적용 범위를 얻기 위해 추가 외부 테스트를 추가 할 수 있습니다.

내장되지 않은 TDD와 마찬가지로 모의 객체 는 확실히 친구입니다.

기본 하드웨어에 대한 인터페이스를 깨끗하고 단순하게 유지하여 가장 낮은 수준 이상의 모든 항목을 조롱하고 훨씬 더 쉽게 시간을 보낼 수 있습니다. 테스트 가능성을 염두에두고 임베디드 응용 프로그램을 설계하면 테스트가 항상 훨씬 순조롭게 진행됩니다. .

또한 프로젝트가 늦게까지 온라인 테스트를 할 수 없다고해서 온라인 테스트를 준비하지 않아야한다는 의미는 아닙니다.

이것들은 (처음에는) 오프라인으로 테스트 할 수없는 비트 만 테스트해야합니다. 물론, 테스트를 미리 작성하고 있기 때문에 TDD가 아니지만 오프라인 TDD 개발은 하드웨어 인터페이스의 모양과 수행해야 할 온라인 테스트에 대한 좋은 아이디어를 제공해야합니다.

또한 온라인 개발 비용이 오프라인 개발보다 훨씬 비싸면 (내가 일하는 곳과 마찬가지로) 온라인에서 잘 이해되는 일련의 테스트를 통해 많은 시간을 절약 할 수 있습니다.

임베디드 개발에서는 종종 전체 애플리케이션 (하드웨어 포함)이 작동하는지 확인하기 위해 경계 스캔 을 수행 합니다. 시스템 디버깅에서 JTAG 를 참조하십시오 .

하드웨어와 연결되지 않은 순수한 소프트웨어 루틴 테스트는 Check 와 같은 표준 C 단위 테스트 프레임 워크를 통해 수행 할 수 있습니다 . 그러나 메모리 제한 (특히 작은 장치의 스택 공간 등)에주의하십시오. 계약을 아십시오! 더 큰 테스트 범위를 얻기 위해 하드웨어에서 소프트웨어 루틴을 추상화하려고 시도 할 수 있지만 일반적으로 소형 PIC 또는 AVR과 같은 임베디드 장치의 성능 측면에서 비용이 많이 듭니다. 그러나 하드웨어 포트를 조롱하여 더 큰 범위를 달성 할 수 있습니다 (물론 해당 모의도 테스트 할 수 있음).

칩 또는 회로 시뮬레이션기에 에뮬레이터를 사용할 수도 있지만 이러한 도구는 비싸고 (특히 조합하여) 복잡합니다.