통합/유닛 테스트 소프트웨어 하드웨어 인터페이스

Question

로봇을 만드는 작은 재미있는 프로젝트를 진행하고 있습니다. 우리는 프로그래머가 로봇을 만드는 사람들과 평행하게 작업하고 있습니다. 따라서 우리는 변경된 소프트웨어를 실행하려고하고 있으며 빌더가 하드웨어를 변경 한 경우가 종종 있습니다. 소프트웨어 테스트가 실행되지 않는 경우 통합이 실패 할 경우 소프트웨어 또는 하드웨어가 실패하는지 또는 더 나쁜지를 파악하는 것이 항상 어렵습니다. 이 문제에 대한 자동 테스트에는 일부 어려운 부분이 있습니다.

우리는 로봇을 움직여 소프트웨어가 없어도 움직일 수 있도록 rc 제어가 가능하도록 몇 가지 방법을 알아 냈습니다. 그런 다음 소프트웨어가 이전과 같은 방식으로 작동 함을 보여주기 위해 로봇을 정의 된 수치로 이동시키는 일부 소프트웨어 테스트를 시작합니다. 그러나 이것은 항상 자동화 작업을 수행 할 수 없기 때문에 시간이 많이 걸리는 작업으로 이어집니다. 누군가 테스트를 시작하고 테스트를보고 로봇이해야 할 일을하는지 알아 내려고합니다.

또 다른 문제는 우리의 실제 하드웨어로 끊임없이 테스트하는 것이 하드웨어, 조인트, 모터, 기어 휠 등을 착용하고 있다는 것입니다.

그러나 테스트는 많은 문제를 일으키고 많은 시간을 소비하는 것으로 밝혀 졌기 때문에 하드웨어 소프트웨어 상호 작용을 다루는 다른 프로젝트에서 어떤 기술이 사용되는지 알고 싶습니다. 사용하십시오.

Answer 1

로봇과 소프트웨어 간의 인터페이스가 먼저 정의되어야합니다. 반드시 철저하게하는 것은 아니며 점진적으로 수행 할 수 있습니다. 예를 들어 기본 동작 (앞으로, 뒤로)으로 작게 시작한 다음 완전히 테스트 한 후 (예 : 왼쪽으로 돌리고 오른쪽으로 회전) 다시 테스트하고 동작을 추가합니다. 그렇게하면 팀 전체가 프로젝트에서 배운 것을 사용하여 인터페이스를 확장 할 수 있으므로 인터페이스 재 작업을 최소화 할 수 있습니다.

Progress before Hardware 문서에서는 이러한 프로세스를 TDD (Test-Driven-Development) 측면에 중점을 두어 자세히 설명합니다.

How to do TDD with hardware 질문에 대한 답변도 참조하십시오.

Answer 2

매우 흥미로운 상황이라고 생각합니다.

테스트 프로세스에는 아무런 문제가 없다고 생각합니다. 로봇을 조롱하고이 모의 모의 실험을하면 모든 것이 좋습니다.
하드웨어 로봇이 조롱 로봇과 다른 역할을하는 경우 다른 큰 문제가 있습니다. 통신.

소프트웨어와 하드웨어 간의 인터페이스는 "프로토콜"사양입니다. 제 생각에는 토론 없이는 변경해서는 안됩니다. 하드웨어 녀석은 그것을 바꿀 수 없으며 소프트웨어 녀석도 변하지 않을 것입니다! 함께 변경할 수 있습니다. 상황에 따라 모든 사람이 스스로 변경합니다.

상황에 따라 팀이 서로 작용하는 것처럼 보입니다. 어쨌든 작동하지 않을 통합 테스트가 아니라 인터페이스 및 특히 커뮤니케이션에 노력을 집중하십시오.

내 제안은 로봇의 소프트웨어 모의를 사양으로 사용하는 것입니다. 따라서 당신은 당신의 모의에 의지 할 수 있으며 하드와 소프트웨어 간의 연결을 정의하는 중심점이 있습니다.
소프트웨어 담당자가 변경하려고하면 OK입니다. 그들은 당신과 그것을 의논해야하고 당신은 소프트웨어 가짜를 바꿀 것입니다. 하드웨어가 변경되고 모의하지 않는다면 사양에 맞서 개발해야하기 때문에 사과해야합니다.

행운을 빈다.