Тесты железа, как их организовать в 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]

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

Про структурность, что может быть структурнее

Код

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

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

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

Код

/
/Lib -- наборы часто используемых функций
/Tests
/Tests/Debug -- тесты на обнаруженные в процессе жизни изделия ошибки
/Tests/Debug/Bug1
/Tests/Debug/Bug1/Test1
/Tests/Debug/Bug1/Test2
...
/Tests/Diagnostic -- тесты функционирования изделия (а точнее - его компонентов)
/Tests/Diagnostic/Device1 -- тесты отдельных компонентов (CPU, RAM etc)
/Tests/Diagnostic/Device1/Subtest1
/Tests/Diagnostic/Device1/Subtest2
...
/Tests/Performance -- тесты характеристик компонентов
/Tests/Performance/Device1
/Tests/Performance/Device1/Speed
/Tests/Performance/Device1/Accuracy
...
/Tests/Reliability -- тесты устойчивойсти всего изделия к внешним воздействиям (температура, питание etc)
/Tests/Reliability/Temperature
/Tests/Reliability/Power
...
/Tests/Interaction -- тесты взаимодействия компонентов
/Tests/Interaction/CPUvsRAM
/Tests/Interaction/MICvsPHONES
/Tests/Interaction/UARTvsVIDEOCONTROLLER
...
/Tests/Approval1
/Tests/Approval2
/Tests/Approval3 -- специальные тесты, разрабатываемые на различных этапах испытаний изделия (после приемосдаточных), типа в составе другого изделия, где-нибудь на объекте и т.п.
...

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

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

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

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

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