Непрерывная интеграция в аппаратно-ориентированную прошивку?

#continuous-integration #embedded #gitlab-ci

#непрерывная интеграция #встроенный #gitlab-ci

Вопрос:

Как можно применять CI в случаях, когда реализация требует использования API прошивки (аппаратно-ориентированного, т. Е. Камер, датчиков и т. Д.), Или даже в наиболее удобном случае, просто данных, полученных с аппаратного обеспечения (*), и, таким образом, тестирование онлайн — по крайней мере, в моем понимании — считается непрактичным?

(*) эмуляция данных в целях тестирования может рассматриваться как обычное альтернативное решение (т.е. Использование псевдоданных, которые эмулируют данные, полученные от датчика)..

Существуют ли какие-либо общие методы интеграции CI на этапах производства таких аппаратно-зависимых / встроенных систем?

Комментарии:

1. мне неясно, чего вы намерены достичь — вы хотите просто запустить QA в своем встроенном приложении? Или вам по какой-то причине требуются аппаратные данные для принятия решений в вашем конвейере CI?

2. Мы разрабатываем код, который использует различные аппаратные устройства. Например, код, который настраивает камеру и получает данные, которые передаются на другое устройство, и так далее. Итак, используя C , мы можем компилировать новые коммиты с помощью gitlab-ci, но как мы можем обеспечить тестирование CI, поскольку программное обеспечение нуждается в обнаружении устройства? Существуют ли потенциально какие-либо общие методы для таких случаев?

3. Пробовали ли вы издеваться над аппаратными интерфейсами или рассматривали возможность использования тестового жгута, в котором контроллер тестового жгута служил бы в качестве gitlab-runner, выполнял тестовый сценарий и завершал конвейер с ошибкой или успехом в соответствии с его результатами?

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

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

Ответ №1:

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

Если важно тестирование на реальном оборудовании, вы можете подключить свое оборудование к вашему CI job runner. Например, в моей компании у нас есть собственное оборудование для нашего продукта. У нас есть «тестовая стойка», в которой несколько таких устройств подключены к нашему автономному GitLab CI runner. Это дает разработчикам, которые пишут прошивку, ОС и программное обеспечение, которые работают на оборудовании, возможность создавать сценарии и тестировать на реальном оборудовании.

Некоторые популярные аппаратные средства (мобильные устройства) доступны «как услуга» и в облаке, в «фермах устройств» (обычно мобильных устройствах, таких как iPhone), таких как AWS device farm; однако, судя по вашему описанию устройств, с которыми вы работаете, это не похоже на то, что оно будет доступно в качестве услуги.