:-) у меня в черновиках почты валяется следующий незаконченный неотправленный текст Здравствуйте, коллеги!
Сегодня я хотел бы затронуть тему, которая меня недавно всерьез озадачила, но мне представляется весьма смутно описанной в различных источниках. Я хотел бы поговорить об методиках и инструментах автоматического тестирования при разработке встраиваемых систем.
Наибольшая сложность в этом вопросе -- собственно в его постановке.
Как в принципе можно протестировать разрабатываемое устройство на этапе разработки/отладки, а также на этапе производства?
В чем сложность?
----------------
Мир встраиваемых систем -- это отдельная вселенная, живущая по своим законам. Чаще всего мы создаем не универсальные программные продукты, которые подобно виндузным программам могут работать на целом зоопарке различных по начинке и частоте процессора машин. В противовес -- мы создаем то, что называют firmware -- т.е. это сплав железа и программы.
Без железа программа ничего не стоит, без программы железо -- это металлолом. Соответсвенно методики тестирования основаны на определении правильности поведения железа, в котором живет программа.
Может показаться, что в такой ситуации любые аналогии с современными методиками тестирования (unittest, automatic test, profiling & code coverage) становятся практически неуместными или по крайней мере слишком притянутыми за уши. Все что мы видим -- это сигналы на экране осциллографа, реже -- данные в окне JTAG-отладчика или просто поток данных в терминальной программе. О каком автоматическом тестировании может идти речь, если для тестирования нужна как минимум пара человеческих глаз?
Почему это кажется важным?
--------------------------
При разработке сложных систем с участием в проекте нескольких разработчиков неизбежно встает проблема интеграции кода, написанного разными программистами в единое целое. Не проблема написать крутой драйвер для какой-то части функциональности, обработчик прерывания или функцию, реализующую математические расчеты. Самое интересное начнинается тогда, когда кучу исходников начинают лепить в конкретное работающее приложение.
При этом программисты, работающие с обычным компьютерным программным обеспечением, имеют в своем распоряжении целый арсенал средств тестирования, который хотя и не гарантирует, но облегчает проблемы тестирования работоспособности одного кода совместно с другим.
В моей практике проверка того, что после внесения некоторых изменений в каком-то месте программы она работает как надо, заключается в загрузке программы в контроллер и ручной проверки при помощи осциллографа или терминальной программы. Проверка на наличие сигналов, нужной формы, амплитуды, соблюдения временных параметров и т.п.
Правильно поставленный вопрос содержит большую часть ответа
-----------------------------------------------------------