Тесты железа, как их организовать в CVS? Опции

[vitan]

Вопрос этот мучит меня уже долгое время.

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

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

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

Как организовать структуру каталогов в CVS, чтобы было ясно видно, что для чего?
Как организовать модули CVS для тестов: должен ли быть один модуль на все тесты (с веточками по ошибкам, или лучше иметь модули для отладочных, сдаточных и регрессионных тестов)?
Может быть, CVS вообще не лучшее средство контроля имеено для тестов?

Если налаживать работу с системой управления требованиями, то появляются дополнительные вопросы.
Как связать каждое требование к железу с конретным тестом понятно, но вот - с его историей?

Поделитесь опытом, плз!

[spf]

Может быть, CVS вообще не лучшее средство контроля имеено для тестов?

CVS уже давно не лучшее средство контроля и для исходников.
Рекомендую посмотреть на SubVersion (ссылка на мою страничку).
У нее более севершенная технология веток и т.п.
Посмотри subversion, может твои идеи (пока не очень понятные) на новой платформе лучше реализуются.

[vitan]

Узнаю...
Когда-то давно читал.
Спасибо, но вопрос даже не в средстве контроля (SVN у меня есть, согласен, что она лучше, но исторически юзаю CVS), а в организации процесса, так сказать.

Вот, к примеру, исходники многих GNU программ организованы по каталогам типа Arch и Common, каждый каталог для своих целей. Как хранить тесты?

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

Возникает вопрос: как вести эту общую копилку? С помощью той же системы контроля версий, с помощью базы данных (возможно, связанной с системой управления требованиями), или еще как-то?

Кто как организовал тестирование своего железа?

Сообщение отредактировал vitan - Jul 19 2006, 06:48

[Doka]

to vitan:

я понимаю что абстрагирование от конкретики на каком-то этапе обсуждения - хорошо.
но всёже - конкретно что за тесты?
т..е. что собой представляют файлы: просто наборы вх.и вых. воздействий, которые после пргонки верифицируются на РС, либо самоверифицируемые модули, интегрируемые в ПО тестовых версий(Си, HDL), etc...
можно этот нюанс подробнее?

[ywg]

to vitan:

я понимаю что абстрагирование от конкретики на каком-то этапе обсуждения - хорошо.
но всёже - конкретно что за тесты?

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

[Doka]

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

ну, мы институтов не оканчивали. умных слов таких не знаем =)
даже не знаю каким боком к этому месту прикрутить систему контроля версий..
может Вы какой совет по существу vitan'у дадите?

Сообщение отредактировал Doka - Jul 19 2006, 20:36

[vitan]

2 SPF:
Ну вот, спасибо, это один из вариантов. Но, честно говоря, какой-то не очень структурированный... Имхо, имея многообразие видов тестов будет тяжеловато... Про виды я ниже поясняю. Если я правильно понял, то предлагается иметь некий "оперативный" репозиторий, из которого переносить устоявшиеся файлы в "главные" в процессе понимания ценности созданного. Это похоже на фаловую помойку, но только выше на один уровень абстракции (с использованием средств контроля версий). Или я не въехал...?
2 Doka:
Тесты у нас пока выглядят так. Если имеем плату с CPU, то пишем тесты отдельных частей платы (разных девайсов), которые исполняются этим CPU. В принципе, testbench-ей пока не делаем, хотя на платах и присутствуют ПЛИСы. Кроме того, недавно появилась у нас т.н. КИА (контрольно-испытательная аппаратура), которая позволяет взять плату, воткнуть ее в КИА, подать на нее воздействие и сравнить результат с желаемым. Поэтому тесты теперь будут исполняться не только на целевой платформе, так сказать.
2 ywg:
На фоне таких слов сам чувствую себя незнайкой... Если не затруднит, киньте ссылочку, где почитать...
2 vladv:
Сии документы я недавно закончил. Они, конечно, помогают в мозгах порядок навести. Но вот мы начали создавать тесты (по плану, по науке), а как за ними следить и организовать? Если CVS/SVN, то какая структура каталогов? Если база данных, то как выглядит? Я понимаю, что у Вас процесс уже отлажен. Расскажите поподробнее, что дальше?