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

[SimpleSoft]

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

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

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

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

[syoma]

syoma, если говорить о сериных продуктах, пробовали ли вы прошивать платы с помощью иголок, Test Points (куда выведен JTAG) и прогонять JTAG Boundary Scan тесты? Если да, то можете поделиться информацией какое оборудование использовали и впечатления от использования?

По поводу JTAG сказать ничего не могу - у нас все лилось по USB и Boundary Scan не было. Поэтому мы все проверяли только функциональными тестами.
Могу более по Signal Conditioning или модульным контроллерам.

1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам?
2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?
Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.
Нужно доказать что интерфейсы соответствуют стандарту и т.п.
3) Как доказать что RTL также соответствует ТЗ?
Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?
4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?

Ну если предположить, что система управления требованиями у Вас настроена и работает - что сам по себе уже значительное улучшение культуры разработки, то самое интересное по вашим вопросам(кроме п.4), что я в последний раз видел на Embedded World - это система тестирования требований. Т.е. засовываете в нее свои требования и она каким-то образом прогоняет все варианты, чтобы можно было увидеть, где есть пробелы. Причем это еще до начала проектирования устройства. Я так толком и не понял, как это работает, но вроде работает.
По п.4. - климатика и ЕМС в принципе самое простое - есть стандарты - им надо соответствовать. Если уверены в своем изделии, то лучше всего тесты делать на конечном этапе, чтобы протестировать изделие в как можно близком к серийному варианте, чтобы не было вопросов при сертификации. Если не уверены - делаете промежуточные тесты до конца разработки. Мы, например, в первый раз микросекундные импульсы тестировали задолго до конца разработки на I/O и входе блока питания, чтобы не переделывать второй раз.

[Torpeda]

По п.4. - климатика и ЕМС в принципе самое простое - есть стандарты - им надо соответствовать. Если уверены в своем изделии, то лучше всего тесты делать на конечном этапе, чтобы протестировать изделие в как можно близком к серийному варианте, чтобы не было вопросов при сертификации. Если не уверены - делаете промежуточные тесты до конца разработки. Мы, например, в первый раз микросекундные импульсы тестировали задолго до конца разработки на I/O и входе блока питания, чтобы не переделывать второй раз.

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

Что касается когда делать тесты...
Количество и объём тестов во время разработки - соответственно фантазии и квалификации разработчика

Дальше следуем стандарту постановки изделий на производство.
"тесты делать на конечном этапе, чтобы протестировать изделие в как можно близком к серийному варианте, чтобы не было вопросов при сертификации." - называется квалификационные испытания (КИ). Это всё что указано в стандартах предявляющим требования к изделию (в т.ч и пожаробезопасность, и транспортопригодность по дорогах класса "Г", и даже те, что розрушают изделие, и что USB это USB и т.д. и .т.п)
На конечном этапе производства проводятся ПСИ, которые гораздо короче КИ и только гарантируют что изготовлено всё как в чертежах.

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