Тесты железа, как их организовать в 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, то какая структура каталогов? Если база данных, то как выглядит? Я понимаю, что у Вас процесс уже отлажен. Расскажите поподробнее, что дальше?

[spf]

2 SPF:
Ну вот, спасибо, это один из вариантов. Но, честно говоря, какой-то не очень структурированный... Имхо, имея многообразие видов тестов будет тяжеловато... Про виды я ниже поясняю. Если я правильно понял, то предлагается иметь некий "оперативный" репозиторий, из которого переносить устоявшиеся файлы в "главные" в процессе понимания ценности созданного. Это похоже на фаловую помойку, но только выше на один уровень абстракции (с использованием средств контроля версий). Или я не въехал...?

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

Код

  test_all/
      test1/
          common/
          src/
          makefile
      test2/
          common/
            src/
            makefile
      test3/
          common/
            src/
            makefile

такое получается при небольших затратах и определяется в первую очередь структурой самих тестов.

[vitan]

Только оперативного репозитория не надо.
"Сборник" нужных тестов организуется в специально организованной рабочей копии всего чего надо.
Про "тяжесть" ничего не скажу т.к. то сих пор не представляю что надо в конце концов...

Ну вот, теперь понятно.
А что скажете про появление и устранение ошибок? Как по-вашему надо организовать и хранить тесты, которые проверяют только найденные и исправленные ошибки? Можно завести для них отдельный каталог, но ведь все равно они потом должн ыбыть включены в общий набор тестов. Копировать их в основной каталог...? Или, может быть, создать некий скрипт, позволяющий извлекать определенные тесты? К примеру, отладили ошибку №123, добавили в скрипт номер этой ошибки, и при последующих извлечениях тесты, связанные с ней попадут к нам в рабочий каталог.
Интересно, кто-нибудь подобное делал?

Еще один вопрос связан с конфигурацией испытательной аппаратуры. Железо, которое мы делаем, по идее, может проверяться на разных стендах. Как лучше: создавать ветки в репозитории, или хранить в отдельных модулях тесты для каждой конфигурации?

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

[spf]

А что скажете про появление и устранение ошибок? Как по-вашему надо организовать и хранить тесты, которые проверяют только найденные и исправленные ошибки? Можно завести для них отдельный каталог, но ведь все равно они потом должн ыбыть включены в общий набор тестов. Копировать их в основной каталог...? Или, может быть, создать некий скрипт, позволяющий извлекать определенные тесты? К примеру, отладили ошибку №123, добавили в скрипт номер этой ошибки, и при последующих извлечениях тесты, связанные с ней попадут к нам в рабочий каталог.
Интересно, кто-нибудь подобное делал?

Не надо никаких скриптов, можно сделать через svn:externals - аналог modules(CVS)
Файл в котором будут перечислены все необходимые тесты будет выглядеть так

Код

  test1        http://repos/..../test1_ok
  test2        http://repos/..../test2.1
  error135   http://repos/..../error135.1

* - repos может быть разным
После извлечения каталога для которого задано подобное, вытянется все что указано в правом столбце и будет помещено в каталог который приведен в правом.

[vitan]

Хм. Действительно, здравая мысль. Спасибо.

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

Я уже почти готов согласиться на такой вариант работы, но смущает вот что.
1) Постоянно потребуется изменять фалик modules (в моем случае с CVS; уж простите, но я с CVS-то еще не всех научил работать, а если я SVN начну толкать, меня замочат просто.... )
Это будет означать необходимость постоянного изменения мануала по модулям CVSа (я вынужден был сделать такой мануал, чтобы народ знал что где) и, возможно, путаницу.
2) Для самоуспокоения (и для успокоения начальства) хотелось бы иметь связь возникающих тестов с требованиями к железу, дабы ни у кого не возникало дурацких вопросов типа "че это вы тут делаете?". Я пока не решил, в каком виде будут храниться и отслеживаться требования, скорее всего это будет база данных из серии DOORS или RequisitePro; так вот тут опять же проблема: как состыковать БД и CVS/SVN.
Для CVS я видел только аудиторский плагин к репозиторию, хранящий свою инфу в своей БД, но это не то, а больше завязок с БД я не видел (и у SVN тоже).
Возможно, удастся путем проавильного проставления тегов и, опять же, неких скриптов связать определенные ревизии тестов с требованиями, но выглядит это как-то муторно...
Уверен, что решение существует, но найти бы его.
PS. В качестве полного комплекса средств я недавно рассматривал те самые проги от Rational и Telelogic, но как-то ближе мне идеология GNU, все-таки...

[spf]

1) Постоянно потребуется изменять фалик modules (в моем случае с CVS; уж простите, но я с CVS-то еще не всех научил работать, а если я SVN начну толкать, меня замочат просто.... )
Это будет означать необходимость постоянного изменения мануала по модулям CVSа (я вынужден был сделать такой мануал, чтобы народ знал что где) и, возможно, путаницу.

в svn есть команда ls
List each TARGET file and the contents of each TARGET directory as
they exist in the repository. If TARGET is a working copy path, the
corresponding repository URL will be used. If specified, REV determines
in which revision the target is first looked up.

поэтому нет необходимости сопровождать модули.
Выведет что есть на текущий момент в каталоге tags в формате XML.
svn ls --xml svn://repos/tags
Можно посмотреть состав "модуля" test1:
svn ls -R --xml svn://repos/tags/test1

Не замочат, а только вдохнут с облегчением.
Есть дока на русском, GUI-клиенты и т.п.
И самое главное - вылечены основные болезни CVS... - Перевод главной страницы официального сайта Subversion
... И тем более надо успевать пока еще не всех научил, чтоб не переучивать
SVN сделан очень похожим на CVS, поэтому простой пользователь может и не заметить что команду cvs заменили на svn
... и инструкция для svn будет короче, т.к. с ветками проще, а в cvs это тонкое искуство.

2) Для самоуспокоения (и для успокоения начальства) хотелось бы иметь связь возникающих тестов с требованиями к железу, дабы ни у кого не возникало дурацких вопросов типа "че это вы тут делаете?". Я пока не решил, в каком виде будут храниться и отслеживаться требования, скорее всего это будет база данных из серии DOORS или RequisitePro; так вот тут опять же проблема: как состыковать БД и CVS/SVN.

Речь про "issue tracking systems"?
Для SVN есть Trac.
Описание впечатляет, но попытка быстро настроить успехом не увенчалась...
Поэтому пока используем простенькую - roundup.

Сообщение отредактировал spf - Jul 21 2006, 07:35

[vitan]

Эх, кабы все было так просто... Десяток проектов в CVS длиною в пару лет нелегко перевести на SVN. Но о новых ндо подумать, Вы правы, конечно...

Речь про "issue tracking systems"?

Нет, речь про "requiremetns management systems"
Фишка в том, чтобы каждый тест проверял свое требование и свою ошибку, как и надо по науке...

[spf]

Эх, кабы все было так просто... Десяток проектов в CVS длиною в пару лет нелегко перевести на SVN. Но о новых ндо подумать, Вы правы, конечно...

Да хоть два десятка и больше 5 лет ;-), все реально при желании, сам проходил.

cvs2svn
RefineSvn

Пользовал первый.

PS:
Работать в двух системах будет еще сложнее, постоянно будут тормозить ограниченности cvs.