Как интегрировать / тестировать программно-аппаратные интерфейсы

Question

Я работаю над маленькими забавными проектами, которые собирает робот. Мы, как программисты, работаем параллельно людям, строящим робота. Поэтому очень часто мы пытаемся запустить измененное программное обеспечение, а сборщики изменили оборудование. Если тесты программного обеспечения не выполняются, всегда сложно определить, происходит ли сбой программного или аппаратного обеспечения или, что еще хуже, в случае сбоя интеграции. Есть некоторые сложные детали с автоматическим тестированием для этих проблем.

Мы придумали несколько способов сломать вещи, поэтому у нас есть rc-контроль, позволяющий роботу выполнять некоторые движения без программного обеспечения, гарантирующего, что он все еще работает. Затем мы запускаем некоторые программные тесты, которые заставляют робота делать определенные цифры, чтобы показать, что программное обеспечение ведет себя так же, как и раньше. Но это всегда сводится к очень трудоемкой задаче, потому что вы не можете автоматизировать ее, и кто-то должен запустить тест, наблюдать за тестом и попытаться выяснить, сделал ли робот то, что он должен делать.

Другая проблема заключается в том, что постоянное тестирование на нашем реальном оборудовании приводит к износу частей нашего оборудования, шарниров, двигателей, зубчатых колес и т. д.

Но оказалось, что не тестирование вызывает столько проблем и занимает так много времени, что мне хотелось бы знать, какие методы используются в других проектах, связанных с взаимодействием аппаратного и программного обеспечения, и есть ли инструменты, которые могут быть б.

Answer 1

Сначала необходимо определить интерфейс между роботом и программным обеспечением; не обязательно исчерпывающе, это может быть сделано постепенно. Начните с малого, например, с базовых движений (вперед, назад), затем, как только он будет полностью протестирован, как в изоляции, так и в интеграции, добавьте некоторое поведение (например, поверните налево, поверните направо), повторите тестирование. Таким образом, вся команда может использовать то, чему она научилась на протяжении всего проекта, для расширения интерфейса, возможно, минимизируя переделки интерфейса.

В статье «Прогресс до аппаратного обеспечения» описан такой процесс более подробно, с акцентом на аспект управляемой тестированием (TDD).

См. также ответы на вопросы о том, как использовать TDD с аппаратным обеспечением .

Answer 2

Я думаю, что это очень интересная ситуация.

Я считаю, что нет никаких проблем с вашим процессом тестирования. Если вы издеваетесь над своим роботом и тестируете его, то все хорошо.
Если аппаратный робот действует не так, как ваш поддельный робот, есть еще одна большая проблема: Связь .

Интерфейсом между программным и аппаратным обеспечением является «протокол». Спецификация. На мой взгляд, это не должно быть изменено без обсуждения. Аппаратные парни могут не изменить его, и вы, программные парни, тоже нет! Вы можете изменить это только вместе. В вашей ситуации каждый меняет его самостоятельно.

В вашей ситуации ваши команды работают друг против друга. Поэтому постарайтесь сосредоточить свои усилия на интерфейсе и особенно на общении, а не на интеграционном тесте, который все равно не сработает.

Моим предложением было бы использовать программный макет робота в качестве единственной спецификации. Таким образом, вы можете положиться на свой макет, и есть центральная точка, которая определяет связь между аппаратным и программным обеспечением.
Когда разработчики программного обеспечения хотят изменить это, хорошо. Они должны обсудить это с вами, и вы смените макет программного обеспечения. Если оборудование было изменено, а макет - нет, у вас есть извинения, потому что вы разрабатываете против вашей спецификации.

Удачи!