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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс зависит от возможностей используемого инструментария, так что рекомендую поискать альтернативу CVS.

Вариант для SVN:
- все тесты в репозитории (одном или нескольких), сопровождаются в обычном порядке.
- копилка: "пустой" проект под svn, в свойствах которого (svn:externals) перечисляются пути (куда: common/test1 ... ) и что/откуда (с какой ветки и т.п.) брать.

После создания рабочей копии копилки будут извлечены все релизные исходники всех тестов ( или если необходимо и бинарники, если они будут занесены )

to vitan:

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

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

" - Уважаемый Чеширски Кот, скажите по какой дароге мне идти?
- Это зависит от того, куда ты хочешь попасть?
- А мне все равно куда.
- Ну тогда, все равно по какой идти..."
Что за конкретно тесты - это зависит от того, что за конретно железо (и софт вокруг него) .

Я бы рекомендовал для начала сделать пару документов, типа "Стратегия тестирования" (цели,
принципы, подходы, средства и т.п. тестирования) и "Тестовый план" (перечень функций которые
надо протестировать, перечень тестов и алгоритмы (методы) тестов). Пока будите над работать
ними - наступит просветление .

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

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

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

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

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

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

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

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

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

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

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

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

в 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 это тонкое искуство.


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

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

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

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

cvs2svn
RefineSvn

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

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

Да, эти штуки мне знакомы, спасибо. Они даже полезны, рекомендую всем юзерам CVS переконвертить ради хохмы свои репозитории разок, сразу увидите кучу скрытых ошибок.

Вот связь с требованиями бы еще установить...
Посмотрел Trac. Есть там тикеты типа Requirements, но имхо как-то они неразвиты там.
Нет возможности отследить связи и конфликты требований.
Или я плохо смотрел, кто знает, просветите!

Позволю себе поднять тему.
Прошло некоторое время, и появилось больше ясности, накопилось больше опыта, может, кого заинтересует.
Итак, предлагался один из вариантов

Пришел к следующей структуре


Каждый тест делится на свои стандартизированные каталоги, о них в форуме уже много написано.

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

Короче говоря, исходный вопрос решился более тщательным продумыванием и осознанием этапности в разработке, а также необходимости повторного использования наработок (/Lib) как можно более часто, за что спасибо ALL.

Связи c требованиями пока нет, как и самой работы с требованиями, но просматривается возможность создания тестов для каждого требования и расположения этих тестов в репозитории в папках с номерами требований (вместо, например, /Tests/Diagnostic/CPU/Test1 будет /Tests/Diagnostic/CPU/Req1).

В общем, появились шансы на победу, с чем я себя и поздравляю накануне праздника!