임베디드 하드웨어를 사용한 테스트 자동화

Question

임베디드 하드웨어에서 직접 테스트 자동화에 성공한 사람이 있습니까?

특히, 하드웨어 레이어 모듈에 대한 단위 테스트 배터리를 자동화할 생각입니다.우리는 하드웨어 계층 코드에 대해 더 큰 확신을 가져야 합니다.많은 프로젝트에서 인터럽트 구동 타이머, ADC, 직렬 IO, 직렬 SPI 장치(플래시 메모리) 등을 사용합니다.

이것이 노력할 가치가 있는 일인가요?

우리는 일반적으로 다음을 목표로 삼습니다.

프로세서:8 또는 16비트 마이크로컨트롤러(일부 DSP 관련)
언어:C(때때로 C++).

Answer 1

확신하는.자동차 산업에서는 하드웨어와 소프트웨어가 올바르게 작동하는지 확인하기 위해 신제품마다 100,000달러 규모의 맞춤형 테스터를 사용합니다.

그러나 개발자는 USB I/O, A/D, PWM 입력/출력 등을 포함하고 워크스테이션에서 스크립팅을 사용하거나 특별히 제작된 HIL/SIL 테스트 소프트웨어를 사용하는 더 저렴한(1,000달러 미만) 테스터도 구축합니다. MxVDev와 같은 것입니다.

HIL(Hardware in the Loop) 테스트는 아마도 의미하는 바일 것입니다. 이는 단순히 장치의 I/O에 연결된 일부 USB 하드웨어 I/O와 이에 대해 테스트를 실행하는 컴퓨터의 소프트웨어를 포함합니다.

그만한 가치가 있는지 여부는 다릅니다.

신뢰성이 높은 산업(비행기, 자동차 등)에서는 고객이 매우 광범위한 하드웨어 테스트를 지정하므로 입찰을 받기 위해서는 이를 보유해야 합니다.

소비자 산업에서는 복잡하지 않은 프로젝트의 경우 일반적으로 그럴 가치가 없습니다.

하지만 몇 명 이상의 프로그래머가 참여하는 프로젝트에서는 정말 하드웨어에서 야간 회귀 테스트를 실행하는 것은 좋은 일입니다. 소프트웨어 테스트만으로 충분하다고 스스로 만족할 만큼 하드웨어를 정확하게 시뮬레이션하는 것은 어렵습니다.

그런 다음 빌드에 문제가 발생하면 테스트가 즉시 표시됩니다.

일반적으로 블랙박스와 화이트박스 테스트를 모두 수행합니다. 하드웨어의 신호와 메모리를 감시할 수 있는 진단 코드가 장치에서 실행됩니다(디버거일 수도 있고 메시지에 반응하도록 작성한 코드일 수도 있음). 예를 들어 버스).이는 내부적으로 무슨 일이 일어나고 있는지 확인할 수 있는 화이트 박스 테스트입니다(심지어 오류를 직접 발생시키지 않고는 테스트할 수 없는 중요한 메모리 오류와 같은 일부 문제가 발생할 수도 있음).

또한 진단 경로를 무시하고 I/O만 자극/읽는 '블랙박스' 테스트도 실행합니다.

훨씬 저렴한 설정을 위해 장치에 연결하고 기본 테스트를 실행할 수 있는 USB 및/또는 이더넷(예: Atmel UC3 제품군)이 포함된 100달러짜리 마이크로 컨트롤러 보드를 구입할 수 있습니다.

특히 제품 유지 관리에 유용합니다. 프로젝트가 완료되면 몇 개의 작업 보드, 테스터 및 전체 소프트웨어 세트를 CD에 저장하세요.문제를 수정하거나 디버그해야 하는 경우 모든 것을 백업하고 변경 사항으로 인해 주요 기능이 영향을 받지 않았다는 사실을 어느 정도 알고(테스트 후) 작업하기가 쉽습니다.

-아담

Answer 2

예.나는 성공했지만 해결해야 할 근본적인 문제는 아닙니다.간단히 말해서 우리 팀이 수행한 작업은 다음과 같습니다.

1. 자체 제작한 C 단위 테스트 프레임워크를 사용하여 다양한 단위 테스트를 정의했습니다.기본적으로 많은 매크로가 있으며 대부분 이름이 지정되었습니다. TEST_EQUAL, TEST_BITSET, TEST_BITVLR, 등.

2. 이렇게 컴파일된 테스트를 실행 환경으로 조정하는 부팅 코드 생성기를 작성했습니다.이는 일반적인 시작 루틴을 실행하는 작은 드라이버일 뿐이지만 제어 루프로 들어가는 대신 테스트 스위트를 실행합니다.완료되면 플래시 메모리에서 실행할 마지막 제품군을 저장한 다음 CPU를 재설정합니다.그런 다음 다음 제품군이 실행됩니다.이는 제품군이 종료될 경우 격리를 제공하기 위한 것입니다.(그러나 모듈이 제대로 작동하는지 확인하기 위해 이 기능을 비활성화할 수도 있습니다.하지만 이는 단위 테스트가 아닌 통합 테스트입니다.)

3. 개별 테스트는 직렬 포트를 사용하여 출력을 기록합니다.직렬 포트가 무료였기 때문에 우리 설계에는 괜찮았습니다.모든 IO가 소비되면 결과를 저장할 방법을 찾아야 합니다.

효과가 있었어요!그리고 그것은 정말 좋았습니다.우리의 맞춤형 데이터로거를 사용하여 "테스트" 버튼을 누르면 몇 분 후에 모든 결과를 얻을 수 있습니다.나는 그것을 강력히 추천합니다.

업데이트됨 테스트 드라이버의 작동 방식을 명확히 합니다.

Answer 3

예.

난이도는 테스트하려는 하드웨어 유형에 따라 다릅니다.앞서 다른 사람들이 말했듯이 문제는 적용해야 하는 외부 자극의 복잡성이 될 것입니다.외부 자극은 아마도 일부 외부 테스트 장비를 사용하여 가장 잘 달성될 수 있습니다(Adam Davis가 설명한 대로).

하지만 고려해야 할 한 가지는 정확히 당신이 확인하려는 것이 무엇인지.

하드웨어와 펌웨어의 상호 작용을 확인하려면 외부 자극(예:모든 ADC 입력에 DAC를 적용하는 등).하지만 이러한 경우 실제로 테스트하고 싶은 코너 케이스는 종종 타이밍 문제(예:foo()) 함수를 실행할 때 도착하는 인터럽트는 의미 있는 방식으로 테스트하기가 엄청나게 어렵고 의미 있는 결과를 얻기가 훨씬 더 어렵습니다.(즉.이 테스트를 처음 100,000번 실행했을 때는 괜찮았습니다.마지막으로 실행했을 때 실패했습니다.왜?!?)

하지만 하드웨어 검증은 별도로 이루어져야 합니다.이 작업이 완료되면 정기적으로 변경되지 않는 한(다운로드 가능한 FPGA 이미지 등을 통해) 하드웨어가 작동한다고 가정하고 펌웨어만 테스트할 수 있습니다.

따라서 이 경우 외부 자극을 처리하는 데 사용되는 알고리즘을 검증하는 데 집중할 수 있습니다.예를 들어 ADC에서 직접 가져온 것처럼 고정 값을 사용하여 ADC 변환 루틴을 호출합니다.이러한 테스트는 반복 가능하므로 이점이 있습니다.하지만 특별한 테스트 빌드가 필요합니다.

장치의 통신 경로를 테스트하는 것은 비교적 간단하며 특별한 코드 빌드가 필요하지 않습니다.

Answer 4

우리는 임베디드 시스템에 대한 자동화된 테스트를 통해 좋은 결과를 얻었습니다.우리는 전용 테스트 시스템에서 실행되는 고급(프로그래밍 및 디버깅이 쉬운) 언어로 작성된 테스트를 보유하고 있습니다.이러한 테스트는 일반적으로 온전성 검사를 수행하거나 장치에 무작위 입력을 생성한 다음 올바른 동작을 확인합니다.이러한 테스트를 생성하고 유지하려면 많은 작업이 필요합니다.우리는 프레임워크를 설계한 다음 인턴이 직접 테스트를 수행하도록 했습니다.

완벽한 솔루션은 아니며 테스트에서 확실히 오류가 발생하기 쉽지만 가장 중요한 부분은 기존 커버리지 허점을 개선하는 것입니다.완벽하지 않거나 전체 기능을 포함하지 않더라도 가장 큰 구멍을 찾아 자동화된 방식으로 이를 덮을 수 있는 무언가를 디자인합니다.나중에 모든 내용이 어느 정도 다루어지면 다시 돌아와서 최악의 내용이나 가장 중요한 기능을 해결할 수 있습니다.

고려해야 할 사항:

• 펌웨어 버그로 인한 처벌은 무엇입니까?현장에서 펌웨어를 업데이트하는 것이 얼마나 쉬운가요?
• 내 테스트는 어떤 종류의 적용 범위를 제공합니까?간단한 건강검진인가요?다양한 시나리오를 테스트할 수 있을 만큼 충분히 구성 가능합니까?
• 테스트가 실패하면 디버깅하기 위해 해당 값을 어떻게 재현할 것입니까?가능한 한 많은 변수를 제거할 수 있도록 모든 장치 및 테스트 설정을 기록했습니까?장치 구성, 펌웨어 버전, 테스트 소프트웨어 버전, 모든 외부 입력, 관찰된 모든 동작?
• 무엇을 테스트하고 있습니까?테스트 중인 장치의 예상 동작에 대한 사양이 충분히 명확합니까? 아니면 코드가 수행해야 한다고 생각하는 작업에 대해 유효성을 검사하고 있습니까?

Answer 5

목표가 하위 수준 드라이버 코드를 테스트하는 것이라면 각 드라이버를 시험할 수 있도록 루프백 케이블이나 여러 개의 상호 연결된 장치를 사용하여 일종의 테스트 장치를 만들어야 할 것입니다.알려진 좋은 소프트웨어가 있는 보드를 개발 빌드를 실행하는 보드와 페어링하면 통신 프로토콜 등의 회귀를 테스트할 수 있습니다.

구체적인 테스트 전략은 테스트하려는 하드웨어에 따라 다릅니다.예를 들어 ADC는 알려진 파형을 제시하고 일련의 샘플을 변환한 다음 적절한 범위, 주파수, 평균값 등을 확인하여 테스트할 수 있습니다.

나는 과거에 이러한 유형의 테스트가 매우 가치 있다는 것을 알았습니다. 이를 통해 기존 응용 프로그램이 손상될 염려 없이 드라이버 코드를 자신 있게 수정하고 개선할 수 있었습니다.

Answer 6

예, 테스트 I/O에 항상 직렬 포트를 사용할 수 있었지만 이렇게 했습니다.

유닛을 떠나는 것이 종종 어렵습니다. 완전히 수정되지 않은.일부 테스트에서는 주석 처리된 줄이나 추가된 호출이 필요합니다.감시견을 처리하기 위해.

IMHO, 이것은 단위 테스트를 전혀 하지 않는 것보다 낫습니다.물론 완전한 통합/시스템 테스트도 수행해야 합니다.

Answer 7

단위 테스트 임베디드 프로젝트는 일반적으로 외부 자극과 외부 측정이 필요하기 때문에 매우 어렵습니다.

우리는 잘못된 조건이나 심지어 약간 비정상적인 조건(특히 한계 확인을 위한)을 찾는 낮은 수준의 드라이버에서 디버그 로깅을 사용하여 hw를 실행하기 위한 기본 명령을 사용하여 외부 직렬 프로토콜(rs232 또는 udp 또는 tcpip 메시지)을 개발하는 데 성공했습니다.

그러나 일단 개발되면 필요한 경우 모든 빌드 후에 테스트를 실행할 수 있습니다.이를 통해 확실히 더 나은 품질의 제품을 제공할 수 있습니다.

Answer 8

나는 이것이 오래되었다는 것을 알고 있지만 아마도 도움이 될 것입니다.예, 그렇게 할 수 있지만 원하는 솔루션에 얼마나 투자하고 싶은지에 따라 다릅니다.저는 2년 넘게 AUTOSAR의 MCAL 계층에 대한 테스트 및 검증 작업을 해왔습니다.이는 소프트웨어 테스트와 관련하여 얻을 수 있는 가장 낮은 수준입니다.일종의 구성 요소 수준 테스트였습니다.어떤 사람들은 이를 단위 수준이라고 부를 수도 있지만 MCAL 구성 요소의 API를 테스트했기 때문에 그보다 약간 더 높았습니다.같은 것들:ADC, SPI, ICU, DIO 등.

사용된 솔루션은 다음과 같습니다.- 대상 마이크로에서 실행중인 테스트 프레임 워크 - 필요할 때 대상에 신호를 제공하고 읽을 수있는 DSPACE 상자 -Vector Canape를 통한 XCP 액세스 테스트 실행 및 결과 컬렉션을 트리거하여 테스트 제어를 수행하기위한 Python 프레임 워크 결과의 검증

테스트 케이스는 C로 작성되었으며 테스트 중인 소프트웨어와 함께 대상에 플래시되었습니다.MCAL 구현을 어떤 식으로든 변경하지 않았기 때문에 이는 블랙박스 테스트였습니다.그리고 시동 순서도 건드리지 않은 것 같아요.테스트 실행을 시작하라는 신호인 플래그의 상태를 지속적으로 확인하기 위해 Idle 작업을 사용했습니다.실제로 테스트를 실행하는 데 10ms 작업이 사용되었습니다.테스트 케이스는 실제로 스위치 케이스였습니다.이 스위치의 모든 경우는 테스트 단계였습니다.Python은 테스트 단계 수준에서 테스트 실행을 트리거했습니다.이 접근 방식의 좋은 점은 다양한 매개변수를 사용하여 단계를 재사용할 수 있다는 것입니다.무엇을 실행할지, 어떻게 실행할지에 대한 이 테스트 제어는 테스트 구현과 테스트 트리거링 및 평가 메커니즘 사이에서 API 역할을 하는 테스트 제어 데이터 구조를 통해 Python으로 수행되었습니다.이것이 바로 CANape가 사용된 이유입니다.실행할 테스트를 설정하고 테스트 결과를 읽습니다.테스트 단계에서 얻은 모든 값은 데이터 구조의 배열 부분에 저장되었습니다.대상이 테스트 환경에서 신뢰할 수 없는 구성 요소로 간주되었기 때문에 테스트 단계 자체는 유효성 검사에 포함되지 않았습니다.검증은 테스트 사양을 기반으로 Python으로 수행되었습니다.Python은 이러한 사양을 구문 분석하고 모든 테스트 단계에 대한 검증 기준을 포함하여 테스트 트리거 스크립트를 자동으로 생성할 수 있었습니다.모든 테스트 케이스의 사양은 검증 기준과 함께 일련의 테스트 단계 설명이었습니다.이러한 단계 중 일부는 dSPACE 관련 단계였습니다.예를 들어, 한 단계는 무언가를 초기화하고 이미 구성된 채널에서 일부 에지를 캡처하도록 요구했으며, 다음 단계는 dSPACE 장비에 명령을 내려 해당 채널에 신호를 적용하는 것이었습니다.

더 저렴한 솔루션은 dSPACE 장비 대신 사내 보드를 사용하는 것입니다.프로그래밍 가능한 신호 발생기를 어느 정도 사용할 수 있지만 대상에서 출력된 신호를 검증해야 하는 경우에는 도움이 되지 않습니다.

Answer 9

목표가 제조 테스트(모듈이 적절하게 조립되었는지, 부주의한 단락/개방 등이 없는지 확인)인 경우 먼저 케이블과 커넥터를 테스트한 다음 소켓 및 납땜 연결을 테스트한 다음 PCB 자체를 테스트해야 합니다.각 개별 라인을 높게 구동하는 반면 이웃 라인은 로우로, 그 반대로 구동하는 액세스 패턴을 찾은 다음 라인의 값을 다시 읽어 이러한 항목을 모두 단락 및 개방에 대해 테스트할 수 있습니다.

하드웨어에 대한 자세한 정보가 없으면 더 구체적으로 설명하기는 어렵지만 대부분의 임베디드 프로세서는 I/O 핀을 GPIO 모드로 설정하여 이러한 종류의 테스트를 단순화할 수 있습니다.

PCA에 대한 못바닥 테스트를 수행하지 않는 경우 이 테스트는 새로 제조된 보드에 대한 필수 첫 번째 단계로 간주되어야 합니다.