ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Суббота
13 июля
63299 Топик полностью
bialix (20.07.2006 08:03, просмотров: 1) ответил Evgeny_CD на TDD (Test-driven Development) применительно к embedded системам: похоже, я догнал, как это должно быть устроено.
:-) у меня в черновиках почты валяется следующий незаконченный неотправленный текст Здравствуйте, коллеги! Сегодня я хотел бы затронуть тему, которая меня недавно всерьез озадачила, но мне представляется весьма смутно описанной в различных источниках. Я хотел бы поговорить об методиках и инструментах автоматического тестирования при разработке встраиваемых систем. Наибольшая сложность в этом вопросе -- собственно в его постановке. Как в принципе можно протестировать разрабатываемое устройство на этапе разработки/отладки, а также на этапе производства? В чем сложность? ---------------- Мир встраиваемых систем -- это отдельная вселенная, живущая по своим законам. Чаще всего мы создаем не универсальные программные продукты, которые подобно виндузным программам могут работать на целом зоопарке различных по начинке и частоте процессора машин. В противовес -- мы создаем то, что называют firmware -- т.е. это сплав железа и программы. Без железа программа ничего не стоит, без программы железо -- это металлолом. Соответсвенно методики тестирования основаны на определении правильности поведения железа, в котором живет программа. Может показаться, что в такой ситуации любые аналогии с современными методиками тестирования (unittest, automatic test, profiling & code coverage) становятся практически неуместными или по крайней мере слишком притянутыми за уши. Все что мы видим -- это сигналы на экране осциллографа, реже -- данные в окне JTAG-отладчика или просто поток данных в терминальной программе. О каком автоматическом тестировании может идти речь, если для тестирования нужна как минимум пара человеческих глаз? Почему это кажется важным? -------------------------- При разработке сложных систем с участием в проекте нескольких разработчиков неизбежно встает проблема интеграции кода, написанного разными программистами в единое целое. Не проблема написать крутой драйвер для какой-то части функциональности, обработчик прерывания или функцию, реализующую математические расчеты. Самое интересное начнинается тогда, когда кучу исходников начинают лепить в конкретное работающее приложение. При этом программисты, работающие с обычным компьютерным программным обеспечением, имеют в своем распоряжении целый арсенал средств тестирования, который хотя и не гарантирует, но облегчает проблемы тестирования работоспособности одного кода совместно с другим. В моей практике проверка того, что после внесения некоторых изменений в каком-то месте программы она работает как надо, заключается в загрузке программы в контроллер и ручной проверки при помощи осциллографа или терминальной программы. Проверка на наличие сигналов, нужной формы, амплитуды, соблюдения временных параметров и т.п. Правильно поставленный вопрос содержит большую часть ответа -----------------------------------------------------------