Абсолютно согласен с one_man_show по поводу приведенного примера

Да, не быстро это все. Про это уже писали в треде.
Необходимость и "глубина" тестирования определяется конкретным проектом.
Единственное что хочу сказать - возможно сделать все.
Хочется с компа скриптами - пожалуйста. Хочется сигнатурник - да на здоровье.
Существуют критерии - стоимость - время - целесообразность создания тестового оборудования. И по приколу эти критерии противоречивы - как в той присказке "Качественно, недорого, быстро - выберите два параметра".

Выходит, Вы как раз склоняетесь к моей точке зрения.
За то время, пока фирма сумеет наладить стенд автоматизированного
контроля, "добровольные тестеры" юзеры пришлют нам
M претензий мылом, и мы выпустим N новых версий.
И стенд придется делать заново. Непрерывно. И этот
стенд никогда не успеет за реальной жизнью. И если программа
отлажена (а это делается один раз)- зачем вообще стенд отладки программ ?!!!

Вообще, такой стенд может иметь смысл толька для
примитивного контроля при массовом производстве ГОТОВЫХ изделий
(но не софта).
Тогда действительно он может существенно поднять производительность
труда и качество продукции.

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



Вы наверное удивитесь, но именно так Америкосы и проверяют..

Т.е сигналы с индикаторных портов снимаются стендиком и вообще все сигналы снимаются, а прогрмма эмулирует действия пользователя, снимает сигналы с индикатора и смотрит верные ли это сигналы (Согасно ТЗ. т.е анализирует что сигналы действительно соответсвуют "добрый вечер" на 19 пикселов сбоку).
ПРимерно что они(Америкосы) проверяли, Встроенное ПО под управлением OS CMX Tiny, ЖК 160 на 160, CAN (ихний протокол верхнего уровня), HART, FieldBus, флешка по SPI, 10 клавиш, и всякие управляющие сигналы, часы.

Все действия задавились скриптом (нажатия клавиш, отказы, прерывания готовности каждые несколько мс, запрос мастера по каналу(CAN, HART ) в рендомазное время, неговоря уже про просто проверки отказов и т.д)...

Действительно на создание оборудования ушло у них около 4 лет и дохрена баксов, но сейчас для проверки нового ПО в новых устройствах, они уже тратят буквально не больше дня!!!! Причем для проверки ПО от разных устройств занят 1 человек, который вам через сутки скажет, что в вашей программе неправильно. И что надо поменять. Точнее скажет не он а программа.

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

Не удивлюсь. Судя по качеству Виндоус.




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

У нас на фирме в этом деле занято 0 человек и тратят они 0 дней.
Просто сам программист (инженер разработчик) должен выдать
готовый продукт "и все". Иначе ни в какие бюджеты не влезешь...
Как же он отлаживается ? Единственным способом - степ-бай-степ.

А кому сейчас легко?

[/quote]
Обратите внимание на NI TestStand
http://sine.ni.com/apps/we/nioc.vp?cid=1457&lang=US

[/quote]

По поводу TestStand: это всего лишь удобная оболочка.
Обеспечивает администрирование и генерацию отчетов.
Позволяет запускать тестовые программы в определенной последовательности и обеспечивает обмен данными между ними.
Но сами тесты должны быть написаны лапками, в тех же LabVIEW или CVI.

Как поставлен процесс у нас:
1. После получения ТЗ - декомпозиция на отдельные элементы.
2. Каждый элемент сразу реализуется в виде теста.
3. После сборки - тест только на общую функциональность.

Пример - технологический контроллер специализированного датчика просто недавно закончили и небольшой)
Состоит из 2-х блоков: один поддерживает постоянную температуру датчика и снимает показания, обменивается по EIA-485 с другим блоком, в котором LCD с многоуровневым меню, 4 кнопки, есть конфигурируемый токовый выход 0-20, 4-20 или 0-5 мА. (процессоры - ATmega8 и F2MC455)

Программные компоненты:
1. Регулятор (ресурсы - АЦП, таймер)
2. Протокол (ресурсы - UART, таймер)
2.1. Драйвер UART
3. Многоуровневое меню
3.1. Драйвер LCD, бегущая строка и т.д. (ресурсы - таймер)
4. Драйвер кнопок, антидребезг и т.д. (ресурсы - таймер)
5. ШИМ для поддержания температуры - линеаризация мощности по таблице (ресурсы - таймер с ШИМ).
6. ШИМ для токового выхода (ресурсы - таймер с ШИМ)

Полученные компоненты распределяются между исполнителями.
Одно из основных требований - возможность повторного использования кода.
На выходе - тестовая программа (не интерактивная)

Например, для меню на LCD сначала нужно написать драйвер в составе проекта - набора тестов (обдумываются в процессе реализации ПО) с описаниями и докой. Потом они используются при наладке других изделий - загрузил тест в м/к - если он не работает, значит, аппаратная неполадка. Тест - генерация последовательностей символов в различных режимах и т.д.
На основе драйвера пишется вложенное меню - то же самое, тест - генерация случайных команд к меню (на уровень вверх, вниз и т.д.), после остановки все должно работать.
Причем писалась и отлаживалась на ATmega8535, а затем была перенесена на F2MC.

Для наладки регулятора (подбор коэффициентов, режимов быстрого выхода на мощностьи т.д.) через 485 подключается компьютер, пишутся программы на CVI.

После сборки проверяется только общая функциональность и взаимодействие компонентов.

Объясняю:
Если функция работы с ЖКИ обеспечивает сколько надо пикселов в изолированном тесте, слишком накладно проверять на готовом устройстве 19 их или нет. Если ПИД работает изолированно, то и будет работать. Думаю, и американцы не дураки, и в качестве элементов тестов берут уже готовые для отдельных программных компонентов.

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

TMX
Собственно со всем согласен, так оно похоже у всех и делается.
У нас это делает все один человек. Т.е. на один прибор - один человек, который и пишет все блоки для этого устройства или берет уже готовые.
На все блоки своя дока.



1. Скриптописец ошибиться не может. Так как даже если он ошибся, то программа выдает все действия которые выпоняет скрипт. И всегда можно проверить, почему вышло не так как хотелось. Это пишется в отчете.
2. Для тестирования ПО, обычно пишется программа испытаний(тестирования), собственно срипт практически и описывает эту программу.
Поэтому написание программы испытаний и скрипта - это одна и таже работа, делающаяся за одно и тоже время. И скрипт не коим образом, не увеличивает трудоемкость.
3. Про 0 человек. Нельзя проверить все пошагово в сложной программе. Отладка в основном идет блочно как сказал TMX, сложные большие куски например, ГУИ отлаживаются и вовсе просто на Компе (как например ГУИ От Микриума uC/GUI).
Естественно перед этим все алгоритмы уже описаны в виде блок схем и диаграмм. Т.е проработано практически все до мелочей. И создана дока, например API для такого-то блока (где указано, что функции должна делать). Реализация API функций - это уже дело программиста.
4. Программист по доке и алгоритмам пишет ПО, отлажиает его у себя. Отдает, как ему кажется , готовое ПО тестеру, который паралельно написанию ПО, уже написал программу испытаний и создал скрипт для этого ПО.
5. Тестер за 1 день тестит, отдает обратно программисту с результатами.
Программер меняет что-то по результатм тестов, возможно указывает ошибки самого тестера. После этого повторяет шаг 4.

Вот ОНО !!!

Встроенная в устройство программа - сложный автомат
с огромным (значительным) числом состояний.
Протестировать ее - значит создать не менее сложный
(а на самом деле значительно более сложный) автомат
состояний.

И время его создания и отладки .. гм-гм.. мы уже это обсуждали.

В худшем случае (большой проект) проверить устройство
теоретически
невозможно.

Пример - тестирование автомата "Процессор INTEL 8080".
Он тоже имеет внутри программы (микропрограммы)
Если на проверку одного состояния этого процессора
затратить 1 мкс, на все тестирование уйдет время
превышающее возраст нашей Вселенной.

То о чем Вы все время говорите - это простейшее тестирование готовых
устройств на "грубый отказ".

>То о чем Вы все время говорите - это простейшее тестирование готовых
>устройств на "грубый отказ".

Да ну нет же, конечно!
Вовсе даже не простейшее!
Я думаю коллеги со мной согласятся, что процентов 95 глюков (общее функционирование системы) отлавливается глазом, тестером и т.п.
Оставшиеся несколько процентов - это действительно кропотливая и нудная работа.
Для ее ускорения и делаются эти чертовы испытательные стенды

Есть такое понятие "система качества", и то о чем я, например, говорю - это вопросы внедрения элементов такой системы в процесс разработки ПО для встроенных приложений.

Повторюсь, я имею ввиду именно процесс разрабтки. Причем существуют эффективные приемы его оптимизации - в нашем случае, повышения качества и уменьшения времени выполнения.

Насчет тестирования ручками самим разработчиком "степ бай степ": как показала моя практика, интерактивные тесты наименее эффективны и ведут к трудноуловимым спорадическим ошибкам на дальнейших этапах. Согласно современным представлениям, стоимость обнаружения ошибки на каждом последующем этапе возрастает экспоненциально. То что разработчик несет ответственность за свою работу - ну попробуйте, привлеките его, если случилось ЧП и, например, пострадали люди. А даже если привлечете, ну и что? Остальные будут бояться и тестировать лучше?

Ваш пример с МП Интел несколько противоречив - если вы проверяете вручную, то времени на тестирование уйдет еще больше, либо вы проверите не все состояния.

Насчет глючности Windows - она и не заявляется, как надежная система, главное - быстро захватить рынок. Вообще-то я не согласен с Йордоном, насчет критерия "достаточной надежности", однако, пользуюсь Windows, а вы?

На мой взгляд, в области разработки "больших систем", таких как банковские приложения, за последние годы наработано большое количество методик разработки в условиях дефицита времени и изменения ТЗ, многие из которых можно применить и в процессе разработки встроенного ПО. Интересно было бы обменяться опытом.

Я так понимаю, что Ваш абсолютный скептицизм, основан на том, что Вы пишите программы на ассемблере, для которого не существует нормальных методик автоматического тестирования программ. В индустрии производства ПО давно разработаны методики оценки правильности работы модулей программ на основе unit-тестов. Т.е. никакой модуль и не тестируется на всем возможном многоообразии входных данных: тестируются на среднестатистических данных и на граничных данных, а также проверяется устойчивость к неверным (ложным) данным. Если модуль проходит тестирование на такой ограниченной выборке тестов, которая тем не менее корректно отображает его поведение на возможных наборах - то нет смысла тестировать Intel 8080 на всех комбинациях регистров.
Это законы больших чисел.

Не собираясь Вас переубеждать, тем не менее попрошу более терпимо высказываться насчет реально работающих методик, а не рассказывать про то, что на тестирование тратится 0 дней 0 часов. Это просто смешно.

Это вы ошибаетесь
1. я практически не пишу на ассемблере.
2. нет разницы, на чем пишесшь с точки зрения отладки.

Необходимо проверить состояния программы и переходы между ними
у программного автомата. Не так ли ? А это значит все равно на чем
написана программа. хоть на коболе.



Да я сам держал в руках мобильный телефон, который работал
совсем хорошо. Только в случае, когда вызов поисходил
когда не был запущен скринсейвер...
Запущенный скринсейвер + вызов - > глюк.

Вот вам пример - во всех состояниях и переходах состояний устройство функционирует нормально.
И лишь в одном из переходов происходит (проявляется!)сбой.
И неважно почему,важно что такое "вот оно", на самом деле существует.



Что значит "более терпимо" ? Не могу я с вами согласиться и все.
Мое мнение не является истинной в последней инстанции,
можете не соглашаться. Разрешаю. <_<
Ни каких внешних приличий ведения беседы нарушено не было с моей стороны.

И действительно я никогда не отлаживаю программ - есть же
доказательство, что это бесполезно. И это действительно так.
Не отладка, а само производство программы осуществляется
"СТЕП БАЙ СТЕП". То есть, когда автомат (или их совокупность)
еще "малы" и тривиальны есть теоретическая и практическая
возможность их точно отладить полностю. Что и приводит
к качественному результату.
Конечно, при росте проекта обязательна "интерференция", связь
между старым и новым. Главным образом по захватываемым
(и высвобождаемым) ресурсам. И это главный недостаток
такой технологии. Но эти ресурсы во встроенной технике
можно непрерывно контролировать..стек например/

Речь вобще-то не про отладку как таковую, а про тестирование. Программист не может хорошо проводить тестирование своего кода, потому что он его слишком хорошо знает.

Это пример, что _не во всех_ состояниях устройство функционирует нормально.
Что говорит про то, что не было произведено нормальное тестирование работы скринсейвера. Косвенно может быть признаком того, что такой скринсейвер является чем-то посторонним для основной программы телефона, или был приделан программистами позднее, когда не оставалось времени на нормальное тестирование.

Тестирование != отладка.