Serega Doc 0 16 февраля, 2011 Опубликовано 16 февраля, 2011 · Жалоба Доброго всем дня. Наткнулся на статьи Развитие в направлении разработки встроенных систем и Эффективная разработка встроенного ПО через тестирование про модульное тестирование для встроенных систем. Хочу уточнить есть unit тесты и mock объекты для компиляторов под AVR/STM8? Что бы свою программу на с++ можно было покрывать тестами. Вести разработку ПО максимально отделив логику от уровня железа. И при этом не испытывать проблем или же минимизировать вопросы перехода с одной платформы на другую. Как например есть программа для контроллера AVR и по каким либо причинам (дефицит, цена, характеристики) решили перейти на STM8. Переписываем классы взаимодействия с аппаратурой контроллера и в минимальные сроки получаем работоспособную (не проваливающую тесты) программу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Johnny81 0 16 февраля, 2011 Опубликовано 16 февраля, 2011 · Жалоба Ну так а что мешает? Слой, независимый от железа, можно гонять на настольном компе и покрывать любыми тестами. Я использую библиотечку googletest, есть и дофига других. Рядом с googletest болтается и библиотечка для mock-объектов, я ее правда не использовал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 16 16 февраля, 2011 Опубликовано 16 февраля, 2011 · Жалоба Тесты обязательно должны проводиться непосредственно в целевом железе. Иначе смысла особого нет. Тоже задумывался. Дело даже не в переносе между платформами. Иногда бывает, что в спешке вносишь в прошивку на ходу потайные трудноуловимые глюки, которые могут всплыть спустя годы успешной эксплуатации, в результате маловероятного стечения случайных факторов. Тесты, во первых, позволяют выявить это ещё на лабораторном столе, а во-вторых, помогают быстро локализовать. Эта тема немного перекликается с другой - о направлении проектирования (сверху вниз, в обратную сторону или промежуточный вариант). Ну и ещё - со стандартизацией кодирования. Осталось подумать, как реализовать. Я лично вижу так: 1. Уровень сопряжения с железом тестируется с помощью осциллографа и других измерительных приборов. 2. На него сверху цепляется некая прослойка-монитор, которая может читать и писать в память, запускать функции и тд. 3. Через канал связи (например, UART) эта технологическая прослойка цепляется к GDB. Далее, на ПК запускаем серию тестов и смотрим результаты. Осталось всё красиво увязать. Для меня эта тема тоже очень актуальна, поскольку прошедший год был очень богат на разные чудеса. Которые спустя некоторое время находились в какой-нибудь нелепой закорючке. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Johnny81 0 16 февраля, 2011 Опубликовано 16 февраля, 2011 · Жалоба Тесты обязательно должны проводиться непосредственно в целевом железе. Иначе смысла особого нет. Зависит от того, что пишите. Если например парсер какого-нить протокола, то без разницы где его тестить (если писать без хаков, конечно) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Serega Doc 0 16 февраля, 2011 Опубликовано 16 февраля, 2011 · Жалоба Ну так а что мешает? Слой, независимый от железа, можно гонять на настольном компе и покрывать любыми тестами. Я использую библиотечку googletest, есть и дофига других. Рядом с googletest болтается и библиотечка для mock-объектов, я ее правда не использовал. А вы под какую платформу используете googletest? И как вы интегрировали эти тесты с компилятором для железа? Что бы запускать их непосредственно из среды в которой пишем программу. Если можно то по подробнее пожалуйста. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Johnny81 0 16 февраля, 2011 Опубликовано 16 февраля, 2011 · Жалоба А вы под какую платформу используете googletest? С и С++ - кроссплатформенные языки. Части программы, написанные без использования платформо-зависимых вещей можно запускать где угодно. В своем коде я выделил такие части и тестирую их на персоналке. Тесты гоняю под MinGW и Visual C++, сейчас думаю прикрутить еще один компилер. И как вы интегрировали эти тесты с компилятором для железа? Никак. Большинство либ для тестов используют стандарную библиотеку с++ и под МК не скомпиляются. В принципе можно написать собственную библиотечку тестирования под МК, но смысла я особого не вижу. На компе тесты выполняются практически мгновенно, их удобно отлаживать и т.д. Что бы запускать их непосредственно из среды в которой пишем программу. Я работаю в eclipse, для МК компиляю IAR-ом, вызывая его из scons-файла. Также в scons завернуты тесты, только там вызываются настольные компилеры. Результат падает в консоль. Это что касалось unit-тестов. Я также тестирую всю железку в целом, но для этого использую специальную прогу-тестер, которая эмулирует собой пользователя железки, управляя по протоколу. Прога получает набор тестов и прогоняет их. Протокол управления был несколько расширен, чтобы по нему можно было передавать "нажатия" кнопок, а также содержимое экрана железки. Однако такие тесты сложнее прогнать - прогон занимает много времени, надо подключать реальное оборудование... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 16 февраля, 2011 Опубликовано 16 февраля, 2011 · Жалоба Эта тема немного перекликается с другой - о направлении проектирования (сверху вниз, в обратную сторону или промежуточный вариант). Встречное направление, ибо эти две сущности - первый шаг после ТЗ и уровень примитивов - остаются неизменными. А вот насчет гонять данные через канал связи - частенько потолок бит-рейта мешает и тогда это плавно переходит в гемор. Приходится лезть в протеус Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Serega Doc 0 22 февраля, 2011 Опубликовано 22 февраля, 2011 · Жалоба о направлении проектирования (сверху вниз, в обратную сторону или промежуточный вариант) - поясните пожалуйста. Не понял что имеется в виду. Тестирование в не целевом окружении возможно лишь для задач не зависящих от железа как Если например парсер какого-нить протокола, то без разницы где его тестить (если писать без хаков, конечно) Если же существует контроллер с обвеской: регистры, ключи, кнопки, LCD экраны и прочее. И тестирование нужно проводить с учетом нюансов электронной схемы. Подскажите насколько правильна вот такая структура формирования тестов: И тогда можно получать информацию о прохождении тестов либо в симуляторе (например Протеус) либо в реальной плате + терминал COM порта. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Johnny81 0 24 февраля, 2011 Опубликовано 24 февраля, 2011 · Жалоба Тестирование в не целевом окружении возможно лишь для задач не зависящих от железа как Если же существует контроллер с обвеской: регистры, ключи, кнопки, LCD экраны и прочее. И тестирование нужно проводить с учетом нюансов электронной схемы. Есть разные виды тестирования. Для модульных тестов целевое окружение не нужно, потому что тестится конкретная подсистема. Все остальные подсиситемы, с которыми она взаимодействует, заменяются заглушками. Например для парсера пакетов модбас совершенно безразличны нюансы электронной схемы... И еще вопрос - какие именно аспекты вы сможете потестить в железе? Например, сможете ли вы сэмулировать различные ошибки на TWI или UART, проблемы инициализации дисплея и т.д. Все равно ничто не отменит тестирования всего изделия целиком, в том виде, как оно будет поставляться клиенту. А та штука, которую нарисовали вы, достаточно геморройна в реализации... Исходя из этого, лично я остановился на: 1. модульных тестах, идущих на компе - запускаются из командной строки, отрабатывают очень быстро 2. автоматическом тестировании в железе готовой прошивки - занимает уже неск часов 3. ручном тестировании в железе готовой прошивки - занимает неск дней, делается отдельными людьми Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 16 24 февраля, 2011 Опубликовано 24 февраля, 2011 · Жалоба 3. ручном тестировании в железе готовой прошивки - занимает неск дней, делается отдельными людьми происходит в течение всего жизненного цикла изделия :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Johnny81 0 24 февраля, 2011 Опубликовано 24 февраля, 2011 · Жалоба >> происходит в течение всего жизненного цикла изделия sm.gif эт уже четвертый тип - конечными пользователями :) Они правда не всегда знают, что тестерами подрабатывают :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 16 7 марта, 2011 Опубликовано 7 марта, 2011 · Жалоба Освежу немного темку. Буквально в пятницу наткнулся на статейку. По-моему, интересно. Пока разобраться времени не было, оставлю здесь якорь, чтобы не уплыло мимо... 7. Заключение UniTesK удобен для функционального тестирования встроенного ПО: * формальные спецификации UniTesK удобны для формализации требований к встроенному программному обеспечению; * тестовые сценарии позволяют компактно записывать сложные тестовые последовательности; * механизм медиаторов предоставляет гибкие средства для отделения сценариев и формальной модели от реализации, позволяют строить различные схемы развёртывания тестового стенда Вот ещё и ещё :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 7 марта, 2011 Опубликовано 7 марта, 2011 · Жалоба Какая-то телепатия... Не далее, как позавчера, завис на очередных довесках к прототредам. Все, что читаю сейчас- так или иначе охвачено в моих потугах. TinyOS, ессо, и близко нету :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 16 8 марта, 2011 Опубликовано 8 марта, 2011 · Жалоба Какая-то телепатия... Не далее, как позавчера, завис на очередных довесках к прототредам. Все, что читаю сейчас- так или иначе охвачено в моих потугах. А я, кстати, с вашей подачи полез искать, после темы про SED и AWK - вот видимо, причина синхронизма :) TinyOS, ессо, и близко нету :) А я давно приглядываюсь, очень интересный подход. В том числе и применительно к тестированию. И даже заточено под мои любимые MSP430 :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
