임베디드 환경 또는 테스트 자동화 가능성이 매우 제한적인 회귀 테스트를 실행하기위한 좋은 방법 및 전략은 무엇입니까?임베디드 시스템에서 회귀 테스트 수행 방법
내 경험상 많은 테스트가 수동으로 수행되어야합니다. 즉 테스터는 일련의 버튼을 누르고 기계가 올바르게 작동하는지 확인해야합니다. 개발자로서 변경 사항이 다른 것을 깨뜨리지 않는다는 것을 확신하는 것은 정말로 어렵습니다.
적절한 회귀 테스트가 없으면 큰 리팩터링 등에서 상황이 더욱 악화됩니다.
누구든지 문제를 인식합니까? 이런 종류의 문제를 해결하기위한 좋은 해결책이나 과정을 찾았습니까?
필자는 개인적으로 임베디드 코드를 타겟 하드웨어와 내 컴퓨터에서 모두 컴파일하는 것을 크게 좋아합니다. 예를 들어, 8086을 대상으로 할 때, 8086 하드웨어와 DOS 진입 점에서 재설정 할 진입 점을 모두 포함했습니다. 하드웨어는 모든 IO가 메모리 맵핑되도록 설계되었습니다. 그런 다음 조건부로 하드웨어 시뮬레이터에서 컴파일하고 조건에 따라 하드웨어 메모리 위치를 시뮬레이트 된 하드웨어 메모리로 변경했습니다.
x86 플랫폼이 아닌 플랫폼에서 작업하려면, 대신 에뮬레이터를 작성하십시오.
또 다른 접근법은 하드웨어를위한 모든 입력과 출력이 소프트웨어를 통해 제어되는 테스트 리그를 만드는 것입니다. 우리는 공장 테스트에서 이것을 많이 사용합니다.
한 번 우리는 IO 하드웨어에 시뮬레이터를 구축했습니다. 그런 식으로 나머지 시스템은 CAN을 통해 몇 가지 명령을 전송하여 하드웨어를 시뮬레이션 된 모드로 전환하여 테스트 할 수 있습니다. 비슷하게 잘 정의 된 소프트웨어는 소프트웨어 명령에 대한 응답으로 IO가 시뮬레이션되는 "시뮬레이션 모드"를 가질 수 있습니다.
대상 환경을 에뮬레이트하는 개별 서브 시스템 및 전체 프로젝트에 대한 테스트 하네스/샌드 박스/모형을 제공하십시오.
이것은 실제 환경에서 테스트 할 필요가 없지만 시뮬레이션이 대부분의 문제를 해결할 때 번호가 크게 줄어들어 모두 통과하고 비싼 인간 중심 테스트를 수행 할 때 합리적으로 자신감이 있습니다 처음으로 통과 할 것입니다.
누구든지 문제를 인식합니까?
가장 확실합니다.
는 이런 종류의 문제를 처리 할 수있는 좋은 솔루션이나 과정이 되었습니까?
기술의 조합 :
PC 컴파일러에서의 컴파일과 관련하여, 이는 높은 수준의 모듈과 테스트에 적합한 하네스가있는 저수준 모듈에 대해서는 의미가 있습니다.
예를 들어 여러 소스의 실시간 신호를 처리해야하는 코드 부분에서는 에뮬레이션을 시작하는 것이 좋지만 충분하다고는 생각하지 않습니다. 가능한 한 현실적인 환경에서 실제 하드웨어의 코드를 테스트하는 대신 대개는 사용할 수 없습니다.
귀하의 앱이 을 빌드하고 적어도 부분적으로는 일반 PC에서 테스트한다는 점을 제외하고 (이는 Valgrind와 같은 도구를 사용하여 에 유용합니다) 소프트웨어 디자인에 대해 생각해 보겠습니다.
하나의 프로젝트는 하드웨어를 구동하기위한 구성 요소를 가지고있었습니다. 하나는 관리 작업을 처리하고 다른 하나는 네트워크 관리를 다루는 프로젝트였습니다. 네트워크 관리가 SNMP에 의해 처리되었으므로 원격으로 실행되는 스크립트를 쓰기 위해 스크립트를 작성하는 것이 쉬웠습니다.
저수준 하드웨어 테스트를 실행하기 위해 필자는 드라이버의 IPC에 테스트 스크립트 및 주입 된 명령을 구문 분석 한 간단한 스크립트 리더 인 을 작성했습니다. 결과물은 비디오 기반 이었기 때문에 눈으로 보는 것보다 처리를 자동화하는 것이 어려웠지 만 RSI는 확실히 을 저장했습니다. 또한 이 버그를 확인하기 위해 알려진 실패 조건을 테스트하거나 시뮬레이션 한 경우 이 다시 발생하는 스크립트를 생성하는 데 매우 유용했습니다.
내가 다시 한 번해볼 때 어디에서나 공유 라이브러리를 구현하면 테스트 하네스와 실제 코드에서 코어 메시지를 보낼 수 있습니다. 나는 파이썬 (또는 뭔가 비슷한) lib 디렉토리를 마무리하므로 내 테스트는 약간 더 "스크립트 가능"할 수있다.
제 경험상 자동 하드웨어 테스트가 중요했습니다. - 두 컴퓨터 모두에서 듀얼 컴파일에 투자하면 & 대상이 "좋은 기능"이지만 선택이 주어지면 자동 하드웨어 테스트에 투자하는 편이 낫습니다. 제조 무기가 고장 분석을 위해 기능을 원하거나 필요로하기 때문에 결국 비용 효율적인 솔루션이 될 것입니다.
저는 자동화 된 하드웨어가 필수라고하는 모든 사람에게 동의합니다. 우리는이 방법을 사용하여 일부 장치와 함께 임베디드 소프트웨어를 테스트합니다. 우리는 하드웨어 시뮬레이터로 가득 찬 대형 2- 랙 테스트 스테이션을 구축했으며, Labview VI, C# 코드, 벤더 DLL 등을 혼합하여 NI TestStand를 사용하여 모든 것을 관리합니다. 우리는 많은 하드웨어를 테스트해야합니다. 그래서 우리는 모든 허튼 소리를 가지고 있습니다. 소프트웨어를 테스트하는 중이면 맨손으로 필수 요소로 다시 확장 할 수 있습니다. 직렬 인터페이스 테스트?직렬 트래픽을 시뮬레이트하고 모든 메시지 (및 유효하지 않은 몇 가지 메시지)를 사용하여 소프트웨어가 올바르게 응답하는지 확인하기위한 장치를 구축하기 만하면됩니다. DIO 테스트? 간단합니다. DIO를 시뮬레이션 할 수있는 USB 주변 장치 또는 임베디드 장치가 많이 있습니다. 타이밍이 중요하다면 다른 임베디드 디바이스를 사용하여 원하는 공차를 확보해야합니다. 그렇지 않으면 PC가 정상적으로 작동합니다.
중요한 부분은 항상 테스트하고있는 내용을 알고 그 이외의 것을 테스트하지 않는 것입니다. 소프트웨어 인 경우 테스트가 가능한 한 하드웨어와 독립적인지 확인하십시오. 파형 생성이나 D/A로 테스트하는 경우에는 별도의 작업을 수행하십시오. 사전 준비된 시퀀스를 내 보내지 않는 한 특별한 작업을 수행하지 않는 임베디드 장치에서 소프트웨어의 특수 빌드로 D/A 하드웨어를 테스트하십시오. 전압 레벨. 그런 다음 참조가 꺼져 있는지, 필터가 잘못된 주파수로 설정되었는지 등을 확인할 수 있습니다. 그런 다음 하드웨어와 독립적으로 소프트웨어를 테스트 할 수 있어야합니다. 개발 보드를 사용하여 소프트웨어를 테스트하고 프로세서에서 동작을 확인하십시오 핀이 맞습니다.
지금까지 대부분의 응답자와 달리 데스크탑 시스템과 전혀 다른 임베디드 환경에서 작업하므로 데스크탑의 임베디드 시스템을 에뮬레이션 할 수 없습니다.
좋은 테스트 시스템을 작성하려면 테스트 시스템에 피드 포워드 및 피드백이 필요합니다. JTAG는 장치를 제어하는 가장 일반적인 피드 포워드 방법입니다. 장치의 완전한 상태 (운이 좋으면 전체 보드)를 설정 한 다음 테스트 코드를 실행하도록 설정할 수 있습니다. 어느 시점에서 당신은 당신의 피드백을 얻습니다. JTAG는 또한 피드백 장치로 사용될 수 있습니다. 그러나이 상황에서 소프트웨어 API가있는 로직 분석기가 가장 좋습니다. 핀의 특정 레벨을 찾고 펄스를 카운트하고 스트리밍 주변 장치의 데이터 스트림을 파싱 할 수도 있습니다.
내가 일하는 곳에서 사용되는 해결책은 야간 자동화 빌드 및 테스트 절차입니다.
테스트 스크립트는 일종의 통신 프로토콜을 사용하는 경우 쉽게 실행할 수 있습니다. 그것은 내부 단위 테스트에 좋습니다. 상황을 더욱 흥미롭고 (철저하게) 만드는 것은 외부 IO를 시뮬레이트하기 위해 보드에 꽂는 와이어 링 하네스를 만드는 것입니다.
에뮬레이션은 개발 및 기본 초기 테스트에 적합하지만 실제 실제 작동 시간은 시스템 검증을위한 신뢰할 수있는 유일한 방법입니다. 물리적 인 동작은 전압 강하, 잡음, 글리치, 디 바운스 (debounce) 문제, 경쟁 조건 등과 같은 코딩되지 않은 문제 (코드 방법으로 인해 발생)를 찾아 낼 수 있습니다.
장시간 시스템 테스트 또한 중요합니다. 시스템을 며칠에서 몇 주 동안 지속적으로 악용하는 자동화 된 테스트를 설정하는 것은 현장에서 몇 달 후까지 자르지 않을 수있는 문제를 강제로 제거하는 좋은 방법입니다. 일이 우스꽝스러운 행동을 시작할 때마다 고객에게 힘을 주기만하면 모든 산업이 접할 수있는 사치가 아닙니다.
이 질문도 참조하십시오 : [하드웨어로 TDD하는 법] (https://stackoverflow.com/questions/585593/how-to-do-tdd-with-hardware) – geschema