Вопрос возник вот почему. Ездили у нас товарищи на стажировку в америку. Так вот, там тестирование ПО, происходит следующим образом:
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 тестировался и по частям и целиком и на разных компах и на разных операционках. И, по всей видимости качество тестирования оч. хорошее. Видимо стоимость тестирования была оценена правильно

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