Вопрос возник вот почему. Ездили у нас товарищи на стажировку в америку. Так вот, там тестирование ПО, происходит следующим образом:
1. С помощью скриптового языка создается программная модель перефириии с которым работает контроллер, т.е. все интерфейсы (SPI, I2C, CAN, HARTи т.д) и нижнего и верхнего уровня, всей переферии (индикатора, управляющих портов, кнопок и т.д)
2. Подсоединяется некое устройство которое передает всю иноформацию с выводов контроллера в компьютер на котором запущена программная модель
3. И вся эта бодяга в разных условиях тестируется.. Т.е эмулируется нажатие клавиш, работа и сбои флеша, озу, ацп и т.д. Причем модель поведения тоже задается с помощью скриптов
4. Выводится отчет об ошибках в каких местах, и что надо сделать чтобы устранить.
Все про все занимает не более 8 часов.

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

Немного из другой области но все же похоже...
Если взять, например, реализацию различных телеком протоколов то для них тестирование производится именно так, как это делают буржуи в пункте 1....для этого даже есть спец язык -ttcn и среда разработки tau ttcn suite. Тестовые сценарии обычно приведены в соответствующем протоколу стандарте. Но оч часто (имхо) нет ни времени, ни средств разбираться с тестером; поэтому имхо народ крутит свои тесты. Вроде бы как ttcn скрипты автоматически генерируются из sdl (sdl - грубо говоря, язык описания модели).
Я могу предположить (так как я не аппаратчик, а программист), что в примере с буржуями тоже используется что-то вроде sdl (может быть vhdl) и уже по vhdl создаются тестовые сценарии.

veark

На сколько я понял от друзей которые ездили в америку, язык скриптов в моем случае, америкосы свой сделали.

Я сам этим вопросом последнее время очень озабочен. Методика американцев - похоже единственно удачная. Но это в плане отработки самого ПО. А тестирования устройства в целом? Подавая на входы контроллера тестовые сигналы и снимая с других выходов отклики? Как с этим обстоит дело?



Понятно, что такое быстро не повторить. А не быстро - это сколько? Месяц? Полгода? Думаю, что если есть действительно стремление и производственная нужда, то имеет смысл делать.

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

Вааау !
Идея отличная. Только кто и как протестирует и наладит
эту программную модель.. А вдруг ошибки и несовершенство
этой модели пропустят критические ошибки тестируемого устройства ?

Дело в том, что этот скриптовый язык практически описывет Техническое задание.
Т.е. например пишем "Нажать На кнопку 1. На индикаторе дожно быть Hello world"
И так далее, и этот алгоритм очень легко проверить.
Так как сам алгоритм есть в описании работы устройства.

Т.е мы по сути задаем последовательность действий.
Скажем по каманде "Нажать на кнопку1 .Прочитать данные из флеша. Проверить правильность. Вывести на индикатор"

У нас запускается модуль считывания инофрмации с клавиатуры, потом модуль считывания и преобразования информации обмена по SPI для Флеша(точнее он запущен всегда), потом модуль считывания и проверки информации с Выводов индикатора.
Я полагаю, что модули эти уже написаны и проверены.. Скажем есть модель эмуляции Flash, Индикатора. А по командам они просто запускаются и выводят отчет.

И как это проверить ? Ставить видеокамеру с системой
распознавания образов ?!!

Если надо проверить нажатие на "КН 1",
то это и вручную можно, и системой контроля можно.
Еще неизвестно что дешевле, если нанять русского .
А если речь идет, например, о системе
автомотизации промышленной установки (или всего предприятия вцелом)?
Такая система контроля может быть сложнее и много дороже самой тестируемой системы.

Теоретически идея наверное подойдет для массового производства примитивной бытовой электроники. Но это все равно уже делают
китайцы и делают быстрее и дешевле всех в мире.

Речь не идет об автоматизации производства, а об проверки правильности работы встроенного ПО (т.е проверке самой программы).
Насчет русского, может оно так и есть, но только проверка ПО даже небольшой проги занимает не менее недели.
Это же надо все режимы задать, все отказы проверить и т.д.
Понятно, что если разработка одна и больше нету, то китаец этот окупается, а если разработок много, то приходится нанимать уже 2, 3 китайца.

Вообще да у на насчет этого, все просто взял челочка и все, Вот например у нас на предприятии, над калибровкой нескольких тысяч датчиков в месяц работают порядка 50 человек. А в Америке над калибровкой того же каличества 3 человека, потому-что все автоматизировано, а у нас полуавтоматизировано, т.е например операции запихивания в термокамеру и выставления калибровочного значения делаются в ручную с копьютера, а у америкосов все автоматом. Калибровка одного датчика и у них и у нас занимает 2 дня. Себестоимость примерно одникова (ПОКА).

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

Речь идет именно об автоматизации производства.
Производства программ. Тестирование - часть этого процесса.

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

Подадим на вход датчика "правильный" сигнал и снимем c выхода
реальный результат. Получим индивидуальную калибровочную
характеристику. Запишем ее в EEPROM. И может быть выведем на принтер
для отчета.
Но это - не производство программ.


А теперь попробуйте автомотизировать тестирование ПО
мобильных телефонов..
Нужно смоделировать именно человеческое поведение - нажатие
на клавиши и кнопки, контролировать правильность вывода
на дисплей с соответствие звучашей мелодии назначенной СМС-у..

> А теперь попробуйте автомотизировать тестирование ПО
>мобильных телефонов..
>Нужно смоделировать именно человеческое поведение - нажатие
>на клавиши и кнопки, контролировать правильность вывода
>на дисплей с соответствие звучашей мелодии назначенной СМС-у.

Скриптом? С компа? Да запросто!
Можно забацать этакий контроллер тестировочный, суешь в него плату нажимаешь кнопку - загорается зеленый - ОК, красный - в морг
Все дело только в необходимости такого устройства.
Помню в том веке были у нас сигнатурные анализаторы, шли как зип для станков с чпу - подключаешь к нему плату - он говорит с точностью до корпуса, кто хворает

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

А теперь попробуйте скриптами потестировать DOOM-3..

В 88г сам столкнулся с агрегатом для проверки цифровых европлат (по габаритам ДВК подоиные). Анализ на основе сигнатур сигналов. Компакт касетный стример. За создание тестовых последовательностей не хило плати. Одну плату женщина делала примерно за 1,5 месяца. Естественно лашки и енки, регистры. Все ттл. Но потом анализ платы за 5 минут, с указанием цепи с неправельной сигнатурой.

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

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

>>Я нажал на кнопку и на дисплее должно появиться
>>"Добрый день" посередине.
>>А появилось "добрый вечер" на 19 пикселов сбоку..
Не понял, к чему эта фраза?
Если к тестированию дисплея - в морг его или регулировать.
Если тестируем софт - в морг
Если фраза для флейма - ....

>Создание тестирующего оборудования для нахождения
>таких ошибок обойдется подороже, чем найм бета тестеров.
>Но это еще цветочки.

Я же писал:
>Все дело только в необходимости такого устройства.
Если единичное или мелкосерийное производство то может и не иметь смысла.
Если важна надежность или скорость нахождения неисправности - может иметь смысл.
Возможны и другие варианты.


>А теперь попробуйте скриптами потестировать DOOM-3..
Что-то вы как воробей с ветки на ветку
>>> А теперь попробуйте автомотизировать тестирование ПО
>>мобильных телефонов..

Ну разные вещи, да?
Давайте договоримся, что тестируем - чисто железо или чисто софт или комплекс
Ну я просто уверен, что DOOM тестировался и по частям и целиком и на разных компах и на разных операционках. И, по всей видимости качество тестирования оч. хорошее. Видимо стоимость тестирования была оценена правильно

Хотелось бы слегка остудить пыл коллег, у которых все легко и быстро, примерами из жизни (к сожалению таких случаев было много):
создается изделие, заранее закладывается срок и средства для тестирования, выделяется бригада из двух человек для создания в будующем стенда автоматического контроля и пр. Начали, делаем, по ходу выясняется как обычно, что со сроком промахнулись. Позже выяснилось, что с деньгами тоже Но никто не подвергает сомнению необходимость создавать стенд, так как изделие очень важное. Бригада работает, порождает тест за тестом, а автоматизма не получается. Только со временем становится понятно, на сколько сложно устройство, и каков должен быть накоплен опыт, чтобы породить тестовый стенд.
Проходит год после того, как устройство уже выпущено и трудится, а бригаду тестеров не расформировывают, так как в реальной среде устройство себя ведет слегка иначе, чем думали. Закончилось все тем, что был создан отдел по проектированию автоматических систем контроля. Опыт показал, что первые сырые тесты сделать действительно легко и быстро, но хорошего результата можно достичь только, если:
- тесты делают люди из состава разработчиков (они лучше знают изделие)
- никто не торопится получить результат быстро, т.к. такой результат нельзя использовать в реальности
- вывод о качестве тестирующего оборудования делается после как минимум года эксплуатационного периода изделия, чтобы можно было понять как ведет себя изделие и как хорошо выявили все его баги на стадии тестирования.
В последнем пункте подставьте свое значение вместо "года".
Удачи

Абсолютно согласен с 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. нет разницы, на чем пишесшь с точки зрения отладки.

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



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

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



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

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

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

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

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

пару ссылок насчет тестирования:

http://russian.joelonsoftware.com/Articles...ouDontHave.html
http://www.joelonsoftware.com/articles/BetaTest.html

http://software-testing.ru/

Вот и я об этом самом говорю.
Для тестирования потребуется создать программу-автомат
проверяющую ВСЕ состояния и ВСЕ переходы тестируемого
обьекта.
А это еще более сложный автомат.
Если мы сомневаемся в более простой программе, из чего
следует, что мы сумеем сделать значительно более сложную ?

А чего там долго рассуждать.
Возьмите чего-либо попроще. Не надо сразу мобильный телефон.
Возбмите, к примеру ПИД-регулятор температуры.
Распространенная техника, практически стандартный проект.
Температуру измеряем датчиком DS1820 или диодом+ацп. На выбор.
Шим модуляция нагревателя. Дисплейчик, пара кнопок.

1.Попробуйте прикинуть, во что обойдется создание тестирующего
оборудования. С технической точки зрения хотябы.
2. попробуйте предложить это бухгалтеру и директору.
3.А потом это предложение распространите на каждый проект
организации.

Увидите, что вам ответят...

Я думаю, тестирование на стадии разработки не должно быть глубоким и не выходить за рамки ТЗ. Главное проверить функционирование устройства в допустиых режимах работы и на отлавливание ошибок, сбоев.
Много ошибок искать не недо, жизнь потом сама покажет, что в реальных условиях не работает.
Важно на первой стадии исправить аппаратные ошибки, т.к. с ними придется возиться руками, кусачками и паяльником
А программное обеспечение оно само так и называется, чтоб его можно было в дальнейшем в программе исправлять без особых переделок.

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

В нашей органазации все устройства тестируются на макете перед тем как отдавать заказчику. Иначе потом рассказывать, что все фигня и мы быстренько программу подлатаем -- когда у него на объекте уже что-то сгорело или сломалось из-за нас -- дохлый номер.

В нашей тоже. Однако отладить программу на макете
и протестировать софт - "не одно и то же". <_<
Вручную я смогу смоделировать например, не штатную
ситуацию о определю - правильно ли работает
алгоритм обработки такой ситуации.
Но мы беседовали о возможностях такой
проверки посредством скриптописца. Это значит
ему придется с помощью программно-аппаратных
средств смоделировать работу датчика DS1820 или АЦП.
А как он (скриптописец) проверит правильность работы
вывода на дисплей ? Именно диаграммы работы - это
ведь тоже делает программа. В такой диаграмме допустимые
"зазоры" могут быть 10-20 нс и это надо будет померить..

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

похоже мы с Вами никогда не договоримся до общих терминов, поэтому дальше продолжать не вижу смысла.

Чтож - не надо, так не надо.

Однако несмотря ни на что по результатам дискуссии
можно сделать некоторые выводы.
По моему мнению , только Ван-Мэншоу (голландец ?! )
и -Тумблер- хоть как то поняли суть проблемы и
возможные трудности и тонкости ее реализации.

А как хорошо всем известно, Эмбеддед Девэлопыры - штучный
товар. Их много не нужно. Обычно 2-4 человека на среднюю
по размерам фирму. Это значит, в ходе бескомпромиссной
и порой жестокой конкурентной борьбы (которая еще не
совсем захватила просторы бывшего Советского Союза)
между производителями за рынки сбыта продукции очень
скоро выяснится, какой ущерб бизнесу наносят "среднего уровня"
разработчики. А поскольку разработчиков много не нужно,
их будет из чего выбрать.
Так вот - желаю Вам остаться в этой профессии !

Вопрос, который уважаемое сообщество обсуждает, очень интересен.
Но предлагаю сразу разделить:
1) тестирование при квалификационных испытаниях по завершению ОКР;
2) и автоматизацию технологических операций ПСИ при производстве Изделий.
В первом надо тестировать и ПО и соответствие параметров "железа"требованиям ТЗ
Во втором случае - достаточно только качество сборки, на соттветствие ТУ(ТТХ), т.к. "рукописи не горят"
Предлагаю в своих статьях указывать, по какому случаю излагается мнение

Мы у себя пришли к выводу, что автоматизированный стенд дожен создаваться до завершения ОКР по Изделию, к примеру, с момента когда готов опытный образец. java script:emoticon(':)')
smilie
На испытания , сартификацию опытного образца, внесение изменениий в документацию по результатам испытаний, технологическую оснастку требуется время. За которое из типовых решений (для данного типа изделий) должен создаваться стенд.
Гибкость стенда должна достигаться применением языка описания операций.
Адаптировать "к изменениям условий окружающей среды" его должна инженерная служба сопровождения Изделия

Лично я всегда воспринимал разработку и тестирование как взаимодополняющие вещи. ВСЕГДА ЕСТЬ И ИЗДЕЛИЕ, И СТЕНД - даже если "тестовый стенд" на самом деле обслуживается покупателем изделия (и такой стенд довольно дорог, ибо его цена в тяжелых случаях - потеря рынка; для каждой группы изделий своя оптимальная грань между "выпустить сырое, но раньше"/"выпустить почти идеальное, но позже"). С формальной точки зрения, есть один документ - ТЗ, по которому кто-то делает СТЕНД, кто-то - ИЗДЕЛИЕ. В некоторый момент их сталкивают между собой. Если ТЗ составлено верно, полное формальное соответствие СТЕНДА и ИЗДЕЛИЯ, разработанных по ТЗ, происходит как раз на оптимальной грани "сырое-раньше"/"идеальное-позже". По результатам взаимодействия изделия и стенда кем-то (в тяжелых случаях - пользователем ИЗДЕЛИЯ) выносится РЕШЕНИЕ, продолжать разработку ИЗДЕЛИЯ (доводку железа, отладку программ и т.п.) или прекратить, совершенствовать СТЕНД дальше или удовлетвориться уровнем тестирования, обеспечиваемым имеющимся. Весь фокус автоматизированных систем для тестирования - в ФОРМАЛИЗАЦИИ: и разработчик ИЗДЕЛИЯ, и создатель СТЕНДА, и автор ТЗ говорят на одном ФОРМАЛЬНОМ языке, им не надо махать руками друг перед другом, объясняя, как и что будет работать и тестироваться. Основная проблема - набрать словарь этого языка, чтобы легко и
просто проверялось, как в начале писалось, " нажатие клавиш, работа и сбои флеша, озу, ацп и т.д." И словарь этот набирается годами, также как опыт программиста, опыт конструктора, опыт менеджера. Условно, разработчик "копит" схемные решения и библиотеки процедур на C, конструктор - библиотеки 3D-моделей, менеджер - свои ощущения рыночной ситуации и умение управлять психологией коллектива. А тестер набирает библиотеку скриптов для тестирования всего, с чем довелось столкнуться. Все вместе каждый раз на новой разработке чему-то учатся, стараясь использовать старый задел. И точно также, как человек, привыкший делать всегда все с нуля, оказывается поражен уровнем разработок в фирме, где годами копили опыт в ДОСТУПНОМ К ИСПОЛЬЗОВАНИЮ виде, также и формализованное, документированное, во многом автоматизированное тестирование способно сильно удивить. Меня, например, сильно удивило, когда немцы показывали, как они проверяют тормозные блоки при массовом производстве: на каждый датчик давления - свой штуцер от насоса с регулируемым давлением, специальная плата, разъемы которой охватывают контрольные точки, измерительные приборы, подключенные к компу. Поэтому говорить, что "За то время, пока фирма сумеет наладить стенд автоматизированного контроля, "добровольные тестеры" юзеры пришлют нам M претензий мылом, и мы выпустим N новых версий" - не
правильно, все от типа изделий и рынка зависит. Тестеру, м.б., даже проще успеть сделать СТЕНД, чем разработчику ИЗДЕЛИЕ, ибо при равной готовности "библиотек" того и другого разработчик столкнется с бОльшим объемом нового для себя, чем тестер (все же, новые типы датчиков, новые протоколы и шины, новые элементы интерфейса появляются реже, чем новые микросхемы и системы команд); но если "библиотек", предыдущего опыта у фирмы нет, то тестер, конечно, опоздает сделать все с нуля по сравнению с разработчиком - одно дело реализовать универсальный тест протокола или шины, другое - использовать некое минимально-достаточное подмножество команд этого протокола или режимов шины.

"1.Попробуйте прикинуть, во что обойдется создание тестирующего
оборудования." - т.е. предполагается как раз ситуация, что тестер начинает всегда работу с нуля. Т.е. фирма НИКОГДА не работала и не хочет работать (=не хочет НАЧАТЬ создавать копилку решений по тестам) на рынках тех изделий, где пользователь требователен к качеству и категорически не согласен что-то тестировать у себя. Ну что же, можно просто подождать, когда пользователь попривыкнет.
Тут, по-моему, прямая аналогия с производством - можно ведь только перепродажей заниматься, со словами "попробуйте прикинуть, во что обойдется закупка станков для производства"

Может немного подолью масла в огонь, может это и , но тут упоминалось не раз ТЗ. К нему хорошо бы добавить Методику приемки-сдачи. Казалось бы, этих документов достаточно, чтобы сделать и сдать. Оба документа утверждаются сторонами. В жизни часто бывает не всё так просто, т.е. не всегда есть возможность следовать букве документа при сдаче изделия.
Ирония судьбы: когда тестируешь изделие в процессе разработки-производства-наладки, тогда лучше его понимаешь и видишь, как же бездарно сделано ТЗ. А уже поздно. Потом понимаешь, как же влип с такой Методикой приемки-сдачи. Тоже поздно. Иногда правда бывает возможность утвердить Методику на последних этапах работ, тогда немного проще.
Несколько вариантов развития событий, чисто по личному опыту за 20 лет:
1) Заказчик свой в доску, работаете с ним десяток лет, это не первый заказ. Попадос, так как, если хотите сохранить лицо, он вас неизбежно нагнет и Вы сделаете, как он хочет, чтобы сохранить "теплые отношения". Здесь обычно спасают сгоревшие сроки, Заказчик готов принять изделие, лишь бы закрыть бумаги, а потом будет мучить Вас до потери пульса, заставляя модернизировать изделие, но после приемки.
2) Заказчик новый или очень крупный (много чиновников и спецов). Попадос, так как некому понять Ваши тяготы, нехватку времени, людей и средств. Здесь может спасти только неопределенность фраз в обоих документах. Двусмысленность позволяет выиграть время, но не более того.
Вывод:
-много внимания уделите созданию ТЗ, нажитый опыт только помогает
-оттяните утверждение Методики приемки-сдачи до последнего этапа разработки-производства
-тестируя изделие, изучайте его, чтобы легче было сдаться

one_man_show
То, что оба документа утверждаются сторонами. и по моемо опыту недостаточно. Тут я вижу две проблемы: проблема стандартных решений и проблема неуважения к формальностям.
1. Проблема стандартных решений (я её называю «Генералы всегда готовиться к прошедшей войне»).
Это очень серьёзная проблема, связанная с инертностью человеческого мышления (по себе замечаю ) и неофобии (если я не ошибаюсь в названии). Очень не многие люди могут критически взглянуть на свой багаж знаний (те кто может, как правило, сидят в конференции: ) ). «Все разработчики рабы своих семейств» - это уже проверено и работает, времени нет, так что будем делать на 155 серии. И ты хоть в лепёшку расшибись доказывая, что так дольше и дороже, всё равно на 155. Ах как хочется не думая, «впарить» знакомый микроконтроллер и не мучиться с FPGA. Согласен, что на переправе коней не меняют, но тогда их просто надо менять раньше. Нормальный разработчик, я как вижу по своим знакомым, живёт старыми знаниями, назавтра копит новые. Обе крайности вредны. И, как абсолютно правильно заметил уважаемый yornik тут, по-моему, прямая аналогия с производством . Я резкий противник революций, но иногда просто необходимо менять наработанные технические решения, иначе изделия становятся неконкурентноспособными.
2. Проблема неуважения к формальностям (я её называю с соответствии со словарём руководителя «Шозахер» (Ваша пояснительная записка излишне перегружена цифрами и фактическими данными) ). Когда разработчик рано переходит в ранг руководителя (а, что ещё хуже, таковым становиться сразу), у него возникает «головокружение от успехов»: новая область знаний (отстань ты со своими графиками, мне тут договор посмотреть надо!), подковёрные интриги (тоже мне, блин, проблема с «микрухой», здесь вон соседи заказ «утаскивают» прямо из под носа). Ему просто некогда (да уже и не охота) вникать в детали, работать с документами (чё ты мне эту бумажку с MTBF под нос тычешь), продумывать всё досконально (щас новая эра – я чё, не знаю как софт пишут штоль? – одни пальцем, бряк на форму компонент, щёлк в инспекторе объектов!). Как говорит один мой знаковый, Билла Гейтса можно убить уже за то, что он позволил домохозяйкам считать себя инженерами . Человек с большим опытом работы мудр, он знает как делать не надо делать, а как можно попробовать. Он дёргает за невидимые ниточки управления аккуратно, чтобы у подчинённого сложилось впечатление, что это он сам придумал, добился. Мне повезло с технической базой, я работал под началом очень опытных специалистов (как программистов, так и аппаратчиков). Но я также побывал под управлением грамотного менеджера. Он приучил меня на каждый чих иметь бумажку (в том числе и от заказчика). Не начинать производство до тех пор, пока не будет согласовано всё, вплоть до сроков поверки последнего используемого вольтметра. Это имело двоякую цель: затянуть сроки за счёт заказчика (дать больше времени всем службам на подготовку) и уточнить недоработанное ТЗ. Когда все документы на разработку были согласованы, как правило, полноценный макет изделия уже был «обнюхан» полностью, ведомость замены имела по пять наименований в каждой позиции. По существу, методика и программа испытаний изделий (которая направлялась заказчику) – это протокол испытаний макета . Также было требование, чтобы документы по проведению испытаний писал отдельный человек. Принципиально из другого отдела. Он мог тормознуть всё. Сначала меня это раздражало (я разработчик – как сказал, так и будет!), а затем я понял глубокий смысл в такой постановке дела. Ну сделал ты прибор, молодец, а кто тебе поверит, что ты его действительно сделал? При этом он смотрел на твоё издание глазами пользователя – и находил массу «ошибок», «неточностей», «несуразностей » и т.п. То, что ты считал «и так понятным» (это я про UserInterface), на самом деле далеко неочевидно.
А вообще-то, всё, что сказал one_man_show и yornik – это готовый рецепт, как надо правильно делать дело!
З.Ы. Извиняюсь за возможный off, просто есть желание поделиться опытом и послушать дельные замечания опытных профессионалов. Вдруг я не прав?
З.Ы.Ы. Составление ТЗ обычно мне всегда напоминает анекдот, про «Вам чай с сахаром или без сахара, чёрный или зелёный, холодный или горячий, в кружке или в стакане».

Я бы добавил еще один пункт: тестирование ПО в процессе разработки, по-моему, половина участников имеет ввиду именно это.

Для тех, кто умеет читать.

http://offline.computerra.ru/2005/576/37494/

В этой статье несколько раз было упомянуто тестирование при разработке. Упомянуто довольно грамотными людьми, которые понимают о чем они говорят.

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

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

Вот по-моему интересная книжка, правда по Java, однако подходы применимы и к другим языкам:
Pragmatic Unit Testing
найдена на http://ebuki.powernews.ru/

Кроме того, интересные книги по теме там же:
изд. Artech House: Agile Software Development
Рассматриваются основные подходы к разработке ПО: FDD, XP и т.д., оттуда можно многое взять, например, разработку через тестирование от XP или инспекцию кода от FDD.

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

Более того, есть сферы, где тестирование ПО является обязательным звеном по пути выхода на рынок с новым продуктом. Таков, например, Bluetooth. Для того, чтобы иметь официальную возможность (www.bluetooth.org) распространять свой bluetooth-powered товар, необходимо пройти т.н. процедуру квалификации, когда все уровни стека (в том числе написанного вами) подвергаются независимой "проверке на вшивость". Это правильно - иначе из-за какого-нить нерадивого производителя может быть дисквалифицирована сама идея данного радиоинтерфейса...