Как тестировать разработанную электронику и встраиваемое ПО?, Делимся опытом Опции

[SimpleSoft]

Здравствуйте!

Перед тем как передать разработанные Embedded software & Hardware заказчику или в серийное производство, мы должны его протестировать.
Конечно много зависит и от проекта и от доступных средств тестирования.

Как делаем мы:
Пример : Разработка ПО на базе STM32F. Использование Continuous integration вкупе с SVN. Отдел QA сделал Python скрипт для выгрузки и сборки ночью проекта (проект на GCC). Загрузка и запуск на целевой плате через JTAG. Целевая плата подключена к управляемому по USB источнику питания и тестируется с помощью FTDI FT4232H. FT4232H эмулирует I2C, SPI и UART и через скрипты Python оформелны протоколы взаимодействия. Стараемся покрывать, насколько можем, тестами через данные интерфейсы. Также проводим нагрузочное тестирование с помощью данного стенда.

Может есть готове комплексы для тестирования? Как вы организовали у себя?
Поделитесь опытом тестирования ваших продуктов.

[syoma]

Предлагаю остановить этот поток сознания, и дать ваше определение понятия "итерация".
Поскольку как мне кажется никто не понимает о чем вы. Про умный дом?
Так там что ни сделаешь всё пойдет, "итерации" теряют смысл ибо они и есть цель.

Причем здесь "умный дом"? Кстати насчет "итераций" там - да там их поле непаханное, особенно когда читаешь истории про попадалово: один начал на ардуино, все сгорело от молнии, выкинул, купил ПЛК. Другой начал на одном контроллере, думал, что хватит возможностей, не хватило ног - начал все сначала с новым контроллером, так как старый уже не выпускают. Третий начал пять лет назад, закончил, сейчас забыл, что делал, так как документации нет. Четвертый мучался с LCD дисплеем полгода, потом понял, что тач-скрин обойдется дешевле...Хохма в общем. Чем вам не итерации?

Но есть проекты где какие-то итерации в принципе невозможны, например система управления промышленным объектом.

Конечно, но этому есть причина - тот кто сделает за 2 итерации просто вылетит с рынка, так как не влезет ни по срокам, ни по стоимости, и никакому заказчику на его объекте эксперименты ни к чему.Но если разбивать такую разработку на несколько этапов, то на отдельных из них будут итерации, как ни крути. Например при пуско-наладке часто надо внести изменения в код или перенастроить параметры и провести тесты. Это итерации, количество которых можно уменьшить, например, путем отладки на макете, моделирования/симуляции, или HIL или на основании опыта.

[AlexandrY]

Это итерации, количество которых можно уменьшить, например, путем отладки на макете, моделирования/симуляции, или HIL или на основании опыта.

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

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

[psL]

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

для ПО есть мажорные, минорные релизы и патчи. По вашему, итерация для изделия - это только патчи?
с точки зрения DCDC может измениться контроллер преобразователя или материалы накопителя, тогда придется переделывать многое или вообще все. Т.е. получится мажорный релиз. Почему за это следует увольнять?